Agile Cat — in the cloud

Facebook の Dragonstone : これは memcached の SSD 実装なのだ!

Posted in Data Center Trends, Facebook, Open Compute, Storage by Agile Cat on November 13, 2013

Facebook’s answer to serving 700TB of graph search data is lots of SSDs
By Derrick Harris – OCT. 24, 2013

_ Giga Om

Summary: Facebook’s decision to include status updates and wall posts in Graph Search could be called great or creepy depending on the user, but it wasn’t an inconsequential decision technologically. In fact, it put a significant strain on the feature’s database infrastructure.

Summary: Status Updates と Wall Posts を Graph Search に取り込むという Facebook の判断は、ユーザーよっては素晴らしいことであり、また、不気味なものになるとも言えるが、テクノロジーの面から見ると、「 取るに足らない判断 」という類のものでは決してない。 実際のところ、この機能は、データベース·インフラに大きな負担をかけるのだ。


Facebook’s graph search feature requires finding and serving the right data fast, and from a database that currently houses more than a trillion posts and 700 terabytes of data overall. In a Thursday morning blog post, engineer Ashoat Tevosyan dove into some of the challenges of building infrastructure that can handle these demands.

Facebook の Graph Search 機能では、正しいデータを素早く見つ出すというサービスが必要となるが、それらのデータは、すでに兆の単位で数えるポストと 700 T Bytes 収容する、データベースから抽出されるものとなる。木曜日の朝のブログ・ポストで、エンジニアである Ashoat Tevosyan が、これらの要求を処理するために必要なインフラを構築するための、いくつかの課題に踏み込んでいる

Facebook’s Dragonstone server.

One decision stood out to me was that Facebook opted for solid-state drives to store most of the data, saving only the most-frequently accessed stuff for RAM. This wasn’t a problem until Graph Search began including users’ posts, which drastically bumped up the size of the indexes it was dealing with. According to the post

私にとって、1つの突出した話は、ほとんどのデータを格納するために、Facebook が SSD を選んでいることであり、それにより、RAM への頻繁なアクセスを抑制していることであった。そして、Graph Search がユーザー・ポストなどを取り込むまでは問題が生じていなかったのだが、そこで取り扱うインデックス・サイズが、著しく巨大化してしまったのだ。彼のポストは、以下のように述べている。

“[S]toring more than 700 terabytes in RAM imposes a large amount of overhead, as it involves maintaining an index that is spread across many racks of machines. The performance cost of having these machines coordinate with each other drove the Unicorn [search infrastructure] team to look into new solutions for serving the posts index.”

「 RAM 上に 700 T Bytes 以上のデータをストアすると、複数のラック・マシンをまたいで分散されたインデックスの維持に関連して、相当量のオーバーヘッドが生じてくる。 それらのマシンにおけるパフォーマンス・コストを相互に調整するために、Unicorn(search infrastructure)チームが、ポスト・インデックスを提供するための、新しいソリューションの調査にとりかかった」

SSDs have been a key part of Facebook’s growth strategy for a while as an option for preserving the performance users require but saving on the high costs of storing data in RAM. In January, it unveiled a new all-flash server call Dragonstone for just such a purpose. In March, the company detailed a system it had built called McDipper, which is an SSD-based implementation of the popular memcached caching layer for RAM.

このところ、ユーザーが要求するパフォーマンスを維持するための選択肢として、Facebook の成長戦略の重要な一部を SSD が構成しているが、RAM 上にデータをストアすることで生じる、高いコストを緩和している。この 1月には、その目的だけのために、Dragonstone と呼ばれる、オール・フラッシュ・サーバーを新たに発表した。そして 3月には、McDipper と呼ばれる、同社で構築されたシステムが詳述された。それは、RAM レイヤにおいて人気の、memcached によるキャッシュを SSD に実装するというものである。

However, just because Facebook is using flash and SSDs a lot more often, that doesn’t mean the company is always happy about. As VP of Engineering Jay Parikh told me during the company’s Open Compute Summit earlier this year, if hard disks are like minivans and current flash drives are like Ferraris, Facebook is looking for the Toyota Prius of storage that delivers the right balance of speed, efficiency and cost.

しかし、Facebook がフラッシュと SSD を多用しているという状況において、それだけでは、同社が常に満足しているということにはならない。VP of Engineering である Jay Parikh が、今年の初めの Open Compute Summit で話してくれたのは、ハードディスクが Mini Van なら、いまのフラッシュ・ドライブは Ferrari のようなものだという例えである。 しかし Facebook が探しているのは、Toyota Prius のようなストレージであり、スピード/効率/コストを適切にバランスさせるものであると言う。

Check out the rest of Tevosyan’s post for more details on building the Graph Search indexes in HBase, harvesting user data from its MySQL cluster without throttling its performance and using Facebook’s new Wormhole technology to update the Graph Search index as changes happen to the MySQL data.

Graph Search のインデックスを、HBase で構築する際の詳細については、Tevosyan のポストをチェックして欲しい。 そのパフォーマンスを絞ることなく、MySQL クラスタからユーザー・データを取得するものである。 そして、MySQL データが変更されると、Graph Search インデックスが更新されるようにするために、Facebook は Wormhole  と呼ばれる、新たなテクノロジーを用いているようだ。

Related research


imageなんというか、空前絶後のナレッジ・ノードを構成する、Open Graph を動かすためには、膨大なキャッシュが必要だということですね。しかも、「 RAM 上に 700 T Bytes 以上のデータをストアすると、複数のラック・マシンをまたいで分散されたインデックスの維持に関連して、相当量のオーバーヘッドが生じてくる」という、プロダクション・システムからのフィードバックをベースに考えたれたのが、この Dragonstone ということなのですね。 う~ん、驚愕です! それにしても、Tesla ではなく Prius が欲しいというのが、手堅い Facebook インフラ・チームらしくて、イイ感じです 🙂 image141



Open Compute について、知っておくべき 10 の事柄
Intel の Open Compute にかける意気込みがスゴイ : 100G Photonics だ!
Intel の 1.6 TB/秒 転送 : その秘密を解く
Google や Facebook は、サーバー用の カスタム CPU に取り組むだろう
Quanta と OCP : Server/Storage/Switch/Rack などがデビュー!
Facebook Hardware Labs は、エンジニアにとって夢のような空間だ


Comments Off on Facebook の Dragonstone : これは memcached の SSD 実装なのだ!

%d bloggers like this: