Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Running in 'PRODUCTION' Reactive Systems with c...

Running in 'PRODUCTION' Reactive Systems with cloud services

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

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

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

Masateru Nishimura

June 29, 2019
Tweet

More Decks by Masateru Nishimura

Other Decks in Technology

Transcript

  1. 自己紹介 • CyberAgent歴1年半 • 所属プロダクト: • サーバーサイドエンジニア ◦ Java/Scalaで並行・並列プログラミング ◦

    クラスタミドルウェア運用 ◦ クラウドアーキテクチャ • 前職のときScalaMatsuri 2017でAkka HTTPに ついて話したこともあります
  2. DSP(リターゲティング)って何? SSP DSP Mark Bid Ad Imp Click ① ②

    ③ ④ ⑤ ユーザー メディアHP 広告枠 枠 枠 図右部①→⑤の流れで外部とデータをやり取り 広告主へredirect (DSPの売上) 広告主HP 商品A  100円   (カート) 枠 Cookie Sync (初回のみ)
  3. 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を処理している
  4. DSPの要件と処理特性② • ストリーミング処理 ◦ Markデータ(ユーザー行動履歴) ◦ 各種ログのAggregationと、速報値としてのリア ルタイムダッシュボードへの反映 ◦ 予算ペーシング

    ◦ Frequency Control ◦ メディアの広告枠の品質評価 ※この辺りは実用上、準リアルタイムだったり結果整 合性が担保されていれば機能要件を満たす。
  5. DSPの処理特性について③ • バッチ処理でいいもの ◦ 配信結果のレポート集計(hourly) ◦ CTR予測(daily) ◦ CVR予測(daily) ◦

    レコメンド用の類似アイテム選定(daily) ※知りたいデータの性質上、ログができてすぐには 結果が不要なもの。一定期間内のログを集計あるい は機械学習し、プロダクトの運用に役立てる。
  6. テクノロジースタック(実装面) 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の良いバランスを目指している
  7. 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
  8. アプリケーション パイプライン キューイング ストレージ コンポーネント図(配信サーバー部分) Cloud Storage Cloud Dataflow Kubernetes

    Engene Cloud Pub/Sub Bid Mark Ad Imp Click リアルタイムストリーミング処理 集計バッチ向けログアグリゲーション CQRSでいうコマンドがEvent SourceとしてPub/Subに蓄積される。 比較的すぐクエリするデータはStreamingでETLする。 Cloud Spanner ユーザーデータ参照
  9. リアルタイムストリーミング処理 下記データは基本的に数十秒以内で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ロジック で利用
  10. 集計基盤 広告運用基盤 コンポーネント図(集計・運用部分) Cloud SQL Cloud Spanner Cloud Storage BigQuery

    Compute Engene GCS側に蓄積したコマンドを集計し、レポート・ CTR/CVRなどの予測値・レコメンドアイテムをとる Kubernetes Engene (Adminアプリ) ログ データ参照(Bidサーバー) Cloud Dataflow (バッチモード)
  11. クラウドでリアクティブシステムをとるメリット • スケールイン・アウトが容易 ◦ 調達速度が早い ◦ 従量課金なので、使った分だけ課金 ◦ システム障害でなどで壊れても自律復旧 •

    メッセージング部分がバルクヘッドになる ◦ 裏側のパイプライン以降でシステム障害が発 生してもアプリケーションサーバー側に影響し ない、ログ欠損も殆どしない。 ◦ データの鮮度を表すWatermarkが蓄積されて いくが、障害から復旧したら追いつく