2011/12/06

Cloudian Partners Summit 2011を開催しました

2011年12月6日は、このブログでもご紹介している2件のプレスリリースがあり、たいへんに慌ただしいなかでしたが、初めての「Cloudian Partners Summit 2011」を開催いたしました。渋谷のセルリアンホテル会議室に40名近くの出席者をお迎えすることができました。


Cloudianは、当初の開発コンセプトはクラウドサービス事業者向けとして開発しました。そのため、クラウドサービス提供に不可欠である統計課金機能、ユーザー・グループ管理機能、利用量の制御機能など、いわゆるサービスプラットフォームがあらかじめ実装されています。また、クラウドサービスを短期間で開始できるよう、インストールが簡単なパッケージソフトウェア製品に仕上げています。

そして、2011年7月19日に商用版をリリース後、約2週間後の8月1日にはクララオンライン様のβサービスに採用いただき、約2ヵ月後の9月29日にはニフティ様の「ニフティクラウドストレージ」が商用サービスを開始されています。

ただし、様々なお客様にCloudianをご紹介するなかで、Amazon S3 REST APIに完全準拠している製品はCloudianだけであり、これを自社のデータセンターで構築するプライベートクラウドに利用すれば、パブリッククラウドとの相互バックアップに使えるというお声をたくさんいただくようになりました。

Geminiはソフトウェア開発にフォーカスしているベンチャーです。そのため、このような広範なニーズにお応えするためには、すでに多く経験を積んだパートナーが必要であると考えました。パートナーの力を借りることで、Geminiだけではお会いできないお客様にもCloudianをご紹介でき、その業界にあった専門的な技術サポートも提供してもらえることが期待できます。

このような背景で、パートナー制度を導入することを決め、この「Cloudian Partners Summit 2011」を開催するに至りました。

当日は、ニフティ様から、Cloudianを選んだ理由(そして、苦労した点も少しだけ)をはじめとした、たいへんに貴重な講演もいただきました。

当日の出席者の皆様には、GeminiオリジナルのCloudianワインを記念にお贈りしました。


Cloudianのパートナーにご興味のある方は、こちらのクラウディアン株式会社のホームページよりお問い合わせください。来年のワインはもっと熟成?しているかもしれません。

ミドクラ、クリエーションライン、Geminiの3社提携について発表しました

2011年12月6日、Cloudianが「ニフティクラウドストレージ」への採用に関する発表と同時になりましたが、ミドクラ様、クリエーションライン様とGeminiの3社提携について発表しました。

戦略的提携の目的としては、「今回提携を行う3社は、それぞれクラウドプラットフォームで必要となるサーバ、ストレージ、ネットワークの各仮想化レイヤーにおいて、多くの導入実績とノウハウを持っており、各社の持つ技術とソリューションを組み合わせることで、このクラウド対応の流れを更に加速すること」であり、

「今回の提携により、高価なアプライアンス製品ではなく汎用IAサーバによるフルラインアップのクラウド環境が実現できることはコスト・柔軟性・規模拡張性において大きな効果を発揮します。それぞれの仮想化レイヤーのAPI連携することにより、レイヤーを跨いだ統合的なプロビジョニング・運用管理を可能にし、コスト・柔軟性・規模拡張性に優れたクラウドプラットフォームを提供」することをねらいとしています。 

この発表も多くのメディアにて記事にしていただきました。特に、Public Keyには、次のようなタイトルの記事で大きく掲載されました。

  「x86サーバがクラウドの万能細胞になる。サーバもストレージもルータ/スイッチも、x86サーバだけで実現。クリエーションライン、ジェミナイモバイル、ミドクラの3社が提携」

Cloudianについても、

「ジェミナイ・モバイル・テクノロジーズが提供する「Cloudian」は、x86サーバのクラスタを用いてクラウドストレージ機能を実現するソフトウェア。内部でNoSQLのCassandraを用い、分散ストレージによる高信頼を実現しつつ、AmazonクラウドのS3互換APIを提供します。」と紹介されています。

「3社の提携は、このx86サーバを万能細胞としたクラウド構築を一挙に実現してしまおうという大いなる野望を秘めていると同時に、従来のクラウド構築を大きく変える可能性を持っている点で注目に値します。」という期待を込めたコメントをいただいています。この期待に沿えるよう、3社でエキサイティングな展開をしてみたいと思います。

Cloudianが「ニフティクラウドストレージ」に採用いただいたことを発表しました

2011年12月6日、Cloudianがニフティ様が提供するクラウドストレージサービスである「ニフティクラウドストレージ」に採用され、本格稼働していることについて発表いたしました。ニフティ様より、以下のエンドースメントをいただき、関係者全員が心から喜んでいます。

 「Gemini様の本報道発表を心より歓迎いたします。 「ニフティクラウドストレージ」は、2011年9月29日に正式公開した容量無制限で自由自在に伸縮できるクラウドストレージサービスです。これまで『ニフティクラウド』が提供してきたシステムリソースに加え、「ニフティクラウドストレージ」をラインナップとしていち早く拡充できたのも、Gemini様から多大のご支援を頂いたことが大きいと考えております。今後も、『ニフティクラウド』はGemini様とともに、クラウドコンピューティング市場でこれまで以上の価値を提供してまいります。」

 このプレスリリースは多くのメディアに記事にしていただきました。

asahi.com: Geminiの「Cloudian(R)」が「ニフティクラウドストレージ」に採用され、 本格稼働

businessnetwork.jp: GeminiのCloudianがニフティクラウドストレージで本格稼働、ミドクラ等との戦略提携も発表

TechTarget Japan: ニフティクラウドストレージが採用したパッケージ製品 Gemini

また、英語でもプレスリリースを行ったところ、400を超える海外メディア記事で紹介されました。

Yahoo! Finance: Nifty Selects Gemini's Cloudian(R) for the Nifty Cloud Storage Service Software Enables Full S3 REST Compliant Multi-Tenant Cloud Storage

CloudianS3 REST APIに完全準拠していることから、S3 REST APIを使っているWebサービス、アプリケーションは何も改修せずに、「ニフティクラウドストレージ」を利用することができます。ぜひ、ご利用になってみてください。

ニフティクラウドストレージについての詳細はこちらです。Cloudianのロゴも掲載いただいていますので、ぜひご覧ください。

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に続く。

2011/09/29

Cloudian英文記事のご紹介

去る9月7日、英文でのCloudianの商用版提供開始に関するプレスリリースを行いました。日本でのプレスリリースである7月19日から約1カ月半を経てからです。

これまで数回のプレスリリースの経験では、英文でプレスリリースを行うと、世界中から問い合わせが寄せられます。今回も例外ではなく、プレスリリース以降、米国などの英語圏から内容に関する問い合わせが米国オフィスに寄せられたことはもちろんですが、メキシコ、中国、ナイジェリア・・・といったお客様からもCloudianの評価版ダウンロードのお申込みをいただくことになりました。

その経験があることから、Cloudianの商用サービス開始を控えている、日本のお客様にリソースを集中するため、英文のプレスリリースを遅らせました。

幸い、たいへん面白い2つの英文記事にCloudianが紹介されましたので、御紹介します。

eWeek: “ Gemini unveils noSQL-based storage platform http://blogs.eweek.com/storage_station/content/general/gemini_mobile_unveils_nosql-based_storage_platform.html


Network Computing: “ Always-On with Amazon S3 ”  http://www.networkcomputing.com/cloud-storage/231602290

このうち、”Always-On with Amazon S3"を翻訳してみました。

”Always-On with Amazon S3"
Stephen Foskett

Amazon S3は、エンタープライズからスタートアップに及ぶストレージユーザーを惹きつけながら、確実に成長を続けています。しかし、多くのユーザーはS3にすべての卵を置いておくことを心配しており、他社は挑戦を始めています。最近、NasuniGeminiが、Amazon S3のユーザーの心配を和らげる可能性のあるプロダクトの概要を伝えてくれました。彼らは全く別のアプローチをしていますが、それぞれが、エンタープライズ・クラウド・ストレージ利用者に、複数のプロバイダー間のストレージのバランスをとることを可能にします。

クラウディアンは、最近、Cloudianを提供開始しました。それは、Amazon S3のAPIに準拠したクラウド・ストレージ・ソフトウェア製品です。この製品は、サービスプロバイダーにとって、既存のAmazon利用者に簡単に利用してもらえるクラウドストレージサービス提供を可能にします。Geminiは、S3に対するAmazonの開発に合わせ続け、可能な限り完全に特徴を同じくするつもりです。

サービスプロバイダーは、自身のクラウドストレージサービスを創り出すためにCloudianを利用します。利用者は、どんなAmazon S3準拠アプリケーションにも、このクラウドストレージソリューションを利用させることができます。Geminiは、利用者は、このサービスをAmazon S3の代替として利用するであろうと語っているものの、私は、多くのユーザーは、それを商用か開発のためにS3と同時に利用しながら、高可用性か、ディザスターリカバリーとして観るだろうと考えています。

しかし、どうやって、利用者は一度に複数のクラウドストレージを利用するのでしょうか? アプリケーションで両方に振り向けるようプログラムする際、S3準拠であることは、その実装をとても簡単にさせます。市販のアプリケーションも、利用者に適切な認証方法を組み込めば、Cloudianサービスプロバイダーに接続することができます。

他のクラウドストレージ・イネブラーも存在していますが、Amazon S3をしっかりと反映していると聞いたのは、Cloudianが初めてです。MezeoScalityClevesafeのようなソリューションは、S3準拠のコネクターのほかに、それ自身のAPIも含んでいます。OpenStackは、処理とディスクイメージとともに、S3機能のサブセットを実装している、最も近い代替ではあります。しかし、完全にS3ソリューションを実装するという方向性は、魅力的です。

しかし、必ずしも全てのアプリケーションが、クラウドストレージを使う訳ではありません。それらにとっては、Nasumiストレージ・コントローラーは良い代替です。オンサイトのスケールアウトNASアプライアンスであるNasumiは、目立たぬように、高可能性とディザスタリカバリーのためにクラウドストレージを利用しています。それは、Amazon S3を含む多くのクラウドストレージソリューションに、透過的にローカルデータを反映します。

Nasumiは、APIにかかわらず、複数のクラウドストレージプロバイダ―に、データをミラー(反映)することができます。これは、クラウドを本質的に信じていないだけではなく、彼らのベンター達を長期間利用し続けることが不確かであるエンタープライズ利用者から人気を集めています。

これらは、クラウドサービスプロバイダーがもはや利用できないという時には確実に面白くなります。ディザスタの際(または、たとえサービスプロバイダーがビジネスをしていたとしても)、Nasumiは、他のプロバイダーにデータアクセスをリダイレクトできます。これは、彼らのストレージ・コントローラーがローカルデータとクラウド間を紐づけていることにより可能となります。この機能を使い、データを、あるサービスプロバイダーから他に移行するためにNasumiを使うことさえあります。

結局のところ、利用者は、彼らの卵を他の誰かのバスケットに喜んで置きたいと望むほどはAmazonに対して心配はしていません。むしろ、かれらは、複数のプロバイダーを使うことにより、リスクのバランスを取りたいと思っています。NasumiとCloudianは、それらのソリューションとしての構成要素となるのでしょう。




2011/09/10

Cloudian presentation at U-Stream

9月8日(木)の第3回クラウドストレージ研究会にて、COOのMichael Tsoが、Cloudianのプレゼンを行いました。プレゼンの模様が、次のUstreamにアップされています。日本語の逐次通訳付きです。ぜひ、ご覧ください。

Michael Tso, COO of Gemini Mobile Technologies, presented Cloudian at the 3rd Cloud Storage meet-up on September 8. Presentation is uploaded to the following Ustream. Presentation is given by English. Please check it out.



2011/08/02

Cloudian (クラウディアン)のプレスリリースを行いました

日本でも本格的なクラウドストレージサービスの登場が期待されているところですが、Geminiは、去る7月19日、Amazon S3と同様のクラウドストレージサービスをマルチテナント(複数のユーザー)に提供することができ、かつ統計、課金、利用量制限(QoS)などのプラットフォーム機能を予め実装したパッケージソフトウェア製品であるCloudianの商用版リリースを発表しました。

実は、このCloudianの試験版リリースは、3月11日に日米同時に発表していました。しかし、プレスリリースした直後に東日本大震災。国内だけではなく、海外においても、そのニュース一色。多くの方の目に触れる機会の少ない発表となってしまいました。

しかし、7月19日のCloudianの商用版発表においては、多くのメディアにご紹介いただきました。

businessnetwork.jp: Gemini、ビッグデータのストレージに最適なCloudianソフトウェアをリリース

ITPro: ジェミナイ・モバイル、Amazon S3準拠API備えるクラウドストレージ構築ソフト

クラウドWatch:Gemini、ビッグデータのクラウドストレージに最適な、Amazon S3準拠「Cloudian」の商用版

CloudZinel[Gemini]ビッグデータのクラウドストレージに最適な、 Amazon S3準拠「Cloudian™」の商用版ソフトウェア製品をリリース

また、このCloudianの商用版リリース発表の約2週間後の8月1日。株式会社クララオンライン様が、Cloudianを使用した商用のクラウドストレージサービス提供開始の発表をされました。7月19日のGeminiの発表では、年内にCloudianを使用した商用クラウドストレージサービスが開始される「見込み」とお伝えしていましたので、当方も驚くほどのスピード感です。この発表も、多くのメディアで紹介されました。

businessnetwork.jp: クララオンライン、ギガバイト単位課金のクラウドストレージ ~ GeminiのCloudianで実現

japan.internet.com: クララオンライン、Amazon S3 準拠クラウドストレージサービスを提供開始

ビジネス+IT:クララオンライン、Amazon S3準拠のクラウドストレージサービスを提供開始

CloudZine: [Gemini]Amazon S3準拠クラウドストレージサービスの提供開始のお知らせ ギガバイト単位課金を実現したクラウドストレージのβ版サービス開始

読売新聞オンライン: Amazon S3 準拠のクラウドストレージサービス開始

Cloudianについては、これからもご紹介できる機会がたくさんありそうです。グローバルに向けた英語版での発表も控えています。どうぞ、御期待ください。

2011/07/15

「みてわかるクラウドマガジン vol.3」にCloudianが紹介されました

7月14日発売の日経BP社発行「みてわかるクラウドマガジン vol.3」の第2章「進化するNOSQL」のPART4(47頁~51頁)に、「Cassandraをマルチノードで動かしてみる」、続けてPART5(52頁~54頁)にも、「プライベート版Amazon S3を構築できるCloudian」と題したGeminiの執筆記事が掲載されています。

「Cassandraをマルチノードで動かしてみる」は、3台で構成するマルチノード環境を体験するために、異なるIPアドレスを設定し、1台の物理サーバ上に複数のインスタンスを立ち上げます。そして、そのうち2台のノード(インスタンス)が停止した場合の自動復旧の様子を確認してみるというものです。コマンドのオペレーションが中心ですので、エンジニアの方々に役立つ記事かと思います。

もともとの原稿で頁数の制約で掲載できなかった部分は、以下のようなCassandraがクラスター内でデータをレプリケーションさせる方法の解説やv0.7とv0.8の新しい機能についてでした。別の機会があれば、ぜひとも御紹介したいと思います。


また、Cloudianについては、法人であればこちらのサイトから申し込むことにより、30日間試験版を使用することができますので、そのインストール方法について説明しています。


来週7月19日(火)には、Cloudianの商用版リリースと使用料金に関するプレスリリースをする予定です。詳細は、ぜひ発表をご覧ください。



2011/07/09

Hibariの日本語プレゼン

2011年7月8日に開催された「第1回分散処理ワークショップ in Tokyo」にて、ジェミナイの河野達也がHibariの紹介を行いました。これまでは、英語でのプレゼンだけでしたが、初めての日本語でのプレゼンとなりました。

当日のプレゼン資料がスライドシェアにアップされています。



また、当日の模様は、U-Streamでご覧になることができます。


2011/05/09

NOSQL, Cassandra, Hibariのハンズオントレーニングを開催しました

去る4月25日(月)、26日(火)、27日(水)、第4回目となるNOSQLとCassandraのハンズオントレーニング、今回初めてとなるHibariのハンズオントレーニングを開催いたしました。

NOSQLとCassandraのハンズオントレーニングには、Webサービスの開発者やCassandraコミュニティで活躍されている方々に加え、大手の通信事業者のR&D部門と企画部門、ハードウェアベンダー、システムインテグレーターなどから多くの参加者をお迎えしました。そして、Hibariのハンズオントレーニングには、前回のNOSQLトレーニングを機にHibariに興味を持っていただいた方々やErlangのコミュニティで活躍されている方々にもご出席いただけました。

Hibariについては、昨年6月にオープンソースとしてリリース以降、多くの方に関心を示していただいていたものの、商用開発した大規模なシステムのコンポーネントを切り出して、オープンソースとしたNOSQL/キー・バリューデータベースであり、かつドキュメントも英語であり、「難しい」とのご意見と、ハンズオントレーニングに対するご要望もいただいていました。そのため、時間がかかりましたが、より利用しやすいように、GitHubに移行し、パッケージ化し、日本語のガイドを整えてきました。

資料はGitHubで公開してありますので、ご興味があればぜひご利用ください。

Hibari アプリケーション開発者ガイド

Hibari ハンズオントレーニング教材(チュートリアル)

また、出席いただいた方々より、次の意見をいただきました。今後の参考にさせていただきたいと思います。

良い点:

  • 質問への対応が迅速
  • 小人数で実技(ハンズオン)という点
  • 実際に動作しながら、開発者と直接質疑が行えた
  • 講師のスキルが高く的確な回答があった

改善すべき点:

  • 例題にElrangのプログラムを作成するのは無理があるのでは?
  • 出席者のサーバーをつないでみると面白いのでは?
  • Erlangを一切絡めずに、JavaやPHPなど人気のあるクライアント言語でKey-Valueの操作を説明すると良いのでは?

また、NOSQLとCassandraのトレーニングについては、開発者向けだけではなく、今後はサービスを提供、運用する方々に最適なコースを追加する必要性を感じました。マーケティング担当者向けのトレーニングがあっても良いのではという意見もいただきました。こちらも併せて、今後の課題としてゆきたいと思います。出席者の皆様には、出席いただき、かつ貴重なご意見をいただき、本当にありがとうございました。

2011/04/22

Hibari 開発者向けガイド(日本語版)が完成しました

Hibari 開発者向けガイド(日本語版)が完成いたしました。


ぜひ、ご活用ください。

2011/04/06

Hibari アプリケーション開発者ガイド 第1章(日本語版)

現在、4月末を目途にオープンソースであるHibariのアプリケーション開発者ガイドの日本語版作成を進めています。英語版はこちらになります。第1章は、NOSQLやHibariの概要について説明しており、ここにご紹介いたします。

1. Hibariとは
Hibari(R)は、キー・バリュー・ストア(KVS)方式を用いた分散型データベースです。大規模化し続けるデータ、いわゆる“Big Data”に対応し、商用にすぐに活用できます。大量のデータをどのように保管するかが大きな問題となる現在、それに対処する「NOSQL」というソリューションが出てきました。Hibariはこの分野で、次のような多くの理由から注目を集めています。
  • Hibariは、プログラミング言語Erlangと革新的なチェイン・レプリケーション技術を使った唯一のオープンソースのキー・バリュー型データベース(KVDB)です。Erlangは、堅牢で高性能な分散型ストレージ・ソリューションの構築には理想的なプログラミング基盤を提供します。一方、チェイン・レプリケーションは、データの一貫性を犠牲にすることなく、高いスループットと高可用性を提供します。
  •  Hibariは、キャリアクラスの通信事業分野で要求される厳格な基準を満たすように作られた唯一のオープンソースのキー・バリュー型データベースです。通信事業分野の製品では、数百万ユーザーの利用実績を持ちます。
  • Hibariは、次のような優れた特長を備えています。
    •  ストレージ・オプションとして、ディスクベースあるいはRAMのみの使用を、テーブル単位で選択できます。
    •  キー単位で有効期限およびカスタムのメタデータをサポートします。
    •  制限範囲内で複数キーのアトミック・トランザクションをサポートします。
    •  キーのタイムスタンプ機能によって「テスト・アンド・セット」型の操作が可能です。
    •  システムの規模に応じた自動データ配置バランシング機能を持ちます。
    •  コードのライブ・アップグレードをサポートします。
    • 複数のクライアントAPIを実装しています。
この最初の章では、「Big Data」の時代が投げかける問題に対処するために近年出現した「NOSQL」ソリューションについて簡単に説明します。その後、大規模データを扱うアプリケーションの開発者や管理者、あるいはユーザーにHibariが提供する大きな利点について、さらに詳しく紹介します。

1.1. なぜNOSQLか?
まず、NOSQLという新しい動向は、伝統的なRDBMS(リレーショナル・データベース管理システム)を無条件に否定するものではありません。この動向は、今日のデータ環境がSQLだけに留まらず(Not Only SQL:NOSQL)、ストレージに多様なツールが必要であるという認識が急速に広がっていることの表われです。リレーショナル型のデータ・ストレージとNOSQL型のデータ・ストレージは、それぞれ異なるアプローチを持ち、異なる種類のアプリケーションやサービスに適しています。これらは互いに補完するものであると理解してください。

NOSQLが注目されるようになった背景には、TB(テラバイト)あるいはPB(ぺタバイト)級のデータを保管して使うアプリケーションやサービスの急増という現状があります。その分野では頻繁に「常時使用可能」な可用性を保証し、エンドユーザーの待ち時間を減らす努力が払われてきました。たとえば次のような多くの市場分野で、さまざまな組織がBig Data時代の到来に備えて取り組んでいます。
  • Web資産:検索、eコマース、ソーシャルメディア、ユーザー作成コンテンツ等による大量データの要求への対応
  • 通信事業:何百万件もの加入者のネットワークログや通話データ記録の管理と分析
  • 公益事業:次世代送電網の巨大データ容量の管理と分析
  • 金融サービス:リスク分析とモデル化を目的とした顧客履歴データの保管およびマイニング
  • 小売分析:クリック・ストリーム分析とマイクロターゲティング
  • バイオテクノロジー:ゲノム解析
これらの分野に限らず、大量データを扱う環境にあるあらゆる組織が、いまや未曽有の大規模データを保管するシステムを構築する問題に直面しています。RDBMSとハイエンドの専用ハードウェアを軸とする伝統的なデータ保管アプローチではこうしたニーズに応えられないと、多くの組織は既に気づいています。特に問題になるのは、次の点です。
  • 単独のRDBMSインスタンスの「スケールアップ」は、どんなにハイエンドのシステムを用いても、また、どんなに多額の費用をかけても、必要な規模を到底達成できません。
  • 複数のRDBMSインスタンスに分割する「スケールアウト」は、巨額の費用を伴ううえに、運用が大幅に複雑になり、リレーショナル・モデルの利点を大きく損ないます。
先進的な組織では、コストや複雑性にしわ寄せせずにBig Dataに適した容量を実現させようと、より良いスケーリングの方法を追求してきました。また、増加の一途をたどる使用シナリオのすべてが、RDBMSの複雑なクエリー機能や管理機能を必要とするわけではないことも、同時に明らかになってきました。アプリケーションやサービスによっては、SQL構造や厳密なACIDが必要ないものもあります。さらに環境によっては、これらの過剰機能が高価につき、柔軟性と即応性が要求される非常に厳しい市場競争の中で、サービス提供が妨げられる可能性すらあります。

つまり、近年急増しているサービスで必要とするデータは、より大規模になる一方で、構造化の必要性はより少ないのです。

そう考えると、業界を牽引するWeb企業がNOSQLの動きの最前線にいるのは不思議なことではありません。特に、Google社のBigTable(2006年)と、Amazon社のDynamo(2007年)は、NOSQL市場に大きな影響を及ぼしました。BigTable やDynamo、あるいはその両方から構想を得たNOSQLソリューションが多数存在しており、ここ2年でいくつかのソリューションがオープンソースのコミュニティで発表されています。

NOSQLを使ったデータ・ストレージソリューションは、それぞれ細かい点では異なりますが、基本的に次のような共通点があります。
  • データモデルがシンプルである。データモデルはソリューションごとに異なり、それによってNOSQLシステムは次の3種類に分類できます。
    1. キー・バリュー型データストア(例:Dynamo、Hibari)
    2. 列指向型データストア(例:BigTable)
    3.  ドキュメント指向型データストア(例:CouchDB)
  • これらはすべて異なるものですが、伝統的なRDBMSと比較すると、データモデルがよりシンプルで高い柔軟性を持ちます。このシンプル指向は、クライアントAPIにも引き継がれています。
  • 汎用型のPCを基盤とした複数ノードに分散できます。何十、何百、何千とある汎用型のPCにスケールアウトすることにより、Big Dataの容量を低廉なコストで実現できます。受信した要求の並列処理と連動するデータ分割スキームにより、必要な高性能を得られます。
  • データ・オブジェクトを複数ノードでレプリケーション(複製)することにより、コンポーネントの障害発生時にも高可用性を確保できます。
NOSQLストレージ・ソリューションの歴史や長所、あるいは設計の問題等についてさらに詳しく知りたい場合は、Webで検索してください。


1.2. なぜHibariか?
Hibariは、Gemini Mobile Technologies社が社内で開発したものです。Gemini Mobile Technologies社は、アジア、ヨーロッパ、アメリカで、Tier 1モバイル・オペレータ向けの大規模メッセージングおよびトランザクション・システム開発分野の先頭に立つ企業です。Gemini社が必要とするデータストアは、Tier 1通信事業分野向け製品の導入環境に必須の堅牢さに加えて、効率的で高速かつ柔軟性を備え、拡張可能なものです。ところが、当時利用できる選択肢の中には満足できるものはありませんでした。そこで2005年に、Gemini社はのちに「Hibari」となるシステムの開発に着手しました。Hibariという名称は、日本語でヒバリ(雲雀)、漢字では「クラウド(雲)の鳥」を意味します。その後、システムが成熟して製品化できるようになったのを機に、2010年7月、Gemini社はApache 2.0ライセンスの下でHibariをオープンソースのコミュニティにリリースしました。Hibariが成長を続けて完成度を高める場として最も適しているのはオープンソースのコミュニティであると、Gemini社は考えています。

ここからは、Hibariの特長について説明します。これらの特長によって、Hibariは現代のBig Dataストレージ・システムを求めるビジネスおよび開発者にとって魅力的な選択肢となっています。
  • Erlangによる開発
  • チェイン・レプリケーションによる高い可用性と強い一貫性
  • 簡単でコストが低廉な拡張性
  • 高性能、特に読み出しと大きいサイズのバリューの処理における高性能
  • シンプルながら強力なクライアントAPI
  • 稼働実績
  • 開発者、システム管理者、そしてビジネスに対するHibariの利点


1.2.1 Erlangによる開発
   Erlangは、高信頼性で高性能な分散型システムを構築するように設計された汎用プログラミング言語および実行環境です。Erlangは、まず1980年代に先進的通信事業のネットワーク・システム構築用にEricsson社によって開発され、その後1998年に、Erlang/OTP (Open Telecom Platform)としてオープンソース化されました。HibariはすべてErlangで記述されています。

Erlangは次のような幅広い長所を持ち、分散型でキー・バリュー方式のストレージ・ソリューションにとって理想的な基盤を提供します。
  • 並列:Erlangのプロセスは、メッセージパッシングによる通信を行い、メモリを共有しないため、非常に軽く実行できます。スケジューリング、メモリ管理、その他並列処理に関するサービスを管理するのはErlang のVMであり、ホストのオペレーティング・システムに並列処理の要求を送ることはありません。
  • 分散:Erlangは、分散環境に特化して設計されています。メッセージパッシングはTCP経由で透過的に行われるため、Erlangのプロセス同士が通信する際は、同一ノードでも違うノードでもまったく同じ方法です。シンプルかつ効率的な設計により、高性能の分散型ストレージ・システムに求められる高度な並列性と拡張性を達成しています。この優れた並列性と分散処理により、Erlangは複数ホスト上で連携しながら稼働する点を除いては、オペレーティング・システムに似た初めてのアプリケーション・システムと言われています。
  • 堅牢性:Erlangのプロセスは、互いに完全に独立しており、データを共有しません。各プロセスが個別に動作するため、プロセスが互いを監視してプロセス障害を検知した場合は、すぐに対応できます。これは、リモート・ノードにおいても可能です。
  • 移植性:Erlangの VMは、Linux上だけでなく、UNIX、Windows、Macintosh、VxWorks上でもすべて同じものが稼働します。Erlangの分散プロセスは、異なるホスト・オペレーティング・システムが混在する環境でも、シームレスに相互の通信ができます。システム管理者は環境の変化に対応してホストをうまく組み合わせる必要があることを考えると、オペレーティング・システムを問わないこの移植性は、ストレージ・システムの弾力性の向上に大きく寄与します。
  • ホット・コードアップグレード:HibariのようなErlang ベースのアプリケーションは、ホット・コードアップグレードをサポートしています。そのため、システムを終了せずにアップグレードを適用できます。切り替え中は旧コードと新コードが同時に稼働します。これは、エンドユーザーに「常時使用可能」な可用性を提供する必要がある環境にとって重要な利点です。
他にも、インクリメンタルなガベージ・コレクションやシングル・アサインメント変数、強固な例外処理機能などにより、Erlangは信頼性の高い分散型アプリケーションに最適なものとなっています。

1.2.2 チェイン・レプリケーションによる高可用性と強い一貫性
分散型でキー・バリュー・ストア方式を用いたHibariは、チェイン・レプリケーション方式を実装しています。チェイン・レプリケーションとは、データの一貫性を犠牲にせず、冗長性を確保して高可用性を得るために、van Renesse and Schneiderが最初に提案したものです。Hibariのストレージ・クラスターにおけるチェイン・レプリケーションの動作を簡単に説明すると、次のようになります。
  • コンシステント・ハッシングにより、キー・スペースを複数のストレージの「チェイン」に分割します。
  • 各チェインは、複数の論理ストレージである「ブリック」から構成されます。ブリックごとにそれぞれErlangのVMインスタンスが稼働します。
  • 各チェイン内では、複数のブリックがそれぞれ相異なる役割を果たします。クライアントからキーとバリューのペアに対する書き込み要求が送信されると、まず「ヘッド」ブリックに書き込まれ、続いてそれが1個以上の下流の「ミドル」ブリックに自動的にレプリケーションされて、最終的に「テイル」ブリックまでレプリケーションされます。このテイル・ブリックが、クライアントの書き込み要求に対する応答を返します。一方、読み出し要求はテイル・ブリックに送信され、テイル・ブリックがクライアントに応答を返します。


多くの分散ストレージ・システムでは、レプリケーションしたデータ間に弱い一貫性、または結果整合性しか保証できないことが多く、しかも一貫性が損なわれた場合の管理をクライアント・アプリケーション(とクライアント・アプリケーションの開発者)に押し付けることがよくあります。それに対して、Hibariはチェイン・レプリケーションを実装しているため、強い一貫性を保証します。データの書き込みは、チェインをたどってテイル・ブリックまでレプリケーションされた時点で初めて完了したと見なされ、その後でクライアントに応答を返します。また、読み出し要求を処理するのはテイル・ブリックだけです。したがって、Hibariのクライアントにオブジェクトの書き込み応答が返された後は、そのオブジェクトを他のクライアントから見ると、必ず最新の状態であることが保証されます。この強い一貫性は、“結果整合性”ではエンドユーザーが期待するサービス・レベルを満たせない環境、あるいは、システム設計者が、データの不整合を管理するために必要なロジックをクライアント・アプリケーションの中にばらまきたくないと望む環境では、貴重なものです。

チェインの「長さ」は、必要とするレプリケーションの程度と冗長性のレベルによって変更できます。たとえばチェインの長さを4とすると、ヘッド・ブリック1個に、ミドル・ブリック2個、テイル・ブリック1個となります。また3ブリック・チェインとすると、ヘッド・ブリック1個、ミドル・ブリック1個、テイル・ブリック1個です。長さ2のチェイン(ヘッド・ブリックとテイル・ブリックが1個でミドル・ブリックなし)で稼働させることも、あるいは長さ1にすることもできます(1個のブリックがヘッドの役割とテイルの役割の両方を果たします)。

どんな長さのチェインでも稼働させることができます。また、システムがチェイン内の障害を検知した場合は、その後のメンバー・ブリックの役割を調整することもできます。これによってHibariは強い一貫性とともに、高可用性を提供できるのです。たとえば3ブリック・チェインのヘッド・ブリックに障害が発生すると、自動的にミドル・ブリックがヘッド・ブリックの役割を引き継ぐため、チェインは正常に機能し続けます。



さらに、新しいヘッド・ブリックに障害が発生した場合でも、残る1個のブリックがヘッドの役割とテイルの役割の両方を果たし、あたかも単独ブリック「チェイン」のように機能して、すべての書き込みおよび読み出し要求を処理します。

複数の論理ブリックを単一の物理ノードで稼働させることもできますが、高可用性を得るためには、特定のチェインのメンバー・ブリックを別々のマシン上に配置することが望ましいのは当然です。もし各マシン上で複数のブリックを稼働させたいと望み、なおかつ各チェインの高可用性を保証したいなら、チェインをマシン間で「ストライプ」構造に配置する選択肢も魅力的です。



書き込み要求を受けるヘッド・ブリックと、書き込み要求に応答して読み出し要求を処理するテイル・ブリックには、ミドル・ブリックより多くの負荷がかかることに注意してください。上図に示すように、異なる役割のブリックを均等に割り振ることも、マシン間の負荷分散の一助となります。

物理ノードに障害が発生した場合は、影響を受ける各チェイン内のブリックが自動的に役割を変更して、各チェインはクライアントに対して正常にサービスを続行します。


Hibariのストレージ・システムにおけるチェイン・レプリケーション、フェイル・オーバー、および修復に関する詳しい情報について、さらにHibariのAdmin Serverと呼ぶ冗長構成クラスター・メンバー・アプリケーションに関する情報については、「Hibari(R)システム管理者ガイド」の以下の節を参照してください。
  • Hibariのアーキテクチャー
  • (論理)ブリックのライフサイクル
  • 動的クラスター再構成
  • Admin Serverアプリケーション


1.2.3 簡単でコストが低廉な拡張性
Hibariは次に示すように、クラスターの増加に伴うコストと運用上の複雑性を最小限に抑えながらBig Dataに拡張性を提供します。
  • Hibariは、物理ノードを追加して、そこに追加チェインを配置することによって、水平に拡張できます。Hibariのクラスターにマシンを追加するごとに、クラスターのストレージ容量の合計と処理性能は線形に増加します。
  • クラスターにチェインを追加(または削減)する場合、システムは中断時間なしでストレージの自動データ配置バランシングを行うため、サービスを中断せずにHibariのストレージ・クラスターを拡大(または縮小)できます。
  • Hibariは、汎用のPC上で稼働します。またシステムは、異なるハードウェア・リソースに容易に対応できます。ストレージ・クラスター内のブリックは、異なる容量のRAMやディスクを使用でき、CPUのさまざまな処理速度にも対応できます。異なるハードウェアを組み合わせてクラスターを構成する場合、Hibariのコンシステント・ハッシング機能をチューニングしてクラスターの使用状況を最適化することも可能です。各チェインに重み付けファクターを指定して、キー・スペース全体に占めるチェインの割り当てを、他のチェインに比べて増加または減少させることもできます。
Hibariは、異種のハードウェアの混在をサポートするだけでなく、Erlangをベースとしているため、ほとんどすべてのオペレーティング・システム上で稼働します。異種のハードウェアおよびオペレーティング・システムに容易に対応できるので、利用できるあらゆるリソースを用いてHibariをインクリメンタルに拡張できます。すべてのリソースを同時に、また同一の種類に揃えて購入する必要はありません。

NOTE:
Hibariの水平拡張の上限値は、明確には決まっていませんが、Erlangに組み込まれたネットワーク分散機能の実装の限界から見て、200~250ノードが実質的な限界になります。また、Hibariのチェインは、理論的には複数のデータ・センターをまたがって延長しで地理的な冗長性を確保することも可能ですが、現在のところ、単一のデータ・センター内の配置しかテストしておらず、稼働実績はありません。

Hibariのクラスター・サイズの変更に関する詳細情報は、「Hibari(R)システム管理者ガイド」の
[動的クラスター再構成]の節を参照してください。

1.2.4 高性能 ― 特に読み出しと大サイズのバリューの処理の場合
Hibariのストレージ・クラスターでは、Big Dataの環境においても高性能を発揮できるよう、複数の機能が連携して働きます。
  •  Hibariを支えるErlang技術は、分散並行処理に特化して設計されており、分散並行処理環境で優れた実力を発揮します。
  •  Hibariに実装されているコンシステント・ハッシングとチェイン・レプリケーションは、複数のチェインが分割されたキー・スペースをまたがって使用することによって、個々のチェインが受ける要求を同時に並行処理できます。チェイン間のデータの配置をチューニングして、異種のハードウェア・リソースの使用状況を最適化することも可能です。
  •  Hibariのチェイン・レプリケーションは、ストレージ・ブリックに、ヘッド、ミドル、テイルという役割の異なる処理を割り当てることによって性能を上げています。この役割分担により、特に読み出し時の性能が向上します。読み出し要求を処理するのはテイル・ブリックで、このブリックは書き込み要求に対する最初の処理の負荷を担っていないからです(この処理はヘッド・ブリックが行います)。
  • Hibariは、多数のテーブル単位の性能チューニングのオプションをサポートしています。たとえば分散型KVDBは、バリューBLOBを保持するストレージとして、ディスクベースか、RAMベースか、どちらか一方をサポートするものしかありません。それに対してHibariは、ディスクベースかRAMベースかを、アプリケーションのニーズに応じてテーブル単位で選択できます。どちらのストレージ・オプションを選んでも、データ変更のログはすべてディスクに保持されるので、電源障害発生時にもデータ復旧が可能です。ディスクI/Oは、バッチ・コミット技術を使用して最小化しています。
Hibariは、こうした機能を活用することにより、現在の主流であるオープンソースのNOSQLストレージ・システムに匹敵する拡張可能な高性能を提供しています。それと同時に、多くのシステムに欠けているデータの信頼性と強い一貫性を提供します。Hibariの性能を他のNOSQLシステムと比較すると、特に読み出しと、大きいサイズ(200KB超)のバリューの処理の点で優れています。大きいサイズのバリューに対しても一貫性を確保できるHibariの高い性能は、小さいサイズのバリューの処理に適応したソリューションとは一線を画すものです。

いかに高性能か、その実例を紹介します。数百万ユーザーが利用するWebメール・システムで、Hibariが処理したトランザクションは秒あたり2,200件、その際の読み出しの平均待ち時間は1~20ミリ秒、書き込みの平均待ち時間は20~80ミリ秒という実績を残しています。

1.2.5 シンプルながら強力なクライアントAPI
Hibariの中核をなすデータモデルとクライアントAPIは、キー・バリュー・ストア方式としてシンプルな設計がなされています。BLOBベースのキーとバリューのペアが、辞書のようにソートされたテーブルに対して、追加、検索、削除を行います。Hibariは、キー・バリュー・ストア方式に伴う柔軟性と拡張性を提供していますが、それと同時に、クライアント・アプリケーションと開発者のパワーを増強する次のような大きな特長を備えています。
  • オプションとして、クライアントがオブジェクト単位に有効期限を設定できます。
  • オプションとして、クライアントがオブジェクト単位にカスタム・フラグを設定できます。この柔軟性を備えたカスタム・メタデータの更新は、関連するバリューBLOBの更新の有無によらずに可能であり、検索もバリューBLOBの有無によらず可能です。
  • オブジェクトの更新のつど、自動的にタイムスタンプを取得します。このタイムスタンプの仕組みにより、「テスト・アンド・セット」型の命令の実行が可能になります。つまりクライアントは、対象のキーのタイムスタンプが期待したものである場合にのみ、要求した命令を実行するように指定できます。
  • HibariのクライアントAPIは、キーの制限範囲内で(具体的にはチェイン全体ではなく特定のチェイン内で)、アトミック・トランザクションをサポートします。この「マイクロ・トランザクション」のサポートは、他のオープンソースのKVDBにはないHibariの特長であり、これによって堅牢なクライアント・アプリケーションの作成がずっと簡単になります。
Hibariは、複数のクライアントAPIの実装をサポートしています。たとえば、次のようなものがあります。
  • ネイティブErlang
  • ユニバーサル・バイナリ・フォーマット(UBF)
  • Thrift
  • Amazon S3
  • JSON-RPC
Hibariのクライアント・アプリケーションは、Java、 C/C++、Python、Ruby、Erlangなど幅広い言語で開発できます。

   HibariのクライアントAPIに関する詳細情報は、[クライアントAPI:ネイティブErlang] および当ガイドでこのあと説明するクライアントAPIの章を参照してください。


1.2.6 稼働実績
  当初、Hibariを開発したのは、主にTier 1通信事業分野におけるデータ保管の要望に応えるためでした。ところがシステムが進化すると、アジアのある大手キャリアから、GB(ギガバイト)級のWebメール・サービスを開始したいという要望が寄せられました。Hibariに対するこの顧客の要求は、次のように厳しいものでした。
  • 開始時点で数百万ユーザー
  • 開始から数ヶ月で、保管するメッセージは数十億件
  • ストレージ容量は数百TB(テラバイト)
  • 継続的な成長を支える柔軟性
  • システムの低廉なコスト(サービスが「フリーミアム」モデルを採用するため)
  • 個々のメッセージのサイズは、添付情報を含めて数バイトから数MB(メガバイト)
  • オブジェクト単位のメタデータ要求のサポート
  • 対話型セッションの強い一貫性
  • データの信頼性(メッセージやメタデータの損失は許されない)
  • 高可用性(「常時使用可能」を第一とするサービス)
  • 短い待ち時間(エンドユーザー・トランザクションで1秒未満の応答時間)
私たちは、この厳しい要求を満たすようにHibariを構築し、広範囲なテストと試行を通じて鍛え上げ、2010年初頭に、この大規模Webメール・システムのサポートを開始しました。現在このシステムは、数百万人のエンドユーザーの数十億件のメッセージを保管し、可用性、待ち時間、一貫性、信頼性、低価格という顧客の要求に応えています。

この間に、Hibariの開発と、GB級Webメール・サービス向けの細かいチューニングと並行して、アジアの大手キャリア2社のモバイル・ソーシャル・ネットワーク・サービス向けのストレージ・ソリューションとしても導入されました。この環境で、Hibariは多様な種類とサイズのデジタルデータとともにユーザー・プロファイル・データを保管しています。

1.2.7 開発者とシステム管理者、そしてビジネスに対するHibariの利点
Hibariは、アプリケーション開発者に対して、次のように大きな利点を提供します。これは、分散型キー・バリュー・ストア方式ではめったに得られない利点です。
  • データの強い一貫性を保証することにより、一貫性が損なわれた場合の管理の重荷をクライアント・アプリケーションから取り除きます。
  • マイクロ・トランザクションをサポートすることにより、強固なアプリケーションの作成をより簡単にします。
  • オブジェクト単位のカスタム・フラグをサポートすることにより、柔軟性の高いサービスに特化したアプリケーション設計を助けます。
  • 多様なクライアントAPIを実装し、多様な開発言語をサポートします。
一方、Hibariがシステム管理者に提供する大きな利点として、次のような運用の自動化があります。これにより、変化の激しいストレージ環境におけるデータ管理が、より簡単になります。
  • 自動レプリケーション
  • ノード障害発生時の自動フェイル・オーバー
  • 障害ノードが復旧する場合の自動修復
  • クラスターの拡張または縮小時の自動データ配置バランシング
そしてHibariはビジネス全体に対しても、サービスの高可用性と短い待ち時間に対するユーザーの要求を満たしながら、低廉なコストでBig Dataの拡張性を提供します。Hibariは、大量のデータを扱う幅広いサービスシナリオに対応できるストレージ・ソリューションです。そのシナリオは、大規模メッセージングやソーシャルメディア、アーカイブなどをはじめ、さまざまな可能性を持ちます。Hibariは、多種多様なオブジェクトすべてに対してデータの強い一貫性と高性能が求められる環境で、その真価を発揮します。

2011/03/28

NOSQL, Cassandra, Hibariのハンズオントレーニングを開催いたします

来月の4月25日(月)、26日(火)、27日(水)の3日間、NOSQLのハンズオントレーニングを開催いたします。このような状況であり、ご予定を調整することが難しいかもしれず、また更なる不測の事態についても心配され、広くご案内をせずにおりました。

しかし、以前より希望されていた方々より、参加できる旨のご連絡をいただき、開催することにいたしました。日程は次のとおりとなります。

2011年4月25日(月)13時~17時 NOSQL Technologies Overview
http://nosqltechoverview.eventbrite.com/

2011年4月26日(火)10時~17時 Cassandra Hands-on
http://cassandrahandson.eventbrite.com/

2011年4月27日(水) 13時~17時 Hibari Hands-on
http://hibarihandson.eventbrite.com/

そして、このたび初めて、Hibariのハンズオントレーニングを実施いたします。Hibariは、SourceforgeからGitHubに移行し、以前は複雑であったインストールをパッケージ化し、さらにアプリケーション開発者向けに新たにドキュメントを準備しました。
http://hibari.github.com/hibari-doc/hibari-app-developer-guide.en.html

すでにお試しいただいている方もおり、そのフィードバックもいただきながら、更新も続けています。また、当日までに日本語版も準備できるように関係者と相談をしているところです。

このようなタイミングでのお知らせとなりましたが、3月末までにお申し込みいただければ料金も40%のディスカウントになります。ぜひ、ご検討いただければ幸いです。

今回4回目となりますが、これまでご参加いただきました方々と、とてもよいご縁ができ、私どもにとってたいへんに素晴らしい機会となっております。皆様にお会いできることを心から楽しみにしています。

2011/03/15

Gemini Mobile announced a test version of software for large-scale cloud service (Translation of businessnetwork.jp articles)

The very good article of "Cloudian" is posted in the Japanese web site of  businessnetwork.jp. Here is the translation of this article.
http://businessnetwork.jp/Detail/tabid/65/artid/1148/Default.aspx

 Gemini Mobile announced a test version of software for large-scale cloud service
writer: Hiroshi Isobe (Editorial Office)
date: Mar 14, 2011

 Gemini Mobile Technologies, a company that provides messaging software for telecom operators (herein after "Gemini") developed and started to provide on Mar 11, 2011 a test version of software, called "Cloudian", for Internet service providers (ISP's) and cloud service providers (CSP's) to build large-scale distributed systems.

 Cloudian is a package of software to provide a flexible operating system for multiple customers to use a large-scale, Amazon S3 based, distributed storage system. It can support flexible service by assigning storage as required and providing volume-based billing capabilities. Its storage is scalable from only two PC's to hundreds of PC's across multiple data centers. Users can assign which data to be stored in which storage area. Also, private storage clusters can be easily configured as per service level agreement (SLA) per user.

 This type of storage is generally called "on-demand cloud storage." The most recognized example is "Amazon S3" provided by Amazon.com. On-demand cloud storage is characterized with an service operation to allow multiple users to use a part of storage whenever necessary and pay for what they have used. It is indeed a core menu of huge public cloud service provided by Amazon.com and Google.

 In Japan, however, many cloud services provided in the country are in effect similar with "hosting", "ASP" and "SaaS" services and not publicly shared on-demand cloud storage as provided by major web services in the US, e.g., Amazon.com, Google, and Facebook. Typically cloud service in Japan is meant to have IT systems of big companies in data centers or to allocate hardware assets, e.g., servers, to each customer (tenant) for their use. Such approach in Japan is often complained for costly initial investment and fixed fees, regardless of actual usage.

 In this background, recently there were two announcements in 2011, which would suggest full-fledged takeoff of Amazon-like, on-demand cloud storage in Japan. One was made by Amazon.com themselves. They announced the operation of a data center for cloud service in Japan. Amazon S3 already has a number of users in Japan. Until today data had to be physically stored in data centers outside Japan, which was the cause of concern about information management and latency among Japanese users. Now that they have a data center in Japan to wipe away these concerns, their opportunity to drive the usage in Japan is higher than ever.

 Another announcement was made by IIJ (Internet Initiative Japan) on "IIJ GIO storage service FV/S" (a beta program for test), a cloud storage service with API of HTTPS/REST interface (equivalent to Amazon S3). The service is based on volume charge and is expected to grow into one that can vie with Amazon S3.
 Cloudian announced by Gemini is believed to be good news for ISP's and CSP's who would like to start similar service with these cloud services.

Cloudian supports Amazon S3, and users can use Amazon S3 REST API. There are a growing number of web services that use Amazon S3 REST API in Japan, too. Gemini says Cloudian can help drastic reduction of development by allowing users to use the software without change to their existing applications.

 In the back end, Cloudian can use highly performing (data processing), scalable, available, NOSQL (Not Only SQL) databases. Currently it supports Cassandra database. Gemini also developed a log analysis system for real-time, large log collection, storage and analysis by using Cassandra (Flume-Cassandra Real-time Log Processor) and started to provide it as open source software last week, which is already gathering attentions in the community. In the future Gemini plans to also support Hibari, a NOSQL database developed by Gemini, and other NOSQL databases as well as their native API's on Cloudian.

 Cloudian package configuration

2011/03/11

Cloudian (クラウディアン)のプレスリリースを行いました

2011年3月11日(金)、GeminiはCloudian(クラウディアン)のプレスリリースを行いました。

http://www.geminimobile.jp/news/press-releases/press-release-4.html

Cloudianは、Amazon S3準拠のマルチテナント・クラウド・ストレージ・システムのソフトウェア製品です。最小2台の汎用PCサーバーから数百台にまで水平拡張でき、数百というマルチテナントが物理的に同じストレージ・サーバー・クラスターを共有できるため、ISPやCSP(クラウド・サービス・プロバイダー)が従量制型のストレージ・サービスを経済的に提供できるようになります。

2011/03/07

Flume-Cassandra Log Processing Systemのオープンソースリリースについて(2)

先週3月3日(木)に英語版でプレスリリースをしましたFlume-Cassandra Log Processing Systemのオープンソースリリースについて、ITProに記事が掲載されましたので、ご紹介いたします。

ジェミナイ、分散KVS「Cassandra」を使ったリアルタイムログ解析システムをOSS化

日本のプレゼン資料になります。ご興味のある方はぜひご覧ください。

2011/03/04

Flume-Cassandra Log Processing Systemのオープンソースリリースについて

先日、3月3日(木)、GeminiのUSチームから、FlumeとCassandraを利用したリアルタイムのログ処理システムをオープンソースとしてリリースしたことを発表しました。
http://www.geminimobile.com/news/press-releases/press-release-3.html

日本語で発表しなかったのは、未だFlumeについては、日本において関心を持っている方が少なく、話題に上ることも少ないであろうと考えたためです。しかし、NOSQLやCassandraのコミュニティでお付き合いいただいている方々から早速いくつかのTweetをいただき、感激しているところです。


また、今回のリリース前に、DataStaxのCEOであるMatt Pfeilと話している際、これは「Big DataとRealtime」を強みとするNOSQLデータベースであるCassandraとしても、ぜひとも応援したいとのことで、コメントを寄せてくれました。さらに、発表後、米国側ではFlumeのコミュニティからも早速メールが届き、MeetUpで話をしてくれないかという依頼も飛び込みました。


実は3月には、この他にもいくつかのNOSQL関連の発表が控えていますので、注目していてください。なお、ご参考のために、発表内容の翻訳をご紹介しておきます。


Gemini Releases Real Time Log Processing based on Flume and Cassandraの和訳
Gemini Mobile Technologies ("Gemini") は、本日、FlumeCassandraを利用したReal-time Log Processing System (“Flume-Cassandra Log Processor”)をオープンソースとしてリリースしたことを発表しました。 このFlume-Cassandra Log Processorは、商用システムからの大量のログを収集し、グラフィックレポートにリアルタイムで処理することを可能にします。加えて、複数のデータセンターからのログを同時に統合し、単一のデータベースで分析することもできます。予見することが難しいリアルタイムでの分析能力を持つ、GeminiFlume-Cassandra Log Processor は、オンライン運用から得られるビジネスインテリジェンスの品質と時間を大幅に改善します。このローコストでかつ小さな手間がもたらす劇的な拡張性は、NOSQLNot Only SQL)技術が可能とするものであり、それはGoogleFacebookAmazonにおけるクラウド・ストレージ技術に端を発するものです。 
ログはリアルタイムでユーザのオンライン行動や利用を記録します。Webサービス・プロバイダー、通信事業者、Eコマース・プロバイダー、そして企業のWebサイトは顧客体験とビジネスを改善するためにログを分析しています。伝統的なシステムはログをオフラインで分析してきました。なぜならば、ログファイルはリレーショナル・データベースにはあまりにも大きく、ログが生成されてから数日から数週間をかけてレポートを作成することが一般的でした。GeminiのソリューションはFlumeを用いて、都度ログをストリームし、データはリアルタイム、つまりログイベントから1秒以内でCassandra NOSQLデータベースに格納されていきます。オフライン分析もCassandraをクエリ―し、MapReduceを動作することにより可能です。このFlume-Cassandra Log Processor は、数台のPCから複数のクラスターに拡張でき、数百テラバイトのログを格納し、分析し、自動的に期限切れのデータを消去します。 
「ビジネスインテリジェンスは企業やサービス・プロバイダーにとって、個人にとって、また効果的なWeb体験をお客様に提供するための重要な構成要素です」とGeminiの共同創立者兼COO、マイケル・ツォーは語っています。「私たちのFlume-Cassandra Log Processorは、以前では困難であったデータ量と速度で、リアルタイムにビジネスインテリジェンスを提供します。私たちは、コミュニティが容易にカスタマイズ、改善できるよう、喜んでこれをオープンソースとしてリリースします」。 
Geminiのリアルタイム・ログ処理ソリューションは、big dataの問題をリアルタイムで解決できるCassandraの能力を、とても印象的に示しています」。DataStaxCEOであり、Apache Cassandraの商用リーダーであるMatt Pfeil, CEOは語っています。「Cassandraは、急速にWebと企業アプリケーションにとって拡張性が高いプラットフォームとしての機運が高まっています。私たちは自らが革新を続けることと、Geminiとの協力関係に大いに期待しているところです」。 

このFlume-Cassandra Log Processor は、Githubからダウンロードできます。 https://github.com/geminitech/logprocessing
FlumeCassandraは次のサイトになります






2011/03/02

NTTソフトウェア株式会社様オンサイトにてNOSQL トレーニングを開催しました

先週、2月25日(金)、NTTソフトウェア株式会社様の研修施設がある横浜事務所にて、オンサイトにおけるNOSQLトレーニングを開催いたしました。

NTTソフトウェア株式会社様では、「NOSQLには以前から取り組んでおり、最近になってニーズが多く寄せられており取り組みを拡大している」とのお話を伺い、オープンソース推進室から社内希望者を募っていただいたところ、大阪からのWebカメラによる参加も含め、30名近くの出席がありました。10秒程度のビデオですが、その模様をご紹介します。


NOSQL Technologies Overview Training from geminimobile on Vimeo.

トレーニングは、NOSQLのTipping Point(ブレイクするきっかけ)となったGoogleのBig Table、AmazonのDynamoの論文の技術概説を行い、そのうえで現存のNOSQLデータベースである、Cassandra、HBASE、MongoDB、Hibariについて、それぞれの特徴を説明し、技術の比較を行いました。また、YCSB論文のパフォーマンス比較についてもご紹介しました。

余談ですが、Hibariが「YCSB論文のパフォーマンス比較に入っていない」とのうれしいご質問もいただきました。Geminiでは数回パフォーマンス比較を行っており、「NOSQL AFTERNOON IN JAPAN」と「Erlang User Conference」で発表をしています。Basho Benchというツールを用いて比較しており、昨年発表したプレゼン資料にありますのでご参照ください。
さいごに、CassandraとYCSBのデモをご覧いただき、半日のトレーニングを終了しました。終了後のサーベイで、「NOSQLが普及するためにどうしたらよいか?」という点をお伺いしたところ、次のようなご意見をいただきました。今後の活動の参考にしたいと思います。
  • イベントやセミナーの開催、宣伝活動による啓蒙
  • 日本語ドキュメントの充実、Web情報の整備
  • 多くの実際の適用事例を紹介
  • NOSQLの適用分野、SQLとの棲み分けを明確にしてゆくこと
  • NOSQLの適用シーン、適用モデルを明確にしてゆくこと
  • RDBMSのように活用方法を定型化、定式化
また、オープンソース推進室には、「今まさにやっている業務へのヒントとなった」、「すぐに業務に活用できる」といった声が寄せられたとのことで、「全体的に成功であった」とのフィードバックもいただきました。私たちとしても、たいへんに熱心に聞いていただき、内容を良く理解した的確な質問をいただき、今回のトレーニングのために米国から講師を出張させて本当に良かったと思っているところです。

このNOSQLのトレーニングは、昨年開始以来、回数を重ね次回は第4回目となりますが、4月後半の開催に向け準備を進めているところです。ご関心のある方は、ぜひ、bigdata at geminimobile.comまでご連絡いただければ幸いです。事前にご案内をさせていただきます。

2011/02/17

日経コンピュータ2月17日発売号に紹介されました

日経コンピュータ2月17日発売号のクローズアップ「超高速DB『NOSQL』が普及へ」と題した8ページに亘る特集記事において、ジェミナイが紹介されました。

「ジェミナイ・モバイル・テクノロジーズも、KVSを利用した分散ストレージ『Cloudian(クラウディアン)』の試験版を2011年2月末に提供する予定だ。Cloudianは、米フェイスブックが開発した列指向型の分散KVSのオープンソースソフト『Cassandra』をベースに、課金機能や容量制限を加えた分散ストレージソフト。Amazon S3のようなオブジェクトストレージ・サービスを構築できる」

この『Cloudian』はUSのチームが開発してきたプロダクトです。クラウドストレージを提供するAmazon S3は「サービス」ですが、それを「ソフトウェア」プロダクトとして、かつ上回る機能を提供するもので、近いうちに詳細を発表する予定です。

そのほか、本特集はバッチ処理型ではなく、「リアルタイム処理に適したNOSQL」を取り上げており、ぜひご一読されることをお勧めします。


2011/02/11

Mongo Tokyoイベントの特別割引のお知らせです

多くの皆様にご参加いただきましたNOSQL AFTERNOON IN JAPANで、一緒にプレゼンをしましたMongo DBの10genが、3月1日(火)に日本初となる「Mongo Tokyo」を開催します。



私たちとしても、NOSQL AFTRNOON IN JAPANにおいて、日本のMonogo DBのユーザーと10 genとの出会いが契機となり、Mongo DBのコミュニティであるMonogo DB JPがスタートし、そのコミュニティの尽力により、このイベントが開催されることになったと聞き、とてもうれしく感じています。

そんな縁もあり、このブログをご覧の方々に、10genからイベントの特別割引の申し出がありました。

「Mongo Tokyo」イベントのチケット購入サイトはこちらになります。

http://www.10gen.com/conferences/mongotokyo2011

このサイトでチケットをご購入の際に、ディスカウントコードを入力することで特別割引を受けることができます。



上記の矢印の「Enter Discount Code」をクリックし、gemini の6文字を入力してください。20%の特別割引となります。

または、こちらのサイトから直接お申し込みください。
http://mongotokyo2011.eventbrite.com/?discount=gemini

ご友人知人の方にもこのディスカウントコードを伝えても良いとのことですので、ぜひとも、お誘い合わせのうえ、ご参加ください。

2011/01/25

「Big Dataがモバイルビジネスに与える影響」

昨年12月より、businessnetwork.jpに連載を開始した「Big Dataとの戦い」の連載最終回が掲載されました。

この最終回は、Big Dataがモバイル通信事業者を始めとするモバイルビジネスに与える影響について、私たちの見方をご紹介しています。

http://businessnetwork.jp/Portals/0/SP/gemini/05_01.html

モバイルビジネスをさまざまな角度から見ながら、これから「起こりうること」、または「望ましい方向性」について考えてみました。

ぜひとも、ご覧いただければ幸いです。

2011/01/04

NOSQLの開発者を募集します

Geminiでは、NOSQLの開発者を募集いたします。

Geminiはソフトウェアベンダーとして、商用NOSQLデータベースであるHibari開発を行い、オープンソースとしてリリースしています。また、米国ではHadoop/Cassandraを用いた商用プロダクトの開発に着手しています。

開発言語はC++、Javaに加え、Erlangを用いています。ご関心のある方のお問い合わせ、お申込みをお待ちしております。

詳細は以下のURLをご覧ください。
http://www.geminimobile.jp/company/career.html