[要約] Building a Real-Time Bidding Platform on AWS #AWSAdTechJP

[要約]Building a Real-Time Bidding

Platform on AWS#AWSAdTechJP

Amazon Web Services Japan 篠原英治2016年3⽉

Building a Real-Time Bidding Platform on AWS• Whitepapers

– https://aws.amazon.com/whitepapers/

[要約]Building a Real-Time Bidding Platform on AWS• PDFをダウンロードできます

– https://d0.awsstatic.com/whitepapers/Building_a_Real_Time_Bidding_Platform_on_AWS_v1_Final.pdf• 今後適宜バージョンが上がっていきますので、最新版をチェックし

てください– 2016年3⽉現在のversion1の要約になります

Abstract• 本Whitepaperの⽬的

– アーキテクト、広告主、そしてDeveloperがRTBを理解し、AWS上で構築できるようになる

– お客さまがご利⽤になっているものに近いリファレンスアーキテクチャの提⽰とRTB platform on AWSをはじめる上での付加的な情報の提供

Introduction• 2016年のRTBの状況

– オンライン広告は⾮常に伸びており、そこに投⼊されるお⾦は、2016年にテレビ広告を上回ると⾔われている

– オンライン広告の中でもRTBは顕著な伸びを⽰している• RTBはオークションベースでディスプレイ広告の表⽰を取り扱うもの• RTBは2015年においてprogrammaticallyに購⼊する広告の74%を占

めており、それは110億USドル規模である• RTBは2016年に30%の伸びると⾔われている• RTBはMobileのディスプレイ広告でも⼀般的になってきている

– 扱うボリュームが増えていくについて、⼀つ⼀つの広告インプレッションに対して、より良い判断を⾏う必要性が出てくる• AWSはリアルタイムに低レイテンシで解析することを可能にするソ

リューションを取り揃えている

Real-Time Bidding Explained• RTBの流れ

– Webサイトを訪れ、そこに広告が配信されていたとすると、以下のようなプロセスを経ていることになる

1. ユーザーがWebサイトやMobileアプリ(Publisher)を訪れる2. Publisherもしくは 3rd PartyのデータプロバイダからAd Exchangeへ

インプレッションの通知3. Ad Exchangeから⼊札リクエストをBidder(Advertiser)へ通知。通常

は100ミリ以内に⼊札価格をAd Exchangeへ返す4. 最も⾼い価格で⼊札したBidder(Advertiser)がそのインプレッション

に対する広告表⽰の権利を勝ち取る5. AdvertiserはWebサイトやMobileアプリに広告クリエイティブを配信

する

Real-Time Bidding Explained• Elastic Nature of Advertising and Ad Tech

– DailyのWebトラフィックのボリュームは以下のように時間帯によって開きが⼤きい

– RTBの⼀般的なloadは下記のような図になる• トラフィックが少ない時間帯にリソースを落としておくことで⼤きな

コスト削減になる

Real-Time Bidding Explained• Elastic Nature of Advertising and Ad Tech

– 季節要因によってもトラフィックのボリュームは⼤きく異なる• 例えばUSにおいては、12⽉のChristmas holidayシーズンや春のTax

シーズンなどはトラフィックが⼤きく伸びる• AWSであれば前述のようにピークに合わせたリソースのプロビジョニ

ングは不要

Real-Time Bidding Explained• Why Speed Matters

– Ad Exchangeは全てのBidderに対して100ミリ秒以内の⼊札リクエストの応答を求める• 1ミリ秒でも遅れれば、いくら⾼い⼊札応答を返したとしても広告が表

⽰されることはない– ⼊札で負けることは、あなたの重要な顧客層に対する広告表⽰の機会を失

うことである• 1分間に何百万もの⼊札リクエストを受け取ることになる• 全ての⼊札リクエストをさばける能⼒はBidder(Advertiser)にとって

Criticalなものである– Exchangeへのネットワーク接続を含めて、可能な限りQuickに！

Real-Time Bidding Explained• Advertising Is Global

– オンライン広告は正にグローバルなアクティビティになってきている• 多くのポテンシャルのあるオーディエンスに広告を届けたければ、

RTBプラットフォームを世界中の全てのExchangeの近くに配置する必要がある

– 地理的にExchangeから遠く離れたところでは100ms以下という制限は満たせない• RTBプラットフォームを構築するのであれば、世界中にデプロイをす

ることを考えなければならない

Real-Time Bidding Explained• The Economics of RTB

– デジタル広告ビジネスは⾮常にコンペティティブでマージンは減少傾向– 様々なテクノロジーソリューションを活⽤できるかもしれないが、安価な

配信を実現しなければ利益を確保することはできない– RTBのコスト

• トラフィックを受け、それを記録する• ⼊札ロジックの実⾏• ⼊札ロジックで使うデータリポジトリの運⽤

– RTB on AWSにおけるコスト最適化• いくつもの戦略を採⽤可能

Real-Time Bidding Explained• Components of a RTB Platform

– Bid Traffic Ingestion and Processing• どのWebサイト、広告表⽰サイズ、ユーザーのデモグラ情報といった

⼊札トラフィックを受付け、ユーザーの過去データ等と照らし合わせ、⼊札価格を計算し、広告URLとともに結果を返す。これを⾮常に短時間⾏う必要がある

– Analysis Traffic Ingestion and Processing• 解析⽤のトラフィックはAd ExchangeやPublisherからトラッキング⽤

のPixel画像を元に送られてくる。⼊札リクエストのようにtime-sensitiveなものではないが⾮常に価値のある情報であり、⼊札価格を決定するために活⽤されるべきもの。このデータを分析することはインプレッションがどれだけの価値があるか⾒積もる上でクリティカルなものである


– Low Latency Data Repository• ⼊札リクエストに対してクイックな応答をするためには、ユーザー情

報の照会/ユーザーへの広告のマッチ度/どの程度その広告がそのユーザーに⾒られたか？といったデータを低レイテンシ(10ミリ秒以下が好ましい)で取得する必要がある

• 異なるリージョンからそのユーザーがアクセスしてくるような場合は、リージョン間でレプリケーション出来る機能はクリティカルである

– Durable Data Repository for Long-Term Storage• ⼤量のデータ(過去全てのデータ)を、安価に保持するためのもの• ユーザーの⾏動を予測するためには過去データの活⽤は⽋かせない

– 例えば、12⽉のショッピング⾏動と4⽉のショッピング⾏動はことなるはずで、仮に去年の12⽉のユーザーの⾏動データを持っていれば、今年の12⽉にユーザーがどのような⾏動をするか予想しやすい

• 広告主⾃⾝が保持する1st Partyデータだけでなく、データプロバイダが提供する3rd Partyも活⽤


– Analytics Platform• 機械学習といった技術を活⽤し、特定のデモグラおよびユーザーに

とってどの程度その広告が効果的か計算する• 複数のデバイスにまたがったユーザーの⾏動をトラックして記録し、

ユーザーのプロファイルおよびオーディエンスセグメントを更新する• Long Term Durable Data Repositoryにある様々なデータを活⽤する

– 処理結果データはLow-Latency Data Storeに保持して⼊札リクエストに対してクイックに応答出来るようにする

– Campaign Management• ⼀般的にはマルチテナントなWebアプリケーションで、広告キャン

ペーンの管理および広告予算を管理する• ⼊札に関する詳細なレポートを顧客に提供する

– “on the fly”で広告キャンペーンを⼿動もしくは⾃動で調整する– その場合は調整結果をLow-Latency Data Storeへ反映させる

Real-Time Bidding Explained• RTB Platform Diagram

– ⼀般的なRTBプラットフォームにおける各コンポーネント

Real Time Bidding on AWS• Elasticity on AWS

– Amazon EC2• 数分間で起動できるサーバーインスタンス• トラフィックに応じたクイックなスケールアップ/ダウンが可能• 解析処理をバッチで稼働させることも可能

– 稼働終了後インスタンスを落とせばその間は課⾦されない• 予想不可能なスパイクにも対応可能• ⻑期間のコミットメントや巨額の初期投資は不要

Real Time Bidding on AWS• Low Latency Networking on AWS

– AWS Region• Exchangeがある場所と同じ地域にあるAWS Regionを使うことで低レ

イテンシを実現– AWS Direct Connect

• PublicなInternet回線を経由すると、jitter(イライラする)なレイテンシが起こる可能性がある

• ExchangeとあなたのVPCをDirect Connect(DX)で結ぶことによって⾼速で安定した接続を実現

– EC2 Instance type• Enhanced networking with SR-IOV(拡張ネットワーキングの有効化)

– http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/enhanced-networking.html

Real Time Bidding on AWS• AWS Global Footprint

– AWSなら世界中のリージョンにRTBプラットフォームをデプロイ可– デプロイメントサービスを利⽤できるのも⼤きなアドバンテージ

• AWS CloudFormation– https://aws.amazon.com/cloudformation/

• AWS OpsWorks– https://aws.amazon.com/opsworks/

• AWS Elastic Beanstalk– https://aws.amazon.com/elasticbeanstalk/

– もし特定のリージョンで広告キャンペーンを持つことがなくなったのであれば、すぐにシャットダウン可能• 次に利⽤する機会があれば直ぐに⽴ち上げ直すことも可能• AWSは使った分だけの従量課⾦

Real Time Bidding on AWS• The Economics of RTB on AWS

– RTB on AWSを改良していく⼀般的な⽅法• Auto Scaling機能を使ったエラスティックなスケールの実現• Spot Instancesを使ったコスト削減

– Spot Fleet APIの活⽤» http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/

spot-fleet.html– Spot Bid Advisorの活⽤

» https://aws.amazon.com/jp/ec2/spot/bid-advisor/• リザーブドインスタンスによるコスト削減• Direct Connectを使った外部との⾼速で安定したネットワーク接続• Amazon DynamoDBを使ったダイナミックなスケールの実現

Real Time Bidding on AWS• Components of an RTB Platform on AWS

– RTBプラットフォームについて理解し、そこで使われるコンポーネントがどんなものか分かったところで、どのコンポーネントにどのAWSサービスが使われていくか解説

– Bid Traffic Ingestion and Processing on AWS• ⼊札リクエストの負荷分散にElastic Load Balancing(ELB)の活⽤

– ELBはAWSによるフルマネージドなロードバランサ» 複数Availability Zoneへの振り分けを簡単に実現» ヘルスチェック機能

• Auto ScalingやAPI/CLIを使ったスケールイン/アウト– Whitepaper『Managing Your Infrastructure at Scale』に詳細

• オープンソースのBidderであるRTBkit(http://rtbkit.org/)– EC2上に簡単にローンチ可能


– Analysis Traffic Ingestion and Processing on AWS• Amazon Kinesisへの直接のデータの取り込み、もしくは、ELB+EC2

でデータを取り込みpre-processingした後にKinesis Producerを使ってKinesisへフォワード

• Kinesis Client Library(KCL)を使ったKinesisストリームからのデータの取り出し

• Kinesis⇒S3(DurableなRepository)にデータを保存• Amazon Kinesis Firehoseを活⽤すれば⼤量データのS3への保存プロ

セスを簡略化可能


– Low Latency Data Repository on AWS• AWS Managedサービスを活⽤

– Amazon DynamoDB– Amazon ElastiCache– Do-it-yourselfでEC2上にAerospike, Cassandra, Couchbaseといった

データベースを稼働させることは可能• Amazon DynamoDBは⾮常に⼤きなテーブルを少ない管理系タスクお

よび⼈的な介⼊無しに運⽤可能– DynamoDB Streamsを活⽤しリージョンをまたいだレプリケーションを

実現– トランザクション量に応じたプロビジョンスループットの上げ下げ

» クラスタ管理等は不要。容易なコスト削減» テーブル毎にスループットを設定可能


– Amazon DynamoDB• Hash KeyとRenge Keyを使ったユーザーのカテゴライズ例

– ユーザーIDをハッシュキー、ユーザーが属するセグメントをレンジキー– ユーザーが属するセグメントによって⼊札価格を調整


– Durable Data Repository for Long-Term Storage on AWS• Amazon S3

– スケーラブル、セキュア、⾼可⽤性を実現。使った分だけの従量課⾦

– Object Lifecycle Management» 例) 7年経過したオブジェクトはAmazon Glacierへ

• Amazon Elastic MapReduce– 分散データ処理基盤– S3から直接データを読み込み、Apache Sparkといったオープン

ソースのツールを使って分析可能• AWS Lambda

– S3にオブジェクトが配置されたイベントを元に、イベント・ドリブンなプロセッシングの実現

– 今までのbatch-basedなアーキテクチャからの開放


– RTB Analytics Platform on AWS• 機械学習のアプローチを取られることが多い

– Spark MLlib on EMRが使われることが多い» もちろん他のツールをEMR上で稼働させることも可能

– Amazon Machine Learning(Amazon ML)» S3にあるLong-termなデータセットを使った分析が可能

• Whitepaper『Big Data Analytics Options on AWS』• 分析のワークロードに⽤いられることが多いサービス

– Amazon Simple Workflow Service(SWF)– AWS Data Pipeline– AWS Lambda


– Campaign Management on AWS• いわゆるWell-ArchitectedなWebアプリケーション• Bid-processingと同じようにシステムになることが多いが、永続化

データの可⽤性がより問われる• Amazon RDS

– Oracle, SQL Server, Aurora, MySQL, PotgreSQL, そしてMaria DBをサポート

– インストール、パッチあて、⽇次バックアップのような保守運⽤的なタスク、そしてMulti-AZの同期レプリケーションをサポート

• Amazon CloudFront– コンテントデリバリネットワーク– セキュアに素早く、ユーザーに⼀番近いエッヂの拠点からJavaScriptや広

告画像を配信することが可能

Reference Architecture Example• AWSの各サービスを活⽤した場合の構成図

Conclusion• Real-time bidding

– 成⻑トレンドである– 効率的にインテリジェントに広告配信するには様々なコンポーネントを構

築する必要がある– AWSのサービス群はそれぞれのコンポーネントにパーフェクトにFitする

• コスト削減が可能でRTBプラットフォームの複雑さを軽減可能• AWSのグローバルインフラストラクチャの利点を享受できる

– スケーラブルなreal-timeインフラを構築する上でオペレーションを⼤幅にAWSにオフロードできる• 競合との差別化に繋がる本質的なタスクに注⼒可能！

Contributors• Steve Boltuch, solutions architect, Amazon Web Services• Chris Marshall, solutions architect, Amazon Web Services• Marco Pedroso, software engineer, A9• Erik Swensson, solutions architect manager, Amazon Web Services• Dmitri Tchikatilov, business development manager, Amazon Web Services• Vlad Vlasceanu, solutions architect, Amazon Web Services• (⽇本語要約) Eiji Shinohara, solutions architect, Amazon Web Services

Further Reading• IAB Real Time Bidding Project• Beating the Speed of Light with Your Infrastructure on AWS• Deploying an RTBkit on AWS with a CloudFormation Template

Technology

[要約] Building a Real-Time Bidding Platform on AWS #AWSAdTechJP