Agile Cat — in the cloud

How Facebook built its Timeline feature
http://wp.me/pwo1E-3P0
By Stacey Higginbotham Jan. 5, 2012, 1:06pm
http://gigaom.com/cloud/how-facebook-built-its-timeline-feature/

Facebook’s Timeline feature is beautiful, although some revile it. But love it or hate it, Timeline is the engineering equivalent of building a racing bike customized for a specific track, only without testing either until race day. At least that’s how Ryan Mack, an infrastructure engineer with Facebook, makes it seem on a blog posted Thursday detailing how Facebook engineered its Timeline feature.

Facebook の Timeline は素晴らしいが、悪口を言う人もいる。 好き嫌いもあるが、Timeline のエンジニアリングは、特定のサーキットにカスタマイズされたレーシング･バイクの開発に等しい。ただし、テストは行われず、ぶっつけ本番でレースに臨んでいる。少なくとも、Facebook のインフラ･エンジニア Ryan Mack にとって、それが彼のやり方のようだ。木曜日（1/5）にポストされたブログが、どのように Facebook Timeline 機能がデザインしたのを、詳述しているように思える。  

Making a legacy MySQL database faster.

クリックで拡大 ⇒

The blog post also offers a ton of data on how Facebook dealt with petabytes of user data stored in legacy MySQL systems on slow disks that could make Timeline less responsive. The company implemented a new architecture that separates out older data to slower disk storage and keeps more recent and more accessed data stored in flash drives and cached using memcached. From the blog:

そして、このブログ･ポストでは、Timeline の反応を遅くしてしまう、低速ディスク上のレガシー MySQL システムにストアされていたペタバイト･ユーザー･データを、Facebook が取り扱った方式についても、膨大なデータが提供されている。 Facebook は、その遅いディスク･ストレージと、従来からのデータを切り離す、新しいアーキテクチャを実装した。それは、直近にアクセスされたデータや、頻繁にアクセスされるデータを、フラッシュ･メモリ･ドライブにストアし、また、memcached にキャッシュするという方式である。以下は、そのブログからの参照である：

Before we began Timeline, our existing data was highly normalized, which required many round trips to the databases. Because of this, we relied on caching to keep everything fast. When data wasn’t found in cache, it was unlikely to be clustered together on disk, which led to lots of potentially slow, random disk IO. …A massive denormalization process was required to ensure all the data necessary for ranking was available in a small number of IO-efficient database requests.

Timeline が開始される前には、既存のデータが高度に正規化されており、対象となるデータベースとの間で、数多くのラウンド･トリップが必要とされていた。 そのような理由から、すべてをキャッシングして、高速化を図るというという手法に依存することにした。 そして、データがキャッシュ上で発見されなかったとき、きわめて低速なランダム I/O が、大量に発生する可能性のあるディスク上のデータを、探さないで済むようにした。つまり、ランキングに必要な全データが、効果的な I/O データベース･リクエストを介して、しかも、少ない呼び出し回数で得られるようにするための、大量の非正規プロセスが必要とされた。

Here’s a visual of the system
クリックで拡大 ⇒

Mack spent a lot of time detailing the challenges of denormalizing the data, which entailed getting an intern to define a custom language that would tell a compiler how to convert old data into the new format and the use of three “data archeologists” to write the conversion rules. It also required Facebook to move older activity data to slower network storage while maintaining acceptable performance. To do this Facebook, “hacked a read-only build of MySQL and deployed hundreds of servers to exert maximum IO pressure and copy this data out in weeks instead of months.”

Mack は、それらのデータの非正規化というチャレンジについて、大量の時間を費やしながら詳述してきた。そこでは、カスタム言語をインターンに定義させることまで必要になり、そこから、古いデータを新しいフォーマットにコンバートする方法を、コンパイラに伝えることになった。 さらに、そのコンバージョン規則を記述するために、3人の「データ考古学者」を採用することにもなった。 そして、受容できるパフォーマンスを維持しながら、さらに古いアクティビティ･データを、低速のネットワーク･ストレージに移動させることも必要となった。 それを実現するために Facebook は、「 MySQL のリード･オンリー･ビルドをハックし、最大の I/O プレッシャーを行使する、数百台のサーバーにディプロイした。 続いて、それらのデータのコピーを、数カ月から数週間に頻度を切り替えて、処理するようにした」。

To speed IO even further, engineers consolidated join tables into a tier of flash-only databases. Since PHP can perform database queries on only one server at a time, Mack said Facebook wrote a parallelizing query proxy that allowed it to query the entire join tier in parallel. Finally Facebook attempted to future-proof its data model, but we’ll see how far that takes it.

さらに I/O を高速化するために、エンジニアたちは複数のテーブルを、フラッシュ･メモリのみで構成されるデータベースの、1つのティアにコンソリデートしていった。 PHP によるデータベース･クエリーは、一度に 1つのサーバーのみという制限がかかるため、 Facebook では、ジョインされているティア全体をパラレルでクエリーしていく、並列化されたクエリー･プロキシーを記述したと、Mack は発言している。 Facebook は最終的に、そのデータ･モデルを future-proof にしようと試みているが、それを私たちが確認するのは、はるか未来になるだろう。

In response to a question I sent Mack, said through a spokesman, that it took Facebook two weeks to dump everyone’s old profile data from the existing system into an archive using “some off-the-shelf network attached storage.” That data was then stored on “the new servers that now power Timeline, which, at the time, were fresh and didn’t have anything hitting them from production. We did incremental updates weekly until later, when we had writes going to both systems in real time.” That’s a lot of fresh servers, although Facebook remained mum about the exact data transferred.

私からの質問に対して、Mack がスポークスマンを介して回答してきたのは、「ストレージにアタッチされた、いくつかの既製品ネットワーク」を用いて、既存システム上の古いプロファイル･データをアーカイブにダンプするのに、2週間を要したというものだった。 続いて、それらのデータは、「いまや Timeline にパワーを供給する新しいサーバーにストアされた。 なお、その時点における、それらのサーバーは、フレッシュなものであり、また、プロダクション･システムからのアクセスが皆無なものであった。私たちは、毎晩遅くまで、Weekly のインクリメタル更新を行なっていった。そして、その時には、2つのシステムに、リアル･タイムで書き込んでいった」とも伝えてきた。 たしかに、大量のフレッシュ･サーバーを用いたのだろうが、転送された正確なデータについては、Facebook は口を閉ざしたままである。

Facebook also built the Timeline aggregator to run locally on each database to avoid information traveling over the network unless that information will be displayed on the page. That’s another timesaver. It also used it’s Hip Hop code for speeding up PHP in that aggregator.

さらに Facebook は、ネットワーク上を情報が移動することを回避するために、個々のデータベース上でローカルに実行される Timeline Aggregator を構築した。 ただし、その情報がページ上に表示される場合には、この情報の移動は制約されない。 つまり、ここでも時間の短縮が図られている。 そして更に、Aggregator の PHP を高速化するために、Hip Hop コードが用いられた。

Building in parallel.

The other element of the blog that I found amazing was how Facebook apparently denormalized its data, had a product team visualizing the Timeline UI, and built a scalable back end system for everything to run on all at the same time. I’m going to call that crazy, but Mack notes that’s what kept the development time frame to a mere six months.

見たところ、Facebook がデータの非正規化を行なっているらしいという、驚くべき発見があったブログには、Timeline UI のビジュアライズと、スケーラブルなバックエンド･システムを、プロダクト･チームが常に同時に構築していたとも書かれている。 私はクレージーだと叫びたいが、Mack の方はというと、6ヶ月間の開発タイム･フレームで保持したものに過ぎないと言っている。

I asked Facebook about what it learned during that process, because I imagine a lot of other sites would love to be able to develop their front and back end systems in parallel and save the cost of replicating their entire production environment’s data to test it. The response a spokesman emailed me from Mack was as follows:

私は、このプロセスで Facebook が学習したことについて尋ねた。 なぜなら、Timeline に限らず、彼らの多くのサイトが、フロント･エンドとバック･エンドを、平行して開発できるようになっていると、想像したからである。また、全体的なプロダクション環境のデータを、テストのためにリプリケートするコストも、排除されていると想像した。 スポークスマンが Mack からのメールを転送してきたが、その答えは以下のとおりである：

Layering is a good way of describing the process of building Timeline. To make sure we could work in parallel, we always made sure that there was at least a temporary technology that each part of the team could build on top of. Some of these were pre-existing, but many of them were quick prototypes built in a couple of days as needed. We also had frequent scrums to identify places where people were blocked on each other, and everyone on the team did an excellent job of knowing what others needed or would soon need.

Timeline の構築プロセスを表現する上で、階層化は良い方式である。 私たちの作業を並列で機能させるために、少なくとも、テンポラリなテクノロジーの上に、チームが構築しているものが在ることを、常に確認していった。 いくつかのテクノロジーは、以前から存在するものであったが、その他の大半は、必要に応じて2～3日で構築されるプロトタイプであった。 それぞれの個人が、相互に守るべき境界線を定めるために、私たちは頻繁に議論してきた。そして、このチームの全員が、他者が必要としていること、また、必要になると思われることを理解するという、素晴らしいジョブを実施していった。

When the production solutions were ready, there was always some friction in migrating from the temporary solution, but usually it was just a few days of work. It was a definite win compared with the weeks or months of delay we’d have faced if we had waited for the production solution up front. Given that we wanted to build the entire system in six months, it was critical that we avoided wasting any time.

そして、プロダクション･ソリューションの準備が整ったとき、テンポラリ･ソリューションからの移行において、いくつかの軋轢が常にあったが、だいたいは数日間の作業でフィックスできた。 このプロダクション･ソリューションを、以前から待っていたとするなら、私たちが直面することになった、数週間あるいは数ヶ月の遅れと比較して、たしかな勝利を収めたと言えるだろう。 全システムを 6ヶ月で構築することが望みだったと考えると、あらゆる時間の浪費を避けたことが、とても重要であった。

From nothing to Timeline in six months is pretty impressive, considering we’re talking about creating something to support more than 800 million users. Now you know a bit more how this Timeline sausage was made.

無から始めて、6ヶ月で Timeline を達成するとは、とても素晴らしい結果である。 そして、8億人以上のユーザーをサポートするための、何らかのものについて、ここで話しているという事実を再認識したい。 そして、いまでは、この Timeline ソーセージが作られた方式について、あなたも少し詳しくなっただろう。

Related research and analysis from GigaOM Pro:

• Dissecting the data: 5 issues for our digital future
• What Amazon’s new Kindle line means for Apple, Netflix and online media
• NewNet Q2: Google closes the quarter with a bang

ーーーーー

いやぁ～～～ 翻訳していて、これほどゾクゾクしてくるのは、ほんとうに久しぶりの経験でした。 昨年の 11月のことですが、「 Big Data の実装へと走る前に、Better Data について考えるべきだ 」という Formatek のブログポストを訳しました。 そのときには、Better Data のイメージが掴めませんでしたが、ここに書かれている非正規化と、Non ストレージ･アクセス（ゼロではありません）も、きっと、その 1つなのだろうと思えてきます。 こうした柔軟な発想には、ほんとうに脱帽です。 ーーー 

ーーーーー

＜関連＞

Facebook のスケール感覚に驚愕！ _1
Facebook のスケール感覚に驚愕！ _2
Facebook 探検隊：どのようなソフトウェアでスケールを達成しているのか _1
Facebook 探検隊：どのようなソフトウェアでスケールを達成しているのか _2
Facebook 探検隊：どのようなソフトウェアでスケールを達成しているのか _3