バージョン: User Guides (Cloud)

[説明] このページは機械翻訳された日本語版です。内容に誤りがございましたら、報告していただけると助かります。

コスト最適化

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

請求内容を理解する

最適化を始める前に、コストがどこから発生しているかを把握してください。Zilliz Cloud の料金は、次の5つの要素で構成されます。

項目	説明	最適化可能か
Compute (CU)	Compute Units に基づく Dedicated クラスターの時間単位課金。	選択 + スケーリング
Read/Write Operations	Serverless クラスターの従量課金。	クエリ最適化
Storage	データとバックアップのストレージ（クラスターの状態に関係なく発生）。	Build Level + データクリーンアップ
Data Transfer	受信、送信、リージョン間転送。	アーキテクチャ計画
Audit Logs	監査ログ記録によるリソース消費。	必要に応じて有効化

ほとんどのユーザーでは、コストの70%以上が Compute に由来し、最適化の余地も最も大きくなります。

料金計算ツールを使用すると、ベクトル次元数、データ量、QPS 要件に基づいて月額見積もりを取得できます。実際のコストは見積もりより低くなることが多く、これはビジネス負荷が常にピーク容量に張り付くことはまれだからです。

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

適切なデプロイ方法の選択は、最も大きな影響を持つ意思決定です。誤った方法を選ぶと、小さな最適化では埋められないコスト差が生じる可能性があります。

デプロイ方法の概要

タイプ	価格目安 (768-dim)	容量/CU	検索 QPS	レイテンシ	ユースケース
Free	0	5 GB, ≤5 colls	—	—	学習、プロトタイピング
Serverless	Pay-per-RU	Auto-scaling	Auto	中程度	不安定なトラフィック、開発/テスト
Dedicated (Performance-optimized)	~$65/M vectors/mo	2M/CU	500–1,500	低 (<10ms p99)	レイテンシ重視の本番環境
Dedicated (Capacity-optimized)	~$20/M vectors/mo	8M/CU	100–300	中程度	大規模、コスト重視
Dedicated (Tiered-storage)	~$7/M vectors/mo	40M/CU (≥8 CU)	100–150 (Hot)	高め	大量データ、コールド/ホット分離
BYOC	Custom	Custom	Custom	Custom	コンプライアンス、Cloud discounts

選択の判断ツリー

データ < 1M vectors、QPS < 50? → Serverless を使用します。アイドル時のコストはゼロで、操作分だけ支払います。「将来の」トラフィックのために Dedicated リソースをプロビジョニングしないでください。
データ 1M–50M vectors、安定した低レイテンシが必要? → Capacity-optimized クラスターが最も費用対効果の高いソリューションです。Performance-optimized オプションより3倍安く、ほとんどの RAG やレコメンデーションのシナリオに十分なサブ100ミリ秒のレイテンシを提供します。Performance-optimized クラスターは、極端な要件（例: <10 ms p99 のリアルタイム検索）の場合にのみ使用してください。
データ > 50M vectors、アクセス頻度が低い? → Tiered-storage クラスターを使用します。Capacity-optimized オプションより3倍安く、データは大量でも頻繁にクエリされるのは一部だけというシナリオ（例: 履歴ログ分析）に適しています。
コンプライアンス要件または既存の Cloud Discounts (RI/SP) がある? → BYOC (Bring Your Own Cloud)。クラスターはお客様の VPC 内で稼働するため、エンタープライズレベルのクラウド割引を活用し、データ主権要件を満たせます。

推奨: Capacity-optimized はほとんどのシナリオに最適

Capacity-optimized クラスターは、単に「遅い」バージョンだと誤解されがちです。実際には、Zilliz Cloud の中で最もアーキテクチャ的に洗練された製品です。

従来のベクトルデータベースは、すべてのインデックスと生データをメモリに保持し、速度のためにコストを犠牲にします。一方、Capacity-optimized クラスターは 階層型ストレージアーキテクチャ を使用します。

階層型ストレージ: 速度を確保するためベクトルインデックスはメモリに保持し、スカラーデータと生ベクトルはインテリジェントなキャッシュを伴う mmap によってディスクへマップします。これにより、Performance-optimized クラスターと比べて CU あたり3倍のデータ密度を実現します。
DiskANN レベルの最適化: IVF インデックスはディスクフレンドリーなアクセス向けに調整され、NVMe SSD でスループットを最大化しながら 10–50ms のレイテンシを維持します。これはほとんどの AI アプリケーションでは無視できる程度です。
高いリソース利用率: Performance-optimized クラスターは30%のヘッドルームを維持することが多い一方、Capacity-optimized クラスターは90%以上のデータ密度に到達できます。

まとめ: Performance-optimized オプションはハードウェアで速度を買うものであり、Capacity-optimized オプションは技術で効率を買うものです。

プロジェクトプラン: Standard vs. Enterprise vs. Business Critical

Zilliz Cloud には、機能とスケーリング上限に影響する複数のプランがあります。

機能	Standard	Enterprise	Business Critical
最大 CU	32 CU	256 CU	512 CU
Replica 上限	Query CU × Repl ≤ 32	Query CU × Repl ≤ 256	Query CU × Repl ≤ 512
SLA	0.999	0.9995	0.9999
Multi-AZ	Single AZ	任意	デフォルトで有効
RBAC	基本	Custom Roles + Audit	Full + SOC2/HIPAA
BYOC	非対応	対応	対応
サポート	Ticket	SA + Slack	24/7 + 15m Response

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

アドバイス: まずは Standard から始めてください。より高い SLA、Multi-AZ、またはより大きなスケールが必要になった場合にのみ、Enterprise へアップグレードします。アップグレードはシームレスで、データ移行は不要です。

よくある落とし穴

Performance-optimized クラスターを既定として選ぶ: 多くのユーザーは、PoC 中に使用した Performance-optimized クラスターを基準に予算を見積もります。しかし、Capacity-optimized は「ダウングレード版」ではなく、コスト効率のために専用設計されたアーキテクチャです。Performance-optimized クラスターのわずか1/3のコストで、ほとんどのシナリオに十分な QPS を提供します。
Tiered-storage オプションを見落とす: Performance-optimized クラスターの1/9のコストで利用できる Tiered-storage クラスターは、明確なホット/コールドのアクセスパターンを持つデータに最適です。低レイテンシが必要なのがデータのごく一部だけであれば、Tiered-storage オプションによってコストを一桁削減できます。
小規模で Dedicated を使用する: 小規模なデータセットや不安定なトラフィックでは、Serverless（従量課金）の方が Dedicated よりはるかに費用対効果に優れます。「エンタープライズらしく見せる」ためだけにリソースを過剰プロビジョニングすることは避けてください。

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

モードを選択したら、各 CU の有用性を最大化するためにパラメータを調整します。

インデックスの Build Level: 容量 vs. リコール

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

Performance-optimized クラスター (768-dim、CU あたり):

Build Level
容量
増加
リコール
QPS
Capacity-first (0)
2.1M
0.4
90–95%
~2,850
Balanced (1) Default
1.5M
Baseline
91–97%
~3,500
Precision-first (2)
1.0M
-0.33
92–98%
~3,000
Capacity-optimized クラスター (768-dim、CU あたり):

Build Level
容量
増加
リコール
QPS
Capacity-first (0)
7M
0.4
89–97%
~300
Balanced (1) Default
5M
Baseline
93–98%
~350
Precision-first (2)
3M
-0.4
94–98%
~345

Build Level	容量	増加	リコール	QPS
Capacity-first (0)	2.1M	0.4	90–95%	~2,850
Balanced (1) Default	1.5M	Baseline	91–97%	~3,500
Precision-first (2)	1.0M	-0.33	92–98%	~3,000

Build Level	容量	増加	リコール	QPS
Capacity-first (0)	7M	0.4	89–97%	~300
Balanced (1) Default	5M	Baseline	93–98%	~350
Precision-first (2)	3M	-0.4	94–98%	~345

ケーススタディ: 16 CU の Capacity-optimized クラスターは、デフォルトで 80M vectors を保持できます。Capacity-first に切り替えると 112M まで増やせる、または同じ 80M vectors を 12 CU に収められるため、CU コストを25%削減できます。

📘**注記**

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

Search Level: パフォーマンス vs. コスト

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

Level 1–3: ほとんどのシナリオに最適です（90–95% リコール）。
Level 4–7: 高精度が必要なシナリオ向けです。95–98% リコールのために、おおよそ 2–3× のレイテンシと引き換えになります。
Level 8–10: 医療や不正検知など、影響の大きいシナリオ向けの極めて高い精度です。ただし、レイテンシとコンピューティングコストが大幅に増加します。

アドバイス: enable_recall_calculation=true を使用してリコールを測定し、ビジネス要件を満たす最も低いレベルを見つけてください。レベルを上げるたびに検索で消費される計算リソースが増えます。Serverless クラスターでは Read vCU コストの上昇に直結し、Dedicated クラスターでは同じ CU 割り当てでサポート可能な QPS が低下します。

Mmap 設定: メモリとディスクのバランス

Memory Mapping (mmap) は、データをメモリからディスクへオフロードします。

クラスタータイプ	デフォルトの MMAP ポリシー	効果
Dedicated (Performance-optimized)	生ベクトルデータのみ mmap を使用。スカラーデータとすべてのインデックスはメモリに保持	低レイテンシを保証
Dedicated (Capacity-optimized)	スカラーインデックス + すべての生データが mmap を使用。ベクトルインデックスのみメモリに保持	容量を最大化
Free / Serverless	すべてのフィールドとインデックスが mmap を使用	システムキャッシュに依存

最適化の推奨事項:

Performance-optimized クラスターでは、スカラーフィルタリングがボトルネックでない場合、スカラーフィールドで mmap を有効にして、ベクトルインデックス用のメモリを解放することを検討してください。
Capacity-optimized クラスターでは、デフォルトポリシーがすでにストレージ優先であるため、通常は追加の調整は不要です。

📘**注記**

mmap 設定を変更する前に Collection を release し、変更後に reload する必要があります。設定を誤るとパフォーマンス低下や 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 は適切なインデックスタイプ（文字列には転置インデックス、数値にはソート済みインデックスなど）を自動的に選択します。
スカラーインデックスのメモリオーバーヘッドは最小限ですが、フィルタリング性能を桁違いに改善します。フルテーブルスキャンをインデックスルックアップに変えられます。
重要: 特に Capacity-optimized クラスターでフィルター付きベクトル検索を行う場合、スカラーインデックスの有無が、クエリレイテンシがミリ秒単位になるか秒単位になるかを直接左右します。

適切な TopK を選択する

TopK は、計算とネットワークのオーバーヘッドに直接影響します。

TopK	相対レイテンシ	相対 RU コスト (Serverless)	典型的なユースケース
1–10	Baseline	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）またはイテレーターを使用します。

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

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

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 の請求に直接影響します。不要なフィールドを減らすことが、コスト削減の最も簡単な方法です。

Partition Key を活用する

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

次の例は、コレクション作成時に Partition Key を指定する方法を示しています。

schema.add_field("tenant_id", DataType.VARCHAR, max_length=128, is_partition_key=True)

ユースケース:

マルチテナント SaaS: tenant_id を Partition Key として使用すると、各テナントのクエリは自分のデータパーティションのみをスキャンするため、QPS とレイテンシの両方が大幅に改善します。
カテゴリフィルタリング: category を Partition Key として使用すると、特定カテゴリ内を検索するときにデータセット全体をスキャンする必要がなくなります。

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

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

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

動的スケーリング

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

Query CU は CU Capacity メトリクス（データ量に基づく）に応じて自動的にスケールします。
Replicas は 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 と Replicas を個別に調整できます。

推奨: 予測しにくいトラフィックには動的スケーリングを使用し、規則的なトラフィックパターンにはスケジュールスケーリングを使用してください。両方を組み合わせることもできます。

Credits と割引をさらに活用する

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

Credits

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

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

Dedicated プログラム

プログラム	対象ユーザー	申請方法
Zilliz AI Startup Program	アーリーステージのスタートアップ	公式ウェブサイトから申請し、追加 Credits と技術サポートを受け取ります
AI Agent Program	AI Agent 開発者	AI Agent アプリケーションを構築する開発者向けの専用 Credits。近日公開。

エンタープライズ顧客

カスタム見積もりについて営業に問い合わせる: エンタープライズ顧客は年間サブスクリプションを通じて割引を受けられます。具体的な料金については営業にお問い合わせください。
Cloud Marketplace サブスクリプション: AWS、Google Cloud、Azure Marketplace 経由でサブスクライブすると、Zilliz Cloud の料金をクラウド請求に統合し、既存のエンタープライズ割引を適用できます。
Advance pay: advance pay でアカウントに入金します。控除の優先順位は、credits > advance pay > cloud marketplace subscriptions/credit cards です。予算管理要件がある組織に適しています。

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

最適化は一度限りの作業ではありません。Zilliz Cloud は、支出を継続的に追跡して最適化するための多次元コスト分析ツールを提供しています。

可視化されたコスト分析

Billing > Usage ページでは、請求を5つのディメンションに分解できます。

ディメンション	目的
Project	異なる事業ラインや部門間の使用量を比較
Cluster	どのクラスターが主なコスト要因かを特定
Time Period	日単位の傾向を表示し、異常な変動を検出
Cost Type	請求カテゴリ別に料金を分解
Cloud Region	マルチリージョンデプロイでリージョン間のコストを比較

複数のディメンションをフィルターとして組み合わせることもできます。たとえば、特定プロジェクトの過去7日間の CU コストを選択すると、その事業ラインのコンピュートコストの推移を正確に把握できます。

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

RESTful API

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

コストレポートを自動生成する
社内の予算管理システムと統合する
カスタムアラートルールを設定する

使用状況アラート

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

新しく起動したクラスターで、実際のコストが想定と一致していることを確認する
動的スケーリングを設定した後、スケーリングが正しく機能していることを確認する
新しいチームメンバーが不要なリソースを作成した可能性がある場合