秒間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億UU 1ヶ月のログ量(圧縮): 10TB データベースのユーザー数: 4億 600億 http request/月 ? 24,000 req / sec ピークは平均の2倍 50,000 req / sec サーバーは何台必要か？ 50,000 req / sec の処理を考える 処理時間: 4 ミリ秒 / req 1 CPU Core あたり: 250 req / sec 必要な CPU 数: 50,000 req / 250 req = 200 Core 1 サーバーの CPU 数 : 16 Core 必要なサーバー数: 200 Core / 16 = 12.5 server 50% の余剰 : 12.5 server / 50% = 25 Server もし処理時間が倍だったら？ 処理時間: 8 ミリ秒 / req 1 CPU Core あたり: 125 req / sec 必要な CPU 数: 50,000 req / 125 req = 400 Core 1 サーバーの CPU 数 : 16 Core 必要なサーバー数: 400 Core / 16 = 25 server 50% の余剰 : 25 server / 50% = 50 Server 倍のサーバー台数が必要 リトルの法則 Little's Law 待ち行列理論 到着率λ 顧客が費やす時間 W 顧客数 L = λ x W from wikipedia リトルの法則 Little's Law 小売店での例 到着率λ 顧客が一時間当たり 10 人到着 : 10人 / hour 顧客が費やす時間 W 0.5 時間店内に滞在 : 0.5 hour 顧客数 L= λ x W 10人/hour x 0.5 hour= 5 人 (平均的な店内の顧客数) リトルの法則 Little's Law システムでの例 到着率λ 50,000 req/sec 顧客が費やす時間 W 4 ミリ秒/req/Core 顧客数 L= λ x W 50,000 req/sec x 0.004 sec/req/Core = 200 Core 200 Core / 16 Core/server / 50% = 25 Server 処理時間 Latency が重要 処理時間が4ミリ増加するだけで、 サーバー数が2倍 コスト 2倍 なるべく Latency を低くする 処理時間 Latency を低くできない/増加した場合 サーバーを横に並べて、キャパシティを確保 Scale Out RTB 広告配信システム構成 十分なサーバー数を並べれば良いか？ アムダールの法則 Amdahl's Law 複数のプロセッサを使い並列計算によってプログラムの高 速化を図る場合 そのプログラムの中で逐次的に実行しなければならない部 分の時間によって高速化が制限される from wikipedia アムダールの法則 Amdahl's Law Amdahl’s Law 20.00 18.00 Parallel Portion 50% 75% 90% 95% 16.00 14.00 Speedup 12.00 10.00 8.00 6.00 4.00 65536 32768 16384 8192 4096 2048 1024 512 256 64 32 16 8 4 2 1 0.00 128 2.00 Number of Processors プログラムの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 sec Load Balancer のオーバーヘッドなし サーバー追加で Scale Out 100,000 read / sec 1 HTTP reqest ごとに 2回の read 処理 100,000 read / sec HDD の IOPS : 200 IOPS 100,000 IOPS = 200 IOPS x 500 HDD ! 10 HDD/server -> 50 server ! 100,000 read / sec SSD の IOPS : 20,000 IOPS 100,000 IOPS = 20,000 IOPS x 5 SSD ! 100,000 read / sec Memory の IOPS : 1,000,000+ IOPS Cost / GB Memory : 8 USD/GB, 8,000 USD/TB SSD : 0.5 USD/GB, 500 USD/TB http://www.jcmit.com/ 100,000 read / sec 100,000 read / sec Distributed Hash Table 100,000 read / sec Distributed Hash Table キーによってアクセス先のサーバーが決まる 0.2 ミリ秒 / read www.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
© Copyright 2024 ExpyDoc
