2011/10/24

Cloudian-OpenStackディストリビューションについて発表しました。

この数カ月間、Cloudianに関する発表が続いています。米国では10月20日(木)、日本では10月21日(金)に、GeminiはOpenStackコミュニティに参加し、Cloudian-OpenStack ディストリビューション版のソフトウェアパッケージをリリースすることを発表しました。

今回は日本語、英語のみならずロシア語、ドイツ語などでのメディア記事にも掲載されました。ここに、主要な記事をご紹介しておきます。

Cloudianのプレスリリース本文:

English Press Release: Cloudian joins the OpenStack community, Enhance API offerings

日本語版プレスリリース:Cloudianは、OpenStackコミュニティに参加し、 Amazon S3との互換性等を機能追加した 「Cloudian™-OpenStack ディストリビューション」をリリース

主な日本語メディアでの紹介記事:

businessnetwork.jp:Gemini、クラウドストレージCloudianにOpenStack対応パッケージを追加
asahi.com:Geminiは、OpenStackコミュニティに参加し、 Amazon S3との互換性等を機能追加した 「Cloudian(TM)-OpenStack ディストリビューション」をリリース
Cloudzine:「Cloudian™-OpenStack ディストリビューション」をリリース

主な英語メディアでの紹介記事:

Yahoo Finance:Gemini Joins the OpenStack Community, Enhances API Offerings Gemini's Cloudian adds Amazon S3 compatibility, provisioning and billing APIs to OpenStack
ReadWrite Cloud:Cloudian Partnership Opens Up NoSQL Treasure Trove for OpenStack

このうち、ReadWriteの記事を以下に翻訳してみました。

(以下、翻訳)

去る3月、Cloudian(旧:Gemini Mobile Technologies、現クラウディアン)という新しい会社が、革新的なクラウド-ホスト・データベース・プラットフォーム・サービスを開始しました。これは、オブジェクトをCloudianのクラウドに格納し、利用者は「利用した分だけを支払う」というものです。サービスはCloudianという名前であり、今週初め、Cloudianは、Oracleデータベース・クラウド・サービスといったビッグネームに肩を並べるための競争力向上のために、次のステップに踏み出しました。



Cloudianとオープンソースのクラウド・オペレーティングシステムであるOpenStackとの新たなパートナーシップにより、OpenStackのアプリケーション開発者は、Cloudianマルチ・テナントNOSQLデータベースへの接続のために、クラウド・ストレージへのアクセスプラットフォームであるAmazon S3 APIを使うことができます。

Cloudianは、実際のところ、データベース・プロバイダーでも、データベース・フォーマットでもなく、むしろ、S3 APIを経由してNOSQLデータベースに接続できるシステムです。この基本的なダイアグラムが示すように、それはCassandraを含む、多彩なNOSQLバックエンド・オブジェクト・ストレージレイヤーを利用しています。Cloudianの計画では、将来的にOpenStackのSwiftもバックエンド・ストアに加えるとしています。

Cloudianの参画により、クラウド・データベースの光景は、いまはこのように見えます: OpenStackの利用者は、オンプレミスでサーバークラスターを設定するためのSwiftレイヤーを利用しています。これらのクラスターは、あらかじめ準備されたストレージを使い簡単に拡張します。Swiftの実装はS3 APIを真似ています。このため、Amazonスタイルの「バケット」に大小のデータオブジェクトを格納することができます。しかし、それは、実際のところ、本物のS3にオブジェクトを格納することと全く同じではありません。ごくわずかなプロバイダーが、ミドルウェアレイヤーで活動しており、SMEStorageはそのひとつです。これらのレイヤーは、S3ストレージ互換の命令に何かを行います。

Swiftが完全にCloudianの運用領域で統合されると、残る部分はS3パブリッククラウドとしながら、オンプレミスにどの程度のデータを格納させるかという拡張のために、OpenStackを利用できます。パブリックか専用クラウドプロバイダーとして自らS3準拠ストレージサービスを提供し、お客様のデータは、必要があればオンプレミスとS3ストレージ間に分割することができます。 最も重要なのは、すでにS3上で設計構築されたアプリケーションが、代わりに、あなたのS3準拠Cloudianクラスターで展開できるということです。

「新しいノード検知とデータリバランシングはサービス停止なしに自動的に実行されます。そして、「Cloudianは、アーキテクチャ固有の自動複製と復旧プロセスにより、データロスなしに、ネットワークとノード障害から回復します。システムは地域冗長性のために、複数のサイトとデータセンター間に展開できます。アップグレードとアップデートは、サービス停止なく実行されます」と。

2011/10/11

Questions from the Tokyo Cassandra conference (The Japanese Translation Part 2)


Part 1に続き、Part 2です。


http://www.datastax.com/dev/blog/questions-from-the-tokyo-cassandra-conference#comment-17013

今回は後半部分を日本語訳で紹介いたします。

(以下、翻訳:Followings are the Japanese translations)


What is leveled compaction and what kinds of workloads does it help? 
レベル・コンパクションとは何でしょうか? どういったワークロードを助けるのでしょう? 
手短な回答としては、レベル・コンパクションは、(新しい行を挿入することに反して)同一行へ多くの更新も含め、読み出しが多いワークロードに対してより良い性能を発揮します。 もう少し長い回答としては、ブログを書く必要があります。それまでの間、CassandraサミットのLightning TalksでBen Coverston氏がレベルコンパクションに関して説明したスライドとビデオがこちらにありますので参照して下さい。

What management tools are there for performance tuning and recovery? 
性能チューニングと復旧のために、どのような管理ツールがありますか?
 DataStax’s OpsCenter は、クラスター管理と監視に注力しています。
これは、キャッシュサイジングやi/oキャパシティのようなハイ・レベルの性能チューニングに役立ちます。バックアップとリストアの管理はロードマップに載っています。 ロー・レベルの性能チューニングのためには、AppDynamicsやdynaTraceといったものが役立つでしょう。

Does Cassandra offer Hadoop integration? 
CassandraはHadoop統合を提供しますか? 
 はい。Cassandraは、基本的なmap/reduce、Pig、Hiveによる読み書きをサポートしています。DataStaxも、DataStax Enterpriseを提供しており、これは、別個にHDFS、ジョブ・トラッカー、タスク・トラッカーやメタストア不要で、同一クラスターにおいてCassandraとHadoopを利用できるプロダクトです。

How do you add and remove nodes in a Cassandra cluster? 
どのようにして、Cassandraクラスターにノードを加えたり、取り除いたりできますか?
 基本的に既存のシードに新しいノードを加えて起動するだけというシンプルさです。DataStaxのドキュメンテーションの、adding capacity (容量追加)のところに内容が記載されています。

What is snapshot used for? 
スナップショットは何に使われるのでしょうか? 
スナップショットは、クラスターのある時点のバックアップを取れるという素晴らしい機能です。
cassandra.yaml内のincremental_backups設定と組みあわせることで、復旧時に最小限のオーバーヘッドとなるように、きめ細かい調整ができます。
 スナップショットは、ハード・リンクを使って実装されており、これはCassandraのログ・ストラクチャード・ストレージエンジンゆえに可能です。これにより、速さと極めて効率的な容量確保の両方を実現しています。
 スナップショットは、他のクラスターにデータをロードするbulk loaderのためにも使われます。たとえば、本物のデータを使って、アプリケーションの新しいバージョンをテストできるといったようなことができます。私たちは、スナップショットデータに対して直接Hadoopクエリを行えるようにすることも計画しています。

What hardware do you recommend for Cassandra deployments? 
Cassandraをデプロイするうえで推奨するハードウェアはありますか? 
 サーバ以外の機材が同じなのであれば、性能の高いマシンを少ない台数用意するよりも、性能の低いマシンを多い台数用意したいところです。これは、ひとつのマシンの障害が全体のキャパシティに与える影響を少なくします。 経験則として、1Uサーバで充分得られるくらいの性能と考えてください。現在では、8コアで32GBのRAMが最適でしょう。 しかし、これは作業量によります。 もし、Hadoopによる分析を多く行う予定ならば、典型的にディスクスペースやi/oに制約されるでしょう。 もし、重い挿入が中心であるならば、CPUに制約されるでしょう。もし、ランダムな読み込みが多いのであれば、磁気ディスクの代わりにSSDを使うべきです。

 What performance tuning advice do you have at the OS, JVM, and Cassandra levels? 
 OS、JVMとCassandraレベルで、性能チューニングに対するアドバイスをお願いします。
 XFSを使用してください。RADI0かRAID10(ディスクスペースに制約があるかによります)を使い、commitlogのために別のスピンドル(又はRAID1で2つ)を残しておいてください。noopやdeadlineスケジューラを使用してください。 Cassandraパッケージは、重要なJVM設定をしっかり設定します。通常、箱から出して唯一変更するとしたら、マシンのRAMの半分がJVMヒープサイズに割当てられるので、大きなマシンを使用する場合は8GBを上限値として設定するとよいでしょう(これは、Cassandra1.0のデフォルト動作になります)。 私たちは、Cassandraがデフォルトの自動設定で高性能に動くよう最善を尽くしました。あなたがインストールしてすぐに変更したいと思うような項目があるとは考えられません。一度何か負荷を掛け始めた後は、キャッシュサイズのチューニングの項キャッシュサイズのチューニングの項が参考になるでしょう。

Are there best practices for running a cluster on Amazon EC2? 
Amazon EC2上のクラスターで動かす際の良い事例はありますか?
 ローカル・ストレージでLかXLのインスタンスを使用してください: I/O性能はSとMサイズでは比例的に悪くなります。EBSはいくつかの理由で悪い組み合わせです(Erik Omnen氏の素晴らしい説明をご覧ください)。 すべてのEphemeral disksをRAID0とし、commitlogとデータの両方をそのボリュームへ置いてください(これは、rootボリュームにcommitlogを置くよりも良いことがテストされています)

How does Cassandra compare to OpenStack? 
CassandraとOpenStackを比較してどう思いますか? 
 これらは全く別物です。Cassandraは、高性能分散型データベースです。OpenStackは、クラウド管理ソフトウェアです。OpenStackのクラウド内にCassandraをデプロイしたり、CassandraをOpenStackに組み込んで、コンフィギュレーションと監視データを格納することはできるかもしれません。しかし、そうでなければ、それらは全く関係ありません。

What considerations are there for running repair in a cluster with a few tens of servers? 
 数十台のサーバーのクラスターでリペアを走らせる際に考慮すべき点は? 
 最も考慮すべきは、repair merkle treesの構築は、(今のところ)かなり重い処理です。そのため、通常は同時にひとつ以上動かさないほうがよいです。ひとつのマシンでリペアを動かし、それが終わったら次を開始してください。 もし、リペアにより性能が悪くなるようであれば、cassandra.yaml内のcompaction_throughput_mb_per_sec設定を減らしてください。

2011/10/07

HyperStoreのプレスリリースを行いました

10月5日のCassandra Conference in Tokyoにて、GeminiのグローバルR&Dを統括するGary Ogasawaraから、NOSQLデータベースとしてCassandraを利用している、Amazon S3準拠のクラウドストレージサービスのためのパッケージソフトウェア、Cloudianについて説明をしました。

多くの方に直接説明できる機会は、たいへんに貴重です。そのため、Cloudianの性能とディスクの利用効率を向上するために開発したHyperStoreについて紹介をし、それを公開したことから、併せてプレスリリースも行いました。

今回も多くのメディアで紹介され、また多くのRTもあり、たいへんに喜んでいます。主な記事は次のとおりです。

ITPro:ジェミナイ、Cassandraを使うクラウドストレージの新機能を開発

businessnetwork.jp:Gemini、クラウド・ストレージCloudianの処理性能とディスク利用効率を向上するソフトウェアを開発

asahi.com: Geminiは、Amazon S3準拠クラウド・ストレージ「Cloudian(TM)」において 処理性能とディスク利用効率を向上する『HyperStore(TM)』を開発

HyperStoreの構成図です。

HyperStoreによる(初期的な)性能試験結果です。

Questions from the Tokyo Cassandra conference (The Japanese Translation Part 1)

10月5日のCassandra Conference in Tokyoの翌日、10月6日にジェミナイ・モバイル・テクノロジーズに、Apache Cassandraプロジェクトのチェアマンであり、DataStaxの共同設立者であるJonathan Ellisが来訪し、Cassandra Talk Sessionを開催する予定でした。

会議室の関係で参加人数が限定されてはいましたが、参加予定の皆様には、Cassandraに関する質問を事前準備いただいていました。残念ながら、急遽、来日が中止となったことから、以下のブログで質問に対する回答を公開してくれました。

http://www.datastax.com/dev/blog/questions-from-the-tokyo-cassandra-conference#comment-17013

多少長いので、今回は前半部分を日本語訳で紹介いたします。

(以下、翻訳:Followings are the Japanese translations)

Tokyo Cassandra Conferenceに際し、私のほうから事前に質問をお願いしたところ、お蔭様でとても良い質問の数々を受け取ることができました--コンファレンスの枠内だけでは応えきれないほど多くの質問を頂いています。そのため、それらの質問に関する回答を公開しておきます。

How is Cassandra different from other NoSQL databases?
Cassandraは他のNOSQLデータベースとどう違うのですか? 
Cassandraは、性能、拡張性、高可能性における最良の組み合わせを提供します。他の選択肢ではこれらの軸の少なくともひとつは欠けています。

完全分散で単一障害点が無いことによる拡張性と高可用性は、極めて簡単に理解されます。しかし、性能については、もう少し詳細に説明をしたいと思います。

あまり評価されていないCassandraがもつ能力の特徴として、カラムファミリーのデータモデルで、動的なカラムを使えることから、そうでなければJoin(結合)が必要となるような複雑なクエリをさせるためのマテリアライズド・ビューを事前に計算できるという点です。

How does Cassandra deal with network and hardware failure?
Cassandraはネットワークやハードウェア障害にどのように対処しますか? 
Cassandraは、2つの方法で障害に対処します。

まず、そのFAILURE DETECTOR(障害検知)により、ピア・ノードがダウンや接続不可といった障害を検知します。

次に、DYNAMIC SNITCHが、実際にはより難しいタスク(たとえば、ディスク障害のために)性能が劣化しているノード検知した時に他のレプリカにクエリ要求のルーティングを実行します。

Cassandraの堅牢な部分は、マスターも特別なノードも無く、普通に障害に対処します。


What is the roadmap for future Cassandra releases?
将来のCassandraリリースのロードマップは? 
私見ですが、Cassandraのコア部分は現在たいへん優れており、これからは使 い勝手の向上に注力していく時期だと思います。これは、運用面での向上とい うよりも、Cassandra上でアプリケーションをより容易に開発できることを指し ます。

DataStaxが準備を進めているのは、 CQL enhancements、 triggers、entity groups、smarter range queries です。


What important performance considerations are there when deploying across multiple data centers?

複数のデータセンターに展開する際、性能面で考えるべき重要な点は何でしょうか?
重要なことは(データセンターが地理的に離れているとの前提で)、QuorumConsistencyLevel は良いオプションでは無いということです。なぜならば、少なくとも1つのコーディネーターと全てのデータセンターは、クライアントリクエストを取り扱うために他のデータセンターとの間の往復遅延を待たねばならないことが良くあるからです。

妥協点として、CassandraはLOCAL_QUORUMにより同じデータセンター内で他のクライアント との強い整合性を保証できるようにしています。そして、当然のことながら、 ConsistencyLevel.ONE でほぼ十分ではないでしょうか:私はアプリケーション の約60%はもっぱらONEを使うと見込んでいます。

What are your thoughts on strong consistency via R/W=One/All?
R/W=One/Allにおける強い整合性に対しては、どのように考えていますか? 
厳密に言うと:この質問は、読み出しConsistencyLevelをONE、書き込みをALL に設定して如何に強い整合性を得られるか解釈できます。

 私は、これは汎用的な設定として良いとは思いません。なぜなら、いくつかのノードが落ちるとクラスターが書き込み不能になるからです。そのことが、強い整合性が必要な際には、読み出しと書き込みを両方Quorumで実行させる理由です。しかし、それが適切な場合のシナリオも想像できます。たとえば、書き込みは定期的にバルクで書き込み、それ以外のワークロードは読み出しだけという場合です。

Is it possible to use journaling filesystems like XFS or Btrfs? Can you mix different filesystems across different machines in a cluster?
XFSやBtrfsのようなジャーナリングファイルシステムを使うことは可能ですか? クラスター内で異なるマシーンをまたがり、異なるファイルシステムを混在できますか? 
イエス、イエスです。最近、DataStaxはCassandraにXFSを推奨しています。ついでながら、私はBtrfsの性能改善の報告を聞いていますが、それがもう少し安定するまで、Btrfsの商用利用は慎重に考えたいと思います。

ファイルシステムの選択はマシン固有です。言うならば、クラスターの他のマシンが何のファイルシステムか判りませんし、何であろうと構いません。Cassandraはひとつのクラスターで異なるオペレーティングシステムの混在はサポートしません。たとえば、WindowsクラスターやLinuxクラスターはできますが、Windows/Linuxクラスターはできません。

私は、試験環境で異なるファイルシステムをテストすることは良いですが、商用環境におけるベストプラクティスは、異常を調べる際に、トラブルシュートが必要なところを絞り込むために、できるだけ物事を同一にしておくことに気を配ります。


Does Cassandra support multiple storage devices per server?

Cassandraは、サーバー毎に複数のストレージデバイスをサポートしますか? 
はい。Cassandraは、cassandra.yamlに複数のdata_file_directories を指定できます。
しかし、JBODコンフィグレーションよりも、RAID0 かRAID10 が推奨されます。

Can you give an example of troubleshooting a Cassandra cluster?
Cassandraクラスターをトラブルシューティングする事例紹介をお願いできますか? 
数ヶ月前、あるお客様で、ディスクスペースが一杯になってしまった1つのCassandraのノードがありました。ファイルシステムを調べると、スペースの大部分がcommitlogセグメントにより占められていることがわかりました。

私たちには、調べることが2点ありました。何故、このノードは、クラスターの他よりも高いレベルの書き込み量を扱っていたのか?、そして、何故、期待されているようにcommitlogセグメントは消去されなかったのか?

最初に私達が行ったことは、Cassandraのlogファイルの確認です。それは、予想外に高い書き込みデータ量がありましたが、それ以外に異常はありませんでした。クラスターの他のノードのログを観ると、それらの多くで、書き込み量が最高に到達する前に、hinted handoffを実行し始めていることが疑わしく見えました。

お客様に確認すると、この前の間に、そのノードはダウンしていました。クラスターの他に対して高い書き込み負荷を続けており、ノード復旧の際に送られてくる大量のヒント(hints)があるということは、納得できます。

しかし、commitlogセグメントが消去されないのは何故でしょうか? 私たちは、お客様にcommitLogクラスのデバッグロギングを有効にしてもらいました。そこで、memtableがフラッシュするに充分な大きさが無い、セグメント毎にわずかな書き込みだけを受け付けた少量のカラムファミリーがあったことが分かりました。フラッシュされないデータが残っていることで、commitlogセグメントは消去されなかったのです。

私たちは、お客様に対して、より頻繁にそれらをフラッシュするように、memtable_flush_after_mins設定 を少量のカラムファミリーにすることを推奨しました。また、ヒント(hints)リプレイが過剰にならないようにmax_hint_window_in_ms設定を減らすことを推奨しました。

最終的に、私達は、将来、この問題を容易に回避できるよう、memtable_flush_after_minsをcommitlog_total_space_in_mbに取り替えるという問題定義(管理番号)を設けました。このフィーチャーは、Cassandra1.0から利用可能になります。

・・Part2に続く。