Cassandra実践入門―Twitter,Facebookが採用するNoSQLシステム

この記事を読むのに必要な時間:およそ 10.5 分

はじめに

2010年のはじめ,TwitterがApache CassandraというJavaで実装された分散型のデータストアシステムを採用しつつあるというニュースが話題を呼びました。このことでCassandraは,NoSQLと呼ばれるシステムの中で最も注目を集めるものの一つになったと言えるでしょう。

2010年7月の時点で,Twitterは,位置情報のデータストレージ,トップツイート(トップページに表示される人気ツイート一覧)などのリアルタイム分析,データマイニング処理など,多くの用途でCassandraを活用しています。また,Cassandraを生み出し,のちにApache Foundationに寄贈したFacebookでは,5億人規模・150Tバイト以上のデータ量を持つユーザメッセージの検索機能Inbox Searchを,150ノードのCassandraクラスタで処理しています

本稿では,まずNoSQLとCassandraについて,その全体像や位置づけを概観します。次にRuby on Rails(以下Rails)からCassandraを利用する方法について解説します。最後にCassandraクラスタ環境の構築と運用方法について説明します。

NoSQL小史

まず,NoSQLの簡単な歴史を紹介しましょう。

RDBMSの限界

RDBMSは長年にわたって広く使われ,特に大規模なシステム開発においては必ずと言ってよいほど採用されています。しかしWebが社会のITインフラとして機能する時代に入ると,SNSSocial Networking ServiceやEC(電子商取引)など世界規模で運営されるWebサイトでは,データ量や同時アクセス数の増大からRDBMSではパフォーマンスの問題が生じるようになってきました。

サーバを増やすことでリニアに性能をスケールできるフロントエンドのWebサーバと違い,バックエンドを引き受けるRDBMSは負荷分散の手法に制約があり,ボトルネックになることが多くなってきたのです。

GoogleのBigtableとAmazonのDynamo

そのような状況の中,2006年にGoogleのBigtable2007年にAmazonのDynamoと,2つの巨大Webサービス企業が,自社の開発した分散ストレージシステムについての技術論文を相次いで発表しました。両者は分散コンピューティング技術を基礎とし,データ量や処理の負荷を多数のサーバに分散できるスケールアウト可能なシステムという共通点を持っていました。

NoSQLという言葉の誕生

これらの論文は多くの人々に影響を与え,BigtableやDynamoの直接的なクローンや,アイデアを積極的に取り入れたシステムの開発プロジェクトが,数多く立ち上げられました。

そして2009年6月11日,サンフランシスコにおいて,それらを取り上げたNOSQL meetupというイベントが開催されました。これが「NOSQL」というキーワードを世界に広めたきっかけだと言われています。

NOSQLは「SQL/RDBMSの否定」というネガティブなイメージを持つため,のちに「Not only SQL = NoSQL」と再定義され現在ではRDBMSと相補的な役割を持つシステムというニュアンスが強調されています。

NoSQLを理解する2つの軸

現在NoSQLとみなされる多くのシステムが存在します。それぞれ多様な特徴を持っており,どのように評価・分類すればよいのか難しいところです。そこで,NoSQLシステムの全体像の理解に役立つ2つの概念を紹介します。

CAP定理

エリック・ブリュワーが2000年に提唱した「CAP定理」The CAP Theoremと呼ばれる概念があります注1)⁠CAP定理は,ネットワーク上の分散システムは,次のC,A,Pの3つの要件のうち,同時に2つしか保証できない,というシステムデザイン上のトレードオフを論じたものです。

  • Consistency(整合性)
  • Availability(可用性)
  • Partition Tolerance(ネットワーク分割耐性)

Cの整合性は,各クライアントが同時に同じデータを読み出すと必ず同じ値が返されることを意味します。Aの可用性は,サービスが恒常的に提供される(停止しない)ことを意味します。Pのネットワーク分割耐性は,分散システム内のネットワークが分断された場合もサービスを継続できることを意味します。

C,A,Pの3要件のうち同時に2つしか保証できないとは,整合性,可用性,ネットワーク分割耐性の3つを兼ね備えたシステムは構築できないことを意味します。たとえば整合性と可用性を重視したシステムは,ネットワーク分割耐性に弱点を持ってしまうというのがCAP定理の主張です。

では,C,A,Pの組み合わせCA/AP/CPは,それぞれどのような処理に向いているのでしょうか。参考までに筆者の考えを表1にまとめました。

表1 C,A,Pの各組み合わせに適した処理

種類適した処理
CA(整合性,可用性)銀行口座など,データの矛盾が許されないリアルタイム処理
AP(可用性,ネットワーク分割耐性)ショッピングカートなど,ダウンタイム短縮への要求が厳しいリアルタイム処理
CP(整合性,ネットワーク分割耐性)検索エンジンのインデックス処理など,データの矛盾が許されない非リアルタイム処理
注1)
「定理」という言葉は本来,理論体系の基礎として公に認められた証明済みの命題のことです。しかしCAP定理が「定理」と言えるかどうかは,まだ評価が定まっていません。

データモデル

NoSQLシステムがデータをどのようなモデルで取り扱うかは,大きく分類して表2の3つの方向性にまとめられます。表2には,筆者が考えるそれぞれのデータモデルに適した用途も掲載しました。

表2 NoSQLのデータモデル分類と,適した用途

データモデル説明適した用途
キー・バリュー型キーに1つの値を対応づけるシンプルなデータモデルキャッシュなど加工済みデータの保存
カラム指向キーに対する値として{名前:値}の集合を扱うデータモデルユーザアカウントなど多数のプロパティを持つオブジェクトの保存
ドキュメント指向XMLやJSONなどのツリー構造を扱うデータモデルディレクトリ・フォルダのような不定形で深い構造を持つデータの保存

2つの軸と各NoSQLシステムの位置づけ

米国の起業家ネイザン・ハーストは,NoSQLの各種システムをCAP定理とデータモデルの2つの観点から調査し,2010年3月に自身のブログエントリでわかりやすく図解しました。その図を和訳したものを図1に掲載します。

Cassandraは,AP型(可用性とネットワーク分割耐性は備えるが,整合性は備えない)かつカラム指向なデータモデルのシステムと位置づけられています注2)⁠表1と表2に挙げた適した処理・用途から,Cassandraは停止が許されない高いサービスレベルを要求される場面で,複雑なデータを管理するのに向いたシステムだと言えます。

図1 CAP定理と各NoSQLシステムの位置づけ

図1 CAP定理と各NoSQLシステムの位置づけ

Nathan Hurst, "Visual Guide to NoSQL Systems", 2010

注2)
後述しますが,実際は整合性について,この分類の枠に収まらない特徴的な機能を備えています。

結果整合性

AP型のNoSQLシステムでは,1つのクライアントから書き込まれた変更をすべてのクライアントから参照できるようになるまで,ある程度時間がかかる可能性があります。その間,データの整合性が守られていないことを,システムの要件として許容しているのです。このような弱い整合性のことを「結果整合性」Eventual Consistencyと呼び,NoSQLシステムにおいて中心的な概念の一つとされています。

著者プロフィール

島田慶樹(しまだけいき)

株式会社ケイビーエムジェイ コマースソリューション事業部 シニアエンジニア。

主にRuby on RailsによるWebシステム開発に従事。大規模ASPサービスの開発・保守を通じてシステムのスケーラビリティやパフォーマンスの問題に取り組み,NoSQLを始めとしたさまざまな技術と格闘する日々。好きなプログラミング言語はSmalltalkとLisp。いつかはPrologをマスターしたいと思いつつ,今はScalaをかじっている。

Twitter:@_shimada

コメント

コメントの記入