可用性ゾーンとは
多くの Azure リージョンには、リージョン内のデータセンターの分離されたグループである可用性ゾーンが用意されています。 それぞれの可用性ゾーンには、独立した電源、冷却装置、ネットワーク インフラストラクチャがあるため、あるゾーンで障害が発生しても、リージョン サービス、容量、高可用性が残りのゾーンでサポートされます。
可用性ゾーンは標準的には数キロメートルで区切られ、通常は 100 キロメートル以内です。 この距離は、高パフォーマンス ネットワーク経由で他の可用性ゾーンに低遅延で接続するのに十分近いということです。 ただし、ローカルの停止や天候の影響を複数のゾーンが受ける確率を下げる程度には遠い距離です。
データセンターの場所は、厳格な脆弱性リスク評価基準を使用して選択されます。 このプロセスでは、データセンター固有のすべての重大なリスクが特定され、可用性ゾーン間の共有リスクが考慮されます。
次の図は、Azure リージョンの例を示しています。 リージョン 1 および 2 は可用性ゾーンをサポートしており、リージョン 3 および 4 には可用性ゾーンがありません。
可用性ゾーンをサポートするリージョンについては、「可用性ゾーンがサポートされている Azure リージョン」をご覧ください。
可用性ゾーンのサポートの種類
Azure サービスでは、ゾーン冗長とゾーンという 2 種類の可用性ゾーンのサポートを提供できます。 各サービスでは、一方または両方の種類がサポートされる場合があります。 信頼性戦略を設計するときには、ワークロードの各サービスで可用性ゾーンがどのようにサポートされているかを必ず理解するようにしてください。
ゾーン冗長デプロイ: ゾーン冗長リソースは、複数の可用性ゾーン間で自動的にレプリケートまたは分散されます。 たとえば、ゾーン冗長データ サービスでは、1 つのゾーン内の障害がデータの可用性に影響を与えないように、複数のゾーンにまたがってデータをレプリケートします。 一部のサービスでは、リソースが使用する一連のゾーンをお客様が選択できますが、その他のサービスでは、Microsoft がゾーンを選択します。
Microsoft は、ゾーン冗長デプロイによって、ゾーン間での要求の分散と、ゾーン間でのデータのレプリケーションを管理します。 可用性ゾーンで障害が発生した場合、Microsoft は別のゾーンへのフェールオーバーを自動的に管理します。
ゾーン デプロイ: ゾーン リソースは、自分で選択した単一の可用性ゾーンにデプロイされます。 この方法には回復性の利点はありませんが、より厳しい待機時間またはパフォーマンス要件を満たすのに役立ちます。 たとえば、仮想マシン、マネージド ディスク、標準 IP アドレスは、同じゾーンにゾーン単位でデプロイできます。
ゾーン リソースの回復性を改善するには、リージョン内の複数の可用性ゾーンで個別のリソースを含むアーキテクチャを設計する必要がありますが、Microsoft がお客様のためにプロセスを管理することはありません。 1 つの可用性ゾーンで障害が発生した場合は、ユーザーが別のゾーンへのフェールオーバーを行います。
リソースをゾーン冗長に構成するか、異なる可用性ゾーンでゾーン リソースの複数のインスタンスを使用すると、リソースは "ゾーン回復性がある" とみなされます。つまり、単一の可用性ゾーンの停止に対する回復性があります。
一部のサービスでは、可用性ゾーンは使用するように構成するまで使用されません。 可用性ゾーンのサポート用にサービスを明示的に構成しない場合、それは "非ゾーン" または "リージョン" デプロイと呼ばれます。 この方法で構成されたリソースは、リージョン内の任意の可用性ゾーンに配置され、移動される可能性があります。 リージョン内の可用性ゾーンで障害が発生した場合、非ゾーン リソースが影響を受けるゾーン内にあり、ダウンタイムが発生する可能性があります。
重要
一部のサービスには、可用性ゾーンのサポートを受けるために満たさなければならない追加要件がある場合があります。 たとえば、特定のレベル、SKU、Azure リージョンのサブセットの可用性ゾーンのみがサポートされる場合があります。
可用性ゾーンのサポートのためのリソースの構成
各サービスには、可用性ゾーンのサポートを構成するための独自の方法があります。 各サービスが可用性ゾーンをサポートする方法と、そのサポートを構成する方法については、サービスごとの Azure 信頼性ガイドを参照してください。
物理ゾーンと可用性ゾーン
各データセンターは、物理ゾーンに割り当てられています。 物理ゾーンは Azure サブスクリプション内の論理ゾーンにマップされ、サブスクリプションによってマップの順序が異なる場合があります。 Azure サブスクリプションには、サブスクリプションの作成時に、このマッピングが自動的に割り当てられます。 このため、あるサブスクリプションのゾーン マッピングは、他のサブスクリプションでは異なる可能性があります。
たとえば、サブスクリプション A は物理ゾーン 1 を論理ゾーン 2 にマップしているのに、サブスクリプション B は物理ゾーン 1 を論理ゾーン 3 にマップしている場合があります。
サブスクリプションの論理ゾーンと物理ゾーンのマッピングを理解するには、List Locations Azure Resource Manager API を使用します。 API から情報を取得するために、Azure CLI または Azure PowerShell を使用できます。
複数のサブスクリプションにまたがる回復性のあるソリューションのゾーン マッピングを比較するには、専用の ARM API である checkZonePeers を使用します。
checkZonePeers API を使用するには、機能 "Microsoft.Resources/AvailabilityZonePeering" を有効にする必要があります。 機能を有効にする方法の詳細については、Azure サブスクリプションでの機能の登録に関する記事を参照してください。
az rest --method get \
--uri '/subscriptions/{subscriptionId}/locations?api-version=2022-12-01' \
--query 'value[?availabilityZoneMappings != `null`].{displayName: displayName, name: name, availabilityZoneMappings: availabilityZoneMappings}'
可用性ゾーンと Azure の更新情報
Microsoft は、リージョンごとに、Azure サービスへの更新を単一の可用性ゾーン内に一度にデプロイすることを目的としています。 このアプローチでは、更新処理中も他のゾーンでワークロードを引き続き実行できるため、更新がアクティブなワークロードに与える影響を軽減できます。 順番に適用されるゾーン更新を利用するには、ワークロードが複数のゾーンにわたって実行されるように既に構成されている必要があります。 Azure で更新をデプロイする方法の詳細については、「安全なデプロイ プラクティスの推進」を参照してください。
Note
Azure の更新情報ブログで報告されているように、Azure では、プライベート IP とパブリック IP のどちらを使用しているかに関係なく、可用性ゾーンをまたぐデータ転送に対して課金しません。 この変更により、Azure は、より回復力のある効率的なアプリケーションとソリューションを Azure で構築する顧客の取り組みをさらに促進し、サポートします
ゾーン間の待ち時間
各リージョン内では、可用性ゾーンは高パフォーマンス ネットワーク経由で接続されます。 Microsoft は、ラウンドトリップ待ち時間が約 2 ミリ秒未満のゾーン間通信を実現するように取り組んでいます。 低待ち時間により、リージョン内での高パフォーマンスの通信と、複数の可用性ゾーン間でのデータの同期レプリケーションが可能になります。
Note
ターゲットの待ち時間とは、ネットワーク リンクの待ち時間を指します。 使用する通信プロトコルと、特定のネットワーク フローに必要なネットワーク ホップによって、待ち時間は異なる場合があります。
ほとんどのワークロードでは、パフォーマンスに大きな影響を与えることなく、ソリューションのコンポーネントを可用性ゾーン間に分散できます。 ゾーン間の待ち時間に対する感受性が高いワークロードがある場合は、選択した可用性ゾーン間の待ち時間を実際のプロトコルと構成でテストすることが重要です。 ゾーン間トラフィックを減らすには、ゾーン デプロイを使用することもできますが、最適を求めるには、信頼性戦略計画で複数の可用性ゾーンを使用する必要があります。
可用性ゾーンのアーキテクチャに関するガイダンス
信頼性の高いワークロードを実現するには:
- 運用ワークロードは、それが含まれるリージョンが可用性ゾーンをサポートしている場合、複数の可用性ゾーンを使用するように構成される必要があります。
- ミッション クリティカルなワークロードの場合、マルチリージョンとマルチゾーンの両方を備えたソリューションを検討する必要があります。
ソリューション アーキテクチャにおけるリージョンと可用性ゾーンの使用方法の詳細については、「可用性ゾーンとリージョンを使用するための推奨事項」を参照してください。