ゾーン リソースとゾーンの回復性

Azure では、 ゾーン リソース は 1 つのゾーンにピン留めされたリソースです。 ゾーン リソースは単一の可用性ゾーン内にあるため、ゾーンの回復性はありません。 リソースを含むゾーンに問題がある場合、リソースでダウンタイムが発生する可能性があります。

一部の Azure サービスでは、ゾーン リソースを必要とするか、デプロイすることができます。 待機時間に関する考慮事項または特定のサービス要件により、リソースをゾーン別にデプロイすることを選択できます。 個々のリソースまたは関連リソースのセットを 1 つのゾーンにピン留めすることができます。

この記事では、ゾーン冗長リソースではなく、ゾーン単一リソースをデプロイすることを選択するシナリオについて説明します。 また、ソリューションがゾーンの停止に対する回復性を維持するために必要な考慮事項と責任についても説明します。

リソースのデプロイの種類

Azure では、一部のデプロイの種類のみがゾーンの回復性を提供します。 次の表では、3 つのリソースデプロイの種類を比較し、そのゾーンの回復性、ゾーン分散、構成オプション、および推奨事項について説明します。

可用性ゾーンとリソースのデプロイの詳細については、「 可用性ゾーン」を参照してください。

ゾーン冗長リソースとゾーン固有リソースを組み合わせたワークロード

多くのワークロードでは、ゾーン冗長リソースとゾーン リソースが組み合わせられます。 たとえば、ワークロードには、データベース層のゾーン仮想マシン (VM) のセット、Azure App Service でホストされているゾーン冗長 Web サーバー、およびデータベース VM にトラフィックを送信するためのゾーン冗長ロード バランサーが含まれる場合があります。

ワークロードでゾーナルリソースとゾーン冗長リソースを組み合わせる場合は、可用性ゾーンに問題がある場合の各リソースとソリューション全体がどのように動作するかを考慮してください。 通常、ゾーン冗長サービスは、データ損失を最小限に抑えたり、まったく失ったりせず、ゾーンの停止から自動的に復旧し、Microsoft はプロセス全体を管理します。 ゾーン リソースの場合は、自動フェールオーバーを構成するか、手動の復旧アクティビティを実行する必要があります。 ゾーンダウン のシナリオで各サービスがどのように動作するか、責任と Microsoft の責任を理解し、ゾーンダウン イベント中のサービスの正常性を監視するには、サービスの信頼性ガイドを参照してください。

ゾーン展開を使用する場合

ゾーン リソースは、明確なニーズがある場合にのみ使用します。 単一ゾーンデプロイの一般的な理由としては、リソースをゾーン内にする必要がある場合、特定のゾーンでのみサービスを使用できる場合、ワークロードがゾーン間の待機時間に対して非常に機密性が高い場合などがあります。

ゾーン デプロイを必要とするリソース

一部の Azure サービスではゾーン デプロイのみがサポートされ、ゾーン冗長デプロイは提供されません。

VM は ゾーン リソースです。 仮想マシン スケール セットを使用して、VM のセットを作成できます。 仮想マシン スケール セットはゾーンスパンにすることができます。つまり、セット内の VM は複数のゾーンに分散されます。 スケール セットは、多くの VM ベースのワークロードに対してゾーンの回復性を実現するための優れた方法です。

もう 1 つの例として、1 つのゾーンへのボリュームのデプロイをサポートする Azure NetApp Files があります。 このサービスでは、複数のゾーン ボリューム間でレプリケートする方法も提供されます。

一部のサービスには、特定のゾーンでのみ使用できるオプションが用意されています。 たとえば、高度なグラフィックス処理装置 (GPU) を使用する特定の VM の種類は、リージョン内の特定のゾーンでのみ使用できます。つまり、複数のゾーンにデプロイすることはできません。 必要な VM の種類をサポートするリージョンとゾーンを確認するには、次のリソースを使用します。

• 各リージョンで使用可能な VM の種類を確認するには、「リージョン 別に利用可能な製品」を参照してください。

• 特定のリージョンの各ゾーン内でサポートされている VM の種類とサイズを確認するには、「 VM SKU の可用性を確認する」を参照してください。

必要な VM の種類が、使用するリージョン内の単一のゾーンでのみ使用できる場合は、その VM のゾーンデプロイを検討し、ゾーンの停止に対して VM の回復性を確保する他の方法を見つけることができます。 ただし、引き続きソリューションの他の部分がゾーン回復性があることを確認する必要があります。

詳細については、 可用性ゾーンをサポートする Azure サービスに関するページを参照してください。

ゾーン間の待ち時間

待機時間に対する感度が非常に高いワークロードがある場合、サービスがゾーン冗長デプロイメントをサポートしている場合でも、ゾーン冗長リソースではなく、ゾーンのリソースを使用することができます。

待機時間の短いネットワークは可用性ゾーンを接続し、ゾーン間のラウンドトリップ待機時間は通常 2 ミリ秒未満です。 ほとんどのワークロードでは、ゾーン間の待機時間は問題になりません。 可用性ゾーン間でリソースを分散することの回復性の利点は、ゾーン間でトラフィックを送信する場合のパフォーマンスへの影響を最小限に抑えるよりも重要です。 ただし、一部のワークロードはゾーン間の待機時間に非常に敏感です。 これらのワークロードには、次のシナリオが含まれる場合があります。

• 従来のオンプレミス アプリケーション: 一部のレガシ ワークロードには、もともとオンプレミス環境用に設計されたアプリケーションを含めることができます。 これらのワークロードでは、データベースやその他のアプリケーションやサービスなどのコンポーネントは、同じホスト上または物理的に近い場所に併置されていることを前提としています。

• 非常に大規模な同期レプリケーション: ステートフル なアプリケーションとデータベースでは、 同期レプリケーションを使用して非常に多くの書き込みが実行される場合があります。 同期レプリケーションとは、書き込み操作が完了したと見なされる前に、データが複数の レプリカ に書き込まれることを意味します。 可用性ゾーン間でレプリカを分散すると回復性が向上しますが、同期レプリケーションを使用すると、ゾーン間の待機時間によってワークロードの書き込み待機時間が長くなる可能性があります。 この待機時間の増加は通常は重要ではありませんが、一部のアプリケーションの設計方法により、大規模に問題になる場合があります。

ゾーン間の待機時間がワークロードに影響していると思われる場合は、特定のワークロードに対して次の手順に従って、現実的な環境でその影響をテストします。

1. 許容されるパフォーマンス要件を定義します。 ゾーン間トラフィックでは待機時間が少なくなりますが、ほとんどのワークロードではごくわずかです。 許容されるパフォーマンスをあなたのワークロードに対して定義します。

2. 1 つの可用性ゾーン内でパフォーマンス テストを実行します。 ベースライン パフォーマンス メトリックのセットを確立します。

   Important

   アプリケーション、プロトコル、構成、Azure リージョンなど、ワークロードをテストします。 現実的な荷重を使用します。 ベンチマークと合成テストでは、ソリューションの実際の動作が示されないため、十分ではありません。

3. ゾーン間レプリケーションを有効にします。 使用するコンポーネントによっては、ゾーンの冗長性を有効にしたり、ゾーン間でレプリカを移動したりできます。

4. パフォーマンス テストを再実行します。 前に収集したのと同じメトリックを収集します。

5. パフォーマンスへの影響を要件と比較します。 要件とパフォーマンス データを使用して、待機時間とゾーンの停止に対する回復性のトレードオフに関する情報に基づいた決定を行います。

   ワークロードの待機時間が許容できないほど長いテストが示されている場合は、次のアクションを実行することを検討してください。

   • 別のゾーン セットを使用してみてください。 異なるゾーン間の待機時間は、互いに異なる物理的な距離を持つ可能性があるため、わずかな変動が発生する可能性があります。

     ヒント

     Azure サブスクリプション間でテストする場合は、 論理ゾーンから物理ゾーンへのマッピング を確認して、予想される物理ゾーンのセットをテストすることを確認します。

   • データ所在地やその他の要因に対する全体的なニーズを満たす別の Azure リージョンがある場合は、そのリージョンで複数のゾーンを使用してみてください。

   • アプリケーションを再設計して、必要なゾーン間通信を最小限に抑えることができるかどうかを検討します。 たとえば、複数の小規模なデータベース操作を 1 つの操作に統合できる場合があります。 この方法により、ワークロードへの待機時間の影響を軽減できます。

   これらのアクションのいずれも役に立たなかった場合は、ゾーン VM やその他のサポートされている Azure サービスを使用して、1 つの可用性ゾーン内で特定のワークロードまたはコンポーネントを実行することを検討してください。 その後、ゾーン障害に対して、ゾーンのコンポーネントを回復性のあるものにする責任を負います。 この記事の残りの部分を確認して、自分の責任と考慮すべきいくつかのアプローチを理解してください。

ゾーン展開の責任

ゾーン 内のリソースは、可用性ゾーンで停止が発生した場合にダウンタイムが発生するリスクがあります。 ゾーン レベルのリソースをデプロイするときは、ゾーン レベルの障害に対するワークロードの回復性を高める責任があります。

ゾーン リソースのゾーン回復性を高めるために、次の責任を考慮してください。

• 複数のリソースのデプロイと構成: 異なるゾーンまたはリージョンに個別のゾーン リソースを手動でデプロイします。 各リソース間で構成の整合性を維持する方法を決定します。 コードとしてのインフラストラクチャ (IaC) を使用すると、複数の同じリソースを迅速にデプロイできるため、ベスト プラクティスです。

• トラフィックのルーティングと分散: ロード バランサー コンポーネントを選択し、ゾーンの回復性を確保し、異なるゾーン内のリソース間でトラフィックを送信するように構成する必要があります。 通常、ルーティング ポリシー (アクティブ/アクティブやアクティブ/パッシブなど)、自動正常性チェック、フェールオーバー プロセスを構成します。 詳細については、「 負荷分散オプション」を参照してください。

• レプリケーションまたはデータ バックアップ: ステートフル リソースの場合は、格納するデータを保護し、複数のゾーンに安全に保持されるようにする必要があります。 一般的な方法は、別の可用性ゾーン内の別のサービス インスタンスへのレプリケーションを構成することです。 状況によっては、代わりにバックアップに依存する場合があります。 ただし、バックアップではゾーン障害時の復旧時間が長くなり、 目標復旧時間 (RTO) を高くする必要があります。 また、より多くのデータ損失が発生するため、より高い 目標復旧ポイント (RPO) が必要になります。

• ゾーン障害検出と応答プロセスの実装: ゾーン リソースの正常性を監視し、異常とマークする条件を定義し、別のゾーンまたはリージョンでの操作の復元などの応答アクションをトリガーする方法を決定する必要があります。

• ゾーン回復プロセス: ゾーンが復旧した後は、プライマリ ゾーン内のリソースへのフェールバックなど、必要な復旧アクションを実行する必要があります。

ゾーン展開の回復性に関する一般的なアプローチ

ゾーン リソースのゾーン回復性の達成に関する情報に基づいた意思決定を行うには、次の要因を考慮してください。

• ワークロード全体を確認します。 ゾーン冗長リソース、ゾーンリソース、および非領域リソースなど、各コンポーネントがゾーンダウンイベント中にどのように動作するかを理解します。 各サービスの信頼性ガイドを使用して、ゾーンダウン シナリオ中のサービスのしくみと、ゾーンダウン イベントのサービスの正常性を監視する方法について説明します。

• ゾーン障害時に許容されるデータ損失について説明します。 RPO は、許容できるデータ損失の量を指定します。

  多くの Azure ゾーン冗長リソースでは、ゾーン障害に対して RPO がゼロになります。つまり、データ損失は発生しません。 通常、すべての変更をゾーン間で同期的にレプリケートすることで、この RPO を実現します。

  ゾーン展開を計画するときは、ゾーンで障害が発生したときにワークロードの RPO 要件を満たすことができることを確認する必要があります。

• ゾーン障害時の許容されるダウンタイムについて説明します。 RTO は、許容できるダウンタイムの量を指定します。

  通常、Azure ゾーン冗長リソースは、ゾーン障害に対して非常に低い RTO を提供し、通常は数秒のダウンタイムしか必要としません。

  ゾーン展開を計画するときは、ワークロードの RTO 要件を満たすことができることを確認する必要があります。 RTO が低い場合は、自動検出と復旧プロセスに依存することが必要になる場合があります。 RTO が高いほど、応答プロセスの柔軟性が向上します。

• コストを理解する。 ゾーン リソースは通常、個別に課金されるため、複数のゾーン リソースをデプロイすると、リソース コストが増加する可能性があります。

回復性のためにゾーン展開を設計する

回復性のためにゾーン展開を設計するときは、可用性ゾーンを使用して 高可用性 と ディザスター リカバリーのどちらを実現するかを検討してください。 これらの概念の違いは、RTO と RPO の要件に基づいています。

RTO が低く、RPO 要件が低い場合は、可用性ゾーンを 高可用性 コンストラクトとして扱う必要があります。 ただし、RTO と RPO が高い場合は、可用性ゾーンを ディザスター リカバリー コンストラクトとして扱うことを選択できます。 詳細については、「 ビジネス継続性、高可用性、ディザスター リカバリー」を参照してください。 ワークロードレベルは、要件と必要なアクションを決定するのに役立ちます。

高可用性向けの設計

複数のゾーンに独自の高可用性アーキテクチャをデプロイすることを検討してください。 高可用性アーキテクチャでは、複数のゾーンにデプロイされているコンポーネント間で自動化された頻繁なデータ レプリケーションと、ゾーン障害が発生した場合にそれらのコンポーネント間の自動フェールオーバーが必要です。

ゾーン VM にデプロイする一部のアプリケーションでは、レプリカ対応など、組み込みの高可用性サポートが提供されます。 たとえば、Azure VM で SQL Server を使用する場合、 可用性グループ はトラフィック ルーティングとフェールオーバー機能を提供します。 同期レプリケーションと非同期レプリケーションのどちらを使用するかを選択できます。 詳細については、 Azure VM 上の SQL Server のビジネス継続性、高可用性、ディザスター リカバリーに関するページを参照してください。

ディザスター リカバリーの設計

ディザスター リカバリーは高可用性とは異なります。障害シナリオでは、ダウンタイムとデータ損失が大きくなる可能性があるためです。 RTO と RPO は通常、数時間以上で測定されます。

ディザスター リカバリー計画は、さまざまなシナリオに備え、自動化されたプロセスと手動プロセスを組み合わせて対応する方法を定義するのに役立ちます。

次のディザスター リカバリーアプローチは、ゾーン展開を計画するときに役立ちます。

• Azure Site Recovery のゾーン間ディザスター リカバリー: この方法は、異なるゾーン内の VM 間でディスク レベルの非同期レプリケーションが必要な場合に便利です。 詳細については、「 可用性ゾーン間で Azure VM のディザスター リカバリーを有効にする」を参照してください。

• Site Recovery リージョン間ディザスター リカバリー: Site Recovery では、リージョン間のディザスター リカバリーがサポートされ、非同期レプリケーションに依存します。 この方法では、プライマリ リージョン内の別のゾーンではなく、別の Azure リージョンのゾーンにフェールオーバーできます。 詳細については、「 Azure VM を別の Azure リージョンにレプリケートする」を参照してください。

• バックアップ ベースのディザスター リカバリー: ソリューションで高 RTO と高 RPO を許容できる場合は、ディザスター リカバリー戦略としてバックアップを使用することを検討してください。 ゾーンで障害が発生した場合は、バックアップを別のゾーンまたはリージョンに復元できます。 また、ソリューション内に他の Azure リソースを事前に作成するか、フェールオーバー プロセス中に作成するかを検討する必要があります。

  ゾーン アーキテクチャでは、多くの場合、それらのバックアップを格納およびレプリケートする責任があります。

  Azure Backup は、広く使用されているマネージド バックアップ サービスです。 ペアになっている Azure リージョン間で、ゾーン冗長バックアップと geo レプリケート バックアップがサポートされます。 Azure VM 上の SQL Server などの一部のアプリケーションには、組み込みのアプリケーション固有のバックアップ機能も含まれています。

次のステップ

• Azure Well-Architected Framework で可用性ゾーンとリージョンを使用するための推奨事項