実稼働環境での使用前のクラスターのテスト 

クラスターのメモリー、CPU、ディスク、ノード数、ネットワークの設定がビジネス上のニーズを満たしていることを確認するためのテスト。

選択したメモリー、CPU、ディスク、ノード数、ネットワークの設定がビジネス上のニーズを満たしていることを確認するには、実稼動環境での使用前にクラスターをテストします。実稼動環境のワークロードをシミュレートすることにより、不愉快な不意打ちを回避し、実稼動環境でのデプロイを成功させることができます。

テスト用のワークロードは、実稼動環境のワークロードとできるだけ一致する必要があります。テストにおける実稼働環境との不一致は、ワークロード間の相違点が全面的に原因である必要があります。

リレーショナル・データベースの見地に立っているかどうかの検討 

Cassandraベースのアプリケーションとクラスターは、リレーショナル・データベースとは大きく異なり、モデリング・エンティティや関係ではなく、クエリーの種類に基づくデータ・モデルを使用します。新しいデータベース・テクノロジーとAPIを学ぶことに加え、単一のマシンではなく分散データベース上でスケールするアプリケーションの作成には、新しい考え方が必要になります。

単一のマシンから分散ノードに移行するために新しいユーザーが採用する一般的なストラテジは、マテリアライズド・ビュー、セカンダリ・インデックス、およびUDF(ユーザー定義関数)を多用することです。大規模なほとんどのアプリケーションでは、これらの手法はあまり使用されませんが、多用する場合は、ノードのサイズ決定とSLAでパフォーマンス・ペナルティを考慮に入れる必要があります。

サービス・レベル契約のターゲット 

実稼働環境に移行する前に、高速および低速のサービス・レベル契約(SLA)の内容と、低速のSLAの許容頻度を決定します。

要求パーセンタイル決定の基本的なルール
パーセンタイル ユース・ケース
100 推奨されません。最悪の測定値は、テストとは無関係であることが多く、Cassandraの外部の要因に基づいています。
99.9 積極的。レイテンシーに敏感なユース・ケースにのみ使用します。これを平均に近い値に保つ必要がある場合は、ハードウェアの負荷が高くなることに留意してください。
99 スイート・スポットであり、最も一般的です。
95 緩やか。レイテンシーに気付きにくい場合、このメトリクスを測定すると効果的です。

次のメトリクスは、ディスク上のデータがRAMよりも大きいクラスターに基づきます。測定値はnodetool cfhistograms(Cassandra 2.1)またはnodetool tablehistograms(Cassandra 3.0、3.x)の99%パーセンタイルにあります。

Apache Cassandra™レイテンシー・メトリクス
ハードウェア レイテンシー
NVMフラッシュ・ストレージ付き最上位CPUノード < 10ms
一般的なSATAベースのSSD < 150ms

この測定値は、テスト、コントローラー、競合などの要因によって大きく変わることがあります。これにより、一部のハードウェアがNVM仕様に近づく場合があります。

一般的なSATAベースシステム 500msが一般的です。

このメトリクスは、コントローラ、競合、データ・モデルなどによって大きく異なります。調整によってこの数値の桁数が変わることがあります。

TPSターゲットの確立 

クラスターで処理する1秒あたりのトランザクション数(TPS)を決定します。理想的には、この数値をテスト・クラスター内の同じノード数と一致させます。代わりに、ノードに対するTPSの割合を使ってテストし、クラスターの動作を評価します。

クラスターがSLA要件を満たさない場合は、根本原因を探します。次のような質問が効果的です。
  • クラスターはそのレベルより下のSLAを満たしているか。
  • SLAが不合格になるのはどのTPSレベルにおいてか。

重要なメトリクスの監視 

クラスター・メトリクスを監視するには、DataStax OpsCenterを使用します。さらにJMX MBeansまたはLinuxのiostatコマンドやdstatコマンドも使用できます。次のメトリクスを監視します。

システム・ヒント 
生成されるシステム・ヒントの数が絶えず多くてはなりません。ノードまたはデータ・センター・リンクがダウンしている場合、このメトリクスが累積される(意図的)ことを予想してください。
保留中のコンパクション 
許容される保留中のコンパクションの数は、コンパクション・ストラテジの種類によって異なります。
コンパクション・ストラテジ 保留中のコンパクション
SizedTieredCompactionStrategy(STCS) 短期間を超える場合は、100を超えてはなりません。
LeveledCompactionStrategy(LCS) 保留中のコンパクションに対しては正確な測定値ではありません。通常、100より大きい値が続く場合は、ストレスがあることを示します。1000より大きい値は、異常です。
DateTieredCompactionStrategy(DTCS) 1000を超えてはなりません。
保留中の書き込み 
短期間を超える場合は、書き込み回数が10,000を超えてはなりません。超えた場合、調整またはサイズ決定の問題があります。
ヒープ使用量 
長い一時停止で大きな急増がある場合、ヒープを調整します。
I/O待ち時間 
メトリクスが5より大きい場合、CPUのI/O待ち時間が長すぎることを意味し、I/Oバウンドになっているしるしです。
CPU使用量 
Hyper-Threadingを使用しているCPUの場合は、物理的に存在するプロセッサー・コアごとにオペレーティング・システムが2つの仮想(論理)コアを割り当て、それらの間でワークロードを共有します。これは、スレッドの半分でCPU使用率が100%である場合、ツールは50%の使用率をレポートしても、CPU容量は満杯となります。実際のスレッドの使用については、ttopコマンドを使用します。
SLAの監視 
で設定したターゲットに従って監視します。
SSTableの数 
SSTableの数が10,000を超えた場合は、「CASSANDRA-11831」を参照してください。
コンパクション・ストラテジ SSTableの数
SizedTieredCompactionStrategy(STCS) 100を大幅に上回ってはなりません。
LeveledCompactionStrategy(LCS) レベル0が100を大幅に上回らないようにしてください。
DateTieredCompactionStrategy(DTCS) DataStaxサービス・チームにお問い合わせください。
ログの警告とエラー 
以下がないかどうかを確認します。
  • SlabPoolCleaner
  • WARN
  • ERROR
  • GCInspector(G1GCを使用するCassandra 2.1〜3.0は冗長です)。
  • hints

実際の障害のシミュレート 

障害をシミュレートすることは、実稼動環境でクラスターが正常に機能することを確認するための鍵となります。障害をシミュレートするには、次の手順に従います。

  1. 1つか2つのノードをオフラインにします(クラスターのサイズによっては、それ以上の数のノードをオフラインにすることが必要な場合があります)。
    • クエリーの失敗が見られますか。
    • 再度オンラインにしたノードは、何の変化もなく機能しますか。
  2. 負荷を受けながら、データ・センターをオフラインにします。

    system.hintが管理不能なレベルになるまで、どれだけの時間オフラインにしておくことができますか。

  3. find "a / のように、2〜3のノード上でCPUに負担をかける高負荷のタスクを実行します。

    このシナリオにより、これが発生した場合のノードへの影響に備えることができます。

  4. 負荷を受けながら、CQLSHで高負荷の範囲クエリーを実行して、クラスターの動作を確認します。例:
    PAGING OFF;
    SELECT * FROM FOO LIMIT 100000000;

    このテストでは、クラスターをユーザーの経験不足による操作や意図しない操作に対して備えます。

実稼動環境の運用のシミュレート 

負荷テスト中に以下の操作を行い、前述の障害中に同じ操作を繰り返します。

  1. リペアを実行して、そのリペアを完了するために十分なオーバーヘッドがあることを確認します。
  2. 新しいノードをクラスターにブートストラップします。
  3. 新しいデータ・センターを追加します。この演習により、実稼動環境で行う必要がある場合のプロセスを把握することができます。
  4. 新しいテーブルの追加、テーブルの削除、既存のテーブルの変更により、スキーマを変更します。
  5. 障害が発生したノードを置換します。新しいノードのブートストラップにかかる時間に注意してください。

少なくとも5つのノードで実際のレプリケーション係数を実行します。 

実稼動環境で実行すると推定される数と同じ数のノードを実行することが理想的です。さらに、実稼働環境で3つのノードのみを実行することを計画している場合は、5つのノードでテストします。3つのノードで迅速に実行されたクエリーが5つのノードでは大幅に遅くなることが判明する場合もあります。このシナリオでは、共通クエリー・パスとしてのセカンダリ・インデックスは、より大きな規模では速度が遅いことが判明します。

必ず実稼働環境と同じレプリケーション係数を使用してください。

実稼働環境のデータ・センター・セットアップのシミュレート 

データ・センターごとに追加の書き込み負荷が発生します。実稼働環境のクラスターにテスト・クラスターよりも多くのデータ・センターがある場合、書き込みが予想以上に多くなる可能性があります。たとえば、RF 3を使用し、2つのデータ・センターでクラスターをテストすると、各書き込みは2つのデータ・センターの4つのノードで行われます。実稼働環境のクラスターで同じRFを使用し、5つのデータ・センターがある場合、各書き込みは5つのデータ・センターの7つのノードで行われます。つまり、コーディネーター・ノードでは書き込みがほぼ2倍の負荷となることを意味します。各リモート・データ・センターでは、転送コーディネーターがデータをそのデータ・センター内の他のレプリカに送信するためです。

ネットワーク・トポロジーのシミュレート 

同じレイテンシーとパイプを使用してネットワーク・トポロジーをシミュレートします。推定されるTPSでテストします。リモート・リンクは多くのユース・ケースおよび予想帯域幅の制限要因になる場合があることに留意してください。

推定されるノードあたりの密度のシミュレート 

注: 通常、SSD、数値の大きいCPU、上位RAMを使用していない限り、ノードあたり1テラバイト(TB)以上使用することが得策であることはほとんどありません。「Capacity per node recommendations」を参照してください。
ノード密度によってターゲットを決定したら、目的の容量になるまでテスト・クラスターにデータを追加していきます。以下をテストします。
  • 目的の密度に近づくとSLAはどうなるか。
  • 目的の密度を超えるとどうなるか。
  • ブートストラップにどれだけの時間がかかるか。
  • リペアにどれだけの時間がかかるか。

テストでのcassandra-stressツールの使用 

cassandra-stressツールは、クラスターの負荷テストおよび基本的なベンチマーク用のJavaベースのストレス・テスト・ユーティリティです。このツールを使用して、選択したハードウェアをテストし、データ・モデリングでの問題を検出します。Cassandra-stressは、読み取り、書き込み、およびそれらを組み合わせたワークロードのテスト用のYAMLベースのプロファイルのほか、さまざまなコンパクション・ストラテジ、キャッシュ設定、およびタイプのスキーマを指定する機能をサポートしています。「cassandra-stressツール」を参照してください。
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  
nodetool tablehistograms
Apache Cassandraバージョン 対応するDataStax Enterpriseバージョン
2.1 4.7, 4.8
3.0 Linux 5.0
3.x Linux  
3.0 Windows  
3.x Windows