1兆req/月の広告システムを横目に 100億req/月ぐらいの広告システムを 新築した話/ Supership CPO 佐野宏英

2021年3月17日（水）に初回β版イベントとして開催したオンラインイベント「KGDC Tech Conference #0」のなかのセッションにて、Supership CPO （最高プロダクト責任者）佐野宏英 が登壇したスライドです。
Supershipが誇るアドテク技術を集約したScaleOut Ad Platformのシステム基盤について解説いたしました。
■ScaleOut DSP
https://supership.jp/business/scaleout/

■KGDC Tech Conference #0 イベントページ
https://kgdc.connpass.com/event/203487/

Transcript

1. Confidential 2021.3.15 Supership 佐野宏英@sanojimaru 1兆req/月 広告システムを横目に 100億req/月ぐらい 広告システムを 新築した話
2. アジェンダ • Supershipの紹介（軽く） • Scaleout Ad Platformの紹介 • SC2(Supership Contents Connect)の紹介 目的 • Supershipの技術を少し知ってもらう • アドテクに興味を持ってもらう 今日話すこと
 2
3. 佐野　宏英（さ 　ひろひで） @sanojimaru 趣味: 顔ハメ エディタ: Vim→VSCode ターミナル: iTerm2+tmux 好きな言語: Javascript系 好きなAWS: Glue ▪略歴 • バイク屋さん • 中小下請けSIer→無名ベンチャー→フリーランス • アップベイダー創業→被M&AでSupershipジョイン • 今に至る 誰な 
 3
4. Trading Desk 広告運用 Data Management Platform（DMP） BRAND 広告主 CUSTOMER 消費者 Solution 検索 不正広告防止 Ad Platform 広告配信プラットフォーム ―広告主向け― ―メディア向け― Data Marketing Consulting Agency 代理店 デジタルマーケティングを中心に様々なソリューションを提供 Supershipとは 4
5. Trading Desk 広告運用 Data Management Platform（DMP） BRAND 広告主 CUSTOMER 消費者 Solution 検索 不正広告防止 Ad Platform 広告配信プラットフォーム ―広告主向け― ―メディア向け― Data Marketing Consulting Agency 代理店 デジタルマーケティングを中心に様々なソリューションを提供 Supershipとは 5
6. Scaleout Ad Platformとは 月間2,500億近くの広告表示を 実現する広告主向け広告配信PF 3,400以上の広告媒体、30,000以上の アプリでの広告配信を実現するPF SSP（メディア向け配信PF） DSP（広告主向け配信PF） 6 Scaleout Ad Platform = 広告配信管理システム （主に）2つのサービスがScaleout Ad Platformの上で稼働中
7. 広告主にとっても、媒体社にとっても、ユーザーにとっても
 もっとも価値 ある広告を届ける仕組み
 広告主 媒体社 ユーザー ターゲット ユーザーだけに 広告を出したいなぁ 広告枠をうまく運用して広告 収益を拡大させたいなぁ 興味 ある広告だけ見たい なぁ アドテクと ？
8. 広告主 媒体社 ユーザー ターゲット ユーザーだけに 広告を出したいなぁ 広告枠をうまく運用して広告 収益を拡大させたいなぁ 興味 ある広告だけ見たい なぁ DSP SSP こ ような世界観を実現するためにテクノロジーで解決
 アドテクと ？
9. 広告主 媒体社 ユーザー ターゲット ユーザーだけに 広告を出したいなぁ 広告枠をうまく運用して広告 収益を拡大させたいなぁ 興味 ある広告だけ見たい なぁ DSP SSP こ ような世界観を実現するためにテクノロジーで解決
 アドテクと ？ こ 取引における手数料を頂く商売 システムコストが高いと逆ザヤリスク有り 安価かつ安定して高トラフィックをさ く仕組みが必要
10. Scaleout Ad Platformとは 10 1. カジュアル(＝安価)に数千億アクセス/dayを捌くことを目指し て開発された純国産広告配信管理システム 2. PCサーバ1台あたり1億アクセス/day~な性能 3. 月間数兆アクセスも可 4. 任意 ターゲティングが可能 5. マルチデバイス対応 基本設計 最 配信研究会 山崎さん（@yamaz）
11. Confidential 11 ID 期間 配信条件 達成状況 優先度 1 08/01 08/31 100万PV, 女性 11万PV 2 ….. 枠売り, 20~30歳代 10万PV 3 ….. 100万PV, 東京在住 11万PV 4 ….. 1000万PV 438万PV ~ ….. ….. ….. 80 ….. Context(不動産,賃貸) CPC@30円 予算10万 56000円 81 ….. BT(保険) 100万PV 48万PV 82 ….. BT(家電) 200万PV 190万PV スケジュールされている広告の中で 広告エンジン 動き
 11
12. Confidential 12 ID 期間 配信条件 達成状況 優先度 1 08/01 08/31 100万PV, 女性 11万PV 2 ….. 枠売り, 20~30歳代 10万PV 3 ….. 100万PV, 東京在住 11万PV 4 ….. 1000万PV 438万PV ~ ….. ….. ….. 80 ….. Context(不動産,賃貸) CPC@30円 予算10万 56000円 81 ….. BT(保険) 100万PV 48万PV 82 ….. BT(家電) 200万PV 190万PV 配信してもOKなもののうち 広告エンジン 動き
 12
13. Confidential 13 ID 期間 配信条件 達成状況 優先度 1 08/01 08/31 100万PV, 女性 11万PV 30 2 ….. 枠売り, 20~30歳代 10万PV 3 ….. 100万PV, 東京在住 11万PV 12 4 ….. 1000万PV 438万PV 100 ~ ….. ….. ….. 80 ….. Context(不動産,賃貸) CPC@30円 予算10万 56000円 81 ….. BT(保険) 100万PV 48万PV 35 82 ….. BT(家電) 200万PV 190万PV 14 その瞬間において一番優先度が高いものを配信する →の一連の動作を50ms以内ぐらいに完了する 今回選ばれた広告 広告エンジン 動き
 13
14. Confidential Railsによる実装例(解説)
 class AdsvrController < ApplicationController def lookup render :text # 全スケジュール 中から Schedules.find(:all) # 配信してよい案件を抽出して .grep{|sched| sched.can_delivered?} 　 # 一番優先度が高いも を選択して .max(&:priority) # 最適なクリエイティブを作成 .to_html end end # これを超高 に処理する が広告エンジンです 14 14
15. Confidential 条件評価部
 # 配信をしていい広告案件を抽出 grep{|sched| sched.can_delivered?} def　can_delivered? return false if @now > end_at || @now < start_at #　広告案件に付与された複数 条件を評価 constraints.each do |cons| value ||= cons.call(@request) return true if value end return false end 15 15
16. Confidential 優先度評価部
 # 一番優先度が高いも を選択 .max(&:priority) 優先度を決定する要素 ▪ 案件につけられた優先度 ▪ クリック単価が高い(優先度高) ▪ PV達成がや い(優先度高) ▪ 特別なユーザがアクセスした時 (優先度高) ▪ 自社稿(優先度低) など 16 16
17. Confidential クリエイティブ最適化
 # 最適なクリエイティブを作成 .to_html ▪ デバイス・表示ページにあわせた出力 ▪ ユーザに応じた最適化 17 17
18. Scaleout Ad Platformのアーキテクチャ 18 • 安価に数千億アクセス /dayを捌くことに特化しており、オンプレ環境（ DC3拠点を運用） • 約2000台ぐらい 物理サーバー（配信サーバーで 1000台、集計で500台ぐらい） • 1リクエストあたり 単価に換算すると AWSより安く済んでいます（当社比）
19. Scaleout Ad Platformのアーキテクチャ 19 何を・誰に配信するか 情報を持つ。数 十億レコード/時を更新することも。サー バーごと ローカルに分散し対応 広告システムの大変ポイント（ごく一部） これらをクリアできる堅牢なシステム
20. Scaleout Ad Platformのアーキテクチャ 20 ログ=お金となる でログ 欠損 許容できない。確実な収集と 集計が必要 広告システムの大変ポイント（ごく一部） これらをクリアできる堅牢なシステム
21. Scaleout Ad Platformのアーキテクチャ 21 1兆レコード/月を超えるデータを毎 時で集計し、正確なレポートを作成 する 広告システムの大変ポイント（ごく一部） これらをクリアできる堅牢なシステム
22. • たくさん 顧客が既に存在する広告システム しかし問題も 22
23. • たくさん 顧客が既に存在する広告システム • 顧客毎 カスタマイズとして様々な仕様を内包化する 非効 率化を招く可能性もあり難しい しかし問題も 23
24. • とある顧客向けに配信コンテンツ 管理、レコメンド 配信、広告 ターゲティング配信を提供 • フルAWS環境とIaCにより、必要に応じて顧客別 デプロイが可能に • AWS コストタグや、場合により AWSアカウントごと分けることで柔軟なコスト管理も実現 • ある程度コスト効率を犠牲にする代わりに、多く マネージドサービスを活用し工数を削減（管理しているサー バー ECSが動いているEC2インスタンスぐらい） • マルチテナント可能なデータ構 も実装 • （コスト 掛かるが）大規模トラフィックにも耐えうる想定 というわけで新築しました 24
25. というわけで新築しました 27 何を・誰に配信するか 情報を持つ。数 十億レコード/時を更新することも。サー バーごと ローカルに分散し対応 理論上、性能上限 ないDynamoDBにより 配信データ 中央集権化
26. というわけで新築しました 28 ログ=お金となる でログ 欠損 許容でき ない。確実な収集と集計が必要 ログ収集 fluentdを利用し欠損な くS3へ保存（困りどころ）
27. というわけで新築しました 29 1兆レコード/月を超えるデータを毎時で集計し、正 確なレポートを作成する 今 ところ性能的にも問題なく、Hadoopクラスタ 管理が 不要になった
28. Fargateが使えない • カーネルパラメータのチューニングが出来ない（ファイルディスクリプタな ど）ので広告システムのような高トラフィックなシステムには不向き • ECS on EC2のインスタンスが削れればフルマネージド化もできそうだが ・・・ 困りどころなど
 30
29. DynamoDBのwriteが高い（金額） • DynamoDBのwrite課金はdeleteも含むため、配信データのリフレッシュで更 新+削除で2倍のコストが掛かる • 更にセカンダリインデックスも使うとN倍・・・ • 更新ごとに新規テーブルを作り、配信サーバが見るテーブルを変更 • 更新中のみwrite capacityを上げ、完了後にすぐに下げる運用 困りどころなど
 31
30. ログ収集で障害が発生 （AWSの問題じゃないけど） • もともとdockerのfluentd-logdriverを利用していたが、buffer-limit設定時 においてもメモリバッファが足りずログがロスト • ECSにEBSボリュームを追加し、fluentdをログファイルで動作させることで ログのロストを回避 困りどころなど
 32
31. AWS化により アドテクにおける大変どころがいくつか楽に • 大量のサーバーやログの管理がなくなった • KVSの性能上限が理論上無くなった • Hadoopクラスタの管理がなくなった ただしお金面ではオンプレのほうがやっぱり安いし性能も良 い（当社比） →チューニングやボリュームディスカウントでもっと頑張る まとめ
 33
32. Supershipはアドテクを中心に 高トラフィックなシステムを オンプレ・クラウド両方で扱うという 貴重な経験ができる会社です。 他にも検索エンジン、機械学習と色々揃っています。 お仕事と人材は随時募集中です。 最後に
 34
33. ご清聴ありがとうございました。 最後に
 35