この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ウィスキー、シガー、パイプをこよなく愛する大栗です。
今週はアメリカ ラスベガスでre:Inventに参加しています。AWS re:Invent 2017のセッション「ATC301 - 1 Million bids in 100ms – using AWS to power your Real Time Bidder」に参加したのでレポートします。
ATC301 - 1 Million bids in 100ms – using AWS to power your Real Time Bidder
登壇者
- Erick Dame - Solutions Architect, AWS
- Ram Kumar Rengaswamy - CTO, BeeswaxIO Corporation
概要
リアルタイムビッディングアプリケーションは、非常に高いスケールとパフォーマンスを持つように設計されています。一般的なRTBのデプロイメントでは、99%のクエリで25ミリ秒のレイテンシで少なくとも100万件/秒を処理するように設計する必要があります。このセッションでは、BeeswaxによるBidder-as-a-Serviceを紹介し、AWSがコアテクノロジーをどのように実現するかを紹介します。AWS上でRTBアプリケーションのエンドツーエンドアーキテクチャの検討から始めます。次に、耐久性のある高性能システムを実装するための課題とベストプラクティスについて解説します。最後に、RTBプラットフォームを大規模に運用しながら、インフラストラクチャコストの最小化をするための推奨事項を説明します。
レポート
このセッションから何を期待するか
- AWSでのRTBの導入
- Beeswaxの紹介
- 主な考慮事項
- パフォーマンス - 取得と速度
- スケール - グローバリゼーションと地域化
- コスト - 運用とスポットマーケット
- データ - データレイク、分析、洞察
従来のRTBデータフローの外観
なぜAWSでRTBを実装するか？
- イノベーション：カッティングエッジなネットワークとコンピュート能力（Network Load Balancer、高I/Oインスタンス）
- 性能に対するコストのリーダーシップとEC2スポットマーケット
- 中国とインドを含むワールドワイドな存在感
- 低レイテンシなデータ処理とキャッシュの幅広い存在感
- パブリッシャとブランドの大きく素早く成長するエコシステム
Beeswaxについて
Beeswax Programmatic Cloud
- すぐに使えるDSPの機能
- 拡張APIを使用して構築
- パートナーの強力な統合
Beeswaxのシステムアーキテクチャ
パフォーマンス - 取得と速度
NLBを使ったRTBアプリケーションの負荷分散
- 低レイテンシ
- トラフィックスパイクに対する弾力性
- 固定のIPアドレス
Elastic Network Adapter (ENA)
- ハードウェアによるオフロードチェックサム
- ネットワークデバイスのマルチRx/Txキュー
- ハードウェアによる受信側ステアリングをサポートする
- CPU間でIRQ負荷を分散する
ネットワーク最適化 - NLB ＋ ENA
- アクティブ接続数：〜200万
- 1分あたりの新規接続：〜200万
- 帯域：120GB/分
自分でテストする - Bees with Machine Guns
負荷テストツール
https://github.com/newsapps/beeswithmachineguns
Amazon DynamoDB Accelerator (DAX)
- 主な利点
- 読み取りパフォーマンスとスケール
- 低コスト
- 機能
- フルマネージメントと高可用性
- DYnamoDB API互換
- ライトスルー
- 柔軟性 - 複数のテーブルの使用
- １０台のレプリカまでスケールアウト
- AWSサービスとの完全な統合
- セキュア
Aerospike
- 高いパフォーマンス（2ms以下の読み取りレイテンシ）のキーバリューストア
- NICごとに秒間25万パケットをハンドリングできる
- プレースメントグループ
- NVMe SSD
スケール - グローバリゼーションと地域化
Building with pods
Hive - ポッドを跨いだデプロイのやり方
- HiveはBeeswaxのシステム管理ツール
- Auto Scalie/ECSの実装を抽象化する
- リソースの作成、デプロイなどの一般的なタスクをサポートする
- Pythonで書かれており、boto3 APIの上で完全に構築されている
- IAMのアクセス制御を活用している
- CloudFormationでセットアップしてローカルとグローバルへ複製する
グローバルDNSサービスを活用する
- 地理的ルーティング
- レイテンシルーティング
- Traffic flows
セキュアなグローバルネットワークを簡単にデプロイする
- デプロイしたリージョン間で状態を同期する
- AWS SolutionのTransit VPCを基にする
コスト - 運用とスポットマーケットプレイス
複数リージョン間のトラフィックパターン
動的なインフラストラクチャのエコシステム
Auto Scaling Group
Beeswax - QPSベースのAuto Scaling
- ベストプラクティス：CPUの閾値を使ったCloudWathのアラームでスケールアップ/ダウン
- スケジュールドアクションを使って毎日日の出前にプレウォーミングする
- 事前に全てのライブラリを含んだAMIを作成しておき起動時間を最適化する
スポットインスタンスの詳細
90%コストを抑えられる
- オプション
- スポットフリーはインスタンスの可用性を維持する
- スポットブロックは動かなければいけないワークロードの間（1−6時間）持続する
- コミットレベル
- 無し
ウォーターフォールAuto Scaling Group
- スポット価格をオンデマンド価格より少なく設定する
- グループのスポットインスタンスの数でCloudWatchアラームを設定する
- スポットのグループが閾値より低下した場合にオンデマンドのグループをスケールする
Beeswax - RTBのスイートスポット
- ベストプラクティス：完全にステートレスにビッダーを作る
- ベストプラクティス：ビッダーの起動時間を最小化する
データ - データレイク、分析、洞察
データレイクとAWSサービス
なぜAmazon S3なのか？
- スケーラブル
- コスト効果が高い
- 柔軟なアクセス
Amazon S3のストレージクラスの選択
- 標準：アクテイブなデータ
- 低頻度アクセス：あまりアクセスしないデータ
- Amazon Glacier：アーカイブデータ
シナリオ
- アドデータを持っている
- データを豊かにしたい
- そのデータに対して複雑なクエリを実行したい
- デベロッパーかデータサイエンティストにデータセットを与えたいと思う
- トレンドの理解と入札の決定のアップデートが必要になる
- このデータを自分の機械学習モデルに与えられるようにするべき
分析
Beeswaxのデータフロー
トラフィックについて実行可能な洞察を得る
- Amazon Kinesisのクエリの1%のサンプル
- Amazon S3データレイクに保存する
- カスタムな終端へストリームする
- 在庫の発券を使いやすく
- ビジネスの発見をドライブする
さいごに
アドネットワークのRTBをAWSで動かす場合に注意すべきポイントが得られるセッションであったと思います。
18
