Ameba広告の配信制御を刷新した話

Transcript

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. ネット広告配信の流れ
10. ここに相当
11. 作成しているデータ1 • 静的なデータ(マスタデータなど) • 広告枠などの配信面の情報 • どのフォーマットの広告を何個返すか • 配信したくないNG業種や広告主 • 出稿側の情報 • 広告主、広告キャンペーン、配信先プレースメント、入札情報など • 広告のクリエイティブ情報(画像、テキスト、動画など) etc…
12. 作成しているデータ2 • 動的なデータ • 広告枠ごとに対する配信候補のインデック スなど (様々な条件で時々刻々と変わる)
13. 当初のアーキテクチャ
15. ෼ִؒ ౰ॳ Ͱ ઃఆ%#ͷ༗ޮͳσʔλͷ શྔநग़ ഑৴ʹదͨ͠ܗ΁ͷՃ޻ Ωϟογϡαʔό΁ͷ 165
16. όοναʔό͕࡞੒ͨ͠ ΩϟογϡσʔλΛ ੈ୅ผʹอ࣋
17. ఆظతʹ࠷৽ੈ୅ͷϙʔϦϯά ੈ୅͕ߋ৽͞ΕͨΒ Ωϟογϡαʔόͷ σʔλΛٵ্͍͛ ΦϯϝϞϦͰอ࣋
18. 良いところ • シンプルな構成でランニングコストが低い • オンメモリで必要な全データをキャッシュするため低レイテンシ • RDBと配信が切り離されているため、RDBがボトルネックになる 心配がない • RDB側のスキーマ変更等による配信への影響もない • キャッシュ作成時に問題が起きても、次の世代の処理が成功すれば 大丈夫、という安心感
19. ちなみに この仕組みについて2016年に弊社公式エンジニ アブログで執筆したのでそちらもぜひご一読を https://ameblo.jp/principia-ca/entry-12145898865.html ౰࣌͸ʮ"+"ʯͱ͍͏ ϒϥϯυ໊Ͱ΍ͬͯ·͠ ͕ͨɺ͍Ζ͍Ζ͋ͬͯݱ ࡏ͸ʮ"NFCB
    *OGFFEʯ ͱ͍͏໊લͰ΍ͬͯ·͢
20. 運用を続けるうちに 課題が顕在化
21. データ量の増加
22. Ϗδωε֦େʹ൐ͬͯ σʔλྔ͕૿େ
23. ॲཧ͕࣌ؒ௕͘ͳΓ ෼ִؒͷόον͕ ෼Ͱ͸ऴΘΒͳ͘ͳΔ ୯ҰαʔόͷͨΊ εέʔϧ΋Ͱ͖ͳ͍
24. σʔλྔ૿େʹΑΓ ༰ྔΛṧഭ εέʔϧΞοϓͰ͙྇೔ ʑ
25. σʔλྔ૿େʹΑΓ ϝϞϦṧഭͰ($ίετ૿େ ٵ্͍͛ʹ΋͕࣌ؒ ͔͔ΔΑ͏ʹ
26. 結果
27. 当初3分間隔だったバッチ ↓ 10分間隔に
28. バッチ間隔が延びると・・・ • 配信設定の追加/変更や、ON/OFFなどが なかなか配信に反映されない • 予算切れになってもなかなか配信が止ま らない
29. アーキテクチャレベルで 刷新することを決断
30. アーキテクチャレベルで 刷新することを決断 ͜ͷ࣌఺Ͱ͸͜Μͳʹେมͩ ͱ͸ߟ͍͑ͯͳ͔ͬͨɾɾɾ
31. 刷新の方針(状態目標) • DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない • ただしレイテンシの悪化は許容範囲内に抑える
32. それを踏まえた実装方針1 • 配信設定のデータソースはRDBのまま • データソースまで変えると改修範囲がシステム のほぼ全域に及んでしまう • オンラインでの既存データの移行が現実的でな い • 配信時にRDBを直接参照しない点は踏襲
33. それを踏まえた実装方針2 • 世代ごとに毎回全量を作成する方式をやめる • 静的なデータは随時差分更新に (時間あたりの更新対象は少ない) • 動的なデータは一定間隔で全量更新 (時間あたりの更新対象は多い) • アドサーバがキャッシュサーバを直接参照する方式から 、APIで配信データを提供する方式に
34. 刷新版アーキテクチャ (ver.1)
36. 3%#͸͜Ε·ͰΑΓ΋ ߴ͍ฒྻ౓ͷΫΤϦΛࡹͨ͘Ίɺ 3FBE
    3FQMJDBΛཱͯͯ )"1SPYZ
    
    &-#Ͱෛՙ෼ࢄ ͜͜͸ۤ೑ͷࡦɾɾɾ
37. Ωϟογϡαʔόʹ ഑৴੍ޚʹඞཁͳ੩తσʔλɺ ಈతσʔλ͕֨ೲ͞ΕΔ ͜͜ʹσʔλ͕ೖΔ͜ͱ͕ ͻͱ·ͣͷΰʔϧ
38. ഑৴੍ޚ"1*͕Ξυαʔό ͔ΒͷϦΫΤετʹର͠ ΩϟογϡαʔόΛࢀরͯ͠ ϨεϙϯεΛฦ͢
39. δϣϒεέδϡʔϥ͕ ΩϟογϡʹࡌͤΔ σʔλͷछྨͱநग़৚݅ ྫ͑͹࠷ऴߋ৽͕෼Ҏ಺ͷ Ωϟϯϖʔϯͱ͔ Λύϥϝʔλʹ"1*ίʔϧ
40. *%
    1BSUJUJPOFS "1*͕ࢦఆ͞Εͨ৚݅Ͱ %#ʹର͠ߋ৽ର৅ͷσʔλͷ*%Λ औಘ͢ΔͨΊʹ4&-&$5ɻ औಘͨ͠*%͝ͱʹϝοηʔδΛ ࡞੒͠,JOFTJTʹྲྀ͢
41. 4ZODISPOJ[FS
    8PSLFS͕ ,JOFTJT͔ΒϝοηʔδΛ औΓग़ͯ֘͠౰*%ʹର͢Δ ΩϟογϡσʔλΛ࡞੒ɻ Ωϟογϡαʔόʹ165
42. ポイント • 更新対象のデータ種別、条件を指定できるようにし、差分 更新を可能に • 現在の設定では最終更新から5分以内の条件で毎分起動 (エラー時のリトライも兼ねて) • IDの抽出と、それに対するキャッシュデータ生成とを分離 し、Kinesis Streamで非同期化することで並列化しやすく した
43. Kinesis Stream • AWSのフルマネージドなデータストリーミングサービス • 複数のConsumerアプリケーションに出力できる • シャード数を調整することで、スループットに応じたス ケーリングが設定できる • KCLというConsumer用のクライアントライブラリが提 供されている
44. 結果
46. ボツ
47. 問題点1 • 並列度を上げた結果、RDBのレイヤーでRead Replica + HAProxyでもスループットが上がら ず、性能要件を満たせない • ある程度以上更新データが混み合うと急激 にスローダウンする
48. 問題点2 • Kinesis Stream(KCL？)の特性上、シャードと クライアントとが1:1に紐づいてしまう • 特定のクライアントノードでスローダウンが 発生したときに他のノードで補い合えない • 遅いクライアントが掴んでいるシャードに入 ったメッセージがどんどん遅れてしまう
49. 問題点2 - 図解
50. 問題点2 - 図解
51. 問題点2 - 図解 4IBSE
    ʹೖͬͨϝοηʔδ͚ͩ ͲΜͲΜ൓ө͕஗Ε͍ͯ͘
52. 刷新後アーキテクチャ (ver.2)
55. RDBをMySQLから Amazon Auroraに • AuroraはAWSが提供するMySQL互換のハイ パフォーマンス、高可用なDBエンジン • 元のMySQLと比較して、同じ構成でのスルー プットが大きく改善して一気に解決 • アプリケーションには(既存のものも含めて) 一切手を入れなくてもよかった (素晴らしい)
56. RDBをMySQLから Amazon Auroraに • AWSが提供するMySQL互換のハイパフォー マンス、高可用なDBエンジン • 元のMySQLと比較して、同じ構成でのスルー プットが大きく改善して一気に解決 • アプリケーションには(既存のものも含めて) 一切手を入れなくてもよかった (素晴らしい) 3%4Ͱͷ.Z42-
    ˠ
    "VSPSBҠߦ΋΍Γ·ͨ͠ ɻ ڵຯ͋Δํ͸࠙਌ձͰ ͔ͭ·͍͑ͯͩ͘͞
57. 非同期化部分をKinesis Stream からSQSに • SQSはAWSが提供するフルマネージド なメッセージキューイングサービス • リソースの空いているコンシューマア プリケーションがSQSにメッセージを 取りに行くため、特定のデータが遅延 していくという心配がなく、均一に
58. 結果
60. ボツ 惜しい
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 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない • ただしレイテンシの悪化は許容範囲内に抑える 目的は達成できたのか σʔλͷߋ৽ྔʹΑΓ্Լ͢Δ͕ ֓Ͷ෼Ҏ಺Ͱ൓ө
73. • DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない • ただしレイテンシの悪化は許容範囲内に抑える 目的は達成できたのか %#ɺΩϟογϡ͸΋ͱΑΓɺ֤Ϟ δϡʔϧ͕෼ࢄฒྻॲཧͰ͖ΔΑ ͏ʹͳͬͨͨΊɺεέʔϧΞ΢τ ʹΑΔεέʔϦϯά͕Մೳʹ
74. 目的は達成できたのか • DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない • ただしレイテンシの悪化は許容範囲内に抑える ฏۉϨΠςϯγ ໿NTˠ໿NT ͳΜͱ͔ڐ༰ൣғͱࢥ͑Δൣғ಺ʹ ཈͑Δ͜ͱ͕Ͱ͖ͨ
75. リリース後
76. 2017年8月に完全移行 • 配信制御API • ピーク時70000qps程度 • レイテンシ3~4ms前後 • 配信への反映 • 概ね2分以内を維持
77. 今後の課題 • 配信制御APIのレスポンスをもう少し速くしたい • 1回の配信で何度も叩かれるAPIなので、1msの改善が全体では大 きくレイテンシの改善につながる • DSP(=Demand Side Platform)などレイテンシ要件が厳しいもの にも不安なく使えるようにしたい • インフラコストの削減 • システムが複雑化した分、インフラコストは膨らんでしまった
78. ご清聴ありがとうございました