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.