オートスケーリング
オートスケーリングは、設定した最小値と最大値の範囲内で Dedicated サービングクラスターを自動的に調整します。ワークロードの急増時にクエリ性能を保護し、トラフィックが減少したときにはリソース使用量を削減するのに役立ちます。
オートスケーリングは、AI エージェント、対話型検索アプリケーション、カスタマーサポートボット、マルチモーダル検索システムなど、トラフィックが予測しにくいワークロードに最も適しています。これらのワークロードは長時間アイドル状態が続いた後、検索リクエストが突発的に急増することがあります。
サービング利用率を健全な範囲に保つため、Zilliz Cloud は生のメトリクスの急上昇のたびに反応するのではなく、ターゲットトラッキングを使用します。システムは平滑化された監視シグナルを評価し、スケーリングジョブを作成する前に安全性チェックを適用します。
Query CU の手動スケーリングは、すべてのプランでサポートされています。
レプリカの手動スケーリングは、Enterprise プラン以上でサポートされています。
オートスケーリングとスケジュールスケーリングは、Enterprise プラン以上でサポートされています。
オートスケーリングの動作を理解する
Zilliz Cloud は、単一の瞬間的なメトリクスの急上昇ではオートスケーリングをトリガーしません。システムは、スケーリングメトリクスが必要な時間だけしきい値を上回るか下回る状態を維持するかどうかを評価し、リソースが頻繁に変更されるのを避けるため、スケーリングイベント間にクールダウンを適用します。
| スケーリング対象 | メトリクス | ターゲット値 | スケールアウト条件 | スケールイン条件 |
|---|---|---|---|---|
| Query CU | Query CU Capacity(スケールイン時は CU Computation も確認) | Query CU Capacity: 70% | 10 分間 80% を超える、または即座に 100% に達する | 30 分間 60% 未満であり、かつターゲットの Query CU が現在の CU Computation を安全に処理できる |
| レプリカ | Query CU Computation | CU Computation: 50% | 2 分間 60% を超える | 10 分間 40% 未満 |
この表の値はデフォルトのオートスケーリング設定であり、必要に応じて Zilliz Cloud によって調整される場合があります。ご不明な点がある場合は、お問い合わせください。
オートスケーリングには、評価ウィンドウ内に十分な有効な監視データが必要です。ウィンドウにデータがない場合、データが不十分な場合、または最近の構成変更後にリセットされた場合、Zilliz Cloud はスケーリングの判断をスキップし、監視を継続します。
したがって、メトリクスがしきい値を超えたからといって、必ずしも直ちにスケーリングがトリガーされるわけではありません。メトリクスが必要な時間だけしきい値を上回るか下回る状態を維持し、クールダウン期間が終了し、かつ評価ウィンドウに十分な有効な監視データが含まれている必要があります。
ターゲットサイズを計算する
オートスケーリングがトリガーされると、Zilliz Cloud はターゲット構成を自動的に計算します。
-
Query CU のスケールアウトでは、Zilliz Cloud は不必要に大きな構成へ一気に移行するのを避けるため、段階的にスケールする傾向があります。
-
Query CU のスケールインでは、Zilliz Cloud はスケールダウン前に、より保守的なチェックを適用します。システムは、ターゲット仕様が現在のデータとロード済みのコンテンツを引き続き保持できること、およびターゲット構成によって CU Computation が高くなりすぎないことを確認します。スケールダウンによって過剰な計算負荷が生じる場合は、スケールインアクションがスキップされ、クラスターは監視を継続します。
-
レプリカのスケールインでは、Zilliz Cloud はスケーリングアクションごとに 1 つのレプリカだけを削除するのではなく、計算されたターゲットレプリカ数まで直接スケールできます。これにより、一時的なトラフィック急増後にクラスターが期待されるサイズへより速く復帰できるようになります。
-
計算されたターゲットが利用可能な仕様でない場合、または実際の構成変更にならない場合、スケーリングアクションはスキップされます。
ターゲットサイズは、スケーリングジョブが作成される前に、仕様マッピングと安全性チェックを通過する必要があります。
スケーリングの振動を回避する
オートスケーリングは、応答性と安定性のバランスを取ります。スケールアウトは性能を保護するためにより敏感に動作し、スケールインは早すぎるスケールダウンの後に再びスケールアウトすることを避けるため、より保守的に動作します。
| メカニズム | 目的 |
|---|---|
| 継続時間ウィンドウ | メトリクスが一定期間、しきい値を上回るか下回る状態を維持することを要求します。 |
| スケールアウトとスケールインのしきい値の分離 | クラスターが単一のしきい値を中心に繰り返しスケーリングするのを防ぎます。 |
| スケーリングイベント間のクールダウン | 短期的なトラフィック変動による連続したスケーリングアクションを防ぎます。 |
| ターゲットサイズの計算 | メトリクスの負荷を実用的なターゲット構成にマッピングします。 |
| 安全性チェック | ターゲット構成が利用可能であり、現在のワークロードを安全に処理できることを保証します。 |
短時間の急増ではスケールアウトはトリガーされません。短時間の低トラフィック期間ではスケールインはトリガーされません。この設計により振動が減り、通常のトラフィック変動時もクラスターが安定した状態に保たれます。
Query CU とレプリカの競合を処理する
Zilliz Cloud は、同一のスケーリングアクションで Query CU とレプリカの両方の構成を変更しません。これにより、複数のリソース次元を一度に変更するリスクを低減します。
-
単一の変更リクエストで Query CU とレプリカを同時に変更することはできません。
-
両方の次元がスケーリング条件を満たす場合、Zilliz Cloud は優先順位に基づく処理を適用します。
-
クエリの並列性の負荷が高い場合、Zilliz Cloud は通常、レプリカのスケーリングを優先します。
-
レプリカのスケールインが Query CU の調整と競合する場合、Zilliz Cloud は Query CU の調整を優先します。
-
ターゲット構成が利用できない場合、または変更がない場合、Zilliz Cloud はアクションをスキップします。
-
スケーリング範囲を設定する
オートスケーリングには、Query CU またはレプリカの最小値と最大値の範囲が必要です。これらの範囲は、Zilliz Cloud がクラスター容量とクエリのスループットをスケールできる境界を定義します。
| 設定 | 目的 | 推奨ガイダンス |
|---|---|---|
| 最小 Query CU | 低トラフィック期間中も利用可能なベースライン容量を定義します。 | 管理タスク、バックグラウンドジョブ、ロード済みデータ、および予想される最小限のサービングワークロードを処理できる値を使用してください。 デフォルトでは、この値は現在の Query CU 値です。 |
| 最大 Query CU | 自動的な Query CU スケールアップのコストと容量の上限を定義します。 | 予想されるデータ増加に対応できる十分な余裕を確保しつつ、暴走するワークロード、再帰的なクエリのバグ、予期しないトラフィック急増から保護できる値を使用してください。 デフォルトでは、この値は現在の Query CU 値の 4 倍です。 |
| 最小レプリカ | 低トラフィック期間中におけるベースラインのクエリサービング冗長性とスループットを定義します。 | アプリケーションに必要な最小限の可用性と QPS を維持できる値を使用してください。 本番ワークロードでは、可用性の目標に必要な最小レプリカ数を下回る値に設定しないでください。 |
| 最大レプリカ | 自動的なレプリカスケールアウトのコストとスループットの上限を定義します。 | 予想されるトラフィックのピークを吸収しつつ、予期しないクエリ急増による無制御なコスト増加を防ぐことができる値を使用してください。 |
最大値は、運用上または予算上の上限より高く設定しないでください。持続的なワークロードの負荷に応じて、オートスケーリングは設定された最大値までスケールアップする場合があります。
オートスケーリングを構成する
オートスケーリングを有効にすると、Zilliz Cloud は関連するメトリクスを継続的に評価し、設定された条件が満たされたときにスケーリングジョブを作成します。
Web コンソールから
-
Query CU のオートスケーリングを構成する
1クラスター Details ページに移動します。
2CU Settings カードの Scale をクリックします。
3スケーリング方法として Auto-scaling を選択し、minimum and maximum Query CU Sizes を設定します。
4Save をクリックします。
-
レプリカのオートスケーリングを構成する
1クラスター Details ページに移動します。
2Replica Settings カードの Scale をクリックします。
3スケーリング方法として Auto-scaling を選択し、レプリカの最小数と最大数を設定します。
4Save をクリックします。
RESTful API から
RESTful API を使用すると、単一の Modify クラスター リクエストで Query 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 '{
"autoscaling": {
"cu": {
"min": 1,
"max": 2
},
"replica": {
"min": 1,
"max": 2
}
}
}'
スケーリングの進行状況を確認する
スケーリングイベントがトリガーされると、Zilliz Cloud はジョブレコードを生成します。進行状況は Jobs ページで確認できます。
Zilliz Cloud コンソールで、対象のプロジェクトに移動します。
Jobs に移動します。
対象のクラスターのスケーリングジョブを探します。
ジョブのステータスを確認します。
スケーリングジョブの実行中は、クラスターのステータスが Modifying になります。ジョブが成功すると、クラスターのステータスは Running に戻ります。
スケーリングジョブの実行中、Zilliz Cloud は以前の構成に基づいてクラスターへの課金を継続します。新しい Query CU またはレプリカの構成が課金に使用されるのは、スケーリングジョブが正常に完了した後のみです。これはスケールアップとスケールダウンの両方の操作に適用されます。
オートスケーリングのトラブルシューティング
| 現象 | 考えられる原因 | 対処 |
|---|---|---|
| メトリクスがしきい値を超えたが、スケーリングが開始されなかった。 | メトリクスが必要な時間だけしきい値を上回る状態を維持しなかった、クールダウンが有効である、または評価ウィンドウのデータが不十分である。 | 評価ウィンドウ全体にわたるメトリクスの推移を確認し、最近の構成変更を見直してください。 |
| トラフィックが減少したにもかかわらず、クラスターがスケールダウンしなかった。 | スケールインはより長く保守的なウィンドウを使用する、またはターゲット構成が現在のデータとロード済みのコンテンツを安全に保持できない。 | Query CU Capacity、データ量、ロード済みのコレクション、およびコレクションまたはパーティションの制限を確認してください。 |
| 高トラフィック時にレプリカがスケールアウトしなかった。 | Query CU Computation のしきい値が継続的に満たされなかった、または別のスケーリングアクションの優先度が高い可能性がある。 | 時間の経過に伴う Query CU Computation を確認し、スケーリングジョブの履歴を見直してください。 |
| オートスケーリングがアクションをスキップした。 | ターゲット仕様が利用できなかった、変更がなかった、または安全性チェックに失敗した。 | min/max の範囲を調整するか、有効なクラスター構成を選択してください。 |
制限事項と考慮事項
-
オートスケーリングは Dedicated サービングクラスターに適用されます。
-
オンデマンドクラスターは自動的にスケールするため、オートスケーリングを構成する必要はありません。
-
レプリカのスケーリングには、最小 4 CU の Query CU 構成が必要です。
-
Query CU × レプリカには上限があります。詳細については、Zilliz Cloud の制限事項 を参照してください。
-
スケールダウンが成功するのは、現在のデータ量と、現在のコレクション数およびパーティション数がターゲット仕様に収まる場合だけです。
-
スケジュールスケーリングには、30 分より長いスケジュール間隔が必要です。