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

by Supership株式会社

Slide 1

Slide 1 text

Conﬁdential 2021.3.15 Supership 佐野宏英@sanojimaru 1兆req/月広告システムを横目に 100億req/月ぐらい広告システムを新築した話

Slide 2

Slide 2 text

アジェンダ ● Supershipの紹介（軽く） ● Scaleout Ad Platformの紹介 ● SC2(Supership Contents Connect)の紹介目的 ● Supershipの技術を少し知ってもらう ● アドテクに興味を持ってもらう今日話すこと  2

Slide 3

Slide 3 text

佐野　宏英（さ　ひろひで） @sanojimaru 趣味: 顔ハメエディタ: Vim→VSCode ターミナル: iTerm2+tmux 好きな言語: Javascript系好きなAWS: Glue ■略歴 • バイク屋さん • 中小下請けSIer→無名ベンチャー→フリーランス • アップベイダー創業→被M&AでSupershipジョイン • 今に至る誰な   3

Slide 4

Slide 4 text

Trading Desk 広告運用 Data Management Platform（DMP） BRAND 広告主 CUSTOMER 消費者 Solution 検索不正広告防止 Ad Platform 広告配信プラットフォーム ―広告主向け― ―メディア向け― Data Marketing Consulting Agency 代理店デジタルマーケティングを中心に様々なソリューションを提供 Supershipとは 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Scaleout Ad Platformとは月間2,500億近くの広告表示を実現する広告主向け広告配信PF 3,400以上の広告媒体、30,000以上のアプリでの広告配信を実現するPF SSP（メディア向け配信PF） DSP（広告主向け配信PF） 6 Scaleout Ad Platform = 広告配信管理システム（主に）2つのサービスがScaleout Ad Platformの上で稼働中

Slide 7

Slide 7 text

広告主にとっても、媒体社にとっても、ユーザーにとっても  もっとも価値ある広告を届ける仕組み  広告主媒体社ユーザーターゲットユーザーだけに広告を出したいなぁ広告枠をうまく運用して広告収益を拡大させたいなぁ興味ある広告だけ見たいなぁアドテクと？

Slide 8

Slide 8 text

広告主媒体社ユーザーターゲットユーザーだけに広告を出したいなぁ広告枠をうまく運用して広告収益を拡大させたいなぁ興味ある広告だけ見たいなぁ DSP SSP こような世界観を実現するためにテクノロジーで解決  アドテクと？

Slide 9

Slide 9 text

広告主媒体社ユーザーターゲットユーザーだけに広告を出したいなぁ広告枠をうまく運用して広告収益を拡大させたいなぁ興味ある広告だけ見たいなぁ DSP SSP こような世界観を実現するためにテクノロジーで解決  アドテクと？こ取引における手数料を頂く商売システムコストが高いと逆ザヤリスク有り安価かつ安定して高トラフィックをさく仕組みが必要

Slide 10

Slide 10 text

Scaleout Ad Platformとは 10 1. カジュアル(＝安価)に数千億アクセス/dayを捌くことを目指して開発された純国産広告配信管理システム 2. PCサーバ1台あたり1億アクセス/day~な性能 3. 月間数兆アクセスも可 4. 任意ターゲティングが可能 5. マルチデバイス対応基本設計最配信研究会山崎さん（@yamaz）

Slide 11

Slide 11 text

Conﬁdential 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

Slide 12

Slide 12 text

Conﬁdential 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

Slide 13

Slide 13 text

Conﬁdential 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

Slide 14

Slide 14 text

Conﬁdential Railsによる実装例(解説)  class AdsvrController < ApplicationController def lookup render :text # 全スケジュール中から Schedules.find(:all) # 配信してよい案件を抽出して .grep{|sched| sched.can_delivered?} 　 # 一番優先度が高いもを選択して .max(&:priority) # 最適なクリエイティブを作成 .to_html end end # これを超高に処理するが広告エンジンです 14 14

Slide 15

Slide 15 text

Conﬁdential 条件評価部  # 配信をしていい広告案件を抽出 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

Slide 16

Slide 16 text

Conﬁdential 優先度評価部  # 一番優先度が高いもを選択 .max(&:priority) 優先度を決定する要素 ■ 案件につけられた優先度 ■ クリック単価が高い(優先度高) ■ PV達成がやい(優先度高) ■ 特別なユーザがアクセスした時 (優先度高) ■ 自社稿(優先度低) など 16 16

Slide 17

Slide 17 text

Conﬁdential クリエイティブ最適化  # 最適なクリエイティブを作成 .to_html ■ デバイス・表示ページにあわせた出力 ■ ユーザに応じた最適化 17 17

Slide 18

Slide 18 text

Scaleout Ad Platformのアーキテクチャ 18 ● 安価に数千億アクセス /dayを捌くことに特化しており、オンプレ環境（ DC3拠点を運用） ● 約2000台ぐらい物理サーバー（配信サーバーで 1000台、集計で500台ぐらい） ● 1リクエストあたり単価に換算すると AWSより安く済んでいます（当社比）

Slide 19

Slide 19 text

Scaleout Ad Platformのアーキテクチャ 19 何を・誰に配信するか情報を持つ。数十億レコード/時を更新することも。サーバーごとローカルに分散し対応広告システムの大変ポイント（ごく一部）これらをクリアできる堅牢なシステム

Slide 20

Slide 20 text

Scaleout Ad Platformのアーキテクチャ 20 ログ=お金となるでログ欠損許容できない。確実な収集と集計が必要広告システムの大変ポイント（ごく一部）これらをクリアできる堅牢なシステム

Slide 21

Slide 21 text

Scaleout Ad Platformのアーキテクチャ 21 1兆レコード/月を超えるデータを毎時で集計し、正確なレポートを作成する広告システムの大変ポイント（ごく一部）これらをクリアできる堅牢なシステム

Slide 22

Slide 22 text

● たくさん顧客が既に存在する広告システムしかし問題も 22

Slide 23

Slide 23 text

● たくさん顧客が既に存在する広告システム ● 顧客毎カスタマイズとして様々な仕様を内包化する非効率化を招く可能性もあり難しいしかし問題も 23

Slide 24

Slide 24 text

● とある顧客向けに配信コンテンツ管理、レコメンド配信、広告ターゲティング配信を提供 ● フルAWS環境とIaCにより、必要に応じて顧客別デプロイが可能に ● AWS コストタグや、場合により AWSアカウントごと分けることで柔軟なコスト管理も実現 ● ある程度コスト効率を犠牲にする代わりに、多くマネージドサービスを活用し工数を削減（管理しているサーバー ECSが動いているEC2インスタンスぐらい） ● マルチテナント可能なデータ構も実装 ● （コスト掛かるが）大規模トラフィックにも耐えうる想定というわけで新築しました 24

Slide 25

Slide 25 text

というわけで新築しました 27 何を・誰に配信するか情報を持つ。数十億レコード/時を更新することも。サーバーごとローカルに分散し対応理論上、性能上限ないDynamoDBにより配信データ中央集権化

Slide 26

Slide 26 text

というわけで新築しました 28 ログ=お金となるでログ欠損許容できない。確実な収集と集計が必要ログ収集 fluentdを利用し欠損なくS3へ保存（困りどころ）

Slide 27

Slide 27 text

というわけで新築しました 29 1兆レコード/月を超えるデータを毎時で集計し、正確なレポートを作成する今ところ性能的にも問題なく、Hadoopクラスタ管理が不要になった

Slide 28

Slide 28 text

Fargateが使えない ● カーネルパラメータのチューニングが出来ない（ファイルディスクリプタなど）ので広告システムのような高トラフィックなシステムには不向き ● ECS on EC2のインスタンスが削れればフルマネージド化もできそうだが・・・困りどころなど  30

Slide 29

Slide 29 text

DynamoDBのwriteが高い（金額） ● DynamoDBのwrite課金はdeleteも含むため、配信データのリフレッシュで更新+削除で2倍のコストが掛かる ● 更にセカンダリインデックスも使うとN倍・・・ ● 更新ごとに新規テーブルを作り、配信サーバが見るテーブルを変更 ● 更新中のみwrite capacityを上げ、完了後にすぐに下げる運用困りどころなど  31

Slide 30

Slide 30 text

ログ収集で障害が発生（AWSの問題じゃないけど） ● もともとdockerのfluentd-logdriverを利用していたが、buffer-limit設定時においてもメモリバッファが足りずログがロスト ● ECSにEBSボリュームを追加し、fluentdをログファイルで動作させることでログのロストを回避困りどころなど  32

Slide 31

Slide 31 text

AWS化によりアドテクにおける大変どころがいくつか楽に ● 大量のサーバーやログの管理がなくなった ● KVSの性能上限が理論上無くなった ● Hadoopクラスタの管理がなくなったただしお金面ではオンプレのほうがやっぱり安いし性能も良い（当社比） →チューニングやボリュームディスカウントでもっと頑張るまとめ  33

Slide 32

Slide 32 text

Supershipはアドテクを中心に高トラフィックなシステムをオンプレ・クラウド両方で扱うという貴重な経験ができる会社です。他にも検索エンジン、機械学習と色々揃っています。お仕事と人材は随時募集中です。最後に  34

Slide 33

Slide 33 text

ご清聴ありがとうございました。最後に  35