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

DataStax EnterpriseまたはApache Cassandraに適したハードウェアの選択は、メモリー、CPU、ディスク、ノード数、およびネットワークの正しいバランスを選択することにかかっています。

DataStax EnterpriseまたはApache Cassandraに適したハードウェアの選択は、ユース・ケースによります。メモリー、CPU、ディスク、ノード数、およびネットワークの正しいバランスは、あまりアクセスされない静的データのある環境と、頻繁にアクセスされる揮発性データのある環境では、大きく異なります。「DataStax EnterpriseとApache Cassandra™でのアンチパターン」を必ずお読みになり、SANストレージ、NASデバイス、およびNFSに関する重要な情報を確認してください。

重要: これらの推奨事項はガイドラインです。期待どおりの実装を行うには、DataStaxサービス・チームに連絡し、デプロイ前に構成を徹底的にテストすることをお勧めします。

テストを行うには、目的の構成に対してcassandra-stressツールを使用します。ブートストラップ、リペア、障害などの一般的な管理操作をテストして、選択したハードウェアがビジネス上のニーズを満たしていることを確認してください。「実稼働環境での使用前のクラスターのテスト」を参照してください。

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

メモリー 

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

専用ハードウェア環境と仮想環境の両方で推奨されるメモリーは次のとおりです。

  • 実稼働:32 GB〜512 GB。最低8 GB(Cassandraのみの場合)、32 GB(DataStax EnterpriseのAnalyticsノードとSearchノードの場合)。
  • 非負荷テスト環境での開発:4 GB未満。
  • DSE Graph:DSE SearchまたはDSE Analyticsの特定の組み合わせに加えて2〜4 GB。大容量の専用グラフ・キャッシュが必要な場合は、RAMを追加してください。
  • Javaヒープ・スペース。「Javaリソースの調整」を参照してください。
  • ガーベージ・コレクション:「Tuning the JVM for optimal Java garbage collection」を参照してください。
  • DSE Searchヒープ割り当て。「Capacity planning for DSE Search」を参照してください。

CPU 

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

  • 実稼働環境の専用ハードウェア:16コアのCPUプロセッサーが現在の価格性能比のスイート・スポットになっています。
  • 非負荷テスト環境での開発における専用ハードウェア:2コアCPUプロセッサーで十分です。
  • DSE Graph:クエリーの最適化と結果セットの準備により、グラフ・クエリーがCPUのボトルネックになることがあるため、若干大型のCPUが推奨されます。

回転式ディスクとソリッド・ステート・ドライブ(ローカルのみ)の対比 

注: クラウド・デプロイについては、DataStaxサービス・チームにお問い合わせください。

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

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

特定のデプロイおよびワークロードに必要な最もコスト効率の良い選択肢を判断するのに手助けが必要な場合は、DataStaxサービス・チームにご連絡ください。

ディスク領域 

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

SSTableは、定期的にコンパクションされます。コンパクションは、データをマージして再度書き込み、古いデータを削除することにより、パフォーマンスを向上させます。ただし、コンパクションのタイプおよびサイズによっては、コンパクション・ディスクの使用率およびデータ・ディレクトリーのボリュームが一時的に増えることがあります。このため、ノード上に適切な量の空きディスク領域を必ず確保してください。

大規模コンパクションの場合:
コンパクション・ストラテジ 要件
SizeTieredCompactionStrategy(STCS) すべてのSSTableコンパクションの合計は、残りのディスク領域よりも小さくなければなりません。
注: 最悪な例:50%の空きディスク領域。このシナリオは、すべてのSSTableが1つの巨大なSSTableにマージされる手動コンパクションで発生する可能性があります。
LeveledCompactionStrategy(LCS) 通常は10%。最悪な例:レベル0のバックログが32 SSTableを超えた場合、50%(LCSではレベル0にSTCSを使用します)。
DateTieredCompactionStrategy(DTCS) テーブルのmax_window_size_secondsプロパティで指定した期間にシステムが書き込むデータ量と同じ空き容量。
TimeWindowCompactionStrategy(TWCS)  

推奨事項

重要: 以下の推奨事項は出発点として使用してください。実稼働環境でデプロイする前に、必ず徹底的にテストしてください。DataStaxでは、目的の構成に対してcassandra-stressを使用してテストすることを強くお勧めしています。ブートストラップ、リペア、障害などの一般的な管理操作をテストして、選択したハードウェアがビジネス上のニーズを満たしていることを確認してください。「実稼働環境での使用前のクラスターのテスト」を参照してください。
ノードあたりの容量(ノード密度) 
ノード密度の決定は、さまざまな要因によって左右されます。考慮が必要な要因は以下のとおりです。
  • ユース・ケース:たとえば、データが頻繁に変更されるかどうかや、どの程度の頻度でアクセスされるかなどがあります。
  • コンパクション・ストラテジ:コンパクション・ストラテジの選択は、ワークロードで書き込みと読み取りのどちらが多いかや、時間に依存するかどうかによって決まります。上述の「ディスク領域」を参照してください。
  • ネットワーク・パフォーマンス:リモート・リンクは多くのユース・ケースおよび予想帯域幅の制限要因になる場合があります。
  • ストレージの速度と、ストレージがローカルかどうか。
  • レプリケーション係数:「データ分散」を参照してください。
  • SLAと、障害を処理する能力。

SSDでは、SLA(サービスレベル契約)、アクセス頻度、データ更新頻度に基づいて、ノードあたり最大3〜5 TBのディスク領域を無圧縮データに使用できます。ただし、これほどの容量の使用は環境に依存するほか、データが静的で、アクセス率が低い場合に最も有効です。環境にかかわらず、メンテナンス(日常業務)とノードの追加や置換などのアクティビティでパフォーマンスに影響が及びます。状況によっては、数日かかる操作もあります。

ほとんどのワークロード(すべてではない)のコンパクション・ストラテジ:
  • STCS(SizeTieredCompactionStrategy):
    • HDD:500 GB
    • SSD:2 TB
  • LCS(LeveledCompactionStrategy):
    • HDD:500 GB
    • SSD:600 GB
  • DTCS(DateTieredCompactionStrategy):(データ・モデルに対してDTCSが最適と想定)
  • TWCS(TimeWindowCompactionStrategy):
Searchノード容量 
最高のパフォーマンスを得るために、Searchノードには最大500 GBの容量を使用してください。それ以上の容量が必要な場合は、広範なテストを行うか、またはDataStaxサービス・チームに相談することをお勧めします。「Capacity planning for DSE Search」を参照してください。
容量およびI/O 
ノードのディスクを選択するときは、容量(格納する予定のデータの量)とI/O(書き込み/読み取りのスループット速度)の両方を考慮してください。ワークロードによっては、低価格のSATAディスクを使用し、(より大きなRAMを持つ)ノードを追加してディスクの容量およびI/Oを拡張する方が適切な場合があります。
ディスクの数 - SATA 
DataStax EnterpriseとCassandraには、ノードあたり最低2台のディスクが必要で、1台はコミット・ログ用、もう1台はデータ・ディレクトリ用です。最低でも、コミット・ログは専用のパーティション上に存在する必要があります。
コミット・ログ・ディスク - SATA 
ディスクは大容量である必要はありませんが、すべての書き込みを追加書き込み(シーケンシャルI/O)として受け取るために十分な速さが必要です。
コミット・ログ・ディスク - SSD 
回転式ディスクとは異なり、コミット・ログとSSTableを同じ場所に格納できます。
DSE Search - SSD 
DSE Searchでは非常に多くのI/Oが行われるため、Cassandraデータと検索データは異なるSSDに格納する必要があります。そうしないと、両方のワークロードによってSSDの限界を超えてしまう可能性があります。
データ・ディスク 
ノードごとに1台以上のディスクを使用して、データ量に対して十分な容量であることと、メモリーにキャッシュされない読み取りとコンパクションに追従できる十分な速さであることを確認してください。
データ・ディスク上のRAID 
通常は、以下の理由からRAIDを使用する必要はありません。
  • データは、選択したレプリケーション係数に基づいて、クラスター全体にレプリケートされます。
  • Cassandraには、ディスク管理機能であるJBOD(Just a bunch of disks)が含まれます。Cassandraは、影響を受けるノードの停止、または故障したドライブをブラックリストに入れることにより、可用性または整合性の要件に従って対応するので、RAID 10を採用しなくても、大容量のディスク・アレイを持つCassandraノードをデプロイできます。また、可用性または整合性の要件に沿って、影響を受けたノードを停止したり、故障したドライブをブラックリストに入れたりするようにCassandraを構成することができます。「JBODを使用した復旧」も参照してください。
コミット・ログ・ディスク上のRAID 
通常、コミット・ログ・ディスクにRAIDは必要ありません。レプリケーションにより、データ喪失を十分に回避できます。さらに冗長性が必要な場合は、RAID 1を使用してください。
拡張ファイル・システム 
DataStaxでは、CassandraをXFSまたはext4上にデプロイすることを推奨しています。ext2またはext3では、64ビットのカーネルを使用していても、ファイルの最大サイズは2 TBです。ext4では、16 TBです。

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

ネットワーク 

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

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

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

ファイアウォール 

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

cassandra.yamlファイルの場所は、インストールのタイプによって異なります。
パッケージ・インストール /etc/cassandra/cassandra.yaml
tarボール・インストール install_location/resources/cassandra/conf/cassandra.yaml
Windows 3.0インストール C:\Program Files\DataStax Community\apache-cassandra\conf\cassandra.yaml
Windows 3.xインストール C:\Program Files\DataStax-DDC\apache-cassandra\conf\cassandra.yaml
cassandra-stressツール
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
Javaリソースの調整
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
データ分散
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
コンパクションの構成
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
JBODを使用した復旧
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
rpc_address
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
listen_address
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
ファイアウォール・ポート・アクセスの構成
Cassandraポート DataStax Enterpriseポート
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows  
max_window_size_seconds
max_window_size_seconds
CQLバージョン 対応するCassandraバージョン 対応するDataStax Enterpriseバージョン
CQL 3.1 2.0, 2.1 4.5および4.6(廃止予定)
CQL 3.2 3.0、3.x 4.7, 4.8, 5.0
DSE Searchのキャパシティの計画
DataStax Enterpriseバージョン
DataStax Enterprise 4.7
DataStax Enterprise 4.8
DataStax Enterprise 5.0