January 23, 2013

Couchbase Server 2.0 クラスタ サイジング入門Part 1: 何台のノードが必要か?

本シリーズの第一部はプロダクションでの利用時に、Couchbase Server 2.0クラスタのサイジングで考慮すべき点を紹介します。第二部ではより深く特定のユースケースやシナリオを扱い、第三部ではハードウェアの注意点、第四部ではクラスタを拡張するタイミングを決定するためのモニタリングについて解説します。

何台のノードが必要か?これはCouchbaseクラスタをデプロイする際、最もよくある(そして最も重要な)質問です。

これには多くの要素が関連しますが、基本はワークロードとデータセットにおける、システム全体の性能と容量の要件を評価することです。そしてそれらを利用可能なハードウェアとリソースに当てはめる作業になります。プロダクション環境でCouchbaseクラスタを運用する一般的なプラクティスとこれらの要素についてのハイレベルで視覚的な議論については、Couchbase Server 2.0 in Production 24x7を参照してください。

Couchbaseクラスタのサイジングは安定性と性能にクリティカルに影響します。可能な限りキャッシュから参照し、更新を処理するために十分なIOキャパシティが必要です。必要なレベルの性能を保持しつつ、システムが実行するその他の処理をサポートするために、必要十分なキャパシティが必要です。

本シリーズを通して、Couchbaseクラスタのサイジングを行う上で考慮すべき5つの要素を紹介します: RAMディスク(IOと容量), CPU, ネットワーク帯域幅、そしてデータの分散です。

  1. RAM:サイジングにおいて最も重要な領域はRAMです。RAMはCouchbaseが高速である所以です。キャッシュされたドキュメントは非常に低いレイテンシと高いスループットで参照可能で、書込み時にも同じことが言えます。

近いうちに最新のサイジング計算式が利用可能になりますが、必要なRAMの計算は次の合計になります。

  • アクティブ、レプリカのデータセット
  • メタデータ (各アイテムにつき約64バイト、加えてキー長)
  • データセットの何割がRAMにキャッシュされるべきか (これを"ワーキングセット"という)
  • OSがディスクIOを適切にキャッシュするためのオーバヘッド

Couchbase Server 2.0では、アイテム毎のメタデータオーバヘッドを削減しました。またejectionアルゴリズムでNRU(not recently used)ビットを利用する最適化を行いました。これはアプリケーションのワークロードに基づき、どのデータがRAMに保持されるかを判断する上で、オブジェクトキャッシュ層をよりインテリジェントにします。

新しいview/index機能を有効利用するためには、OSのディスクキャッシュ用にもRAMを確保する必要があります。これについては第二部で詳細を解説します

2. ディスク:ディスクサブシステムの要件は容量とIOの二つに分割できます。

Couchbase Server 2.0は1.8よりも多くのディスク容量を必要とします。ディスク容量は"安価"であり、通常は問題にはなりませんが、考慮は必要です。部分的更新をおこなうディスクフォーマットから、追記のみのフォーマットへの移行は、全ての更新処理(挿入/更新/削除)が新規のエントリをファイルに作成することを意味します。これは信頼性、性能、一貫性を大きく向上させ、ウォームアップ/起動時間を向上します。しかしながら、ディスクサイズが際限なく増加することにもなります。

1.8では頻繁な更新や削除によるディスク上のファイルのフラグメント化により、時折性能が犠牲になることがありました。2.0ではフラグメント化は発生せず、加えて、必要なデータのコピーだけを保存し、ディスク上のファイルサイズを削減する、自動コンパクションプロセスも組込みました。

追記のみのディスクフォーマットの特性から、ワークロードに応じて、必要なディスクサイズは全データセットサイズ(アクティブ/レプリカの合計)の2倍から3倍になるでしょう。より頻繁な更新/削除処理は、挿入と参照がメインのワークロードよりも劇的にサイズを増加させます。実際は、サイズは増加し、自動コンパクション処理が起動すると小さくなります。2倍から3倍という数字は、実際のデータ用ではなく、自動コンパクションのために必要なものです。2倍から3倍という数字は、実際のデータ用ではなく、自動コンパクションのために必要なものです。

これに加え、Couchbase Server 2.0のview/indexingを利用する場合、新たな要件があります。これについても第二部で触れます。

IO:これは継続的な更新頻度、データベースファイルのコンパクション要件、そしてその他のディスクアクセスが必要な全ての処理の合計になります。Couchbase Serverは自動的にデータベースへの更新をRAM上にバッファし、最終的にディスクへと永続化します。これにより、ディスクが処理できる以上の更新性能を実現しています。しかしながら、継続的に更新を行うためには、結果的に必要十分なディスクIO性能が必要です。

自動コンパクションの実行スケジュールと閾値は簡単に変更できますが、コンパクションを正常に完了させることはディスクサイズを制御するために非常に重要です。

詳細は第二部で触れますが、Couchbase Server 2.0の新機能であるviews/indexingやクロスデータセンタレプリケーション(XDCR)を利用する場合、ディスクIOはより注意してサイジングが必要になります。

最後に、バックアップ用、そしてCouchbase以外のプロセスに必要な十分なディスク容量とIOを保持しているか確認してください。可能であればIOや領域を効率的に利用するために、データファイル、インデックスファイル、インストール/設定ディレクトリを別々のドライブ/デバイスに配置してください。

3. CPU:Couchbase Server 1.8では通常、それほど考慮する必要がありませんでしたが、Couchbase Server 2.0の新機能のいくつかはより多くのCPUを必要とします。オブジェクトベースのキャッシュ層はCPUが不足していても非常に高いスループットと低いレイテンシを提供できますが、その他のシステムをスムースに運用できるように、十分な処理能力を確保することが重要です。通常、少なくとも4つのコア、XDCRを利用して複製するバケット毎に追加で1つ、そしてデザインドキュメント(viewに関連)毎に追加で1つのコアを推奨します。

4. ネットワーク:多くの場合、ネットワークはCouchbaseクラスタのサイジングにおいて決定的な要素にはなりません。しかし、ネットワークレベルで何が起きているのか理解することは重要ですし、アプリケーションとCouchbaseノード間、そしてノードとノードの間でトラフィックを処理するための、十分な帯域を用意することは重要です。XDCRを利用する場合、クラスタ間(通常はWAN間で地理的に分散)にも十分な帯域が必要になります。

ネットワークはいつも、レイテンシに対する最終的なボトルネックになります。例えば、キャッシュ上のドキュメントに対するread/writeレスポンス時間は99パーセンタイルにおいて、Amazon AWSで1-2ms、標準的なgig-eネットワークでは500-900us、10Gネットワークでは200us未満となります。これらはCouchbase

Server自体は非常に低いレイテンシを提供できるということを意味します。時間がかかるのは通常ネットワークです。経路は異なりますが、これらのベンチマーク結果を性能比較対象とすることができます。

5.データの分散:他の項目に関係なく、データを安全にすることは常に重要です。Couchbaseは分散システムとして設計され、非常にリニアなスケーラビリティとデータの冗長化を行うことができます。ただしこれを効率的に実行するにはそれなりの考慮が必要です。

極端に言えば、一つのノードだけでRAM/ディスク/CPU/ネットワークと全ての要件にマッチするかもしれません。しかし、これは明らかに単一障害点となります。

二つ目のノードを追加すると、レプリケーションが可能になりますが、理想的な環境とは言えません。一方のノードが故障すると、もう一方が単一障害点になります。また、将来的にスケールする要件がある場合、クラスタ内により多くのノードが存在するほうが、各ノード間を移動するデータが少量で済みます。

これらの理由から、他の要素に関わらず、少なくとも3ノードでクラスタを構成することをお勧めします。

最も優先度の高い要求となる要素が常にあるはずで、それが必要なノード数を決定付けます。例えば、少量のデータセットに対して非常に高頻度の更新処理を行う場合、ディスクスループットが必要になるため、より多くのノードが必要になります。一方、大きなデータセットに対する参照メインの処理では、RAM要求のために多くのノードが必要になります。

これら全ての要素はノード追加による恩恵を受け、スケールします。アプリケーションのreadやwriteがノード間で均等に分散されるだけでなく、コンパクション、リバランス、view/indexの更新、そしてXDCRといった機能もノードを増やすことで大きな効果が得られます。各ノードではローカルのデータセットを処理すればよく、ディスクやCPU負荷の高い処理も並列に実行することができます。

要件とリソースに対する要望が変化する中、Couchbase Serverを高価なノードでスケールアップするアーキテクチャではなく、サイジングを考慮した的確なノードのアーキテクチャにも目を向ける必要があります。

最後に、ガイドラインと計算式はサイジングに必要な数字が正しい場合のみ役に立つものです。アプリケーションの特徴的な振る舞いを、様々なレベルのスケールでテストし、継続的にモニタリングすることで、システムが適切にサイジングされているかを確認できます。

 第二部ではCouchbase Server 2.0クラスタをデプロイする際の考慮事項について、より深く解説します。

Till next time...

Comments