データ耐障害性
Zilliz Cloudは、完全管理型ベクターデータベースサービスとして、エンタープライズグレードの**高可用性（HA）および災害復旧（DR）**機能を提供し、さまざまな障害シナリオ下でもミッションクリティカルなデータおよびサービスの継続的な可用性を確保します。
主要機能
-
高可用性（HA）：自動障害検出および迅速なフェイルオーバーメカニズムにより、ノード、可用性ゾーン（AZ）、またはリージョンレベルの停止中でもサービス運用を中断することなく維持します。
-
災害復旧（DR）：包括的なバックアップおよびリストア戦略により、重大なインシデント後の迅速なビジネス復旧を可能にします。
-
柔軟な耐障害性ティア：標準からエンタープライズグレードのクロスリージョン展開まで、ビジネスシナリオ全体にわたる多様なRPO/RTO要件を満たすように調整されています。
-
コスト最適化：ビジネス価値およびリスク許容度に基づいて最もコスト効果の高い耐障害性戦略を選択してください。
主要概念
主要指標
-
リカバリポイント目標（RPO）：時間で測定される最大許容データ損失。たとえば、RPOが5分の場合、障害発生時に最大5分間の最近のデータが失われる可能性があります。
-
リカバリタイム目標（RTO）：障害発生から完全なサービス復旧までの最大許容時間。これには、障害検出、フェイルオーバー意思決定、および実際の復旧が含まれます。
-
サービスレベル合意（SLA）：Zilliz Cloudのサービス可用性へのコミットメントは通常、パーセント単位で表されます（たとえば、99.95％のアップタイムは、月あたり21.6分を超えないダウンタイムを意味します）。
故障許容範囲
-
ノードレベルの故障許容：単一のコンピュートまたはストレージノードの故障
-
AZレベルの故障許容：AZ全体の停止（データセンター故障など）
-
リージョンレベルの故障許容：リージョン全体のサービス中断（自然災害など）
-
クラウドプロバイダーレベルの故障許容：単一クラウドベンダーからのリスクを軽減するためのマルチクラウド展開
耐障害性アーキテクチャティア
高可用性（HA）ティア
ティア | 説明 | RPO | RTO | 書き込みレイテンシ / 複製数スケジュール | 故障許容 | SLA | 相対的なコスト |
|---|---|---|---|---|---|---|---|
標準 | マルチレプリカメカニズムを持つシングルリージョン、シングルAZ展開 | 0秒 | ≤1分 | シングルAZ内での書き込み；WALがクォーラム経由で複製 | ノードレベルの故障 AZ：1 リージョン：1 | SLA保証なし | 低 |
エンタープライズ | 自動フェイルオーバー付きの3つのAZにまたがるシングルリージョン展開 | 0秒 | ≤1分 | AZ間書き込み；WALがクォーラム経由で複製 | AZレベルの故障 AZ：3 リージョン：1 | 99.95% | 中 |
エンタープライズマルチレプリカ | リージョン内でのアクティブ-アクティブマルチレプリカアーキテクチャ；高速フェイルオーバー付きの読み書き分離 | 0秒 | ≤10秒 | AZ間書き込み；WAL経由でのレプリカ間同期 | AZレベルの故障 AZ：3 リージョン：1 | 99.99% | 中〜高 |
クロスリージョンHA | グローバルロードバランシング付きのマルチリージョン/マルチクラウド展開 | ≤10秒 | 手動または自動フェイルオーバー： 自動：≤3分 | AZ間の同期書き込み；他のリージョン/クラウドへの非同期レプリケーション | リージョンレベルの故障 AZ：≥3 リージョン：≥2 | 99.99% | 高 |
クロスリージョンHAは2025年11月に利用可能になります。インクリメンタルバックアップは2025年12月に利用可能になります。
災害復旧（DR）ティア
ティア | 説明 | RPO | 復旧速度 | バックアップ戦略 | 使用例 | 追加コスト |
|---|---|---|---|---|---|---|
ローカルバックアップ | 同一リージョンのオブジェクトストレージ；スケジュールされた完全バックアップ | 時間単位 | 数分から数時間 | 完全バックアップ | 誤操作削除、論理エラー復旧 | 低 |
クロスリージョンバックアップ | 異なるリージョンに保存されたバックアップデータ；リージョン災害からの保護 | 時間単位 | 数分から数時間 | リージョン/クラウド間にわたる完全バックアップの複製 | リージョン災害、コンプライアンス要件 | 中 |
インクリメンタルバックアップ | リアルタイムインクリメンタルバックアップ；きめ細かい復旧ポイント | ≤1分 | 数分から数時間 | トランザクションログの継続的なキャプチャ | クリティカルワークロードのポイントインタイム復旧 | 中〜高 |
クイック選択ガイド
ビジネスティアリングおよび耐障害性推奨事項
ティア1 – ミッションクリティカルワークロード
-
特徴： 24時間365日運用；わずかなダウンタイムでも重大な損失が発生；極めて高いビジネス価値
-
推奨： クロスリージョンHA + エンタープライズマルチレプリカ + 継続的データ保護
-
目標： RPO = 0秒、RTO < 30秒、クロスクラウド/リージョンDR
-
予想コスト： 高
ティア2 – 重要なビジネスシステム
-
特徴： 24時間365日運用；高い安定性要求
-
推奨： エンタープライズマルチレプリカ + クロスリージョンバックアップ
-
目標： RPO = 0秒、RTO < 30秒
-
予想コスト： 中〜高
ティア3 – 一般アプリケーション
-
特徴： ビジネス時間中に運用；コストに敏感；ある程度の復旧時間を容認
-
推奨： エンタープライズ + ローカルバックアップ
-
目標： RPO = 0秒、RTO < 3分
-
予想コスト： 低〜中
ティア4 – 非クリティカルワークロード
-
特徴： 必須でないシステム；コストに敏感；スケジュールされたメンテナンスウィンドウを許容
-
推奨： 標準 + ローカルバックアップ
-
目標： RPO = 0秒、RTO < 3分
-
予想コスト： 低〜中
コスト最適化決定マトリックス
ビジネスへの影響 | データ価値 | コンプライアンス要件 | 推奨ソリューション | コストレベル |
|---|---|---|---|---|
極めて高い | 極めて高い | 厳格 | クロスリージョンHA + 完全DR | 高 |
高い | 高い | 中程度 | エンタープライズマルチレプリカ + クロスリージョンバックアップ | 中〜高 |
中 | 中 | 基本 | エンタープライズ + ローカルバックアップ | 中 |
低 | 低 | なし | 標準 + 基本バックアップ | 低 |
よくある質問（FAQ）
Q1: 標準プランおよびエンタープライズプランはどのようにして高可用性を実現していますか？
アーキテクチャ設計
Zilliz Cloudは、3つのデータタイプを持つコンピュート・ストレージ分離アーキテクチャを使用します：
-
メタデータ： etcdに保存（3つのレプリカ、RAFTプロトコル）
-
ログデータ： 独自のWoodpeckerに保存（クォーラムプロトコル）
-
Rawデータおよびインデックスデータ： オブジェクトストレージに保存、クラウドストレージのネイティブHAを継承
コンピュートノードHA
-
Kubernetesによって自動スケジューリングで管理
-
シングルノードまたはシングルAZの故障時にポッドが自動的に再生成
-
コーディネーターが他のQueryNodeにセグメントを再割り当て
-
インデックスおよびデータはストレージから再読み込みされる；復旧時間 < 1分
コスト最適化
-
複数永続レプリカ + 動的インメモリ読み込みを使用
-
複数のインメモリレプリカを維持することによるコスト爆発を回避
-
DRアーキテクチャを簡素化
-
ログおよびオブジェクトストレージ帯域幅を利用してより高速な復旧を実現
-
Q2: マルチレプリカメカニズムはどのように動作しますか？
コアメカニズム
-
シャードレベル： 複数のStreamNodeが主/待機の役割で同じシャードをロード
-
セグメントレベル： 複数のQueryNodeが同じセグメントをロード；データは単一コピーとして永続化
読み書き分離
-
書き込み： 主StreamNodeによって処理
-
読み取り： 任意の待機StreamNodeまたはQueryNodeによって提供
主な利点
-
高速フェイルオーバー： Proxyが自動的にトラフィックを待機ノードにリダイレクト
-
より高いQPS： 複数のインメモリレプリカが読み取りスループットを向上
-
スムーズなアップグレード： ローリングアップデートによりサービスのジッターを削減し、安定性を向上
Q3: グローバルデータベースはクロスリージョンの高可用性をどのように実現しますか？
CDC同期
-
変更データキャプチャ（CDC）がDDL、DML、およびバルクインポート操作を同期
-
通常の同期レイテンシ < 10秒
-
RPOが非常に低いクロスリージョン/クロスクラウドDRを有効化
データ書き込み戦略
-
同一リージョン内での複数AZへの同期書き込み
-
書き込みレイテンシはAZ間レベル
-
極端なフェイルオーバーシナリオでは、データ損失 < 10秒
2026年のロードマップ： クロスリージョンWoodpeckerでRPO = 0を実現
フェイルオーバーモード
-
手動： OpenAPIまたはWebコンソール経由
-
自動： Zillizのヘルスチェックサービスが障害を検出し、1〜3分以内にフェイルオーバーを完了
アクセスパターン
モード | 特徴 | 使用例 |
|---|---|---|
アクティブ-スタンバイDR | プライマリが読み書き処理；スタンバイはフェイルオーバー時のみ有効化 | 標準災害復旧 |
アクティブ-アクティブ（マルチリード） | プライマリ書き込み；複数リージョンが読み取りを提供（最寄りリージョン読み取り） | グローバル読み取り中心、低書き込みワークロード |
マルチプライマリ （2026年登場予定） | 両リージョンが書き込みを許可；ユーザーがデータ競合を回避する必要あり | セルベースまたはシャーディングされた展開 |
最新の機能更新または技術サポートについては、Zilliz Cloudサポートにお問い合わせください。