最適なパフォーマンスを得るためのベスト プラクティス
Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフル マネージド サービスです。 このサービスでは、各ワークロードの特定のニーズに応じて構成をオーバーライドすることもできます。これにより、必要に応じて最大限の柔軟性と制御が可能になります。 この記事では、パフォーマンスを最適化する方法に関するヒントを提供します。
最適なセットアップと構成
レプリケーション係数、ディスク数、ノード数、SKU
Azure ではほとんどのリージョンで "3 つ" の可用性ゾーンがサポートされており、Cassandra Managed Instance により可用性ゾーンがラックにマップされるため、カーディナリティの高いパーティション キーを選択してホット パーティションを回避することをお勧めします。 最適なレベルの信頼性とフォールト トレランスを実現するために、レプリケーション係数 3 を構成することを強くお勧めします。 また、ノードの数としてレプリケーション係数の倍数 (3、6、9 など) を指定することもお勧めします。
プロビジョニングするディスクの数に対して RAID 0 を使用します。 そのため、最適な IOPS を得るには、選択した SKU の最大 IOPS を P30 ディスクの IOPS と合わせて確認する必要があります。 たとえば、Standard_DS14_v2 SKU では 51,200 のキャッシュされていない IOPS がサポートされているのに対して、単一の P30 ディスクの基本パフォーマンスは 5,000 IOPS です。 従って、4 つのディスクでは 20,000 IOPS になり、マシンの制限を大きく下回ります。
SKU とディスク数に対してワークロードの広範なベンチマークを行うことを強くお勧めします。 コアが 8 つのみの SKU の場合は特にベンチマークが重要です。 調査したところ、8 コア CPU は要求が最も少ないワークロードにしか機能せず、ほとんどのワークロードのパフォーマンスを発揮するには少なくとも 16 コアが必要です。
分析ワークロードとトランザクション ワークロード
トランザクション ワークロードでは通常、低待機時間向けに最適化されたデータ センターが必要であるのに対し、分析ワークロードでは多くの場合、より複雑なクエリが使用され、実行時間が長くなります。 ほとんどの場合、別々のデータ センターが必要になります。
- 低待機時間向けに最適化されたものが 1 つ
- 分析ワークロード向けに最適化されたものが 1 つ
分析ワークロード向けに最適化する
分析ワークロードには、次の cassandra.yaml 設定を適用することをお勧めします (適用方法については、こちらを参照してください)。
Timeouts
| 値 | Cassandra MI の既定値 | 分析ワークロードの推奨値 |
|---|---|---|
| read_request_timeout_in_ms | 5,000 | 10,000 |
| range_request_timeout_in_ms | 10,000 | 20,000 |
| counter_write_request_timeout_in_ms | 5,000 | 10,000 |
| cas_contention_timeout_in_ms | 1,000 | 2,000 |
| truncate_request_timeout_in_ms | 60,000 | 120,000 |
| slow_query_log_timeout_in_ms | 500 | 1,000 |
| roles_validity_in_ms | 2,000 | 120,000 |
| permissions_validity_in_ms | 2,000 | 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 メトリックを表示できます。
ヒント
現実的な CPU ビューが必要な場合は、フィルターを追加し、プロパティを Usage kind=usage_idle で分割します。 この値が 20% 未満の場合は、分割を適用して、すべての使用種別ごとの使用状況を取得できます。
CPU がほとんどのノードで恒久的に 80% を超えると、データベースがオーバーロードになり、複数のクライアントでタイムアウトが発生します。 このシナリオでは、次のアクションを実行することをお勧めします。
- より多くの CPU コアを持つ SKU に垂直方向にスケールアップする (特にコア数が 8 以下の場合)。
- ノードを追加して水平方向にスケーリングする (前述のように、ノードの数はレプリケーション係数の倍数である必要がある)。
CPU が少数のノードでのみ高く、他のノードで低い場合は、ホット パーティションを示しており、さらなる調査が必要です。
Note
SKU の変更は、Azure Portal、Azure CLI、ARM テンプレートのデプロイを介してサポートされます。 ARM テンプレートをデプロイまたは編集し、SKU を次のいずれかに置き換えることができます。
- Standard_E8s_v4
- Standard_E16s_v4
- Standard_E20s_v4
- Standard_E32s_v4
- Standard_DS13_v2
- Standard_DS14_v2
- Standard_D8s_v4
- Standard_D16s_v4
- Standard_D32s_v4
- Standard_L8s_v3
- Standard_L16s_v3
- Standard_L32s_v3
- Standard_L8as_v3
- Standard_L16as_v3
- Standard_L32as_v3
現在、SKU ファミリ間の移行はサポートされていないことに注意してください。 たとえば、現在、Standard_DS13_v2 があり、Standard_DS14_v2 などのより大きな SKU へのアップグレードに関心がある場合、このオプションは使用できません。 しかし、サポート チケットを開いて、上位 SKU へのアップグレードを要求できます。
ディスクのパフォーマンス
サービスは Azure P30 マネージド ディスク上で実行され、"バースト IOPS" が可能になります。 ディスク関連のパフォーマンスのボトルネックに関して、慎重な監視が必要です。 この場合は、IOPS メトリックを確認することが重要です。
メトリックに次の特性の 1 つまたはすべてが表示される場合、スケールアップの必要を示している可能性があります。
- 常に基本 IOPS (5,000 IOPS にノードあたりのディスク数を乗算して数を取得すること) 以上である。
- 常に SKU で許容される書込みの最大 IOPS 以上である。
- SKU がキャッシュ ストレージ (write-through-cache) をサポートしており、この数がマネージド ディスクからの IOPS より小さい (これが読み取り IOPS の上限になる)。
IOPS が少数のノードに対してのみ上昇している場合は、ホット パーティションが発生している可能性があり、潜在的なスキューがないかデータを確認する必要があります。
IOPS が、選択した SKU でサポートされている値より低いが、ディスク IOPS 以上の場合は、次のアクションを実行できます。
- ディスクを追加して、パフォーマンスを向上させる。 ディスクを増やすには、サポート ケースを生成する必要があります。
- ノードを追加して、データ センターをスケールアップする。
IOPS が SKU がサポートする最大値に達した場合は、次のことができます。
- より多くの IOPS をサポートする別の SKU にスケールアップする。
- ノードを追加して、データ センターをスケールアップする。
詳細については、「仮想マシンとディスクのパフォーマンス」を参照してください。
ネットワーク パフォーマンス
ほとんどの場合、ネットワーク パフォーマンスは十分です。 しかしながら、データを頻繁にストリーミングしている (水平方向のスケールアップ/スケールダウンを頻繁に行うなど) 場合やイングレス/エグレス データ移動が膨大な場合、これが問題になる可能性があります。 場合により、SKU のネットワーク パフォーマンスの評価が必要になります。 たとえば、Standard_DS14_v2 SKU では 12,000 Mb/秒がサポートされているので、これをメトリックのバイトイン/アウトと比較します。
ネットワークが少数のノードに対してのみ上昇している場合、ホット パーティションが発生している可能性があり、データ分散やアクセス パターンで潜在的なスキューがないか確認する必要があります。
- より多くのネットワーク I/O をサポートする別の SKU に垂直方向にスケールアップする。
- ノードを追加して、クラスターを水平方向にスケールアップする。
接続されているクライアントが多すぎる
アプリケーションの望ましい待機時間に必要な並列要求の最大数をサポートするようにデプロイを計画してプロビジョニングする必要があります。 特定のデプロイでは、システムに最小しきい値を超える負荷が生じると、全体的な待機時間が長くなります。 接続されているクライアントの数を監視して、許容できる制限を超えないようにします。
ディスク領域
ほとんどの場合、既定のデプロイは IOPS 向けに最適化されているため、十分なディスク領域があり、ディスクの使用率は低くなります。 それでも、ディスク領域のメトリックを定期的に確認することをお勧めします。 Cassandra には大量のディスクが蓄積され、圧縮がトリガーされると、ディスクが減ります。 このため、ディスク使用量をより長期間にわたって確認して、圧縮しても領域を取り戻せないといった傾向を明らかにすることが重要です。
Note
圧縮に使用できる領域を確保するには、ディスク使用率を約 50% に保つ必要があります。
この挙動が少数のノードでのみ見られる場合、ホット パーティションが発生している可能性があり、データ分散やアクセス パターンで潜在的なスキューがないか確認する必要があります。
- ディスクを追加するが、SKU によって課される IOPS 制限に留意する
- クラスターを水平方向にスケールアップする
JVM メモリ
既定の数式では、VM のメモリの半分が JVM に割り当てられ、上限は 31 GB です。これはほとんどの場合、パフォーマンスとメモリのバランスが良好です。 一部のワークロード、特にパーティションをまたぐ読み取りや範囲スキャンを頻繁に行うワークロードで、メモリの問題が発生する可能性があります。
ほとんどの場合、メモリは Java ガベージ コレクターによって効果的に再利用されますが、特に CPU が 80% を超えることが多い場合、ガベージ コレクターに十分な CPU サイクルが残っていません。 そのため、CPU パフォーマンスの問題は、メモリの問題より前に対処する必要があります。
CPU が 70% 未満で推移し、ガベージ コレクションでメモリを再利用できない場合、より多くの JVM メモリが必要になることがあります。 これは、メモリが限られている SKU を使用している場合に特に当てはまります。 ほとんどの場合、クエリとクライアント設定を確認し、CQL クエリ内の limit で選択されている内容と共に fetch_size を減らす必要があります。
実際により多くのメモリが必要な場合は、次のことができます。
- JVM メモリ設定を増やすためのチケットを提出する
- より多くのメモリが利用可能な SKU に垂直方向にスケーリングする
廃棄標識
TTL の有効期限が切れた行 ("廃棄標識" と呼ばれる) を削除するリーパーを使用して、7 日ごとに修復を実行します。 ワークロードによっては、削除の頻度が高く、Cassandra ログに Read 96 live rows and 5035 tombstone cells for query SELECT ...; token <token> (see tombstone_warn_threshold) のような警告や、廃棄標識が多すぎるためにクエリを実行できなかったことを示すエラーが表示される場合があります。
クエリが満たされない場合の短期的な軽減策は、Cassandra 構成の 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.
この場合は、クエリを確認して、推奨されるバッチ サイズを下回るようにする必要があります。 まれに、短期的な軽減策として、Cassandra 構成の batch_size_fail_threshold_in_kb を既定値の 50 から高い値に増やすことができます。
大きなパーティションの警告
次の警告が CassandraLogs に表示される場合があります。
Writing large partition <table> (105.426MiB) to sstable <file>
これは、データ モデルに問題があることを示しています。 詳細については、stack overflow の記事を参照してください。 これは、重大なパフォーマンスの問題を引き起こす可能性があり、対処する必要があります。
特殊な最適化
圧縮
Cassandra では、テーブルの作成時に適切な圧縮アルゴリズムを選択できます (「圧縮」を参照)。既定値は LZ4 で、これはスループットと CPU には優れていますが、ディスク上の領域を多く消費します。 Zstd (Cassandra 4.0 以上) を使用すると、CPU オーバーヘッドを最小限に抑えながら約 12% の領域を節約できます。
memtable ヒープ領域の最適化
既定では、cassandra.yaml の memtable_heap_space に JVM ヒープの 1/4 を使用します。 書き込み指向のアプリケーションや、メモリが小さい SKU の場合、フラッシュが頻繁に行われ、sstable が断片化され、さらに圧縮が必要になることがあります。 このような場合は、少なくとも 4048 に増やすことが有益ですが、他の操作 (読み取りなど) が影響を受けないように、慎重なベンチマークが必要です。
次のステップ
この記事では、最適なパフォーマンスを得るためのベスト プラクティスをいくつか紹介しました。 これで、クラスターの操作を開始できます。