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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

About me

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

今日のテーマ

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

配信制御？

Slide 8

Slide 8 text

ネット広告配信の流れ

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

ここに相当

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

当初のアーキテクチャ

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

෼ִؒ ౰ॳ Ͱ ઃఆ%#ͷ༗ޮͳσʔλͷ શྔநग़ ഑৴ʹదͨ͠ܗ΁ͷՃ޻ Ωϟογϡαʔό΁ͷ 165

Slide 16

Slide 16 text

όοναʔό͕࡞੒ͨ͠ ΩϟογϡσʔλΛ ੈ୅ผʹอ࣋

Slide 17

Slide 17 text

ఆظతʹ࠷৽ੈ୅ͷϙʔϦϯά ੈ୅͕ߋ৽͞ΕͨΒ Ωϟογϡαʔόͷ σʔλΛٵ্͍͛ ΦϯϝϞϦͰอ࣋

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

ちなみにこの仕組みについて2016年に弊社公式エンジニアブログで執筆したのでそちらもぜひご一読を https://ameblo.jp/principia-ca/entry-12145898865.html ౰࣌͸ʮ"+"ʯͱ͍͏ ϒϥϯυ໊Ͱ΍ͬͯ·͠ ͕ͨɺ͍Ζ͍Ζ͋ͬͯݱ ࡏ͸ʮ"NFCB*OGFFEʯ ͱ͍͏໊લͰ΍ͬͯ·͢

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

データ量の増加

Slide 22

Slide 22 text

Ϗδωε֦େʹ൐ͬͯ σʔλྔ͕૿େ

Slide 23

Slide 23 text

ॲཧ͕࣌ؒ௕͘ͳΓ ෼ִؒͷόον͕ ෼Ͱ͸ऴΘΒͳ͘ͳΔ ୯ҰαʔόͷͨΊ εέʔϧ΋Ͱ͖ͳ͍

Slide 24

Slide 24 text

σʔλྔ૿େʹΑΓ ༰ྔΛṧഭ εέʔϧΞοϓͰ͙྇೔ ʑ

Slide 25

Slide 25 text

σʔλྔ૿େʹΑΓ ϝϞϦṧഭͰ($ίετ૿େ ٵ্͍͛ʹ΋͕࣌ؒ ͔͔ΔΑ͏ʹ

Slide 26

Slide 26 text

結果

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

アーキテクチャレベルで刷新することを決断 ͜ͷ࣌఺Ͱ͸͜Μͳʹେมͩ ͱ͸ߟ͍͑ͯͳ͔ͬͨɾɾɾ

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

3%#͸͜Ε·ͰΑΓ΋ ߴ͍ฒྻ౓ͷΫΤϦΛࡹͨ͘Ίɺ 3FBE3FQMJDBΛཱͯͯ )"1SPYZ&-#Ͱෛՙ෼ࢄ ͜͜͸ۤ೑ͷࡦɾɾɾ

Slide 37

Slide 37 text

Ωϟογϡαʔόʹ ഑৴੍ޚʹඞཁͳ੩తσʔλɺ ಈతσʔλ͕֨ೲ͞ΕΔ ͜͜ʹσʔλ͕ೖΔ͜ͱ͕ ͻͱ·ͣͷΰʔϧ

Slide 38

Slide 38 text

഑৴੍ޚ"1*͕Ξυαʔό ͔ΒͷϦΫΤετʹର͠ ΩϟογϡαʔόΛࢀরͯ͠ ϨεϙϯεΛฦ͢

Slide 39

Slide 39 text

δϣϒεέδϡʔϥ͕ ΩϟογϡʹࡌͤΔ σʔλͷछྨͱநग़৚݅ ྫ͑͹࠷ऴߋ৽͕෼Ҏ಺ͷ Ωϟϯϖʔϯͱ͔ Λύϥϝʔλʹ"1*ίʔϧ

Slide 40

Slide 40 text

*%1BSUJUJPOFS "1*͕ࢦఆ͞Εͨ৚݅Ͱ %#ʹର͠ߋ৽ର৅ͷσʔλͷ*%Λ औಘ͢ΔͨΊʹ4&-&$5ɻ औಘͨ͠*%͝ͱʹϝοηʔδΛ ࡞੒͠,JOFTJTʹྲྀ͢

Slide 41

Slide 41 text

4ZODISPOJ[FS8PSLFS͕ ,JOFTJT͔ΒϝοηʔδΛ औΓग़ͯ֘͠౰*%ʹର͢Δ ΩϟογϡσʔλΛ࡞੒ɻ Ωϟογϡαʔόʹ165

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

結果

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

ボツ

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

問題点2 - 図解

Slide 50

Slide 50 text

問題点2 - 図解

Slide 51

Slide 51 text

問題点2 - 図解 4IBSEʹೖͬͨϝοηʔδ͚ͩ ͲΜͲΜ൓ө͕஗Ε͍ͯ͘

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

RDBをMySQLから Amazon Auroraに • AuroraはAWSが提供するMySQL互換のハイパフォーマンス、高可用なDBエンジン • 元のMySQLと比較して、同じ構成でのスループットが大きく改善して一気に解決 • アプリケーションには(既存のものも含めて) 一切手を入れなくてもよかった (素晴らしい)

Slide 56

Slide 56 text

RDBをMySQLから Amazon Auroraに • AWSが提供するMySQL互換のハイパフォーマンス、高可用なDBエンジン • 元のMySQLと比較して、同じ構成でのスループットが大きく改善して一気に解決 • アプリケーションには(既存のものも含めて) 一切手を入れなくてもよかった (素晴らしい) 3%4Ͱͷ.Z42-ˠ "VSPSBҠߦ΋΍Γ·ͨ͠ ɻ ڵຯ͋Δํ͸࠙਌ձͰ ͔ͭ·͍͑ͯͩ͘͞

Slide 57

Slide 57 text

非同期化部分をKinesis Stream からSQSに • SQSはAWSが提供するフルマネージドなメッセージキューイングサービス • リソースの空いているコンシューマアプリケーションがSQSにメッセージを取りに行くため、特定のデータが遅延していくという心配がなく、均一に

Slide 58

Slide 58 text

結果

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

ボツ惜しい

Slide 61

Slide 61 text

問題点 • 静的なデータの更新量が多い状況下では Synchronizer Workerが混み合い、更新対象の多い動的なデータの定期的な更新が追いつかない • それでも更新要求は一定間隔で送り続けるため、ジョブがどんどん溜まってしまう

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

結果

Slide 69

Slide 69 text

無事リリース

Slide 70

Slide 70 text

配信制御のリプレース無事完了

Slide 71

Slide 71 text

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

Slide 72

Slide 72 text

• DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわらない • ただしレイテンシの悪化は許容範囲内に抑える目的は達成できたのか σʔλͷߋ৽ྔʹΑΓ্Լ͢Δ͕ ֓Ͷ෼Ҏ಺Ͱ൓ө

Slide 73

Slide 73 text

• DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわらない • ただしレイテンシの悪化は許容範囲内に抑える目的は達成できたのか %#ɺΩϟογϡ͸΋ͱΑΓɺ֤Ϟ δϡʔϧ͕෼ࢄฒྻॲཧͰ͖ΔΑ ͏ʹͳͬͨͨΊɺεέʔϧΞ΢τ ʹΑΔεέʔϦϯά͕Մೳʹ

Slide 74

Slide 74 text

目的は達成できたのか • DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわらない • ただしレイテンシの悪化は許容範囲内に抑える ฏۉϨΠςϯγ ໿NTˠ໿NT ͳΜͱ͔ڐ༰ൣғͱࢥ͑Δൣғ಺ʹ ཈͑Δ͜ͱ͕Ͱ͖ͨ

Slide 75

Slide 75 text

リリース後

Slide 76

Slide 76 text

2017年8月に完全移行 • 配信制御API • ピーク時70000qps程度 • レイテンシ3~4ms前後 • 配信への反映 • 概ね2分以内を維持

Slide 77

Slide 77 text

今後の課題 • 配信制御APIのレスポンスをもう少し速くしたい • 1回の配信で何度も叩かれるAPIなので、1msの改善が全体では大きくレイテンシの改善につながる • DSP(=Demand Side Platform)などレイテンシ要件が厳しいものにも不安なく使えるようにしたい • インフラコストの削減 • システムが複雑化した分、インフラコストは膨らんでしまった

Slide 78

Slide 78 text

ご清聴ありがとうございました