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

by shiv3

Slide 1

Slide 1 text

新ABEMA 広告配信 Architecture

Slide 2

Slide 2 text

自己紹介略歴 2017~ ヤフー株式会社・広告のデータ基盤周り 2019~ 現職・DMP開発・リニアパーソナライズド広告配信芝崎拓海株式会社AbemaTV/サーバサイドエンジニア

Slide 3

Slide 3 text

アジェンダ ● ABEMAについて ● ABEMAの広告配信概要 ● 予算消化型について ● 直面した課題と解決

Slide 4

Slide 4 text

ABEMAについて

Slide 5

Slide 5 text

メディアガイドより抜粋

Slide 6

Slide 6 text

ABEMAの広告

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

メディアガイドより抜粋

Slide 10

Slide 10 text

メディアガイドより抜粋　予約型　　予算消化型　純広告配信期間とimpressionを保証設定された予算分の広告が配信される

Slide 11

Slide 11 text

広告配信システムについて

Slide 12

Slide 12 text

リニア広告配信基盤ビデオ広告配信基盤 CSAI SSAI VAST VMAP 　広告配信基盤　 https://www.cyberagent.co.jp/way/feat ures/list/detail/id=24874

Slide 13

Slide 13 text

ビデオ広告配信基盤予約型消化型予約型消化型リニア広告配信基盤　広告配信基盤　予算消化型配信基盤

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

予算消化型アーキテクチャ設計方針 ● (なるべく)新しめの技術を導入してみる ● マイクロサービスによる関心の分離 ● ある程度のレイテンシ要求(そんなに高くない) ● (なるべく)キャッシュを使わない配信システム構成 ● 運用の容易生

Slide 16

Slide 16 text

採用した(新しめの)技術 Istio ● サービスメッシュ ● Anthos Service Meshを使用 (ASMのプラン変更に伴い切り替えた Open Policy Agent(OPA) ● 管理画面の認証認可に使用 ● opa-envoy-pluginを使用し sidecarコンテナとしてenvoyと一緒にinject Argo Workﬂow ● Workﬂow Engineとして使用 Argo CD ● CI/CD(GitOps)に使用 Bazel ● Go/DockerイメージのBuild やCIテスト時に使用モノレポ ● 各マイクロサービスやk8sの manifestファイルを１つのリポジトリで管理 KPT ● k8sのmanifest管理

Slide 17

Slide 17 text

Istio(Anthos Service Mesh) ● sidecar proxyのconﬁg管理をまとめてやってくれる ● トラフィックミラーリング機能で本番配信前に本番リクエストで挙動確認 ● トラフィックルーティングでカナリアリリースなど ● Anthos Service Mesh ● 元々自前でIstioをインストールしていたが、ASMに移行した ○ helm → Istio-operator → ASM ● mtlsが自動で有効になっている ASMで作成されるトポロジマップ (β機能

Slide 18

Slide 18 text

Istio/Traffic Mirroring bid-ingress-gateway bid-service bid-empty- service bid nginx 実際にレスポンスを広告無し(204)として返すサーバ同じリクエストをミラーリング

Slide 19

Slide 19 text

Istio/Traffic Mirroring bid-ingress-gateway bid-service bid-empty- service bid nginx 実際にレスポンスを広告無し(204)として返すサーバ実際に広告を配信するサーバにもリクエストを流し、実際に変える広告のレスポンスを確認

Slide 20

Slide 20 text

Istio/Traffic Routing bid-ingress-gateway bid-service bid-empty- service bid nginx トラフィックルーティングで移行確認 10%~ 90%~

Slide 21

Slide 21 text

Open Policy Agent ● 汎用ポリシーエンジン ● opa-envoy-pluginを利用 ● EnvoyのExternal AuthorizationとしてOPAを統合 ● 認証・認可の実装をコンポーネントに入れず、Sidecar Containerで担当 ● JWTに付与したユーザーの属性を認可に使用 ● 主にgRPCの通信とJTWのユーザー属性の比較を行う ● regoというポリシーを記述する言語で認可のRuleを記述

Slide 22

Slide 22 text

gRPCをパースして OPAに問い合わせる Open Policy Agent front-api jwtの検証(認証認可 gRPC web + jwt token リクエストの検証認証認可に成功したリクエストのみfront-apiに通すログイン jwtの発行 Policy

Slide 23

Slide 23 text

モノレポ ● １つのレポジトリ下に全マイクロサービスのコンポーネントを管理 ● CI/CD構成の共通化・ライブラリのバージョン管理の一元化 ● 大規模リファクタリングや結合テストが容易に ● 複数のマイクロサービスにまたがる変更を1つのPRで完結出来る ● BazelでGo/Dockerビルドを行うことでCI時間の短縮 components以下

Slide 24

Slide 24 text

CI/CD/GitOps 　prd環境　　stg環境　　dev環境　 manifestの更新バージョンの作成自動でmanifestへ imageの更新しPR

Slide 25

Slide 25 text

配信システム

Slide 26

Slide 26 text

予算消化型広告配信システム概要配信系コンポーネント ABEMA 集計基盤 DMP 管理画面用コンポーネント広告運用者 DMP DB AD DB

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

集計基盤配信系コンポーネント管理画面用コンポーネント DMP DMP DB AD DB

Slide 29

Slide 29 text

配信系コンポーネントと責務 bid filter pacemaker deal ● MediaからのOpenRTBのリクエストをParseし、gRPCに変換して背後のコンポーネントにリクエストする ● VAST及びBidレスポンスを生成してレスポンスを返す ● ターゲティング配信用にユーザーごとのOptOutの確認、フィルタリングを行う ● フリークエンシーフィルターも行う ● 広告予算の進捗管理を行う ● 予算内に配信できる広告を返す ● DBから配信できる広告を取得して返す dmp zero

Slide 30

Slide 30 text

DealInfo MediaInfo AudienceInfo bid filter pacemaker deal bid request ABEMA 広告配信フロー bid requestをgRPCに変換してﬁlterにリクエスト bid-ingress-gateway

Slide 31

Slide 31 text

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 広告配信フロー３つのコンポーネントに並列でリクエスト

Slide 32

Slide 32 text

AdList bid filter pacemaker deal zero-fq dmp zero-ad-progre ss 広告予算進捗キャンペーンの予算進捗を見て返す広告を決定(ペーシングロジック CampaignID List ABEMA 広告配信フロー DBから広告を取得し、それぞれの広告進捗を取得

Slide 33

Slide 33 text

デモグラカスタムオーディエンスエリア AdgのFQ bid filter pacemaker deal zero-fq dmp zero-campaign- progress AdList 各種フィルターを行ってレスポンス ABEMA 広告配信フローオーディエンスの情報ごとにフィルタリング、FQの制御

Slide 34

Slide 34 text

集計系コンポーネントと責務 zero ● リアルタイム処理基盤 ● GCPではバックエンドにBigTableを利用 ● User FQの作成と予算進捗の管理に使っている ● ダッシュボードでもCreative・Ad・AdGroupの配信進捗を表示する用途で利用 tracking ● 広告の視聴ログをAvroに変換してDataﬂowに入れるだけ https://developers.cyberagent.co.jp/blog/archives/11402/

Slide 35

Slide 35 text

fq ad tracking-log campaign adgroup creative zero userIDごとに historyを作成各IDごとにカウント 1日ごとに進捗をBQ から更新 tracking filter pacemaker bid フリークエンシー・リーセンシーの取得キャンペーン進捗の取得 front-api 速報値の取得 ABEMA 生ログとして BQに入れる

Slide 36

Slide 36 text

直面した課題と解決

Slide 37

Slide 37 text

opa-envoy-pluginがIstioで使えない問題 ● 今回の認可のアーキテクチャでは、sidecar proxyがgRPCの通信をパースした上で、 OPAに問い合わせる必要があった(pack_as_bytesオプション ● extauthzでgRPCをパースする処理がenvoyには入っていたが、Istio proxyには入っていなかった(gRPCを使わなければ可能だった ● → Istio proxyに取り込まれるまではFront APIではIstioを使わない方法で対応 😢

Slide 38

Slide 38 text

スケールとレイテンシの関係 ● Spannerは主キーでシャーディングされたデータのかたまりに対してポインタをもちクエリの処理を行う ● 前提として主キーが偏るとホットスポットになり、スケールしづらくなる (auto incrementなどのkeyはNG スキーマ設計のベストプラクティス https://cloud.google.com/spanner/docs/schema-design?hl=ja

Slide 39

Slide 39 text

スケールとレイテンシの関係 ● しかし、外部キー制約で複数のシャードにまたがるクエリを実行すると複数のシャードへのアクセスが発生するため、全体としてのパフォーマンスが悪化する ● そのため、スケールとレイテンシがトレードオフの関係にある ● すべて外部キー制約でテーブル設計し、複数のシャードにまたがるクエリを実行すると数秒かかるケースがあった Ad1 Ad2 Ad3 Ad4 deal 複数のシャードからデータを取得するとレイテンシが悪化

Slide 40

Slide 40 text

インターリーブ ● インターリーブは親子関係のテーブルを物理的にまとめる方法 ● 運用上ホットスポットにならない程度の粒度を考える必要がある参考:超実践 Cloud Spanner 設計講座 https://www.slideshare.net/HammoudiSamir/cloud-spanner-78081604

Slide 41

Slide 41 text

インターリーブ ● 配信時は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

Slide 42

Slide 42 text

jsonのデコード処理 ● 負荷試験用にダミーの視聴ログを送り続けていると、ﬁlter のレイテンシが悪化するようになった ● リーセンシー用途に取得するUserの広告接触履歴の jsonのデコード処理が遅くなっていくことがわかった ● → goのjsonデコードでReﬂectionを使わずeasyjsonを使うようにし改善 fq filter フリークエンシー・リーセンシーの取得

Slide 43

Slide 43 text

Spanner sdkのデコード処理が重い問題 ● 負荷テストを行ったところ、dealのCPU使用率が異常に高かった ● ほとんどSpannerのgo-sdk内の codec.Unmarshal処理が締めていた ● レスポンスの広告の数に比例して重い ● CPU使用率によってレイテンシも悪化赤い部分がSpannerのデコード処理 deal

Slide 44

Slide 44 text

Spanner sdkのデコード処理が重い問題 ● → やむなくキャッシュを実装 ● fqとは異なりこちらはキャッシュが使える ● 30秒でも広告のキャッシュをdealに持っておくだけでも相当改善 ● 広告の量に依存するので、配信される広告の量が増えたタイミングでキャッシュの保持期間を伸ばす方針に

Slide 45

Slide 45 text

まとめ ● Istioを用いたトラフィックルーティング ● Open Policy Agentを用いることで認証認可を分離 ● 新しい技術を採用しトラブった際はドキュメントやIssue、コードを読む ● レイテンシとスケーラビリティはトレードオフの関係にある(夢のDBはない ○ → ビジネス要件に合ったID・テーブル設計を行う ● パフォーマンスはあまり予測で見積もりをたてすぎず、実際に負荷試験してみないと分からないケースも多い ○ 実装→負荷試験のスパンが早いと良い

Slide 46

Slide 46 text

ありがとうございました！