メインコンテンツまでスキップ
バージョン: 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 計算メトリック値に基づいて自動スケールします。

よくある質問​

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

    ニーズに適した正しいスケーリング方法を選択するための簡単なヒントを以下に示します：

    ZsKhw59w5hZv4RbjorlclAaEn4e

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

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

  2. いつレプリカをスケールすべきで、いつクエリ CU をスケールすべきですか？

    以下の対応を推奨します：

    • レプリカ数を増加させる場合：

      • 高い QPS（秒間クエリ数）と高い可用性を扱う必要がある場合。

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

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

    • クエリ CUを増加させる場合：

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

      • CPU またはメモリ使用率が高い状態が見られる場合。

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

    • 提案: クエリ CU が 1〜8 の提供クラスターの場合、クエリ CU を直接スケールできます。クエリ CU が 8 を超える提供クラスターの場合は、レプリカを増加させてください。

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

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

    ORwIwl2z2h0XxLbFNLBcdFOlneh

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

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

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

      • スタンダードプロジェクト：クエリ CU ≤ 32

      • レプリカ > 1 の場合、提供クラスターを 12 クエリ CU 未満にスケールダウンすることはできません。

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

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

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

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

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