分散化技術は難しい。課題の解決方法により特徴が生まれる


 ここまで、Big Dataに対応するためには分散コンピューティング処理を行うソフトウェア技術の導入が解決方法であると説明してきました。しかし、この分散コンピューティング処理について、Geminiの開発者は常に「簡単ではない」と言います。

 それは、考えなければいけない課題が山ほどあるからです。前回ご紹介したEric Brewer博士が提唱したCAP定理は、次の3つ条件のうち2つしか満たせないと証明しています。

●システム全体として、データの更新があった際に複数の複製(レプリカ)データの一貫性(Consistency)を保つことができるでしょうか?

●システム全体として、いつでもどんな状態でもリクエストに応えること(Availability)ができるでしょうか?

●システムのネットワークが分断された場合でも、システム全体として正しい処理を行うこと(Partitioning Tolerance)ができるでしょうか?

 上記の3つの条件は、学究的な分類としての意味合いも強いですが、実際のオペレーションにおいては、他にもデータが失われることがないか(Data loss)、システム停止をせずに容易に拡張できるか(Elasticity)、障害への耐用性は備わっているか(Durability)など、多くの課題があります。そして、すべての課題に対して完全な答えを提供するものは存在しないとも言えるのでしょう。

 Big Dataを処理するソフトウェアは、それぞれの方法で課題を解決しようとしています。その理由は、アプリケーションやサービスの特性に合わせて、必要な機能が徐々に実装されてきたからです。利用はこの点に配慮し、特徴を見極めたうえで最適なものを選び出すことが求められます。

モバイルクラウドのBig Dataに向けて開発した「Hibari」


 本年7月、Geminiは、モバイルクラウドのBig Dataを扱うソフトウェアである「Hibari」(ヒバリ、雲雀)をオープンソースとしてリリースしました。

 Hibariは、Big Dataに最適化した分散キー・バリュー型のデータベースです。その特徴を簡単に挙げると以下になります。
●中国におけるSNSや日本で数百万人が利用する大規模Webメールにおける商用実績がある
●データの「読み出し」に最適化されている
●さまざまなサイズのバリュー(値)において安定的であり、とくに大きなバリュー(値)においてパフォーマンスが高い

 以下では、Dynamo 、Hadoop/HBase、Cassandra、MongoDBなど、Big Data向けの代表的なNOSQLデータベースと比較しながら、Hibariの特徴を説明します。単なる製品解説としてではなく、アプリケーションやビジネスのニーズに応じて最適なNOSQLのシステムを選び出すための参考として読んでいただければ幸いです。

(1)データモデル
 Hibariはキー・バリュー型であり、Dynamoと同じく、キーとバリューが対になるデータモデルです。それに対し、Hadoop/HBaseやCassandraはコラム指向型であり、ひとつのキーに対して複数のバリュー(値)を格納するコラム(列)を持つことができます。

 Webメールで言えば、キーをMessage IDとして、つねに紐づけられたメッセージ本体をとりだすといった利用方法であればキー・バリュー型のシンプルな構造が便利です。一方で、メッセージ本体に付随する情報、たとえば属性情報などが複数あるといった場合には、キーに紐づくコラム(列)を自由に作り、まとめてバリュー(値)を取り出せるコラム指向型が適していると言えます。

 また、MongoDBのようなドキュメント指向型は、テーブル定義が必要無いことから(スキーマレス)、変更が多いなど、高い柔軟性が求められるケースに適していると言われています。

(2)データの分散方法
 HibariはDynamoやCassandraと同じコンシステントハッシングという方法により、多数並んだサーバーの負荷が均等になるようにデータ格納場所を決めます。さらに、Hibariは、おそらく大規模な商用実装は世界で初めてである「チェインレプリケーション」というデータの複製方法を実装しています。

 これは、(3つのサーバーを1つのチェインとするなど)複数のサーバーからなるチェイン内にHead、Middle、Tailという役割をもつ複製を作り、複数のサーバーに分散格納するというものです。これにより、ひとつのサーバーに障害が起きたとしても、他のサーバーに複製が格納されていることから、システムとしてデータを失うことがありません(図3)。

図3 Hibariの特徴

図3 Hibariの特徴


(3)データの一貫性(Consistency)
 チェインレプリケーションという複製方法は、データの一貫性を保証するという面でも大きな役割を果たします。

 チェインレプリケーションでは、データの「書き込み」はHeadという役割のサーバー(正確にはブリックと呼ぶ論理的なデータの塊)に行い、「読み出し」は常にTailという役割のサーバー(ブリック)から行います。これにより、システムに複数の複製が存在しても、更新前の複製データを読み出すことがありません。

 このような性質を「強い一貫性(Strong Consistency)」と呼びます。Hadoop/HBaseも同じ性質を持ちますが、Dynamoは更新の際には一時的に更新前と更新済の複製が混在する状態を容認します。そのトレードオフとして、「書き込み」の遅延を小さくできるという利点を得ています。Cassandraには、この「一貫性」のレベルを都度設定する機能があります。

 このデータの一貫性は、アプリケーションやビジネスのニーズに合わせて考えることになるでしょう。たとえば、HibariのようにWebメールでは、「読み出す」メールに一貫性が求められます。一方で、受付申込のような「書き込み」が中心となるアプリケーションでは、一貫性よりは速さを重視すれば良いとも言えるからです。

(4)可用性(Availability)と耐用性(Durability)
 分散型のシステムにおいては、一部のサーバーが故障した場合でもシステム全体としては、常にリクエストに対して答えることができるという可用性(Availability)やシステム全体としては動き続けるという耐用性(Durability)が不可欠となります。

 Hibariのチェインレプリケーションにおいては、チェインのなかのひとつのサーバーが故障しても、HeadとTailの役割を自動的に再割当することにより、Headに「書き込み」が行われ、「Tail」から「読み出す」という仕組みを維持します。チェインのなかのサーバーが1台となる場合でも、その1台がHeadとTailの役割を同時に果たします。Hibariでは、冗長構成の管理サーバーが、論理ブリックを随時監視し、障害時やサーバーの追加や置換のオペレーションを行います。

 一方、Hadoop/HBaseでは、マスターサーバーがデータを格納したタブレットサーバーの監視、追加や置換といったオペレーションを行います。DynamoやCassandraは管理サーバーを持たず、サーバー相互間でそれぞれの状態を監視し合うという特徴があります。また、速さを重視しメモリーだけにデータを格納すると、サーバー障害や電源オフの際、そのデータは消えてしまうため、内蔵ディスクに対しデータの書き込みを同時に行うことでデータロスを防ぐという仕組みも、Hibariをはじめ、Hadoop/HBaseやCassandraなどは備えています。

*************************************************

 ここまで、Hibariを中心に、最近注目を集めているHadoop/HBaseやCassandraなども含めて特徴を整理してきましたが、NOSQLと分類されるデータベースはまだまだ世界中に数多くあります。

 これらのソフトウェアは多くがオープンソースであり、誰もが無料で利用することができます。解説本も書店で見かけるようになってきていますし、Big Dataをすでに経験している、またはその時代を予見している感度の高い技術者が主催する勉強会も数多く開催され、資料も公開されています。

 これらのNOSQLを試してみてはいかがでしょうか。Hibariも以下のサイトから何時でもダウンロードもすることができます。ぜひ、利用してみてください。
https://github.com/hibari/

 次回は「オープン化とBig Data技術」というテーマで、オープンソースにする理由やそのビジネスについて解説する予定です。

(2010年12月3日掲載)

前ページへ12連載目次へ
page top