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
AdTech on Azure - Cosmos DBを利用した配信システムの全て -
Search
Shinichi Morimoto
February 27, 2019
Technology
2
2.5k
AdTech on Azure - Cosmos DBを利用した配信システムの全て -
Shinichi Morimoto
February 27, 2019
Tweet
Share
More Decks by Shinichi Morimoto
See All by Shinichi Morimoto
Actor Model meets the Kubernetes - CNDT 2019
shnmorimoto
6
4.9k
Akka Cluster 超入門 - 2019 Fringe81 大新年勉強会
shnmorimoto
1
360
頑張らないKubernetes/ Real World Kubernetes
shnmorimoto
4
1.9k
circeから学ぶ GenericProgramming入門 - Scala関西Summit 2018
shnmorimoto
4
3.3k
Other Decks in Technology
See All in Technology
Microsoft 365 でデータセキュリティを強化しよう
sophiakunii
2
360
AWSの初級者向けAI・ML資格『AWS Certified AI Practitioner』の傾向と対策/So You Want To Pass AWS Certified AI Practitioner
quiver
0
610
テストコードの品質を客観的な数値で担保しよう〜Mutation Testのすすめ〜
ysknsid25
12
3.7k
とある事業会社にとっての Kaggler の魅力
hakubishin3
7
1.2k
Azure App Service on Linux の Sidecar に Phi-3 を配置してインテリジェントなアプリケーションを作ってみよう/jazug-anniv14
thara0402
0
550
寒冷地稲作の歴史にみるコミュニティ
miu_crescent
2
120
テストを楽に書きたい
tomorrowkey
1
220
Webセキュリティのあるきかた
akiym
32
11k
怖くないオフライン機能開発 〜基本的な技術で実現する現場向けオフライン機能 / Developing offline functions without fear ~ Offline functions for the field realized with basic technology
kaminashi
1
120
Efficient zero-copy networking using io_uring
ennael
PRO
0
410
外部カンファレンスで登壇しよう! 〜「強い」エンジニアへの一歩を踏み出す〜
logica0419
4
110
エンジニア向け会社紹介資料
caddi_eng
14
270k
Featured
See All Featured
Keith and Marios Guide to Fast Websites
keithpitt
408
22k
Making Projects Easy
brettharned
115
5.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Bash Introduction
62gerente
608
210k
Design by the Numbers
sachag
278
19k
RailsConf 2023
tenderlove
28
850
WebSockets: Embracing the real-time Web
robhawkes
59
7.4k
BBQ
matthewcrist
85
9.2k
Scaling GitHub
holman
458
140k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
12
1.6k
Debugging Ruby Performance
tmm1
73
12k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
2
310
Transcript
Ad Tech on Azure Cosmos DBを利用した配信システムの全て Fringe81 株式会社 技術開発本部 森本 真一
© 2019 Fringe81 Co.,Ltd.
広告配信について © 2019 Fringe81 Co.,Ltd. スマホ 広告配信システム ① 広告をリクエスト 〜な方が訪問されたので、広告をく
ださい。 ②広告情報を返却 その方に最適な広告はこれです。 ③広告を表示 -------------------- -------------------- -------------------- --------------------
広告配信で重要なこと © 2019 Fringe81 Co.,Ltd. • 広告配信システムは可用性が高くなくてはならない ◦ 広告はメディアにとって収益源の一つ ◦
もし広告配信システムが落ちた場合、落ちている間、収益は0 • 広告配信システムはレスポンスが早くなければならない ◦ レスポンスが返るまで、広告枠(広告が表示される場所)は真っ白なまま ◦ レスポンスが遅い場合、メディアのUXを著しく損なう
広告配信で重要なこと © 2019 Fringe81 Co.,Ltd. • 広告配信システムは可用性が高くなくてはならない ◦ 広告はメディアにとって収益源の一つ ◦
もし広告配信システムが落ちた場合、落ちている間、収益は0 • 広告配信システムはレスポンスが早くなければならない ◦ レスポンスが返るまで、広告枠(広告が表示される場所)は真っ白なまま ◦ レスポンスが遅い場合、メディアのUXを著しく損なう 落ちると、非常にまずい 高可用性 レスポンスが速くなくてはならない(数十ms) 低レイテンシ
広告配信について(再) © 2019 Fringe81 Co.,Ltd. スマホ 広告配信システム ① 広告をリクエスト 〜な方が訪問されたので、広告をく
ださい。 ②広告情報を返却 その方に最適な広告はこれです。 ③広告を表示 -------------------- -------------------- -------------------- -------------------- より詳細に見てみる
広告が配信されるまで © 2019 Fringe81 Co.,Ltd. スマホ 有効な広告セット取得 (一般的にはキャッシュで持つ) 有効な広告をフィルタリング -
広告枠にマッチするか - デバイスはマッチするか( iOS/Android) - etc... ユーザー属性情報でフィルタリング リアルタイムな情報でフィルタリング - 広告の予算 - Frequency(同じ広告を何回も表示しな い) 表示する広告を決定 ① 広告をリクエスト OS情報、広告識別子、どの広告枠 か、etc ②最適な広告情報を返却 広告主、メディア双方に最も利益を もたらす広告
広告が配信されるまで © 2019 Fringe81 Co.,Ltd. スマホ 有効な広告セット取得 (一般的にはキャッシュで持つ) 有効な広告をフィルタリング -
広告枠にマッチするか - デバイスはマッチするか( iOS/Android) - etc... ユーザー属性情報でフィルタリング リアルタイムな情報でフィルタリング - 広告の予算 - Frequency(同じ広告を何回も表示しな い) 表示する広告を決定 ① 広告をリクエスト OS情報、広告識別子、どの広告枠 か、etc ②最適な広告情報を返却 広告主、メディア双方に最も利益を もたらす広告 プログラム内部の処理で頑張れる部 分 速い処理 プログラム外 (別システム?DB?KVS?) への問い合わせが必要な部分 遅い処理
外部(他システム、DB、KVS)問い合わせ © 2019 Fringe81 Co.,Ltd. • ユーザー属性情報問い合わせ ◦ ユーザ毎に属性情報を管理している ◦
通常データ量が多い(ユーザ数 × 属性数)ため、プログラム内でキャッシュできな い • リアルタイムな情報の問い合わせ(広告予算の消化額等) ◦ 広告がクリックされる度に予算が消化される ◦ 常に最新の情報を参照しないと予算を超過して、広告が表示されることがある ◦ 複数のサーバで同一の情報を参照/更新しないといけない DB/KVSに問い合わせ/更新するために、時間がかかる処理になる
ここまでのまとめ © 2019 Fringe81 Co.,Ltd. • 広告配信システムには高可用性が必要 • 広告配信システムには低レイテンシが必要 ◦
広告配信の仕組み上、外部への問い合わせ/更新が必要 ◦ 外部への問い合わせ/更新は時間がかかる処理
ここまでのまとめ © 2019 Fringe81 Co.,Ltd. • 広告配信システムには高可用性が必要 • 広告配信システムには低レイテンシが必要 ◦
広告配信の仕組み上、外部への問い合わせ/更新が必要 ◦ 外部への問い合わせ/更新は時間がかかる処理 Azure の Managed Service を活用して 高可用性 × 低レイテンシ なシステムを構築する!!!
© 2019 Fringe81 Co.,Ltd. 広告配信システムアーキテクチャ 配信システム 属性情報システム Internal LB Public
LB Cosmos DB Azure Cache for Redis Azure Database for MySQL
© 2019 Fringe81 Co.,Ltd. 広告配信システムアーキテクチャ 配信システム 属性情報システム Internal LB Public
LB Cosmos DB Azure Cache for Redis Azure Database for MySQL
配信システムの可用性(Virtual Machine) © 2019 Fringe81 Co.,Ltd. • LoadBalancer配下に複数台を並べる構成 • 可用性セットを利用
◦ 全台がメンテナンスで一斉に停止するのを防ぐ ◦ 本当は可用性ゾーンを利用したいが、まだ東日本リージョンでGAにならず …。 • Azure Site Recoveryについては検討中 ◦ 数種類のDB/KVSを利用しているので、それらのレプリケーション方法の 検証中
© 2019 Fringe81 Co.,Ltd. 広告配信システムアーキテクチャ 配信システム 属性情報システム Internal LB Public
LB Cosmos DB Azure Cache for Redis Azure Database for MySQL 属性情報の問い合わせ
属性情報システム(属性情報の管理) © 2019 Fringe81 Co.,Ltd. • 配信サーバからの属性情報の問い合わせに対して低レイテンシ で返答するシステム • 属性情報は容量が大きいデータの為、プログラム内にキャッシュ
はしない • RocksDBを利用して、属性情報を格納し管理する ◦ Facebookが開発した組み込み用KVS ◦ 高速なストレージを効率よく利用できる
© 2019 Fringe81 Co.,Ltd. 広告配信システムアーキテクチャ 配信システム セグメントシステム Internal LB Public
LB Cosmos DB Azure Cache for Redis Azure Database for MySQL データの問い合わせ
データの問い合わせ © 2019 Fringe81 Co.,Ltd. • DB/KVSを特性に合わせて使い分ける • 非リアルタイムなデータ(頻繁に更新されないデータ) ◦
Azure Database for MySQL ▪ 管理画面から更新される広告情報マスター ▪ 定期的にロードし、プログラム上でキャッシュする • リアルタイムなデータ(広告配信システム上で更新、頻繁に更新されるデータ) ◦ Azure Cache for Redis ▪ データが消えてもビジネスには多大な影響を与えないデータ ◦ Cosmos DB ▪ 広告予算の消化額等 ▪ 永続化が必須となるデータ
データの問い合わせ © 2019 Fringe81 Co.,Ltd. • DB/KVSを特性に合わせて使い分ける • 非リアルタイムなデータ(頻繁に更新されないデータ) ◦
Azure Database for MySQL ▪ 管理画面から更新される広告情報マスター ▪ 定期的にロードし、プログラム上でキャッシュする • リアルタイムなデータ(広告配信システム上で更新、頻繁に更新されるデータ) ◦ Azure Cache for Redis ▪ データが消えてもビジネスには多大な影響を与えないデータ ◦ Cosmos DB ▪ 広告予算の消化額等 ▪ 永続化が必須となるデータ 問い合わせに低レイテンシーが要求されるデータを担う
データの問い合わせ © 2019 Fringe81 Co.,Ltd. • DB/KVSを特性に合わせて使い分ける • 非リアルタイムなデータ(頻繁に更新されないデータ) ◦
Azure Database for MySQL ▪ 管理画面から更新される広告情報マスター ▪ 定期的にロードし、プログラム上でキャッシュする • リアルタイムなデータ(広告配信システム上で更新、頻繁に更新されるデータ) ◦ Azure Cache for Redis ▪ データが消えてもビジネスには多大な影響を与えないデータ ◦ Cosmos DB ▪ 広告予算の消化額等 ▪ 永続化が必須となるデータ インメモリなので速い。データの永続化は必要なし。
データの問い合わせ © 2019 Fringe81 Co.,Ltd. • DB/KVSを特性に合わせて使い分ける • 非リアルタイムなデータ(頻繁に更新されないデータ) ◦
Azure Database for MySQL ▪ 管理画面から更新される広告情報マスター ▪ 定期的にロードし、プログラム上でキャッシュする • リアルタイムなデータ(広告配信システム上で更新、頻繁に更新されるデータ) ◦ Azure Cache for Redis ▪ データが消えてもビジネスには多大な影響を与えないデータ ◦ Cosmos DB ▪ 広告予算の消化額等 ▪ 永続化が必須となるデータ データの永続化が必要。それでも速い…?
Cosmos DB © 2019 Fringe81 Co.,Ltd. • AzureのManaged NoSQL Service
• グローバル規模にレプリケーション可能 • 要求ユニット(RU)単位でのコスト課金 • 高速なデータアクセス • 選べるAPI ◦ SQL, Cassandra, MongoDB, etc • 選べる整合性 ◦ 厳密、有界整合性、セッション、一貫性のあるプレフィックス、結果的
広告配信 - CosmosDBの利用 - © 2019 Fringe81 Co.,Ltd. 配信システム Cosmos
DB Cosmos DB レプリケーション 東日本リージョン 西日本リージョン Read/Write 数msでの レスポンス
Cosmos DBの利用 © 2019 Fringe81 Co.,Ltd. • 可用性を担保したい ◦ グローバル規模にレプリケーション可能な為、最悪Regionが落ちてもなん
とかなる ◦ 現在は西日本にのみレプリケート • 低レイテンシー ◦ Readであれば、数msでデータアクセス可能 ◦ アクセスするPartitionが異なる場合だと十分性能がスケールする • 運用が楽 ◦ Managed Serviceなので運用が楽 ◦ 自動スケールはしないが、スケーリング(RUを増やす)はAzure のコンソー ルからできる
Cosmos DBのここがちょっと…。 © 2019 Fringe81 Co.,Ltd. • Atomic Counterが欲しい…。 ◦
単純に加算のみをしたいユースケースが多い。 ◦ 現状ではread -> write or ストアドプロシージャを駆使するしかない • RUの自動スケール ◦ 現状、事前にRUを見積もらなければならない ◦ リクエストがスパイクした場合を考えて、現状かなりの余裕を持たせている ◦ 自動スケールがあると、運用も費用面でも嬉しい…。
まとめ © 2019 Fringe81 Co.,Ltd. • 広告配信システムでは 高可用性 と 低レイテンシー
が重要 • 高可用性を担保するための仕組みを利用する ◦ 可用性セット、Azure Site Recovery • 高可用性と低レイテンシーを実現する為に各種データストアを使 い分ける ◦ MySQL, Redis, CosmosDBの用途にあった組み合わせ • CosmosDBは是非利用しよう ◦ グローバル規模でのレプリケーション(マルチマスターも可) ◦ Partitionをきちんと設計すれば高速なデータアクセスも可