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

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

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

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

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

クエリ CU またはレプリカのどちらをスケーリングするかは、目的によります。一般的な目安として以下があります：

  • クエリ CU 数が 1～8 のクラスターの場合、直接クエリ CU をスケーリングできます。

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

より多くの容量が必要な場合のクエリ CU スケーリング​

容量関連の制限に達している場合や、データ量およびワークロードの継続的な増加が見込まれる場合は、クエリ CU をスケーリングしてください。

典型的な兆候およびシナリオ：

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

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

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

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

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

クラスターがデータを保持できるが、クエリスループット（QPS）にボトルネックが発生している、または可用性を向上させたい場合は、レプリカをスケーリングしてください。

典型的な兆候およびシナリオ：

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

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

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

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

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

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

手動スケーリング​

ワークロードを明確に把握しており、変更が必要になるタイミングを予測できる場合に、手動でリソースを調整します。

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

  • レプリカ：クエリスループットと可用性を向上させるために増加させ、需要が低下した際に減少させます。

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

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

スケジュールされたスケーリングでは、Zilliz Cloud が以下の 2 つのモードを提供しています：

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

  • 詳細モード：より柔軟性を持たせるために Unix cron 式 を使用

動的スケーリング​

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

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

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

よくある質問 (FAQ)​

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

    以下のヒントを参考に、ニーズに合ったスケーリング方法を選択してください：

    ZsKhw59w5hZv4RbjorlclAaEn4e

    • ワークロードパターン（例：毎日の一定のピークや計画されたバッチインポートジョブ）を明確に把握している場合、手動 スケーリングおよび スケジュールされた スケーリングが適しています。クエリ CU を即座に調整したい場合は手動スケーリングを、特定の将来の時刻に定期的に調整したい場合はスケジュールされたスケーリングを選択してください。

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

  2. レプリカとクエリ CU のどちらをスケーリングすべきですか？

    以下の状況でスケーリングすることを推奨します：

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

      • 高 QPS（1 秒あたりのクエリ数）および高可用性が必要な場合。

      • 多数の同時検索またはクエリリクエストが発生しており、スループットを向上させる必要がある場合。

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

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

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

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

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

    • 提案：CU 数が 1～8 のクラスターの場合、直接クエリ CU をスケーリングできます。CU 数が 8 を超えるクラスターの場合、レプリカを増やすことをお勧めします。

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

    以下の図は、Zilliz Cloud におけるスケーリング操作のワークフローを示しています。

    ORwIwl2z2h0XxLbFNLBcdFOlneh

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

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

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

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

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

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

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

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

    • スケーリングジョブの生成：リソースチェックが通過すると、Zilliz Cloud はスケーリングジョブを作成します。進捗状況は ジョブ ページで追跡できます。この間、クラスターステータスは 変更中 に変わり、サスペンド、移行、削除などのクラスター操作は利用できなくなります。

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