2021/11/06 オンライン勉強会 「アドテクを支える技術 〜1日40億リクエストを捌くには〜」 https://microad.connpass.com/event/229092/

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

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

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

4. インターネット広告の市場規模
● 2019年、初めてインターネット広告費が2兆円超えでテレビメディア広告費を抜く
● 8年連続のプラス成長
● 総広告費は6兆6,514億円なので、約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. 広告の品質維持
● 昨今、不適切なメディアへの配信によるブランド毀損の懸念があり、ブランドセーフティが注目される
○ 漫画村、Anitube等の違法サイトに広告を掲載していた広告代理店等が炎上
● インターネット広告の仕組みを悪用したアドフラウド(広告詐欺)が問題になっている
○ これも漫画村で使われていたので、注目が集まった
7
アドベリフィケーションの重要性が増す
DSP DB
ブランドセーフティ
API
アドフラウドAPI
URL/IPで問い合わせ
定期的にDBを更新
アドベリ関連のソリューションを提供している会社例
DSPによるアドベリの活用

8. プライバシーの問題
● ターゲティング広告ではユーザーのトラッキングが重要
● しかし、世の流れ的にはトラッキングは規制の対象になり始めている
● EUでは一般データ保護規則(GDPR)が2018年5月に施行
○ 日本では改正個人情報保護法
● SafariではITP(Intelligent Tracking Prevention)によってサードパーティクッキーをブロック
● Googleが推進するPrivacy Sandboxによってクッキーの代替案が提案
● 今後は「プライバシーテック」が流行るような気がしている (個人的見解)
8
Webページ
計測
タグ
Webページ
計測
タグ
計測
サーバ
Webページを横断して計測
(Cookieを利用)
DSP
DB
永続化 RTB時に参照
Cookieを利用した
トラッキング

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

10. 10
DSPのパフォーマンスで重要な３つの軸

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

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

13. スループットと入札機会
● 大量のリクエスト = 入札機会の増大 = 売上アップ
● 出来る限り多くのリクエストを受けたい
● 大量のリクエストを捌きたいなら・・・
○ サーバを増やす
○ サーバのスペックを上げる
● しかし・・
○ サーバは高い(1台当たり10~20万)
○ ラックに限りがある
○ 1台当たりの収益率が落ちるのは本末転倒
● よって、富豪的アプローチで万事解決とは行かない
● ハードに頼り切るのではなく、ソフトウェアも限界までチューニング
13
大量のリクエストが捌けることは業務が成立する十分条件
日毎のリクエスト数 ※軸の値は伏せてます
増加傾向にある

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

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

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

17. 保守性、信頼性を維持しながら高速化をする
● 業務アプリケーションでは、保守性、信頼性を維持することが大事
● 保守性が欠如したアプリケーション
○ 複雑すぎて改修のコストがとてつもないことになる
○ 開発スピードが著しく落ちる
○ 場合によっては改修不能になる -> ビジネスの閉塞
● 信頼性が欠如したアプリケーション
○ ある日信じられない金額の損失を出す事になる。場合によっては倒産
○ 商品として売ることが難しくなる
● 高速化は保守性、信頼性に相反する結果をコードにもたらす事が多い
○ 高速化を頑張るほどビジネス的に閉塞してしまう可能性がある
○ ただ、絶対相反するわけではないので
○ 熟考して設計すれば３つを比較的維持できる道が見つかる場合もある
17

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

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

20. Scala
● JVM言語（Javaの基盤に乗る言語）の1つ
● 静的型付け言語
○ 型推論・パターンマッチング
● 小規模なスクリプトから大規模システムの構築まで幅広く利用可能
○ Scalaはscalable languageに由来する
● Java製ライブラリと相互運用可能
● オブジェクト指向と関数型プログラミングの概念を持つ
● 充実したコレクションAPI
○ ループ処理ではなく述語関数によって表現
20
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文を使わずにループ処理)

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

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

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

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

25. スループットの向上 まとめ
● 並列処理を導入することは主要な言語であれば大体可能
● ScalaとAkkaの組み合わせでは比較的コードの見た目や構造を並列処理に寄せすぎずに並列処理を実現
できる
● 保守性、信頼性をあまり損なう事無くスループットを向上することが出来た
※スループットの向上にはマルチスレッド以外の解決方法も数多あります
25

26. 26
大量の広告在庫に対応するために
計算をなるべく避ける

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

28. 共通した情報を見つけ出して処理結果を共有する
● 似たような設定を行っている広告については、共通した項目で括りだして1回の処理で実施するようにする
● 単純な物もあれば、よく考えなければ見つけられないものもある
28
広告在庫
広告の配信情報をま
とめた物
判定処理
共通した情報を利用することで処理量を減らす
広告よりも数が少ない
物によっては多くなっ
ていかない
数が多くなっていく

29. 広告在庫の処理方法を変更する
● 広告在庫はリクエスト毎にDSP処理を通じて入札するべきかどうか精査されていく（減っていく）
● リクエスト毎に対象になる在庫の管理には標準のSet型というリスト状のクラスが使用している
● ただ、Scala標準のデータ型ですらDSPでは重く感じる
● 広告在庫周りの処理は書き換えが多くて、読み込みが少ない（1リクエストあたり）
● 上記に注目して、書き込み負荷が非常に軽く、読み込みが重いデータ構造を用意することにした
(Set型は書き込み負荷が重く、読み込みが負荷が軽い)
29
処理１ 処理２
在庫
在庫を減らしていく
たまに読み込まれる
在庫の処理自体を改善して底上げを行う

30. 大量の広告在庫に対応 まとめ
● 広告在庫管理周りはビジネスのスケールに応じてどんどん負荷が高まる
● そのため特に力を入れてチューニングを行う
● 広告の在庫が増えても負荷が増えすぎないような仕組みなどを検討する
30

31. 31
レスポンス速度の向上には処理の最適化が必要

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

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

34. データベース周りの最適化
データベースの内容をメモリにコピー
● 広告配信の指示など頻繁に変わらないデータ
ベースの情報は定期的にメモリにコピーして
参照するようにする
● コピーの際にDSP処理に合わせて事前計算な
どを実施する
● 頻繁に変わるデータベースでは実施すること
が出来ない
34
データベースへのアクセスをまとめる
● 同じデータベースにアクセスする別々の処理
で一度にアクセスするようにする
● あまり関係の無い処理をまとめるのでデメ
リットがある
○ 関係の無い処理の共通部分を見つけ出す設計
○ 無理な設計で保守性が落ちる
DSP処理
メモリ上のコ
ピー
データベース
とても遅い
とても早い
DSP内部処理
１
DSP内部処理
2
アクセスをまと
める処理 データベース
アクセスと処理速度がとても向上する
データベースへのアクセスが減少する

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

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

37. レスポンス速度の向上 まとめ
● レスポンス速度を向上させるには処理を目で見て最適化をかけられそうな箇所を探す事が多い
● 解決が簡単そうに見えて、実際に最適化する段になると信頼性や保守性に影響がある事が判明すること
が多い
37
高速化、信頼性、保守性を天秤にかけて最適な答えを探す

38. パフォーマンスに対するアプローチ まとめ
● スループット量の向上にはマルチスレッドが効く
○ 並列処理にも強いScala
○ 高度な並列処理機能を持つAkkaフレームワーク
● 大量の広告在庫に対応するには計算をなるべく避ける
○ 広告在庫に応じて計算をなるべく増やさないようにする
● レスポンス速度の向上には処理の最適化が必要
○ データベースへのアクセスを削減する
○ 広告の選択に探索アルゴリズムを導入する
38
実際には、まだまだ３つの軸の改善が必要

39. まとめ
● インターネット広告の概要について話した
○ 市場規模は2019年に2兆を超え、市場規模が増大している
○ DSP/SSPが登場し、ターゲティング広告が主流になった
○ 広告の効果を測る、代表的な指標を紹介した
○ 近年は広告の品質やプライバシーの問題に注目が集まっている
● 広告配信システムが持つパフォーマンス要件について話した
○ レスポンス
○ スループット
○ 広告在庫量
● 広告配信システムパフォーマンスへのアプローチについて話した
○ 業務アプリケーションの高速化は思った以上に大変
○ スループット量を向上させる方法
○ さばける広告在庫量を増やす方法
○ レスポンスを向上させる方法
39

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