コスト最適化
データ規模とクエリボリュームが増大するにつれ、コスト制御は極めて重要になります。このガイドでは、デプロイメントの選択、インデックスのチューニング、エラスティックスケーリング、割引、および請求分析という 5 つの次元にわたって、Zilliz Cloud のコスト最適化戦略を体系的に説明します。
請求書の理解
最適化を行う前に、コストがどこから発生しているかを特定してください。Zilliz Cloud の料金は、以下の 5 つの要素で構成されています。
項目 | 説明 | 最適化可能？ |
|---|---|---|
専用クラスターの Compute Units に基づく時間課金。 | 選択 + スケーリング | |
Serverless クラスターの使用量に応じた従量課金。 | クエリの最適化 | |
データおよびバックアップストレージ（クラスターのステータスに関わらず）。 | ビルドレベル + データクリーンアップ | |
イングレス、エグレス、およびリージョン間転送。 | アーキテクチャ計画 | |
監査ログのためのリソース消費。 | 必要に応じて有効化 |
ほとんどのユーザーにとって、コストの 70% 以上はComputeに由来し、これが最大の最適化ポテンシャルも秘めています。
料金計算機 を使用して、ベクトル次元、データボリューム、および QPS 要件に基づいた月次見積もりを取得してください。ビジネス負荷がピーク容量で無期限に維持されることは稀であるため、実際のコストは見積もりよりも低くなることがよくあります。
適切なデプロイメント方法の選択
適切なデプロイメント方法の選択は、最も影響の大きい決定です。誤った方法を選択すると、細かな最適化では埋め合わせられないコストが発生する可能性があります。
デプロイメント方法の一覧
タイプ | 価格目安（768 次元） | 容量/CU | 検索 QPS | レイテンシ | ユースケース |
|---|---|---|---|---|---|
Free | 0 | 5 GB, ≤5 コレクション | — | — | 学習、プロトタイピング |
Serverless | RU 従量課金 | オートスケーリング | 自動 | 中 | 不安定なトラフィック、開発/テスト |
Dedicated (パフォーマンス最適化済み) | 約$65/M ベクトル/月 | 1.5M/CU | 500–1,500 | 低 (<10ms p99) | レイテンシが重要な本番環境 |
Dedicated (容量最適化済み) | 約$20/M ベクトル/月 | 5M/CU | 100–300 | 中 | 大規模、コスト重視 |
Dedicated (ティアードストレージ) | 約$7/M ベクトル/月 | 20M/CU (≥8 CU) | 100–150 (ホット) | 高 | 膨大なデータ、ホット/コールド分離 |
BYOC | カスタム | カスタム | カスタム | カスタム | コンプライアンス、クラウド割引 |
選択の意思決定ツリー
-
データ < 100 万ベクトル、QPS < 50？ → Serverless を使用してください。アイドルコストゼロで、操作に対してのみ支払います。「潜在的な」トラフィックのために専用リソースをプロビジョニングしないでください。
-
データ 100 万～5,000 万ベクトル、安定した低レイテンシが必要？ → 容量最適化済み クラスターが最も費用対効果の高いソリューションです。これはパフォーマンス最適化済みオプションの 3 分の 1 のコストであり、ほとんどの RAG や推薦シナリオで十分なサブ 100 ミリ秒のレイテンシを提供します。パフォーマンス最適化済み クラスターは、極端な要件（例：<10 ms p99 のリアルタイム検索）の場合にのみ使用してください。
-
データ > 5,000 万ベクトル、アクセス頻度が低い？ → ティアードストレージ クラスターを使用してください。これは容量最適化済みオプションの 3 分の 1 のコストであり、膨大なデータのうち一部のみが頻繁にクエリされるシナリオ（例：履歴ログ分析）に理想的です。
-
コンプライアンスまたは既存のクラウド割引 (RI/SP) がある？ → BYOC (Bring Your Own Cloud)。クラスターはお客様の VPC で実行され、エンタープライズレベルのクラウド割引を活用し、データ主権の要件を満たすことができます。
推奨：容量最適化済み—ほとんどのシナリオに最適
容量最適化済みクラスターは、単なる「低速版」と誤解されることがよくあります。実際には、これは Zilliz Cloud で最も建築的に洗練された製品です。
従来のベクトルデータベースがすべてのインデックスと生データをメモリに保持し、コストを速度と引き換えにしているのに対し、容量最適化済みクラスターはティアードストレージアーキテクチャを採用しています。
-
階層化ストレージ： ベクトルインデックスは速度のためにメモリに残り、スカラーフィールドと生ベクトルはインテリジェントなキャッシングにより mmap を介してディスクにマップされます。これにより、パフォーマンス最適化済みクラスターと比較して CU あたりのデータ密度が 3 倍になります。
-
DiskANN レベルの最適化： IVF インデックスはディスクフレンドリーなアクセス用に調整され、NVMe SSD を活用してスループットを最大化し、10～50ms のレイテンシを維持します。これはほとんどの AI アプリケーションにおいて無視できるレベルです。
-
高いリソース利用率： パフォーマンス最適化済みクラスターはしばしば 30% の余裕を持たせますが、容量最適化済みクラスターは 90% 以上のデータ密度に達することができます。
まとめ： パフォーマンス最適化済みオプションはハードウェアで速度を購入するのに対し、容量最適化済みオプションは技術で効率を購入します。
プロジェクトプラン：Standard vs. Enterprise vs. ビジネスクリティカル
Zilliz Cloud には、機能とスケーリング制限に影響を与えるいくつかのプランがあります。
機能 | Standard | Enterprise | ビジネスクリティカル |
|---|---|---|---|
最大 CU | 32 CU | 256 CU | 512 CU |
レプリカ制限 | Query CU × Repl ≤ 32 | Query CU × Repl ≤ 256 | Query CU × Repl ≤ 512 |
SLA | 0.999 | 0.9995 | 0.9999 |
マルチ AZ | シングル AZ | オプション | デフォルトで有効 |
RBAC | 基本 | カスタムロール + 監査 | 完全 + SOC2/HIPAA |
BYOC | 非対応 | 対応 | 対応 |
サポート | チケット | SA + Slack | 24/7 + 15 分以内応答 |
詳細については、詳細なプラン比較 を参照してください。
アドバイス： まずは Standard から開始してください。より高い SLA、マルチ AZ、または大規模化が必要になった場合にのみ Enterprise にアップグレードしてください。アップグレードはシームレスであり、データ移行は不要です。
よくある落とし穴
-
デフォルトでパフォーマンス最適化済みクラスターを選択する： 多くのユーザーが、PoC で使用したパフォーマンス最適化済みクラスターに基づいて予算を立てています。しかし、容量最適化済みは「ダウングレード版」ではなく、コスト効率のために特別に設計されたアーキテクチャです。これは、パフォーマンス最適化済みクラスターの 3 分の 1 のコストで、ほとんどのシナリオに十分な QPS を提供します。
-
ティアードストレージオプションを見落とす： パフォーマンス最適化済みクラスターの 9 分の 1 のコストであるティアードストレージクラスターは、明確なホット/コールドアクセスパターンを持つデータに理想的です。データの小さな部分のみが低レイテンシを必要とする場合、ティアードストレージオプションを使用することでコストを桁違いに削減できます。
-
小規模向けに Dedicated を使用する： 小規模なデータセットや不安定なトラフィックの場合、Serverless（従量課金）の方が Dedicated よりもはるかに費用対効果が高くなります。「エンタープライズ」の外見のためだけにリソースを過剰プロビジョニングすることは避けてください。
インデックスとストレージの最適化
モードを選択したら、パラメータを調整して各 CU の効用を最大化します。
インデックスビルドレベル：容量 vs 再現率
build_level パラメータ は、インデックスの精度とストレージ密度を制御します。極端な再現率を必要としないシナリオでは、これを減らすことで各 CU のストレージ容量を大幅に増やすことができます。
-
パフォーマンス最適化済みクラスター（768 次元、CU あたり）：
ビルドレベル
容量
増加
再現率
QPS
容量優先 (0)
2.1M
0.4
90–95%
約 2,850
バランス (1) デフォルト
1.5M
基準
91–97%
約 3,500
精度優先 (2)
1.0M
-0.33
92–98%
約 3,000
-
容量最適化済みクラスター（768 次元、CU あたり）：
ビルドレベル
容量
増加
再現率
QPS
容量優先 (0)
7M
0.4
89–97%
約 300
バランス (1) デフォルト
5M
基準
93–98%
約 350
精度優先 (2)
3M
-0.4
94–98%
約 345
事例研究： デフォルトでは、16 CU の容量最適化済みクラスターは 8,000 万ベクトルを保持できます。容量優先 に切り替えることで、これを 1 億 1,200 万に増やすか、同じ 8,000 万ベクトルを 12 CU に収容できるようになり、CU コストを 25% 節約できます。
build_level パラメータは設定後に変更できません。変更するには、インデックスを削除して再作成する必要があります。コレクションを作成する前に要件を評価することを推奨します。このパラメータは浮動小数点ベクトルタイプ（FLOATVECTOR、FLOAT16VECTOR、および BFLOAT16_VECTOR）のみをサポートします。
検索レベル：パフォーマンス vs コスト
-
レベル 1～3： ほとんどのシナリオに最適（90～95% の再現率）。
-
レベル 4～7： 高精度シナリオ。95～98% の再現率を得るために、レイテンシを約 2～3 倍犠牲にします。
-
レベル 8～10： 医療、不正検出など重要なシナリオ向けの極端な精度ですが、レイテンシと計算コストが大幅に増加します。
アドバイス： enable_recall_calculation=true を使用して再現率を測定し、ビジネス要件を満たす最低レベルを見つけてください。レベルを上げるごとに検索で消費される計算リソースが増加します。Serverless クラスターでは、これは直接 Read vCU コストの上昇につながります。Dedicated クラスターでは、同じ CU 割り当てでサポート可能な QPS が低下することを意味します。
Mmap 設定：メモリとディスクのバランス
メモリマッピング (mmap) は、データをメモリからディスクにオフロードします。
クラスタータイプ | デフォルトの MMAP ポリシー | 効果 |
|---|---|---|
Dedicated (パフォーマンス最適化済み) | 生ベクトルデータのみ mmap を使用。スカラーデータとすべてのインデックスはメモリに残る | 低レイテンシを保証 |
Dedicated (容量最適化済み) | スカラーインデックス + すべての生データが mmap を使用。ベクトルインデックスのみメモリに残る | 容量を最大化 |
Free / Serverless | すべてのフィールドとインデックスが mmap を使用 | システムキャッシュに依存 |
最適化の推奨事項：
-
パフォーマンス最適化済みクラスターの場合、スカラーフィルタリングがボトルネックでない場合は、スカラーフィールドで mmap を有効にして、ベクトルインデックスのためにメモリを解放することを検討してください。
-
容量最適化済みクラスターの場合、デフォルトのポリシーはすでにストレージ優先であるため、通常は追加のチューニングは不要です。
mmap 設定を変更する前にコレクションをリリースし、その後で再ロードする必要があります。設定を誤るとパフォーマンスの低下や OOM エラーの原因となる可能性があるため、まずテスト環境で検証してください。
クエリの最適化
効率的なクエリは、Serverless ユーザーの Read Unit (RU) コストを削減し、Dedicated CU の QPS を向上させます。
スカラーフィールドのインデックス化
多くのユーザーが スカラーインデックス を軽視しています。これがないと、フィルタ（例：category == "electronics" または timestamp > 1700000000）によってコレクション全体のスキャンがトリガーされ、非常に高額になります。頻繁にフィルタリングされるスカラーフィールドのインデックスを作成できます。
collection.create_index(
field_name="category",
index_name="idx_category"
)
collection.create_index(
field_name="timestamp",
index_name="idx_timestamp"
)
最適化の推奨事項:
-
filter式に登場するすべてのスカラーフィールドにインデックスの構築を行ってください。Zilliz Cloud は、適切なインデックスタイプ（文字列には転置インデックス、数値にはソート済みインデックスなど）を自動的に選択します。 -
スカラーインデックスはメモリオーバーヘッドが最小限ですが、フィルタリング性能を桁違いに向上させ、フルテーブルスキャンをインデックスルックアップに変換します。
-
重要: 特に容量最適化クラスターでのフィルタ付きベクトル検索において、スカラーインデックスの有無が、クエリレイテンシをミリ秒単位にするか秒単位にするかを直接決定します。
Select appropriate TopK
TopK は、計算およびネットワークのオーバーヘッドに直接影響します。
TopK | 相対レイテンシ | 相対 RU コスト (Serverless) | 典型的なユースケース |
|---|---|---|---|
1–10 | ベースライン | 1x | RAG（通常は 3～5 のコンテキストチャンク） |
10–50 | 1.2–1.5x | 1.5–2x | 推薦システム、検索結果ページ |
50–200 | 1.5–3x | 2–4x | 候補セット生成、リランキング入力 |
200–1000 | 3–10x | 4–10x | バッチ分析、クラスタリング |
-
RAG: TopK 3～10 を使用してください。コンテキストを増やしても LLM の品質が向上することはほとんどなく、トークンと RU を浪費するだけです。
-
推薦: リランキングモデルの制限値（通常は 20～50）を使用してください。
-
大 TopK: 1 つのリクエストで大量の結果セットを返す代わりに、ページネーション（
offset+limit）または イテレーター を使用してください。
Refine output fields
デフォルトでは、以下に示すように、検索はすべてのスカラーフィールドを返します。
results = collection.search(vectors, "embedding", search_params, limit=10)
ただし、すべてのクエリで大きなテキストフィールド（例：ドキュメントの全文）を返すと、レイテンシと RU コストが増加します。そのため、必要な出力フィールドのみを指定できます。
results = collection.search(
vectors, "embedding", search_params, limit=10,
output_fields=["id", "title", "category"] # 不要返回 "content" 等大字段
)
詳細については、出力フィールドの使用 を参照してください。
最適化の推奨事項:
-
output_fieldsを常に明示的に指定し、ビジネスロジックに必要なフィールドのみを返すようにしてください。 -
RAG シナリオでは、元のテキストが必要な場合、まずベクトル検索で ID を取得し、その後その ID を使用して外部ストレージ（例：Redis、データベース）からソースコンテンツを取得することを検討してください。これにより、ベクトル検索を高速に保ちつつ、外部ストレージでキャッシングの恩恵を受けることができます。
-
Serverless モードでは、返されるデータ量が Read vCU の課金に直接影響します。不要なフィールドを削減することが、コストを削減する最も簡単な方法です。
パーティションキーの活用
パーティションキー は、スカラー値に基づいてデータを自動的にパーティションに分散し、検索時に無関係なデータをスキップできるようにします。
以下の例は、コレクション作成時にパーティションキーを指定する方法を示しています。
schema.add_field("tenant_id", DataType.VARCHAR, max_length=128, is_partition_key=True)
ユースケース:
-
マルチテナント SaaS:
tenant_idをパーティションキーとして使用することで、各テナントのクエリが自身のデータパーティションのみをスキャンするようになり、QPS とレイテンシの両方が大幅に改善されます。 -
カテゴリフィルタリング:
categoryをパーティションキーとして使用することで、特定のカテゴリ内で検索する際にデータセット全体をスキャンする必要がなくなります。
パフォーマンス向上: データが均等に分散されている 100 のテナントを想定すると、パーティションキーを使用することでクエリごとのスキャン量が約 99% 削減されます。分布が不均一な場合でも、スキャン量は通常 50〜90% 削減されます。
Elastic scaling
専用クラスターにおける最大のコストの落とし穴は、「ピーク負荷に合わせてプロビジョニングし、24 時間 365 日稼働させること」です。Zilliz Cloud はこのパターンを打破するための 3 つのスケーリング戦略を提供します。
Dynamic scaling
最小および最大 CU 値を設定すると、システムがリアルタイムの負荷に基づいて自動的にスケーリングします。
- クエリ CU は、CU 容量メトリクス（データ量駆動）に基づいて自動的にスケーリングします
- レプリカは、CU 計算メトリクス（QPS 駆動）に基づいて自動的にスケーリングします
典型的なシナリオ: 昼間のピーク時に 32 CU 必要だが、夜間は 8 CU で済む EC サイトの検索サービス。動的スケーリング設定で min=8、max=32 を設定すると、システムはオフピーク時に自動的に 8 CU までスケールダウンします。1 日あたり 10 時間のオフピーク時間を想定すると、月間の計算コストを約 30〜40% 削減できます。
詳細については、動的スケーリング をご覧ください。
Scheduled scaling
トラフィックパターンが予測可能なワークロードに適しています。基本モード（シンプルなセレクター）と詳細モード（Unix cron 式）をサポートしています。
典型的な設定:
- 平日は 9:00 に 32 CU までスケールアップし、22:00 に 8 CU までスケールダウン
- 週末は終日 8 CU を維持
- 月末のプロモーション期間に向けて事前にスケーリング
詳細については、スケジュールされたスケーリング をご覧ください。
Manual scaling
最もシンプルなオプションを見落としてはいけません — ワークロードが閑散期に入った場合（例：プロジェクト間やオフシーズン）、CU 設定を積極的に減らしてください。多くのユーザーは PoC 後にスケールダウンすることを忘れ、不要な容量に対して数週間、あるいは数か月分を支払ってしまうことがあります。
詳細については、手動スケーリング をご覧ください。
Scaling constraints
- クエリ CU × レプリカ ≤ 256
- レプリカ > 1 の場合、クラスターは 8 CU 未満にスケールできません
- スケールダウン時、データ量は新しい CU 容量の 80% 未満である必要があります
- 8 CU 未満ではクエリ CU のみ調整可能。8 CU 超ではクエリ CU とレプリカを独立して調整可能
推奨: 予測不可能なトラフィックには動的スケーリングを、定期的なトラフィックパターンにはスケジュールされたスケーリングを使用してください。これら 2 つを組み合わせることも可能です。
Get more credits and discounts
技術的な最適化に加え、Zilliz のプロモーションプログラムを最大限に活用することも同様に重要です。
クレジット
チャネル | クレジット | 有効期限 | 注記 |
|---|---|---|---|
新規ユーザー登録 | $100 クレジット | 30 日間 | すぐに使用可能、クレジットカード不要 |
支払い方法の追加 | — | 1 年に延長 | 未使用のクレジットは、支払い方法を追加すると自動的に延長されます |
ごみ箱 | 無料 | — | ごみ箱にある削除済みデータには料金が発生しません |
推奨: 初回登録後できるだけ早く支払い方法を追加し、$100 クレジットの有効期限を 30 日から 1 年に延長して、技術評価に十分な時間を確保してください。
Dedicated programs
プログラム | 対象ユーザー | 申請方法 |
|---|---|---|
Zilliz AI スタートアッププログラム | 初期段階のスタートアップ | 公式サイトから申請して、追加クレジットと技術サポートを受け取ります |
AI エージェントプログラム | AI エージェント開発者 | AI エージェントアプリケーションを構築する開発者向けの専用クレジット。近日公開予定。 |
Enterprise customers
-
営業担当者へのお問い合わせによるカスタム見積もり: エンタープライズ顧客は年間サブスクリプションを通じて割引を受けられます。具体的な価格については 営業担当者にお問い合わせください。
-
クラウドマーケットプレイスサブスクリプション: AWS、Google Cloud、Azure マーケットプレイスを通じてサブスクライブすることで、Zilliz Cloud の料金をクラウド請求書に統合し、既存のエンタープライズ割引を適用できます。
-
前払い: 前払い でアカウントに資金を入金できます。控除優先順位は以下の通りです：クレジット > 前払い > クラウドマーケットプレイスサブスクリプション/クレジットカード。予算管理要件のある組織に適しています。
Monitor usage page
最適化は一度きりの取り組みではありません。Zilliz Cloud は、支出を継続的に追跡・最適化するのに役立つ多次元のコスト分析ツールを提供します。
Visualized Cost Analysis
請求 > 使用状況ページでは、請求書を 5 つの次元に分解できます。
次元 | 目的 |
|---|---|
プロジェクト | 異なる事業ラインや部門間の使用状況を比較 |
クラスター | どのクラスターが主要なコスト要因かを特定 |
期間 | 日次トレンドを表示し、異常な変動を検出 |
コストタイプ | 請求カテゴリ別に料金を内訳 |
クラウドリージョン | マルチリージョン展開におけるリージョン間のコストを比較 |
複数の次元をフィルターとして組み合わせることができます。例えば、特定のプロジェクトの過去 7 日間の CU コストを選択すると、その事業ラインの計算コストトレンドを正確に把握できます。
詳細については、コスト分析 をご覧ください。
RESTful API
Query Daily Usage API は、最大小数点以下 8 桁の精度で使用状況データを提供し、内部的な FinOps ワークフローにプログラム的に統合して以下のことを行えます。
- コストレポートの自動生成
- 内部予算システムとの統合
- カスタムアラートルールの設定
Usage alerts
異常な支出を早期に発見するために、コストメトリクス を監視し、アラート閾値を設定することをお勧めします。特に以下のシナリオで重要です。
- 新規立ち上げられたクラスターで、実際のコストが期待値と一致しているか確認するため
- 動的スケーリングを設定した後、スケーリングが正しく機能しているか確認するため
- 新しいチームメンバーが不要なリソースを作成した可能性がある場合
Cost optimization checklist
すぐに実行できるチェックリスト：
選択フェーズ
インデックス設定
クエリ最適化
運用フェーズ
請求最適化
Summary
Zilliz Cloud でのコスト最適化は、単一のパラメータを調整することではなく、選択、設定、クエリ、運用、請求にわたるシステム全体の取り組みです。最も効果の高い最適化は以下の通りです。
-
まず容量最適化クラスターを選択する — これは「ダウングレード」ではありません。これはコスト効率のために特別に設計された階層型ストレージアーキテクチャであり、ユニットコストはパフォーマンス最適化クラスターの 1/3 で、生産環境のユースケースの 90% 以上をカバーします。
-
クエリパターンを最適化する — スカラーフィールドにインデックスを張り、TopK を制御し、返されるフィールドを削減し、パーティションキーを使用します。これらそれぞれがクエリあたりのコストを有意に削減します。
-
エラスティックスケーリングを使用する — アイドル状態のリソースに対する支払いを止め、30〜40% を節約します。
-
ビルドレベルを調整する — 同じ CU で 40% 多くのデータを保存します。
適切に行えば、ほとんどのユーザーはビジネス要件を満たしながらコストを合理的な範囲内に抑えられ、ストレージ階層化、インデックス最適化、エラスティックスケジューリングにおいて Zilliz Cloud が提供する技術的利点を享受できます。