Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo

3,697 views

Published on

QCon Tokyo 2014 にて発表した資料です。http://qcontokyo.com/

Published in: Technology
  • Be the first to comment

秒間5万リクエストを処理する リアルタイム広告システム / BS3-3 新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 #QConTokyo

  1. 1. 秒間5万リクエストを処理する リアルタイム広告システム BS3-3新しい潮流:ビッグデータのリアルタイム応用:ユーザ事例 ソネット・メディア・ネットワークス株式会社 安田 崇浩 April 30, 2014 QCon TOKYO 2014
  2. 2. 自己紹介 氏名: 安田 崇浩 所属: ソネット・メディア・ネットワークス株式会社 2008年くらいからクラウド を仕事で活用 2010年くらいからインターネット広告システムを開発 2012年くらいからRTBシステムを開発
  3. 3. DSPプラットフォーム『 Logicad』 大規模な配信ログ、オーディエンスデータを高速かつ安定 的に処理することが可能なシステムインフラを備え、独自 のアルゴリズムを用い、RTBにも対応した自社開発の広告 配信最適化プラットフォーム www.logicad.com
  4. 4. 広告配信システム規模 1ヶ月の処理量: 600億httprequest/月 1ヶ月のUU数: 1億UU 1ヶ月のログ量(圧縮): 10TB データベースのユーザー数: 4億
  5. 5. 600億http request/月 ? 24,000 req/ sec ピークは平均の2倍 50,000 req/ sec サーバーは何台必要か?
  6. 6. 50,000 req / sec の処理を考える 処理時間: 4ミリ秒/ req 1 CPU Coreあたり:250 req /sec 必要なCPU数:50,000 req/ 250 req = 200 Core 1 サーバーのCPU数:16Core 必要なサーバー数: 200 Core/ 16 =12.5 server 50%の余剰: 12.5server / 50% =25Server
  7. 7. もし処理時間が倍だったら? 処理時間: 8 ミリ秒/ req 1 CPU Coreあたり:125 req /sec 必要なCPU数:50,000 req/ 125 req = 400 Core 1 サーバーのCPU数:16Core 必要なサーバー数: 400 Core/ 16 =25server 50%の余剰: 25 server /50%= 50 Server 倍のサーバー台数が必要
  8. 8. リトルの法則 Little's Law 待ち行列理論 到着率λ 顧客が費やす時間 W 顧客数L = λxW fromwikipedia
  9. 9. リトルの法則 Little's Law 小売店での例 到着率λ 顧客が一時間当たり 10 人到着 :10人/ hour 顧客が費やす時間 W 0.5時間店内に滞在: 0.5 hour 顧客数L= λ xW 10人/hour x0.5hour= 5 人(平均的な店内の顧客数)
  10. 10. リトルの法則 Little's Law システムでの例 到着率λ 50,000 req/sec 顧客が費やす時間 W 4 ミリ秒/req/Core 顧客数L= λ xW 50,000 req/secx 0.004sec/req/Core= 200 Core 200Core /16 Core/server / 50% = 25Server
  11. 11. 処理時間Latencyが重要 処理時間が4ミリ増加するだけで、 サーバー数が2倍 コスト2倍 なるべくLatencyを低くする
  12. 12. 処理時間Latencyを低くできない/増加した場合 サーバーを横に並べて、キャパシティを確保 Scale Out
  13. 13. RTB 広告配信システム構成
  14. 14. 十分なサーバー数を並べれば良いか?
  15. 15. アムダールの法則 Amdahl's Law 複数のプロセッサを使い並列計算によってプログラムの高 速化を図る場合 そのプログラムの中で逐次的に実行しなければならない部 分の時間によって高速化が制限される fromwikipedia
  16. 16. アムダールの法則 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 Speedup 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 Number of Processors Amdahl’s Law Parallel Portion 50% 75% 90% 95% プログラムの95%を並列化しても どれだけCPU数を増やしても20倍以上には高速化しない 少しの直列部分が性能に大きく影響 なるべく直列部分を減らす
  17. 17. 50,000 HTTP req/sec
  18. 18. 50,000 HTTP req/sec LoadBalancer を配置 LoadBalancer の可用性? LoadBalancer のScale Out ? 100マイクロ秒でも速くしたい
  19. 19. 50,000 HTTP req/sec DNSRound Robin 方式 AWSRoute53Weighted Round Robin サーバーダウン時にはAPIで DNSを書換えTTL=60sec LoadBalancer のオーバーヘッドなし サーバー追加でScale Out
  20. 20. 100,000 read / sec 1 HTTP reqest ごとに 2回のread 処理
  21. 21. 100,000 read / sec HDDの IOPS: 200 IOPS 100,000IOPS =200IOPS x500HDD ! 10 HDD/server -> 50 server !
  22. 22. 100,000 read / sec SSDの IOPS: 20,000 IOPS 100,000IOPS =20,000IOPS x5 SSD !
  23. 23. 100,000 read / sec Memory の IOPS :1,000,000+ IOPS Cost/ GB Memory : 8USD/GB,8,000 USD/TB SSD: 0.5 USD/GB, 500USD/TB http://www.jcmit.com/
  24. 24. 100,000 read / sec
  25. 25. 100,000 read / sec DistributedHash Table
  26. 26. 100,000 read / sec DistributedHash Table キーによってアクセス先のサーバーが決まる 0.2ミリ秒/ read www.aerospike.com
  27. 27. 50,000 req/sec を処理するために リトルの法則 Little'sLaw アムダールの法則 Amdahl's Law 限界までLatencyを低く 最新CPU, SSD,micro Benchmark,less GC 直列の部分を少なくし DNSRR,DHT, MessagingQueue 並列性によって キャパシティを確保
  28. 28. ありがとうございました www.logicad.com

×