予算消化型広告配信アーキテクチャ

アドテク×アーキテクチャ オレシカナイト-オレシカナイトVol.15 での発表資料です
https://cyberagent.connpass.com/event/204170/

Transcript

1. 新ABEMA 広告配信 Architecture
2. 自己紹介 略歴 2017~ ヤフー株式会社 ・広告のデータ基盤周り 2019~ 現職 ・DMP開発 ・リニアパーソナライズド広告配信 芝崎 拓海 株式会社AbemaTV/サーバサイドエンジニア
3. アジェンダ • ABEMAについて • ABEMAの広告配信概要 • 予算消化型について • 直面した課題と解決
4. ABEMAについて
5. メディアガイドより抜粋
6. ABEMAの広告
9. メディアガイドより抜粋
10. メディアガイドより抜粋 　予約型　 　予算消化型　 純広告 配信期間とimpressionを保証 設定された予算分の広告が配 信される
11. 広告配信システム について
12. リニア広告配信基盤 ビデオ広告配信基盤 CSAI SSAI VAST VMAP 　広告配信基盤　 https://www.cyberagent.co.jp/way/feat ures/list/detail/id=24874
13. ビデオ広告配信基盤 予約型 消化型 予約型 消化型 リニア広告配信基盤 　広告配信基盤　 予算消化型 配信基盤
14. 予算消化型広告配信 アーキテクチャ
15. 予算消化型 アーキテクチャ設計方針 • (なるべく)新しめの技術を導入してみる • マイクロサービスによる関心の分離 • ある程度のレイテンシ要求(そんなに高くない) • (なるべく)キャッシュを使わない配信システム構成 • 運用の容易生
16. 採用した(新しめの)技術 Istio • サービスメッシュ • Anthos Service Meshを使用 (ASMのプラン変更に伴い切り替えた Open Policy Agent(OPA) • 管理画面の認証認可に使用 • opa-envoy-pluginを使用し sidecarコンテナとしてenvoyと一 緒にinject Argo Workflow • Workflow Engineとして使用 Argo CD • CI/CD(GitOps)に使用 Bazel • Go/DockerイメージのBuild やCIテスト時に使用 モノレポ • 各マイクロサービスやk8sの manifestファイルを１つのリポ ジトリで管理 KPT • k8sのmanifest管理
17. Istio(Anthos Service Mesh) • sidecar proxyのconfig管理をまとめてやってくれる • トラフィックミラーリング機能で本番配信前に本番リクエス トで挙動確認 • トラフィックルーティングでカナリアリリースなど • Anthos Service Mesh • 元々自前でIstioをインストールしていたが、ASMに移行し た ◦ helm → Istio-operator → ASM • mtlsが自動で有効になっている ASMで作成されるトポロジマップ (β機能
18. Istio/Traffic Mirroring bid-ingress-gateway bid-service bid-empty- service bid nginx 実際にレスポンスを広告無 し(204)として返すサーバ 同じリクエストを ミラーリング
19. Istio/Traffic Mirroring bid-ingress-gateway bid-service bid-empty- service bid nginx 実際にレスポンスを広告無 し(204)として返すサーバ 実際に広告を配信するサーバに もリクエストを流し、実際に変える 広告のレスポンスを確認
20. Istio/Traffic Routing bid-ingress-gateway bid-service bid-empty- service bid nginx トラフィックルー ティングで移行 確認 10%~ 90%~
21. Open Policy Agent • 汎用ポリシーエンジン • opa-envoy-pluginを利用 • EnvoyのExternal AuthorizationとしてOPAを統合 • 認証・認可の実装をコンポーネントに入れず、Sidecar Containerで担当 • JWTに付与したユーザーの属性を認可に使用 • 主にgRPCの通信とJTWのユーザー属性の比較を行う • regoというポリシーを記述する言語で認可のRuleを記述
22. gRPCをパースして OPAに問い合わせる Open Policy Agent front-api jwtの検証(認証 認可 gRPC web + jwt token リクエストの検証 認証認可に成功したリクエストのみfront-apiに通す ログイン jwtの発行 Policy
23. モノレポ • １つのレポジトリ下に全マイクロサービスのコンポーネ ントを管理 • CI/CD構成の共通化・ライブラリのバージョン管理の一 元化 • 大規模リファクタリングや結合テストが容易に • 複数のマイクロサービスにまたがる変更を1つのPRで 完結出来る • BazelでGo/Dockerビルドを行うことでCI時間の短縮 components以下
24. CI/CD/GitOps 　prd環境　 　stg環境　 　dev環境　 manifestの更新 バージョンの作成 自動でmanifestへ imageの更新しPR
25. 配信システム
26. 予算消化型広告配信システム概要 配信系 コンポーネント ABEMA 集計基盤 DMP 管理画面用 コンポーネント 広告運用者 DMP DB AD DB
28. 集計基盤 配信系 コンポーネ ント 管理画面用 コンポーネント DMP DMP DB AD DB
29. 配信系コンポーネントと責務 bid filter pacemaker deal • MediaからのOpenRTBのリクエストをParseし、gRPCに変換して背後の コンポーネントにリクエストする • VAST及びBidレスポンスを生成してレスポンスを返す • ターゲティング配信用にユーザーごとのOptOutの確認、フィルタリングを行う • フリークエンシーフィルターも行う • 広告予算の進捗管理を行う • 予算内に配信できる広告を返す • DBから配信できる広告を取得して返す dmp zero
30. DealInfo MediaInfo AudienceInfo bid filter pacemaker deal bid request ABEMA 広告配信フロー bid requestをgRPCに変換してfilterにリクエスト bid-ingress-gateway
31. bid filter pacemaker deal zero-fq dmp pacemaker/dmp/zeroに同時にリクエスト pacemaker: 広告の取得 zero: fqの取得 dmp: user情報の取得 ID userID DealInfo MediaInfo DealInfo MediaInfo spannerへ配信中の広告の取得 pacemakerはdealにそのままリクエスト DealInfo MediaInfo AudienceInfo ABEMA 広告配信フロー ３つのコンポーネントに並列でリクエスト
32. AdList bid filter pacemaker deal zero-fq dmp zero-ad-progre ss 広告予算進捗 キャンペーンの予算進捗を見て返す広 告を決定(ペーシングロジック CampaignID List ABEMA 広告配信フロー DBから広告を取得し、それぞれの広告進捗を取得
33. デモグラ カスタムオーディエンス エリア AdgのFQ bid filter pacemaker deal zero-fq dmp zero-campaign- progress AdList 各種フィルターを行ってレス ポンス ABEMA 広告配信フロー オーディエンスの情報ごとにフィルタリング、FQの制御
34. 集計系コンポーネントと責務 zero • リアルタイム処理基盤 • GCPではバックエンドにBigTableを利用 • User FQの作成と予算進捗の管理に使っている • ダッシュボードでもCreative・Ad・AdGroupの配信進捗を表示する用途で利用 tracking • 広告の視聴ログをAvroに変換してDataflowに入れるだけ https://developers.cyberagent.co.jp/blog/archives/11402/
35. fq ad tracking-log campaign adgroup creative zero userIDごとに historyを作成 各IDごとに カウント 1日ごとに進捗をBQ から更新 tracking filter pacemaker bid フリークエンシー・ リーセンシーの取 得 キャンペーン進捗 の取得 front-api 速報値の取得 ABEMA 生ログとして BQに入れる
36. 直面した課題と解決
37. opa-envoy-pluginがIstioで使えない問題 • 今回の認可のアーキテクチャでは、sidecar proxyがgRPCの通信をパースした上で、 OPAに問い合わせる必要があった(pack_as_bytesオプション • extauthzでgRPCをパースする処理がenvoyには入っていたが、Istio proxyには入ってい なかった(gRPCを使わなければ可能だった • → Istio proxyに取り込まれるまではFront APIではIstioを使わない方法で対応 😢
38. スケールとレイテンシの関係 • Spannerは主キーでシャーディングされたデータのかたまりに対してポイ ンタをもちクエリの処理を行う • 前提として主キーが偏るとホットスポットになり、スケールしづらくなる (auto incrementなどのkeyはNG スキーマ設計のベスト プラクティス https://cloud.google.com/spanner/docs/schema-design?hl=ja
39. スケールとレイテンシの関係 • しかし、外部キー制約で複数のシャードにまたがるクエリを実行すると複数のシャードへ のアクセスが発生するため、全体としてのパフォーマンスが悪化する • そのため、スケールとレイテンシがトレードオフの関係にある • すべて外部キー制約でテーブル設計し、複数のシャードにまたがるクエリを実行すると数 秒かかるケースがあった Ad1 Ad2 Ad3 Ad4 deal 複数のシャードからデー タを取得するとレイテン シが悪化
40. インターリーブ • インターリーブは親子関係のテーブルを物理的にまとめる方法 • 運用上ホットスポットにならない程度の粒度を考える必要がある 参考:超実践 Cloud Spanner 設計講座 https://www.slideshare.net/HammoudiSamir/cloud-spanner-78081604
41. インターリーブ • 配信時はAdGroupに紐づくDeal情報から親のAdvertiserまでの情報とAdの情報を取得 • １つのAdvertiserがどれくらいのPromotionやCampaignを作成するかを目安に無限にス ケールする必要はないと考え、ある程度の粒度でインターリーブを作成 • 目標のレイテンシになるまでテーブル・クエリ設計と負荷試験を繰り返した Advertiser Promotion Campaign AdGroup Ad A p1 c1 g1 a1 c2 g2 a2 g3 a3 B p2 c3 g4 a4
42. jsonのデコード処理 • 負荷試験用にダミーの視聴ログを送り続けていると、filter のレイテンシが悪化するようになった • リーセンシー用途に取得するUserの広告接触履歴の jsonのデコード処理が遅くなっていくことがわかった • → goのjsonデコードでReflectionを使わずeasyjsonを使う ようにし改善 fq filter フリークエンシー・ リーセンシーの取 得
43. Spanner sdkのデコード処理が重い問題 • 負荷テストを行ったところ、dealのCPU使 用率が異常に高かった • ほとんどSpannerのgo-sdk内の codec.Unmarshal処理が締めていた • レスポンスの広告の数に比例して重い • CPU使用率によってレイテンシも悪化 赤い部分がSpannerのデコード処理 deal
44. Spanner sdkのデコード処理が重い問題 • → やむなくキャッシュを実装 • fqとは異なりこちらはキャッシュが使え る • 30秒でも広告のキャッシュをdealに 持っておくだけでも相当改善 • 広告の量に依存するので、配信され る広告の量が増えたタイミングで キャッシュの保持期間を伸ばす方針 に
45. まとめ • Istioを用いたトラフィックルーティング • Open Policy Agentを用いることで認証認可を分離 • 新しい技術を採用しトラブった際はドキュメントやIssue、コードを読む • レイテンシとスケーラビリティはトレードオフの関係にある(夢のDBはない ◦ → ビジネス要件に合ったID・テーブル設計を行う • パフォーマンスはあまり予測で見積もりをたてすぎず、実際に負荷試験してみないと 分からないケースも多い ◦ 実装→負荷試験のスパンが早いと良い
46. ありがとうございました！