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

データレジリエンス

Zilliz Cloud は、フルマネージド型の ベクトルデータベース サービスとして、さまざまな障害シナリオ下においてもミッションクリティカルなデータとサービスの継続的な可用性を確保するための、エンタープライズグレードの High Availability (HA) および Disaster Recovery (DR) 機能を提供します。

Core Capabilities​

  • High Availability (HA): ノード、アベイラビリティゾーン (AZ)、またはリージョンレベルの停止時において、自動的な障害検出と迅速なフェイルオーバーメカニズムにより、サービスの中断を防ぎます。

  • Disaster Recovery (DR): 包括的なバックアップおよびリストア戦略により、重大なインシデント発生後のビジネス復旧を迅速に行います。

  • Flexible Resilience Tiers: 標準からエンタープライズグレードのクロスリージョン展開まで、ビジネスシナリオに応じた多様な RPO/RTO 要件に合わせて調整可能です。

  • コスト最適化: ビジネス価値とリスク許容度に基づき、最も費用対効果の高いレジリエンス戦略を選択できます。

キー Concepts​

Core Metrics​

  • Recovery Point Objective (RPO): 許容される最大のデータ損失量を時間で表した指標です。例えば、RPO が 5 分の場合、障害発生時に最大 5 分間の最新データが失われる可能性があることを意味します。

  • Recovery Time Objective (RTO): 障害発生からサービス完全復旧までに許容される最大の時間であり、障害検出、フェイルオーバーの意思決定、実際の復旧作業を含みます。

  • Service Level Agreement (Uptime SLA): Zilliz Cloud のサービス可用性に関するコミットメントは、通常パーセンテージで表されます（例：99.95% の稼働率は、月間のダウンタイムが 21.6 分以下であることを意味します）。

Fault Tolerance Scope​

  • Node-level fault tolerance: 単一の計算ノードまたはストレージノードの障害

  • AZ-level fault tolerance: AZ 全体の停止（例：データセンターの障害）

  • Region-level fault tolerance: リージョン全体のサービス停止（例：自然災害）

  • Cloud provider-level fault tolerance: 単一のクラウドベンダーに起因するリスクを軽減するためのマルチクラウド展開

Resilience Architecture Tiers​

High Availability (HA) Tiers​

Tier

Description

RPO

RTO

Write Latency / Replication Scheme

Fault Tolerance

SLA

Relative Cost

Standard

マルチレプリカメカニズムを採用した単一リージョン・単一 AZ 展開

0 秒

≤1 分

単一 AZ 内での書き込み；Quorum 経由で WAL をレプリケート

ノードレベルの障害

AZs: 1

Regions: 1

SLA 保証なし

低

Enterprise

自動フェイルオーバー機能を備えた、3 AZ にまたがる単一リージョン展開

0 秒

≤1 分

AZ 間書き込み；Quorum 経由で WAL をレプリケート

AZ レベルの障害

AZs: 3

Regions: 1

99.95%

中

Enterprise Multi-Replica

リージョン内のアクティブ - アクティブ型マルチレプリカアーキテクチャ；読み書き分離による高速フェイルオーバー

0 秒

≤10 秒

AZ 間書き込み；WAL 経由でレプリカ間同期

AZ レベルの障害

AZs: 3

Regions: 1

99.99%

中～高

Cross-Region HA

グローバル負荷分散を備えたマルチリージョン/マルチクラウド展開

≤10 秒

手動または自動フェイルオーバー：

自動：≤3 分

AZ 間での同期書き込み；他のリージョン/クラウドへの非同期レプリケーション

リージョンレベルの障害

AZs: ≥3

Regions: ≥2

99.99%

高

📘Notes

Cross-region HA は 2025 年 11 月に利用可能になる予定です。

Disaster Recovery (DR) Tiers​

Tier

Description

RPO

Restore Speed

Backup Strategy

Use Case

Additional Cost

Local Backup

同一リージョンのオブジェクトストレージ；定期的なフルバックアップ

毎時

数分～数時間

フルバックアップ

誤削除、論理エラーからの復旧

低

Cross-Region Backup

異なるリージョンにバックアップデータを保存；地域的な災害から保護

毎時

数分～数時間

リージョン/クラウド間でレプリケートされるフルバックアップ

地域的な災害、コンプライアンス要件

中

Quick Selection Guide​

Business Tiering & Resilience Recommendations​

Tier 1 – Mission-Critical Workloads​

  • Characteristics: 24 時間 365 日稼働；数分のダウンタイムでも多大な損失が発生；極めて高いビジネス価値

  • Recommended: Cross-region HA + Enterprise Multi-Replica + 継続的データ保護

  • Targets: RPO = 0 秒、RTO < 30 秒、クロスクラウド/リージョン DR

  • Expected Cost: 高

Tier 2 – Important Business Systems​

  • Characteristics: 24 時間 365 日稼働；高い安定性が必要

  • Recommended: Enterprise Multi-Replica + Cross-region Backup

  • Targets: RPO = 0 秒、RTO < 30 秒

  • Expected Cost: 中～高

Tier 3 – 一般 アプリケーション​

  • Characteristics: 営業時間中に稼働；コスト重視；ある程度の復旧時間を許容

  • Recommended: Enterprise + Local Backup

  • Targets: RPO = 0 秒、RTO < 3 分

  • Expected Cost: 低～中

Tier 4 – Non-Critical Workloads​

  • Characteristics: 必須ではないシステム；コスト重視；計画されたメンテナンスウィンドウを許容

  • Recommended: Standard + Local Backup

  • Targets: RPO = 0 秒、RTO < 3 分

  • Expected Cost: 低～中

コスト最適化 Decision Matrix​

Business Impact

データ Value

Compliance Requirement

Recommended ソリューション

Cost Level

極めて高い

極めて高い

厳格

Cross-region HA + 完全な DR

高

高い

高い

適度

Enterprise Multi-Replica + Cross-region Backup

中～高

中

中

基本

Enterprise + Local Backup

中

低

低

なし

Standard + 基本バックアップ

低

Frequently Asked Questions (FAQ)​

Q1: Standard プランと Enterprise プランはどのようにして高可用性を実現していますか？

アーキテクチャ設計

Zilliz Cloud は、計算とストレージを分離したアーキテクチャを採用しており、以下の 3 つのデータタイプを扱います：

  • Metadata: etcd に保存（3 レプリカ、RAFT プロトコル）

  • Log データ: 独自技術の Woodpecker に保存（Quorum プロトコル）

  • Raw & Index データ: オブジェクトストレージに保存され、クラウドストレージ本来の HA を継承

計算ノードのHA

  • Kubernetes によって管理され、自動スケジューリングを実施

  • 単一ノードまたは単一 AZ の障害发生时、Pod は自動的に再生成

  • コーディネーター がセグメントを他の QueryNodes に再割り当て

  • インデックスとデータはストレージから再読み込みされ、復旧時間は 1 分未満

コスト最適化

  • 複数の永続レプリカ と 動的なインメモリ読み込み を活用

    • 複数のインメモリレプリカを維持することによるコスト急増を回避

    • DR アーキテクチャを簡素化

    • ログおよびオブジェクトストレージの帯域幅を活用し、より高速な復旧を実現

Q2: マルチレプリカメカニズムはどのように動作しますか？

コアメカニズム

  • Shard Level: 複数の StreamNodes が同じシャードをプライマリ/スタンバイ役割で読み込み

  • Segment Level: 複数の QueryNodes が同じセグメントを読み込み；データは単一コピーとして永続化

読み書き分離

  • Writes: プライマリ StreamNode が処理

  • Reads: いずれかのスタンバイ StreamNode または QueryNode が対応

主な利点

  • Fast フェイルオーバー: プロキシ がトラフィックを自動的にスタンバイノードへリダイレクト

  • Higher QPS: 複数のインメモリレプリカにより読み込みスループットが向上

  • Smooth Upgrades: ローリングアップデートによりサービスの揺らぎを軽減し、安定性を向上

Q3: Global データベース はどのようにしてクロスリージョンの高可用性を実現しますか？

CDC同期

  • Change データ Capture (CDC) により、DDL、DML、およびバルクインポート操作を同期

  • 典型的な同期レイテンシは 10 秒未満

  • 非常に低い RPO でクロスリージョン/クロスクラウド DR を実現

データ書き込み戦略

  • 同一リージョン内の複数の AZ にわたってデータを同期書き込み

  • 書き込みレイテンシは AZ 間レベル

  • 極端なフェイルオーバーシナリオでも、データ損失は 10 秒未満

📘Notes

2026 年のロードマップ： クロスリージョン Woodpecker により RPO = 0 を実現

フェイルオーバー Modes

  • Manual: OpenAPI または Web コンソール経由

  • Automatic: Zilliz ヘルスチェックサービスが障害を検出し、1～3 分でフェイルオーバーを完了

Access Patterns

Mode

Characteristics

Use Case

Active-Standby DR

プライマリが読み書きを担当；スタンバイはフェイルオーバー時のみ活性化

標準的なディザスタリカバリ

Active-Active (Multi-Read)

プライマリが書き込み；複数のリージョンが読み込みを提供（最寄リージョン読み込み）

グローバルな読み込み重視・書き込み少量のワークロード

Multi-Primary (2026 年予定)

両リージョンが書き込みを受け付け；ユーザーはデータ競合を回避する必要あり

セルベースまたはシャード化された展開

最新の機能アップデートや技術サポートについては、Zilliz Cloud サポート までお問い合わせください。