AdTechSTUDIOでのAWS活用戦略
サイバーエージェント 木村衆平様より、アプリケーションエンジニアの視点から。
オンライン広告の今
オンラインディスプレイ広告を取り巻く環境
ターゲティング広告の流行
オンラインで流行っている広告は、「ターゲティング」。かなり細かくターゲティング出来る時代になってきた。誰にどんな広告を、の、だれが非常に重要視される用になってきている。
このような広告が発展していったのはWEB広告で計測ができるという特性がある。
シビアにこの広告予算で良いかという部分を見ることが出来る。ROIを追求していくとターゲティング広告の重要性が必然的に上がっていく。
広告出稿のリアルタイム化
広告出稿の意思決定がリアルタイム化してきている。出すか、出さないか、どのくらいの金額を払う価値が有るかをものすごく短時間で判断する必要がある。
Dynalystが出来るまで
Dynalystとは
ユーザーパーソナライズドな広告配信サービス。
ユーザーがある広告主のサイトを訪問して、洋服を見たりとサイト内で行動する。その行動をトラッキングして広告を出す。
その人は広告を打つべき人なのか？すでに購入が終わっているなら、すぐに広告を出さないほうが良いし、迷っていそうであれば、商品をおすすめしてみたり。Amazonのお勧め欄の広告板のようなものです。
Dynalystは基本的に全てAWSで運用されています。
今回、Dynalystの紹介にあたって2つキーワードを挙げさせて頂きます。
- リアルタイム
- ユーザーパーソナライズド
リアルタイム
サイト内のユーザー行動がリアルタイムに広告に反映される、RTB時代だからこそ出来る。
バナーを管理画面から入稿して配信という形だったが、入稿事態が自動化されていたり、それをユーザーが訪問した時にリアルタイムに判断するということが出来るようになったり。
ユーザーパーソナライズド
サイトを訪問したユーザーによって見えるバナーが違うようになる。例えば、女性向けのアイテムが並んで、男性なら男性向けアイテムが並んだりと変化する。
Ad Tech StudioでのAWS活用戦略
スピーディーにプロダクトを世に送り出すための工夫
Dynalystをどのように作ったか？
人数はとても少なかった。5,6人の人数。アプリケーションを作る人だけでなく、サービスをどのようなものにするか企画する人含めてこの人数。リリースまで2,3ヶ月というスケジュール。
大切な要件として上がっていたのはRealTime。計測から配信への反映機関を短くすることが広告効果に絶大な影響を及ぼす。
そして、配信量が増えて、一日数数億インプレッションをさばけるようにする。
アプリケーションの機能に集中する
アプリケーションを開発する、AWS基板を作る人達はビジネスロジックに集中できることが重要だと思っている。システムそのものに大きな価値はなくて、お客様の期待を超えたプラスアルファの部分が「サービス」なのかなと思う。
広告の目標にフォーカスできるようなものにしたかった。
そこで「User managed service as much as possible !!」。
開発で大切にしたこと
広告主サイトに訪れたユーザーの行動を計測する。
ユーザーの小魚津に基づいて趣味趣向に合いそうな広告を配信
できるだけタイムリーに効果を確認できるようにする。
どのように実現したか
ELB → WEBアプリケーションがログを吐く → fluentd → DynamoDB、ElasticCacheにデータを投入
DynamoDBが行動ログを記録、ElasticCacheは、ターゲティング配信ならターゲティング対象化を判断するのが重要なので、その判断のキャッシュとして利用する。フットプリントサマリーのようなものになっている。
DynamoDBの活用
DynamoDBのユースケースとしては典型的になっている。ハッシュキーでユーザーが居て、RangeKeyでいつ、そのあと、どの広告主の何をどうしたという情報を入れていく形になっている。
広告主ごとにどういう情報を持っておくべきかは変わってくる。
旅行系ならいつ何(どのホテルのどのコース)を買ったかに加えて、その宿泊の期間がいつなのかが付加されてくる。
ElasticCache
あるユーザーが広告主様のサイトで最後にとった広告はなにかという情報を持っている。
リアルタイム性が重要だと言いましたが、ユーザーが最後にとった情報も極めて重要になります。
テーブルの構造は、Redisの使い方のようになるが、KeyにたいしてハッシュテーブルでValueを持っている。Redisはメモリを使っているので、広告主の数が増えてきてもメモリが単純増加しないような作りでハッシュテーブルで持たせている。
配信機能でまず判断したい、ターゲティング対象か否か？を判断するのに使う。
ターゲティング対象である確率は一般的に２０％以下
ということはなるべく早い段階で残り８０％の対象でないという判断がしたい。その判断に使う。
広告配信の仕組み
ElasticCasheに問い合わせる、対象であれば、DynamoDBに問い合せ、ではこの広告で、というのを決定する。
DynamoDBはいろいろな広告材料を持つDBとつながっている。
どのように趣味趣向を解析するか？
ここまでは、一度見たものを広告に出すようなパーソナライズドだが、よりユーザーに合わせて最適な広告を出したい。
どのように趣味趣向を判断するのか。あるメディアサイトに訪れたユーザーに対し行動に基づく趣味趣向に合いそうな広告を配信する。
fluentdがlogをS3に上げて、SQSに通知、ワーカーアプリケーションがそれを消化していく。マニフェストを作ってRedshiftへコピーしていく。
流れ込んだ先のRedshiftでユーザーの広告反応や、ユーザー一人がどのような行動をしたかという情報プラス、おすすめすべき商品の一覧、そして、そのユーザー以外の人がどのような行動をしているのかというのをセグメントで分けて抽象化し、おすすめすべき商品を解析・予測していく。
なぜRedshiftか
配信ロジックが変わった時にどのように変化が出るのかをなるべく早く察知したい。
１時間すら待ちたくない、RTBの世界で１時間たっても広告配信結果が見られないのはありえないということで、すぐにRedshiftへコピーしている。
分析する人が、SQL書ければ基本的な分析がRedshiftで出来る。そういう分析が低コストでできるのが重要だと考えている。
データがあって仮設を立てて検証していく流れの中で、ぼくは仮説の精度を上げることが非常に重要だと思っていて、様々な角度から簡単にデータを見ることが出来るという意味でRedshiftは良いと思っている。
分析基板というくくりに入っているが、データとして集約しても居るので、レポーティングの基板としても使っています。
なぜそんなに高頻度でコピーを流すのかというと、最新を分析できるようにということに加え、マネージドサービスを全面的に信頼するという考え方だと、自分らでEC2上に載せるアプリでは、そこにデータを置かずに、マネージドサービスにデータを運ぶほうが良いのではないかと思っている。
小さい単位でマネージドサービスに移してしまって、移した先で、集約されて大きくなっていくのが良いと。
fluentdもログ集約として使うのが普通だと思うが、私達のサービスでは各アプリケーションのfluentdがそれぞれサッサとデータを転送する。
そうして配信した結果がRedshiftに溜まっていくが、それをどのように使うのかというところで、小刻みにRedshiftへデータを入れているので、まずは、広告主様にフィードバックしたり、あとは、広告配信に活用するために、このような広告配信ロジックではこのような結果になったという情報をRDSに溜め込み、次へ活かしていっている。
これが、計測→配信→集計の流れになります。
CAでのAWS活用事例
サイバーエージェントはAWSをいろんなのところで使っています。
新規事業がとても多く、それがとてもスピーディーだと思っています。
広告配信サービスは、たくさんあって、Dynalystはその一つにすぎない。
変化の激しい業界・組織の中でリザーブドインスタンスを買うのはものすごく頭を捻らなければならない。
安いのは知ってるけど、どうやって導入したらいいんだ！というところでひっかかっていた。
Consolidated Billing
全社システムの親アカウントを持っていて、会社が違っても事業部が違っても子アカウントとして紐付けて、それぞれが別々に運用していく。
こうするとリザーブドインスタンスが買える状態になる。
親がリザーブドインスタンスの一括購入をおこない、子アカウントは初期費用を気にすること無く利用開始する。親アカウントは全体でRI適用率が６０〜７０％負担になるように１年のリザーブドインスタンス購入計画を立てる。