作成者別アーカイブ: kanapom

ClassicLinkを使用してVPCとEC2-Classic間の相互通信を行う

Pocket

こんにちは。技術開発部部長の川住です。

弊社DSP「Bypass」はシステムをAWSに移行してから5年以上が経過しました。近年ではEC2インスタンスをVPC (Virtual Private Cloud) 内に作成し運用していますが、AWSへの移行当初にVPC外(EC2-Classic)に作成したサーバがいくつか現在も稼働しており、「VPC内で稼働しているインスタンス」と、「VPC外で稼働しているインスタンス」が混在している環境となっています。今回はこのような環境で使用すると便利な「ClassicLink」という機能を紹介します。

ClassicLinkを使うとできること

  • VPC外のインスタンスと特定のVPCの相互接続

ClassicLinkを使用すると、VPC内(外)のサーバがあたかも同一のLAN上に存在するかのように、VPC外(内)のインスタンスからアクセスできるようになります。これによって、VPC外インスタンスのVPC内への移行を段階的に行えますし、移行の際のダウンタイムを減らせます。

ClassicLinkではできないこと

  • 異なるVPC間の相互接続

ClassicLinkでは、「VPC外 (EC2-Classic) 」のインスタンスと特定のVPCとの相互接続を行う機能であり、VPC間の相互接続には使用できません。このような場合には、「VPC peering」機能を使用して相互接続の設定を行う必要があります。

  • VPC外のインスタンスと、複数のVPCとの相互接続

ClassicLinkはサーバごとに相互接続を行うVPCを設定できますが、ClassicLinkで接続できるVPCは1インスタンスに対して1つだけです。複数のVPCへのアクセスを実現にするには「VPC peering」機能と、VPCのルーティング設定を組み合わせる必要があります。

ClassicLinkの使い方

ClassicLinkの設定はAWSのコンソール画面上、またはaws-cliで行えます。設定したいインスタンスを選択し、接続したいVPC名と、VPC外からの通信の際にVPC側で適用するセキュリティグループを選択します。VPC内のセキュリティグループからはVPC外のセキュリティグループは参照できないので、EC2-ClassicのIP帯などを指定したインバウンドルールを設定したセキュリティグループを作成しておく必要があります。

ClassicLink使用時の注意点

ClassicLinkは起動中のインスタンス対してのみ設定でき、停止すると設定が失われてしまうので注意が必要です。

まとめ

使用できる場面は少ないですが、ClassicLinkを使用することで、VPC内外の相互接続を簡単に行えて、それによってVPC内への移行作業の手間やダウンタイムの削減が可能です。

今回は以上となります。

決定木アンサンブルモデルのデプロイを容易にするライブラリtreeliteの紹介(1)

Pocket

はじめまして。技術開発部の安井です。現在は弊社で運営しているDSPにおける広告効果の分析や機械学習モデルの構築/運用を行なっています。

DSPと機械学習

詳細なDSPに関する説明は省きますが、DSPではSSPから受け取った広告リクエストに対して以下の事項を決定して広告オークションにおける入札応答を行わなければいけません。

  • 入札可能な広告の内、どの広告で入札を行うのか
  • いくらで入札を行うのか

入札する広告、金額を決定にはクリック率、コンバージョン率等の広告リクエストに対する実際のパフォーマンスの値をを活用しています。これらの広告パフォーマンスを入札サーバ上で予測するために弊社では機械学習モデルを活用しています。しかし、DSPにおける機械学習モデルの活用には以下のようなハードルが存在します。

  • 入札サーバを構築しているプログラムと機械学習モデルを学習しているプログラムでは使用しているプログラミング言語が異なる
  • SSPへの入札応答にはシビアな時間制約が存在する

これらを解決するための方法として今回はtreeliteというライブラリをご紹介します。

treelite

treeliteとは近年巷でよく使われているXGBoostやLightGBM等のGBDTの実装ライブラリやscikit-learnに実装されているRandomForestRegressor(Classifier)、GradientBoostingRegressor(Classifier)等のいわゆる決定木をアンサンブルしているモデルのデプロイを容易にするためのライブラリになっています。加えて、モデルが直接Cコードとして吐き出されるため、推論時間の高速化も期待できる実装となっています。開発は以下のリポジトリで行われています。

dmlc/treelite

Referenceはこちら

Treelite: toolbox for decision tree deployment

treeliteを用いたモデルのデプロイのオプションとして次の3つのオプションが示されています。

1.デプロイターゲットのマシンにtreeliteをインストールする

こちらはデプロイ先のマシンにtreeliteをインストールしておくシンプルな方法です。 ゆえにデプロイ先のマシンにpythonがインストールされている必要があります。

2.デプロイターゲットのマシンにランタイムパッケージと一緒にデプロイする

treeliteではランタイムパッケージをアウトプットすることができます。 このランタイムパッケージをデプロイプロセスで同時にターゲットマシンにデプロイすることで、 モデルを使用できるようにする方法です。 こちらもデプロイ先のマシンにpythonがインストールされている必要があります。

3.モデルとなるCコードのみデプロイする

こちらはCコードとしてアウトプットされたモデルのみをターゲットマシンに送る方法です。 Cコードに変換されたモデルは以下のインタフェースから予測値を取得できます。

dataが予測を行うときに必要となる特徴量の集合で、pred_marginはモデルがアウトプットした値をシグモイド関数に通すか通さないかというフラグとなっています(2値分類タスクの場合)。union Entryに関しては以下のように定義されており、特徴量が存在しない場合はmissingに-1が設定されており、特徴量が存在する場合はfvalueに値が格納されている状態を定義します。qvalueに関しては現状使われていないように見受けられます。

golangでのtreeliteモデルの使用方法

上記3種類のデプロイ方法のうち、3番目のCコードのみをデプロイする方法であればpredict関数とのつなぎ込みの部分さえ実装すればpython以外の言語 でもアンサンブルモデルを使用できます。弊社の入札サーバではgolangが採用されており、cgoを使うことでアンサンブルモデルのつなぎ込みを実現することができます。今回はLightGBMのモデルをtreeliteのモデルに変換し、golangから参照する部分までご紹介します。まずは、LightGBMのモデルを読み込みtreeliteのモデルをアウトプットする部分です。LightGBMのモデルはlgb.modelというファイルに保存されていることとします。

5行目のloadでLightGBMのモデルを読み込み6行目で共有ライブラリに変換を行います。その後、7行目で変換した共有ライブラリから必要なヘッダーとCコード、メタ情報を抽出し、zipファイルにまとめます。デフォルトだとzipファイルには以下のファイルがまとめられています。

header.hmain.cが実際のモデル部分でそれらをコンパイルフローがMakefileにまとまっています。recipe.jsonにはモデルコードのメタ情報が格納されています。それではこれらのモデルをgolangから参照できるようにしましょう。コードはこちらとなります。

ディレクトリ構成は以下のようになっていることを想定しており、こちらのコードはmain.goに記述されています。

こちらのコードは16次元のベクトルを受け取り0~1までの確率値を返すモデルを想定しています。予測を行う関数はfunc predictTreelite(fvals []float32) float32ですがまず最初に受け取ったベクトルをバイナリ列の配列に変換しています。これはunion Entryを表現するための型がgolang側に存在しないためこのような形を取っています。今回はベクトルの中にmissingが存在しない想定で実装がされていますが、missingが存在しうる場合は-1のバイナリ列を代わりに入れてあげるようにします。このようにしてバイナリ列の配列に変換されたベクトルをモデルファイルのpredictに渡してあげることでモデルの予測値を獲得します。実際にビルドして実行すると以下のように0~1までの確率値が出力されます。

さいごに

今回はtreeliteでLightGBMで学習されたモデルをtreeliteのモデルに変換して、golangから参照するところまで紹介しました。次回はtreeliteのモデルとLightGBMのモデルとの予測速度比較、golangから参照したtreeliteモデルとgolangで記述されたアンサンブルモデル予測ライブラリleavesとの予測速度比較を行いたいと思います。

treeliteのドキュメント

SQS + Lambdaでs2sの基盤を作った話

Pocket

こんにちは。技術開発部・配信/インフラチームの二階堂です。

弊社のプロダクトでは連携している効果測定ツールに対して、S2Sで通知を行う場合があります。 この通知処理を以前まではEC2上に配置したデーモンプログラムで行っていたのですが、処理の共通化・高速化・インフラ費用削減などの目的でSQS+Lambdaに移行しました。 この経験を踏まえて移行時のポイントを紹介したいと思います。

移行前のフローと問題点

  1. 通知先のURLの入ったログを通知用インスタンス(複数ある内のどれか一つ)に書き出す
  2. EC2上に配置したデーモンプログラムがログを読み込み通知を行う
  3. 同じくデーモンプログラムが通知結果のログを書き出す

問題点

  1. 常時起動のインスタンスが高価
  2. 時間帯によって通知量が変化するため通知量が多い時に時々遅延が発生する
  3. 通知漏れが発生した際にどの通知用インスタンスが原因か調査するコストが高い

SQS + Lambda のフロー

  1. 通知先のURLの入ったログをSQSに送信
  2. 定期実行されるLambda(図中a)がSQSに送られたメッセージ数(NumberOfMessageSent)に比例した数の通知用Lambda(図中b)をキック
  3. 通知用LambdaがSQSからメッセージを取得→通知→結果をS3に保存を5分間繰り返す

特徴・改善点

  • 常時起動EC2よりLambdaの方が圧倒的に安価 (問題点1)
  • 全てのログを一度SQSに送る事でそれ以降のフローを共通化し調査コストを下げた (問題点3)
  • Lambdaを2段構成にする事で通知量の変化に柔軟に対応できるようになった (問題点2)
  • 通知用Lambdaはログのパースと通知しかしていないので他の通知にも容易に対応できる

効果

  • インフラコストが約10分の1に減った
  • リリース以前には定期的に発生していた調査や再通知などの対応もほぼ無くなり安定して動作している

移行した感想

Lambdaの料金は実行時間*メモリ使用量なのでその辺を意識したコードになっていないと高い効果が得られません。 今回の処理内容はただの通知なのでメモリはあまり使わないので速度を上げる工夫として通知部分を並列化しました。 最初は並列化していなかったのですがその時は移行前とあまり費用が変わらなかったことを考えるとコスト意識の重要性が判りやすいのではないかと思います。

今回の基盤開発は並列化対応も含めて何かと初めての経験が多い開発だったので効果にしても経験にしてもとても有意義なものだったと思います。

今回は以上となります。

Lambda@Edgeを利用した画像のリサイズを試してみた

Pocket

こんにちは。技術開発部部長の川住です。

弊社プロダクトにて、「オリジナル画像を適切な大きさに縮小してから読み込む仕組み」を作る必要が生じたので、遅ればせながらLambda@Edgeを使ってみたので、利用時のポイントを紹介したいと思います。

Lambda@Edgeとは?

Lambda@Edgeは、Amazon CloudFrontのエッジサーバで、AWS Lambdaの関数を実行できる仕組みです。リクエスト-レスポンス間の以下4つのタイミングに対してLambda関数を設定できます。

  • CloudFrontのエッジサーバがユーザからのリクエストを受け取る時 (Viewer Request)
  • (エッジサーバにキャッシュがなく)、オリジンサーバへリクエストを転送する前 (Origin Request)
  • オリジンサーバからレスポンスを受信した後 (Origin Response)
  • エッジサーバからユーザへレスポンスを転送する前 (Viewer Response)

Lambda関数に機能を実装することで、例えば以下のような仕組みを実現できます。

  • ユーザ認証やリダイレクトを行う
  • HTTPヘッダを操作する (追加, 削除, 変更)
  • コンテンツを必要に応じて加工してレスポンスする

Lambda@Edgeを使用した画像のリサイズ

Lambda@Edgeを利用した画像のリサイズの仕組みの構築方法に関しては、こちら にて詳しく紹介されていますので、実装の詳細については割愛します。大雑把に言いますと、2つのLambda関数を実装しそれらをCloudFrontに設定することで実現しています。

  • Viewer Requestとして、リサイズ後の幅や高さなどのパラメータを受け取り、パスに組み込む関数をCloudFrontに登録する
    • エッジにリサイズ後の画像のキャッシュがあれば、オリジンへリクエストは転送されず、キャッシュデータがレスポンスされる
  • Origin Responseとして、必要に応じてオリジンから受け取った画像をリサイズし、レスポンスとして返す関数をCloudFrontに登録する
    • オリジンにリサイズ後の画像がすでに保管されている場合は、保管されている画像をレスポンスする
    • オリジンにリサイズ後の画像が保管されていない場合は、画像を取得してリサイズした後、オリジンにデータを格納し、画像をレスポンスする

Lambda@Edge利用時のポイント

Lambda@EdgeはAWS Lambdaと同様の制約を受けるほかに、Lambda@Edge特有の制約や注意点があったので紹介します。

スペック面での制約

AWS Lambdaでは実行時のメモリ量やタイムアウト時間を設定できますが、Lambda@Edgeでの実行時にはこれらの設定上限が通常よりも厳しくなります。

  • メモリ量の上限: 128MB
  • タイムアウトの上限: 5秒

その他制約に関してはこちらが詳しいです。また、AWS Lambdaでは複数の言語をサポートしていますが、Lambda@Edgeで使用できるのは「 node.js 6.10, node.js 8.10 」のみとなっています。

Lambda関数はus-east-1 (バージニア北部) に登録する必要がある

CloudFrontに設定できるLambda@Edge関数はバージニア北部に登録されているものだけです。

バージョンつきのarnを紐つける必要がある

CloudFrontには $LATEST$ALIAS のarnを設定できないので、バージョンを発行したLambda関数をCloudFrontに設定する必要があります。

実行時のCloudWatch Logはエッジサーバのリージョンに排出される

Lambda関数の登録自体はus-east-1 (バージニア北部) ですが、実行はCloudFrontのエッジサーバであるため、実行時のCloudWatch Logの排出先はエッジサーバのロケーションに依存します。 (日本からアクセスした場合には、東京、ソウル、シンガポールリージョンあたりにログが排出されていました。大半は東京。)

使ってみた感想

  • 今回の用途以外にも、A/Bテストなどにも利用できそう
  • 大量アクセスのある場面には注意が必要
    • リクエスト数とLambdaのコード実行時間に比例して利用料金が発生。キャッシュヒット率を高める工夫が必要になってきそう。

今回は以上となります。

AWS ストレージサービス「S3」

Pocket

今週もまた台風が近づいておりますね。 初めまして、今年新卒で入社した技術開発部の程です。 週末は同僚と登山に行く予定なのに台風直撃の知らせを聞いて下がり気分です。 自然ばかりはITの技術だけではどうにもならないので仕方ないですね。

さて、私、現在は自社DSP、Bypassの開発に携わっているのですが 弊社広告配信システムはAWSを利用して構築されております。 今回は、AWSの中でも特に 弊社広告配信システムにおいても実際に活用している S3というストレージサービスについて 簡単に概要や特徴などについてまとめたいと思います。

S3

S3では、バケットと呼ばれる仮想的なオブジェクト置き場に 様々なファイルやメディアコンテンツ(=オブジェクト)を格納し AWSクラウドサーバ上に保存することができます。 保存したオブジェクトはいつでもどこからでも参照したり 新規オブジェクトを追加することができます。

S3の特徴

  • 容量無制限
  • スケーラブル
    容量は無制限となっており、大量のデータを扱う場合にも、上限を心配することなく使用できます。
  • 冗長化されている
    保存したオブジェクトは異なるアベイラビリティゾーン(AWSによる場所の区分け) にある複数のサーバーに複製保存されるので 障害発生時にデータロストの危険性が低く安心です。 また、自前で冗長化する手間が省けるという利点もあります。
  • 高い堅牢性
    99.999999999%(イレブンナイン)の堅牢性(aws公式サイトより)

S3の操作

S3上でオブジェクトは次のような形式で表現され、管理されます。

調べたところ、S3内部ではフォルダという概念はなく、S3上では単純にKey-Value方式でオブジェクトが格納されているのだそうです。 とはいえ、実際に使ってる時はあんまり意識する必要はなく、通常のファイルと同じような感覚で操作できるのがいいですね。

AWSではS3を操作するための方法をいくつか用意しており、目的に応じて使い分けも可能です。 具体的には以下のようなものが挙げられます。

  • ブラウザ上のコンソールから操作
  • コマンドラインから操作
  • AWS提供のSDKより各種アプリケーションから操作
  • 3rd party製のツールで操作

コマンドラインから操作できるのは便利ですね。 以下のように、基本的なバケットやファイルの作成、削除、コピーなどの操作は一通りCLIで実行可能です。

S3操作用のコマンドとしては上記のものの他に、aws s3apiというものがあり、前者はAPIとコマンドが1:1で対応する形の低レベルなコマンド群であるのに対し、後者は複数のリクエストにまたがる様な処理などが実装された高レベルなコマンド群である、という違いがあります。

もちろん、ローカル->S3だけではなく, S3->ローカルやS3->S3間のファイル移動を行うこともできます。

コンソールから操作する場合は以下のような画面上で、バケット作成やファイルのアップロードを行います。

ログインしたら最初に表示されるバケット管理画面のイメージです。

バケット新規作成の後は、そのバケット内に格納されるファイルを管理する画面に遷移します。 この画面上では、バケットへのファイルのアップロードや、フォルダの作成などができます。

適当に1個ファイルをアップロードしてみるとこのようにファイルが追加されます。

コンソール上で操作する場合は、クリック操作だけで非常に簡単に、バケットの作成からファイルのアップロードまで実行することができました。

S3のユースケース

AWS公式サイトやWebサイト上の記事を調べると、次の3つが主なユースケースとしてよく取り上げられています。

  • データのバックアップ
    前述の通り、高い堅牢性を備えていることから、消失すると困る様々なデータを保管する。
  • コンテンツ配信
    S3上に保存したコンテンツを配信する。
  • ログデータなどの保存先
    EC2で収集されたログの退避先、ビッグデータ分析で使用する生データの保存先として利用する。

弊社広告配信システムにおいては特に動画広告の場合に、S3上に動画素材をアップロードした上で AWS CloudFrontとS3を連携させることで、容量の大きい動画系広告でも高速かつ安定した広告配信を実現しています。

バージョン管理

S3で保存されるオブジェクトは、バージョンで管理することも可能です。例えば、誤削除などのミス発生時などにこの機能が適用されていれば、すぐに以前のバージョンに復旧することができます。 この機能を有効化すると、オブジェクトを更新した時などに 前の世代のオブジェクトが自動的に保管される様になります。 何世代分保存するかを指定することもできます。

Notification(通知)機能

バケットにファイルが追加されたことをイベントとして検知したい時はこの機能が有用です。 この機能ではバケット単位で、以下のイベントが発生した際に Amazon SNS, SQS, LambdaといったAWSサービスに通知を飛ばすことができます。

  • 新しいオブジェクトの作成イベント(Put, Post, Copy, CompleteMultiPartUpload)
  • オブジェクト削除イベント(Delete, DeleteMarkerCreated)
  • 低冗長化ストレージのオブジェクト消失イベント(RRSObjectLost)

その他の機能

  • クロスリージョンレプリケーション
    別リージョンへの複製保存を行う。
  • S3へのアクセスログ
    S3上でバケットに対してどんな操作を行ったかの記録ログを出力させる。
  • Tag管理
    バケットに対してタグを指定する。
  • メタデータ
    オブジェクトに対してメタデータを設定する。

私自身、入社して初めてクラウドサービスを触ったのですが 実際に使ってみるとその操作の簡単さと便利さに驚きました。 個人利用も可能なので、個人の自主アプリ制作などにも活用できそうですね。

それでは以上となります。

AWS Glue + Athena構成を試す

Pocket

こんにちは。技術開発部の赤井橋です。

弊社では現在adstirログ基盤のリプレイスを計画しており、その一貫としてAWS Glueでのデータ変換(json → parquet)、及び変換データのAthenaでの検索を試しました。

Glueとは

https://aws.amazon.com/jp/glue/

2017-08-15から利用出来るようになった抽出、変換、ロード (ETL) を行う完全マネージド型のAWSサービスです。 使い所としてはファイルのカラムナフォーマットへの変換、及びパーティションが有効なディレクトリへの配置、データカタログ(テーブル定義のメタデータ)の更新・・など、 ビッグデータを使いやすく成型する場面が多いかと思います。

Glueが提供する機能

大きく分けて2つ存在します。(2018-07-31時点)

1. データカタログの更新

クローラという機能を用いてデータカタログの自動更新を行うことが出来ます。 クローラは指定されたデータソース(特定のS3ディレクトリなど)内をスキャンし、該当ディレクトリにあるファイルフォーマットに合わせたテーブル定義(パーティショニング含む)を自動で行ってくれます。 定義されたデータカタログはAthena、EMR、Redshift Spectrumでも使用(2018-07-31時点)でき、実行スケジュールの登録も可能です。

2. ETL

ジョブという機能を用いてデータ抽出、変換を行うことが出来ます。 ジョブ追加時のセットアップガイダンスに従って進めていくと最終的にPythonのスクリプトが自動生成されます。シンプルな処理であればスクリプトの修正は不要ですが、手の込んだ処理の場合修正する必要があります。 ジョブを定期実行するトリガーという機能もあります。

使用にあたり

上記2つの機能はどちらかだけ使用してもよく、どちらとも使用したい場合も使用順序に制約はありません。 そのため、クローラでテーブル定義を更新し、更新されたテーブル定義を元にジョブでのデータ変換を行う、という流れ以外にもジョブで変換されたファイルに対してクローラでテーブル定義を更新する、という用途でも使用出来ます。

ジョブのスクリプト

セットアップガイダンスを終えるとPythonスクリプトが生成されますが、例えば特定の引数を受け取って処理を行いたい場合は別途実装が必要です。 スクリプトではGlueで独自定義されたDynamicFrameというデータ構造を操作することで独自の変換処理を行えます。

例)AWS CLIからyear引数を指定してGlueを実行し、受け取ったyear引数をS3のデータソースのパスとして設定したい場合

AWS CLI

スクリプト

変換対象のフォーマットが複雑な場合も別途実装が必要です。

例)tsvフォーマットの1列にjson文字列があり、json文字列の部分をstructの配列として変換したい場合

元データ(tsv)

スクリプト

GlueとAthena、使ってみて不自由だった点

Glueでデータソースとして読み込めるのは文字コードがUTF-8のみ

UTF-8以外の文字列が変換対象のデータソースに含まれているとGlueでの変換処理が失敗します。

[AWS Black Belt Onine Seminar] AWS Glue

根本的な解決ではないですが、AWS Lambdaを用い対象となるログファイルをUTF-8に変換する、という前処理を行うことで対処しました。

DPUを上げても劇的な処理速度向上は見込めない

GlueではDPU(データ処理ユニット)の数を指定出来るのですが、2倍にすれば2倍処理が早くなる、という挙動ではありませんでした。 7.7G分のファイルでそれぞれ検証したところ、

という結果でした。

Athenaでのstruct型の使い勝手が悪い

struct型のスキーマ定義に値を追加すると、スキーマと同様の構造で格納されているパーティションでは問題なく検索出来ますが、 値が存在しない(スキーマ変更前の構造の)ファイルが格納されているパーティションでは「HIVE_CANNOT_OPEN_SPLIT」エラーが発生し検索できませんでした。

こちら根本的な解決法はないようで、暫定対応としてstruct型をstring型に変更し検索の際にstring文字列をjsonと扱うように対処しました。

まとめ

検証の結果、コストや処理時間なども考慮するとまだGlue + Athenaを導入する判断に至っていません。ただ、比較的新しく提供されたサービスのため今後も機能が追加され使い勝手も改善されていくはずです。 ビッグデータがますます全盛となる時代、このようなサービスの重要性は増していくのではないでしょうか。

今回は以上です。

APIを利用したCloudWatchの設定

Pocket

こんにちは。配信/インフラチームの佐々木です。

弊社ではAWS上にシステムを構築していますが、前回お話しした通り監視ツールはCloudWatchを利用するケースが増えております。 今回はAPIを利用してCloudWatchを設定する手順をご説明します。

Alarmの設定

CloudWatchの用途としてインスタンスの監視に使うケースは多いと思います。そこでインスタンスのAlarmを設定するスクリプトを作ってみました。aws-cliとbotoどちらかを利用するのですが、今回はaws-cliで実装しています。

このように引数にNameタグを指定して利用します。

インスタンスIDで指定する方がシンプルな実装になるのですが、インスタンスIDはコピーペーストする必要がありますし、Nameタグの方がワイルドカード指定も出来て便利です。またアラーム名にもNameタグが入っていた方わかりやすくて良いと思います。ただNameタグが一意である必要がありますのでその点は注意が必要です。

Dashboardの設定

CloudWatchのDashboardもAPIを利用して設定することが可能です。その手順を記載します。

APIの仕様は以下になるのですが、元になる設定が無いと難しいと思いますので、適当なDashboardから定義をコピーします。ここでは2台のインスタンスのCPU使用率とNetworkInのメトリックを登録しています。

https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutDashboard.html

[アクション]の[ダッシュボードの編集]を選択すると、Jsonの定義を取得できます。ここから直接変更することも可能です。

コピーしたJsonを元に編集します。インスタンスを1台増やしてサイズも倍にしてみました。

作成したJsonファイルを以下のコマンドで適用します。

完成しました。

またこちらのページに、複数インスタンスを自動で登録するスクリプトが載っております。台数や取得するパラメータが多い場合などにはかなり有用かと思います。

https://aws.amazon.com/jp/blogs/news/new-api-cloudformation-support-for-amazon-cloudwatch-dashboards/

今回は以上になります。

監視ツールの比較

Pocket

こんにちは。配信/インフラチームの佐々木です。

今回は監視用ミドルウェアについて比較(と個人的な所感)について記載したいと思います。 私自身が実際に利用したことのあるツールが殆どなので、使用感なども踏まえてお話できればと思います。

Zabbix

ZabbixはラトビアのZabbix社で開発されているツールで、OSSの監視ツールではNagiosと並んでシェアが高い製品になります。Zabbixの特徴としては非常に多機能で、監視については大抵の事がZabbixで出来ますので、監視を一元管理したい場合には非常に有効なツールになります。その一方設定が複雑で、動作も他のツールと比較すると重いです。C言語/PHPで書かれており、設定ファイルがXML(GUIで設定することの方が多いと思いますが)、データストアにMysql/PostgreSQLが利用されていますが、大規模なインフラの監視の場合はRDBの知識が必要になってきます。

Nagios

NagiosはZabbixとよく比較されるツールですが、この二つは意外と差異が多い印象です。Nagiosはアラート機能に特化しているツールで、メトリクス可視化用のツール(munin等)と使い分けて利用する事が多いです。その分軽量かつ設定もシンプルで、バックエンドにデータストアの利用もありません。設定はテキストファイルに記述し、この点もGUIで管理するZabbixとは大きな違いがあります。

Munin

前述の通りNagios等と組み合わせて使われる事が多いツールですが、可視化用のツールなもののアラート通知の機能もちゃんと搭載されています。

Monit

Monitはアラート機能に特化しているツールで、導入と設定が簡単なため、カジュアルに最低限の監視だけしたい!という場合にお勧めできるツールです。一応WEBインターフェースも用意されているのですが、メトリクスを見るのにはあまり適していません。

Sensu

SensuはNagiosの問題点を解決する用途で開発されたツールで、クラウド環境に適した作りになっているのが大きな特徴です。Chef/Puppetを利用することで、エージェントをインストールするだけで監視を開始でき、オートスケール等に対応しやすいのが売りです。SensuはRubyで書かれていますが、データストアにRedis、エージェントとの通信部分にRabbitMQ、WEBインターフェースにGraphite等が使われていて、様々なミドルウェアを必要としますがそれをChef/Puppetで簡単にインストールする、というコンセプトの製品です。設定は全てJsonで行うので、この点もコードとして扱いやすいというメリットがあります。

PandraFMS

PandraFMSはスペインのArtica社で開発されているツールで、AWS等のクラウド/仮想環境への対応やスマートフォンでのWEBインターフェースを備えており、最近の環境に適した製品になっています。無償版と有償版の他にSaasがあるのが特徴で、こういった料金体系の製品はかなり珍しいかと思います。有償版があるだけに使いやすいUIを備え、設定もGUIで行います。開発言語はPerlなようです。

私は今回紹介する中でSensuとPandraFMSだけは利用経験が無いのですが、双方とも機会があれば使ってみたいと思う製品です。

Amazon CloudWatch

監視ツールというよりAWSの機能の一つなのですが、APIを利用することによりAWS以外のリソースも監視可能です。昔は使いにくかったのですが最近かなり改善されており、実際弊社でもアラート通知・メトリクス可視化でCloudWatchを利用するケースが増えています。料金がかかってしまうのが難点ではありますが、監視サーバ用にインスタンスを立てるよりも安く済むケースもありそうですし、AWSを利用している場合はぜひお勧めしたい機能です。

Makerel

はてな社で開発されているSaas型の監視ツールで、日本国内で開発されているだけに日本人向けのUIになっているのが特徴です。面白いのはサーバサイドがScala、エージェントがGo言語で書かれているのですが、エージェント部分はソースが公開されているという点です。Pluginのプルリクエストも受け付けているようで、開発に参加してみるのも面白いかもしれません。

今回は以上となります。

lua-resty-httpを利用したCookieの操作

Pocket

こんにちは。配信/インフラチームの佐々木です。

弊社では広告配信にLuaを利用しておりますが、LuaでCookieを扱う際lua-resty-httpというモジュールを利用すると、Cookieが複数の場合などに非常に便利です。 そこで今回はresty-httpを利用したCookieSyncの流れを、サンプルコードと共に説明したいと思います。 一言にCookieSyncと言っても色々な方式がありますが、今回はSSP(united.jp)側からDSP(example.net)のCookieを自ドメインで保存する形式で記載します。

resty-httpでCookieを付与する処理は上記のようなコードになります。 “http://example.net”というURLにアクセスする際、クライアントが保持しているCookieから該当するプレフィックス_example_が付いている物だけ抽出し、プレフィックスを取り除いた上でヘッダに付与してリクエストします。プレフィックスを入れる処理は後述します。

上記の処理では”http://example.net”から付与されたCookieをTableに保存しています。resty-httpの仕様として、SetされるCookieが単数の場合は文字列、複数の場合はTableとして扱われますので、両方のケースが想定される場合は上記のような処理になります。

CookieSyncをする場合、どのドメインのCookieなのか区別する必要がありますので、プレフィックスに_example_を付与した上で、ドメインを書き換えます。 こうして書き換えたCookieを、クライアントに保存します。 再度クライアントがアクセスした際は、一番上の処理に戻り、保存されたCookieを付与してリクエストをします。

今回はCookieの処理のみになりますので非常に短いコードになりましたが、lua-resty-httpは非常にシンプルで扱いやすく、LuaでAPIを実装する際には非常に有効なモジュールとなっております。

今回は以上となります。

Windows Mixed RealityのadstirSDK研究開発について

Pocket

MRサービス研究開発室の佐々木(竜)と申します。 MRサービス研究開発の一環としてHoloLensのアプリにおいて広告表示を行うSDKを開発しましたのでその紹介をさせていただきます。

前提知識

Windows Mixed Realityとは?

Untitled Diagram
MRは、現在一般的な仮想現実技術のAR、VRを含んだ技術です。 現実空間に仮想的なものを表示する部分から、周りのもの全てを仮想的に表示するところまでを技術範囲としています。

HoloLensとは?

Windows Mixed Realityに準じたAR端末で、端末内にPCが内蔵されており単体で動作します。 視線方向の環境データを認識して現実物体に対してオクルージョンなどの処理をしながら表示することができます。

MixedRealityToolKit-Unityとは?

HoloLensのアプリケーションを作成するときに必要となる、HoloLensデバイスの入力などを容易に制御できるようにするスクリプト群です。 これを用いることにより、Unity上で空間認識などを扱うアプリケーションを容易に開発することができます。

実際の動作動画

SDK設計

動作環境設定

開発環境 Unity 5.6.2f1
Visual Studio 2015

device
HoloLens Developer Edition
Windows10 Microsoft

Plugin
MixedRealityToolKit#Unity 5.6.2f1

Scene Hierarchy 今回はテストのため、広告を表示するのに最低限のオブジェクトのみを配置しています

機能要件

  • UnityのScene内に広告を表示します。
  • 広告は実際にadstir経由で入札を行い、案件をとってきます。
  • HoloLens側の空間認識を利用し、実際に壁にポスターのように表示します。
  • 人のタップしたジェスチャーを認識して、Edgeを起動LPを表示します。

動作フロー

広告表示フロー (2)

①空間を認識する

MixedRealityToolKit内のSpatialMapping.prefabをScene内に配置することで、HoloLensで認識した空間データをもとに、空間をメッシュ化して空間に沿ったメッシュとメッシュコライダーを配置します。作成した空間が、アプリケーションの動作上十分な数に達したとき空間のメッシュへの変換を停止します。

上記のようにコルーチンのStart処理で、マッピングの終了をハンドリングします。 そして、あらかじめ設定した空間認識の時間を過ぎたときMapping処理を止めて、空間メッシュを作成します。 空間認識の処理は重い処理となっているので、アプリケーションの要件に合わせて、空間スキャンの時間を設定します。

参照 : HoloToolkitのSpatialMappingを理解する

②広告データを取得する

①の動作と同時に広告リクエストを非同期で飛ばします。

広告をリクエストする前に、処理が終わったイベントを登録します。OnSetAdImage内では広告が読み込まれたフラグを立てる処理と、タップされたときのイベントをセットします。Unityの他のGameObjectから広告の読み込み終了を参照しやするするために、フラグとしてイベントの終了をUnity側で持っておきます。

Managed Pluginを作成するとき

UnityEditor側からDebugで動作させるときと、実際にHoloLensに配置して動作させるときでアプリケーションのrun timeが変わり、参照できるライブラリが変わってきます。 今回のSDKでは、実際にUnityのSceneに配置する前提でした。なので、UnityEditor側からある程度動作を再現したかったので下記のようなプロジェクト構成をしました。

Pluginディレクトリ構成

Pluginの実態はSharedの中に持っていて、UWP、UnityのフォルダはSharedファイルからのシンボリックリンクを張っています。また、コード内ではコンパイルを切り替えるマクロを使って、動作環境ごとのコードを書いています。

上記のように、NETFX_CORE条件内でUWP側のアプリケーションの挙動、もう一方でUnity側の挙動を記述します。 参照 : HoloLens用 Managed Pluginの作り方

③ 広告を配置する

広告のオブジェクトの読み込みが終わり、空間のデータも蓄積されたとき、広告を壁に埋め込みます。

ここでは、広告オブジェクトを配置する壁オブジェクトを決定します。 視線方向を取得して、壁のオブジェクトと視線がぶつかる位置に広告を配置します。 壁のオブジェクトが広告を配置することができない幅の壁のオブジェクトが、選択された場合は、壁オブジェクトの再配置を行います。

④LPを表示する

広告表示フロー

Sceneに配置した。IntractionManagerにTapしたイベントを登録します。IntaractionManagerは人がGestureなどをしたときにイベントをフックしてくれていて、このコンポーネントを使うことでGestureなどの処理を容易にしてくれています。 Tapをされたオブジェクトが、実際の広告のオブジェクトだった時に、ダイアログを表示して遷移するかを問い合わせます。 遷移するが選ばれたとき、アプリケーションをサスペンド状態にして、Edgeを呼び出します。

参照 : MixedRealityToolkit-UnityのInputManagerを紐解く ~Gesture編~

以上が一通りの動作となります。

まとめ

壁の認識、ジェスチャーからのインプットなどを利用したHoloLens用adstirMRSDKを作ってきました。 現状はまだ、動作環境が制限されるなど様々な課題が多く実用的なSDKとはなっていませんが、ARKit/ARCoreなどのモバイルのARフレームワークの発展とともにコンテンツが成熟してきたとき、また、広告を利用していただける機会が生まれたとき、より良いユーザー体験ができるSDKを提供していきたいと思っています。

ユナイテッドでは、エンジニアを絶賛募集しています!このように最新技術にトライできる環境で一緒に働きませんか?