Azure Managed Instance for Apache Cassandra は、純粋なオープンソースの Apache Cassandra クラスター用のフル マネージド サービスです。 サービスでは、各ワークロードの特定のニーズに応じて、構成をオーバーライドすることもできます。 この機能により、必要に応じて最大限の柔軟性と制御が可能になります。 この記事では、パフォーマンスを最適化する方法に関するヒントを提供します。
最適なセットアップと構成
レプリケーション係数、ディスク数、ノード数、SKU
Azure では、ほとんどのリージョンで 3 つの 可用性ゾーンがサポートされています。 Azure Managed Instance for Apache Cassandra は、可用性ゾーンをラックにマップします。 ホット パーティションを回避するために、カーディナリティの高いパーティション キーを選択することをお勧めします。 最適なレベルの信頼性とフォールト トレランスを実現するために、レプリケーション係数 3 を構成することを強くお勧めします。 また、ノードの数としてレプリケーション係数の倍数 (3、6、9 など) を指定することもお勧めします。
Azure では、プロビジョニングするディスクの数に対して 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 設定を適用することをお勧めします。 これらの設定を適用する方法の詳細については、「 Cassandra 構成の更新」を参照してください。
Timeouts
| 価値 | Cassandra MI の既定値 | 分析ワークロードの推奨値 |
|---|---|---|
| read_request_timeout_in_ms | 5,000 | 1万 |
| レンジリクエストのタイムアウト（ミリ秒単位） | 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 |
| 役割の有効性（ミリ秒単位） | 二千 | 120,000 |
| パーミッション有効期間_ミリ秒単位 | 二千 | 120,000 |
キャッシュ
| 価値 | Cassandra MI の既定値 | 分析ワークロードの推奨値 |
|---|---|---|
| ファイルキャッシュサイズ（MB単位） | 2,048 | 6,144 |
その他の推奨値
| 価値 | Cassandra MI の既定値 | 分析ワークロードの推奨値 |
|---|---|---|
| commitlog_total_space_in_mb | 8,192 | 16,384 |
| column_index_size_in_kb | 64 | 16 |
| 圧縮スループット（メガバイト/秒） | 128 | 256 |
クライアントの設定
サーバーに適用されているタイムアウトに従って、Cassandra クライアント ドライバーのタイムアウトを増やすことをお勧めします。
待機時間を短縮するための最適化
既定の設定は、既に低待機時間のワークロードに適しています。 テール レイテンシに最適なパフォーマンスを確保するためには、予測実行をサポートするクライアント ドライバーを使用し、それに応じてクライアントを構成することを強くお勧めします。 Java V4 ドライバーの場合、この動作とポリシーを有効にする方法を示すデモ をこのサンプルで見つけることができます。
パフォーマンスのボトル ネックを監視する
CPU パフォーマンス
すべてのデータベース システムと同様に、Cassandra は、CPU 使用率が約 50% で 80% を超えない場合に最適に動作します。 ポータルの [監視] 内の [メトリック] タブで、CPU メトリックを表示できます。
ヒント
現実的な CPU ビューが必要な場合は、フィルターを追加し、プロパティを Usage kind=usage_idle で分割します。 この値が 20% 未満の場合は、分割を適用して、すべての使用種別ごとの使用状況を取得できます。
ほとんどのノードで CPU が完全に 80% を超える場合、データベースはオーバーロードされ、複数のクライアント タイムアウトが発生します。 このシナリオでは、次のアクションを実行することをお勧めします。
- 特にコア数が 8 以下の場合は、CPU コア数が多い SKU に垂直方向にスケールアップします。
- ノードを追加して水平方向にスケーリングします。 前述のように、ノードの数はレプリケーション係数の倍数である必要があります。
CPU が少数のノードに対してのみ高く、他のノードでは低い場合は、ホット パーティションを示します。詳細な調査が必要です。
注
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 メトリックを確認することが重要です。
メトリックに次の特性のいずれかが表示される場合は、スケールアップが必要になる場合があります。
- 基本 IOPS より高いか、または等しい状態が一貫して維持されます。 ノードあたりのディスク数で 5,000 IOPS を乗算して、その数を取得してください。
- 常に SKU で許容される書込みの最大 IOPS 以上である。
- SKU はキャッシュされたストレージ (書き込みキャッシュ) をサポートしており、この数はマネージド ディスクからの IOPS よりも小さくなります。 この値は、読み取り IOPS の上限です。
IOPS が少数のノードに対してのみ上昇している場合は、ホット パーティションが発生している可能性があり、潜在的なスキューがないかデータを確認する必要があります。
IOPS が SKU でサポートされているものより低く、ディスク IOPS 以上の場合は、次のアクションを実行できます。
- ディスクを追加して、パフォーマンスを向上させる。 ディスクを増やすには、サポート ケースを生成する必要があります。
- ノードを追加して、データ センターをスケールアップします。
IOPS が SKU がサポートする最大値に達した場合は、次のことができます。
- より多くの IOPS をサポートする別の SKU にスケールアップします。
- ノードを追加して、データ センターをスケールアップします。
詳細については、「 仮想マシンとディスクのパフォーマンス」を参照してください。
ネットワーク パフォーマンス
ほとんどの場合、ネットワーク パフォーマンスで十分です。 ただし、データを頻繁にストリーミングしている場合 (水平方向のスケールアップ/スケールダウンが頻繁に発生する場合や、大量のイングレス/エグレス データの移動がある場合)、このパフォーマンスが問題になる可能性があります。 SKU のネットワーク パフォーマンスを評価することが必要な場合があります。 たとえば、 Standard_DS14_v2 SKU は 12,000 Mb/秒をサポートしています。 この値をメトリックのバイトイン/アウトと比較します。
少数のノードに対してのみネットワーク負荷が上昇している場合は、ホットパーティションが存在し、データの分散とアクセスパターンを見直して偏りがないか確認する必要があります。
- より多くのネットワーク I/O をサポートする別の SKU に垂直方向にスケールアップする。
- ノードを追加して、クラスターを水平方向にスケールアップする。
接続されているクライアントが多すぎる
アプリケーションの必要な待機時間に必要な並列要求の最大数をサポートするようにデプロイを計画し、プロビジョニングする必要があります。 特定のデプロイでは、システムに最小しきい値を超える負荷が生じると、全体的な待機時間が長くなります。 接続されているクライアントの数を監視して、この状況が許容できる制限を超えないようにします。
ディスク領域
ほとんどの場合、十分なディスク領域があります。 既定のデプロイは IOPS 用に最適化されており、ディスクの使用率が低くなります。 ただし、ディスク領域のメトリックを定期的に確認することをお勧めします。 Cassandra は多数のディスクを蓄積し、圧縮がトリガーされたときにそれを減らします。 圧縮で領域を回収できないなど、傾向を確立するには、より長い期間にわたってディスクの使用状況を確認することが重要です。
注
圧縮に使用できる領域を確保するには、ディスク使用率を約 50% に保つ必要があります。
少数のノードに対してのみこの動作が表示される場合は、ホット パーティションがあり、データ分散とアクセス パターンでスキューの可能性を確認する必要がある可能性があります。
- ディスクを追加するが、SKU によって課される IOPS 制限に留意する
- クラスターを水平方向にスケールアップする
JVM メモリ
既定の数式では、仮想マシンのメモリの半分が 31 GB の上限で Jave Virtual Machine (JVM) に割り当てられます。 ほとんどの場合、このアプローチはパフォーマンスとメモリのバランスが適切です。 一部のワークロード、特にパーティションをまたぐ読み取りや範囲スキャンを頻繁に行うワークロードで、メモリの問題が発生する可能性があります。
ほとんどの場合、メモリは Java ガベージ コレクターによって効果的に再利用されますが、特に CPU が 80% を超えることが多い場合、ガベージ コレクターに十分な CPU サイクルが残っていません。 そのため、CPU パフォーマンスの問題は、メモリの問題より前に対処する必要があります。
CPU が 70% 未満で推移し、ガベージ コレクションでメモリを再利用できない場合、より多くの JVM メモリが必要になることがあります。 メモリが限られている SKU を使用している場合は、さらに多くの JVM メモリが必要になることがあります。 ほとんどの場合、クエリとクライアント設定を確認し、CQL クエリ内の fetch_size で選択されている内容と共に limit を減らす必要があります。
実際により多くのメモリが必要な場合は、次のことができます。
- JVM メモリ設定を増やすためのチケットを提出する
- より多くのメモリが利用可能な SKU に垂直方向にスケーリングする
廃棄標識
私たちは毎週、TTLの有効期限が切れた行を削除する「リーパー」というツールを使用して、トゥームストーンと呼ばれる修復を実行しています。 一部のワークロードでは、削除頻度が高くなり、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>
このメッセージは、データ モデルの問題を示します。 詳細については、この スタック オーバーフローに関する記事を参照してください。 この問題は、重大なパフォーマンスの問題を引き起こす可能性があり、対処する必要があります。
特殊な最適化
圧縮
Cassandra では、テーブルの作成時に適切な圧縮アルゴリズムを選択できます。 既定値は LZ4 で、スループットと CPU には優れていますが、ディスク上の領域が増えます。 Zstd (Cassandra 4.0 以上) を使用すると、CPU オーバーヘッドを最小限に抑えながら約 12% の領域を節約できます。
memtable ヒープ領域の最適化
既定では、cassandra.yaml 内の memtable_heap_space に JVM ヒープの 1/4 を使用します。 書き込み指向のアプリケーションや、メモリが小さい SKU の場合、この問題により、頻繁にフラッシュされ、 sstablesが断片化され、圧縮が必要になることがあります。 このような場合は、少なくとも 4048 に増やすと良い場合があります。 この方法では、読み取りなどの他の操作が影響を受けないように、慎重なベンチマークが必要です。