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
210
EKSクラスタをいい感じに作ろうとしたら令和になった話(前編) / We tried to build EKS cluster nicely
euno7
6
1.3k
SIerとインターネット企業のエンジニアの仕事 / Comparing work of engineer between SIer and Internet company
euno7
0
480
奥深きキャッシュの世界 / The world of profound cache
euno7
4
970
Other Decks in Technology
See All in Technology
3/26 クラウド食堂LT #2 GenU案件を通して学んだ教訓 登壇資料
ymae
1
190
ISUCONにPHPで挑み続けてできるようになっ(てき)たこと / phperkaigi2025
blue_goheimochi
0
130
Symfony in 2025: Scaling to 0
fabpot
2
150
バクラクでのSystem Risk Records導入による変化と改善の取り組み/Changes and Improvement Initiatives Resulting from the Implementation of System Risk Records
taddy_919
0
200
React Server Componentは 何を解決し何を解決しないのか / What do React Server Components solve, and what do they not solve?
kaminashi
6
1.1k
数百台のオンプレミスのサーバーをEKSに移行した話
yukiteraoka
0
590
Cloud Native PG 使ってみて気づいたことと最新機能の紹介 - 第52回PostgreSQLアンカンファレンス
seinoyu
0
160
30代エンジニアが考える、エンジニア生存戦略~~セキュリティを添えて~~
masakiokuda
4
2k
BCMathを高速化した一部始終をC言語でガチ目に解説する / BCMath performance improvement explanation
sakitakamachi
2
1.2k
Redefine_Possible
upsider_tech
0
220
OCI見積もり入門セミナー
oracle4engineer
PRO
0
100
コード品質向上で得られる効果と実践的取り組み
ham0215
1
200
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
117
51k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
176
52k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Product Roadmaps are Hard
iamctodd
PRO
52
11k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
11
610
For a Future-Friendly Web
brad_frost
176
9.6k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
22
2.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Mobile First: as difficult as doing things right
swwweet
223
9.5k
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)などレイテンシ要件が厳しいもの
にも不安なく使えるようにしたい • インフラコストの削減 • システムが複雑化した分、インフラコストは膨らんでしまった
ご清聴ありがとうございました