秒間5万リクエストを処理する リアルタイム広告システム / BS3-3...
-
Upload
takahiro-yasuda -
Category
Technology
-
view
2.022 -
download
7
description
Transcript of 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3...
![Page 1: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/1.jpg)
秒間5万リクエストを処理するリアルタイム広告システム
BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例
ソネット・メディア・ネットワークス株式会社
安田 崇浩
April 30, 2014
QCon TOKYO 2014
![Page 2: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/2.jpg)
自己紹介氏名: 安田 崇浩所属: ソネット・メディア・ネットワークス株式会社2008年くらいから クラウド を仕事で活用2010年くらいから インターネット広告システムを開発2012年くらいから RTB システムを開発
![Page 3: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/3.jpg)
DSPプラットフォーム『 Logicad 』大規模な配信ログ、オーディエンスデータを高速かつ安定的に処理することが可能なシステムインフラを備え、独自のアルゴリズムを用い、RTBにも対応した自社開発の広告配信最適化プラットフォーム
www.logicad.com
![Page 4: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/4.jpg)
広告配信システム規模
1ヶ月の処理量: 600億 http request/月1ヶ月のUU数: 1億UU1ヶ月のログ量(圧縮): 10TBデータベースのユーザー数: 4億
![Page 5: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/5.jpg)
600億 http request/月 ?24,000 req / secピークは平均の2倍50,000 req / secサーバーは何台必要か?
![Page 6: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/6.jpg)
50,000 req / sec の処理を考える
処理時間: 4 ミリ秒 / req1 CPU Core あたり: 250 req / sec必要な CPU 数: 50,000 req / 250 req = 200 Core1 サーバーの CPU 数 : 16 Core必要なサーバー数: 200 Core / 16 = 12.5 server50% の余剰 : 12.5 server / 50% = 25 Server
![Page 7: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/7.jpg)
もし処理時間が倍だったら?
処理時間: 8 ミリ秒 / req1 CPU Core あたり: 125 req / sec必要な CPU 数: 50,000 req / 125 req = 400 Core1 サーバーの CPU 数 : 16 Core必要なサーバー数: 400 Core / 16 = 25 server50% の余剰 : 25 server / 50% = 50 Server
倍のサーバー台数が必要
![Page 8: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/8.jpg)
リトルの法則 Little's Law
待ち行列理論到着率λ顧客が費やす時間 W顧客数 L = λ x W
from wikipedia
![Page 9: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/9.jpg)
リトルの法則 Little's Law
小売店での例到着率λ
顧客が一時間当たり 10 人到着 : 10人 / hour
顧客が費やす時間 W0.5 時間店内に滞在 : 0.5 hour
顧客数 L= λ x W10人/hour x 0.5 hour= 5 人 (平均的な店内の顧客数)
![Page 10: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/10.jpg)
リトルの法則 Little's Law
システムでの例到着率λ
50,000 req/sec
顧客が費やす時間 W4 ミリ秒/req/Core
顧客数 L= λ x W50,000 req/sec x 0.004 sec/req/Core = 200 Core200 Core / 16 Core/server / 50% = 25 Server
![Page 11: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/11.jpg)
処理時間 Latency が重要処理時間が4ミリ増加するだけで、サーバー数が2倍コスト 2倍なるべく Latency を低くする
![Page 12: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/12.jpg)
処理時間 Latency を低くできない/増加した場合サーバーを横に並べて、キャパシティを確保Scale Out
![Page 13: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/13.jpg)
RTB 広告配信システム構成
![Page 14: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/14.jpg)
十分なサーバー数を並べれば良いか?
![Page 15: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/15.jpg)
アムダールの法則 Amdahl's Law
複数のプロセッサを使い並列計算によってプログラムの高速化を図る場合そのプログラムの中で逐次的に実行しなければならない部分の時間によって高速化が制限される
from wikipedia
![Page 16: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/16.jpg)
アムダールの法則 Amdahl's Law
20.00
18.00
16.00
14.00
12.00
10.00
8.00
6.00
4.00
2.00
0.00
Sp
ee
du
p
1
2
4
8
16
32
64
12
8
25
6
51
2
10
24
20
48
40
96
81
92
16
38
4
32
76
8
65
53
6
Number of Processors
Amdahl’s Law
Parallel Portion
50%
75%
90%
95%
プログラムの95%を並列化してもどれだけCPU数を増やしても20倍以上には高速化しない少しの直列部分が性能に大きく影響なるべく直列部分を減らす
![Page 17: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/17.jpg)
50,000 HTTP req/sec
![Page 18: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/18.jpg)
50,000 HTTP req/sec
Load Balancer を配置Load Balancer の可用性 ?Load Balancer のScale Out ?100 マイクロ秒でも速くしたい
![Page 19: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/19.jpg)
50,000 HTTP req/sec
DNS Round Robin 方式AWS Route53 Weighted Round Robinサーバーダウン時には API で DNS を書換え TTL=60 secLoad Balancer のオーバーヘッドなしサーバー追加で Scale Out
![Page 20: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/20.jpg)
100,000 read / sec
1 HTTP reqest ごとに 2回の read 処理
![Page 21: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/21.jpg)
100,000 read / sec
HDD の IOPS : 200 IOPS100,000 IOPS = 200 IOPS x 500 HDD !10 HDD/server -> 50 server !
![Page 22: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/22.jpg)
100,000 read / sec
SSD の IOPS : 20,000 IOPS100,000 IOPS = 20,000 IOPS x 5 SSD !
![Page 23: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/23.jpg)
100,000 read / sec
Memory の IOPS : 1,000,000+ IOPSCost / GB
Memory : 8 USD/GB, 8,000 USD/TBSSD : 0.5 USD/GB, 500 USD/TBhttp://www.jcmit.com/
![Page 24: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/24.jpg)
100,000 read / sec
![Page 25: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/25.jpg)
100,000 read / sec
Distributed Hash Table
![Page 26: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/26.jpg)
100,000 read / sec
Distributed Hash Tableキーによってアクセス先のサーバーが決まる0.2 ミリ秒 / readwww.aerospike.com
![Page 27: 秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo](https://reader036.fdocuments.net/reader036/viewer/2022062418/5565fa88d8b42a20158b53dc/html5/thumbnails/27.jpg)
50,000 req/sec を処理するために
リトルの法則 Little's Lawアムダールの法則 Amdahl's Law限界まで Latency を低く
最新CPU, SSD, micro Benchmark, less GC直列の部分を少なくし
DNS RR, DHT, Messaging Queue並列性によってキャパシティを確保