メインコンテンツまでスキップ
バージョン: User Guides (Cloud)

クラスターのスケーリング

Zilliz Cloudでは、クエリCUはインデックスを提供し、検索リクエストを処理するために使用されるハードウェアリソースのセットです。クエリCUは、クエリサービスを実行する完全に管理された物理ノードと考えることができます。レプリカは、同じリソースとデータを含むクラスターレベルのコピーです。クエリCUは主にクラスターの容量と計算リソースを決定し、レプリカはクエリを提供する追加の並列処理を提供します。

クエリCUとレプリカ比較​

ワークロードが増加し、より多くのデータが書き込まれるにつれて、クラスターは最終的に容量とパフォーマンスの限界に達する可能性があります。これを積極的に管理するために、メトリクスページでクエリCU容量とクエリCU計算を監視し、限界に達する前にスケーリングすることができます。

クエリCUとレプリカのどちらをスケーリングするかは、目標によって異なります。経験則として：

  • 1〜8個のクエリCUを持つクラスターの場合、クエリCUを直接スケーリングできます。

  • 8個を超えるクエリCUを持つクラスターの場合、必要に応じてクエリCUまたはレプリカをスケーリングできます。

容量を増やすためのクエリCUのスケーリング​

容量関連の制限に達している場合、またはデータとワークロードの継続的な増加が予想される場合は、クエリCUをスケーリングします。

一般的なシグナルとシナリオは次のとおりです。

  • 書き込み操作が失敗するが、読み取りは成功する。これは、クラスターが容量に達しているか、それに近いことを示していることがよくあります。

  • 大規模なデータセットを扱っているか、より多くのコレクションが必要な場合。

  • CPUまたはメモリ使用率が高い場合。

詳細については、クエリCUのスケーリングを参照してください。

スループットまたは可用性を高めるためのレプリカのスケーリング​

クラスターがデータを保持できるが、クエリのスループット（QPS）のボトルネックが見られる場合、またはより良い可用性が必要な場合は、レプリカをスケーリングします。

一般的なシグナルとシナリオは次のとおりです。

  • 中小規模のデータセットだが、QPSのボトルネックが発生している。

  • スループットを向上させるために、複数の同一のコピーにクエリ負荷を分散したい。

  • 可用性を向上させたい。

詳細については、レプリカの管理を参照してください。

スケーリングオプション​

Zilliz Cloudは、クラスターリソースをスケーリングするための複数の方法を提供します。ワークロードパターンに応じて、すぐに、スケジュールに基づいて、または自動的にスケーリングできます。

手動スケーリング​

ワークロードを明確に理解しており、変更が必要な時期を予測できる場合は、リソースを手動で調整します。

  • クエリCU: 容量を拡張するために増加させ、需要が減少したときにコストを削減するために減少させます。

  • レプリカ: クエリのスループットと可用性を高めるために増加させ、需要が減少したときに減少させます。

スケジュールされたスケーリング​

ワークロードに繰り返しパターンがある場合（例：平日のピークと週末の谷）、スケジュールされたスケーリングを使用します。一般的なユースケースには、営業時間中のトラフィックの急増や、予測可能なバッチ/クエリウィンドウが含まれます。

スケジュールされたスケーリングの場合、Zilliz Cloudは2つのモードを提供します。

  • 基本モード: スケジュールを定義するためのシンプルなセレクター。

  • 詳細モード: より柔軟なUnix cron式を使用します。

動的スケーリング​

予測不可能なワークロードに対して動的スケーリングを有効にします。Zilliz Cloudは、リアルタイムのメトリクスに基づいて、ユーザー定義の最小-最大範囲内でリソースを自動的に調整します。

  • クエリCU: CU容量メトリクス値に基づいて自動スケーリングします。

  • レプリカ: CU計算メトリクス値に基づいて自動スケーリングします。

FAQ​

  1. どのスケーリングオプションを選択すべきですか？

    以下は、ニーズに合ったスケーリング方法を選択するのに役立つ簡単なヒントです。

    ZsKhw59w5hZv4RbjorlclAaEn4e

    • ワークロードパターンを非常に明確に理解している場合（一貫した毎日のピークや計画されたバッチインポートジョブなど）は、手動スケーリングとスケジュールされたスケーリングが適切なオプションです。クエリCUをすぐに調整する必要がある場合は、手動スケーリングを選択します。特定の将来の時刻に繰り返し調整を行いたい場合は、スケジュールされたスケーリングを選択します。

    • ワークロードが予測不可能で、日中または週を通して変動する場合は、動的スケーリングが推奨されます。定義した範囲内でクラスターサイズを自動的に調整し、コストを最適化しながらパフォーマンスを維持するのに役立ちます。

  2. レプリカをスケーリングすべき時期とクエリCUをスケーリングすべき時期はいつですか？

    次のことをお勧めします。

    • レプリカ数を増やす場合：

      • 高いQPS（1秒あたりのクエリ数）と高い可用性を処理する必要がある場合。

      • ワークロードが多数の同時検索またはクエリリクエストで構成されている場合。スループットを向上させる必要があります。

      ヒント：各レプリカは、クエリCUリソースの独立したコピーであり、クエリのサブセットを処理します。

    • クエリCUを増やす場合：

      • 大規模なデータセットを扱っているか、より多くのコレクションが必要な場合。

      • CPUまたはメモリ使用率が高い場合。

      ヒント：CUサイズを大きくすると、各クエリノードにより多くの計算リソースと容量が与えられます。

    • 提案: 1〜8個のCUを持つクラスターの場合、クエリCUを直接スケーリングできます。8個を超えるCUを持つクラスターの場合、レプリカを増やしてください。

  3. Zilliz Cloudでのスケーリングはどのように機能しますか？

    次の図は、Zilliz Cloudでのスケーリング操作のワークフローを示しています。

    ORwIwl2z2h0XxLbFNLBcdFOlneh

    • スケーリングの開始: WebコンソールまたはRESTful APIを介してスケーリングリクエストを送信できます。

    • リソースチェック: Zilliz Cloudは、次の要件に対してスケーリングリクエストを検証します。

      • エンタープライズプロジェクト：クエリCU × レプリカ ≤ 256

      • 標準プロジェクト：クエリCU × レプリカ ≤ 32

      • レプリカ > 1の場合、クラスターは8個未満のクエリCUにスケールダウンできません。

      • 現在のデータ量 < 新しいCUサイズのCU容量の80%。

      • 現在のコレクションとパーティションの数 < 新しいCUサイズで許可されるコレクションとパーティションの最大数。

      • スケーリングで問題が発生した場合は、サポートに連絡してください。

    • スケーリングジョブの生成: リソースチェックが合格すると、Zilliz Cloudはスケーリングジョブを作成します。ジョブページで進行状況を追跡できます。この間、クラスターのステータスは変更中に変わり、一時停止、移行、削除などのクラスター操作は利用できません。

    • ジョブが完了しました: ジョブが完了すると、スケーリングは成功し、クラスターのステータスは実行中に戻ります。リソース調整を確認するメールも届きます。