How to face the load - Speaker Deck

Slide 1

Slide 1 text

大規模な広告配信の仕組み pixiv 広告のシステム例 pixiv Inc. saki 2022.03.27

Slide 2

Slide 2 text

2 Proﬁle ● saki (@yensaki) ● 経歴 ○ - 2017: カカクコム(食べログ) ○ 2017 -: ピクシブ ■ 2017 - 2019: pixivFACTORY ■ 2019 - : 広告 ● 好きな技術 ○ Ruby on Rails ○ Kubernetes saki ピクシブ株式会社アドプラットフォーム事業部

Slide 3

Slide 3 text

3 発表の流れ 1. 広告の概要 2. インフラ構成 3. アプリケーション構成 4. 重要ポイント

Slide 4

Slide 4 text

4 1.広告の概要 

Slide 5

Slide 5 text

5 ピクシブの広告規模リクエスト数 ● 月間500億件…超 ○ 年々増えてる広告のリクエスト種類とは ● 広告取得 ● rendering通知 ● クリック ● コンバージョンなど https://www.wantedly.com/companies/pixiv/post_articles/283162

Slide 6

Slide 6 text

広告配信のフロー 6 広告配信サーバーから JavaScriptを取得 &実行して広告を描画

Slide 7

Slide 7 text

広告配信のフロー: 広告リクエスト 7

Slide 8

Slide 8 text

広告配信のフロー: rendering完了通知 8 impressionとして受領 (本当は画面内に表示されたことも計測するなどもう少し考えることはある )

Slide 9

Slide 9 text

広告配信のフロー: クリック遷移 9

Slide 10

Slide 10 text

10 データ登録やレポートなどのビジネスを支える管理画面裏側には管理画面

Slide 11

Slide 11 text

11 これから紹介するもの移行途中のものもあるので、実際の構成の中からクラウドを中心とした構成を紹介します

Slide 12

Slide 12 text

12 2. インフラ構成 

Slide 13

Slide 13 text

13 アーキテクチャ

Slide 14

Slide 14 text

14 GKE(Google Kubernetes Engine) 広告配信サーバー・管理画面はGKE上

Slide 15

Slide 15 text

15 GKE(Google Kubernetes Engine) 「サーバーレス化できたほうが楽では？」 → GKE(GCE)のEgressはCloud Runより省費用広告配信の特徴によるもの ● リクエスト数が多い ● リクエストあたりのサイズが小さい

Slide 16

Slide 16 text

16 pximg ● pixivのイラスト配信に使われているもの ○ 画像変換と高速配信を両立できる ● なぜCDNではない？ ○ 広告用画像の要件を満たしつつ費用減が両立可能 ○ 管理コストもほぼ増えない https://www.sakura.ad.jp/services/imageflux/image/ 使ってみたい方はこちらをご検討ください

Slide 17

Slide 17 text

17 配信ログ集積 ● 配信サーバーからCloud Loggingに送信 ○ BigQueryにexport ● BigQuery上で加工してDBにレポート記録 ● BIツールでの分析にも活用 ● 蓄積データ ○ 1日100GB超

Slide 18

Slide 18 text

18 3.アプリケーション構成 

Slide 19

Slide 19 text

19 広告配信サーバー ● Golang + echo ● Pod: ○ 70〜200(移行途中の分も含む) ● レイテンシ: ○ 〜20ms ● リクエスト処理: ○ 最大300万件/min

Slide 20

Slide 20 text

20 管理画面 ● Ruby on Rails ○ CRUDをベースにした管理画面 ○ 社内にはRailsサービスが多い ● Pod: 2件前後

Slide 21

Slide 21 text

21 バッチ ● Argo Workﬂow ● Rails rakeタスクがメイン ● DB, Redis, BigQueryに対してアクセス・更新

Slide 22

Slide 22 text

22 4. 重要ポイント 

Slide 23

Slide 23 text

23 データ反映 ● 配信サーバーはDBを参照しない ○ DBクエリでは遅くなるため ○ その分、反映時間は0秒ではない ■ バッチ実行間隔とキャッシュクリアに依存

Slide 24

Slide 24 text

24 シンプル化 ● 配信サーバーは責務に集中 ○ 高速な大量配信 ● そのために他の要素は完全分離 ○ 管理画面 ○ CTR予測 ○ ログ集計

Slide 25

Slide 25 text

25 まとめ 

Slide 26

Slide 26 text

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