へ～たのめも

2010/05/25 08:47

Mozilla Blog Riak and Cassandra and HBase, Oh My!の勝手訳。各分散 KVS の特徴が分析されていて興味深い……と思って訳してみた。この無様なタイトルは Google 翻訳による。

Riak と Cassandra と HBase、あらまー!

我々は、SoCorro Crash プロジェクトにおいて HBase との統合を進めているが、その話はちょっと置いておいて、今回はメトリック・チームが巻き込まれている別のプロジェクトについて話をしよう。

Mozilla Labs Test Pilotは、実世界の Firefox ユーザをから集めたデータを分析して、ユーザ・エクスペリエンスを向上させるための実験をしたり、定量的データを集めたりするためのプロジェクトだ。

私がこのプロジェクトに興味をそそられ、興奮しているのは、彼らがユーザのプライバシーを保護しようという姿勢を強く示しているためだ。嬉しいことに、彼らはユーザ視点で非常に読み易いプライバシー・ポリシーを公開している。

Test Pilot では、データ送信の各ステップで、ユーザは自分が送信しているデータを意識し、安心できるようになっている。ユーザーは自分自身が送信するデータを送信前に確認することができるし、その上でデータを送信するかどうかを選択できるようにしているのだ。ほとんどの送信データは URL のような機微情報を含まない、ごく一般的なものに限られていて、どのようなことであれ個人を特定できるような情報とは関連付けられていない。

Test Pilot のプレ 1.0 リリースでは、そのアドオンから送信されるデータは単純なスクリプトで処理され、NFS サーバ上のフラットファイルに格納されていた。

我々は、ユーザ数と集収データ量を急激に拡大させようと計画している。というわけで、この単純なストレージは役に立たない。以下は、我々の計画で洗い出されたデータ・ストレージが備えるべき最も重要な要件群だ。

想定される最少ユーザ数: 百万人。年末までには一千万人を収容し、さらに数千万人規模に拡張可能なデザイン(これは私のお気に入りである見積りの 1x 10x 100x ルールに従うものだ)。
一回の「実験」で集められるデータは 1.2TB。
想定されるピークトラフィック: 実験の終了間際で、8時間にわたって約75GB/時間。これが2回。この 2日間で全データの約 90% を集収するはずだ。
高トラフィック化でも高い可用性を保つこと。
不正なデータによって実験が影響を受けたり、アプリケーションが障害になったりしないよう、必要な検証機構やセキュリティ制約を課せられること。
柔軟で使いやすいデータ解析、データ走査。統計やデータ処理に長けた連中ではあるが、全員がプログラミングに長けているというわけではないので、高レベル API があればなお良い。
性能。

私は技術屋だ。私は、流行にのったり、可能性のあるツールを使うために、技術を調査するのが好きだ。私は SQL の熱烈な信奉者だが、一方で"NoSQL" 系技術の大ファンでもある。NoSQL が活用される場面は、かなり多いと思っている。

このプロジェクトの特性を考えたとき、私は key-value ストアかカラム・ストアの採用が適切であると感じて、自分の調査用ブックマークを掘りおこして技術的なメリット・デメリットの比較を行なった。

最終的に、我々のチームは選択肢を以下の 3候補に絞った。

HBase
Cassandra
Riak

我々は最近、これらのソリューションの利点と欠点を洗い出すための打ち合わせを持った。ここでは、その議論の結果をみんなと共有したいと思う。私が議論の結果を共有したいと思っているのは、採用に至らなかった 2候補に改善をうながすためではなく、以下の 2つの理由からだ。

クラウド(Crowd;群集)ソーシング - 私は、様々な技術に精通したエキスパートから幅広いフィードバックを受けるためには、思索や仮説をオープンにすることが一番有効だと信じているからだ。また、問題点を隠しておくよりは、それを軽減するために、見過していた機能に注目したり、有識者からの警告を受け入れた方が良いと信じている。
知識の共有 - 仮に我々の出した答が完全でなく、理想のソリューションに辿りついていなかったとしても、我々がここで提示したたくさんの良い基準は、同様の選択を迫られている他のチームの役に立つだろうと信じる。

では、具体的な比較ポイントを説明していこう。

スケイラビリティ - 当初想定負荷を捌き、また負荷の増大に応じて容易にスケールアウト可能なソリューションであること。
弾性(Elasticity) - ピーク時間帯が比較的短かく、ピーク時間以外はほとんどアイドル状態である。このため、割り当てたハードウェアが遊ばないように、またピーク時にリソースが枯渇しないような方法を考えることが重要である。
信頼性 - 安定した稼働と高い可用性が重要である。ある領域のプロジェクトと比較すれば信頼性要件は比較的低いものの、ピーク時間帯に数時間もダウンするようなことがあれば、クライアント層でデータを保持しておき、後日に再送信するような仕組みが必要になるだろう。
ストレージ - 実施中の実験および、データ分析中の直近のいくつかの実験について、充分な容量を保持できる必要がある。データは時がたつにつれて古くて使いものにならなくなると思われるので、活動中のクラスタから取り除いてアーカイブできることが望ましい。
分析 - 分析者フレンドリなシステムを提供するためには、何が必要だろうか?
コスト - 初期構成および年末までに準備する構成のために、ハードウェアの追加配備に必要な実コスト。
人的リソース - プロジェクトが最初の重要な段階およびその後のいくつかの段階をこなすまでに、どの程度の時間と手間を必要とするか。加えて維持管理コストとコードの所有権についても考慮する必要がある。
セキュリティ - 我々が扱うデータは、外部の信頼できないデータソースから受信されるため、ユーザのプライバシーとシステムの健全性を確実なものにするために何が必要かを検討しなくてはならない。
拡張性 - 将来的なプロジェクトの要件拡大に応じて進化可能なプラットフォームを配備する必要がある。願わくば、他プロジェクトでも利用可能なプラットフォームにしたい。
障害回復とデータ移行 - もしリリース後にシステムが要件を満たせなくなった場合、どのような代替手段が取れるか。他の技術に乗り替えようとした場合、どのようにデータを移行するか?

さて、3つの候補について我々のチームが出した結論とともに、もう一度これらのポイントを見直してみよう。

弾性 - 負荷の増大に応じて、マシンを追加できること。マシンを取り除くときには、マシンの電源を切ればデータが再配置されること。ソフトウェアの不良によって、レプリケーション・データが欠損したり破損したりして、データを喪失するリスクは、もちろんある。3候補すべてについて、既存データの再配置は、データがクラスタ内を行き来するために、余計な負荷がかかる。どの程度の時間が必要か、またどの程度の手動操作が必要か、どこまで自動化できるか、どの程度のリスクがあるのか、ノード追加時に追加の効果を得るまでにどれくらいの時間を要するか、などを考慮する必要がある。
HBase
HBaseでは、データは "region" に分割されている。"Region" のデータ・ファイルは HDFS に保存されているため、クラスタ内の複数ノードにレプリケーションされている。各 RegionServer が一組の region を所有している。通常は、RegionServer は自分自身が稼働するローカル HDFS データノード内の region を所有する。新しいノードが追加されると、HDFS はそのノードをレプリケーション用に使用しようとする。Region ファイルが分割されるタイミングで、HBase はどのマシンがその新しく分割された region を所有すべきかを決定する。最終的には、新しく追加されたノードは適切な量の新しいデータや新しくスプリットされたデータを保持する。データの再配置は、HDFS の再配置と HBase による region の再構成の両方を含む。
Cassandra
Cassandra では、各ノードは、複数のデータ範囲を要求する。デフォルトでは、新しいマシンが追加されると、データ範囲のうち最も大きいものの、半分のデータを保持する。この挙動を変更する起動時オプションも存在する。安全で容易な再配置のためには特定の設定が必要であり、全データ範囲を対象とした再配置コマンドも存在する。再配置の進捗を監視するためのツールも存在する。
Riak
Riak では、データは各ノードに分散配置された複数のパーティションに分割される。ノードが追加されると、パーティション所有権の分散が変更され、既存データと新規データの両方について新しいデータへの移行が開始される。
コスト - どのソリューションも、一般的なサーバ・ハードウェアと Linux OS が使用可能である。
HBase
ピーク時間帯の膨大なトラフィックを処理するため、専用のクラスタが必要となる。たとえば Socorro のような他プロジェクトとクラスタを共有すると、他プロジェクトに悪影響が及ぶだろう。また、計画メンテナンス時にも、どちらか片方だけではなく、両方のプロジェクトを止めなくてはいけなくなる。HBase はメモリ喰いだ。現在の我々のシステムは、デュアル・クアッド・コアのハイパースレッド付きで、4TB のディスクと 24GB のメモリを積んでいる。これより小さな構成というのは、組めそうにない。マスターノードのために、少なくとも 2台の高可用性マシンが必要であり、年末には 1クラスタのために12台のマシンが必要になるだろう。
Cassandra
メモリ要件に関してはずっと軽い。特にキャッシュに大量のデータを保持する必要がない場合は、特に軽い。現在の Test Pilotプロジェクトに割り当てられている 4ノードについてCPU 数を二倍にするほか、8台のマシンを追加でオーダーすることになるだろう。Cassandra 上で分析を行うには、既存の Hadoop クラスタを活用する必要がある。
Riak
メモリ要件は Cassandra 同様に軽い。当初はプロジェクトに割り当てられている既存の 4台(クアッドコア、8GBメモリ)だけで充分で、さらに同等程度のマシンを 2台、クラスタに追加したい。さらに分析処理用に2つ目のクラスタを 6～8台のやや性能的に劣るマシンで構築する。Riak が持つ弾力性のおかげで、ピーク時間帯にはこのうちの N-3台を一時的に書き込み用クラスタに転用することができる。
人的リソース
HBase
クライアントから実験データを受けとるためのフロントエンド層が必要。クライアントへの修正が少なければ少ないほど良い。Thriftか、Java による独自開発が妥当な選択肢だ。機能性、安定性とも、アプリケーションは充分にテストされる必要がある。開発とテストにそれぞれ 2週間と見積もっている。見積りは、実装が必要なセキュリティ・コード、サニティ・チェック、クラスタ間通信のエラー処理などの量に依存する。分離されたフロントエンドを維持管理していくのは、不毛だ。データをパースして、適切なカラム・ファミリー内に格納するために、ス

1/2

Cassandra: ほとんど HBase と同じ。Thrift または Java のアプリケーションを手動で開発、テストする必要がある。フロントエンドのスキーマ設計も必要となる。
Riak: 組み込みの REST サーバが、すでに充分にテストされ、リリース可能な状態。スキーマ設計は最小限で、スキーマを REST サーバ上に作り込む必要は特に必要ない。

Security - いかなる種類のハンドシェイク・プロトコルも、認証トークンも、使用することはできない。もし、認証トークンを使おうと思ったら、クライアント・アドオンに膨大な修正が必要になり、プロジェクトの遅延を引き起こす。どうせ機微情報はやりとりしないので、オーバヘッドばかり大きなSSL は、たいして役には立たなそうだ。我々のファイアウォールとプロキシー/ロードバランサー層が、最も重要な防御ラインだ。URL ハックや、不自然なサイズのペイロード、同一の IP アドレスから繰り返される通信などは、ここで排除できる。理想的には、データ検査部分が IP アドレスのブラックリストや、データ・シグネチャーのブラックリストと通信できれば、クラスタの健全性損失を最小限に抑えるために充分な防備を持っていると言えるだろう。
HBase/Cassandra
データを検査し、不正なまたは不完全なデータを排除するためのフロントエンド層を独自開発する必要がある。これはフロントエンド層への要件と開発時間見積りに追加される。
Riak
Webmachine の pre-commit フックをデータ検査のために使用することができる。
拡張性 - 格納されているデータが変更されたとき、3候補すべてにおいて入力のセキュリティチェック処理やスキーマ変更に伴う入力解析処理の変更が必要になる可能性がある。
HBase
カラム・ファミリーの追加または変更を含むスキーマの変更は、テーブルを無効にしてから行う必要がある。つまり、保守のための計画停止が必要になる。新しいテーブルの作成は、オンラインで行うことができる。
Cassandra
スキーマの変更は、各ノードのローリング・リスタートを必要とする。
Riak
新規のバケツとスキーマは、完全に動的に作成できる。
データ移行 - 3候補いずれとも、データをシステム外に複製、エクスポート、MapReduce する処理は容易だ。
障害復旧 - 3候補いずれを採用しても、クライアント・アドオン側で、クラスタ高負荷時には通信を控え、通信が失敗したときには、後でリトライするような機能を作り込むのがベストだろう。
HBase
独自に実装するフロントエンドは、クラスタがオンラインになるまでデータをスプールしておく機能を持つことで、障害時処理の一部を担当できるだろう。障害時用に別のクラスタを持っておくことが、最も実行可能性の高い障害対策だ。
Cassandra
HBase と同じ。
Riak
分析用のクラスタを一時的に受信データの処理用に利用することができる。独自に作り込んだフロントエンドは存在しないので、もし、Riak クラスタをクライアントから接続可能な状態にできなければ、サーバ側でデータをスプールするような場所はない。
信頼性 - 特にクライアントのアドオンがリトライ機能を持っていたり、フロントエンド層がスプール機能を持っている場合には、短期間のダウンタイムは深刻な問題ではない。
HBase
今後のバージョンがより良い高可用性オプションを提供するまでは、Hadoop NameNode と Habase Master は依然として単一障害点である。ある種の管理作業とアップグレードは、NameNode と HBase Masterの情報を更新するまでの間、全クラスタを同時停止する必要がある。多くの管理作業についてローリング・リスタートで対応できるものの、HBase の有識者はローリング・リスタートの採用を推奨していない。
Cassandra
単一障害点なし。ほとんどの構成変更は、ローリング・リスタートで対応可能。
Riak
カサンドラと同じ。
分析
HBase
(場合によっては JDBC 接続とともに) HIVE ベースのインターフェースを提供可能。分析者がある種の共通的で単純なジョブを実行するときのために、単純化された MapReduce フレームワークを提供可能。
Cassandra
Hadoop を使えるので、HBase と同様。
Riak
Map Reduce ジョブは、JavaScript で開発可能で、REST API を通じて実行できる。これらのジョブ実行を実現するための、軽量なウェブインターフェースを作り込むこともできる。

これらの評価と、ソリューションをほとんど初期設定不要な状態で提供する上で必要な人的リソースを考慮して、Test Pilot のバックエンドは Riak で構築することに決定した。我々が大きく投資している HBase と比較して、いろいろな意味で似通っている別技術を採用することには少し違和感があるが、私はこの選択が最善であると考えている。また、他プロジェクトで Riak を採用する可能性がある分野も、実際にいくつかある。

もしなにか質問や心配ごと、不明な点があれば、どうぞお気軽にコメントに書いて欲しい。質問には返事をして、必要であれば記述を更新する。

カテゴリ