Azure App Service の信頼性

この記事では、Azure App Service の信頼性サポートについて説明し、可用性ゾーンによるリージョン内の回復性と、リージョン間のディザスター リカバリーおよび事業継続の両方を取り上げます。 Azure における信頼性の原則の詳細については、Azure の信頼性に関するページを参照してください。

Azure App Service は、Web アプリケーション、REST API、モバイル バックエンドをホストするための HTTP ベースのサービスであり、次のような Microsoft Azure の機能をアプリケーションに追加します。

• セキュリティ
• 負荷分散
• 自動スケール
• 管理の自動化

アプリケーションのワークロードの信頼性と回復性を Azure App Service によって強化する方法については、「App Service を使用する理由」を参照してください。

可用性ゾーンのサポート

Azure 可用性ゾーンとは、各 Azure リージョン内にある、3 つ以上に物理的に分離されたデータセンターのグループです。 各ゾーン内のデータセンターには、独立した電源、冷却手段、ネットワーク インフラストラクチャが備わっています。 ローカル ゾーンの障害が発生した場合、可用性ゾーンは、1 つのゾーンが影響を受けたときに、リージョンのサービス、容量、高可用性が残りの 2 つのゾーンによってサポートされるように設計されています。

障害の範囲は、ソフトウェアやハードウェアの障害から、地震、水害、火災などの事象に至る可能性があります。 Azure サービスの冗長と論理的な分離により、障害に対するトレランスが実現されます。 Azure の可用性ゾーンの詳細については、リージョンと可用性ゾーンに関する記事を参照してください。

Azure の可用性ゾーン対応サービスは、適切なレベルの信頼性と柔軟性を提供するように設計されています。 それらは 2 つの方法で構成できます。 それらは、ゾーン間の自動レプリケーションによるゾーン冗長、またはインスタンスを特定のゾーンにピン留めするゾーンベースのいずれかになります。 これらのアプローチを組み合わせることもできます。 ゾーン ベースとゾーン冗長のアーキテクチャを比較した詳細については、「可用性ゾーンとリージョンの使用に関する推奨事項」を参照してください。

Azure App Service を可用性ゾーン (AZ) にデプロイして、ビジネス クリティカルなワークロードの回復性と信頼性を実現するのに役立てることができます。 このアーキテクチャは、ゾーン冗長とも呼ばれます。

App Service をゾーン冗長として構成すると、プラットフォームによって、選んだリージョン内の 3 つのゾーンに Azure App Service プランのインスタンスが自動的に分散されます。

ゾーン冗長デプロイでのインスタンスの分散は、アプリのスケールインとスケールアウトであっても、次のルール内で決定されます。

• App Service プランの最小インスタンス数は 3 です。
• 3 を超える容量を指定し、インスタンスの数が 3 で割り切れる場合は、インスタンスが均等に分散されます。
• 3*N を超えたインスタンス数は、残りの 1 つまたは 2 つのゾーンに分散されます。

可用性ゾーンのサポートは、App Service プランの特性の 1 つです。 App Service プランは、マネージド マルチテナント環境または専用環境で、App Service Environment v3 を使用して作成できます。 App Service Environment v3 の詳細については、App Service Environment v3 の概要に関するページを参照してください。

ゾーン冗長として構成されていない App Services の場合、VM インスタンスはゾーン回復性がなく、そのリージョン内のゾーンで障害発生時にダウンタイムが発生する可能性があります。

エンタープライズ デプロイ アーキテクチャの詳細については、「App Services Environment を使用した高可用性エンタープライズ デプロイ」を参照してください。

前提条件

可用性ゾーンを有効にするための現在の要件と制限は次のとおりです。

• Windows と Linux はどちらもサポートされています。

• 可用性ゾーンは、新しい App Service 占有領域でのみサポートされます。 使用しているのがサポートされているリージョンのいずれかであっても、ご利用のリソース グループで可用性ゾーンがサポートされていない場合はエラーが発生します。 ご利用のワークロードが、可用性ゾーンをサポートしているスタンプに確実に配置されるようにするには、新しいリソース グループ、App Service プラン、および App Service を作成することが必要になる場合があります。

• App Services プランは、可用性ゾーンをサポートする次のいずれかのプランである必要があります。

  • App Service Premium v2 または Premium v3 プランを使用するマルチテナント環境。
  • Isolated v2 App Service プランと合わせて使用される、App Service Environment v3 を使用する専用環境。

• 専用環境の場合、App Service Environment は v3 である必要があります。

  重要

  App Service Environment v2 および v1 は 2024 年 8 月 31 日に廃止される予定です。 App Service Environment v3 の方が使いやすく、より強力なインフラストラクチャ上で実行されます。 App Service Environment v3 について詳しくは、「App Service Environment の概要」を参照してください。 現在 App Service Environment v2 または v1 を使用し、v3 にアップグレードしたい場合は、この記事の手順に従って新しいバージョンに移行ください。

• 最小インスタンス数である 3 つのゾーンが適用されます。 インスタンス数として 3 未満を指定すると、この最小数がプラットフォームによってバックグラウンドで強制されます。

• 可用性ゾーンを指定できるのは、新しい App Service プランを作成するときのみです。 既存の App Service プランは、可用性ゾーンを使用するように変換できません。

• 次のリージョンで、マルチテナント環境で実行されている Azure App Services がサポートされています。

  • オーストラリア東部
  • ブラジル南部
  • カナダ中部
  • インド中部
  • 米国中部
  • 東アジア
  • 米国東部
  • 米国東部 2
  • フランス中部
  • ドイツ中西部
  • イスラエル中部
  • イタリア北部
  • 東日本
  • 韓国中部
  • メキシコ中部
  • 北ヨーロッパ
  • ノルウェー東部
  • ポーランド中部
  • カタール中部
  • 南アフリカ北部
  • 米国中南部
  • 東南アジア
  • スペイン中部
  • スウェーデン中部
  • スイス北部
  • アラブ首長国連邦北部
  • 英国南部
  • 西ヨーロッパ
  • 米国西部 2
  • 米国西部 3
  • 21Vianet によって運営される Microsoft Azure - 中国北部 3
  • Azure Government - US Gov バージニア

• App Service Environment v3 の可用性ゾーンをサポートするリージョンについては、「リージョン」を参照してください。

可用性ゾーンが有効になっているリソースを作成する

マルチテナント ゾーン冗長 App Service をデプロイするには

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

"resources": [
  {
    "type": "Microsoft.Web/serverfarms",
    "apiVersion": "2018-02-01",
    "name": "your-appserviceplan-name-here",
    "location": "West US 3",
    "sku": {
        "name": "P1v3",
        "tier": "PremiumV3",
        "size": "P1v3",
        "family": "Pv3",
        "capacity": 3
    },
    "kind": "app",
    "properties": {
        "zoneRedundant": true
    }
  }
]

専用環境を使用してゾーン冗長 App Service をデプロイする

Isolated v2 プランで App Service Environment v3 を作成する方法については、「App Service Environment を作成する」を参照してください。

トラブルシューティング

フォールト トレランス

可用性ゾーンの障害に備えるためには、サービスの容量を過剰にプロビジョニングして、ソリューションが容量の 1/3 の損失を許容し、ゾーン全体の障害発生時にパフォーマンスを低下させることなく機能し続けられるようにする必要があります。 プラットフォームによって VM が 3 つのゾーンに分散されていて、少なくとも 1 つのゾーンの障害に対応できる必要がある場合は、ピーク ワークロードのインスタンス数にゾーン数/(ゾーン数 -1)、つまり 3/2 をかけます。 たとえば、通常のピーク ワークロードに 4 つのインスタンスが必要な場合、6 つのインスタンスをプロビジョニングする必要があります: (2/3 * 6 インスタンス) = 4 インスタンス。

ゾーン ダウン エクスペリエンス

トラフィックは、使用可能なすべての App Service インスタンスにルーティングされます。 ゾーンがダウンした場合は、App Service プラットフォームによって、失われたインスタンスが検出され、新しい置換インスタンスの検索とトラフィックの拡散が必要に応じて自動的に試行されます。 自動スケーリングを構成済みで、さらに多くのインスタンスが必要と判断された場合は、自動スケーリングから App Service に対してインスタンス追加の要求も発行されます。 自動スケーリングの動作は App Service プラットフォームの動作に依存せず、自動スケーリング インスタンス数の指定が 3 の倍数である必要はありません。

可用性ゾーンが有効になっている App Service プランにデプロイされたアプリケーションは、同じリージョン内の他のゾーンで障害が発生しても、引き続きトラフィックを実行および提供します。 ただし、非実行時の動作 (App Service プランのスケーリング、アプリケーションの作成、アプリケーションの構成、およびアプリケーションの発行を含む) では、他の可用性ゾーンの障害から影響を受ける可能性があります。 App Service プランのゾーン冗長で確保されるのは、デプロイされたアプリケーションの継続的なアップタイムのみです。

App Service プラットフォームによってインスタンスがゾーン冗長 App Service プランに割り当てられると、基になる Azure Virtual Machine Scale Sets によって提供されるベスト エフォートのゾーン負荷分散が使用されます。 App Service プランの "バランスが取れる" のは、各ゾーンに、その App Service プランで使用される他のすべてのゾーンと同じ数の VM または +/- 1 個の VM がある場合です。

可用性ゾーンの移行

既存の App Service インスタンスまたは環境リソースを非可用性ゾーンのサポートから可用性ゾーンのサポートに移行することはできません。 可用性ゾーンのサポートを受けるためには、可用性ゾーンが有効になっているリソースを作成する必要があります。

価格

App Service Premium v2 または Premium v3 プランを使用するマルチテナント環境の場合、App Service プラン内に 3 つ以上のインスタンスがある限り、可用性ゾーンの有効化に関連する追加コストは発生しません。 ご利用の App Service プラン SKU、指定した容量、および自動スケーリング条件に基づいてスケーリングする任意のインスタンスに基づいて課金されます。 可用性ゾーンを有効にし、容量として 3 未満を指定した場合、プラットフォームによって最小インスタンス数の 3 が強制され、これらの 3 つのインスタンスに対して課金されます。 App Service Environment v3 の可用性ゾーンに関する価格モデルは異なります。 App Service Environment v3 の価格情報については、「価格」を参照してください。

リージョン間のディザスター リカバリーおよび事業継続

ディザスター リカバリー (DR) とは、ダウンタイムやデータ損失につながるような、影響の大きいイベント (自然災害やデプロイの失敗など) から復旧することです。 原因に関係なく、災害に対する最善の解決策は、明確に定義されテストされた DR プランと、DR を積極的にサポートするアプリケーション設計です。 ディザスター リカバリー計画の作成を検討する前に、「ディザスター リカバリー戦略の設計に関する推奨事項」を参照してください。

DR に関しては、Microsoft は共有責任モデルを使用します。 共有責任モデルでは、ベースライン インフラストラクチャとプラットフォーム サービスの可用性が Microsoft によって保証されます。 同時に、多くの Azure サービスでは、データのレプリケート、または障害が発生したリージョンから別の有効なリージョンにクロスレプリケートするフォールバックは、自動的には行われません。 それらのサービスについては、お客様がワークロードに適したディザスター リカバリー計画を設定する必要があります。 Azure PaaS (サービスとしてのプラットフォーム) オファリング上で実行されるほとんどのサービスには、DR をサポートするための機能とガイダンスが用意されており、お客様はサービス固有の機能を使って迅速な復旧をサポートでき、DR 計画の開発に役立ちます。

このセクションでは、App Service にデプロイされた Web アプリの一般的な戦略について説明します。

App Service で Web アプリを作成する場合は、リソースの作成時に Azure リージョンを選択すると、単一リージョン アプリになります。 災害時にリージョンが使用できなくなったとき、アプリケーションも使用できなくなります。 複数リージョンの地域アーキテクチャを使用して、セカンダリ Azure リージョン内に同じデプロイを作成すると、アプリケーションは単一リージョンの障害の影響を受けにくくなり、事業継続が保証されます。 リージョン全体のデータ レプリケーションを使用して、アプリケーションの最後の状態を回復できます。

IT の場合、事業継続プランは主に目標復旧時間 (RTO) と目標復旧時点 (RPO) によって推進されます。 RTO と RPO の詳細については、「復旧目標」を参照してください。

通常、RTO に関する SLA を維持することは、地域の災害に対して実用的ではないため、RPO のみに関するディザスター リカバリー戦略を設計するのが一般的です (つまり、中断を最小限に抑えることではなく、データの復旧に重点を置きます)。 ただし、Azure では、自動 geo フェールオーバー用に App Service をデプロイすることは実用的なだけでなく、明快にもなります。 これを使用すると、RTO と RPO の両方に対応して、アプリケーションの災害耐性をさらに向上させることができます。

目的の RTO および RPO メトリックに応じて、App Service マルチテナント環境と App Service 環境のどちらにも、一般的には 3 つのディザスター リカバリー アーキテクチャが使用されます。 各アーキテクチャについて次の表で説明します。

複数リージョンの地域でのディザスター リカバリー

アクティブ/アクティブまたはアクティブ/パッシブ アーキテクチャの Azure リージョン間で Web アプリのコンテンツと構成をレプリケートする方法は、App Service のバックアップと復元の使用など複数あります。 ただし、バックアップと復元によって作成されるのは特定の時点でのスナップショットであり、最終的にはリージョンをまたがる Web アプリのバージョン管理の課題が発生することになります。 バックアップおよび復元のガイダンスとディザスター リカバリーのガイダンスの比較については、次の表を参照してください。

バックアップと復元と、ディザスター リカバリーの比較

バックアップおよび復元の方法の制限を回避するには、両方の Azure リージョンにコードをデプロイするように CI/CD パイプラインを構成してください。 Azure Pipelines または GitHub Actions の使用を検討してください。 詳しくは、「Azure App Service への継続的デプロイ」をご覧ください。

停止の検出、通知、管理

• 災害時にタイムリーな通知を行うために、Web アプリの監視とアラートを設定することをお勧めします。 詳細については、「Application Insights 可用性テスト」を参照してください。

• Azure でアプリケーション リソースを管理するには、コードとしてのインフラストラクチャ (IaC) メカニズムを使用してください。 複数のリージョンにまたがる複雑なデプロイで、リージョンを別個に管理し、信頼性の高い方法でリージョン間の構成の同期を維持するには、予測可能でテスト可能で反復可能なプロセスが必要です。 Azure Resource Manager テンプレートや Terraform などの IaC ツールを検討してください。

ディザスター リカバリーと障害検出を設定する

複数リージョンの地域でディザスター リカバリーを準備する場合は、アクティブ/アクティブまたはアクティブ/パッシブ アーキテクチャのいずれかを使用できます。

アクティブ/アクティブ アーキテクチャ

アクティブ/アクティブ ディザスター リカバリー アーキテクチャでは、同じ Web アプリが 2 つの別個のリージョンにデプロイされ、Azure Front Door を使用して両方のアクティブなリージョンにトラフィックがルーティングされます。

このアーキテクチャ例では、次のようになります。

• 同じ App Service アプリが、価格レベルとインスタンス数を含む 2 つの別個のリージョンにデプロイされます。
• App Service アプリに直接の送られるパブリック トラフィックはブロックされます。
• Azure Front Door を使用して、両方のアクティブなリージョンにトラフィックがルーティングされます。
• 災害時は、リージョンの 1 つがオフラインになり、Azure Front Door はトラフィックをオンラインのままのリージョンのみにルーティングします。 このような geo フェールオーバー中の RTO は、ほぼゼロです。
• アプリケーション ファイルは、CI/CD ソリューションを使用して両方の Web アプリにデプロイする必要があります。 このようにすると、RPO が実質的にゼロになります。
• アプリケーションがファイル システムを積極的に変更する場合、RPO を最小限に抑える最善の方法は、Web アプリの "/home" コンテンツ共有に直接書き込まずに、マウントされた Azure Storage 共有にのみ書き込むことです。 次に、マウントされた共有に対して Azure Storage 冗長機能 (GZRS または GRS) を使用します。この RPO は約 15 分です。

App Service で Web アプリのアクティブ/アクティブ アーキテクチャを作成する手順の概要は次のとおりです。

1. 2 つの異なる Azure リージョンに 2 つの App Service プランを作成します。 2 つの App Serviceプランを同じように構成します。

2. Web アプリの 2 つのインスタンスを、各 App Serviceプランに 1 つ作成します。

3. 次を持つ Azure Front Door プロファイルを作成します。

   • エンドポイント。
   • それぞれ優先順位が 1 の 2 つの配信元グループ。 優先順位が等しいと、トラフィックを両方のリージョンに均等にルーティングする (したがって、アクティブ/アクティブ) ように Azure Front Door に通知されます。
   • 1 つのルート。

4. Web アプリへのネットワーク トラフィックを Azure Front Door インスタンスからのみに制限します。

5. データベース、ストレージ アカウント、認証プロバイダーなどの他のすべてのバックエンド Azure サービスを設定して構成します。

6. 継続的デプロイを使用して、両方の Web アプリにコードをデプロイします。

"アクティブ/パッシブ" アーキテクチャを設定する方法については、「チュートリアル: Azure App Service で高可用性のマルチリージョン アプリを作成する」を参照してください。 同じ手順に最小限の変更を加えると (Azure Front Door で配信元グループの両方の配信元の優先順位を "1" に設定する)、アクティブ/アクティブ アーキテクチャが得られます。

アクティブ/パッシブ アーキテクチャ

このディザスター リカバリー方法では、同じ Web アプリが 2 つの別個のリージョンにデプロイされ、Azure Front Door を使用して 1 つのリージョン ("アクティブな" リージョン) にのみトラフィックがルーティングされます。

このアーキテクチャ例では、次のようになります。

• 同じ App Service アプリが、2 つの異なるリージョンにデプロイされます。

• App Service アプリに直接の送られるパブリック トラフィックはブロックされます。

• Azure Front Door を使用して、プライマリ リージョンにトラフィックがルーティングされます。

• コストを節約するために、セカンダリ App Service プランは、少ないインスタンス数や、低い価格レベルで構成されています。 考えられる方法は 3 とおりあります。

  • 推奨: セカンダリ App Service プランの価格レベルはプライマリと同じに、インスタンスの数は同じか少なくします。 この方法では、2 つの App Service プランの機能と VM のサイズの両方でパリティが確保されます。 geo フェールオーバー中の RTO は、インスタンスのスケールアウト時間にのみ依存します。

  • やや推奨: セカンダリ App Service プランの価格レベルの種類は同じ (PremiumV3 など) ですが、VM のサイズは小さく、インスタンス数は少なくします。 たとえば、プライマリ リージョンを P3V3 レベル、セカンダリ リージョンを P1V3 レベルにすることが考えられます。 この方法では、2 つのApp Service プランの機能パリティは引き続き確保されますが、セカンダリ リージョンがアクティブなリージョンになったときにサイズ パリティが不足して、手動によるスケールアップが必要になる場合があります。 geo フェールオーバー中の RTO は、インスタンスのスケールアップとスケールアウトの両方の時間に依存します。

  • あまり推奨されない: セカンダリ App Service プランの価格レベルをプライマリとは別にし、インスタンスは少なくします。 たとえば、プライマリ リージョンを P3V3 レベル、セカンダリ リージョンを S1 レベルにすることが考えられます。 セカンダリ App Service プランに、アプリケーションを実行するために必要なすべての機能があることを確認してください。 2 つの機能の可用性が異なると、Web アプリの回復が遅れる可能性があります。 geo フェールオーバー中の RTO は、インスタンスのスケールアップとスケールアウトの両方の時間に依存します。

• アクティブなリージョンが非アクティブになった場合に備えて、セカンダリ リージョンに自動スケーリングを構成します。 アクティブ リージョンとパッシブ リージョンの両方に、同じ自動スケーリング ルールを設定することをお勧めします。

• 災害時は、プライマリ リージョンが非アクティブになり、セカンダリ リージョンがトラフィックの受信を開始して、アクティブなリージョンになります。

• セカンダリ リージョンがアクティブになると、ネットワーク負荷が事前構成済みの自動スケーリング ルールをトリガーして、セカンダリ Web アプリをスケールアウトします。

• アクティブなリージョンとして実行するために必要な機能がまだない場合は、セカンダリ リージョンの価格レベルを手動でスケールアップすることが必要な場合があります。 たとえば、自動スケーリングには Standard レベル以上が必要です。

• プライマリ リージョンが再びアクティブになると、Azure Front Door がトラフィックをプライマリ リージョンに送信するように自動的に戻し、アーキテクチャは前と同じアクティブ/パッシブに戻ります。

• アプリケーション ファイルは、CI/CD ソリューションを使用して両方の Web アプリにデプロイする必要があります。 このようにすると、RPO が実質的にゼロになります。

• アプリケーションがファイル システムを積極的に変更する場合、RPO を最小限に抑える最善の方法は、Web アプリの "/home" コンテンツ共有に直接書き込まずに、マウントされた Azure Storage 共有にのみ書き込むことです。 次に、マウントされた共有に対して Azure Storage 冗長機能 (GZRS または GRS) を使用します。この RPO は約 15 分です。

App Service で Web アプリのアクティブ/パッシブ アーキテクチャを作成する手順の概要は次のとおりです。

1. 2 つの異なる Azure リージョンに 2 つの App Service プランを作成します。 セカンダリ App Service プランは、前述のいずれかの方法を使用してプロビジョニングできます。
2. プライマリ リージョンが非アクティブになったときにプライマリと同じインスタンス数にスケーリングされるように、セカンダリ App Service プランの自動スケーリング ルールを構成します。
3. Web アプリの 2 つのインスタンスを、各 App Serviceプランに 1 つ作成します。
4. 次を持つ Azure Front Door プロファイルを作成します。
   • エンドポイント。
   • プライマリ リージョンの優先順位が 1 の 1 つの配信元グループ。
   • セカンダリ リージョンの優先順位が 2 の 2 番めの配信元グループ。 優先順位が異なると、オンラインのときはプライマリ リージョンを優先する (したがってアクティブ/パッシブ) ように Azure Front Door に通知されます。
   • 1 つのルート。
5. Web アプリへのネットワーク トラフィックを Azure Front Door インスタンスからのみに制限します。
6. データベース、ストレージ アカウント、認証プロバイダーなどの他のすべてのバックエンド Azure サービスを設定して構成します。
7. 継続的デプロイを使用して、両方の Web アプリにコードをデプロイします。

"アクティブ/パッシブ" アーキテクチャを設定する方法については、「チュートリアル: Azure App Service で高可用性のマルチリージョン アプリを作成する」を参照してください。

パッシブ/コールド アーキテクチャ

パッシブ/コールド アーキテクチャを使用すると、別のリージョンにある Azure Storage アカウントで、ご利用の Web アプリのバックアップが定期的に作成され、維持されます。

このアーキテクチャ例では、次のようになります。

• 1 つの Web アプリが単一のリージョンにデプロイされます。

• Web アプリは、同じリージョン内の Azure Storage アカウントに定期的にバックアップされます。

• バックアップのリージョン間レプリケーションは、Azure Storage アカウントのデータ冗長構成に依存します。 可能な場合、Azure Storage アカウントを GZRS として設定してください。 GZRS は、リージョン内の同期ゾーン冗長とセカンダリ リージョンでの非同期の両方を提供します。 GZRS が使用できない場合は、アカウントを GRS として構成してください。 GZRS と GRS はどちらも RPO が約 15 分です。

• ストレージ アカウントのプライマリ リージョンが使用できなくなったときにバックアップを取得できるようにするには、セカンダリ リージョンへの読み取り専用アクセスを有効にします (ストレージ アカウントをそれぞれ RA-GZRS または RA-GRS にします)。 geo 冗長性を利用するようにアプリケーションを設計する方法の詳細については、「geo 冗長性を使用して高可用性アプリケーションを設計する」を参照してください。

• Web アプリのリージョンでの災害時は、Azure Storage アカウントのバックアップを使用して、多くの場合、読み取りアクセス権でセカンダリ リージョンから、必要なすべての App Service依存リソースを手動でデプロイする必要があります。 RTO は、数時間または数日になる場合があります。

• RTO を最小限に抑えるために、Web アプリのバックアップを別の Azure リージョンに復元するために必要なすべての手順を概説する包括的なプレイブックを用意することを強くお勧めします。

App Service で Web アプリのパッシブ/コールド リージョンを作成する手順の概要は次のとおりです。

1. Web アプリと同じリージョンに Azure Storage アカウントを作成します。 [パフォーマンス レベル] に [Standard] を選択し、[冗長性] に [geo 冗長ストレージ (GRS)] または [geo ゾーン冗長ストレージ (GZRS)] を選択します。

2. RA-GRS または RA-GZRS (セカンダリ リージョンの読み取りアクセス権) を有効にします。

3. Web アプリのカスタム バックアップを構成します。 Web アプリのバックアップのスケジュール (時間単位など) を設定することもできます。

4. Web アプリのバックアップ ファイルがストレージ アカウントのセカンダリ リージョンから取得できることを確認します。

単一リージョンの地域でのディザスター リカバリー

Web アプリのリージョンに GZRS または GRS のストレージがない場合、あるいはリージョン ペアのどちらにも該当しない Azure リージョンに自分がいる場合は、ゾーン冗長ストレージ (ZRS) またはローカル冗長ストレージ (LRS) を使用して同様のアーキテクチャを作成する必要があります。 たとえば、次のようにストレージ アカウントのセカンダリ リージョンを手動で作成できます。

GRS や GZRS を使用せずにパッシブ/コールド リージョンを作成する手順の概要は次のとおりです。

1. Web アプリと同じリージョンに Azure Storage アカウントを作成します。 [パフォーマンス レベル] に [Standard] を選択し、[冗長性] に [ゾーン冗長ストレージ (ZRS)] を選択します。

2. Web アプリのカスタム バックアップを構成します。 Web アプリのバックアップのスケジュール (時間単位など) を設定することもできます。

3. Web アプリのバックアップ ファイルがストレージ アカウントのセカンダリ リージョンから取得できることを確認します。

4. 異なるリージョンに 2 つめの Azure Storage アカウントを作成します。 [パフォーマンス レベル] に [Standard] を選択し、[冗長性] に [ローカル冗長ストレージ (LRS)] を選択します。

5. AzCopy などのツールを使用して、カスタム バックアップ (Zip、XML、およびログ ファイル) をプライマリ リージョンからセカンダリ ストレージにレプリケートします。 次に例を示します。

   azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'
   

   PowerShell ワークフロー Runbook で Azure Automation を使用して、スケジュールに沿ってレプリケーション スクリプトを実行できます。 レプリケーション スケジュールが Web アプリのバックアップと同様のスケジュールに従うようにしてください。

次のステップ

• チュートリアル: Azure App Service で高可用性のマルチリージョン アプリを作成する
• Azure での信頼性