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

コスト最適化

データがスケールし、クエリ量が増加するにつれ、コスト管理が重要になります。本ガイドでは、Zilliz Cloud のコスト最適化戦略を、デプロイメント選択、インデックスチューニング、弾力スケーリング、割引、請求分析の5つの観点から体系的に解説します。

請求を理解する​

最適化を行う前に、コストの発生元を特定してください。Zilliz Cloud の料金は5つの構成要素からなります：

項目

説明

最適化可能？

コンピュート（CU）

Dedicated クラスターの Compute Unit による時間課金。

選択 + スケーリング

読み取り/書き込み操作

Serverless クラスターの従量課金。

クエリ最適化

ストレージ

データおよびバックアップストレージ（クラスター状態に関わらず）。

ビルドレベル + データクリーンアップ

データ転送

イングレス、エグレス、およびクロスリージョン転送。

アーキテクチャ計画

監査ログ

監査ログのリソース消費。

必要に応じて有効化

ほとんどのユーザーにとって、コストの70%以上がコンピュートから発生しており、これは最も最適化の余地がある部分でもあります。

料金計算ツールを使用して、ベクトル次元、データ量、QPS要件に基づく月額見積もりを取得してください。実際のコストは見積もりより低くなることが多く、業務負荷がピーク容量を無期限に維持することはほとんどありません。

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

適切なデプロイメント方式の選択は、最も影響力のある決定です。誤った方式を選択すると、小さな最適化では埋められないコストが発生します。

デプロイメント方式の概要​

タイプ

価格目安（768次元）

容量/CU

検索 QPS

レイテンシ

ユースケース

Free

0

5 GB、≤5 コレクション

—

—

学習、プロトタイピング

Serverless

RU 従量課金

オートスケーリング

自動

中

不安定なトラフィック、開発/テスト

Dedicated（パフォーマンス最適化済み）

~$65/百万ベクトル/月

150万/CU

500–1,500

低（<10ms p99）

レイテンシ重視の本番環境

Dedicated（容量最適化済み）

~$20/百万ベクトル/月

500万/CU

100–300

中

大規模、コスト重視

Dedicated（階層型ストレージ）

~$7/百万ベクトル/月

2,000万/CU（≥8 CU）

100–150（ホット）

高

大量データ、コールド/ホット分離

BYOC

カスタム

カスタム

カスタム

カスタム

コンプライアンス、Cloud 割引

選択の意思決定ツリー​

  • データ < 100万ベクトル、QPS < 50？ → Serverless を使用。操作分のみ課金で、アイドルコストゼロ。「潜在的な」トラフィックのために Dedicated リソースをプロビジョニングしないでください。

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

  • データ > 5,000万ベクトル、アクセス頻度が低い？ → 階層型ストレージクラスターを使用。容量最適化済みオプションの3分の1のコストで、大量データのうち頻繁にクエリされるサブセットのみが存在するシナリオ（例：履歴ログ分析）に最適です。

  • コンプライアンスまたは既存の Cloud 割引（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

Multi-AZ

Single AZ

オプション

デフォルトで有効

RBAC

Basic

カスタムロール + 監査

フル + SOC2/HIPAA

BYOC

非対応

対応

対応

サポート

チケット

SA + Slack

24/7 + 15分レスポンス

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

アドバイス： Standard から開始。より高い SLA、Multi-AZ、または大規模が必要になった時点で Enterprise にアップグレードしてください。アップグレードはシームレスで、データ移行は不要です。

よくある落とし穴​

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

  2. 階層型ストレージオプションの見落とし： パフォーマンス最適化済みクラスターの9分の1のコストで、階層型ストレージクラスターは明確なホット/コールドアクセスパターンを持つデータに最適です。データのごく一部のみが低レイテンシを必要とする場合、階層型ストレージオプションはコストを桁違いに削減できます。

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

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

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

インデックスビルドレベル：容量 vs. 再現率​

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

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

    ビルドレベル

    容量

    増加率

    再現率

    QPS

    容量優先 (0)

    210万

    0.4

    90–95%

    ~2,850

    バランス (1) デフォルト

    150万

    ベースライン

    91–97%

    ~3,500

    精度優先 (2)

    100万

    -0.33

    92–98%

    ~3,000

  • 容量最適化済みクラスター（768次元、CUあたり）：

    ビルドレベル

    容量

    増加率

    再現率

    QPS

    容量優先 (0)

    700万

    0.4

    89–97%

    ~300

    バランス (1) デフォルト

    500万

    ベースライン

    93–98%

    ~350

    精度優先 (2)

    300万

    -0.4

    94–98%

    ~345

ケーススタディ： 16 CU の容量最適化済みクラスターはデフォルトで8,000万ベクトルを保持します。容量優先に切り替えるとこれが1億1,200万に増加し、または同じ8,000万ベクトルを12 CU に収めることができます—CU コストを25%削減します。

📘**Note**

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

検索レベル：パフォーマンス vs. コスト​

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

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

  • レベル 4–7： 高精度シナリオ。約2–3倍のレイテンシと引き換えに95–98% の再現率。

  • レベル 8–10： 高リスクシナリオ（例：医療、不正検出）のための極限精度ですが、レイテンシとコンピュートコストが大幅に増加します。

アドバイス： enable_recall_calculation=true を使用して再現率を測定し、ビジネス要件を満たす最低レベルを見つけてください。レベルが1つ上がるごとに検索で消費されるコンピュートリソースが増加します—Serverless クラスターではこれが直接 Read vCU コストの増加に、Dedicated クラスターでは同じ CU 配分でサポート可能な QPS の低下を意味します。

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

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

クラスタータイプ

デフォルト MMAP ポリシー

効果

Dedicated（パフォーマンス最適化済み）

生ベクトルデータのみ mmap を使用；スカラーデータとすべてのインデックスはメモリに残る

低レイテンシを保証

Dedicated（容量最適化済み）

スカラーインデックス + すべての生データが mmap を使用；ベクトルインデックスのみメモリに残る

容量を最大化

Free / Serverless

すべてのフィールドとインデックスが mmap を使用

システムキャッシュに依存

最適化の推奨事項：

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

  • 容量最適化済みクラスターでは、デフォルトポリシーはすでにストレージ優先です；追加のチューニングは一般的に不要です。

📘**Note**

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 は適切なインデックスタイプ（文字列には転置インデックス、数値にはソートインデックスなど）を自動的に選択します。

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

  • 重要: 特に容量最適化クラスターでのフィルタ付きベクトル検索では、スカラーインデックスの有無が、クエリレイテンシがミリ秒単位になるか秒単位になるかを直接左右します。

適切な 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）または イテレータ を使用してください。

出力フィールドの絞り込み​

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

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 を取得し、その後、外部ストレージ（例：Redis、データベース）から ID を使ってソースコンテンツを取得することを検討してください。これにより、ベクトル検索を高速に保ちながら、外部ストレージがキャッシングの恩恵を受けられるようになります。

  • 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​

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

Dynamic scaling​

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

  • Query CU は CU容量 メトリクス（データ量主導）に基づいて自動スケーリングされます

  • Replica は CU計算 メトリクス（QPS主導）に基づいて自動スケーリングされます

典型的なシナリオ: 昼間のピーク時に32 CUが必要だが、夜間は8 CUで十分なeコマース検索サービス。動的スケーリング の設定で min=8、max=32 と設定すると、オフピーク時に自動的に8 CUまでスケールダウンします。1日あたりオフピーク時間を10時間と仮定すると、月間のコンピュートコストを約30〜40%削減できます。

詳細については、Dynamic Scaling を参照してください。

Scheduled scaling​

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

典型的な設定:

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

  • 週末は終日8 CUを維持

  • 月末のプロモーション期間に事前スケーリング

詳細については、Scheduled Scaling を参照してください。

Manual scaling​

最もシンプルなオプションを見落とさないでください — ワークロードが静寂期に入った場合（例: プロジェクト間やオフシーズン中）、積極的にCU設定を削減してください。多くのユーザーはPoC後にスケールダウンを忘れ、数週間から数ヶ月にわたって不要な容量の料金を支払うことになります。

詳細については、Manual Scaling を参照してください。

Scaling constraints​

  • Query CU × Replica ≤ 10,240

  • Replica > 1 の場合、クラスターは12 CU未満にスケールできません

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

  • 12 CU未満ではQuery CUのみ調整可能です。12 CU以上では、Query CUとReplicaを独立して調整できます

推奨: 予測不能なトラフィックには 動的スケーリング を、定期的なトラフィックパターンには スケジュールされたスケーリング を使用してください。両者を組み合わせることも可能です。

Get more credits and discounts​

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

クレジット​

Channel

クレジット

Validity

Notes

New user registration

$100 credits

30 days

Ready to use immediately, no credit card required

Add a payment method

—

Extended to 1 year

Any unused credits are automatically extended upon adding a payment method

ごみ箱

Free

—

Deleted data incurs no charges while in the ごみ箱

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

Dedicated programs​

Program

Target 対象ユーザー

How to Apply

Zilliz AI Startup Program

Early-stage startups

Apply through the official website to receive additional credits and technical support

AI Agent Program

AI Agent developers

Exclusive credits for developers building AI Agent applications. Coming soon.

Enterprise customers​

  • 営業部門に連絡してカスタム見積もりを取得: エンタープライズ顧客は年間サブスクリプションを通じて割引を受けることができます。具体的な価格については 営業部門に連絡 してください。

  • Cloud Marketplace サブスクリプション: AWS、Google Cloud、Azure Marketplace を通じてサブスクライブすると、Zilliz Cloud の料金をクラウド請求に統合し、既存のエンタープライズ割引を適用できます。

  • Advance pay: advance pay を通じてアカウントに資金を入金してください。控除の優先順位は: クレジット > advance pay > cloud marketplace サブスクリプション/クレジットカードです。予算管理要件を持つ組織に適しています。

Monitor usage page​

最適化は一度きりの作業ではありません。Zilliz Cloud は多角的なコスト分析ツールを提供し、支出の継続的な追跡と最適化を支援します。

Visualized Cost Analysis​

請求 > Usage ページでは、5つの次元で請求を内訳できます:

Dimension

目的

Project

Compare usage across different business lines or departments

Cluster

Identify which cluster is the primary cost driver

Time 期間

View day-level trends and detect abnormal fluctuations

Cost Type

Break down charges by billing category

クラウドリージョン

Compare costs across regions in multi-region deployments

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

詳細については、Analyze Cost を参照してください。

RESTful API​

Query Daily Usage API は、小数点以下8桁までの精度で使用状況データを提供し、内部的なFinOpsワークフローにプログラムで統合して以下が可能です:

  • コストレポートの自動生成

  • 内部予算システムとの統合

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

Usage alerts​

cost metrics の監視とアラート閾値の設定を推奨し、異常な支出を早期に検出してください — 特に以下のシナリオで重要です:

  • 新しく起動したクラスターで、実際のコストが想定と一致するか確認するため

  • 動的スケーリング の設定後、スケーリングが正しく機能しているか確認するため

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

Cost optimization checklist​

すぐに実行できるチェックリスト:

Selection Phase

Index 設定

Query Optimization

運用 Phase

請求 Optimization

Summary​

Zilliz Cloud におけるコスト最適化は、単一のパラメーターを調整することではなく — 選択、設定、クエリ、運用、請求にまたがるシステム的な取り組みです。最も効果の高い最適化は以下の通りです:

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

  2. クエリパターンを最適化する — スカラーフィールドにインデックスを作成し、TopKを制御し、返却フィールドを削減し、パーティションキーを使用します。これらのそれぞれがクエリあたりのコストを意味fullyに削減します。

  3. Elastic scaling を使用する — アイドルリソースの支払いをやめ、30〜40%の節約を実現します。

  4. Build level を調整する — 同じCUで40%多くのデータを保存します。

適切に実行すれば、ほとんどのユーザーはビジネス要件を満たしながらコストを適正な範囲内に抑えることができ — ストレージ階層化、インデックス最適化、および弾力的なスケジューリングにおける Zilliz Cloud の技術的優位性からも恩恵を受けることができます。