Ad Tech on AzureCosmos DBを利用した配信システムの全てFringe81 株式会社技術開発本部森本 真一© 2019 Fringe81 Co.,Ltd.
View Slide
広告配信について© 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 LBPublic LBCosmos DBAzure Cache for RedisAzure Database for MySQL
配信システムの可用性（Virtual Machine）© 2019 Fringe81 Co.,Ltd.● LoadBalancer配下に複数台を並べる構成● 可用性セットを利用○ 全台がメンテナンスで一斉に停止するのを防ぐ○ 本当は可用性ゾーンを利用したいが、まだ東日本リージョンでGAにならず…。● Azure Site Recoveryについては検討中○ 数種類のDB/KVSを利用しているので、それらのレプリケーション方法の検証中
© 2019 Fringe81 Co.,Ltd.広告配信システムアーキテクチャ配信システム属性情報システムInternal LBPublic LBCosmos DBAzure Cache for RedisAzure Database for MySQL属性情報の問い合わせ
属性情報システム（属性情報の管理）© 2019 Fringe81 Co.,Ltd.● 配信サーバからの属性情報の問い合わせに対して低レイテンシで返答するシステム● 属性情報は容量が大きいデータの為、プログラム内にキャッシュはしない● RocksDBを利用して、属性情報を格納し管理する○ Facebookが開発した組み込み用KVS○ 高速なストレージを効率よく利用できる
© 2019 Fringe81 Co.,Ltd.広告配信システムアーキテクチャ配信システムセグメントシステムInternal LBPublic LBCosmos DBAzure Cache for RedisAzure 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 DBCosmos 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をきちんと設計すれば高速なデータアクセスも可
shnmorimoto
palark
hokaccha
masaaki_k
sansantech
shomaekawa
oracle4engineer
koheiawa
datarian
yuhattor
keiko713
chrislema
lara
sugarenia
kastner
samanthasiow
robhawkes
colly
ddemaree
matthewcrist
mraible
aleyda
reverentgeek