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をきちんと設計すれば高速なデータアクセスも可