実践戦 クラウドで Reactive Systems 　CyberAgent アドテク本部 CA DyVE 西村政輝 2019.6.29 ScalaMatsuri2019 アンカンファレンス

アジェンダ 1. 自己紹介 2. DSPについて 3. 処理特性とアーキテクチャ選定

自己紹介 ● CyberAgent歴1年半 ● 所属プロダクト： ● サーバーサイドエンジニア ○ Java/Scalaで並行・並列プログラミング ○ クラスタミドルウェア運用 ○ クラウドアーキテクチャ ● 前職のときScalaMatsuri 2017でAkka HTTPに ついて話したこともあります

DSPについて

DSP（リターゲティング）って何？ SSP DSP Mark Bid Ad Imp Click ① ② ③ ④ ⑤ ユーザー メディアHP 広告枠 枠 枠 図右部①→⑤の流れで外部とデータをやり取り 広告主へredirect (DSPの売上) 広告主HP 商品A 　100円 　　(カート) 枠 Cookie Sync (初回のみ)

DSPの各エンドポイントの役割と今受けてる負荷 名称 役割 リクエスト数(※) Mark ・広告主サイトからのビーコンを受ける。 ・DSPとSSPのcookieのIDをマッピングする。 〜1000req/s Bid ・SSPから広告入札リクエストを受ける。 ・入札レスポンスを100ミリ秒以内でSSPに返す。 数万req/s Ad ・落札した広告枠のHTML(iframe)を生成して返す。 (内緒)req/s Imp ・落札した広告からのビーコンを受ける。 Adの10%程 Click ・落札した広告からのクリックを受ける。 ・クリックに対し広告主サイトへredirectする。 Impの0.n%程 弊プロダクトの場合、現在、ピークタイムにおいて Bidで20,000〜req/sを処理している

DSPのプロダクトに 求められた処理特性と アーキテクチャ選定

DSPの要件と処理特性① コマンドに対し、処理結果を知りたいタイミングは種 類によってまちまちなので3つに分類 ● オンライントランザクション ○ 管理画面からの配信設定の変更 ※入力した設定が確実にシステムに登録されたこと をその場で担保する必要があるが、今回のような広 告配信システムでは意外と少ない。

DSPの要件と処理特性② ● ストリーミング処理 ○ Markデータ（ユーザー行動履歴） ○ 各種ログのAggregationと、速報値としてのリア ルタイムダッシュボードへの反映 ○ 予算ペーシング ○ Frequency Control ○ メディアの広告枠の品質評価 ※この辺りは実用上、準リアルタイムだったり結果整 合性が担保されていれば機能要件を満たす。

DSPの処理特性について③ ● バッチ処理でいいもの ○ 配信結果のレポート集計(hourly) ○ CTR予測(daily) ○ CVR予測(daily) ○ レコメンド用の類似アイテム選定(daily) ※知りたいデータの性質上、ログができてすぐには 結果が不要なもの。一定期間内のログを集計あるい は機械学習し、プロダクトの運用に役立てる。

リアクティブシステムとは イベント駆動を主体にすることで、スケーラビリティティと障害耐 性を兼ね揃えたシステム 出展：https://www.reactivemanifesto.org/ja

テクノロジースタック（実装面） Cloud SQL Cloud Spanner Adapter UseCase Cloud Pub/Sub Cloud Storage Logger Repository Domain Model CTR Predictor Endpoint Scaffeine (キャッシュ) Scalike JDBC AIPredictor Serving SSP SSP SSP 言語はScala2.12。DDDとFPの良いバランスを目指している

Presentation Pipelines (for Real-time Data) Application (DSP Endpoints) Storages Ingest Batch Pipelines (for Batch) テクノロジースタック（インフラ面） Mark Kubernetes Engine Bid Kubernetes Engine Imp Kubernetes Engine Click Kubernetes Engine Cloud Pub/Sub Cloud Pub/Sub Cloud Pub/Sub Cloud Pub/Sub Ad Kubernetes Engine Log Aggregation Cloud Dataflow Retargeting Cloud Dataflow Budget Cloud Dataflow Cloud Storage Cloud Spanner Cloud SQL Digdag Compute Engine Admin Kubernetes Engine インフラはGCPを採用している Brand-safety Cloud Dataflow BigQuery Cloud Pub/Sub

アプリケーション パイプライン キューイング ストレージ コンポーネント図（配信サーバー部分） Cloud Storage Cloud Dataflow Kubernetes Engene Cloud Pub/Sub Bid Mark Ad Imp Click リアルタイムストリーミング処理 集計バッチ向けログアグリゲーション CQRSでいうコマンドがEvent SourceとしてPub/Subに蓄積される。 比較的すぐクエリするデータはStreamingでETLする。 Cloud Spanner ユーザーデータ参照

リアルタイムストリーミング処理 下記データは基本的に数十秒以内でBid時に参照できる ● Markデータ(ユーザー行動履歴) ● FrequecyControl(Imp,Click) ● 予算ペーシング Cloud Pub/Sub Cloud Dataflow Cloud Spanner Kubernetes Engene Mark 流れ Click Imp Spannerでのデータの持ち方： Bidサーバーでのレイテンシを考慮し、 Key-Value形式で1リクエストで取れるように Kryo Serializerで直列化して保持 各種ユーザー情報を ストリーミング処理 bidロジック で利用

集計基盤 広告運用基盤 コンポーネント図（集計・運用部分） Cloud SQL Cloud Spanner Cloud Storage BigQuery Compute Engene GCS側に蓄積したコマンドを集計し、レポート・ CTR/CVRなどの予測値・レコメンドアイテムをとる Kubernetes Engene (Adminアプリ) ログ データ参照(Bidサーバー) Cloud Dataflow （バッチモード）

クラウドでリアクティブシステムをとるメリット ● スケールイン・アウトが容易 ○ 調達速度が早い ○ 従量課金なので、使った分だけ課金 ○ システム障害でなどで壊れても自律復旧 ● メッセージング部分がバルクヘッドになる ○ 裏側のパイプライン以降でシステム障害が発 生してもアプリケーションサーバー側に影響し ない、ログ欠損も殆どしない。 ○ データの鮮度を表すWatermarkが蓄積されて いくが、障害から復旧したら追いつく

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