エンタープライズ実装のためのハードウェアの選択

適切なハードウェアの選択は、メモリー、CPU、ディスク、ノード数、ネットワークなどのリソースの正しいバランスを選択することにかかっています。

適切なハードウェアの選択は、メモリー、CPU、ディスク、ノード数、ネットワークなどのリソースの正しいバランスを選択することにかかっています。「Cassandraにおけるアンチパターン」にも、ハードウェア、特にSANストレージ、NASデバイス、およびNFSに関する重要な情報が記載されています。

注意:
負荷テストまたは実稼働には、開発に適したマシンは使用しないでください。障害が発生する可能性があります。

メモリー 

Cassandraのノードのメモリーは多ければ多いほど、読み取りパフォーマンスも高くなります。RAMが多いとメモリー・テーブル(memtable)はより多くの最新の書き込みデータを保持できます。memtableが大きいと、ディスクにフラッシュされるSSTableが最小限になり、読み取り時にスキャンされるファイルも最小限となります。RAMの最適容量は、ホット・データの予測サイズによって決まります。

専用ハードウェア環境と仮想環境両方の場合:

  • 実稼働:16GB〜64GB。最小は8GB。
  • 非負荷テスト環境での開発:4GB未満。
  • Javaヒープ・スペースの設定については、「Javaリソースの調整」を参照してください。

CPU 

挿入の多いワークロードは、Cassandraではメモリーの限界に達する前にCPUの限界に達します(すべての書き込みはコミット・ログに記録されますが、Cassandraでは、書き込みは非常に効率的であるためCPUが限界要因です)。Cassandraは高度に並列処理され、使用可能な限り多くのCPUコアを使用します。

  • 実稼働環境:
    • 専用ハードウェアの場合、8コアのCPUプロセッサーが現在の価格性能比のスイート・スポットになっています。
    • 仮想環境の場合は、4〜8コアCPUプロセッサー。
  • 非負荷テスト環境での開発:
    • 専用ハードウェアの場合は、2コアCPUプロセッサー。
    • 仮想環境の場合は、2コアCPUプロセッサー。

回転式ディスク対ソリッド・ステート・ドライブ 

CassandraではSSDが推奨されます。SSDに搭載されているNANDフラッシュ・チップは、ランダム読み取り時に非常に低レイテンシーの応答時間を提供する一方で、コンパクション操作に対して十分なシーケンシャル書き込みパフォーマンスを提供します。近年、ドライブ・メーカーは全体的耐久性を向上させてきましたが、これは主に予備の(表に出ない)容量と組み合わせることによって実現されています。さらに、PBW/DWPDレーティングは、ランダム書き込みワークロードなど、最悪ケースのシナリオに基づく確率的推定値であり、Cassandraは大規模なシーケンシャル書き込みしか行わないため、ドライブは耐久力レーティングを大幅に超えます。それでも、ドライブの障害発生に備えて計画を立てて、予備のドライブを準備しておくことが重要です。サーバーのベンダーやサードパーティのドライブ・メーカーがさまざまなSSDを販売しています。

SSDの購入に当たっては、SSD耐久性をワークロードではなく、ドライブに障害が発生したときに交換作業がどれほど難しいのかを基準にして判断することが最善策です。忘れないでいただきたいのは、Cassandraがクラスター全体でデータをレプリケートしているため、データは保護されている、という点です。購入戦略には、以下が含まれます。
  • ドライブをすぐに入手できる場合は、必要なパフォーマンスを提供できる製品のうち価格が最も安いドライブを購入します。
  • ドライブのスワッピングが困難である場合は、高耐久性モデルの購入を検討します。おそらくはミッド・レンジから始めて、選択した当初モデルの障害発生率に基づいて、それより耐久性が高いか低い交換品を選択します。
  • 必ず低価格のSSDを購入し、当初のドライブに障害が発生するまで、複数台の予備品をサーバー内でオンラインかつ未使用状態に保ちます。こうすることで、サーバーに手を触れることなく、ドライブを交換することができます。

特定のデプロイおよびワークロードに必要なコスト効率の良い選択肢を決定するのに手助けが必要なDataStaxのお客様は、ソリューション・エンジニアまたはアーキテクトにご相談ください。

ディスク領域 

ディスク領域は使い方によって異なります。したがって、メカニズムを理解することが重要です。Cassandraは、永続性のためにデータをコミット・ログに追加するとき、および永続的な格納のためにmemtableSSTableデータ・ファイルにフラッシュするときに、データをディスクに書き込みます。コミット・ログに対するアクセス・パターン(読み取り/書き込み比率)は、SSTableのデータに対するパターンと異なります。これは、SSD(ソリッド・ステート・ドライブ)より、回転式ディスクの場合に重要となります。

SSTableは、定期的にコンパクションされます。コンパクションは、データをマージして再度書き込み、古いデータを削除することにより、パフォーマンスを向上させます。ただし、コンパクションの構成のタイプおよびコンパクションのサイズによっては、コンパクション・ディスクの使用率およびデータ・ディレクトリーのボリュームが一時的に増えることがあります。このため、ノード上に適切な量の空きディスク領域を確保する必要があります。大規模コンパクションの場合には、ノード上に十分なディスク領域を確保しましょう。SizeTieredCompactionStrategyおよびDateTieredCompactionStrategyには50%(最悪の場合)、LeveledCompactionStrategyには10%必要です。コンパクションの詳細については、以下を参照してください。

ディスク・サイズの計算方法については、「使用可能なディスク容量の計算」を参照してください。

推奨事項:

ノードあたりの容量
ほとんどのワークロードは、I/Oにもよりますが、ノードあたり500GB〜1TBの容量で最適に処理されます。無圧縮データについて、Cassandra 1.2以降で推奨される最大容量は、ノードあたり3〜5TBです。Cassandra 1.1の場合は、ノードあたり500〜800GBです。レプリケーションのことも必ず考慮してください。
容量およびI/O
ディスクを選択するときは、容量(格納する予定のデータの量)とI/O(書き込み/読み取りのスループット速度)の両方を考慮してください。ワークロードによっては、低価格のSATAディスクを使用し、(より大きなRAMを持つ)ノードを追加してディスクの容量およびI/Oを拡張する方が適切な場合があります。
ディスクの数 - SATA
Cassandraには、最低2台のディスクが必要で、1台はコミット・ログ用、もう1台はデータ・ディレクトリ用です。最低でも、コミット・ログは専用のパーティション上に存在する必要があります。
コミット・ログ・ディスク - SATA
ディスクは大容量である必要はありませんが、すべての書き込みを追加書き込み(シーケンシャルI/O)として受け取るために十分な速さが必要です。
コミット・ログ・ディスク - SSD
回転式ディスクとは異なり、コミット・ログとSSTableを同じ場所に格納できます。
データ・ディスク
1台以上のディスクを使用して、データ量に対して十分な容量であることと、メモリーにキャッシュされない読み取りとコンパクションに追従できる十分な速さであることを確認してください。
データ・ディスク上のRAID
通常は、以下の理由からRAIDを使用する必要はありません。
  • データは、選択したレプリケーション係数に基づいて、クラスター全体にレプリケートされます。
  • Cassandraのバージョン1.2以降は、ディスク管理機能であるJBOD(Just a bunch of disks)が含まれます。Cassandraは、影響を受けるノードの停止、または故障したドライブをブラックリストに入れることにより、ディスクの故障に適切に対応できるので、RAID 10を採用しなくても、大容量のディスク・アレイを持つCassandraノードをデプロイできます。可用性または整合性要件に沿って、影響を受けるノードを停止したり、故障したドライブをブラックリストに入れたりするようにCassandraを構成することができます。「JBODを使用した単一ディスク障害からの復旧」も参照してください。
コミット・ログ・ディスク上のRAID
通常、コミット・ログ・ディスクにRAIDは必要ありません。レプリケーションにより、データ喪失を十分に回避できます。さらに冗長性が必要な場合は、RAID 1を使用してください。
拡張ファイル・システム
DataStaxでは、CassandraをXFSまたはext4上にデプロイすることを推奨しています。ext2またはext3では、64ビットのカーネルを使用していても、ファイルの最大サイズは2TBです。ext4では、16TBです。

SizeTieredCompactionStrategyを使用する場合、Cassandraは1つのファイルでディスク領域のほぼ半分を使用することがあるので、大容量のディスクを使用する場合、特に32ビットのカーネルを使用する場合は、XFSを使用してください。XFSのファイル・サイズ制限は、32ビットのカーネルでは最大16TBで、64ビットでは実質的に無制限です。

ノード数 

バージョン1.2より前は、ノードあたりの推奨ディスク領域は300〜500GBでした。Cassandra 1.2になり、JBODのサポート、仮想ノード(vnode)、オフヒープ・ブルーム・フィルター、並列レベル化コンパクション(SSDノードのみ)などの改善により、数テラバイトのディスク領域を持つ、少ない台数のマシンで済むようになりました。

ネットワーク 

Cassandraは、分散型のデータ・ストアであるため、読み取り/書き込み要求およびノード間でのデータのレプリケーションを処理するために、ネットワークに負荷をかけます。ネットワークがノード間のトラフィックをボトルネックなしに処理できることを確認してください。インターフェイスを別々のネットワーク・インターフェイス・カードにバインドすると良いでしょう。要求に応じて、パブリックまたはプライベートを使用できます。

  • 推奨帯域幅は1000 Mbit/s(ギガビット)以上です。
  • Thrift/ネイティブのプロトコルは、rpc_addressを使用します。
  • Cassandraの内部ストレージ・プロトコルは、listen_addressを使用します。

Cassandraは、コーディネーター・ノードに地理的に最も近いレプリカに要求を効率的にルーティングし、可能であれば同じラック内のレプリカを選択します。リモート・データ・センターにあるレプリカより、同じデータ・センターにあるレプリカが常に選択されます。

ファイアウォール 

ファイアウォールを使用する場合は、クラスター内のノードが互いに通信できることを確認してください。「ファイアウォール・ポート・アクセスの構成」を参照してください。