メインコンテンツまでスキップ

コスト最適化

データ規模とクエリ量が増加するにつれて、コスト管理が重要になります。このガイドでは、デプロイ方式の選択、インデックスのチューニング、エラスティックスケーリング、割引、請求分析という 5 つの観点から、Zilliz Cloud のコスト最適化戦略を体系的に説明します。

請求内容を理解する​

最適化に取り組む前に、コストがどこで発生しているかを把握してください。Zilliz Cloud の料金は、次の 5 つの項目で構成されています。

項目説明最適化可能？
コンピューティング（CU）Compute Unit に基づく Dedicated クラスターの時間課金です。選択 + スケーリング
Read/Write OperationsServerless クラスターの従量課金です。クエリ最適化
ストレージデータとバックアップのストレージです（クラスターの状態を問いません）。ビルドレベル + データクリーンアップ
データ転送イングレス、エグレス、リージョン間転送です。アーキテクチャ設計
監査ログ監査ログのリソース消費です。必要に応じて有効化

ほとんどのユーザーにとって、コストの 70% 以上は コンピューティング が占めており、ここが最適化の余地も最も大きい領域です。

料金計算ツール を使用すると、ベクトルの次元数、データ量、QPS 要件に基づいて月額の見積もりを取得できます。実際のビジネス負荷がピーク容量のまま無期限に推移することはまれなため、実際のコストは見積もりを下回ることがよくあります。

適切なデプロイ方式を選択する​

適切なデプロイ方式の選択は、最も影響の大きい判断です。誤った方式を選ぶと、小さな最適化では埋められないほどのコストにつながる可能性があります。

デプロイ方式の概要​

種類料金参考（768 次元）容量/CU検索 QPSレイテンシーユースケース
無料05 GB、≤5 コレクション——学習、プロトタイピング
ServerlessRU 従量課金自動スケーリング自動中不安定なトラフィック、Dev/Test
Dedicated（パフォーマンス最適化）~$65/M ベクトル/mo2M/CU500–1,500低（<10ms p99）レイテンシー重視の本番環境
Dedicated（キャパシティ最適化）~$20/M ベクトル/mo8M/CU100–300中大規模、コスト重視
Dedicated（階層型ストレージ）~$7/M ベクトル/mo40M/CU100–150（ホット）高め大規模データ、cold/hot 分離
BYOCカスタムカスタムカスタムカスタムコンプライアンス、クラウド割引

選択の判断ツリー​

  • データが 100 万ベクトル未満、QPS が 50 未満の場合
    → Serverless を使用します。操作に対してのみ料金が発生し、アイドル時のコストはゼロです。「将来の」トラフィックを見込んで Dedicated リソースをプロビジョニングしないでください。

  • データが 100 万～5,000 万ベクトルで、安定した低レイテンシーが必要な場合
    → キャパシティ最適化 クラスターが最もコスト効率の高いソリューションです。パフォーマンス最適化オプションよりも 3 倍安く、100 ミリ秒未満のレイテンシーを提供するため、ほとんどの RAG およびレコメンデーションシナリオには十分です。パフォーマンス最適化 クラスターは、極端な要件（例：<10 ms p99 のリアルタイム検索）にのみ使用してください。

  • データが 5,000 万ベクトルを超え、アクセス頻度が低い場合
    → 階層型ストレージ クラスターを使用します。キャパシティ最適化オプションよりも 3 倍安く、大規模データのうち一部のみが頻繁にクエリされるシナリオ（例：履歴ログ分析）に最適です。

  • コンプライアンス要件、または既存のクラウド割引 (RI/SP) がある場合
    → BYOC（Bring Your Own Cloud） です。クラスターは VPC 内で実行されるため、エンタープライズレベルのクラウド割引を活用しながら、データ主権の要件を満たすことができます。

推奨：キャパシティ最適化はほとんどのシナリオに最適​

キャパシティ最適化クラスターは、単なる「低速版」と誤解されることがよくあります。実際には、Zilliz Cloud で最もアーキテクチャが洗練された製品です。

従来のベクトルデータベースは、コストと引き換えに速度を得るため、すべてのインデックスと生データをメモリに保持します。一方、キャパシティ最適化クラスターは 階層型ストレージアーキテクチャ を採用しています。

  • 階層型ストレージ： ベクトルインデックスは速度のためにメモリに保持され、スカラーデータと生のベクトルはインテリジェントキャッシュを備えた mmap によってディスクにマッピングされます。これにより、パフォーマンス最適化クラスターと比較して、CU あたり 3 倍のデータ密度を実現できます。

  • DiskANN レベルの最適化： IVF インデックスはディスクに適したアクセス向けに調整され、NVMe SSD によるスループットを最大化しながら 10–50ms のレイテンシーを維持します。これはほとんどの AI アプリケーションにとって無視できる程度です。

  • 高いリソース使用率： パフォーマンス最適化クラスターは多くの場合 30% の余裕を確保しますが、キャパシティ最適化クラスターは 90% 以上のデータ密度に達することができます。

まとめ： パフォーマンス最適化オプションはハードウェアで速度を買い、キャパシティ最適化オプションはテクノロジーで効率を買います。

プロジェクトプラン：Standard、Enterprise、Business Critical の比較​

Zilliz Cloud では、機能とスケーリングの上限に影響する複数のプランを提供しています。

機能StandardEnterpriseBusiness Critical
最大 CU32 CU256 CU512 CU
レプリカ上限Query CU × Repl ≤ 32Query CU × Repl ≤ 256Query CU × Repl ≤ 512
SLA0.9990.99950.9999
マルチ AZシングル AZオプションデフォルトで有効
RBAC基本カスタムロール + 監査フル + SOC2/HIPAA
BYOC非対応対応対応
サポートチケットSA + Slack24/7 + 15 分以内の応答

詳細については、プランの詳細比較 を参照してください。

アドバイス： Standard から開始してください。より高い SLA、マルチ AZ、または大規模なスケールが必要な場合にのみ Enterprise にアップグレードします。アップグレードはシームレスで、データ移行は不要です。

よくある落とし穴​

  1. デフォルトでパフォーマンス最適化クラスターを選ぶ： 多くのユーザーは、PoC で使用したパフォーマンス最適化クラスターを基準に予算を立てます。しかし、キャパシティ最適化は「ダウングレード版」ではなく、コスト効率のために専用に設計されたアーキテクチャです。パフォーマンス最適化クラスターのわずか 1/3 のコストで、ほとんどのシナリオに十分な QPS を提供します。

  2. 階層型ストレージオプションを見落とす： パフォーマンス最適化クラスターの 1/9 のコストで利用できる階層型ストレージクラスターは、hot/cold のアクセスパターンが明確なデータに最適です。データのごく一部にのみ低レイテンシーが必要な場合は、階層型ストレージオプションによってコストを桁単位で削減できます。

  3. 小規模な用途で Dedicated を使用する： 小規模なデータセットや不安定なトラフィックには、Serverless（従量課金）の方が Dedicated よりもはるかにコスト効率が高くなります。「エンタープライズ」らしさだけを目的として、リソースを過剰にプロビジョニングしないでください。

インデックスとストレージの最適化​

モードを選択したら、各 CU の有用性を最大化するようにパラメーターをチューニングします。

インデックスのビルドレベル：容量と再現率の比較​

build_level パラメーター は、インデックスの精度とストレージ密度を制御します。これを下げると、極端な再現率を必要としないシナリオでは、各 CU のストレージ容量を大幅に増やすことができます。

  • パフォーマンス最適化クラスター（768 次元、CU あたり）：

    ビルドレベル容量増加再現率QPS
    容量優先（0）2.1M0.490–95%~2,850
    バランス（1）デフォルト1.5Mベースライン91–97%~3,500
    精度優先（2）1.0M-0.3392–98%~3,000

  • キャパシティ最適化クラスター（768 次元、CU あたり）：

    ビルドレベル容量増加再現率QPS
    容量優先（0）7M0.489–97%~300
    バランス（1）デフォルト5Mベースライン93–98%~350
    精度優先（2）3M-0.494–98%~345

ケーススタディ： 16 CU のキャパシティ最適化クラスターは、デフォルトで 8,000 万ベクトルを保持できます。Capacity-first に切り替えるとこれが 1 億 1,200 万ベクトルに増えるか、同じ 8,000 万ベクトルを 12 CU に収めることができ、CU コストを 25% 削減 できます。

Note

build_level パラメーターは、一度設定すると変更できません。変更するには、インデックスを削除して再作成する必要があります。コレクションを作成する前に要件を評価することをお勧めします。このパラメーターは、浮動小数点ベクトル型（FLOAT_VECTOR、FLOAT16_VECTOR、BFLOAT16_VECTOR）のみをサポートします。

検索レベル：パフォーマンスとコストの比較​

level パラメーター（1–10）は、検索の精度を制御します。

  • レベル 1–3： ほとんどのシナリオに最適です（再現率 90–95%）。

  • レベル 4–7： 高精度のシナリオ向けです。レイテンシーを約 2–3 倍にしても、再現率 95–98% を得られます。

  • レベル 8–10： 重要なシナリオ（例：医療、不正検出）向けの極めて高い精度を実現しますが、レイテンシーとコンピューティングコストが大幅に増加します。

アドバイス： enable_recall_calculation=true を使用して再現率を測定し、ビジネス要件を満たす最小のレベルを見つけてください。レベルを上げるたびに検索で消費される計算リソースが増加します。Serverless クラスターでは、これがそのまま読み取り vCU コストの増加につながり、Dedicated クラスターでは、同じ CU 割り当てでサポートできる QPS が低下することを意味します。

mmap 設定：メモリとディスクのバランス​

メモリマッピング（mmap） は、データをメモリからディスクにオフロードします。

クラスターの種類デフォルトの mmap ポリシー効果
Dedicated（パフォーマンス最適化）生のベクトルデータのみが mmap を使用し、スカラーデータとすべてのインデックスはメモリに保持されます低レイテンシーを保証します
Dedicated（キャパシティ最適化）スカラーインデックスとすべての生データが mmap を使用し、ベクトルインデックスのみがメモリに保持されます容量を最大化します
Free / Serverlessすべてのフィールドとインデックスが mmap を使用しますシステムキャッシュに依存します

最適化の推奨事項：

  • パフォーマンス最適化クラスターでは、スカラーフィルタリングがボトルネックでない場合、スカラーフィールドで mmap を有効にして、ベクトルインデックス用のメモリを解放することを検討してください。

  • キャパシティ最適化クラスターでは、デフォルトのポリシーがすでにストレージ優先であるため、通常は追加のチューニングは必要ありません。

Note

mmap 設定を変更する前にコレクションをリリースし、変更後に再ロードする必要があります。設定を誤ると、パフォーマンスの低下や OOM エラーが発生する可能性があります。まずテスト環境で検証してください。

クエリの最適化​

効率的なクエリは、Serverless ユーザーの Read Unit（RU）コストを削減し、Dedicated CU の QPS を向上させます。

スカラーフィールドにインデックスを作成する​

多くのユーザーは、BITMAP などのインデックスタイプを使用したスカラーインデックス作成を怠っています。スカラーインデックスがない場合、フィルター（例：category == "electronics" や timestamp > 1700000000）は コレクション全体のスキャン を引き起こし、非常に大きなコストがかかります。頻繁にフィルタリングされるスカラーフィールドにはインデックスを作成できます。

python
from pymilvus import MilvusClient
from pymilvus import MilvusClient, DataType

client = MilvusClient(
    uri="YOUR_CLUSTER_ENDPOINT",
    token="YOUR_CLUSTER_TOKEN"
)

index_params = client.prepare_index_params()

index_params.add_index(
    field_name="category",
    index_type="BITMAP",
    index_name="idx_category"
)

index_params.add_index(
    field_name="timestamp",
    index_type="BITMAP",
    index_name="idx_timestamp"
)

client.create_index(
    collection_name="my_collection",
    index_params=index_params
)

最適化の推奨事項：

  • filter 式に含まれるすべてのスカラーフィールドにインデックスを構築します。Zilliz Cloud は、適切なインデックスタイプ（文字列には転置インデックス、数値にはソート済みインデックスなど）を自動的に選択します。

  • スカラーインデックスのメモリオーバーヘッドは最小限ですが、フィルタリングのパフォーマンスを桁違いに向上させ、テーブル全体のスキャンをインデックスルックアップに変えます。

  • 重要： 特にキャパシティ最適化クラスターでのフィルター付きベクトル検索では、スカラーインデックスの有無によって、クエリのレイテンシーがミリ秒単位になるか秒単位になるかが直接決まります。

適切な TopK を選択する​

TopK は、コンピューティングとネットワークのオーバーヘッドに直接影響します。

TopK相対レイテンシー相対 RU コスト（Serverless）一般的なユースケース
1–10ベースライン1xRAG（通常 3–5 個のコンテキストチャンク）
10–501.2–1.5x1.5–2xレコメンデーションシステム、検索結果ページ
50–2001.5–3x2–4x候補セットの生成、再ランキングの入力
200–10003–10x4–10xバッチ分析、クラスタリング

  • RAG： TopK 3–10 を使用します。コンテキストを増やしても LLM の品質が向上することはほとんどなく、トークンと RU を浪費します。

  • レコメンデーション： 再ランキングモデルの上限（通常 20–50）を使用します。

  • 大きな TopK： 1 回のリクエストで大量の結果セットを返す代わりに、ページネーション（offset + limit）またはイテレーターを使用してください。

出力フィールドを絞り込む​

デフォルトでは、検索は以下に示すようにすべてのスカラーフィールドを返します。

python
query_vector = [0.3580376395471989, -0.6023495712049978, 0.18414012509913835, -0.26286205330961354, 0.9029438446296592]

results = client.search(
    collection_name="my_collection",
    data=[query_vector],
    anns_field="embedding",
    search_params={"metric_type": "COSINE"},
    limit=10
)

ただし、すべてのクエリで大きなテキストフィールド（例：ドキュメントの全文）を返すと、レイテンシーと RU コストが増加します。そのため、必要な出力フィールドのみを指定できます。

python
query_vector = [0.3580376395471989, -0.6023495712049978, 0.18414012509913835, -0.26286205330961354, 0.9029438446296592]

results = client.search(
    collection_name="my_collection",
    data=[query_vector],
    anns_field="embedding",
    search_params={"metric_type": "COSINE"},
    limit=10,
    # Do not return large fields such as "content"
    output_fields=["id", "title", "category"]
)

詳細については、出力フィールドの使用 を参照してください。

最適化の推奨事項：

  • 常に output_fields を明示的に指定し、ビジネスロジックで必要なフィールドのみを返します。

  • RAG シナリオで元のテキストが必要な場合は、まずベクトル検索で ID を取得し、次にその ID によって外部ストレージ（例：Redis、データベース）からソースコンテンツを取得することを検討してください。これによりベクトル検索を高速に保ちながら、外部ストレージのキャッシュの利点を活用できます。

  • Serverless モードでは、返されるデータ量が Read vCU の課金に直接影響します。不要なフィールドを減らすことが、コストを削減する最も簡単な方法です。

パーティションキーを活用する​

パーティションキー は、スカラー値に基づいてデータを自動的にパーティションに分散し、検索が無関係なデータをスキップできるようにします。

次の例は、コレクションを作成するときにパーティションキーを指定する方法を示しています。

python
schema = client.create_schema()

schema.add_field(field_name="id",
    datatype=DataType.INT64,
    is_primary=True)

schema.add_field(field_name="embedding",
    datatype=DataType.FLOAT_VECTOR,
    dim=5)

# Add the partition key
schema.add_field(
    field_name="tenant_id",
    datatype=DataType.VARCHAR,
    max_length=128,
    is_partition_key=True,
)

ユースケース：

  • マルチテナント SaaS： tenant_id をパーティションキーとして使用すると、各テナントのクエリがそのテナント自身のデータパーティションのみをスキャンするようになり、QPS とレイテンシーの両方が大幅に改善されます。

  • カテゴリフィルタリング： category をパーティションキーとして使用すると、特定のカテゴリ内で検索するときにデータセット全体をスキャンする必要がなくなります。

パフォーマンスの向上： データが均等に分散された 100 テナントを想定した場合、パーティションキーを使用するとクエリあたりのスキャン量が約 99% 削減されます。分散が不均等な場合でも、通常はスキャン量が 50–90% 削減されます。

エラスティックスケーリング​

Dedicated クラスターの最大のコストの落とし穴は、「ピーク負荷に合わせてプロビジョニングし、24 時間稼働し続けること」です。Zilliz Cloud は、このパターンを打破する 3 つのスケーリング戦略を提供しています。

自動スケーリング​

CU の最小値と最大値を設定すると、システムはリアルタイムの負荷に基づいて自動的にスケーリングします。

  • Query CU は CU Capacity メトリクスに基づいて自動的にスケーリングします（データ量に基づく）

  • レプリカは CU Computation メトリクスに基づいて自動的にスケーリングします（QPS に基づく）

一般的なシナリオ： 日中ピーク時に 32 CU を必要とし、夜間は 8 CU のみで足りる e コマース検索サービスを考えます。自動スケーリング設定で min=8、max=32 を設定すると、システムはオフピーク時間帯に自動的に 8 CU までスケールダウンします。1 日あたり 10 時間のオフピーク時間を想定すると、月間のコンピューティングコストを約 30–40% 削減できます。

詳細については、自動スケーリング を参照してください。

スケジュールスケーリング​

トラフィックパターンが予測可能なワークロードに適しています。Basic モード（シンプルなセレクター）と Advanced モード（Unix cron 式）をサポートします。

一般的な構成：

  • 平日の 9:00 に 32 CU までスケールアップし、22:00 に 8 CU までスケールダウンします

  • 週末は終日 8 CU を維持します

  • 月末のプロモーション期間に備えて事前にスケールします

詳細については、スケジュールスケーリング を参照してください。

手動スケーリング​

最もシンプルな選択肢を見落とさないでください。ワークロードが静かな期間（例：プロジェクト間やオフシーズン）に入ったら、CU 構成を積極的に減らします。多くのユーザーは PoC 後にスケールダウンするのを忘れ、数週間から数か月にわたって不要な容量の料金を支払い続けています。

詳細については、手動スケーリング を参照してください。

スケーリングの制約​

  • Query CU × Replica ≤ 10,240

  • Replica > 1 の場合、クラスターを 12 CU 未満にスケールダウンすることはできません

  • スケールダウンする場合、データ量は新しい CU 容量の 80% 未満である必要があります

  • 12 CU 未満では Query CU のみを調整できます。12 CU を超える場合は、Query CU と Replica を個別に調整できます

推奨： 予測できないトラフィックには動的スケーリングを使用し、規則的なトラフィックパターンにはスケジュールスケーリングを使用します。この 2 つは組み合わせることができます。

クレジットと割引をさらに取得する​

技術的な最適化に加えて、Zilliz のプロモーションプログラムを最大限に活用することも同様に重要です。

クレジット​

チャネルクレジット有効期間備考
新規ユーザー登録$100 クレジット30 日間すぐに利用可能。クレジットカードは不要です
支払い方法の追加—1 年間に延長未使用のクレジットは、支払い方法の追加時に自動的に延長されます
ごみ箱無料—ごみ箱にある削除済みデータには料金が発生しません

推奨： 初回登録後、できるだけ早く支払い方法を追加して、$100 クレジットの有効期間を 30 日間から 1 年間に延長してください。これにより、技術評価に十分な時間を確保できます。

Dedicated プログラム​

プログラム対象者申請方法
Zilliz AI Startup Program初期段階のスタートアップ公式 Web サイト から申請すると、追加のクレジットと技術サポートを受けられます
AI Agent ProgramAI Agent 開発者AI Agent アプリケーションを構築する開発者向けの限定クレジットです。近日提供予定です。

エンタープライズ顧客​

  • カスタム見積もりについては営業担当者に問い合わせてください： エンタープライズ顧客は年間サブスクリプションを通じて割引を受けられます。具体的な料金については 営業担当者に問い合わせてください。

  • クラウドマーケットプレイスのサブスクリプション： AWS、Google Cloud、Azure のマーケットプレイスを通じてサブスクライブすると、Zilliz Cloud の料金をクラウドの請求書にまとめ、既存のエンタープライズ割引を適用できます。

  • 前払い： 前払い を通じてアカウントに資金を入金します。控除の優先順位は、クレジット > 前払い > cloud marketplace subscriptions/credit cards です。予算管理の要件がある組織に適しています。

使用状況ページを監視する​

最適化は一度きりの取り組みではありません。Zilliz Cloud は多次元のコスト分析ツールを提供し、支出を継続的に追跡して最適化できるようにします。

可視化されたコスト分析​

Billing > Usage ページでは、請求内容を次の 5 つの観点で分類できます。

観点目的
プロジェクト異なる事業部門や部署間の使用状況を比較します
クラスターどのクラスターが主なコスト要因であるかを特定します
期間日単位の傾向を表示し、異常な変動を検出します
コストタイプ請求カテゴリ別に料金を分類します
クラウドリージョンマルチリージョン展開のリージョン間でコストを比較します

複数の観点をフィルターとして組み合わせることができます。たとえば、特定のプロジェクトの過去 7 日間の CU コストを選択すると、その事業部門のコンピューティングコストの傾向を正確に把握できます。

詳細については、コストを分析する を参照してください。

RESTful API​

Query Daily Usage API は、最大 8 桁の小数精度で使用状況データを提供し、内部の FinOps ワークフローにプログラムで統合して、次のことを行えます。

  • コストレポートを自動的に生成する

  • 内部の予算管理システムと統合する

  • カスタムのアラートルールを設定する

bash
export BASE_URL="https://api.cloud.zilliz.com"
export TOKEN="YOUR_API_KEY"

curl --request POST \
--url "${BASE_URL}/v2/usage/query" \
--header "Authorization: Bearer ${TOKEN}" \
--header "Request-Timeout: 5" \
--header "Content-Type: application/json" \
-d '{
    "start": "2024-01-01T00:00:00Z",
    "end": "2024-02-01T00:00:00Z"
}'

使用状況アラート​

コストメトリクス を監視し、アラートしきい値を設定して異常な支出を早期に検出することをお勧めします。特に次のシナリオでは重要です。

  • 新しく起動したクラスターで、実際のコストが想定と一致していることを確認する場合

  • 動的スケーリングを設定した後、スケーリングが正しく機能していることを確認する場合

  • 新しいチームメンバーが不要なリソースを作成した可能性がある場合

コスト最適化チェックリスト​

すぐに実行できるチェックリストは次のとおりです。

選択フェーズ

インデックス構成

クエリ最適化

運用フェーズ

請求の最適化

まとめ​

Zilliz Cloud のコスト最適化は、単一のパラメーターを調整することではなく、選択、構成、クエリ、運用、請求にまたがるシステム全体の取り組みです。最も効果の高い最適化は次のとおりです。

  1. まずキャパシティ最適化クラスターを選択する — これは「ダウングレード」ではありません。コスト効率のために特別に設計された階層型ストレージアーキテクチャであり、単価はパフォーマンス最適化クラスターの 1/3 で、本番ユースケースの 90% 以上をカバーします。

  2. クエリパターンを最適化する — スカラーフィールドにインデックスを作成し、TopK を制御し、返されるフィールドを絞り込み、パーティションキーを使用します。これらはそれぞれ、クエリごとのコストを有意義に削減します。

  3. エラスティックスケーリングを使用する — アイドル状態のリソースへの支払いをやめ、30–40% を節約します。

  4. ビルドレベルをチューニングする — 同じ CU で 40% 多くのデータを保存します。

適切に実行すれば、ほとんどのユーザーはビジネス要件を満たしながらコストを十分に妥当な範囲内に抑え、ストレージの階層化、インデックス最適化、エラスティックスケジューリングで Zilliz Cloud が提供する技術的利点を活用できます。

このページは役に立ちましたか？
Ctrl I