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
5k
Akka Cluster 超入門 - 2019 Fringe81 大新年勉強会
shnmorimoto
1
370
頑張らないKubernetes/ Real World Kubernetes
shnmorimoto
4
2k
circeから学ぶ GenericProgramming入門 - Scala関西Summit 2018
shnmorimoto
4
3.4k
Other Decks in Technology
See All in Technology
Introduction to Works of ML Engineer in LY Corporation
lycorp_recruit_jp
0
140
Taming you application's environments
salaboy
0
190
日経電子版のStoreKit2フルリニューアル
shimastripe
1
140
EventHub Startup CTO of the year 2024 ピッチ資料
eventhub
0
120
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
6
660
Flutterによる 効率的なAndroid・iOS・Webアプリケーション開発の事例
recruitengineers
PRO
0
120
オープンソースAIとは何か? --「オープンソースAIの定義 v1.0」詳細解説
shujisado
10
1.1k
いざ、BSC討伐の旅
nikinusu
2
780
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
190
OCI Vault 概要
oracle4engineer
PRO
0
9.7k
rootlessコンテナのすゝめ - 研究室サーバーでもできる安全なコンテナ管理
kitsuya0828
3
390
組織成長を加速させるオンボーディングの取り組み
sudoakiy
2
210
Featured
See All Featured
Faster Mobile Websites
deanohume
305
30k
Put a Button on it: Removing Barriers to Going Fast.
kastner
59
3.5k
Bash Introduction
62gerente
608
210k
A Tale of Four Properties
chriscoyier
156
23k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Music & Morning Musume
bryan
46
6.2k
How to Ace a Technical Interview
jacobian
276
23k
Designing Experiences People Love
moore
138
23k
Speed Design
sergeychernyshev
25
620
Unsuck your backbone
ammeep
668
57k
The Invisible Side of Design
smashingmag
298
50k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
329
21k
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をきちんと設計すれば高速なデータアクセスも可