AdRoll: 420億件/日の取引をさばくRTBプラットフォームの計測

https://www.youtube.com/watch?v=qURhXHbxbDU&list=UUKrD_GYN3iDpG_uMmADPzJQ

1 comment | 0 points | by WazanovaNews 約4時間前 edited


Jshiike 約4時間前 edited | ▲upvoteする | link

RTB (Real-time Bidding) のテクノロジーを利用した広告リターゲッティングのプラットフォームを提供するAdRollのエンジニア、Brian TroutwineのErlang Factory 2014での講演。InfoQで紹介されてました。

前提条件

  • 1日最大420億件のトランザクション。（スライドの数値は誤りとのこと。）相当な並列処理が必要。
  • 遅延（= 取引の完了期限）は100ms以下
  • Firm real-time system（遅延すると計算結果の価値はなくなるが、システム全体にとっては深刻な状況にはならないこと。ちなみに、高度の安全性が求められる航空システムは、遅延すると計算結果の価値はなくなるだけでなく、状況によっては深刻な事態になる可能性があるので、”Hard real-time system” と呼ばれる。遅延しても計算結果の価値がなくならないケースの場合は、”soft real-time system” ）
  • グローバルで、24/7のオペレーション

大規模リアルタイムシステムでは、まれだと思われる事象の頻度が上がる可能性があり、原因をすぐに発見して対処するのは難しい。事前によくシステムを理解し、計測しないと、何をするべきで、何をするべきでないかは判断しがたい。

監視システムの導入

exometer

  • データ収集、集計、レポーティング機能をそれぞれ独立して実行できる。つまり、「今日集めたデータを後日分析/表示」のようなことが柔軟に設定できる。
  • 静的 or 動的設定が可能
  • runtimeのオーバーヘッドが相当低く、かつ予測しやすい
  • （ビデオの16:06 - 21:52で実際の設定方法の紹介をしています。）

何を見つけたいのか？

  • VMキラーの特定
  • システムパフォーマンスのリグレッション
  • 普通でないシステムの振る舞い

事例１

AdRollのRTBシステムで、タイムアウトが一定間隔で急増する事象を繰り返した。

  • システムの負荷は一定
  • ネットワークトラッフィクと実行キューは、同様に一定間隔で急増を繰り返していた。

実際に起きたのは、

  • スケジューラのスレッドはCPUにロックしていた。ログを取得するバックグランドのプロセスが20分ごとに走る設定をしていたが、gzipシステムゆえに、かなりCPUの時間を消費する仕組みであった。
  • 本番環境にCPUシールドをセットしていなかった。
  • 一つのスケジューラスレッドの処理でCPUをはじき飛ばすかたちになると、以降のリクエストを受け付けられなくなり、タイムアウトが続いた。
  • CPUシールドをセットし、VM専用のプロセスを用意して、解決した。

事例２

何のアラートもなく、広告のリクエストがほぼ終日激減

  • タイムアウトの急増は見られなかった。
  • 広告のリクエスト/入札の対比率のグラフでも事象は確認。
  • 広告交換マーケットプレースの取引量も確かに落ちていた。
  • 実行キュー、CPU、ネットワークI/Oの数値は問題なし。
  • 本番システムには何も変更をかけていないことも確認。
  • Amazon側の障害でないことも確認した。

原因は、AdRoll側で付与したIDをもとに、サードパーティのシステムとやり取りをしていたが、そのサードパーティの上限である15億件を超えてしまったため。処理できるID数に上限があるという仕組みだということを知らなかったし、サードパーティも通知してくれなかった。

あるべき姿

情報が少なすぎても、また多すぎてうまく解釈できなくても問題は起きる。

課題としては、

  • コードからデータを計測しようとすると、コード量が増える。計測できる状態にする工数がかかり、もろもろ挿入されたコードをメンテすることになる。
  • runtimeインパクトは低くても、他の箇所に影響がでるときもあり、ゼロではない。
  • 依存するライブラリは、何を計測すると有効かについては、個々異なる。

解決策

#erlang #rtb #adroll

Back