2010/08/30

Hibari presentation at Tokyo Erlang Workshop

先日、第5回Erlang分散システム勉強会(Tokyo Erlang Workshop)において、Hibariのプレゼンテーションの機会をいただきました。大きな集まりにおける初めてのHibariのプレゼンテーションです。限られた時間でお伝えしたいことがたくさん有り、日本語で概要をご説明し、技術的に詳しい内容は英語で開発者よりお伝えするというご説明方法となりました。

参加いただいた皆さんには、とても真剣に耳を傾けていただき、心から感謝しています。また、とても鋭いご質問をいただきました。未だ英語のドキュメントがあるだけですので、リソースの関係で段階的にはなりますが、日本語でお伝えできるようにしていければと考えています。Slideshareの資料をご覧いただければ、英語での説明内容も日本語でカバーされているとは思いますが、Q&Aについて、ここで簡単に補足も含めてご紹介しておきたいと思います。

(1) Amazon S3のクライアントAPI
Amazon S3のクライアントAPIについてご質問をいただきました。現在、商用済み(Production-ready)システムのクライアントAPIにはUBFとNative Erlang Client APIを利用していますが、その他、Amazon S3、JSON-RPC-RFC4627によるクライアントAPIも用意しています。ただし、このAmazon S3は、GeminiでProductionはしていませんので、もしご関心のある場合には、ぜひとも、ご利用いただき、フィードバックいただければと考えています。

(2)Chain Replication
Chain ReplicationのFailoverについてご質問をいただきました。Hibariの場合には、CassandraのようなGossipプロトコルを利用しているのではなく、Admin serverが、各チェインを管理しています。このAdmin serverは、このFailoverのようにチェインに何らかの変更を加える必要があるときに機能します。

(3)Readのレイテンシー
HibariのRead(読み出し)のレイテンシーについてご質問をいただきました。Write(書き込み)のレイテンシーについては、Hibariは、fsyncによりDiskへのWrite(書き込み)を確認すること、またチェインの構造からWrite(書き込み)をシリアライズしている一方で、HBaseはfsyncがなく、またCassandraとともにWrite(書き込み)をパラレルで処理しているため、レイテンシーに差がでるとプレゼンのなかでご説明いたしました。一方の、Readに関しては、小さいValueの場合に1ms(ミリセカンド)程度の差が生じますが、パフォーマンステストの条件により充分に変わり得る(現在、YCSBパフォーマンステストを実施中です)と説明いたしました。むしろ、このRead(読み出し)が安定的であるといことは、アプリケーションを開発する方々にとって開発し易いというメリットがあるのではないかと考えています。

(4) github
Hibariは、なぜgithubを利用しなかったのかというご質問をいただきました。すでにgithubにもミラーサイトがありますが、Sorceforgeを利用した理由は統計機能が充実しているからとお答えしました。以前このブログでもご紹介いたしましたが、この統計機能により、世界中の国からのDLの数を知ることができます。リリースして約1カ月が経ちますが、あと数日で1000DLになると思います。その際にはぜひお知らせさせていただきます。

http://github.com/norton


(5)Network Partition
Chain Replicationという仕組みにおけるNetwork Partitionについてのご質問をいただきました。このNetwork Partitionとはネットワーク分断という意味ですが、ご質問の趣旨はPartition Tolerance(分断耐性)、つまり、ネットワークに一部障害があっても誤ったレスポンスを返さないという耐性についてのご質問と理解しています。未だに各種議論が絶えないBrewerのCAP定理においては、一般的にデータベースにおいては、Consistency(一貫性)、Availability(可用性)と、このPartition Tolerance(分割耐性)の3つの条件のうち、2つしか満たせないとされています。

Hibariの場合には、複数の複製(Replica)が存在する分散環境にあっても、Diskに書き込みを確認したデータだけを読み出すというConsistency(一貫性)と正常動作しているノードが受け取った全てのリクエストに対して必ずレスポンスをするというAvailability(可用性)を重視しています。しかし、最近では、実際のオペレーションにおいては、このAvailability(可用性)とPartition Tolerance(分割耐性)は排反事象だろうか?というような議論もあります。特に、Network Partition(ネットワーク分断)に際してはAvailability(可用性)までも失われるケースもあり得ますので、このPartition tolerance(分断耐性)については、さまざまなケースを想定しなければなりません。

詳細なケース分けは、バックアップ資料にあります。これを簡単に説明すると、Admin serverの分断については、3つのAdmin serverを配置することで分断耐性を持つことができます。一方、ChainのなかのHead、Middle、Tailの各ノードに関しては、仮に、Headが分断されたとしても、Middleがその役割を担うというように、Chainのなかで常にHeadとTailの役割が新たに割り振られます。その点では、Chainのなかでは分断耐性があります。しかし、仮にHead、Middle、Tailの3つのノードを含むChainが分断された場合には、分断されたChain側のクライアントに対しては結果的に(Eventually) 正しい答えを返しますが、異なる側からの書き込み、読み出しはできないという状況になります。この場合にはネットワーク全体としては、やがてConsistency(一貫性)を失うことにつながります。その場合にはAvailability(可用性)を犠牲にして、分断された側をストップさせてもConsistency(一貫性)を保つという対応も必要であろうと考えているところです。

なお、クライアントが分断された場合には、クライアントがAdmin serverと同じ側にあり、かつChainのサブセットが残っていれば分断耐性はありますが、完全にクライアントがChainから分断された場合と、クライアントがAdmin severと異なる側にある場合には分断耐性は無くなります(どんなシステムでも同じことが起きるのかもしれません)。

実際のオペレーションにおいて、このように分断される状況が発生しないようなネットワーク構成をとり、運用が行われるはずですが、バックアップ資料のようなさまざまなケースが想定され、またその組み合わせもあり、私たちとしても、さらに深く議論し、考えていきたいと思います。

Hibari Open Source Projectのメーリングリストなどにおける議論も大歓迎ですので、一緒に考える機会をいただければと思います。
Hibari at TEW5 (japanese)
View more presentations from geminimobile.

2010/08/26

Summary of "Cassandra" for 3rd nosql summer reading in Tokyo

第3回目となる"nosql summer reading in Tokyo"の論文は、最近注目を集めているCassandraをとりあげました。Cassandraは、以前ご紹介したGoogleのBigTableとAmazonのDynamoの良いところを合わせたと言われているとおり、論文からもそれを伺い知ることができます。

たとえば、分散されたノード間に主従関係を作らず、Gossipプロトコルにより、サーバー相互間で連絡をしあい、あるサーバーに障害が起きていないかと監視するという優れたメカニズムが実装されています。

また、SQL以外という意味で幅広いNo-SQLという分野においてコラム指向と分類されるように、キーに紐づくひとつのrow(行)に対して、いくつにでも増やせるという複数のコラムを持つことができます。そして、そのコラムはコラムファミリーとして、複数のコラムのグループをつくることもできます。このようなコラムのグループを作ることにより、検索を容易に行うことができるというメリットを得ることができます。

そして、この論文には言及されていませんが、データの一貫性(Consistency)のレベルを設定できるという点にもメリットがあります。たとえば、一貫性(Consistency)のレベルを、ゼロと設定すると、データの一貫性を全く確認することなく、書き込み/読み出しを実行します。以前にもご紹介した「Eventual Consistency(結果整合性)」を受け入れることができるアプリケーションの場合には、このトレードオフとして良いレイテンシーを得ることができるはずです。逆に、書き込むノードの数と読み出すサーバーの数の合計が、レプリカ(複製)する数よりも多いQUORUMに設定すれば、「強い一貫性(Strong Consistency)」を得ることもできます。この設定は、クライアント側で、書き込み/読み出しの都度設定します。

Hibariは、この人気が高いCassandraのAPIを利用できるように準備をしているところです。Hibariの場合は、Cassandraのようなコラムを複数持つデータモデルではなく、キーとバリューが対となるキー・バリュー型に分類されます。そのため、複数のコラムを持つCassandraのアプリケーションがHibariを利用する際に、複数のコラムファミリーでグループ化されたコラムを、ひとつひとつのコラムとします。また、HibariはChain Replicationにより「強い一貫性(Strong Consistency)」を保証するように設計されていますので、Cassandraのクライアント側で設定する一貫性(Consistency)のレベルに関する情報は必要が無くなります。

このように、HibariでCassandraのAPIを利用するためには、いくつかの仕組みを用意する必要はありますが、「書き込みを重視するCassandra」と「読み出しを重視するHibari」というように、それぞれの持ち味が異なります。

やがて、数多くのNoSQLのシステムに対する理解が深まり、その特徴が明確になり始めれば、アプリケーションのニーズに応じて、それぞれの特徴にあったシステムを選び使い分けることができるようになると考えています。

2010/08/25

Erlang, GB mail box web mail, Hibari

先日、楽天技術研究所様の勉強会でHibariの開発言語であるErlangを中心に、GB(ギガバイト)のメールボックスを提供するWeb mail(私たちはCloud maiとも呼んでいます)と、このGB mail box web mailのデータベースに実装されているHibariについて、開発者からお話をさせていただきました。

楽天技術研究所様では、すでにErlangを用いた開発が進められており、その開発成果のご紹介をいただきましたが、いまだ日本では商用開発に利用しているケースは多くないようです。

Geminiは2008年よりErlangによる開発を始めました。大規模なシステムの一部として高性能の"User Profile"ストレージサーバーが必要でしたが、LDAPとRDBMSでは、ニーズを満たすことができず、Erlangにより自社開発するに至りました。

それ以降、C/C++とErlangを主に開発言語としています。そして、数百万人のユーザーにGBのメールボックスを提供するWebmailという大規模なシステムにおいては、既にC/C++で開発済みの一部コンポーネントを除き、システム全体のほとんどをErlangにより開発しています。

2005年のアイデア段階から、数年かけて開発してきたHibariも、このGB mailbox web mailに実装し、さらにテストやバグフィックスに多くの時間を費やし、より良いプロダクトにしました。

Erlangのメリットは、Big Dataの処理に必要な、複数のサーバーへの分散や並行処理に向いた関数言語であり、また、その効率性や生産性の高さにあります。Geminiの開発者は、分散や並行処理という重たい開発部分はErlangに任せることができるので、「小さなチームで大きな仕事ができる」と良く語ります。

今後、多くの方にErlangを利用していただき、そしてHibariのオープンソースプロジェクトにもご参加いただければと考えています。開発にご興味のある方々のために、いくつかのハンズオンミーティングも計画しています。準備ができましたら、あらためてお知らせさせていただきたいと思います。

2010/08/16

Hibariの由来

とてもありがたいことなのですが、、Hibariにご興味を持っていただいている方々から、たびたびHibariの名前の由来についてご質問いただいています。日本語版のプレスリリースでは、「ヒバリ」について特別な注記をしませんでしたが、英語版のプレスリリースには、次の( )を付けました。


Hibari (meaning "Cloud Bird" in Japanese)


漢字ではHibariは「雲雀」と書きますので、"Cloud Sparrow"が正しいのかもしれません。ただし、Sparrowと表現すると、「Sparrowとは何か?」という質問が続きそうですので、Birdとしました。そして、この漢字を見ていただければ、Hibariは「Cloudのなかで、たくさん使われそうな」技術?というイメージが湧きませんか。


このHibariという名前は、日本、米国、中国系とさまざまな国籍が入り混じったメンバーが、Hibariだけではなく、いわゆるnosqlの技術全般の打合せをしていた最後に、ひとりから「ところで、Hibariという名前はどうだろう?」との提案で、全員が「Hibari?」と、?マークを頭に浮かべながら、考え始めました。


日本人であれば、「ヒバリ」と聞くと、かなりの確率で「美空ひばり(30代後半以上かもしれませんが・・・)」を思い浮かべてしまいます。Geminiは双子座の意味ですので、「双子座の美空ひばり」ファンが開発者だと面白いTweetsもいただきました。渋谷の道玄坂生まれの「ひばり」ちゃんなのですか?という方もいらっしゃいましたが。


Hibariという発音に違和感が無いと言いながら、米国人はGoogleサーチを始めました。すぐに見つかるのは、Hibari(雲雀)というアニメだったようで、Hibariとはアニメか?と質問が続きます。


中国に長く滞在していた日本人がヒバリを中国語(漢字)で調べました。そして、ひとこと、ヒバリは「雲雀」と書くらしいと。中国系米国人が、あー、たしかに雲雀・・、それに同意します。


そんなやりとりで、Hibari(雲雀)という名前は、なかなか良いということになりました。あとづけのように、Hで始まるからApacheプロジェクトでHadoopの次に並ぶとか、HyperScaleというGeminiの別の技術名称と相性が良いとか・・、いろいろな講釈も続きます。


Hibari(雲雀)となりましたが、Hibariを提案した彼の意図はHibari(=Skylark)としたかったとか。彼はStarwarsの大ファン。Skywalkerに始まるSkyシリーズ。分かる人には分かるかもしれません。そう考えると、Hibariの由来はそれなりに深めることができ、それぞれに思いがありそうです。早速、商標登録手続きを始めました。


なお、このHibariの絵はCEOが自ら書いています。Hadoopがかわいい象をロゴにしていることもありますが、基盤技術はBackEndと呼ばれるように、とかく裏方になりがちです。ロゴと言えども、すこしでも多くの人に理解し、親しんでもらうきっかけになれば良いなと思っています。







2010/08/05

Summary of "Amazon's Dynamo" for the 2nd nosql summer reading in Tokyo

第2回目の"nosql summer reading in Tokyo"では、"Eventual Consistency(結果整合性)"を提起したことで有名な、"Amazon's Dynamo"の論文を題材に読書会を開催しました。

この論文以前には、分散環境において複数のノードにレプリカ(複製)されたデータの一貫性(Consistency)を保つことは当然のことと考えられており、先に発表されたGoogleの"Big Table"は、"Strong Consistency(強い一貫性)"が前提となっています。

しかし、その1年後に発表されたAmazonの"Dynamo"は、すべてのアプリケーションが必ずしもデータの一貫性(Consistency)を求めている訳ではないという前提で開発され、そのトレードオフとして、遅延(Latency)が少ないというメリットを得ています。

この論文においては、他にも多くの分散環境に適切に対応する方法が提示されており、そのひとつに"Consistent Hashing"があります。これは、ハッシュ関数を用いて分散化されたノードに、偏りなく、均等にデータを格納するというものです。

なお、Hibariは、"Chain Replication"により"Strong Consistency(強い一貫性)を提供するという点ではDynamoとは異なりますが、この"Consistent Hashing"が実装されています。