クエリCUのスケーリング
Contact Sales to Enable BYOC

ワークロードの増加とデータの書き込みが進むにつれ、サービングクラスターは容量の限界に達する可能性があります。このような場合、読み取り操作は引き続き機能しますが、新しい書き込み操作は失敗する可能性があります。

これを事前に管理するため、メトリクスページで クエリ CU容量 を監視し、クエリCUのスケーリングが必要なタイミングを判断できます。ビジネスニーズとパターンに基づいて、クエリCUの数を増やしてクラスター容量を拡張したり、需要が減少した際にコスト削減のため減らしたりすることができます。

1 - 12 CUのサービングクラスターでは、クエリCUを直接スケーリングできます。12 CUを超えるサービングクラスターについては、レプリカを増やしてください。

このガイドでは、変化するワークロードに合わせてサービングクラスターのサイズを変更する方法について説明します。

考慮事項

リソースの制限:
- スケールアップ
  - Dedicated (Standard) クラスター: 最大32 CU
    
    Dedicated (Enterprise) クラスター: 最大1,024 CU
  - クエリCU数 × レプリカ数 の積は10,240を超えてはいけません
  より大きなクエリCUについては、営業にお問い合わせください。
- スケールダウン
  - レプリカを持つクラスターは12 CU未満にスケールダウンできません
  - スケールダウンのリクエストは、以下の条件を満たす場合のみ成功します:
    - 現在のデータ量 < 新しいCUサイズのCU容量の80%
    - 現在のコレクション数とパーティション数 < 新しいCUサイズで許可されるコレクションとパーティションの最大数
スケーリング中: クラスターのステータスが「変更中」に変わり、この間は操作を実行できません。複数のスケーリングタスクがトリガーされた場合、トリガー時刻に基づいて順次処理されます。完了時間はデータ量に依存します。
パフォーマンスへの影影響: スケーリングにより、わずかなサービスの揺らぎが発生する可能性があります。
バックアップの制限: 動的およびスケジュールされたスケーリング設定は、バックアップに含まれません。クラスターを復元した後、これらの設定を手動で再構成してください。

手動スケーリング

Zilliz Cloud コンソールまたは RESTful API を使用して、クラスターを手動でスケールアップまたはスケールダウンできます。

以下のデモでは、Zilliz Cloud Web コンソールでクラスターを手動でスケールアップおよびスケールダウンする方法を示しています。

📘Notes

Scale Query Node CU ダイアログボックスで Save をクリックすると、プロジェクトのリソースクォータを確認するよう求められます。リソースが十分であれば、確認完了後にダイアログボックスが消えます。そうでない場合は、

Go To Project リソース設定 をクリックしてプロジェクトのリソース設定を編集するか、
前のステップに戻る をクリックしてクラスター設定を変更してください。

このプロセス中、ローリングのために追加のリソースが必要になります。これらのリソースは使用後に解放されます。

さらに、RESTful API を使用してクエリCUを手動でスケーリングすることもできます。

以下の例では、既存のクラスターを2 CUにスケーリングします。詳細については、クラスターの変更を参照してください。

export TOKEN="YOUR_API_KEY"
export CLUSTER_ID="inxx-xxxxxxxxxxxxxxx"

curl --request POST \
--url "${BASE_URL}/v2/clusters/${CLUSTER_ID}/modify" \
--header "Authorization: Bearer ${TOKEN}" \
--header "Accept: application/json" \
--header "Content-Type: application/json" \
-d '{
    "cuSize": 2
}'

考慮事項​

手動スケーリング​

考慮事項

手動スケーリング