Azure 可用性ゾーンの移行ベースライン
この記事では、非可用性ゾーンから可用性ゾーンのサポートへの移行を目的として、可用性ゾーンに対するアプリケーションの準備状況を評価する方法について説明します。 ご利用のアプリケーションおよびリージョンの要件に沿って可用性ゾーンのサポートをどのように利用できるかを明確にするのに必要な手順について説明します。 可用性ゾーンと、これをサポートするリージョンの詳細については、「Azure リージョンと可用性ゾーンとは」を参照してください。
信頼性の高いワークロードを作成する場合は、次の可用性ゾーン構成のうち少なくとも 1 つを選択できます。
ゾーン ベース。 ゾーン構成では、自分で選択した特定の可用性ゾーンを使用します。
ゾーン冗長。 ゾーン冗長構成では、リソースをゾーン間で自動的に複製または分散します。
Azure では、ゾーンおよびゾーン冗長の 2 つの可用性ゾーン オプションに加えて、グローバル サービス (つまり、リージョンに関係なくグローバルに利用できる) も提供しています。 これらのサービスは、リージョン間で常に利用できるため、リージョンおよびゾーンのいずれの障害に対しても回復性があります。
可用性ゾーンをサポートする Azure サービスについては、「サービスとリージョンの可用性ゾーンのサポート」を参照してください。
Note
ご利用のリソースに対してゾーン構成 (ゾーンまたはゾーン冗長) を選択しない場合、リソースとそのサブコンポーネントは、ゾーン回復性がなくなり、該当するリージョンでゾーン障害が発生した場合にダウンする可能性があります。
可用性ゾーンのサポートへの移行に関する考慮事項
SLA と信頼性の両方の目標を達成する可用性ゾーンを使用して、信頼性の高い Azure アプリケーションを作成する方法はいくつか考えられます。 以下の手順に従えば、サービスの機能、データ所在地、コンプライアンス要件、待機時間などの技術的および規制上の考慮事項に基づいて、ニーズに合った適切なリージョンを選択することができます。
手順 1: 可用性ゾーンをサポートしている Azure リージョンであるかどうかを確認する
この最初の手順では、選択した Azure リージョンによって、可用性ゾーンと、アプリケーションに必要な Azure サービスとがサポートされていることを検証する必要があります。
選択したリージョンで可用性ゾーンがサポートされている場合は、可用性ゾーンのためのワークロードを構成することを強くお勧めします。 そのリージョンで可用性ゾーンがサポートされていない場合は、Azure Resource Mover ガイダンスを参照して、可用性ゾーンのサポートを提供しているリージョンに移行する必要があります。
Note
一部のサービスの場合、可用性ゾーンを構成できるのはデプロイ時に限られます。 既存のサービスに対して可用性ゾーンを含める場合は、再デプロイが必要になる場合があります。 サービス固有のドキュメントについては、「Microsoft Azure 製品とサービスの可用性ゾーン移行ガイダンスの概要」を参照してください。
手順 2: Azure リージョン内で製品および SKU の可用性を確認する
この手順では、選択した Azure リージョンの可用性ゾーン内で、必須の Azure サービスと SKU が使用可能であることを検証します。
リージョンでのサービスのサポートについては、「リージョン別の利用可能な製品」を参照してください。
Azure リージョンおよびゾーン別に使用可能な VM SKU の一覧を表示するには、「提供されている VM SKU の確認」を参照してください。
選択したリージョンでアプリケーションに必要なサービスと SKU がサポートされていない場合は、手順 1: Azure リージョンでの製品の可用性を確認するに戻って、アプリケーションに必要なサービスと SKU をサポートする新しいリージョンを見つける必要があります。 ワークロードは、ゾーン冗長性を使用して構成することを強くお勧めします。
Azure IaaS Virtual Machines のゾーンベースの高可用性を実現するには、Virtual Machine Scale Sets (VMSS) Flex を使用して、VM を複数の可用性ゾーンに分散します。
手順 3: アプリケーションの要件を検討する
この最後の手順では、アプリケーションの要件に基づいて、ご利用のアプリケーションに最も適した可用性ゾーンのサポートの種類を特定します。
可用性ゾーンの適切なデプロイを選択するのに役立つ 3 つの重要な質問を以下に示します。
アプリケーションに待機時間の影響を受けやすいコンポーネントが含まれていますか?
同じ Azure リージョン内の複数の Azure 可用性ゾーンは、高パフォーマンス ネットワークによって接続され、ラウンドトリップ待機時間は 2 ms 未満となります。
低待機時間が厳密な要件になっていない場合、高可用性を実現するには、ゾーン冗長デプロイを使用してワークロードを構成することをお勧めします。
ゲーム、エンジニアリング シミュレーション、高頻度取引 (HFT) など、物理的な近接性と低待機時間を必要とする重要なアプリケーション コンポーネントの場合は、ゾーン デプロイを構成することをお勧めします。 Virtual Machine Scale Sets Flex を使用すれば、ゾーン アライン コンピューティングと、ストレージ ディスク同士の接続を実現できます。
ご利用のアプリケーション コードでは、分散モデルを処理する準備ができていますか?
分散型マイクロサービス モデルの場合、アプリケーションによっては、ゾーン間でマイクロサービス同士の継続的なデータ交換が行われる可能性があります。 API を介したこの継続的なデータ交換は、パフォーマンスに影響を与える可能性があります。 パフォーマンスを向上させ、信頼性の高いアーキテクチャを維持するには、ゾーン デプロイを選択できます。
ゾーン デプロイを使用する場合は、次の手順を行う必要があります。
アーキテクチャ内で待機時間の影響を受けやすいリソースまたはサービスを特定します。
待機時間の影響を受けやすいリソースまたはサービスで、ゾーン デプロイをサポートしていることを確認します。
待機時間の影響を受けやすいリソースまたはサービスを同じゾーン内に併置します。 アーキテクチャ内の他のサービスは、引き続きゾーン冗長のままとすることができます。
待機時間の影響を受けやすいゾーン サービスを複数の可用性ゾーン間でレプリケートし、ゾーンの回復性を確保します。
標準またはグローバル ロード バランサーを使用して、複数のゾーン デプロイ間で負荷を分散します。
Azure サービスで可用性ゾーンがサポートされている場合は、ノードを複数のゾーンに分散することによるゾーン冗長性を使用して、アップタイム SLA を高め、ゾーンの停止に対する保護を強化することを強くお勧めします。
3 層アプリケーションの場合は、アプリケーション、ビジネス、データの各層について、またはそれらの状態 (ステートフルまたはステートレス) について理解した上で、ワークロードの種類に応じてベスト プラクティスおよびガイダンスに沿った設計を行うことが重要です。
次の例のような Azure 上の特殊なワークロードについては、それぞれのランディング ゾーン アーキテクチャのガイダンスおよびベスト プラクティスを参照してください。
SAP
Azure Virtual Desktop
Azure Kubernetes Service
Oracle
コンプライアンス、データ所在地、またはガバナンスの要件を理由に、同じ Azure リージョン内で事業継続とディザスター リカバリーを実現する必要がありますか?
リージョン ペアが存在しない場合に、同じリージョン内で事業継続とディザスター リカバリーを実現するには、ゾーン冗長性を使用してワークロードを構成することを強くお勧めします。 単一リージョン アプローチは、同じ Azure リージョン内でデータ所在地およびガバナンスの要件が厳格に設定されている特定の業界にも適用できます。 同じ Azure リージョン内の可用性ゾーン間で Azure 仮想マシンをレプリケート、フェールオーバー、およびフェールバックする方法については、「可用性ゾーン間で Azure VM のディザスター リカバリーを有効にする」を参照してください。
複数のリージョンが必要な場合、または Azure リージョンで可用性ゾーンがサポートされていない場合は、リージョン ペアを使用することをお勧めします。 リージョン ペアは約 100 マイル離れた距離にそれぞれ配置され、これにより、火災、洪水、地震、およびその他の自然または予期せぬ災害など、リージョン レベルの障害から影響範囲を保護することができます。 詳しくは、「Azure でのリージョン間レプリケーション: 事業継続とディザスター リカバリー」を参照してください。
Note
ビジネス面および技術面の要件を満たすには、ゾーン、ゾーン冗長、グローバルの各サービスの組み合わせを最適に機能させるというシナリオが考えられます。
他に考慮する点
アプリケーションの可用性と回復性をテストする方法については、アプリケーションの可用性と回復性のテストに関するページを参照してください。
リージョン内の各データセンターは、それぞれ物理ゾーンに割り当てられています。 物理ゾーンは、Azure サブスクリプション内の論理ゾーンにマップされています。 Azure サブスクリプションには、サブスクリプションの作成時に、このマッピングが自動的に割り当てられます。 専用の ARM REST API (listLocations) を使用し、API バージョンを 2022-12-01 に設定すると、ご利用のサブスクリプションにおける論理ゾーンから物理ゾーンへのマッピングを一覧表示できます。 この情報は、アプリケーションの重要なコンポーネントを、すべての物理ゾーンで利用できるとは限らない、戦略的サービスとして分類される Azure リソースと併置する必要がある場合に重要な情報となります。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示