Running in 'PRODUCTION' Reactive Systems with cloud services

@ ScalaMatsuri 2019 Unconference Day RoomD 16:00〜
https://2019.scalamatsuri.org/

クラウド（GCP）で数万QPSのbidリクエストを捌く広告配信システムをリアクティブシステムとして実装し、そして実際に稼働している話です。

スライドの内容的に、アーキテクチャの紹介とメリットの紹介に寄っています。

Transcript

1. 実践戦 クラウドで Reactive Systems 　CyberAgent アドテク本部 CA DyVE 西村政輝 2019.6.29 ScalaMatsuri2019 アンカンファレンス
2. アジェンダ 1. 自己紹介 2. DSPについて 3. 処理特性とアーキテクチャ選定
3. 自己紹介 • CyberAgent歴1年半 • 所属プロダクト： • サーバーサイドエンジニア ◦ Java/Scalaで並行・並列プログラミング ◦ クラスタミドルウェア運用 ◦ クラウドアーキテクチャ • 前職のときScalaMatsuri 2017でAkka HTTPに ついて話したこともあります
4. DSPについて
5. DSP（リターゲティング）って何？ SSP DSP Mark Bid Ad Imp Click ① ② ③ ④ ⑤ ユーザー メディアHP 広告枠 枠 枠 図右部①→⑤の流れで外部とデータをやり取り 広告主へredirect (DSPの売上) 広告主HP 商品A 　100円 　　(カート) 枠 Cookie Sync (初回のみ)
6. 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を処理している
7. DSPのプロダクトに 求められた処理特性と アーキテクチャ選定
8. DSPの要件と処理特性① コマンドに対し、処理結果を知りたいタイミングは種 類によってまちまちなので3つに分類 • オンライントランザクション ◦ 管理画面からの配信設定の変更 ※入力した設定が確実にシステムに登録されたこと をその場で担保する必要があるが、今回のような広 告配信システムでは意外と少ない。
9. DSPの要件と処理特性② • ストリーミング処理 ◦ Markデータ（ユーザー行動履歴） ◦ 各種ログのAggregationと、速報値としてのリア ルタイムダッシュボードへの反映 ◦ 予算ペーシング ◦ Frequency Control ◦ メディアの広告枠の品質評価 ※この辺りは実用上、準リアルタイムだったり結果整 合性が担保されていれば機能要件を満たす。
10. DSPの処理特性について③ • バッチ処理でいいもの ◦ 配信結果のレポート集計(hourly) ◦ CTR予測(daily) ◦ CVR予測(daily) ◦ レコメンド用の類似アイテム選定(daily) ※知りたいデータの性質上、ログができてすぐには 結果が不要なもの。一定期間内のログを集計あるい は機械学習し、プロダクトの運用に役立てる。
11. リアクティブシステムとは イベント駆動を主体にすることで、スケーラビリティティと障害耐 性を兼ね揃えたシステム 出展：https://www.reactivemanifesto.org/ja
12. テクノロジースタック（実装面） 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の良いバランスを目指している
13. 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
14. アプリケーション パイプライン キューイング ストレージ コンポーネント図（配信サーバー部分） Cloud Storage Cloud Dataflow Kubernetes Engene Cloud Pub/Sub Bid Mark Ad Imp Click リアルタイムストリーミング処理 集計バッチ向けログアグリゲーション CQRSでいうコマンドがEvent SourceとしてPub/Subに蓄積される。 比較的すぐクエリするデータはStreamingでETLする。 Cloud Spanner ユーザーデータ参照
15. リアルタイムストリーミング処理 下記データは基本的に数十秒以内で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ロジック で利用
16. 集計基盤 広告運用基盤 コンポーネント図（集計・運用部分） Cloud SQL Cloud Spanner Cloud Storage BigQuery Compute Engene GCS側に蓄積したコマンドを集計し、レポート・ CTR/CVRなどの予測値・レコメンドアイテムをとる Kubernetes Engene (Adminアプリ) ログ データ参照(Bidサーバー) Cloud Dataflow （バッチモード）
17. クラウドでリアクティブシステムをとるメリット • スケールイン・アウトが容易 ◦ 調達速度が早い ◦ 従量課金なので、使った分だけ課金 ◦ システム障害でなどで壊れても自律復旧 • メッセージング部分がバルクヘッドになる ◦ 裏側のパイプライン以降でシステム障害が発 生してもアプリケーションサーバー側に影響し ない、ログ欠損も殆どしない。 ◦ データの鮮度を表すWatermarkが蓄積されて いくが、障害から復旧したら追いつく
18. ご清聴 ありがとう ございました！