クラスターのスケーリングを計画する
スケーリングは、データ量、コレクション数、トラフィック、または可用性要件が増加するにつれて、Dedicated サービングクラスターを健全な状態に保つのに役立ちます。Zilliz Cloud では、通常、次の 2 つの理由でスケールします。
-
容量の逼迫: クラスターがデータ、コレクション、パーティション、またはインデックスを保持してサービスを提供するために、より多くのリソースを必要としています。
-
クエリコンピュートの逼迫: クラスターはデータを保持できますが、クエリの同時実行数、QPS、またはレイテンシの要件を満たすには、より高い並列サービス提供能力が必要です。
Dedicated サービングクラスターでは、Query CU またはレプリカを手動でスケールするか、オートスケーリングまたはスケジュールスケーリングを構成できます。
オンデマンドクラスターは自動的にスケールするため、手動でのスケーリングは必要ありません。
Query CU の手動スケーリングは、すべてのプランでサポートされています。
レプリカの手動スケーリングは、Enterprise プラン以上でサポートされています。
オートスケーリングとスケジュールスケーリングは、Enterprise プラン以上でサポートされています。
何をスケールするかを理解する
クラスターに影響している逼迫の種類に基づいて、スケーリング対象を選択します。
-
クラスターが、ロード済みのデータ、コレクション、パーティション、またはインデックスを保持してサービスを提供するためにより多くの容量を必要とする場合は、Query CU をスケールします。
-
クラスターがすでにデータを保持できているものの、クエリトラフィックがより高い並列サービス提供能力を必要とする場合は、レプリカをスケールします。
ほとんどの場合:
-
Query CU は容量の逼迫に対処します。
-
レプリカはスループットと可用性の逼迫に対処します。
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 は、並列クエリ処理能力を高めるためにレプリカをスケールアウトすることがあります。 |
スケーリング方法を選択する
ワークロードの予測可能性と運用上の意図に基づいて、スケーリング方法を選択します。
| スケーリング方法 | 最適な用途 | 例 |
|---|---|---|
| 手動スケーリング | 起動、負荷テスト、移行、大規模なデータインポートなど、タイミングとターゲットサイズが既知の一回限りの変更 | 新しい RAG アプリケーションを公開する前に、最初のユーザーの波に備えて容量とクエリのスループットを確保するために、Query CU とレプリカを増やします。 |
| スケジュールスケーリング | 予測可能なトラフィックパターン、定期的な営業時間のピーク、または定時実行されるバッチ検索・評価ジョブ | 社内の AI エージェントやナレッジベースアプリケーションは、平日の営業時間帯にトラフィックが集中するため、クラスターは朝にスケールアップし、夕方にスケールダウンします。 |
| オートスケーリング | 予測できないワークロード、AI エージェント、インタラクティブアプリケーション、カスタマーサポートボット、マルチモーダル検索 | AI エージェントは何時間もアイドル状態になることがあり、その後、複雑なプロンプトを処理したり長期記憶を取得したりする際に、多数の検索をトリガーする場合があります。オートスケーリングはスパイク時にリソースを追加し、その後スケールダウンします。 |
スケーリングの動作を理解する
スケーリングリクエストが送信またはトリガーされると、Zilliz Cloud は要求された構成を検証し、スケーリングジョブを作成します。
スケーリングジョブの実行中:
-
クラスターのステータスが Modifying に変わります。
-
一時停止、移行、削除など、一部の管理操作は一時的に利用できなくなります。
-
新しい構成の準備が整うまで、現在の構成が引き続きサービスを提供します。
-
Zilliz Cloud は、スケーリングに canary upgrade の仕組みを使用し、限定的な範囲で新しい構成を検証してから段階的にロールアウトします。その結果、スケーリング中に既存の接続が切断されることはありません。
-
新しい構成は、スケーリングジョブが正常に完了した後にのみ有効になります。
-
スケーリングジョブが完了しない場合、クラスターは引き続き以前の構成を使用します。
スケーリング操作により、一時的なサービスジッターが発生する可能性があります。
進行状況は Jobs ページで確認できます。ジョブが完了すると、クラスターのステータスは Running に戻ります。
スケーリング中の課金を理解する
スケーリングジョブの実行中、Zilliz Cloud はスケーリング前の構成に基づいてクラスターへの課金を継続します。
新しい Query CU またはレプリカの構成が課金に使用されるのは、スケーリングジョブが正常に完了した後だけです。このルールは、スケールアップとスケールダウンの両方の操作に適用されます。
スケーリングジョブがまだ進行中の場合、または完了しない場合、課金は引き続き以前の構成に基づきます。
つまり、スケーリングジョブが正常に完了するまで、ターゲット構成に対して課金されることはありません。
制限事項と要件を確認する
スケーリングを構成する前に、以下の制限事項を確認してください。
-
レプリカのスケーリングには、最小で 4 CU の Query CU 構成が必要です。
-
Query CU × レプリカには上限があります。詳細については、Zilliz Cloud の制限事項 を参照してください。
-
スケールダウンは、現在のデータ量、および現在のコレクション数とパーティション数がターゲット仕様に収まる場合にのみ成功します。
-
スケジュールスケーリングでは、30 分より長いスケジュール間隔が必要です。
スケーリング結果を検証する
スケーリング後に、変更が想定どおりに機能したことを確認するため、以下のシグナルを確認します。
| シグナル | 検証内容 |
|---|---|
| Query CU Capacity | 容量の逼迫が緩和されました。 |
| Query CU Computation | クエリコンピュートの逼迫が緩和されました。 |
| QPS と読み取りレイテンシ | クエリのパフォーマンスが向上しました。 |
| ジョブのステータス | スケーリングジョブが正常に完了しました。 |
| クラスターのステータス | クラスターが Modifying から Running に戻りました。 |
| 課金または使用量データ | ジョブの完了後、課金が新しい構成に切り替わりました。 |
グローバルクラスターのスケーリングを計画する
グローバルクラスターのスケーリングは、通常の Dedicated クラスターのスケーリングとは異なるルールに従います。
-
Query CU はプライマリクラスターからスケールします。
-
プライマリで Query CU をスケールすると、Zilliz Cloud は同じ Query CU 数をすべてのセカンダリクラスターに自動的に適用します。
-
セカンダリクラスターは、Query CU を個別にスケールすることはできません。
-
レプリカ は、プライマリクラスターまたはセカンダリクラスターごとに個別にスケールします。
-
独立したレプリカ設定を使用して、トラフィックの多いリージョンにはより多くのサービス提供容量を割り当て、トラフィックの少ないリージョンまたはスタンバイリージョンにはより少ないレプリカを割り当てます。
詳細については、グローバルクラスターのスケーリング を参照してください。