サイトに広告が表示される瞬間、内部で何が行なわれているのかご存知ですか？ 実は、『RTB』と呼ばれる広告オークションが行われているのです。 1日に20億回RTBに参加しているMicroAd BLADEは、単に落札するだけでなく高い広告効果を出す事を目的にしており、様々な大量データを参照しています。一方、タイム アウトするとオークションに参加すらできないため、処理時間も重要です。BLADEで は様々な工夫により、たった5msで入札処理を行っています。 本セッションでは、BLADEのシステム内部と、それを支える職人達についてお話しま す。

1. 5ミリ秒の中身を公開！
～ネット広告配信と支える職人たち～
株式会社マイクロアド 佐藤 由紀

2. 自己紹介
Pascal → FORTRAN → アセンブラ → C →・・・
2002年～：宇宙＆その他科学のお仕事
2010年 ：株式会社マイクロアドに入社
2011年～：システム部門の統括
Favorite：
日本の伝統を守るクールな職人さん
ペンギン
2

3. RTBって？
• RealTime Bidding
T の略。
• ネット広告配信の際、オークション形式でリアルタ
イムに表示広告を決定する仕組み。
• オークション主催 ： SSP （Supply Side Platform）
広告枠を供給する側＝サイト運営者 が利用するサービス
• オークション参加 ： DSP （Demand Side Platform）
広告枠を消費する側＝広告主 が利用するサービス
3

4. RTBの流れ
RTBリクエスト DSP A社
RTBレスポンス
SSP
¥100
DSP B社
¥30
Webユーザ
Webユーザ
4

5. リクエスト／レスポンスの例
**Request Sample** **Response Sample**
ad_width: 300 bid: 8840000
ad_height: 250 ad_code: "<a href="http://xxx..."><img
src="http://xxx..." /></a>"
spot_id: xxx
bid_id: "xxx..."
user_id: "xxxx"
targeting_type_id: 3
user_ip_address: "xxx"
advertiser_id: "xxx"
site_url: "http://xxx..."
creative_category_id: 12
referrer: "http://xxx..."
site_category_id: 1
allowed_creative_types: IMAGE
5

6. 本日のお話
• MicroAd BLADEのRTB入札処理の一部を公開
• DSPの入札処理のポイント
「適切な広告選定・入札額決定」と「高速な入札処理」
どちらも追い求める事が重要！
• MicroAd BLADEは？
大量データ参照と高度なロジックを組み込みながら、
高速な処理（5ms！！）も実現
6

7. 1.適切な広告選定・入札額決定
• どの広告を入札するべきか
• 落札/配信するだけが目的ではない。
• 成果につながらないと・・・ダメ
• いくらで入札するべきか
• 入札額上げる↑と・・・配信量：増○ コスト：高×
• 入札額下げる↓と・・・配信量：減× コスト：低○
適切な
⇒多目的最適化問題を解き、適切な金額で入札が必要
7

8. 2.高速な入札処理
＜制約条件＞
• 80ms前後のタイムアウト制約あり
• タイムアウトすると、入札に参加できない
• タイムアウトが頻発すると、ペナルティもある
• 海外SSPとのRTBでは通信だけで、～70ms
⇒入札処理に使える時間は実質10ms以下
その中で最適な広告と入札額を決める
8

9. MicroAd BLADE サービス概要
• MicroAdが開発/提供するDSP
• 2011年6月にリリース
• 5つのSSPと接続
• サービス利用広告主 4,000社を突破！
• 主な広告配信手法
• リターゲティング
• オーディエンスターゲティング
9

10. リターゲティング
広告主サイトへの再来訪を促す広告配信手法
広告主サイト訪問
成約！
再来訪 離脱
追跡
離脱ユーザが閲覧する ユーザがサイトを離れる
サイトに広告を掲載
10

11. オーディエンスターゲティング
潜在顧客をターゲットとして、広告を配信する手法
Hadoop
統計解析
広告主サイト Netezza
SPSS Modeler
訪問ユーザ
11

12. オーディエンスターゲティング
統計解析の結果・・・広告主サイトに来る人の特徴が分かる！
興味関心データ Demographics
（どういう人がどれくらい興味があるか） （性別や年代、居住地等）
12

13. オーディエンスターゲティング
どの程度、広告主サイトに興味が Demographicsを指定する
ある人たちに広告配信するか （例：40代女性）
設定に合致する行動特性を持つwebユーザを
ネット中からかき集め、その人たちに広告を配信！
13

14. BLADEのRTBレスポンス件数
25億件/日
を
99.x%を
で処理！
5msで処理！
13億件/日
4億件/日
1億件/日
2011/7 2012/1 2012/7 2013/1
14

15. RTB入札部分のシステム構成
・・・・・
RTBサーバ（約60台） RTBプログラム ログ
Kyoto Tycoon サーバ群
Retargeting Frequency
Audience 入札額算出
demographics
Targeting パラメータ
15

16. 広告選定と入札額決定
¥20
¥10
¥18 ¥25
¥5
¥21
¥25
1.広告リストアップ 3.入札額の導出
2.配信不可広告の除外 4.入札広告の決定
5ms
16

17. 入札広告と入札額の決定 ～ステップ1～
【主な参照データ】
＜広告データ＞
広告主：4,000件 ¥10 ¥20
配信設定：10,000件
¥18 ¥25
クリエイティブ：2,9000件
¥5
etc.. ¥21
¥25
＜リターゲティングデータ＞
850,000,000件
1.広告リストアップ 3.入札額の導出
＜オーディエンスターゲティングデータ＞
540,000,000件
2.配信不可広告の除外 4.入札広告の決定
＜demographicsデータ＞
680,000,000件
17

18. 入札広告と入札額の決定 ～ステップ2～
【主な参照データ】
¥20
¥10
配信NG 広告データ ¥25
¥5
¥18
10,000件
¥21
¥25
1.広告リストアップ 3.入札額の導出
2.配信不可広告の除外 4.入札広告の決定
18

19. 入札広告と入札額の決定 ～ステップ3～
【主な参照データ】 ¥20
¥10
＜Frequencyデータ＞ ¥18 ¥25
¥5
1,600,000,000件 ¥21
¥25
＜入札額算出パラメータ＞
広告枠 x 配信広告の相性
50,000,000件
etc…1.広告リストアップ 3.入札額の導出
2.配信不可広告の除外 4.入札広告の決定
19

20. 入札広告と入札額の決定 ～ステップ4～
¥20
¥10
¥18 ¥25
¥5
¥21
¥25
1.広告リストアップ 3.入札額の導出
2.配信不可広告の除外 4.入札広告の決定
20

21. ☆本題☆ 5msへの取り組み
データ参照がボトルネックになりがち
一般的なWebアプリ同様、BLADEも例外ではない
アプリケーション周りのデータ参照の工夫
1. KVS（Kyoto Tycoon）
2. レプリケーションによるローカル参照
3. キャッシュ
4. オブジェクトキャッシュ
etc…
21

22. 1．KVS（Kyoto Tycoon）の利用
KVSに向くデータ
• レコード数が多いデータ（数百万～）
• キー/バリューで参照できれば良いデータ
⇒BLADEでは主に、Webユーザごとに紐付くデータ
数億レコードでも数万QPS以上が可能！
22

23. 1.Kyoto Tycoonの負荷対応
• Step1：参照は複数台のスレーブ
⇒負荷分散と冗長化
• Step2：更新が多い場合はストレージIO高速化
⇒更新遅延よりも参照遅延が致命的なので
スレーブの高性能化が重要
• Step3：更新負荷がきつい場合はマスタ分散
⇒キーによるパーティショニング
23

24. 1.Kyoto Tycoon Java用ライブラリ
1. 公式ライブラリがない
2. memcached互換等はある。でも・・要件が合わない
↓
自作ライブラリ
• スレッドセーフ
• コネクションプーリング
• 格納するデータのシリアライズ/デシリアライズ
• キーによるパーティショニング
• バイナリプロトコル対応
24

25. 2.レプリによるローカル参照
• 参照データサイズが大きい(1k～)と通信コスト
が高くなる
↓
• データ参照するサーバ（RTBサーバ）上に
スレーブを立てて、サーバ間通信を回避
25

26. 2.レプリによるローカル参照
・・・・・
RTBサーバ RTBプログラム ログ
KT
Kyto Tycoon サーバ群 レプリケーション
Retargeting Frequency
Audience 入札額算出
demographics
Targeting パラメータ
26

27. 3.キャッシュ
使い分けが大事！
• 整合性やリアルタイム性をどの程度担保すべきか？
↓
• どうやってキャッシュするか
27

28. 3.キャッシュ
全件キャッシュ
• 容量がさほど大きくなく全件メモリに載る
• 全データがまんべんなく参照される
• マスタがRDB（MySQL）
有効期限付きLRUキャッシュ
• 容量が大きく、全件メモリに載らない
• 特定のデータだけ頻繁にアクセスされる
• マスタがKVS（Kyoto Tycoon）
28

29. 例：全件キャッシュ
広告配信データ
（配信種類／配信期間／上限入札額／バナーファイル名･･･）
キャッシュ方法
• アプリ起動時に全件ロード
• 以後、2分ごとに専用の更新スレッドで全件リロード
※入札広告決定後、最新のデータをマスタから取得
（整合性・リアルタイム性の担保）
29

30. 例：有効期限付きLRUキャッシュ
広告枠ごとのベース入札額
（枠によってリクエスト数が大幅に異なる）
キャッシュ方法
• 一定件数だけキャッシュ
• キャッシュにない場合だけKVS（マスタ）から取得
• 取得データは一定確率でキャッシュ（有効期限含む）
※稀にしか参照しないデータをキャッシュしないための工夫
• キャッシュの指定件数を超えると、最古データから削除
30

31. 4.オブジェクトキャッシュ
RTBサーバ
RTBプログラム
KVS/DBから取得し
解決！
解決！ 生成したオブジェクトを
取得データ→Object
変換コスト Javaアプリでキャッシュ
KVSサーバ DBサーバ
31

32. まとめ
• 広告配信はRTBという仕組みで行われている
• RTBは「業務ロジックの高度化」と「処理の高速化」の
両方が鍵
• MicroAd BLADEはどちらも最高のクオリティを目指し、日
々様々な工夫を続けている
32

33. もっと話したかったこと
少数精鋭
• RTB入札アプリケーションの設計・開発・運用を3名のエンジニアで
担当
• 10万リクエスト/秒のネットワークと700台の物理サーバの設計・構築・運用を
3名のインフラエンジニアで担当
なぞな職人たち
• 信号機システムの研究開発をしていた職人
• 南の島でネットワーク構築と素潜り？ばっかりしていた職人
• 宇宙物理学の博士号を持っている職人
• 暗闇で戦闘機を発見できる職人
33

34. ACTION！
職人魂で
エッジの効いたモノづくりを
していきましょう。
34

35. ACTION！への想い
動けばいい。
無駄なんて気にするな。
サーバを足しておけばいいじゃない。
そんなのクールじゃないっ！
伝統職人の皆さんに鼻で笑われちゃいますよ・・・
35

36. ACTION！
職人魂で、
エッジの効いたモノづくりを
していきましょう。
36

37. ご清聴ありがとうございました。
株式会社マイクロアド 佐藤 由紀
37