メインコンテンツまでスキップ

自動スケーリング

自動スケーリングは、設定した最小値と最大値の範囲内で Dedicated サービングクラスターを自動的に調整します。ワークロードの急増時にクエリ性能を保護し、トラフィックが減少したときのリソース使用量の削減に役立ちます。

自動スケーリングは、AI エージェント、インタラクティブ検索アプリケーション、カスタマーサポートボット、マルチモーダル検索システムなど、トラフィックが予測しにくいワークロードに最も有効です。これらのワークロードは長時間アイドル状態になることがあり、その後、検索リクエストが急増することがあります。

サービング使用率を健全な範囲に保つため、Zilliz Cloud は生のメトリクススパイクのたびに反応するのではなく、ターゲットトラッキングを使用します。システムは平滑化された監視シグナルを評価し、スケーリングジョブを作成する前に安全チェックを適用します。

Note

Query CU の手動スケーリングは、すべてのプランでサポートされています。

レプリカの手動スケーリングは、Enterprise プラン以上でサポートされています。

自動スケーリングとスケジュールスケーリングは、Enterprise プラン以上でサポートされています。

自動スケーリングの動作を理解する​

Zilliz Cloud は、単一の瞬間的なメトリクススパイクによって自動スケーリングをトリガーすることはありません。システムは、スケーリングメトリクスが必要な時間にわたってしきい値を上回っているか下回っているかを評価し、頻繁なリソース変更を避けるためにスケーリングイベント間にクールダウンを適用します。

スケーリング対象メトリクス目標値スケールアウト条件スケールイン条件
Query CUQuery CU Capacity（スケールイン時は CU Computation も確認）Query CU Capacity: 70%10 分間 80% を超える、または直ちに 100% に達する30 分間 60% 未満であり、かつ対象の Query CU が現在の CU Computation を安全に処理できる
レプリカQuery CU ComputationCU Computation: 50%2 分間 60% を超える10 分間 40% 未満
Note

この表の値はデフォルトの自動スケーリング設定であり、必要に応じて 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 とレプリカの両方の構成を変更することはありません。これにより、複数のリソース次元を一度に変更するリスクが軽減されます。

  • 1 回の変更リクエストで 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 を維持する値を使用してください。
本番ワークロードでは、可用性目標に必要な最小レプリカ数を下回る値に設定しないでください。
最大レプリカ自動的なレプリカスケールアウトのコストとスループットの上限を定義します。想定されるトラフィックピークを吸収しつつ、予期しないクエリスパイクによる制御不能なコスト増加を防ぐことができる値を使用してください。
Note

最大値は、運用上または予算上の上限を超えて設定しないでください。持続的なワークロード負荷によって必要とされる場合、自動スケーリングは設定された最大値までスケールアップすることがあります。

自動スケーリングを構成する​

自動スケーリングを有効にすると、Zilliz Cloud は関連するメトリクスを継続的に評価し、設定された条件が満たされたときにスケーリングジョブを作成します。

Web コンソールから​

  • Query CU の自動スケーリングを構成する

    1

    クラスター Details ページに移動します。

    2

    CU Settings カードの Scale をクリックします。

    3

    スケーリング方法として Auto-scaling を選択し、minimum and maximum Query CU Sizes を構成します。

    4

    Save をクリックします。

  • レプリカの自動スケーリングを構成する

    1

    クラスター Details ページに移動します。

    2

    Replica Settings カードの Scale をクリックします。

    3

    スケーリング方法として Auto-scaling を選択し、レプリカの最小数と最大数を構成します。

    4

    Save をクリックします。

RESTful API から​

RESTful API を使用すると、1 回の Modify クラスター リクエストで Query CU とレプリカの両方の自動スケーリングを構成できます。

bash
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 ページで確認できます。

1

Zilliz Cloud コンソールで、対象のプロジェクトに移動します。

2

Jobs に移動します。

3

対象クラスターのスケーリングジョブを見つけます。

4

ジョブのステータスを確認します。

スケーリングジョブの進行中、クラスターのステータスは Modifying です。ジョブが成功すると、クラスターのステータスは Running に戻ります。

Note

スケーリングジョブの実行中、Zilliz Cloud は以前の構成に基づいてクラスターへの課金を継続します。新しい Query CU またはレプリカ構成が課金に使用されるのは、スケーリングジョブが正常に完了した後だけです。これはスケールアップとスケールダウンの両方の操作に適用されます。

自動スケーリングのトラブルシューティング​

確認された事象考えられる原因対応
メトリクスがしきい値を超えたが、スケーリングが開始されませんでした。メトリクスが必要な時間にわたってしきい値を上回らなかった、クールダウンが有効である、または評価ウィンドウのデータが不十分です。評価ウィンドウ全体にわたるメトリクスの推移を確認し、最近の構成変更を確認してください。
トラフィックが減少したのに、クラスターがスケールダウンしませんでした。スケールインではより長く慎重なウィンドウが使用される、または対象の構成が現在のデータとロード済みコンテンツを安全に保持できません。Query CU Capacity、データ量、ロード済みコレクション、およびコレクションまたはパーティションの上限を確認してください。
高トラフィック時にレプリカがスケールアウトしませんでした。Query CU Computation のしきい値が継続しなかった、または別のスケーリング操作の優先度が高い可能性があります。時系列で Query CU Computation を確認し、スケーリングジョブの履歴を確認してください。
自動スケーリングが操作をスキップしました。対象の仕様が利用できなかった、変更がなかった、または安全チェックに失敗しました。min/max の範囲を調整するか、有効なクラスター構成を選択してください。

制限事項と考慮点​

  • 自動スケーリングは Dedicated サービングクラスターに適用されます。

  • オンデマンドクラスターは自動的にスケーリングされるため、自動スケーリングの構成は不要です。

  • レプリカのスケーリングには、最小 4 CU の Query CU 構成が必要です。

  • Query CU × レプリカには上限があります。詳細については、Zilliz Cloud Limits を参照してください。

  • スケールダウンが成功するのは、現在のデータ量と現在のコレクション数およびパーティション数が対象の仕様に収まる場合だけです。

  • スケジュールスケーリングでは、30 分を超えるスケジュール間隔が必要です。

Ctrl I