Facebookが新サービスの基盤にしたのは、MySQLでもCassandraでもなく、HBaseだった

2010年11月18日

Facebookが15日に発表した新しいサービス「Facebook Messages」は、チャットやつぶやき、そして電子メールなど、自分宛のテキストやメッセージをすべて1つのインボックスで管理できると発表されました。

The Underlying Technology of Messages | Facebook

同社が15カ月かけて開発してきたこの新サービスのバックエンドデータベースは、これまで同社が大規模運用してきたMySQLでも、同社が開発したNoSQLデータベースのCassandraでもなく、グーグルのBigTableをモデルとしてオープンソースで開発された分散データベース「HBase」でした。

Facebookのソフトウェアエンジニア、Kannan Muthukkaruppan氏がFacebookにポストした記事「The Underlying Technology of Messages」で、その技術的背景が紹介されています。

MySQLとCassandraが落選した理由

HBaseとは前述のように、グーグルのBigTableをモデルにオープンソースで開発されたNoSQLデータベースの1つです。Apache Software Foundationでオープンソースとして開発が続けられており(大規模分散処理フレームワークであるHadoopのサブプロジェクトから4月に昇格)、HDFS(Hadoop Distributed File System)の上に分散データベースを構築。大規模なデータに対するリアルタイムなランダムアクセスを得意とします。

なぜFacebookはHBaseを採用したのでしょうか? Muthukkaruppan氏は記事で、現在のMessagesインフラでは、毎月3億5000万のユーザーが150億通のメッセージを送り、3億のユーザーが1200億回のチャットを行っており、そのデータパターンには以下の2つの特徴があると記しています。

こうしたデータを扱う前提で、MySQL、Cassandra、HBaseほかいくつかのデータベースを評価した結果、HBaseを選択する結果になった、とのことです。

MySQLとCassandraが落選した理由が以下に解説されています。

MySQL proved to not handle the long tail of data well; as indexes and data sets grew large, performance suffered. We found Cassandra's eventual consistency model to be a difficult pattern to reconcile for our new Messages infrastructure.

MySQLはロングテールなデータをうまく扱えなかった。データとインデックスが増加すると性能が落ちていくのだ。また、CassandraのEventual Consistency(結果整合性)モデルは、新しいメッセージインフラにうまく適合させるのが困難だった。

HBaseを選んだ理由は性能、スケーラビリティ、シンプルな一貫性モデル

一方で、HBaseについては以下のように評価しています。少し長いですが、該当部分を引用しましょう。

HBase comes with very good scalability and performance for this workload and a simpler consistency model than Cassandra. While we’ve done a lot of work on HBase itself over the past year, when we started we also found it to be the most feature rich in terms of our requirements (auto load balancing and failover, compression support, multiple shards per server, etc.).

HBaseは、負荷に対して非常に高いスケーラビリティと性能を発揮し、CassandraよりもシンプルなConsistency Model(一貫性モデル)を備えている。これまでHBaseで多くの作業をしてきて、HBaseは私たちの要件に対してリッチな機能を備えていることが分かった(自動ロードバランス、フェイルオーバー、圧縮機能、サーバーごとに数十個のシャードを割り当てサーバごとの複数分割:Multible Shards per Server、など)。

さらにHBase下のファイルシステムとなるHDFSについても次のように評価しています。

HDFS, the underlying filesystem used by HBase, provides several nice features such as replication, end-to-end checksums, and automatic rebalancing. Additionally, our technical teams already had a lot of development and operational expertise in HDFS from data processing with Hadoop.

HBaseの下でファイルシステムとなっているHDFSも、いくつかの優れた機能を提供してくれる。レプリケーション、エンド・ツー・エンド・チェックサム、自動リバランシングなど。加えて、私たちの技術チームはすでにHadoopによるデータ処理を行っていたので、HDFSに関する多くの開発や運用の専門性を備えていたのだ。

自社開発したCassandraにさえこだわらない

Facebookは、いまだかつて誰も経験したことのない規模のソーシャルネットワークサービスを構築するために、これまでNoSQLデータベースのCassandraをはじめ、Haystackファイルシステム、PHPをC/C++に変換してコンパイルするHiphop for PHPなど、さまざまな新しいテクノロジーを自社で開発してきました。

しかし、そうしたソフトウェアにこだわることなく、他にすぐれているソフトウェアがあればためらいなく採用し、その上に新たなサービスを構築していく。こうした客観的な判断と高い技術力が同社の成長を支えているのでしょう。

関連記事

このエントリーをはてなブックマークに追加
follow us in feedly

タグ : Facebook , Hadoop , MySQL , NoSQL



≫次の記事
時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了
≪前の記事
EucalyptusとOpenStackが協力へ? Eucalyptusの共同創立者が「協力できる可能性がある」

Loading...

Blogger in Chief

photo of jniino Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。新しいオンラインメディアの可能性を追求しています。
詳しいプロフィール


Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed



Publickey 最新記事 10本

Publickey Topics 最新記事 10本


PR - Books


fig

fig

fig

fig



blog comments powered by Disqus