Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
Ad Tech on Azure Cosmos DBを利用した配信システムの全て Fringe81 株式会社 技術開発本部 森本 真一 © 2019 Fringe81 Co.,Ltd.
Slide 2
Slide 2 text
広告配信について © 2019 Fringe81 Co.,Ltd. スマホ 広告配信システム ① 広告をリクエスト 〜な方が訪問されたので、広告をく ださい。 ②広告情報を返却 その方に最適な広告はこれです。 ③広告を表示 -------------------- -------------------- -------------------- --------------------
Slide 3
Slide 3 text
広告配信で重要なこと © 2019 Fringe81 Co.,Ltd. ● 広告配信システムは可用性が高くなくてはならない ○ 広告はメディアにとって収益源の一つ ○ もし広告配信システムが落ちた場合、落ちている間、収益は0 ● 広告配信システムはレスポンスが早くなければならない ○ レスポンスが返るまで、広告枠(広告が表示される場所)は真っ白なまま ○ レスポンスが遅い場合、メディアのUXを著しく損なう
Slide 4
Slide 4 text
広告配信で重要なこと © 2019 Fringe81 Co.,Ltd. ● 広告配信システムは可用性が高くなくてはならない ○ 広告はメディアにとって収益源の一つ ○ もし広告配信システムが落ちた場合、落ちている間、収益は0 ● 広告配信システムはレスポンスが早くなければならない ○ レスポンスが返るまで、広告枠(広告が表示される場所)は真っ白なまま ○ レスポンスが遅い場合、メディアのUXを著しく損なう 落ちると、非常にまずい 高可用性 レスポンスが速くなくてはならない(数十ms) 低レイテンシ
Slide 5
Slide 5 text
広告配信について(再) © 2019 Fringe81 Co.,Ltd. スマホ 広告配信システム ① 広告をリクエスト 〜な方が訪問されたので、広告をく ださい。 ②広告情報を返却 その方に最適な広告はこれです。 ③広告を表示 -------------------- -------------------- -------------------- -------------------- より詳細に見てみる
Slide 6
Slide 6 text
広告が配信されるまで © 2019 Fringe81 Co.,Ltd. スマホ 有効な広告セット取得 (一般的にはキャッシュで持つ) 有効な広告をフィルタリング - 広告枠にマッチするか - デバイスはマッチするか( iOS/Android) - etc... ユーザー属性情報でフィルタリング リアルタイムな情報でフィルタリング - 広告の予算 - Frequency(同じ広告を何回も表示しな い) 表示する広告を決定 ① 広告をリクエスト OS情報、広告識別子、どの広告枠 か、etc ②最適な広告情報を返却 広告主、メディア双方に最も利益を もたらす広告
Slide 7
Slide 7 text
広告が配信されるまで © 2019 Fringe81 Co.,Ltd. スマホ 有効な広告セット取得 (一般的にはキャッシュで持つ) 有効な広告をフィルタリング - 広告枠にマッチするか - デバイスはマッチするか( iOS/Android) - etc... ユーザー属性情報でフィルタリング リアルタイムな情報でフィルタリング - 広告の予算 - Frequency(同じ広告を何回も表示しな い) 表示する広告を決定 ① 広告をリクエスト OS情報、広告識別子、どの広告枠 か、etc ②最適な広告情報を返却 広告主、メディア双方に最も利益を もたらす広告 プログラム内部の処理で頑張れる部 分 速い処理 プログラム外 (別システム?DB?KVS?) への問い合わせが必要な部分 遅い処理
Slide 8
Slide 8 text
外部(他システム、DB、KVS)問い合わせ © 2019 Fringe81 Co.,Ltd. ● ユーザー属性情報問い合わせ ○ ユーザ毎に属性情報を管理している ○ 通常データ量が多い(ユーザ数 × 属性数)ため、プログラム内でキャッシュできな い ● リアルタイムな情報の問い合わせ(広告予算の消化額等) ○ 広告がクリックされる度に予算が消化される ○ 常に最新の情報を参照しないと予算を超過して、広告が表示されることがある ○ 複数のサーバで同一の情報を参照/更新しないといけない DB/KVSに問い合わせ/更新するために、時間がかかる処理になる
Slide 9
Slide 9 text
ここまでのまとめ © 2019 Fringe81 Co.,Ltd. ● 広告配信システムには高可用性が必要 ● 広告配信システムには低レイテンシが必要 ○ 広告配信の仕組み上、外部への問い合わせ/更新が必要 ○ 外部への問い合わせ/更新は時間がかかる処理
Slide 10
Slide 10 text
ここまでのまとめ © 2019 Fringe81 Co.,Ltd. ● 広告配信システムには高可用性が必要 ● 広告配信システムには低レイテンシが必要 ○ 広告配信の仕組み上、外部への問い合わせ/更新が必要 ○ 外部への問い合わせ/更新は時間がかかる処理 Azure の Managed Service を活用して 高可用性 × 低レイテンシ なシステムを構築する!!!
Slide 11
Slide 11 text
© 2019 Fringe81 Co.,Ltd. 広告配信システムアーキテクチャ 配信システム 属性情報システム Internal LB Public LB Cosmos DB Azure Cache for Redis Azure Database for MySQL
Slide 12
Slide 12 text
© 2019 Fringe81 Co.,Ltd. 広告配信システムアーキテクチャ 配信システム 属性情報システム Internal LB Public LB Cosmos DB Azure Cache for Redis Azure Database for MySQL
Slide 13
Slide 13 text
配信システムの可用性(Virtual Machine) © 2019 Fringe81 Co.,Ltd. ● LoadBalancer配下に複数台を並べる構成 ● 可用性セットを利用 ○ 全台がメンテナンスで一斉に停止するのを防ぐ ○ 本当は可用性ゾーンを利用したいが、まだ東日本リージョンでGAにならず …。 ● Azure Site Recoveryについては検討中 ○ 数種類のDB/KVSを利用しているので、それらのレプリケーション方法の 検証中
Slide 14
Slide 14 text
© 2019 Fringe81 Co.,Ltd. 広告配信システムアーキテクチャ 配信システム 属性情報システム Internal LB Public LB Cosmos DB Azure Cache for Redis Azure Database for MySQL 属性情報の問い合わせ
Slide 15
Slide 15 text
属性情報システム(属性情報の管理) © 2019 Fringe81 Co.,Ltd. ● 配信サーバからの属性情報の問い合わせに対して低レイテンシ で返答するシステム ● 属性情報は容量が大きいデータの為、プログラム内にキャッシュ はしない ● RocksDBを利用して、属性情報を格納し管理する ○ Facebookが開発した組み込み用KVS ○ 高速なストレージを効率よく利用できる
Slide 16
Slide 16 text
© 2019 Fringe81 Co.,Ltd. 広告配信システムアーキテクチャ 配信システム セグメントシステム Internal LB Public LB Cosmos DB Azure Cache for Redis Azure Database for MySQL データの問い合わせ
Slide 17
Slide 17 text
データの問い合わせ © 2019 Fringe81 Co.,Ltd. ● DB/KVSを特性に合わせて使い分ける ● 非リアルタイムなデータ(頻繁に更新されないデータ) ○ Azure Database for MySQL ■ 管理画面から更新される広告情報マスター ■ 定期的にロードし、プログラム上でキャッシュする ● リアルタイムなデータ(広告配信システム上で更新、頻繁に更新されるデータ) ○ Azure Cache for Redis ■ データが消えてもビジネスには多大な影響を与えないデータ ○ Cosmos DB ■ 広告予算の消化額等 ■ 永続化が必須となるデータ
Slide 18
Slide 18 text
データの問い合わせ © 2019 Fringe81 Co.,Ltd. ● DB/KVSを特性に合わせて使い分ける ● 非リアルタイムなデータ(頻繁に更新されないデータ) ○ Azure Database for MySQL ■ 管理画面から更新される広告情報マスター ■ 定期的にロードし、プログラム上でキャッシュする ● リアルタイムなデータ(広告配信システム上で更新、頻繁に更新されるデータ) ○ Azure Cache for Redis ■ データが消えてもビジネスには多大な影響を与えないデータ ○ Cosmos DB ■ 広告予算の消化額等 ■ 永続化が必須となるデータ 問い合わせに低レイテンシーが要求されるデータを担う
Slide 19
Slide 19 text
データの問い合わせ © 2019 Fringe81 Co.,Ltd. ● DB/KVSを特性に合わせて使い分ける ● 非リアルタイムなデータ(頻繁に更新されないデータ) ○ Azure Database for MySQL ■ 管理画面から更新される広告情報マスター ■ 定期的にロードし、プログラム上でキャッシュする ● リアルタイムなデータ(広告配信システム上で更新、頻繁に更新されるデータ) ○ Azure Cache for Redis ■ データが消えてもビジネスには多大な影響を与えないデータ ○ Cosmos DB ■ 広告予算の消化額等 ■ 永続化が必須となるデータ インメモリなので速い。データの永続化は必要なし。
Slide 20
Slide 20 text
データの問い合わせ © 2019 Fringe81 Co.,Ltd. ● DB/KVSを特性に合わせて使い分ける ● 非リアルタイムなデータ(頻繁に更新されないデータ) ○ Azure Database for MySQL ■ 管理画面から更新される広告情報マスター ■ 定期的にロードし、プログラム上でキャッシュする ● リアルタイムなデータ(広告配信システム上で更新、頻繁に更新されるデータ) ○ Azure Cache for Redis ■ データが消えてもビジネスには多大な影響を与えないデータ ○ Cosmos DB ■ 広告予算の消化額等 ■ 永続化が必須となるデータ データの永続化が必要。それでも速い…?
Slide 21
Slide 21 text
Cosmos DB © 2019 Fringe81 Co.,Ltd. ● AzureのManaged NoSQL Service ● グローバル規模にレプリケーション可能 ● 要求ユニット(RU)単位でのコスト課金 ● 高速なデータアクセス ● 選べるAPI ○ SQL, Cassandra, MongoDB, etc ● 選べる整合性 ○ 厳密、有界整合性、セッション、一貫性のあるプレフィックス、結果的
Slide 22
Slide 22 text
広告配信 - CosmosDBの利用 - © 2019 Fringe81 Co.,Ltd. 配信システム Cosmos DB Cosmos DB レプリケーション 東日本リージョン 西日本リージョン Read/Write 数msでの レスポンス
Slide 23
Slide 23 text
Cosmos DBの利用 © 2019 Fringe81 Co.,Ltd. ● 可用性を担保したい ○ グローバル規模にレプリケーション可能な為、最悪Regionが落ちてもなん とかなる ○ 現在は西日本にのみレプリケート ● 低レイテンシー ○ Readであれば、数msでデータアクセス可能 ○ アクセスするPartitionが異なる場合だと十分性能がスケールする ● 運用が楽 ○ Managed Serviceなので運用が楽 ○ 自動スケールはしないが、スケーリング(RUを増やす)はAzure のコンソー ルからできる
Slide 24
Slide 24 text
Cosmos DBのここがちょっと…。 © 2019 Fringe81 Co.,Ltd. ● Atomic Counterが欲しい…。 ○ 単純に加算のみをしたいユースケースが多い。 ○ 現状ではread -> write or ストアドプロシージャを駆使するしかない ● RUの自動スケール ○ 現状、事前にRUを見積もらなければならない ○ リクエストがスパイクした場合を考えて、現状かなりの余裕を持たせている ○ 自動スケールがあると、運用も費用面でも嬉しい…。
Slide 25
Slide 25 text
まとめ © 2019 Fringe81 Co.,Ltd. ● 広告配信システムでは 高可用性 と 低レイテンシー が重要 ● 高可用性を担保するための仕組みを利用する ○ 可用性セット、Azure Site Recovery ● 高可用性と低レイテンシーを実現する為に各種データストアを使 い分ける ○ MySQL, Redis, CosmosDBの用途にあった組み合わせ ● CosmosDBは是非利用しよう ○ グローバル規模でのレプリケーション(マルチマスターも可) ○ Partitionをきちんと設計すれば高速なデータアクセスも可