Agile Cat — in the cloud

Facebook における 1300万/秒 クエリーの秘密

Posted in Big Data, Facebook by Agile Cat on November 28, 2010

Facebook At 13 Million Queries Per Second Recommends: Minimize Request Variance
THURSDAY, NOVEMBER 4, 2010 AT 8:48AM
http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html

highscalability

Facebook gave a MySQL Tech Talk where they talked about many things MySQL, but one of the more subtle and interesting points was their focus on controlling the variance of request response times and not just worrying about maximizing queries per second.

Facebook は MySQL Tech Talk において、同社におけるMySQL への取り組みを詳述したが、その中でも微妙で興味深いポイントは、リクエスト・レスポンス・タイムのバラつきを制御することへの注力であり、毎秒のクエリー数を最大にすることが関心事ではないことだった。

e468f100-b468-4cfe-91da-bbb1f19bbd46[4]

But first the scalability porn. Facebook’s OLTP performance numbers were as usual, quite dramatic:

しかし、最初に言っておくが、そのスケーラビリティは普通ではない。 Facebook における OLTP のパフォーマンス値は、いつものとおり、きわめてドラマチックである:

  • Query response times: 4ms reads, 5ms writes.
  • Rows read per second: 450M peak
  • Network bytes per second: 38GB peak
  • Queries per second: 13M peak
  • Rows changed per second: 3.5M peak
  • InnoDB disk ops per second: 5.2M peak
  • クエリー・レスポンス・タイムは、4ms reads, 5ms writes
  • Row の読み込みは、最速で  450M/sec
  • ネットワーク速度は、最速で 38GB/sec
  • クエリー数は、最速で 13M/sec
  • Row 変更は、最速で  3.5M/sec
  • InnoDB disk ops は、最速で  5.25M/sec

Some thoughts on creating quality, not quantity:

  • They don’t care about average response times, instead, they want to minimize variance. Every click must be responded to quickly. The quality of service for each request matters.
  • It’s OK if a query is slow as long as it is always slow.
  • They don’t try to get the highest queries per second out of each machine. What is important is that the edge cases are not the bad.
  • They figure out why the response time for the worst query is bad and then fix it.
  • The performance community is often focussed on getting the highest queries per second. It’s about making sure they have the best mix of IOPs available, cache size, and space.
  • 彼らは、平均レスポンス・タムを気にかけないが、その代わりに、時間のバラつきを最小化したいと望む。 すべてのクリックに対して、素早いレスポンスが要求される。 それぞれのリクエストに対する、サービス品質が重視される。
  • すべてのクエリーが遅い場合には、それは、それで、OK である。
  • 彼らは、それぞれのマシンから、毎秒あたり最大のクエリーを得ようとしない。 重要なことは、余裕のある状況を悪化させないことだ。
  • 彼らは、最悪のクエリー・タイムが生じる理由を理解した後に、それを修正する。
  • パフォーマンス・コミュニティは、毎秒あたり最高のクエリーを得るようにフォーカスさせられる。 それにより、利用可能な IOPs および、キャッシュのサイズとスペースに関して、ベスト・ミックスが確実に得られるようになる。

To minimize variance they must be able notice, diagnose, and then fix problems:

  • They measure how things work in operation. They can monitor at subsecond levels so they catch problems.
  • Servers have miniature fractures in their performance which they call "stalls." They’ve built tools to find these.
  • Dogpile collection. Every second it notices if something is wrong and ships it out for analysis.
  • Poor man’s profiler. Attach GDB to servers to know what’s going on, they can see when stalls happen.
  • Problems are usually counter-intuitive this can never happen type problems.

・ Extending a table locks the entire instance.
Flushing dirty pages was actually blocking.
How statistics get sampled in InnoDB.
Problems happen on medium-loaded systems too. Their systems aren’t that loaded to ensure quality of service, yet the problems still happen.

  • Analyze and understand every layer of the software stack to see how it performs at scale.
  • Monitoring system monitors different aspects of performance so they can notice a change in performance, drill down to the host, then drill down to the query that might be causing the problem, then kill the query, and then trace it back to the source file where it occurred.
  • They have a small team, so they make very specific changes to Linux and MySQL to support their use cases. Longer term changes are made by others.

  • 彼らは、運用における動作を測定する。 そこでは、0.1 秒レベルでのモニタリングが可能なため、問題を捉えることが可能になる。
  • サーバーには、彼らが「 Stall 」と呼ぶ、パフォーマンス上における小規模な障害が生じる。 彼らは、それを見つけ出すためのツールを作成した。
  • それが Dogpile コレクションである。 毎秒ごとに、何らかの問題があれば警告を出し、分析のために送信する。
  • それが、Poor man’s profiler である。起こっていることを認識するために、GDB をサーバーにアタッチする。 そして、Stall が起きたときに、それを確認する。
  • 通常、それらの問題は直感的に分かるものではなく、また、以下のような顕著な結果を引き起こすものでもない。

インスタンス全体をロックさせるほど、テーブルを拡大してしまう。
フラッシュする不要なページが、実際にはブロックされている。
InnoDB のサンプルにあるような、数値データが生じる。
中程度の負荷のシステムでも、問題が生じる。それらのシステムには、サービス品質が保証するほどの負荷がかけられていないが、それでも問題が生じる。

  • ソフトウェア・スタックの全レイヤに関して、それらがスケールされたときの挙動を分析し、理解する。
  • それにより、パフォーマンスの変化に気づき、ホストに対するドリルダウンが可能となる。 続いて、問題を起こしている可能性を持つクエリーをドリルダウンし、そのクエリーを kill し、さらに、問題を起こしたソース・ファイルに戻り、トレースを行う。
  • 彼らは小規模なチームであるため、そのユースケースをサポートするために、きわめて限定された変更を、Linux と MySQL に対して施すことができる。それよりも大規模な変更は、他のチームにより行われる。

Please watch the MySQL Tech Talk for more color and details.

より詳細な影響などについては、MySQL Tech Talk を参照して欲しい。

Related Articles

ーーーーー

運用コストの引き下げがイノベーションには欠かせないというロジックが、以前の Microsoft の資料に書かれていたと記憶しています。 もちろん、パフォーマンスや生産性の向上に結びつかない運用を指してのことでしょうが、ここで紹介したような Facebook の運用術を見ていると、まったく異なる世界が広がっていると思えてきます。

それに加えて、テクノロジーを売る会社ではないため、こうした運用のためのノウハウや、データセンターに関するナレッジを、オープンにしてしまう姿勢にも驚かされます。 いろいろな意味で、Facebook はクラウド・パイロット的な役割を担っているのだと、最近は そんなふうに感じるようになりました。 ーーー A.C.

ーーーーー

<関連>
Facebook を 1.8 倍速に、WordPress を 2.7 倍速にする、HipHop とは ?
Facebook の HDFS クラスターは 21 PB !!!
わずか四半期の間に、サーバー数が倍増した Facebook の事情
Facebook のスケール感覚に驚愕!
Facebook 探検隊: どのようなソフトウェアでスケールを達成しているのか
Facebook 映画 『 The Social Network 』 の感想ブログをご紹介します

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: