Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Ameba広告の配信制御を刷新した話
Search
ykoma
April 18, 2023
Technology
0
230
Ameba広告の配信制御を刷新した話
ykoma
April 18, 2023
Tweet
Share
More Decks by ykoma
See All by ykoma
ネット被害に遭わないための IDパスワード管理 / Manage IDs and passwords to avoid internet fraud
euno7
0
220
EKSクラスタをいい感じに作ろうとしたら令和になった話(前編) / We tried to build EKS cluster nicely
euno7
6
1.3k
SIerとインターネット企業のエンジニアの仕事 / Comparing work of engineer between SIer and Internet company
euno7
0
490
奥深きキャッシュの世界 / The world of profound cache
euno7
4
990
Other Decks in Technology
See All in Technology
Machine Intelligence for Vision, Language, and Actions
keio_smilab
PRO
0
430
君だけのオリジナル async / await を作ろう / TSKaigi 2025
susisu
17
13k
グループ ポリシー再確認 ③
murachiakira
0
150
Eight Engineering Unit 紹介資料
sansan33
PRO
0
3.1k
Introduction to Bill One Development Engineer
sansan33
PRO
0
230
GitHub Coding Agent 概要
kkamegawa
1
1.2k
AIのための オンボーディングドキュメントを整備する - hirotea
hirotea
9
2.2k
RDRA3.0を知ろう
kanzaki
2
400
AIに実況させる / AI Streamer
motemen
3
1.4k
2025advance01
minamizaki
0
120
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
17k
Bill One 開発エンジニア 紹介資料
sansan33
PRO
4
12k
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
How GitHub (no longer) Works
holman
314
140k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The Invisible Side of Design
smashingmag
299
50k
Rails Girls Zürich Keynote
gr2m
94
13k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
12k
Building Better People: How to give real-time feedback that sticks.
wjessup
368
19k
Making Projects Easy
brettharned
116
6.2k
Making the Leap to Tech Lead
cromwellryan
133
9.3k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
180
53k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Transcript
Ameba広告の配信制御 アーキテクチャを 刷新した話 オレシカナイト vol.3 2017-09-27
About me
About me • 駒原 雄祐 (こまはら ゆうすけ) • (株)サイバーエージェント (2010~)
MDH アドテクノロジー局所属 • サーバサイドエンジニア • Ameba Infeed開発責任者(2015~)
About me • SIer出身 • サイバーエージェント入社後 • 課金プラットフォーム • コミュニティサービス
• 2012年からAmebaの広告のお仕事 • 妻と娘(1歳)とチワワ(3歳)の3人と1匹暮らし
今日のテーマ
Ameba広告の配信制御 アーキテクチャを刷新 した話
配信制御?
ネット広告配信の流れ
None
ここに相当
作成しているデータ1 • 静的なデータ(マスタデータなど) • 広告枠などの配信面の情報 • どのフォーマットの広告を何個返すか • 配信したくないNG業種や広告主 •
出稿側の情報 • 広告主、広告キャンペーン、配信先プレースメント、入札情報など • 広告のクリエイティブ情報(画像、テキスト、動画など) etc…
作成しているデータ2 • 動的なデータ • 広告枠ごとに対する配信候補のインデック スなど (様々な条件で時々刻々と変わる)
当初のアーキテクチャ
None
ִؒ ॳ Ͱ ઃఆ%#ͷ༗ޮͳσʔλͷ શྔநग़ ৴ʹదͨ͠ܗͷՃ Ωϟογϡαʔόͷ 165
όοναʔό͕࡞ͨ͠ ΩϟογϡσʔλΛ ੈผʹอ࣋
ఆظతʹ࠷৽ੈͷϙʔϦϯά ੈ͕ߋ৽͞ΕͨΒ Ωϟογϡαʔόͷ σʔλΛٵ্͍͛ ΦϯϝϞϦͰอ࣋
良いところ • シンプルな構成でランニングコストが低い • オンメモリで必要な全データをキャッシュするため低レイテンシ • RDBと配信が切り離されているため、RDBがボトルネックになる 心配がない • RDB側のスキーマ変更等による配信への影響もない
• キャッシュ作成時に問題が起きても、次の世代の処理が成功すれば 大丈夫、という安心感
ちなみに この仕組みについて2016年に弊社公式エンジニ アブログで執筆したのでそちらもぜひご一読を https://ameblo.jp/principia-ca/entry-12145898865.html ࣌ʮ"+"ʯͱ͍͏ ϒϥϯυ໊Ͱͬͯ·͠ ͕ͨɺ͍Ζ͍Ζ͋ͬͯݱ ࡏʮ"NFCB*OGFFEʯ ͱ͍͏໊લͰͬͯ·͢
運用を続けるうちに 課題が顕在化
データ量の増加
Ϗδωε֦େʹͬͯ σʔλྔ͕૿େ
ॲཧ͕࣌ؒ͘ͳΓ ִؒͷόον͕ ͰऴΘΒͳ͘ͳΔ ୯ҰαʔόͷͨΊ εέʔϧͰ͖ͳ͍
σʔλྔ૿େʹΑΓ ༰ྔΛṧഭ εέʔϧΞοϓͰ͙྇ ʑ
σʔλྔ૿େʹΑΓ ϝϞϦṧഭͰ($ίετ૿େ ٵ্͍͛ʹ͕࣌ؒ ͔͔ΔΑ͏ʹ
結果
当初3分間隔だったバッチ ↓ 10分間隔に
バッチ間隔が延びると・・・ • 配信設定の追加/変更や、ON/OFFなどが なかなか配信に反映されない • 予算切れになってもなかなか配信が止ま らない
アーキテクチャレベルで 刷新することを決断
アーキテクチャレベルで 刷新することを決断 ͜ͷ࣌Ͱ͜Μͳʹେมͩ ͱߟ͍͑ͯͳ͔ͬͨɾɾɾ
刷新の方針(状態目標) • DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない •
ただしレイテンシの悪化は許容範囲内に抑える
それを踏まえた実装方針1 • 配信設定のデータソースはRDBのまま • データソースまで変えると改修範囲がシステム のほぼ全域に及んでしまう • オンラインでの既存データの移行が現実的でな い •
配信時にRDBを直接参照しない点は踏襲
それを踏まえた実装方針2 • 世代ごとに毎回全量を作成する方式をやめる • 静的なデータは随時差分更新に (時間あたりの更新対象は少ない) • 動的なデータは一定間隔で全量更新 (時間あたりの更新対象は多い) •
アドサーバがキャッシュサーバを直接参照する方式から 、APIで配信データを提供する方式に
刷新版アーキテクチャ (ver.1)
None
3%#͜Ε·ͰΑΓ ߴ͍ฒྻͷΫΤϦΛࡹͨ͘Ίɺ 3FBE3FQMJDBΛཱͯͯ )"1SPYZ &-#Ͱෛՙࢄ ۤ͜͜ͷࡦɾɾɾ
Ωϟογϡαʔόʹ ৴੍ޚʹඞཁͳ੩తσʔλɺ ಈతσʔλ͕֨ೲ͞ΕΔ ͜͜ʹσʔλ͕ೖΔ͜ͱ͕ ͻͱ·ͣͷΰʔϧ
৴੍ޚ"1*͕Ξυαʔό ͔ΒͷϦΫΤετʹର͠ ΩϟογϡαʔόΛࢀরͯ͠ ϨεϙϯεΛฦ͢
δϣϒεέδϡʔϥ͕ ΩϟογϡʹࡌͤΔ σʔλͷछྨͱநग़݅ ྫ͑࠷ऴߋ৽͕Ҏͷ Ωϟϯϖʔϯͱ͔ Λύϥϝʔλʹ"1*ίʔϧ
*%1BSUJUJPOFS "1*͕ࢦఆ͞Εͨ݅Ͱ %#ʹର͠ߋ৽ରͷσʔλͷ*%Λ औಘ͢ΔͨΊʹ4&-&$5ɻ औಘͨ͠*%͝ͱʹϝοηʔδΛ ࡞͠,JOFTJTʹྲྀ͢
4ZODISPOJ[FS8PSLFS͕ ,JOFTJT͔ΒϝοηʔδΛ औΓग़ͯ֘͠*%ʹର͢Δ ΩϟογϡσʔλΛ࡞ɻ Ωϟογϡαʔόʹ165
ポイント • 更新対象のデータ種別、条件を指定できるようにし、差分 更新を可能に • 現在の設定では最終更新から5分以内の条件で毎分起動 (エラー時のリトライも兼ねて) • IDの抽出と、それに対するキャッシュデータ生成とを分離 し、Kinesis
Streamで非同期化することで並列化しやすく した
Kinesis Stream • AWSのフルマネージドなデータストリーミングサービス • 複数のConsumerアプリケーションに出力できる • シャード数を調整することで、スループットに応じたス ケーリングが設定できる •
KCLというConsumer用のクライアントライブラリが提 供されている
結果
None
ボツ
問題点1 • 並列度を上げた結果、RDBのレイヤーでRead Replica + HAProxyでもスループットが上がら ず、性能要件を満たせない • ある程度以上更新データが混み合うと急激 にスローダウンする
問題点2 • Kinesis Stream(KCL?)の特性上、シャードと クライアントとが1:1に紐づいてしまう • 特定のクライアントノードでスローダウンが 発生したときに他のノードで補い合えない • 遅いクライアントが掴んでいるシャードに入
ったメッセージがどんどん遅れてしまう
問題点2 - 図解
問題点2 - 図解
問題点2 - 図解 4IBSEʹೖͬͨϝοηʔδ͚ͩ ͲΜͲΜө͕Ε͍ͯ͘
刷新後アーキテクチャ (ver.2)
None
None
RDBをMySQLから Amazon Auroraに • AuroraはAWSが提供するMySQL互換のハイ パフォーマンス、高可用なDBエンジン • 元のMySQLと比較して、同じ構成でのスルー プットが大きく改善して一気に解決 •
アプリケーションには(既存のものも含めて) 一切手を入れなくてもよかった (素晴らしい)
RDBをMySQLから Amazon Auroraに • AWSが提供するMySQL互換のハイパフォー マンス、高可用なDBエンジン • 元のMySQLと比較して、同じ構成でのスルー プットが大きく改善して一気に解決 •
アプリケーションには(既存のものも含めて) 一切手を入れなくてもよかった (素晴らしい) 3%4Ͱͷ.Z42-ˠ "VSPSBҠߦΓ·ͨ͠ ɻ ڵຯ͋Δํ࠙ձͰ ͔ͭ·͍͑ͯͩ͘͞
非同期化部分をKinesis Stream からSQSに • SQSはAWSが提供するフルマネージド なメッセージキューイングサービス • リソースの空いているコンシューマア プリケーションがSQSにメッセージを 取りに行くため、特定のデータが遅延
していくという心配がなく、均一に
結果
None
ボツ 惜しい
問題点 • 静的なデータの更新量が多い状況下では Synchronizer Workerが混み合い、更新対象の 多い動的なデータの定期的な更新が追いつか ない • それでも更新要求は一定間隔で送り続けるた め、ジョブがどんどん溜まってしまう
刷新後アーキテクチャ (ver.3)
None
None
ver.2からの変更点 • Synchronizer Workerの後ろにさらにもう一段SQSと Worker(Indexer)を設け、動的なデータ(定期的に全量を洗い直すデ ータ)はそちらに流すようにした • Indexerは広告枠が生きている限り、インデックスデータを作成し たらまたIndexer用SQSにキューイングし、ループすることで繰り 返し処理を行う
• Indexer用のSQSには30秒の遅延キューの設定を入れた (30秒+αの時間間隔で動的データが更新される)
解決! • SQSの遅延キューの仕組みを利用し、動的デ ータが静的データの影響を受けずに一定間隔 (30秒+α)でデータがリフレッシュされる仕組 みが実現できた
None
結果
無事リリース
配信制御のリプレース 無事完了
目的は達成できたのか • DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない •
ただしレイテンシの悪化は許容範囲内に抑える
• DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない • ただしレイテンシの悪化は許容範囲内に抑える
目的は達成できたのか σʔλͷߋ৽ྔʹΑΓ্Լ͢Δ͕ ֓ͶҎͰө
• DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない • ただしレイテンシの悪化は許容範囲内に抑える
目的は達成できたのか %#ɺΩϟογϡͱΑΓɺ֤Ϟ δϡʔϧ͕ࢄฒྻॲཧͰ͖ΔΑ ͏ʹͳͬͨͨΊɺεέʔϧΞτ ʹΑΔεέʔϦϯά͕Մೳʹ
目的は達成できたのか • DBでのデータ更新から配信への反映は当初と同じ3 分以内を目標 • スケールしないポイントを作らない • 全データアドサーバ上でのオンメモリにはこだわら ない •
ただしレイテンシの悪化は許容範囲内に抑える ฏۉϨΠςϯγ NTˠNT ͳΜͱ͔ڐ༰ൣғͱࢥ͑Δൣғʹ ͑Δ͜ͱ͕Ͱ͖ͨ
リリース後
2017年8月に完全移行 • 配信制御API • ピーク時70000qps程度 • レイテンシ3~4ms前後 • 配信への反映 •
概ね2分以内を維持
今後の課題 • 配信制御APIのレスポンスをもう少し速くしたい • 1回の配信で何度も叩かれるAPIなので、1msの改善が全体では大 きくレイテンシの改善につながる • DSP(=Demand Side Platform)などレイテンシ要件が厳しいもの
にも不安なく使えるようにしたい • インフラコストの削減 • システムが複雑化した分、インフラコストは膨らんでしまった
ご清聴ありがとうございました