プロダクション前のDataStax Enterpriseクラスターのテスト

リレーショナル・データベースの背景がある場合の考慮事項

DataStax Enterpriseベースのアプリケーションとクラスターはリレーショナル・データベースと大きく異なっており、実体と関係のモデリングではなく、クエリーのタイプに基づいたデータ・モデルを使用します。新しいデータベース・テクノロジーやAPIを学習する以外に、1台のマシンではなく分散データベースに拡大できるアプリケーションを作成するには、新たな考え方が必要です。

1台のマシンから分散ノードへと移行するために新規ユーザーが使用する一般的な戦略は、マテリアライズド・ビュー、セカンダリ・インデックス、およびUDF（ユーザー定義関数）を多用するというものです。ほとんどのアプリケーションにおいて、規模が大きくなると、これらの手法はあまり用いられず、用いる場合はノードのサイズ変更やSLAのパフォーマンス・ペナルティを考慮して余裕を持たせる必要があることを認識することが重要です。

サービス・レベル・アグリーメントのターゲット

プロダクション環境に入る前に、高速/低速のサービス・レベル・アグリーメント（SLA）の構成要素、さらに低速のSLAが認められる頻度を決定します。

次のメトリクスは、RAMよりもディスク上に多くデータがあるクラスターに基づいています。測定値はnodetool tablehistograms使用時の99パーセンタイルで表されています。

TPSターゲットを設定する

クラスターで処理する1秒あたりのトランザクション件数（TPS）を決定します。お使いのテスト・クラスターのノード数と同じ数にできれば理想的です。あるいは、ノードに対するTPSの比率をテストして、クラスターの動作を評価します。

重要なメトリクスの監視

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

システム・ヒント

生成されるシステム・ヒントの量は、継続的に高くあるべきではありません。ノードが停止している場合やデータ・センターがダウンしている場合は、このメトリクスが（設計上）累積されます。

保留中のコンパクション

許容される保留中のコンパクションの数は、コンパクション・ストラテジの種類によって異なります。

コンパクション・ストラテジ	保留中のコンパクション
SizedTieredCompactionStrategy（STCS）	短期間を超える場合、100件を超えないようにします。
LeveledCompactionStrategy（LCS）	保留中のコンパクションを表す、正確ではない測定値。一般的に、100を超えた状態が続くと、ストレスがかかっていることがうかがえます。1000を超える場合は異常です。
TimeWindowCompactionsStrategy（TWCS）

保留中の書き込み

短期間を超える場合に、10,000件の書き込みを超えないようにします。超えた場合、調整またはサイズ変更の問題があります。

ヒープ使用量

長い一時停止期間中に大きい山形が発生した場合は、ヒープを調整します。

I/O待機

5を上回るメトリクスは、CPUのI/Oの待ち時間が長すぎて、I/Oバウンドになっていることを示します。

CPU使用量

ハイパースレッディングを使用するCPUでは、物理的に存在する各プロセッサー・コアごとに、オペレーティング・システムが2つの仮想（論理）コアに対処して、2つのワークロードを共有することを覚えておくと便利です。これは、スレッドの半分のCPUの使用率が100%の場合、ツールで50%の使用率と報告されてもCPU容量は最大に達していることを意味します。実際のスレッド使用率を確認するには、ttopコマンドを使用します。

SLAの監視

上記で設定したターゲットに従って監視します。

SSTableの数

SSTableの数が10,000を超える場合は、CASSANDRA-11831を参照してください。

注: DateTieredCompactionStrategy（DTCS）は廃止される予定です。

ログの警告とエラー

以下を確認します。

• SlabPoolCleaner
• WARN
• ERROR
• GCInspector
• hints

実際の機能停止のシミュレーション

機能停止のシミュレーションを行うことは、クラスターがプロダクション環境で正常に機能することを確認する決め手となります。機能停止をシミュレーションするには：

1. 1～2つのノードをオフラインにします（クラスター・サイズによっては多い方が望ましい場合があります）。
   • クエリーは失敗し始めましたか。
   • オンラインに戻したとき、ノードは何の変更もなく機能を開始しましたか。
2. 負荷がかかっている状態でデータ・センターをオフラインにします。

   system.hintsが管理不能なレベルになるまで、どれぐらいの期間オフラインにすることができますか。

3. いくつかのノードで、「find "a /」のように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でテストします。多くのユース・ケースおよび想定される帯域幅にとって、リモート・リンクが限界要因になる場合があることにご注意ください。

想定されるノードあたりの密度のシミュレーション

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