Azure アプリケーションのバックアップとディザスター リカバリー

ディザスター リカバリーは、致命的な損失の発生時にアプリケーション機能を復元するプロセスです。

クラウドでは、障害が発生することを事前に確認します。 目標は、障害がまったく発生しないように努力することではなく、障害が発生した単一コンポーネントの影響を最小限に抑えることです。 テストは、これらの影響を最小限に抑える方法の 1 つです。 できる限りアプリケーションのテストを自動化します。ただし、その場合は失敗に備える必要があります。 障害が発生したときは、バックアップおよび復旧の計画を用意してあることが重要になります。

障害発生時の機能の制限に対する許容範囲に基づいて、アプリケーションごとに異なるビジネス上の意思決定を行います。 アプリケーションによっては、利用できない、利用できる機能が制限される、処理が遅れる、などの状態を許容できる場合もあります。 また、機能の制限が許容されないアプリケーションもあります。

重要なポイント

  • 重大な障害のシナリオに基づいて、定期的にディザスター リカバリー計画を作成し、テストします。
  • 機能が制限された状態でほとんどのアプリケーションを実行するようにディザスター リカバリー戦略を設計します。
  • アプリケーションのビジネス要件と状況に合わせて調整されたバックアップ戦略を設計します。
  • フェールオーバーとフェールバックの手順とプロセスを自動化します。
  • フェールオーバーとフェールバックのアプローチのテストと検証を少なくとも 1 回成功させます。

ディザスター リカバリー プラン

まずはリカバリー プランの作成から開始します。 プランは、完全にテストした後に完成と見なされます。 顧客向けに定義したサービス レベル アグリーメント (SLA) 内で機能を復元するために必要な人員、プロセス、およびアプリケーションを含めます。

ディザスター リカバリー プランを作成してテストする際には、次の推奨事項を考慮してください。

  • サポートへの連絡と問題のエスカレーションのプロセスを含めます。 この情報は、初めて復旧プロセスを実行する際に、長時間にわたるダウンタイムを回避するのに役立ちます。
  • アプリケーションの障害によるビジネスの影響を評価します。
  • ミッションクリティカルなアプリケーションに対応できる、複数のリージョンにわたるディザスター リカバリー アーキテクチャを選択します。
  • 自動化やテストも含めたディザスター リカバリー プランの特定のオーナーを指定します。
  • 特にすべての手動の手順について、プロセスを文書化します。
  • 可能な限りプロセスを自動化します。
  • すべての参照データとトランザクション データに対してバックアップ戦略を確立し、これらのバックアップの復元を定期的にテストします。
  • アプリケーションによって使用される Azure サービスのスタックに対して、アラートを設定します。
  • プランを実行する運用スタッフをトレーニングします。
  • プランを検証し改善するために、定期的な障害のシミュレーションを実行します。

Azure Site Recovery を使用して仮想マシン (VM) をレプリケートする場合は、完全に自動化されたリカバリー プランを作成して、アプリケーション全体をフェールオーバーします。

運用準備状況のテスト

セカンダリ リージョンへのフェールオーバーと、プライマリ リージョンへのフェールバックについて、運用準備状況のテストを実行します。 多くの Azure サービスでは、ディザスター リカバリー訓練のために手動フェールオーバーまたはテスト フェールオーバーをサポートしています。 その代わりに、Azure サービスをシャットダウンまたは削除することによって、模擬的なシステム停止状態を作り出すこともできます。

通常のアプリケーション ライフサイクルの一部として自動運用応答を頻繁にテストし、運用上の有効性を確認する必要があります。

フェールオーバーとフェールバックのテスト

フェールオーバーとフェールバックをテストして、お使いのアプリケーションの依存サービスがディザスター リカバリー中に同期的にバックアップされることを確認します。 システムおよび操作の変更はフェールオーバーおよびフォールバック機能に影響を与える可能性がありますが、その影響はメインのシステムで障害が発生するか、オーバーロードが発生するまで検出されない場合があります。 現実に発生した問題に対して使用する前に、フェールオーバー機能をテストします。 また、依存関係のあるサービスが正しい順序でフェールオーバーおよびフェールバックすることを確認します。

Azure Site Recovery を使用して VM をレプリケートしている場合は、ディザスター リカバリーの模擬訓練として定期的にフェールオーバーのテストを行い、実装しているレプリケーション計画が正しく機能することを確認します。 フェールオーバーのテストを行っても、実行中の VM レプリケーションや運用環境に影響はありません。 詳細については、「Azure へのディザスター リカバリー訓練を実行する」を参照してください。

依存サービスの停止

各依存サービスについて、サービス中断による影響、およびアプリケーションがどのように応答するかを理解する必要があります。 多くのサービスには、回復性と可用性をサポートする機能が含まれるため、各サービスを個別に評価することで、ディザスター リカバリー プランが向上する可能性があります。 たとえば、Azure Event Hubs では、セカンダリ名前空間へのフェールオーバーがサポートされています。

ネットワークの停止

Azure ネットワークの一部にアクセスできなくなると、アプリケーションやデータにもアクセスできなくなる場合があります。 このような状況では、機能を制限してほとんどのアプリケーションを実行するようにディザスター リカバリー戦略を設計することをお勧めします。

機能の制限を使用できない場合に残されているオプションは、アプリケーションのダウンタイムまたは代替リージョンへのフェールオーバーです。

機能制限のシナリオ:

  • Azure ネットワークが停止してアプリケーションからデータにアクセスできなくなっても、キャッシュ データを使用して、ローカルで、機能に制限のある状態で、アプリケーションを実行できます。
  • 接続が回復するまでは、代わりの保存場所にデータを保存できます。

復旧の自動化

障害が発生したときセカンダリ Azure リージョンにアプリケーションを復旧またはフェールオーバーするステップを定めて、システムが停止した場合にも、影響を小さく抑える効果的な方法で、可能ならば自動的に、応答できるようにしておく必要があります。 フェールオーバーを発生させた問題が解決したときに、アプリケーションをプライマリ リージョンにフェールバックするのに必要なプロセスをキャプチャするための、同じように体系化された手順も、存在する必要があります。

フェールオーバーの手順を自動化するときは、フェールオーバーのオーケストレーションに使うツールも、フェールオーバー計画の一部として考慮します。 たとえば、VM 上で実行されている Jenkins からフェールオーバーを実行すると、その仮想マシンが停止の一部である場合、問題が発生します。 Azure DevOps Projects はリージョンにもスコープが設定されています。

バックアップ戦略

リージョン間での分散コンピューティングを実装するには、多くの代替方法を利用できます。 これらの方法は、特定のビジネス要件とアプリケーション環境に合わせる必要があります。 大まかに言えば、方法は以下のカテゴリに分類できます。

  • 災害発生時の再デプロイ:この方法では、アプリケーションは災害時に一から再デプロイされます。 復旧時間を保証する必要のある重要なアプリケーション以外は、1 から再デプロイするのが適切です。

  • ウォーム スペア (アクティブ/パッシブ): 代替リージョンにセカンダリ ホステッド サービスを作成し、最低必要な容量を保証するためのロールをデプロイします。 ただし、このロールは運用環境のトラフィックを受信しません。 この方法は、リージョン間にトラフィックを分散するように設計されていないアプリケーションに有用です。

  • ホット スペア (アクティブ/アクティブ) :アプリケーションは複数のリージョンで運用負荷を受信するように設計されています。 各リージョンのクラウド サービスは、ディザスター リカバリーのために必要な容量よりも大きい容量で構成されている場合があります。 その代わりに、障害時およびフェールオーバー時に、必要に応じてクラウド サービスをスケールアウトする場合もあります。 この方法は、アプリケーションの設計に大きな投資が必要ですが、重要な利点があります。 たとえば、復旧時間が短いことが保証されていること、すべての復旧場所で連続してテストを実行できること、容量を有効に使用できることなどです。

リージョンの障害に備えた計画

Azure はリージョンと呼ばれる物理的および論理的な単位に分割されます。 リージョンは、ごく近くにある 1 つ以上のデータセンターで構成されます。 多くのリージョンとサービスでは、1 つのデータ センターでの障害に対する回復性を高めるために使用できる可用性ゾーンもサポートされています。 ソリューションの可用性を向上させるには、可用性ゾーンがあるリージョンを使用することをご検討ください。

ネットワーク障害などの原因によって、まれに、可用性ゾーンやリージョン全体の施設にアクセスできなくなる場合があります。 あるいは、自然災害などによって施設全体が消失することもあり得ます。 Azure には、複数のゾーンおよびリージョンに分散するアプリケーションを作成するための機能があります。 そのように分散することで、1 つのゾーンまたはリージョンの障害が他のゾーンまたはリージョンに影響を与える可能性を最小限に抑えることができます。

次のステップ

メインの記事に戻る: テスト