TwitterとDiggがNoSQLの「Cassandra」を選ぶ理由

2010年3月8日

スケーラブルなデータベースを実現する手段として「Sharding MySQL plus memcached」がよく知られる方法だとは、1つ前の記事「MySQL+Memcachedの時代は過ぎ、これからはNoSQLなのか、についての議論」で紹介しました。

ちなみに「Sharding」(シャーディング)とは複数のデータベースにデータを分散して運用することで、ざっくりいえばShared Nothing的な分散データベース構成のことです(この記事で紹介する英文中には「Shared MySQL」(共有MySQL)との記述がありますが、これは恐らく「Sharded MySQL」(ShardされたMySQL)のミススペルではないと推測します)。

日本で(たぶん)もっともMySQLについて詳しく解説してあるブログ「漢(オトコ)のコンピュータ道」のエントリ「さらにMySQLを高速化する7つの方法」では、Shardingとは何かについて簡単に触れているとともに「Shardingが必要になるほど大規模なデータベースはどちらかといえば少数派なので、あまり一般的なケースには当てはまらないかも知れないが」と書いてあります。Shardingを採用する規模というのはそれだけ大きいのだといえるでしょう。

TwitterとDiggがNoSQLを検討している

The Apache Cassandra Project

そのShardingされたMySQLやMemcachedなど用いて運用している超大規模なWebサイトのTwitterやDiggは、それぞれ新しいデータベースとしてCassandraを採用し、MySQLからリプレースしようとしています。

Cassandraとは、The Apache Projectが開発中のNoSQLデータベース。キーバリュー型データストアの一種で、Eventual Consistency(結果整合性)、レプリケーションと自動フェイルオーバーによるフォールトトレラント機能などを実装しています。

2つの会社はなぜMySQLからCassandraへと移行しようとしているのでしょうか? なぜCassandraなのでしょうか? 理由と選考過程について紹介してみましょう。

Twitter:Cassandraは単一障害点がなくスケーラブル

TwitterがMySQLからなぜ他のデータベースへと移行しようとしているのか。「myNoSQL」の2月23日のエントリ「Cassandra @ Twitter: An Interview with Ryan King」で、TwitterでCassandraの利用を推進中のRyan King氏に対するインタビューを掲載しています。ポイントを見てみましょう。

Twitterは、ShardingされたMySQLとMemcachedで運用していたけれども、運用コストが大きくなってきたことが、ほかのデータベースを検討し始めた理由だとKing氏は答えています。

We have a system in place based on shared mysql + memcache but its quickly becoming prohibitively costly (in terms of manpower) to operate. We need a system that can grow in a more automated fashion and be highly available.

私たちはShardingされたMySQL + memcachedをベースとしたシステムを運用しています。しかしそれは急速に受け入れがたいほど運用コストが(おもに人的コストが)かかるようになってしまいました。もっと高可用で自動化された方法で成長可能なシステムが必要です。

そこでTwitterでは2つの手段を検討したとのこと。それは、さらに自動化されたMySQLをセットアップするか、あるいはほかのもっと高速なデータベースへと移行するか、です。

  • A more automated sharded mysql setup
  • Various databases: HBase, Voldemort, MongoDB, MemcacheDB, Redis, Cassandra, HyperTable and probably some others I’m forgetting.

それらを以下の観点で比較したとのこと。

  • How will we add new machines?
  • Are their any single points of failure?
  • Do the writes scale as well?
  • How much administration will the system require?
  • If its open source, is there a healthy community?
  • How much time and effort would we have to expend to deploy and integrate it?
  • Does it use technology which we know we can work with? … and so on.

つまり、(性能を向上させるための)マシンの追加方法、単一障害点の有無、データ追加が多くてもスケールするか、管理コスト、プロジェクトの将来性などが主な比較項目のようです。

特にTwitterはデータベースへの書き込み負荷が非常に多いと考えられるので、データ追加のスケーラビリティは大きなポイントのはずです。

Asking these questions narrowed down our choices dramatically. Everything but Cassandra was ruled out by those questions. Given that it seemed to be our best choice, we went about testing its functionality (“can we reasonably model our data in this system?”) and load testing.

こうした質問によって選択肢は劇的に狭められていった。Cassandraだけが答えられたのだ。私たちにとって最適な選択だといえ、これから機能と負荷テストをしようとしているところだ。

Cassandraを採用する重要なポイントを、King氏は次のようにまとめています。

  • No single points of failure
  • Highly scalable writes (we have highly variable write traffic)
  • A healthy and productive open source community

Digg:Cassandraはバランスがよい

一方のDiggはどのようにしてCassandraを選んだのでしょうか? Diggのオフィシャルブログに、昨年の9月にポストされたエントリ「Looking to the future with Cassandra」から紹介しましょう。

Digg has been researching ways to scale our database infrastructure for some time now. We’ve adopted a traditional vertically partitioned master-slave configuration with MySQL, and also investigated sharding MySQL with IDDB.

これまでDiggはスケールするデータベースを調査してきた。これまでに伝統的な手法であるパーティションに分けたMaster-Slave構成のMySQLを取り入れ、Sharding MySQLとInnoDBについても調査してきた。

DiggでもSharding MySQLは選択肢にあったようです。しかし、彼らの調査でもやはりMySQLでは運用コストが大きくなりすぎるとの結論となり、「we felt comfortable looking at more exotic, non-relational data stores.」つまりNoSQLへと選択肢を広げたのでした。

After considering HBase, Hypertable, Cassandra, Tokyo Cabinet/Tyrant, Voldemort, and Dynomite, we settled on Cassandra.

そしてさまざまなNoSQLを検討した結果、Cassandraを選択したと。

Each system has its own strengths and weaknesses, but Cassandra has a good blend of everything. It offers column-oriented data storage, so you have a bit more structure than plain key/value stores. It operates in a distributed, highly available, peer-to-peer cluster.

それぞれのシステムには強みと弱みがあるが、Cassandraはそれらを適切なバランスで備えていた。カラム指向型データストレージであり、キーバリュー型データストアよりもややデータ構造を備えている。分散構成による高い可用性を持つピア・ツー・ピア型のクラスタで運用できる。

Cassandraの評価を一気に固めることになるか

TiwtterもDiggも、これから実運用にCassandraを投入するフェーズを迎えることになります。両社とも動いているシステムのデータベースを入れ替えるのですから、それは慎重かつ大きなプロジェクトになることでしょう。

そして、入れ替え後に果たして想定した通りの能力をCassandraが発揮してくれるのか。もし順調にいったとしたら、それを契機にNoSQLが、Cassandraが、スケーラブルな環境において実用的なレベルで非常に優れたシステムだという評価を一気に固めることになるかもしれません。

関連記事

Twitterはすでに徹底的にMemcachedのオプティマイズなどを行い、性能向上に努力してきました。その様子は次の記事で紹介しています。

NoSQLについては以下の記事をぜひ参照してみてください。

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

タグ : NoSQL , Twitter



≫次の記事
Google App Engineダウンの原因はデータセンターの電源故障。さらに復旧手順のミスが重なった
≪前の記事
MySQL+Memcachedの時代は過ぎ、これからはNoSQLなのか、についての議論

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