How to face the load

学生団体Volareさんとの勉強会( https://volare.connpass.com/event/238578/ )で発表した資料です

Transcript

1. 大規模な広告配信の仕組み pixiv 広告のシステム例 pixiv Inc. saki 2022.03.27
2. 2 Profile • saki (@yensaki) • 経歴 ◦ - 2017: カカクコム(食べログ) ◦ 2017 -: ピクシブ ▪ 2017 - 2019: pixivFACTORY ▪ 2019 - : 広告 • 好きな技術 ◦ Ruby on Rails ◦ Kubernetes saki ピクシブ株式会社 アドプラットフォーム事業部
3. 3 発表の流れ 1. 広告の概要 2. インフラ構成 3. アプリケーション構成 4. 重要ポイント
4. 4 1.広告の概要

5. 5 ピクシブの広告規模 リクエスト数 • 月間500億件…超 ◦ 年々増えてる 広告の リクエスト種類とは • 広告取得 • rendering通知 • クリック • コンバージョンなど https://www.wantedly.com/companies/pixiv/post_articles/283162
6. 広告配信のフロー 6 広告配信サーバーから JavaScriptを取得 &実行して広告を描画
7. 広告配信のフロー: 広告リクエスト 7
8. 広告配信のフロー: rendering完了通知 8 impressionとして受領 (本当は画面内に表示されたことも計測するなどもう少し考えることはある )
9. 広告配信のフロー: クリック遷移 9
10. 10 データ登録やレポートなどのビジネスを支える管理画面 裏側には管理画面
11. 11 これから紹介するもの 移行途中のものもあるので、実際の構成の中から クラウドを中心とした構成を紹介します
12. 12 2. インフラ構成

13. 13 アーキテクチャ
14. 14 GKE(Google Kubernetes Engine) 広告配信サーバー・管理画面はGKE上
15. 15 GKE(Google Kubernetes Engine) 「サーバーレス化できたほうが楽では？」 → GKE(GCE)のEgressはCloud Runより省費用 広告配信の特徴によるもの • リクエスト数が多い • リクエストあたりのサイズが小さい
16. 16 pximg • pixivのイラスト配信に使われているもの ◦ 画像変換と高速配信を両立できる • なぜCDNではない？ ◦ 広告用画像の要件を満たしつつ 費用減が両立可能 ◦ 管理コストもほぼ増えない https://www.sakura.ad.jp/services/imageflux/image/ 使ってみたい方はこちらをご検討ください
17. 17 配信ログ集積 • 配信サーバーからCloud Loggingに送信 ◦ BigQueryにexport • BigQuery上で加工してDBにレポート記録 • BIツールでの分析にも活用 • 蓄積データ ◦ 1日100GB超
18. 18 3.アプリケーション構成

19. 19 広告配信サーバー • Golang + echo • Pod: ◦ 70〜200(移行途中の分も含む) • レイテンシ: ◦ 〜20ms • リクエスト処理: ◦ 最大300万件/min
20. 20 管理画面 • Ruby on Rails ◦ CRUDをベースにした管理画面 ◦ 社内にはRailsサービスが多い • Pod: 2件前後
21. 21 バッチ • Argo Workflow • Rails rakeタスクがメイン • DB, Redis, BigQueryに対してアクセス・更新
22. 22 4. 重要ポイント

23. 23 データ反映 • 配信サーバーはDBを参照しない ◦ DBクエリでは遅くなるため ◦ その分、反映時間は0秒ではない ▪ バッチ実行間隔とキャッシュクリアに依存
24. 24 シンプル化 • 配信サーバーは責務に集中 ◦ 高速な大量配信 • そのために他の要素は完全分離 ◦ 管理画面 ◦ CTR予測 ◦ ログ集計
25. 25 まとめ

26. 26 • 各サービスに責務を分けてシンプル化 • 分ける際は遅延反映や事前処理を検討 まとめ ※このシステム構成は私だけでなく、昔のチーム &今のチームで考えられたものです