Downloaded 15 times
Uploaded byYusuke Komahara
PPTX, PDF5,753 views
Ameba広告の配信制御アーキテクチャを刷新した話 ~オレシカナイトvol.3~
オレシカナイト vol.3 の登壇資料です。さまざまな配信にまつわる設定を、実際の広告配信に反映させるための配信制御アーキテクチャを、初期ローンチ後1年半で刷新するにいたった経緯と、そこからの長い戦いの歴史を赤裸々に公開します。
Ameba広告の配信制御アーキテクチャを刷新した話 ~オレシカナイトvol.3~
- 1.
- 2.
- 3.About me• 駒原雄祐 (こまはら ゆうすけ)• (株)サイバーエージェント (2010~)MDH アドテクノロジー局所属• サーバサイドエンジニア• Ameba Infeed開発責任者(2015~)
- 4.About me• SIer出身•サイバーエージェント入社後• 課金プラットフォーム• コミュニティサービス• 2012年からAmebaの広告のお仕事• 妻と娘(1歳)とチワワ(3歳)の3人と1匹暮らし
- 5.
- 6.
- 7.
- 8.
- 11.作成しているデータ1• 静的なデータ(マスタデータなど)• 広告枠などの配信面の情報•どのフォーマットの広告を何個返すか• 配信したくないNG業種や広告主• 出稿側の情報• 広告主、広告キャンペーン、配信先プレースメント、入札情報など• 広告のクリエイティブ情報(画像、テキスト、動画など) etc…
- 12.
- 13.
- 15.
- 16.
- 17.
- 18.良いところ• シンプルな構成でランニングコストが低い• オンメモリで必要な全データをキャッシュするため低レイテンシ•RDBと配信が切り離されているため、RDBがボトルネックになる心配がない• RDB側のスキーマ変更等による配信への影響もない• キャッシュ作成時に問題が起きても、次の世代の処理が成功すれば大丈夫、という安心感
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.刷新の方針(状態目標)• DBでのデータ更新から配信への反映は当初と同じ3分以内を目標• スケールしないポイントを作らない•全データアドサーバ上でのオンメモリにはこだわらない• ただしレイテンシの悪化は許容範囲内に抑える
- 32.それを踏まえた実装方針1• 配信設定のデータソースはRDBのまま• データソースまで変えると改修範囲がシステムのほぼ全域に及んでしまう•オンラインでの既存データの移行が現実的でない• 配信時にRDBを直接参照しない点は踏襲
- 33.それを踏まえた実装方針2• 世代ごとに毎回全量を作成する方式をやめる• 静的なデータは随時差分更新に(時間あたりの更新対象は少ない)•動的なデータは一定間隔で全量更新(時間あたりの更新対象は多い)• アドサーバがキャッシュサーバを直接参照する方式から、APIで配信データを提供する方式に
- 34.
- 36.RDBはこれまでよりも高い並列度のクエリを捌くため、Read Replicaを立ててHAProxy +ELBで負荷分散(ここは苦肉の策・・・)
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.ポイント• 更新対象のデータ種別、条件を指定できるようにし、差分更新を可能に• 現在の設定では最終更新から5分以内の条件で毎分起動(エラー時のリトライも兼ねて)•IDの抽出と、それに対するキャッシュデータ生成とを分離し、Kinesis Streamで非同期化することで並列化しやすくした
- 43.Kinesis Stream• AWSのフルマネージドなデータストリーミングサービス•複数のConsumerアプリケーションに出力できる• シャード数を調整することで、スループットに応じたスケーリングが設定できる• KCLというConsumer用のクライアントライブラリが提供されている
- 44.
- 47.問題点1• 並列度を上げた結果、RDBのレイヤーでReadReplica +HAProxyでもスループットが上がらず、性能要件を満たせない• ある程度以上更新データが混み合うと急激にスローダウンする
- 48.問題点2• Kinesis Stream(KCL？)の特性上、シャードとクライアントとが1:1に紐づいてしまう•特定のクライアントノードでスローダウンが発生したときに他のノードで補い合えない• 遅いクライアントが掴んでいるシャードに入ったメッセージがどんどん遅れてしまう
- 49.
- 50.
- 51.問題点2 - 図解Shard3に入ったメッセージだけどんどん反映が遅れていく
- 52.
- 55.RDBをMySQLからAmazon Auroraに• AuroraはAWSが提供するMySQL互換のハイパフォーマンス、高可用なDBエンジン•元のMySQLと比較して、同じ構成でのスループットが大きく改善して一気に解決• アプリケーションには(既存のものも含めて)一切手を入れなくてもよかった (素晴らしい)
- 56.RDBをMySQLからAmazon Auroraに• AWSが提供するMySQL互換のハイパフォーマンス、高可用なDBエンジン•元のMySQLと比較して、同じ構成でのスループットが大きく改善して一気に解決• アプリケーションには(既存のものも含めて)一切手を入れなくてもよかった (素晴らしい)RDSでのMySQL → Aurora移行もやりました。興味ある方は懇親会でつかまえてください
- 57.非同期化部分をKinesis StreamからSQSに• SQSはAWSが提供するフルマネージドなメッセージキューイングサービス•リソースの空いているコンシューマアプリケーションがSQSにメッセージを取りに行くため、特定のデータが遅延していくという心配がなく、均一に
- 58.
- 61.問題点• 静的なデータの更新量が多い状況下ではSynchronizer Workerが混み合い、更新対象の多い動的なデータの定期的な更新が追いつかない•それでも更新要求は一定間隔で送り続けるため、ジョブがどんどん溜まってしまう
- 62.
- 65.ver.2からの変更点• Synchronizer Workerの後ろにさらにもう一段SQSとWorker(Indexer)を設け、動的なデータ(定期的に全量を洗い直すデータ)はそちらに流すようにした•Indexerは広告枠が生きている限り、インデックスデータを作成したらまたIndexer用SQSにキューイングし、ループすることで繰り返し処理を行う• Indexer用のSQSには30秒の遅延キューの設定を入れた(30秒+αの時間間隔で動的データが更新される)
- 66.
- 68.
- 69.
- 70.
- 71.目的は達成できたのか• DBでのデータ更新から配信への反映は当初と同じ3分以内を目標• スケールしないポイントを作らない•全データアドサーバ上でのオンメモリにはこだわらない• ただしレイテンシの悪化は許容範囲内に抑える
- 72.• DBでのデータ更新から配信への反映は当初と同じ3分以内を目標• スケールしないポイントを作らない•全データアドサーバ上でのオンメモリにはこだわらない• ただしレイテンシの悪化は許容範囲内に抑える目的は達成できたのかデータの更新量により上下するが概ね2分以内で反映
- 73.• DBでのデータ更新から配信への反映は当初と同じ3分以内を目標• スケールしないポイントを作らない•全データアドサーバ上でのオンメモリにはこだわらない• ただしレイテンシの悪化は許容範囲内に抑える目的は達成できたのかDB、キャッシュはもとより、各モジュールが分散並列処理できるようになったため、スケールアウトによるスケーリングが可能に
- 74.目的は達成できたのか• DBでのデータ更新から配信への反映は当初と同じ3分以内を目標• スケールしないポイントを作らない•全データアドサーバ上でのオンメモリにはこだわらない• ただしレイテンシの悪化は許容範囲内に抑える平均レイテンシ約50ms→約65msなんとか許容範囲と思える範囲内に抑えることができた
- 75.
- 76.2017年8月に完全移行• 配信制御API• ピーク時70000qps程度•レイテンシ3~4ms前後• 配信への反映• 概ね2分以内を維持
- 77.今後の課題• 配信制御APIのレスポンスをもう少し速くしたい• 1回の配信で何度も叩かれるAPIなので、1msの改善が全体では大きくレイテンシの改善につながる•DSP(=Demand Side Platform)などレイテンシ要件が厳しいものにも不安なく使えるようにしたい• インフラコストの削減• システムが複雑化した分、インフラコストは膨らんでしまった
- 78.