クラスタースケーリングを計画する

スケーリングは、データ量、コレクション数、トラフィック、または可用性要件の増加に応じて、Dedicated サービングクラスターを健全な状態に保つのに役立ちます。Zilliz Cloud では、通常 2つの理由でスケーリングを行います。

• 容量の逼迫：クラスターがデータ、コレクション、パーティション、またはインデックスを保持して提供するために、より多くのリソースを必要としています。

• クエリ計算リソースの逼迫：クラスターはデータを保持できますが、クエリの同時実行数、QPS、またはレイテンシの面で、より高い並列サービング能力が必要です。

Dedicated サービングクラスターでは、Query CU またはレプリカを手動でスケーリングするか、自動スケーリングまたはスケジュールスケーリングを構成できます。

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

Note

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

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

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

何をスケーリングするかを理解する

クラスターに影響している逼迫の種類に基づいて、スケーリング対象を選択してください。

• クラスターがロード済みデータ、コレクション、パーティション、またはインデックスを保持して提供するためにより多くの容量を必要とする場合は、Query CU をスケーリングします。

• クラスターがすでにデータを保持できていても、クエリトラフィックにより高い並列サービング容量が必要な場合は、レプリカをスケーリングします。

ほとんどの場合：

• Query CU は容量の逼迫に対応します。

• レプリカはスループットと可用性の逼迫に対応します。

Note

Query CU が限られている小規模なクラスターでは、Query CU を増やすことで QPS も改善する場合があります。ただし、ほとんどの場合、検索スループットと可用性を改善するには レプリカ をスケーリングしてください。

スケーリングのシグナルを特定する

スケーリングが必要かどうか、またどのリソースを調整すべきかを判断するには、次の症状を使用します。

症状	考えられる原因	推奨される対応
書き込み操作が失敗し始めますが、クエリは引き続き動作します。	クラスターが容量の上限に近づいています。	Query CU を増やします。
データ量が増え続けています。	容量要件が増加しています。	Query CU を増やします。
コレクションまたはパーティションの数が、現在の仕様の上限に近づいています。	現在のクラスターサイズでは十分な容量が提供されていません。	Query CU を増やします。
QPS が増加し、クエリレイテンシが高くなります。	クエリ同時実行の逼迫が増加しています。	レプリカを増やします。
ピーク時間帯にはクエリが遅くなりますが、オフピーク時間帯には正常です。	予測可能なピーク時にリソースが不足しています。	スケジュールスケーリングまたは自動スケーリングを有効にします。
トラフィックが予測できません。	ワークロードが大きく変動します。	自動スケーリングを有効にします。
オフピーク時間帯にはリソースがアイドル状態です。	クラスターが過剰にプロビジョニングされています。	スケジュールスケーリングまたは自動スケーリングを有効にします。

メトリクスを使ってスケーリングを判断する

Zilliz Cloud は、Query CU とレプリカのどちらをスケーリングすべきかを判断するための 2つのメトリクスを提供しています。

メトリクス	説明	スケーリングの指針
Query CU Capacity	現在の Query CU が容量の上限にどの程度近づいているかを測定します。ロード済みデータで使用されるメモリと、クラスターのストレージクォータに対する保存データサイズという 2つのシグナルのうち、高い方の値を使用します。	高い値が持続している場合は、現在の Query CU サイズに十分な容量がない可能性があります。自動スケーリングが有効になっている場合、Zilliz Cloud は容量を増やすために Query CU をスケールアップすることがあります。
Query CU Computation	クエリの実行が CPU リソースをどの程度使用しているかを測定します。QueryNode の CPU 使用率と CPU 上限との比率から計算されます。	高い値が持続している場合は、クエリの実行が CPU に依存していることを意味します。Zilliz Cloud は、並列クエリ処理能力を高めるためにレプリカをスケールアウトすることがあります。

スケーリング方法を選択する

ワークロードの予測可能性と運用上の意図に基づいて、スケーリング方法を選択してください。

スケーリング方法	最適な用途	例
手動スケーリング	起動、負荷テスト、移行、大規模なデータインポートなど、タイミングと目標サイズが分かっている 1 回限りの変更。	新しい RAG アプリケーションを起動する前に、最初のユーザー群に備えて容量とクエリスループットを確保するため、Query CU とレプリカを増やします。
スケジュールスケーリング	予測可能なトラフィックパターン、営業時間中に繰り返されるピーク、または固定時刻のバッチ検索や評価ジョブ。	社内の AI エージェントまたはナレッジベースアプリケーションは、平日の業務時間中にトラフィックの大半を受けるため、クラスターは朝にスケールアップし、夕方にスケールダウンします。
自動スケーリング	予測不可能なワークロード、AI エージェント、インタラクティブアプリケーション、カスタマーサポートボット、マルチモーダル検索。	AI エージェントは何時間もアイドル状態のままとなる場合がありますが、その後、複雑なプロンプトを処理したり長期記憶を取得したりする際に、多数の検索をトリガーすることがあります。自動スケーリングはスパイク時にリソースを追加し、その後スケールダウンします。

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

スケーリングリクエストが送信またはトリガーされると、Zilliz Cloud は要求された構成を検証し、スケーリングジョブを作成します。

スケーリングジョブの実行中：

• クラスターのステータスは Modifying に変わります。

• suspend、migrate、drop など、一部の管理操作が一時的に利用できなくなります。

• 新しい構成の準備が整うまで、現在の構成でサービングが継続されます。

• Zilliz Cloud はスケーリングに canary upgrade の仕組みを使用し、限定的な範囲で新しい構成を検証してから段階的にロールアウトします。その結果、スケーリング中に既存の接続が切断されることはありません。

• 新しい構成は、スケーリングジョブが正常に完了した後にのみ有効になります。

• スケーリングジョブが完了しない場合、クラスターは引き続き以前の構成を使用します。

スケーリング操作により、一時的なサービスのジッターが発生する場合があります。

進行状況は Jobs ページで追跡できます。ジョブが完了すると、クラスターのステータスは Running に戻ります。

制限事項と要件を確認する

スケーリングを構成する前に、次の制限事項を確認してください。

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

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

• スケールダウンは、現在のデータ量と、現在のコレクション数およびパーティション数が、ターゲット仕様の範囲内に収まる場合にのみ成功します。

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

スケーリング結果を検証する

スケーリング後は、次のシグナルを確認して、変更が期待どおりに機能したことを確かめます。

シグナル	検証内容
Query CU Capacity	容量の逼迫が低下しています。
Query CU Computation	クエリ計算リソースの逼迫が低下しています。
QPS と読み取りレイテンシ	クエリのパフォーマンスが向上しています。
ジョブステータス	スケーリングジョブが正常に完了しています。
クラスターステータス	クラスターが Modifying から Running に戻っています。
請求または使用量データ	ジョブの完了後、請求が新しい構成に切り替わっています。