オレシカナイト vol.3 の登壇資料です。 さまざまな配信にまつわる設定を、実際の広告配信に反映させるための配信制御アーキテクチャを、初期ローンチ後1年半で刷新するにいたった経緯と、そこからの長い戦いの歴史を赤裸々に公開します。

1. Ameba広告の配信制御
アーキテクチャを
刷新した話
オレシカナイト vol.3
2017-09-27

2. About me

3. About me
• 駒原 雄祐 (こまはら ゆうすけ)
• (株)サイバーエージェント (2010~)
MDH アドテクノロジー局所属
• サーバサイドエンジニア
• Ameba Infeed開発責任者(2015~)

4. About me
• SIer出身
• サイバーエージェント入社後
• 課金プラットフォーム
• コミュニティサービス
• 2012年からAmebaの広告のお仕事
• 妻と娘(1歳)とチワワ(3歳)の3人と1匹暮らし

5. 今日のテーマ

6. Ameba広告の配信制御
アーキテクチャを刷新
した話

7. 配信制御？

8. ネット広告配信の流れ

11. 作成しているデータ1
• 静的なデータ(マスタデータなど)
• 広告枠などの配信面の情報
• どのフォーマットの広告を何個返すか
• 配信したくないNG業種や広告主
• 出稿側の情報
• 広告主、広告キャンペーン、配信先プレースメント、入札情報など
• 広告のクリエイティブ情報(画像、テキスト、動画など) etc…

12. 作成しているデータ2
• 動的なデータ
• 広告枠ごとに対する配信候補のインデック
スなど
(様々な条件で時々刻々と変わる)

13. 当初のアーキテクチャ

15. 3分間隔(当初)で
設定DBの有効なデータの
全量抽出
配信に適した形への加工
キャッシュサーバへの
PUT

16. バッチサーバが作成した
キャッシュデータを
世代別に保持

17. 定期的に最新世代のポーリング
世代が更新されたら
キャッシュサーバの
データを吸い上げ
オンメモリで保持

18. 良いところ
• シンプルな構成でランニングコストが低い
• オンメモリで必要な全データをキャッシュするため低レイテンシ
• RDBと配信が切り離されているため、RDBがボトルネックになる
心配がない
• RDB側のスキーマ変更等による配信への影響もない
• キャッシュ作成時に問題が起きても、次の世代の処理が成功すれば
大丈夫、という安心感

19. ちなみに
この仕組みについて2016年に弊社公式エンジニ
アブログで執筆したのでそちらもぜひご一読を
https://ameblo.jp/principia-ca/entry-12145898865.html
当時は「A.J.A.」という
ブランド名でやってまし
たが、いろいろあって現
在は「Ameba Infeed」と
いう名前でやってます

20. 運用を続けるうちに
課題が顕在化

21. データ量の増加

22. ビジネス拡大に伴って
データ量が増大

23. 処理時間が長くなり
3分間隔のバッチが
3分では終わらなくなる
単一サーバのため
スケールもできない

24. データ量増大により
容量を逼迫
スケールアップで凌ぐ日々

25. データ量増大により
メモリ逼迫でGCコスト増大
吸い上げにも時間が
かかるように

26. 結果

27. 当初3分間隔だったバッチ
↓
10分間隔に

28. バッチ間隔が延びると・・・
• 配信設定の追加/変更や、ON/OFFなどが
なかなか配信に反映されない
• 予算切れになってもなかなか配信が止ま
らない

29. アーキテクチャレベルで
刷新することを決断

30. アーキテクチャレベルで
刷新することを決断
この時点ではこんなに大変だ
とは考えていなかった・・・

31. 刷新の方針(状態目標)
• DBでのデータ更新から配信への反映は当初と同じ3
分以内を目標
• スケールしないポイントを作らない
• 全データアドサーバ上でのオンメモリにはこだわら
ない
• ただしレイテンシの悪化は許容範囲内に抑える

32. それを踏まえた実装方針1
• 配信設定のデータソースはRDBのまま
• データソースまで変えると改修範囲がシステム
のほぼ全域に及んでしまう
• オンラインでの既存データの移行が現実的でな
い
• 配信時にRDBを直接参照しない点は踏襲

33. それを踏まえた実装方針2
• 世代ごとに毎回全量を作成する方式をやめる
• 静的なデータは随時差分更新に
(時間あたりの更新対象は少ない)
• 動的なデータは一定間隔で全量更新
(時間あたりの更新対象は多い)
• アドサーバがキャッシュサーバを直接参照する方式から
、APIで配信データを提供する方式に

34. 刷新版アーキテクチャ
(ver.1)

36. RDBはこれまでよりも
高い並列度のクエリを捌くため、
Read Replicaを立てて
HAProxy + ELBで負荷分散
(ここは苦肉の策・・・)

37. キャッシュサーバに
配信制御に必要な静的データ、
動的データが格納される
ここにデータが入ることが
ひとまずのゴール

38. 配信制御APIがアドサーバ
からのリクエストに対し
キャッシュサーバを参照して
レスポンスを返す

39. ジョブスケジューラが
キャッシュに載せる
データの種類と抽出条件
(例えば最終更新が5分以内の
キャンペーンとか)
をパラメータにAPIコール

40. ID Partitioner
APIが指定された条件で
DBに対し更新対象のデータのIDを
取得するためにSELECT。
取得したIDごとにメッセージを
作成しKinesisに流す

41. Synchronizer Workerが
Kinesisからメッセージを取
り出して該当IDに対する
キャッシュデータを作成。
キャッシュサーバにPUT

42. ポイント
• 更新対象のデータ種別、条件を指定できるようにし、差分
更新を可能に
• 現在の設定では最終更新から5分以内の条件で毎分起動
(エラー時のリトライも兼ねて)
• IDの抽出と、それに対するキャッシュデータ生成とを分離
し、Kinesis Streamで非同期化することで並列化しやすく
した

43. Kinesis Stream
• AWSのフルマネージドなデータストリーミングサービス
• 複数のConsumerアプリケーションに出力できる
• シャード数を調整することで、スループットに応じたス
ケーリングが設定できる
• KCLというConsumer用のクライアントライブラリが提
供されている

44. 結果

47. 問題点1
• 並列度を上げた結果、RDBのレイヤーでRead
Replica + HAProxyでもスループットが上がら
ず、性能要件を満たせない
• ある程度以上更新データが混み合うと急激
にスローダウンする

48. 問題点2
• Kinesis Stream(KCL？)の特性上、シャードと
クライアントとが1:1に紐づいてしまう
• 特定のクライアントノードでスローダウンが
発生したときに他のノードで補い合えない
• 遅いクライアントが掴んでいるシャードに入
ったメッセージがどんどん遅れてしまう

49. 問題点2 - 図解

50. 問題点2 - 図解

51. 問題点2 - 図解
Shard 3に入ったメッセージだけ
どんどん反映が遅れていく

52. 刷新後アーキテクチャ
(ver.2)

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. 刷新後アーキテクチャ
(ver.3)

65. ver.2からの変更点
• Synchronizer Workerの後ろにさらにもう一段SQSと
Worker(Indexer)を設け、動的なデータ(定期的に全量を洗い直すデ
ータ)はそちらに流すようにした
• Indexerは広告枠が生きている限り、インデックスデータを作成し
たらまたIndexer用SQSにキューイングし、ループすることで繰り
返し処理を行う
• Indexer用のSQSには30秒の遅延キューの設定を入れた
(30秒+αの時間間隔で動的データが更新される)

66. 解決！
• SQSの遅延キューの仕組みを利用し、動的デ
ータが静的データの影響を受けずに一定間隔
(30秒＋α)でデータがリフレッシュされる仕組
みが実現できた

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. ご清聴ありがとうございました