Facebook メッセージを支えるストレージ･インフラを解説 – James Hamilton « Agile Cat

Facebook メッセージを支えるストレージ･インフラを解説 – James Hamilton

Posted in Big Data, Facebook, James Hamilton by Agile Cat on November 2, 2011

Storage Infrastructure Behind Facebook Messages
Tuesday, October 25, 2011
http://perspectives.mvdirona.com/2011/10/25/StorageInfrastructureBehindFacebookMessages.aspx

One of the talks that I particularly enjoyed yesterday at HPTS 2011 was Storage Infrastructure Behind Facebook Messages by Kannan Muthukkaruppan. In this talk, Kannan talked about the Facebook store for chats, email, SMS, & messages.

昨日（10/24）の HPTS 2011 で、とりわけ興味深かった話として、Kannan Muthukkaruppan による Storage Infrastructure Behind Facebook Messages がある。そこで、Kannan は、チャット／電子メール／SMS／メッセージのための Facebook ストアについて話をした。

This high scale storage system is based upon HBase and Haystack. HBase is a non-relational, distributed database very similar to Google’s Big Table. Haystack is simple file system designed by Facebook for efficient photo storage and delivery. More on Haystack at: Facebook Needle in a Haystack.

このハイ･スケールなストレージ･システムは、HBase と Haystack をベースにしている。 HBase は、Google の Big Table に極めて類似した、Non Relational な分散データベースである。 Haystack は、効果的な写真ストレージと配達のために、Facebook によりデザインされたシンプルなファイル･システムである。 Haystack の総裁については、Facebook Needle in a Haystack を参照して欲しい。

In this Facebook Message store, Haystack is used to store attachments and large messages. HBase is used for message metadata, search indexes, and small messages (avoiding the second I/O to Haystack for small messages like most SMS).

この Facebook メッセージ･ストアにおいては、アタッチメントと長いメッセージをストアするために Haystack を使用する。 HBase に関しては、メッセージ･メタデータおよび、サーチ･インデックス、短いメッセージのために使用される（大半の SMS のような短いメッセージのために、Haystack に2番目の I/O を儲けることを回避）。

Facebook Messages takes 6B+ messages a day. Summarizing HBase traffic:

Facebook Messages は、1日あたり 6B 以上のメッセージを処理する。以下は、HBase トラフィックの概要である：traffic:

75B+ R+W ops/day with 1.5M ops/sec at peak
The average write operation inserts 16 records across multiple column families
2PB+ of cooked online data in HBase. Over 6PB including replication but not backups
All data is LZO compressed
Growing at 250TB/month

The Facebook Messages project timeline:

Facebook Messages プロジェクトの年譜は、以下のとおりである：

2009/12: Project started
2010/11: Initial rollout began
2011/07: Rollout completed with 1B+ accounts migrated to new store
Production changes:
- 2 schema changes
- Upgraded to Hfile 2.0

クリックで拡大 ⇒

They implemented a very nice approach to testing where, prior to release, they shadowed the production workload to the test servers.

彼らは、リリースに先立つテストにおいて、そのプロダクション･ワークロードからテストサーバーへと追尾する、とても素晴らしいアプローチを実装している。

注記）動詞の Shadow は［追尾］で良い？

After going into production the continued the practice of shadowing the real production workload into the test cluster to test before going into production:

プロダクション･フェーズに入った後も、現実のプロダクション･ワークロードを追尾する、継続的なプラクティスが実践され、次のプロダクションを検査するためのテスト･クラスタに、その結果が取り込まれていく：

クリックで拡大 ⇒

The list of scares and scars from Kannan:

心配事のリストと、Kannan による痕跡は、以下のとおりである：

Not without our share of scares and incidents:
- s/w bugs. (e.g., deadlocks, incompatible LZO used for bulk imported data, etc.)
  - found a edge case bug in log recovery as recently as last week!
performance spikes every 6 hours (even off-peak)!
- cleanup of HDFS’s Recycle bin was sub-optimal! Needed code and config fix.
transient rack switch failures
Zookeeper leader election took than 10 minutes when one member of the quorum died. Fixed in more recent version of ZK.
HDFS Namenode – SPOF
flapping servers (repeated failures)
Sometimes, tried things which hadn’t been tested in dark launch!
- Added a rack of servers to help with performance issue
  - Pegged top of the rack network bandwidth!
  - Had to add the servers at much slower pace. Very manual .
  - Intelligent load balancing needed to make this more automated.
A high % of issues caught in shadow/stress testing
Lots of alerting mechanisms in place to detect failures cases
- Automate recovery for a lots of common ones
- Treat alerts on shadow cluster as hi-pri too!
Sharding service across multiple HBase cells also paid off

Kannan’s slides are posted at: Here

–jrh

James Hamilton
e: jrh@mvdirona.com
w: http://www.mvdirona.com
b: http://blog.mvdirona.com / http://perspectives.mvdirona.com

ーーーーー

それぞれのメッセージに対して、適切なストレージを割り当て、さらにはプロダクションとシャドウの上手い関係を構築してという、とても緻密な運用に驚かされます。一見、大雑把に見える Facebook ですが、いつものとおり、洗練されていますね！でも・・・先週の Open Compute Summit では、Agile_Cat の名前がエントリーされていなくて、一瞬こわばりましたが、同じ境遇の人もたくさん居たみたいで、その場で名札をバンバン印刷して、来た人をドンドン入れてくれちゃいました。やっぱり、大雑把それと、会場には James Hamilton さんが居て、がんばれ Agile_Cat と応援してくれたのには、大感激してしまいました。ーーー