QCon Tokyo 2014
QCon2014 My Report Top
Detail Report#5/8
ビッグデータのリアルタイム応用:ユーザー事例
安田 崇浩:ソネット・メディア・ネットワークス株式会社
技術・開発部 開発リーダー
月間600億件を処理するリアルタイム広告 Logicad
田中 聡:Glossom株式会社
アドプラットフォーム事業部開発グループ1 Blossomチーム
田村 俊明:Aerospike, Inc.
nCountry Manager, Japan
はじめに
- いままでは金融(Enterprise)→他業種
- 現在 Ad -> Enterprise にひろがっている仕組みが多くなっている
RTB (Real Time Bidding)
- 広告主が入札して、表示される
- だいたい150ms - 180ms ですべての処理が終わる
- データアクセスは、3ms 以下で終わらす
Sonet 安田さん Logicad
(logicadの仕組みの説明はぜひ下記のSlideShareをご参照！)
http://www.slideshare.net/yasuda/logicad
広告配信規模
- 600億http request / 月
- 1か月 UU １億UU
- Log 10TB
request 規模
- 24000 req / sec
- ピークは夜間 平均の倍
50000 req/sec を処理するとは、
- 4msec / req で処理できたとしても
- 250 req/sec 1 core 1coreではこれだけ
- CPU 200 core トータルで必要
- 1 server cpu 16 core のっていたとして
- 12.5 X 50%余剰 25台あれば処理できる
Little's law リトルの法則
- 待ち行列理論
- 到着率 A: 50000
- 顧客が費やす時間W : 4msec
顧客数 L = A W : 200 core, 25 server
処理時間が非常に重要（4->8 msec にふえると コストが倍）
Amdahl's Law アムダールの法則
- 複数のプロセッサを使い並列計算するばあい逐次処理がある場合あしかせになる
- 例えば5% 逐次処理がのこっていると20倍以上には高速化しない
50000 HTTP Req/sec
- 通常のLBを使うとどうしても100 micro 秒単位で処理がかかる
- やり取り先が、SSP（固定 IP ）ということもある
- AWS Route 53 weighted round robin のほうがはやい
DB traffic
IOPS
1 HTTP requestごとに2回のRead処理が必要
100,000 read / sec
- HDD IOPS: 200 IOPS -> 500 HDD
- SSD IOPS:20000 IOPS -> 5 SSD
- Memory : 1000000 IOPS
Cost
- Memory : 8 USD/GB 8000 USD
- SSD 0.5USD/GB 500USD
Distributed Hashtable(分散ハッシュ)
- KVS Sharding 時に、キーによってアクセス先のサーバーが決まる
- どこかに問い合わせる必要がない
- 0.2 ミリ秒でread している
結論：Aerospike を SSD KVS のために使っている
まとめ
- Little, Amdahls's law
- Latency を低く: 最新CPU, SSD, less GC
- 直列の部分を少なく: DNS RR, DHT, Message, Ques
- 並列性によって
- キャパシティを確保
田中さん : Glossom
経歴：
Yahoo -> Gree -> Glossom (DSP配信エンジン)
About Glossom
- 2013 11 月 インターネット広告会社
- AD Network
システム
下記の3機能のトライアングル
配信
- 広告閲覧者
集計
- 広告主
入稿ツール
- Analyst
レポートデータ
広告配信システムに求められる
- 高速レスポンス * きめ細やかな 属性配信
- Re-targeting
- Behavior targeting
- Frequency control
柔軟性確保のため、LUAを使用
言語をまたいだ関数呼び出し
- C/C->LUA
- LUA->C/C++
配信サーバーの実装ポリシー
配信フレームワークをC/C++
- リクエストのParse/Validation
- User情報の取得
- Log出力
細かいところをLuaで
- 案件データ中のターゲッティング条件を 値ではなくLUAの式をいれる
メリット
- 配信フレームワークに修正をいれない
- LUA式を書き換えることで色々柔軟な配信が可能
- 実装導入スピードが上がる
- Stored procedureとしてLuaも使える
デメリット
- 複雑度
- C++でそのまま実装するよりは工数がかかる