秒間5万リクエストを処理するリアルタイム広告システム

BS3-3 新しい潮流：ビッグデータのリアルタイム応用：ユーザ事例

ソネット・メディア・ネットワークス株式会社

安田　崇浩

April 30, 2014

QCon TOKYO 2014

自己紹介氏名: 安田 崇浩所属: ソネット・メディア・ネットワークス株式会社2008年くらいから クラウド を仕事で活用2010年くらいから インターネット広告システムを開発2012年くらいから RTB システムを開発

DSPプラットフォーム『 Logicad 』大規模な配信ログ、オーディエンスデータを高速かつ安定的に処理することが可能なシステムインフラを備え、独自のアルゴリズムを用い、RTBにも対応した自社開発の広告配信最適化プラットフォーム

www.logicad.com

広告配信システム規模

1ヶ月の処理量: 600億 http request/月1ヶ月のUU数: 1億UU1ヶ月のログ量(圧縮): 10TBデータベースのユーザー数: 4億

600億 http request/月 ?24,000 req / secピークは平均の2倍50,000 req / secサーバーは何台必要か？

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

もし処理時間が倍だったら？

処理時間: 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

倍のサーバー台数が必要

リトルの法則 Little's Law

待ち行列理論到着率λ顧客が費やす時間 W顧客数 L = λ x W

from wikipedia

リトルの法則 Little's Law

小売店での例到着率λ

顧客が一時間当たり 10 人到着 : 10人 / hour

顧客が費やす時間 W0.5 時間店内に滞在 : 0.5 hour

顧客数 L= λ x W10人/hour x 0.5 hour= 5 人 (平均的な店内の顧客数)

リトルの法則 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

処理時間 Latency が重要処理時間が4ミリ増加するだけで、サーバー数が2倍コスト 2倍なるべく Latency を低くする

処理時間 Latency を低くできない/増加した場合サーバーを横に並べて、キャパシティを確保Scale Out

RTB 広告配信システム構成

十分なサーバー数を並べれば良いか？

アムダールの法則 Amdahl's Law

複数のプロセッサを使い並列計算によってプログラムの高速化を図る場合そのプログラムの中で逐次的に実行しなければならない部分の時間によって高速化が制限される

from wikipedia

アムダールの法則 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倍以上には高速化しない少しの直列部分が性能に大きく影響なるべく直列部分を減らす

50,000 HTTP req/sec

50,000 HTTP req/sec

Load Balancer を配置Load Balancer の可用性 ?Load Balancer のScale Out ?100 マイクロ秒でも速くしたい

50,000 HTTP req/sec

DNS Round Robin 方式AWS Route53 Weighted Round Robinサーバーダウン時には API で DNS を書換え TTL=60 secLoad Balancer のオーバーヘッドなしサーバー追加で Scale Out

100,000 read / sec

1 HTTP reqest ごとに 2回の read 処理

100,000 read / sec

HDD の IOPS : 200 IOPS100,000 IOPS = 200 IOPS x 500 HDD !10 HDD/server -> 50 server !

100,000 read / sec

SSD の IOPS : 20,000 IOPS100,000 IOPS = 20,000 IOPS x 5 SSD !

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/

100,000 read / sec

100,000 read / sec

Distributed Hash Table

100,000 read / sec

Distributed Hash Tableキーによってアクセス先のサーバーが決まる0.2 ミリ秒 / readwww.aerospike.com

50,000 req/sec を処理するために

リトルの法則 Little's Lawアムダールの法則 Amdahl's Law限界まで Latency を低く

最新CPU, SSD, micro Benchmark, less GC直列の部分を少なくし

DNS RR, DHT, Messaging Queue並列性によってキャパシティを確保

ありがとうございました

www.logicad.com