Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフル マネージド サービスです。 サービスでは、各ワークロードの特定のニーズに応じて、構成をオーバーライドすることもできます。 この機能により、必要に応じて最大限の柔軟性と制御が可能になります。 この記事では、パフォーマンスを最適化する方法に関するヒントを提供します。
最適なセットアップと構成
レプリケーション係数、ディスク数、ノード数、および製品レベル
Azure では、ほとんどのリージョンで 3 つの 可用性ゾーンがサポートされています。 Azure Managed Instance for Apache Cassandra は、可用性ゾーンをラックにマップします。 ホット パーティションを回避するために、カーディナリティの高いパーティション キーを選択することをお勧めします。 最適なレベルの信頼性とフォールト トレランスを実現するには、レプリケーション係数 3 を構成することを強くお勧めします。 また、ノードの数としてレプリケーション係数の倍数を指定することをお勧めします。 たとえば、3、6、9 などを使用します。
Azure では、プロビジョニングしたディスクの数に対して RAID 0 が使用されます。 1 秒あたりの最適な入力/出力操作 (IOPS) を取得するには、選択した製品レベルの最大 IOPS と P30 ディスクの IOPS を確認します。 たとえば、 Standard_DS14_v2 製品レベルでは、51,200 のキャッシュされていない IOPS がサポートされます。 1 つの P30 ディスクの基本パフォーマンスは 5,000 IOPS です。 4 つのディスクは 20,000 IOPS になり、マシンの制限を大きく下回ります。
製品レベルとディスク数に対するワークロードの広範なベンチマークを強くお勧めします。 ベンチマークは、8 コアのみの製品レベルでは特に重要です。 私たちの研究では、8 コア CPU が最も要求の厳しいワークロードにのみ機能することを示しています。 ほとんどのワークロードでは、適切に実行するために少なくとも 16 個のコアが必要です。
分析ワークロードとトランザクション ワークロード
通常、トランザクション ワークロードには、低待機時間用に最適化されたデータセンターが必要です。 分析ワークロードでは、多くの場合、より複雑なクエリが使用されるため、実行に時間がかかります。 ほとんどの場合、次の機能を備えた個別のデータセンターが必要です。
- 低待機時間用に最適化された 1 つ。
- 分析ワークロード用に最適化された 1 つ。
分析ワークロードの最適化
分析ワークロードには、次の cassandra.yaml 設定を適用することをお勧めします。 これらの設定を適用する方法の詳細については、「 Cassandra 構成の更新」を参照してください。
Timeouts
| 価値 | Cassandra MI の既定値 | 分析ワークロードの推奨値 |
|---|---|---|
read_request_timeout_in_ms |
5,000 | 1万 |
range_request_timeout_in_ms |
1万 | 20,000 |
counter_write_request_timeout_in_ms |
5,000 | 1万 |
cas_contention_timeout_in_ms |
1,000 | 二千 |
truncate_request_timeout_in_ms |
60,000 | 120,000 |
slow_query_log_timeout_in_ms |
500 | 1,000 |
roles_validity_in_ms |
二千 | 120,000 |
permissions_validity_in_ms |
二千 | 120,000 |
キャッシュ
| 価値 | Cassandra MI の既定値 | 分析ワークロードの推奨値 |
|---|---|---|
file_cache_size_in_mb |
2,048 | 6,144 |
その他の推奨値
| 価値 | Cassandra MI の既定値 | 分析ワークロードの推奨値 |
|---|---|---|
commitlog_total_space_in_mb |
8,192 | 16,384 |
column_index_size_in_kb |
64 | 16 |
compaction_throughput_mb_per_sec |
128 | 256 |
クライアントの設定
サーバーに適用されるタイムアウトに従って、Cassandra クライアント ドライバーのタイムアウトを増やすことをお勧めします。
待ち時間を短縮するために最適化する
既定の設定は、待機時間の短いワークロードに既に適しています。 末尾の待機時間に最適なパフォーマンスを確保するために、 投機的実行 をサポートするクライアント ドライバーを使用し、それに応じてクライアントを構成することを強くお勧めします。 Java V4 ドライバーの場合、デモでは、このプロセスのしくみと、 このサンプルのポリシーを有効にする方法を示します。
パフォーマンスのボトルネックを監視する
CPU パフォーマンス
すべてのデータベース システムと同様に、Cassandra は、CPU 使用率が約 50% で 80% を超えない場合に最適に動作します。 CPU メトリックを表示するには、Azure portal の [ 監視 ] セクションで [ メトリック ] タブを開きます。
現実的な CPU ビューの場合は、フィルターを追加し、 Usage kind=usage_idle を使用してプロパティを分割します。 この値が 20%より小さい場合は、分割を適用して、すべての使用状況の種類による使用量を取得します。
ほとんどのノードで CPU が完全に 80% を超える場合、データベースはオーバーロードされ、複数のクライアント タイムアウトが発生します。 このシナリオでは、次のアクションを実行することをお勧めします。
- 特にコア数が 8 以下の場合は、CPU コア数が多い製品レベルに垂直方向にスケールアップします。
- ノードを追加して水平方向にスケーリングします。 前述のように、ノードの数はレプリケーション係数の倍数である必要があります。
CPU が少数のノードに対してのみ高く、他のノードでは低い場合は、ホット パーティションを示します。 このシナリオでは、さらに調査が必要です。
製品レベルの変更は、Azure portal、Azure CLI、Azure Resource Manager テンプレート (ARM テンプレート) のデプロイを使用してサポートされます。 ARM テンプレートをデプロイまたは編集し、製品レベルを次のいずれかの値に置き換えることができます。
Standard_E8s_v4Standard_E16s_v4Standard_E20s_v4Standard_E32s_v4Standard_DS13_v2Standard_DS14_v2Standard_D8s_v4Standard_D16s_v4Standard_D32s_v4Standard_L8s_v3Standard_L16s_v3Standard_L32s_v3Standard_L8as_v3Standard_L16as_v3Standard_L32as_v3
現在、製品ファミリ間の移行はサポートされていません。 たとえば、現在 Standard_DS13_v2 を所有していて、 Standard_DS14_v2などの大規模な製品にアップグレードする場合、このオプションは使用できません。 サポート チケットを開き、上位の製品へのアップグレードを要求します。
ディスクのパフォーマンス
このサービスは Azure P30 マネージド ディスク上で実行されます。これにより、 バースト IOPS が可能になります。 ディスク関連のパフォーマンスのボトルネックに関しては、慎重な監視が必要です。 この場合、IOPS メトリックを確認することが重要です。
メトリックに次の特性のいずれかが表示される場合は、スケールアップが必要になる場合があります。
- メトリックは一貫して基本 IOPS 以上です。 ノードあたりのディスク数で 5,000 IOPS を乗算して、その数を取得してください。
- メトリックは、書き込みに対して製品階層で許可されている最大IOPSと同等以上の値を一貫して記録しています。
- 製品レベルではキャッシュストレージ (ライトスルー キャッシュ) がサポートされており、この数はマネージド ディスクの IOPS よりも小さくなります。 この値は、読み取り IOPS の上限です。
少数のノードに対してのみ IOPS が昇格されている場合は、ホット パーティションがあり、データのスキューの可能性を確認する必要がある可能性があります。
IOPS が製品レベルでサポートされているものより低く、ディスク IOPS 以上の場合は、次のアクションを実行します。
- さらにノードを追加して 、データセンターをスケールアップします。
IOPS が製品レベルでサポートされている上限に達した場合は、次のことができます。
- より多くの IOPS をサポートする別の製品レベルにスケールアップします。
- さらにノードを追加して 、データセンターをスケールアップします。
詳細については、「 仮想マシンとディスクのパフォーマンス」を参照してください。
ネットワーク パフォーマンス
通常、ネットワーク パフォーマンスで十分です。 データを頻繁にストリーミングする場合 (水平方向のスケールアップ/スケールダウンが頻繁に発生する場合や、大量のイングレス/エグレス データの移動がある場合など)、このパフォーマンスが問題になる可能性があります。 製品レベルのネットワーク パフォーマンスを評価する必要がある場合があります。 たとえば、 Standard_DS14_v2 製品レベルでは 12,000 Mb/秒がサポートされています。 この値をメトリックのバイトイン/アウトと比較します。
少数のノードに対してのみネットワークが昇格されている場合は、ホット パーティションが存在する可能性があります。 データ分散とアクセス パターンを確認して、スキューの可能性を確認します。
- より多くのネットワーク I/O をサポートすることで、異なる製品レベルに垂直方向にスケールアップします。
- ノードを追加して、クラスターを水平方向にスケールアップする。
接続されているクライアントが多すぎる
アプリケーションの必要な待機時間に必要な並列要求の最大数をサポートするようにデプロイを計画およびプロビジョニングします。 特定のデプロイでは、最小しきい値を超える負荷をシステムに導入すると、全体的な待機時間が長くなります。 接続されているクライアントの数を監視して、この状況が許容できる制限を超えないようにします。
ディスク領域
ほとんどの場合、十分なディスク領域があります。 既定のデプロイは IOPS 用に最適化されており、ディスクの使用率が低くなります。 ただし、ディスク領域のメトリックを確認することをお勧めします。 Cassandra は多数のディスクを蓄積し、圧縮がトリガーされたときにそれらを減らします。 圧縮で領域を回収できない場合など、傾向を確立するには、より長い期間にわたってディスク使用量を確認することが重要です。
注
圧縮に使用できる領域を確保するには、ディスク使用率を約 50%に維持します。
この動作が少数のノードに対してのみ表示される場合は、ホット パーティションが存在する可能性があります。 データ分散とアクセス パターンを確認して、スキューの可能性を確認します。
- ディスクを追加しますが、製品レベルによって課される IOPS の制限に注意してください。
- クラスターを水平方向にスケールアップします。
JVM メモリ
既定の数式では、仮想マシンのメモリの半分が Java 仮想マシン (JVM) に割り当てられ、上限は 31 GB です。 ほとんどの場合、このアプローチはパフォーマンスとメモリのバランスが適切です。 一部のワークロード (特にパーティション間の読み取りまたは範囲スキャンが頻繁に行われるワークロード) は、メモリに問題がある可能性があります。
ほとんどの場合、メモリは Java ガベージ コレクターによって効果的に回収されます。 CPU が 80% を超えることが多い場合、ガベージ コレクターの CPU サイクルが不足しています。 メモリの問題を確認する前に、CPU パフォーマンスの問題に対処します。
CPU が 70% を下回り、ガベージ コレクションでメモリを再利用できない場合は、JVM メモリが必要になることがあります。 メモリが限られている製品レベルの場合は、JVM メモリを増やす必要があります。 ほとんどの場合、クエリとクライアント設定を確認し、Cassandra クエリ言語 (CQL) クエリ内のfetch_sizeで選択した内容と共にlimitを減らす必要があります。
より多くのメモリが必要な場合は、次のことができます。
- 使用可能なメモリが増える製品レベルに垂直方向にスケーリングします。
廃棄標識
リパーを使用して 7 日ごとに修復を実行します。これにより、有効期限 (TTL) が切れた行が削除されます。 これらの行は 墓石と呼ばれます。 一部のワークロードでは、より頻繁に削除され、Cassandra ログに Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) などの警告が表示されます。 一部のエラーは、過剰な廃棄石が原因でクエリを実行できなかったことを示しています。
クエリが満たされない場合の短期的な軽減策は、tombstone_failure_thresholdの値を既定の 100,000 から高い値に増やすことです。
また、キースペースの TTL を確認し、毎日修復を実行して、より多くの墓石をクリアすることをお勧めします。 TTL が短く (たとえば、2 日未満)、データがすばやく流れ込んで削除される場合は、 圧縮戦略 を確認し、 Leveled Compaction Strategyを優先することをお勧めします。 場合によっては、このようなアクションは、データ モデルのレビューが必要であることを示している場合があります。
バッチ警告
CassandraLogs で次の警告が発生し、関連する可能性のあるエラーが発生する可能性があります。
Batch for [<table>] is of size 6.740KiB, exceeding specified threshold of 5.000KiB by 1.740KiB.
クエリを確認し、推奨されるバッチサイズを超えないようにしてください。 まれに、短期的な軽減策として、batch_size_fail_threshold_in_kbのを既定値の 50 から高い値に増やします。
大きなパーティションの警告
CassandraLogs で次の警告が表示される場合があります。
Writing large partition <table> (105.426MiB) to sstable <file>
このメッセージは、データ モデルの問題を示します。 詳細については、この Stack Overflow の記事を参照してください。 この問題は、重大なパフォーマンスの問題を引き起こす可能性があり、対処する必要があります。
特殊な最適化
圧縮
Cassandra では、テーブルの作成時に適切な圧縮アルゴリズムを選択できます。 既定値は LZ4 で、スループットと CPU には優れていますが、ディスク上の領域が増えます。 Zstandard (Cassandra 4.0 および up) を使用すると、CPU オーバーヘッドを最小限に抑えながら約 12% の領域を節約できます。
memtableヒープ空間を最適化する
既定値は、 ファイル内のcassandra.yamlに JVM ヒープの 4 分の 1 を使用することです。 書き込み指向アプリケーションや、メモリの量が少ない製品レベルでは、この問題により、フラッシュが頻繁に発生し、 sstablesが断片化し、圧縮が必要になることがあります。 少なくとも 4,048 に増やすと良いかもしれません。 この方法では、他の操作 (読み取りなど) が影響を受けないように、慎重なベンチマークが必要です。