「アドテクを支える技術 〜1日40億リクエストを捌くには〜」 【23卒/24卒】オンライン勉強会：「アドテクを支える技術 〜1日40億リクエストを捌くには〜」 https://microad.connpass.com/event/255303/ #MicroadDevs

1. アドテクを支える技術
1日40億リクエストを捌くには
株式会社マイクロアド
大澤 昂太
2022年 エンジニア夏オンライン勉強会

2. 自己紹介
● 名前: 大澤 昂太
● 職歴:
○ アドテクとかよく知らなかったものの、2016年新卒でマイクロアドに入社
○ SkyMagicという部署で小型ドローンの開発とドローンの集中制御ソフトの開発に参加
○ データエンジニア部署に移動してデータ基盤周りの開発に参加
○ 現在 DSP開発部署でチームリーダーをしています
■ 高速化周りの仕事が多いです
● 趣味
○ 基本家が好きで、本を読んだり映画を観ています
○ 外に出るとダイビング、操船、山登り等をすることが多いです
2
船酔い 筋肉痛 意外と寒い

3. 3
インターネット広告とは

4. インターネット広告の市場規模
● 2019年、初めてインターネット広告費が2兆円超えでテレビメディア広告費を抜く
● 総広告費は6兆円規模なので、約30%がインターネット広告費
● コロナ禍の中でも９年連続成長
4
引用: https://www.dentsu.co.jp/news/release/pdf-cms/2020014-0311.pdf

5. ターゲティング広告
● インターネット広告の始まりは日本だと1996年頃
● 最初はHTMLに直接広告を埋め込んでいた
● 広告を管理するアドサーバの登場によって、広告枠に動的に広告が表示できるようになる
● アクセス情報、IP、時間帯等に応じて広告を出し分けられる (ターゲティング広告)
● 具体的には下記のターゲティングが可能 (マイクロアドで利用可能な機能のみ掲載)
○ デバイスターゲティング
○ プレースメントターゲティング
○ オーディエンスターゲティング
○ ロケーションターゲティング
○ タイムターゲティング
○ ・・・
5
Webページ
広告
Webページ
広告
Webサーバ
アドサーバ
Webサーバ
Cookie、IP、時間等を利用してユーザに
適切な広告を配信
予約しておいた広告を配信
アドサーバ以前 アドサーバ以降

6. DSP/SSPへの変遷
● 最初の頃、広告主はメディアや広告枠を選定して購入する必要があり手間がかかった(純広告)
● また、メディアは広告在庫が売れ残るリスクがあった
● そこで、複数メディアの広告枠をまとめて販売するアドネットワークが登場
● しかし広告主、メディア双方にとってデメリットがあった
○ 広告主: 掲載面を選べないので、出したくないメディアにも広告が出る
○ メディア: 適正な価格で取引できない
● そこで、オークションの機能を持ったアドエクスチェンジが登場
● アドエクスチェンジを構成するツールがDSP (Demand Side Platform), SSP (Supply Side Platform)
● だったが、RTBが主流になり、DSP/SSPが直接繋がるようになる
6
Webページ
広告
Webページ
広告
Webページ
広告
アドネットワーク 広告主
広告枠をまとめて購入
アドエクスチェンジ DSP
SSP
買いたい価格で買う
売りたい価格で売る
オークション方式で取引
SSP
DSP
RTB (Real Time Bidding)
DSP
DSP
SSP
SSP
SSPとDSP同士が相互に繋がる
アドネットワーク アドエクスチェンジ DSP/SSP

7. 広告の品質維持
昨今、インターネット広告の品質問題が注目されている
● ブランドセーフティ - 不適切なメディアへの配信による広告主のブランド毀損の懸念がある
● アドフラウド(広告詐欺) - ネット広告の仕組みを悪用して広告主からお金を引き出す問題
漫画村等の違法サイトが話題の時にこれらも問題になり広告を掲載していた広告代理店等が炎上した
7
アドベリフィケーションの重要性が増す
DSP DB
ブランドセーフティ
API
アドフラウドAPI
URL/IPで問い合わせ
アドベリ関連のソリューションを提供している会社例
DSPによるアドベリの活用

8. プライバシーの問題
ターゲティング広告ではユーザー単位のトラッキングが重要だった。しかし、世の流れ的にはトラッキング
は規制の対象になり始めている
● EUでは一般データ保護規則(GDPR)が2018年5月に施行
○ 日本では改正個人情報保護法
● SafariではITP(Intelligent Tracking Prevention)によってサードパーティクッキーをブロック
● ChromeではPrivacy Sandboxなどクッキーの代替案が提案（PostCookie）
8
そのため業界では
● メディア側の広告効果に注目が集まっている(トピック分析)
○ データを持つ会社との連携などが加速
● PostCookie技術などグループ化されたユーザー情報を分析できるように開発進行
● 会員制サイトなどログイン制のサイトの情報などをに注目
Cookieによるターゲティング比率はかなり下がっているがインターネット広告への需要は高まっているので
新しく複雑なデータ構造への分析がうまく言った企業が伸びると考えている

9. ここまでは一般的なインターネット広告の話でした。
続いて、自分が担当しているDSPの技術的な部分を見ていきます。
9

10. DSPのパフォーマンスで重要な３つの軸
● レイテンシ（早くレスポンスを返せるか）
● スループット（大量のオークションを処理できるか）
● 取り扱い量（大量の広告を取り扱えるか）
10

11. 100msのレスポンス制約
● SSPが入札要求をしてから100ms以内に返却することがDSPの必須条件
● 100msを超えた場合はタイムアウトで入札が拒否される
● レイテンシを含む時間なのでDSPでは遅くても30ms程度で処理する
● 入札できない = 落札されない = 売上を生まない
11
100msの制約を守ることは業務が成立する必要条件
SSP
DSP A
DSP B
DSP C
WEBページ
広告枠
入札要求
100ms以内に応答しないとタイムアウト
応札(50ms)
広告をリクエスト
広告をレスポンス
応札(100ms)
応札(150ms)
入札要求
入札要求
50msで応答してい
るので入札成功
100msで応答して
いるので入札成功
150msで応答して
いるので入札失敗

12. スループットと入札機会
● 大量のオークションリクエストを受けると
良いオークションに入札できる機会が増える
● 入札機会の増大 = 売上アップ
● 大量のリクエストを捌きたいなら・・・
○ サーバを大量に用意する
○ サーバのスペックを上げる
● しかし・・
○ サーバはコストがかかる
● よって、富豪的アプローチで万事解決とは行かない
● 1台あたりの収益を改善するためにチューニング
12
大量のリクエストが捌くことは業務が成立する十分条件
日毎のリクエスト数 ※軸の値は伏せてます
増加傾向にある

13. 増え続ける広告在庫
● DSPビジネスの拡大とともに扱う広告在庫は増大 ※広告在庫とは広告の表示可能回数のこと
● 1度のオークションで出来るだけ多くの広告在庫を入札候補にしたい
● 多くの広告在庫を扱える = より精度の高い広告を配信可能 = 高い広告効果
○ また、たくさん表示可能なため単純に売上が伸びる
● 一方で扱う広告の増大は処理負荷の増大に直結
● 少なくても業務は成り立つけどビジネスが拡大できない
13
多くの広告在庫を扱えることは業務が成立する十分条件
SSP DSP
入札要求
応札
化粧品関連のページから
リクエスト
うーん・・・とりあえず健
康関連？ DSP 化粧品が最適！
(略)
入札要求
応札
DSP
(略)
入札要求
応札
(タイムアウト)
化粧品
関連
健康
関連
旅行
関連
広告在庫
健康
関連
旅行
関連
広告在庫
旅行
関連
健康
関連
化粧品
関連
広告在庫
・・・
お、おおすぎる！
処理が間に合わねぇ
広告在庫が少ないと・・・ 広告在庫が多いと 広告在庫が多過ぎると
処理が間に合わず機会損失が発生するのは
もったいない！
こうならないようにエンジニアが頑張る

14. パフォーマンスに対するアプローチとキーワード
● 業務アプリケーションの高速化は思った以上に大変
○ 保守性、信頼性との両立
● スループット量の向上にはマルチスレッドが効く
○ Scala
○ Akkaフレームワーク
● 大量の広告在庫に対応するには計算を増やさないようにする
○ 広告在庫に応じて計算をなるべく実施しないようにする
● レスポンス速度の向上には処理のボトルネック解消が必要
○ データベースへのアクセスを削減する
○ 高速なアルゴリズムの導入を検討する
14
次のスライドからそれぞれ詳細な説明をしていきます

15. 15
業務アプリケーションの高速化は思った以上に大変

16. 保守性、信頼性を維持しながら高速化をする
● 業務アプリケーションでは、保守性、信頼性を維持することが大事
● 保守性が欠如したアプリケーション
○ 複雑すぎて改修のコストがとてつもないことになる
○ 開発スピードが著しく落ちる
○ 場合によって機能追加が不能になる -> ビジネスの閉塞
● 信頼性が欠如したアプリケーション
○ ある日信じられない金額の損失を出す事になる
○ 商品として売ることが難しくなる
● 高速化(最適化)は保守性、信頼性に相反する結果をコードにもたらす事が多い
○ 高速化を頑張るほどビジネス的に閉塞してしまう可能性がある
○ ただ、絶対相反するわけではないのでなるべく良い案を探す
16
高速化
最適化
保守性
信頼性
真ん中を目指せると嬉しいが基本どちらかに寄る

17. 17
スループット量の向上にはマルチスレッドが効く

18. マルチスレッド
● 複数のタスクを同時に実行するための機能
○ 複数のタスクは別々のCPUに割り当てられる事がある
○ マルチCPUの性能を存分に使うことができる
● しかし…
○ スレッドを使ったプログラミングは複雑になりやすく、問題を起こしやすい
18
次はAkkaとScalaでのマルチスレッドを活用について

19. Scala
● JVM言語（Javaの基盤に乗る言語）の1つ
● 静的型付け言語
○ 型推論・パターンマッチング
● Java製ライブラリと相互運用可能
● オブジェクト指向と関数型プログラミングの概念を持つ
● 充実したコレクションAPI
○ ループ処理ではなく述語関数によって表現
19
object Main extends App {
println("Hello world")
}
Seq(1,2,3,4,5)
.map(_ * 2)
.filter(_ > 5)
> Hello world
> Seq[Int] = List(6, 8, 10)
Hello worldの例 述語関数を使った例(for文を使わずにループ処理)

20. なぜScalaなのか
● 業務ロジックを安全に書ける
○ 言語がカバーできる業務ロジックの範囲が広く、誤ったロジックを書くと開発中に警告する
○ 関数型言語の特徴があり、バグが発生しやすいコードを避ける事が推奨されている
○ null関連のエラーを発生させない構造
■ 総じてランタイムエラーが発生しづらい
● 安心してデータベースを利用できる
○ データベース周りの活発なプロジェクトが多いJava言語の資産を使用できる
○ 変わったデータベースへもアクセスする手段が用意されている事も多い
● 生産性が高い
○ 関数型特有の癖があるものの、標準ライブラリが強力で複雑な事が短くコーディング出来る
● 実行速度が割と早い
○ Javaに近いくらいは速度を出すことが出来る
○ 上記３つのメリットを持ちながら実行速度が早い言語はそんなにない
20

21. Scalaの並行プログラミング
Future
● Scalaで非同期処理を記述するための仕組み
● 並行処理が非常に手軽に取り扱うことができる
● Futureは処理が完了していないということを値として取り扱う事ができる
● そのため処理の完了を待つこと無く後続の処理をつなげていくことが出来る
21
Future {
println("処理１")
}
println("処理２")
処理を並行に実行させる例（処理１と処理２は並列に実行される）
val f = Future {
println("処理")
}
f.map(x => process(x))
Futureを値化した例 (fには処理が未確定の状態か確定した状態が入る)
処理が確定でも未確定でも後続処理をつなげていくことが出来る

22. Akka
● Scala製の並行並列処理に特化したツールキット(フレームワークとライブラリを合わせたやつ)
● 並行並列、分散システムを簡単に記述するためにアクターモデルを提供
○ アクターモデル自体は1973年に登場
○ クラウドコンピューティングの進歩とムーアの法則の終焉などでスケールアウトが主流になってきたことで
再び注目を浴びてきた
● アクター以外にAkka Streams, Akka Clustering, Akka HTTP等様々なコンポーネントを提供している
● Akkaはリアクティブ宣言に基づいて設計されている
○ 「リソースを効率よく利用し、アプリケーションをを自動的にスケールできるようにすること」 (Akka実践バイブルより引用)
22
引用: https://www.reactivemanifesto.org/ja

23. アクターモデル
● アクターはメッセージ駆動の計算実体(スレッドに似ている)
○ アクターは非同期に実行される
● アクター同士(数千・数百万)が協調して1つのアプリケーションを構成する
● アトミックやロックを使わず、安全に並行並列処理が実装できる
○ アクターはメールボックス(メッセージキューみたいな)を持っていて、1度に1つ処理
● アクターはfire-and-forget(撃ちっぱなし)の性質によって、非同期処理を実現している
● スケーラビリティのためにアクター同士は疎結合になっている
○ 空間/位置: 位置透過性とも。同じノード、異なるノード等、どこにアクターがいても良い
○ 時間: アクターはタスクの完了について何も保証しないし、期待もしない
○ インターフェース: アクター同士は何も共有しない。インタフェースが正しいかとか関係ない
23
Actor
Actor
Actor
メッセージ送信
メッセージ送信
メッセージ送信
アクターシステム
メールボックス
(メッセージキュー)
アクターは非同期で動作するのでア
クターの数だけ並行並列に動作可
能
ロックとかアトミックな操作は一切不
要
メッセージを受信し
て何か処理

24. スループットの向上 まとめ
● 並行処理を導入する
● Scalaは先進的な並行処理サポートが有る
● 保守性、信頼性をあまり損なう事無くスループットを向上することが出来た
※スループットの向上にはマルチスレッド以外の解決方法も数多あります
24

25. 25
大量の広告在庫に対応するために
計算をなるべく抑える

26. 広告在庫に応じて増える処理
● DSPビジネスのスケールに応じて広告の在庫は増え続ける
● 増えた広告に対して愚直に対応していると限界が来てしまう
○ ただ、高い保守性を持つコードは愚直な実装である事が多い
● なるべく広告の在庫と連動しづらい仕組みを心がける
○ 広告在庫間の共通項を見つけ出して処理結果を共有する
広告在庫の処理方法を変更する
26
DSP
(略)
入札要求
応札
(タイムアウト)
旅行
関連
健康
関連
化粧品関
連
広告在庫
・・・
お、おおすぎる！
処理が間に合わねぇ

27. 共通した情報を見つけ出し一緒に処理する
● 発生したオークションが広告在庫とマッチしているか測る判定処理が多くある
● 似たような設定を行っている広告在庫については、共通した項目で括りだして少ない処理で実施
するようにする
27
広告在庫
広告の配信情報の
共通項目
オークション毎
判定処理
共通した情報を利用することで処理量を減らす
広告在庫よりも数が少
なく在庫が増えても数
が増えづらい物
数が多くなっていく
在庫がマッチしている
か判定する
こちらで判定する
一致しているものをま
とめて処理

28. 広告在庫の処理方法を変更する
広告在庫はオークション毎にDSP処理を通じて入札するべきかどうか精査されていく
28
処理１ 処理２
在庫
対象ではない物を在庫か
ら減らすための書き込み
を行う
たまに読み込まれる
広告在庫を管理する処理自体を改善して底上げを行う
在庫の処理には特性があることに気づいた
● 広告在庫周りの処理は書き書き込みが多くて、読み込みが少ない（1リクエストあたり）
● 上記に注目して、書き込み負荷が軽く、読み込みが重いデータ構造を用意することにした
● 普通の言語では書き込み負荷が重く、読み込み負荷が軽い構造を提供している

29. 大量の広告在庫に対応 まとめ
● 広告在庫管理が増えるとその分負荷が高まる
● そのため特に力を入れてチューニングを行う
● 広告の在庫が増えても負荷の増加が緩やかな仕組みなどを検討する
29

30. 30
レスポンス速度の向上にはボトルネック解消が必要

31. レスポンス速度が遅くなる原因
● （オークション）レスポンス速度が遅くなる原因は本当に色々考えられる
○ CPUを使った計算処理時間にかかっている
○ 他のスレッドの完了を待っている所がある
○ データのディスクへの読み書き時間がかかっている
○ 外部への通信（データベースなど）時間がかかっている
○ …
● Webアプリケーションでは通信やディスクへの読み書きが大きな問題になっている事が多い
● 事前調査の結果、弊社のDSPでもデータベース周りが特に重そうだった
31
データベース周りから改善をかけていく

32. データベースへの対処方法
● メモリへのアクセスと比べてしまうとデータベースへのアクセスはとてつもなく遅い
○ ネットワークを経由しているためその分遅延がある
○ TCP通信は待ちが多いので直列で実施されると特に遅くなる
32
アプリケーション
サーバ
ネットワークは遅い
アプリケーション データベース
直列で処理す
る場合、往復
時間待つ事に
なる
リクエスト
レスポンス
リクエスト
レスポンス
データベースへのアクセス量を減らすアプローチを行う
データベース

33. データベース周りのボトルネック解消
データベースの内容をメモリにコピー
● 広告配信の指示など頻繁に変わらないデータ
ベースの情報は定期的にメモリにコピーして
参照するようにする
● 問題点として頻繁に変わるデータベースでは
実施することが出来ない
33
データベースへのアクセスをまとめる
● 同じデータベースにアクセスする別々の処理
で一度にアクセスするようにする
DSP処理
メモリ上のコ
ピー
データベース
遅いアクセス
早いアクセス
DSP内部処理
１
DSP内部処理
2
アクセスをまと
める処理 データベース
アクセスと処理速度がとても向上する
データベースへのアクセスが減少する
事前コピー
一度のアクセスに
二度のアクセス要求

34. CPUで実施している処理が遅い場合
● データベース周りの問題を潰してもまだ目標に届かない場合CPUなど他の箇所を見て
いく見ていく
● CPUでは様々な問題が発生する
○ 入力に応じて処理量が増える所で問題が発生しやすい（計算量のオーダーが大きい）
○ がO(1)の処理でもそもそもそれ自体が大変重かったりするから注意する
● 計測した結果、特に重い中でも手軽そうな所から改修をかける
34
CPU周りは予想外の箇所が問題
になっている事が多いので事前
計測がとても重要
重かった広告の配信時間制御処理周りを見ていく

35. 広告の配信時間制御処理周りの改修
● 時間に応じてある広告の配信を開始したり取りやめたりする処理が存在する
● ここが重くなってきた事が調査でわかったので最適化をかける
● 時間制御するために時間が一致する広告が存在するか確認する処理が線形探索O(n)になっていた
● 二分探索木を導入してO(logn)になるように修正を行う事を検討した
● 二分探索木を導入するには事前に対象がソートされている必要がある
● 処理対象のデータを直接ソートしてしまうと、広告がこの処理に特化して並んでしまう
（他の制御で似たようなことが起きたときに、様々なデメリットが発生）
● 並び順情報を別で保持するインデックスという仕組みを作成してそこに対して二分探索を実施するよう
にした
● クラスの中にインデックスを隠す事で従来のユニットテストを再利用出来るようにした
35
広告在庫 開始時間インデックス
クライアント
クラス
従来どおり
アクセス
内部ではインデックスを利用した
アクセスにすり替わっている
広告在庫クラス 終了時間インデックス
広告
(時間内)
広告
(時間内)
広告
(時間外)
広告
(時間内)
有効な広告を探す

36. レスポンス速度の向上 まとめ
● レスポンス速度を向上させるには、処理を計測して最適化をかけられそうな箇所を探す
● 解決が簡単そうに見えて、うまくやらないと信頼性や保守性に影響がある事が判明する事
が多い(コードがめちゃめちゃに)
36
高速化、信頼性、保守性を天秤にかけて最適な答えを探す

37. パフォーマンスに対するアプローチ まとめ
● スループット量の向上にはマルチスレッドが効く
○ 並列処理に強いScala
○ 高度な並列処理機能を持つAkkaフレームワーク
● 大量の広告在庫に対応するには計算をなるべく避ける
○ 広告在庫に応じて計算をなるべく増やさないようにする
○ 広告在庫自体の処理を高速化して底上げを図る
● レスポンス速度の向上には処理のボトルネック解消が必要
○ データベースへのアクセスを削減する
○ アルゴリズムの導入を検討する
37
今後も、まだまだ３つの軸の改善が必要

38. We Are Hiring!!
38
マイクロアドでは、広告配信システムを一緒に作りたい人を
募集しています！
https://recruit.microad.co.jp/
公式アカウント @microad_dev もよろしくお願いします。