事業継続とディザスター リカバリー

組織およびエンタープライズ アプリケーション ワークロードには、目標復旧時間 (RTO) と回復ポイントの目標 (RPO) の要件があります。 効果的な事業継続とディザスター リカバリー (BCDR) の設計により、これらの要件を満たすプラットフォーム レベルの機能を提供できます。 BCDR 機能を設計するには、プラットフォームのディザスター リカバリー (DR) 要件をキャプチャします。

設計上の考慮事項

アプリケーション ワークロードの BCDR を設計する際には、次の要因を考慮してください。

  • アプリケーションとデータの可用性に関する要件:

    • 各ワークロードの RTO と RPO の要件。
    • アクティブ/アクティブおよびアクティブ/パッシブの可用性パターンに対するサポート。
  • サービスとしてのプラットフォーム (PaaS) サービス用のサービスとしての BCDR:

    • ネイティブ DR と高可用性 (HA) 機能のサポート。
    • PaaS サービスの geo レプリケーションと DR 機能。
  • フェールオーバーを目的としたマルチリージョン デプロイのサポート (パフォーマンス上の理由からコンポーネントは近接)。

  • 障害中に機能が低下したり、パフォーマンスが低下したりする場合のアプリケーション操作。

  • Availability Zones または可用性セットに対するワークロードの適合性:

    • ゾーン間のデータ共有と依存関係。
    • 可用性セットと比較した、更新ドメインに対する Availability Zones の影響。
    • 同時にメンテナンスできるワークロードの割合。
    • 特定の仮想マシン (VM) の最小在庫管理単位 (SKU) に関する Availability Zones のサポート。 たとえば、Azure Ultra Disk Storage には Availability Zones を使用する必要があります。
  • アプリケーションとデータの一貫性のあるバックアップ:

    • VM スナップショット。
    • Azure Backup Recovery Services コンテナー。
    • サブスクリプションによって、Recovery Services コンテナーの数と各コンテナーのサイズが制限されます。
  • フェールオーバーが発生した場合のネットワーク接続:

    • Azure ExpressRoute の帯域幅の容量計画。
    • リージョン、ゾーン、またはネットワークの停止時のトラフィック ルーティング。
  • 計画的および計画外のフェールオーバー:

    • フェールオーバーおよびフェールバック後の IP アドレスの整合性の要件と IP アドレスを維持する必要がある可能性。
    • エンジニアリング DevOps 機能のメンテナンス。
    • アプリケーション キー、証明書、シークレット用の Azure Key Vault DR。
  • データの保存場所:

    • データを国または地域の国境内に保持するかどうかを指定する、データの保存場所に関する国内/リージョンのガイダンスについて説明します。 このガイダンスは、リージョン間レプリケーションの設計に影響します。
    • 有効なセットと同じ地域内に存在する Azure リージョンは、リージョン間レプリケーションを使用して、税や法執行の要件などのデータの保存場所の要件を満たすのに役立ちます。 詳細については、Azure のリージョン間レプリケーションに関するページを参照してください。

設計の推奨事項

次の設計プラクティスでは、アプリケーション ワークロードに関して BCDR をサポートしています。

  • Azure 間の VM DR シナリオには Azure Site Recovery を利用します。

    Site Recovery ではリアルタイムのレプリケーションと自動復旧を使用して、リージョン間でワークロードをレプリケートします。 VM ワークロード用の組み込みプラットフォーム機能では、低い RPO および RTO の要件を満たせます。 Site Recovery を使用すると、運用環境のワークロードに影響を与えることなく、復旧訓練を実行できます。 また Azure Policy を使用して、レプリケーションを有効にしたり、VM の保護を監査したりすることもできます。

  • ネイティブ PaaS DR 機能を使用します。

    組み込みの PaaS 機能により、ワークロード アーキテクチャでのレプリケーションとフェールオーバーのための設計とデプロイの両方を簡単に自動化できるようになります。 サービス標準を定義する組織は、Azure Policy を通じてサービス構成を監査および適用することもできます。

  • Azure ネイティブのバックアップ機能を使用します。

    Azure Backup と PaaS ネイティブのバックアップ機能を使用すると、サード パーティのバックアップ ソフトウェアとインフラストラクチャの必要がなくなります。 他のネイティブ機能と同様に、Azure Policy でバックアップ構成を設定、監査、適用して、組織の要件に確実に準拠させることができます。

  • ExpressRoute 接続には、複数のリージョンとピアリングの場所を使用します。

    停止が Azure リージョンまたはピアリング プロバイダーの場所に影響を与える場合、ハイブリッド ネットワーク アーキテクチャが冗長になっていると、中断のないクロスプレミス接続を確保できます。

  • 運用ネットワークと DR ネットワークで重複する IP アドレス範囲を使用することは避けてください。

    IP アドレスが重複する運用ネットワークと DR ネットワークにはフェールオーバー プロセスが必要であり、アプリケーションのフェールオーバーが複雑化し、遅延するおそれがあります。 可能であれば、すべてのサイトへの同時接続を提供する BCDR ネットワーク アーキテクチャを計画します。