2020/09/05 - サマーオンライン勉強会 資料① アドテクを支える技術～広告配信システムに課せられた100msの制約～ https://hrmos.co/pages/microad/jobs/0000083

1. インターネット広告の
概要とシステム設計
株式会社マイクロアド
松宮 康二 (まっつー)
エンジニア夏オンライン勉強会

2. 自己紹介
● 名前: 松宮 康二(まっつー)
● 役職: シニアエンジニア DSP担当
● 最近触ってるもの
● 最近の趣味: キャンプ
● ちょっと前の趣味: ラーメン作り
● Twitter: @mattsu6666
2

3. もくじ
● インターネット広告とは
○ インターネット広告の市場規模
○ ターゲティング広告
○ DSP/SSPへの変遷
○ 広告の指標
○ 広告の品質維持
○ プライバシーの問題
● 広告配信システムの宿命
○ 100msの制約
○ 1つのエンドポイントに全ての機能が詰まっている
○ 増え続ける広告在庫
○ 増え続けるリクエスト
○ まとめると
○ 業務課題に対するアプローチとキーワード
● なぜScala, DDD, Akkaなのか
○ Scala
○ なぜScalaなのか
○ 関数型言語はなぜシンプルなのか
○ ポリモーフィズムが重要な理由
○ DDD
○ ドメインモデルをピュアにすべきな理由
○ 巨大なモノリシックなアプリのメンテナビリティ
○ Akka
○ アクターモデル
○ スループットではなくレイテンシを高める
○ なぜScala, DDD, Akkaなのか
● まとめ
3

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

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

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

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

8. 広告の指標
● 広告は様々な指標を使って効果を測定している
● 代表的な指標
○ インプレッション数: 広告を表示した回数
○ ビューアブルインプレッション数: 広告を表示して、ユーザが実際に見た回数
○ クリック数: 広告をクリックした回数
○ コンバージョン数: 商品の購入、サブスク、資料請求、アプリインストール、会員登録等の行動
○ インプレッション単価 (CPM: Cost per Mille): 1000回あたりのインプレッション単価
○ クリック率 (CTR: Click Through Rate): インプレッションのうちクリックした率
○ クリック単価 (CPC: Cost per Click): 1クリックあたりの単価
○ コンバージョン率 (CVR: Conversion Rate): クリックしてコンバージョンまで行った率
○ コンバージョン単価 (CPA: Cost per Acquisition): コンバージョンあたりの単価
8
CTR低いですね。目標CPCを引き上げて様子見てみましょう。
インプレッションは出てますが、ビューアブルインプレッションは全く計測されませんね。
アドフラウド(広告詐欺)かも知れません。
予算10万円で100CPMなので100万インプレッションですね。ブランディング目的としてはい
い調子です。
利用例
運用担当
開発担当
営業担当

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

10. プライバシーの問題
● ターゲティング広告ではユーザのトラッキングが重要
● しかし、世の流れ的にはターゲティング広告は規制の対象になり始めている
● EUでは一般データ保護規則(GDPR)が2018年5月に施行
○ 日本の企業でも欧州圏のユーザをトラッキングすると罰則
○ 加えて、eプライバシー規則が新たに審議されている
● SafariではITP(Intelligent Tracking Prevention)によってサードパーティクッキーをブロック
● Googleが推進するPrivacy Sandboxによってクッキーの代替案が提案
● 改正個人情報保護法が2020年6月に成立。2022年6月までに施行予定
○ ユーザのトラッキングに同意が必要になる
● 今後は「プライバシーテック」が流行るような気がしている (個人的見解)
10
Webページ
計測
タグ
Webページ
計測
タグ
計測
サーバ
Webページを横断して計測
(Cookieを利用)
DSPDB
永続化 RTB時に参照
Cookieを利用した
トラッキング

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

12. 12
広告配信システムの宿命

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

14. 1つのエンドポイントに全ての機能が詰まっている
● 一般的なWebアプリ等と異なり、エンドポイントはSSP毎に1つだけ
○ 設計次第だがマイクロアドではSSP毎にエンドポイントを分けている
○ 1つのAPIに対して機能追加し続けるイメージ
● ビジネスのスケールとともに機能は増え続ける
● 機能が増えても100msの制約は不変
● しかし機能追加は避けては通れない
14
機能追加は業務を継続する必要条件
SSP A
DSP
入札要求
POST /rtb/a
SSP B
入札要求
POST /rtb/b
SSP C
入札要求
POST /rtb/c
位置情報を使う機能
ユーザの性別とか判定する機能
ユーザと似たユーザを検索する機能
行動履歴を使う機能
ブラックリストユーザ判定機能
ヽ(・ω・ヽ*) PDM
オフライン購買データを使う機能
新機能追加して！
RTBの内部処理
・・・
機能追加をすればする程、RTBの内部処理は
複雑かつ高負荷になっていく。

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

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

17. まとめると
● 100msの制約を守ることは業務が成立する必要条件
● 機能追加は業務を継続する必要条件
● 多くの広告在庫を扱えることは業務が成立する十分条件
● 大量のリクエストが捌けることは業務が成立する十分条件
17
このようなアドテク特有の課題をどうやってクリアするか？
100msの制約
機能追加
多くの広告在庫を扱える 大量のリクエストが捌ける
業務

18. 業務課題に対するアプローチとキーワード
● プログラミング言語にScalaを採用
○ 関数型プログラミング
○ オブジェクト指向プログラミング
○ JVM言語
● ソフトウェアの設計手法にドメイン駆動設計(DDD)を採用
○ 3層 + ドメインアーキテクチャ
○ ドメインモデル
○ ユビキタス言語
● 主要なフレームワーク・ツールキットにAkkaを採用
○ 並行並列処理
○ リアクティブシステム
○ アクターモデル
18
次のスライドから詳細な説明をしていきます

19. 19
なぜScala, DDD, Akkaなのか

20. Scala
● JVM言語の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なのか
● 関数型言語の特徴を持っており、シンプルに記述できる
○ イミュータブル
○ 副作用を発生させづらい構文(例えばif文ではなくif式)
○ nullを発生させないデータ構造
● オブジェクト指向言語の特徴を持っており、DDDとの相性が良い
○ ポリモーフィズム(最も重要！) ※後述
○ カプセル化
○ 継承
● JVM言語の安心感
○ 十分な実績を持つJavaとの互換性
○ JVM上で動作するため、Javaに近い性能を期待できる
○ コンパイル言語なので、型安全による安心感
21

22. 関数型言語はなぜシンプルなのか
● 関数型プログラミングは純粋関数だけを使う
○ 純粋関数とは副作用がない関数
● 副作用とは関数内で副次的に発生するアクション
○ グローバル変数に再代入する
○ データベースを参照・更新する
○ I/O
○ 例外を投げる等
● 純粋関数は入力に対して必ず同じ出力がある
● システムの状態に依存しないので...
○ 頭の中で状態を追いながら読まなく良い
○ テストコードが書きやすい
22
class Auth {
public void auth(Token token) {
token.set(getAuth())
}
}
副作用があるケース(コードはJava)
class Auth {
def auth(token: Token): Token = {
token.copy(getAuth())
}
}
副作用がないケース
返り値(結果型)がvoidかTokenの違いがある
副作用があるケースは「 tokenを更新」
副作用がないケースは「 tokenを新規作成」

23. ポリモーフィズムが重要な理由
● ポリモーフィズム(多態性)はインタフェースに実装できる性質
○ オブジェクト指向以前もポリモーフィズムは可能だったが、言語レベルで安全に実装できるようになった (だからこそ重要)
● インタフェースによってプログラムをより抽象的・汎用的に記述できる
○ 例えばUNIXのIOデバイスドライバはopen, close, read, write, seekの標準機能を提供する
○ もしインタフェースが統一されていなかったら、デバイス依存のコードになり用途が限られる
● インタフェース同士が依存し合うことで高いモジュール性・疎結合性を得る
● ポリモーフィズムによって、ソースコードの依存関係を絶対的に制御(※後述)
23
モジュール同士が抽象に依存
具象クラスを自由に付け替えられる => 疎結合
UNIXはデータの入出力をファイルとして扱う => デバイス非依存

24. DDD
● DDD(ドメイン駆動設計)はソフトウェア設計手法のこと
○ 技術では無く、ドメイン知識(業務知識)を中心に考える
● 事業価値を最大化することが我々の究極の目標
● しかし実際には...
○ ドメインエキスパート(PDMなどドメインに詳しい人)は事業価値の向上に注力
○ エンジニアは業務上の問題を技術的に解決しようとする
○ エンジニアによって翻訳されたソフトウェアになってしまう
○ 両者のコミュニケーションの相違が起こってしまう
● DDDはドメインエキスパートとエンジニアが共通認識(ユビキタス言語)を
持ったソフトウェアを作る(コードがドメインモデルを反映)
24
(・ω・*) PDM
「広告」には「画像」とか「動画」とかの種類があるんだよ
なぁ。
「広告主」がどっちか選んで「 登録」するんだよねぇ
エンジニア (,,ﾟДﾟ)
画像とか動画とかいってもフォーマット色々あるし、「 JPEG
広告」「PNG広告」「MP4広告」みたいな感じで実装すっか。
生成ロジックを統一したいし、「 ユーザ」が「広告ジェネレー
タ」を使って「生成」するようにしよっと。
下の会話では両者が違う言葉を使っている。
この状況が続くと、両者の認識のズレは拡大し、いつかプロ
グラムの修正が困難な状況に陥る可能性が高い

25. ドメインモデルをピュアにすべきな理由
● ドメインモデルは何にも依存させるべきではない(ピュアにすべき)
● さらに、ビジネスルールは技術的関心事に左右されるべきではない
● ビジネスルールとはドメインモデルの構成要素
○ "Business rules describe the operations, definitions and constraints that apply to an organization. Business rules can apply to people,
processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals."
○ つまり、ビジネス活動の中で意思決定を行うための規則
○ 個人的には、コンピュータが消滅しても失われないルールのことだと思ってる
○ 僕らが一番守りたいのはビジネスルール
25
※広告の例だと
分かりづらかっ
たので
お店を例にしま
した
ECサイト ~インターネット時代~商品を買う例
お店 ~近代~ お店 ~昔~
● 合計の求め方
● 小計の求め方
● 消費税の求め方
などは「会計システム」「POSシステ
ム」「そろばん」(技術的関心事)に左
右されるべきじゃない！
引用: https://en.wikipedia.org/wiki/Business_rule

26. 巨大なモノリシックなアプリのメンテナビリティ
● 広告配信システムは非機能要件的にどうしてもモノリシックな一枚岩に
● 一枚岩故にドメインはめちゃくちゃ複雑
● 一枚岩なのに色んなシステムと接続しまくる
● 何も考えずに作ったらメンテナビリティは容易に悪化
● DDDを取り入れ多層アーキテクチャによってドメインモデルを保護
● レイヤーの依存関係を厳格にし、影響範囲の局所化と明確化
26
プレゼンテーション層
データソース層
アプリケーション層 ドメイン層
A
B
AはBに依存している
HTTPやRPCなどの入力の
インタフェースを担当
ユースケースを担当
(ビジネスロジック)
DB接続周り担当
ビジネスルール担当
(ドメインモデル)

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

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

29. スループットではなくレイテンシを高める
● アクターモデルによって、並行並列処理が安全に実装可能
● スレッドでは実現出来なかったスケールアウトも可能
● アクターによって処理を細かい単位で分離するので、局所的にスケール可能
● よって、Akkaを採用することにした
● しかし・・・良いことばかりではない
○ 高い学習コスト
○ アプリケーションの性質上、コアなロジックはアクターによるスケールアウトが難しい(通信コストが無視出来ない)
○ まだ発展途上のOSSのため、バージョン上がるとガッツリAPIが変わってる
● スループットは変わらないが、レイテンシは高めたい(アクターモデルの恩恵を享受)
○ 全体をそれなりに早くではなく、1リクエスト辺りの応答速度を高めたい
○ 大量のリクエストを満遍なくタイムアウトさせるより、少量のリクエストを確実に返せた方が良い
○ そのためにはアクターモデルを活用した並行並列処理が使いやすい
29
リクエスト1の処理
リクエスト2の処理
リクエスト1の処
理
リクエスト1の処
理
リクエスト2の処
理
リクエスト2の処
理
スレッド1
スレッド2
200ms
スレッド1
スレッド2
200ms
200msでどちらも2件のリクエストを
捌いた。
しかし、左は200msかかってしまっ
てタイムアウトになった
一方で右は100msで応答したので
入札できた
広告配信システムでは100msの制
約があるのでタイムアウト！
超理想の話なので実際にはこんな
綺麗に並列化は難しい

30. なぜScala, DDD, Akkaなのか
● Scala
○ オブジェクト指向、関数型のメリットを享受できる
○ JVM上で動作するので性能面での安心感
○ 強力な型システムによって規模の拡大が原因でメンテナビリティが低下しづらい等
● DDD
○ 複雑なドメインに立ち向かう手段
○ ビジネスルールに集中でき、事業価値を高めやすい
○ Scalaと相性が良い(オブジェクト指向との相性が良い)
● Akka
○ 並行並列処理、分散処理を安全に実装できる
○ 様々な便利なコンポーネントが使える
30

31. まとめ
● インターネット広告の概要について話した
○ 市場規模は2019年に2兆を超え、益々注目を浴びている
○ DSP/SSPが登場し、ターゲティング広告が主流になった
○ 広告の効果を測る、代表的な指標を紹介した
○ 近年は広告の品質やプライバシーの問題に注目が集まっている
● 広告配信システムが持つ特殊な要件を話した
○ 100msの絶対的な制約があり、それを満たしたシステム設計を求められる
● 広告配信システムを実現するために使用した技術の説明をした
○ Scala, DDD, Akkaを取り上げ、システム設計の一部を紹介した
○ Scalaは関数型、オブジェクト指向型であり、大規模な開発に耐えうる言語であった
○ DDDを導入することで、複雑な仕様のシステムにおけるメンテナビリティの向上に努めている
○ Akkaを利用することで、コアなロジックを簡潔に保つような設計にしている
31

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

33. 参考文献
● 必携 インターネット広告
● Scalaスケーラブルプログラミング第3版
● Scala関数型デザイン&プログラミング―Scalazコントリビューターによる関
数型徹底ガイド
● Clean Architecture 達人に学ぶソフトウェアの構造と設計
● 実践ドメイン駆動設計
● Akka実践バイブル アクターモデルによる並行・分散システムの実現
● 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向
の実践技法
33