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など、さまざまな新しいテクノロジーを自社で開発してきました。

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

関連記事

あわせて読みたい

MySQL NoSQL データベース Facebook Hadoop




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

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

最新記事10本