▮▮Coloprice
JA
EN EnglishRU РусскийUK УкраїнськаTH ไทยZH 中文FR FrançaisJA 日本語DE DeutschVI Tiếng ViệtID Bahasa Indonesia
見積もり依頼

ディザスタリカバリー

DRサイト選定

ディザスタリカバリーサイトは、共通の災害を避けるために十分に離れていて、かつ必要なレプリケーションモードに対応できるほど十分に近い必要があります。この2つの制約条件と候補市場に実在する施設が、ベンダー検討前の候補絞り込みを決定します。下記ツールは14市場間の測定ラウンドトリップタイムと1629施設カタログに基づいて、この3つをすべて検証します。

DRペアファインダー

プライマリー市場を選択してください。候補はラウンドトリップタイムでランク付けされ、各距離で対応するレプリケーションモードが表示されます。

DR候補RTT対応レプリケーション市場内の施設

RTT値はパブリッククラウドの地域間測定値です（Azure、cloudping.co）。ソースはレイテンシマトリックスに記載されています。コロケーション施設間の光ファイバールートは類似の経路に従います。RPOをこのペアに確定する前に、オペレーターと確認してください。

レプリケーション方式は物理によって決まる

ファイバー内の光は往復時間1ミリ秒あたり約100 kmの距離をカバーします。この単一の数値がアーキテクチャを決定します：同期レプリケーションはアプリケーションの書き込み予算内に往復遅延を納める必要があり、これが距離を約100 km以内に制限します。それより遠い距離はストレージレイヤーが何を約束していても非同期になります。

方式RTT予算RPOその意味
同期≤ ~10 msゼロすべての書き込みはアプリケーション処理進行前に両拠点で確認されます。トランザクションレイテンシーはラウンドトリップを含むため、距離がアプリケーションのコストになります。
ニアシンクロナス~10–25 ms秒書き込みは確認応答を緩和して継続的にストリーミングされます。フランクフルト–アムステルダムやシンガポール–クアラルンプールのような都市圏隣接ペアに最適な選択肢です。
非同期任意分DRサイトはレプリケーション間隔分遅延します。長距離での唯一の選択肢であり、ほとんどのワークロードにも適しています。

4つのDRパターン、正直な価格設定

コストはプライマリサイトの稼働コストのシェアとして表現されます。パターンがRTOを決定し、レプリケーションモードがRPOを決定し、その組み合わせが予算を決定します。ほとんどの環境はワークロード層によって異なるパターンを実行します。レベニューパスではアクティブ-アクティブ、1日待機が可能なワークロードではバックアップ-復元です。

パターンRPORTOプライマリに対するコスト仕組み
バックアップと復元時間～日日~5%バックアップをオフサイトに複製し、インフラはディザスタ発生時のみ構築。低コスト、低速復旧であり、復旧プロセスはテストされていない。
パイロットライト数分～数時間時間~10–20%コアデータを最小限のフットプリントにレプリケート。フェイルオーバーはスケールアップ。DR サイトではデータベース用に数ラックを常時運用し、計算リソースは必要に応じて追加。
ウォームスタンバイ秒～分分～時間~30–50%本番環境の縮小版を常時稼働。フェイルオーバーは昇格であり、新規構築ではない。
アクティブ-アクティブ≈ ゼロ≈ ゼロ100%+両サイトがトラフィックを処理。片方の喪失は容量低下の事象であり、停止ではない。アプリケーション側がこれに対応して構築されている必要があり、既存システムへの後付けは再実装を意味する。

スタンバイ フットプリント コストは、ターゲット市場の Index rate における colocation cost estimator で算出してください。

実際に発生する障害

DR 計画は地震を想定しがちですが、incident log によると、実際の脅威はより身近にあります。電力系統の不安定性、UPS バッテリ火災、冷却システム故障、ネットワーク機器の障害などです。同じ電力網、同じ洪水危険区域、同じキャリアホテルの背後にある DR サイトは、これらのほぼすべてから保護しません。最近の事例：

  • 2026-09-01Google Cloud: network degradation in us-central1-b takes down 15 products for up to 4h08mus-central1-b (Council Bluffs, Iowa)
  • 2026-08-31Microsoft 365: authentication-configuration fault disrupts Exchange Online, Teams, SharePoint and Defender XDR for multiple daysGlobal (Microsoft 365 cloud services)
  • 2026-08-27Proton: total cooling failure at Frankfurt datacenter takes down Mail, VPN, Drive and Pass for 2h18mFrankfurt, Germany (Proton-operated datacenter)
  • 2026-08-20Google Cloud us-west1 (Oregon) region: multi-service degradation for about 3h40mus-west1 region (The Dalles, Oregon)
  • 2026-08-17GitHub outage: retry storm and Central US datacenter network saturation cause 7h47m disruption to Issues, PRs, Actions and CopilotCentral US datacenter region, with failover traffic routed to Northern Virginia

全事例ログ →

DR サイトのチェックリスト

  1. 本番環境とは異なる電力系統 — マーケティング宣伝ではなく、実際の変電所で確認する
  2. 本番環境の洪水危険区域および地震活動域の外
  3. 光ファイバ経路の多様性確保 — 2つのサイトはキャリアホテルまたはケーブルランディング施設を共有してはいけない
  4. RTT は測定値であり推定値ではない — また、選択したレプリケーション モードの予算内である
  5. 施設がコンプライアンス要件に応じた水準で認定されていることを確認 — 認定ディレクトリを参照
  6. 容量が契約上拡張可能であること — 実際の災害時にスケール不可能なDRサイトは飾りに過ぎない
  7. 契約上保証された対応時間を持つ遠隔作業員サービス — 広域災害時には現地に飛ぶ余裕はない
  8. 本番稼働前にエンドツーエンドフェイルオーバーテストを実施、その後は年1回実施 — 計画は実現能力ではない

よくある質問

プライマリとDRデータセンター間の距離はどの程度離れるべきか？

災害を共有しない程度に離れ、レプリケーションモードに対応可能な程度に近い必要があります。最小要件は独立した電力網、独立した洪水地帯、独立したキャリアパスです — 実際には50km以上。同期レプリケーションは約100km（ラウンドトリップ約10ms）が上限で、非同期レプリケーションであれば距離制限はありません。アジア太平洋地域の多くの規制当局は国外DR設置を要求しており、これにより非同期が必須になります。

RPOとRTOの違いは何か？

RPO（復旧時点目標）は許容可能なデータ損失量で、レプリケーションモードで決定されます。RTO（復旧時間目標）は許容可能なダウンタイム期間で、DRパターンで決定されます — バックアップ復元は数日での復旧、アクティブ-アクティブは秒単位での復旧です。コスト負荷はこれら両方に比例し、いずれか一方を1桁改善すると、DR予算全体がおおよそ2倍になります。

同期レプリケーションは国境を越えて機能するか？

隣接国間のみで可能です。シンガポール–クアラルンプール間（約8ms RTT）はサポート可能、フランクフルト–アムステルダム間（約11ms）は限界です。約25msを超えるいかなる距離も、ストレージベンダーのデータシートの記載如何を問わず非同期が必須です — 各ライトはラウンドトリップの遅延を被り、DRチームが気づく前にアプリケーションチームが体感します。

実際のデータセンター障害の主要原因は何か？

当社のインシデント記録は、電力事象（電力網外乱とUPS障害）、火災（リチウムイオン電池室が繰り返し関与）、冷却障害、ネットワーク機器故障が大多数を占め、広域自然災害は稀です。実務的な含意：同一都市圏・同一電力網上にあるDRサイトは、実際の施設レベルでの大多数のインシデントに対して防護を提供しません。一方、国を隔てたサイトはほぼ全てのインシデントから防護します。

パブリッククラウドはコロケーション環境のDRサイトとして有効か？

バックアップ復元およびパイロットライトパターンでは、多くの場合有効です — スタンバイ容量の費用は実行時にのみ発生し、これはクラウド課金モデルそのものです。陥穽はリターンパス上のエグレス費用と運用ギャップです。コロケーション資産をクラウドインフラに復旧することは、2つのデプロイメントターゲットの永続的な維持を意味します。レプリケーションではなく完全復元シナリオをテストしてください。

DRテストの実施頻度はどの程度か？

完全なフェイルオーバーは少なくとも年1回、コンポーネント復元は四半期ごと、重大なインフラ変更後に実施。未テストのDR計画は計画書であり、実現能力ではありません — インシデント記録は、障害が実テストでのみ真に検証される仕組み（電力切替、冷却再起動）に集中していることを示しています。

DR候補市場の選定中？

プライマリサイト、必要なRPO、適用規制をお知らせください。実行可能なDR市場の施設候補、ベンチマーク価格、および各オペレーターに確認すべき質問をお送りします。

1営業日以内に返信します。スパムや連絡先の転売はありません。