[要約] 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_Bi
dding_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アプリに広告クリエイティブを配信
する

• Elastic Nature of Advertising and Ad Tech
– DailyのWebトラフィックのボリュームは以下のように時間帯によって開き
が⼤きい
– RTBの⼀般的なloadは下記のような図になる
• トラフィックが少ない時間帯にリソースを落としておくことで⼤きな
コスト削減になる

• Elastic Nature of Advertising and Ad Tech
– 季節要因によってもトラフィックのボリュームは⼤きく異なる
• 例えばUSにおいては、12⽉のChristmas holidayシーズンや春のTax
シーズンなどはトラフィックが⼤きく伸びる
• AWSであれば前述のようにピークに合わせたリソースのプロビジョニ
ングは不要

• Why Speed Matters
– Ad Exchangeは全てのBidderに対して100ミリ秒以内の⼊札リクエストの
応答を求める
• 1ミリ秒でも遅れれば、いくら⾼い⼊札応答を返したとしても広告が表
⽰されることはない
– ⼊札で負けることは、あなたの重要な顧客層に対する広告表⽰の機会を失
うことである
• 1分間に何百万もの⼊札リクエストを受け取ることになる
• 全ての⼊札リクエストをさばける能⼒はBidder(Advertiser)にとって
Criticalなものである
– Exchangeへのネットワーク接続を含めて、可能な限りQuickに！

• Advertising Is Global
– オンライン広告は正にグローバルなアクティビティになってきている
• 多くのポテンシャルのあるオーディエンスに広告を届けたければ、
RTBプラットフォームを世界中の全てのExchangeの近くに配置する必
要がある
– 地理的にExchangeから遠く離れたところでは100ms以下という制限は満
たせない
• RTBプラットフォームを構築するのであれば、世界中にデプロイをす
ることを考えなければならない

• The Economics of RTB
– デジタル広告ビジネスは⾮常にコンペティティブでマージンは減少傾向
– 様々なテクノロジーソリューションを活⽤できるかもしれないが、安価な
配信を実現しなければ利益を確保することはできない
– RTBのコスト
• トラフィックを受け、それを記録する
• ⼊札ロジックの実⾏
• ⼊札ロジックで使うデータリポジトリの運⽤
– RTB on AWSにおけるコスト最適化
• いくつもの戦略を採⽤可能

• 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へ反映させる

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

Real Time Bidding on AWS
• Elasticity on AWS
– Amazon EC2
• 数分間で起動できるサーバーインスタンス
• トラフィックに応じたクイックなスケールアップ/ダウンが可能
• 解析処理をバッチで稼働させることも可能
– 稼働終了後インスタンスを落とせばその間は課⾦されない
• 予想不可能なスパイクにも対応可能
• ⻑期間のコミットメントや巨額の初期投資は不要

• 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/enh
anced-networking.html

• 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は使った分だけの従量課⾦

• 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を使ったダイナミックなスケールの実現

• 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

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

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (12)

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

Similar to [要約] Building a Real-Time Bidding Platform on AWS #AWSAdTechJP (20)

More from Eiji Shinohara

More from Eiji Shinohara (20)

Recently uploaded

Recently uploaded (9)

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