ゾーン関連のハードウェア障害、ネットワークの中断、自然災害に対するアプリケーションの回復性を高めるためには、ゾーンの回復性のためにAzureワークロードを設計することが重要です。 リージョン内の複数の可用性ゾーンにリソースを分散すると、重要なサービスに影響を与える単一のゾーン停止のリスクを軽減できます。
ワークロードの最初の計画とデプロイ中にゾーンの回復性に対処するのがベスト プラクティスですが、既存の回復性のないワークロードをゾーン回復性のある構成に変換するのが一般的です。 一般に、既存のワークロードに対してゾーンの回復性を有効にする処理は簡単であり、Microsoft は引き続きプロセスを簡略化します。 ただし、ワークロードを変更すると、リスクが発生する可能性があります。 関連するリスクを理解したら、それらのワークロード内のどのワークロードとサービスがビジネスにとって最も重要であるかを評価して優先順位を付け、最も影響の大きいリソースにゾーンの回復性を最初に適用できるようになります。
この記事では、Azure ワークロードでゾーンの回復性を有効にするための主な考慮事項について説明します。 また、より回復性の高いアーキテクチャへの移行を計画し、実装するためにも役立ちます。
ヒント
現在ワークロードを設計中の場合、または現在のワークロードの設計レビューを計画している場合は、Azure Well-Architected Framework (WAF) の冗長性を設計するための
ゾーン回復性とは
Azure サービスは、次の 2 つの主な方法で可用性ゾーンの停止に対する回復性を高めることができます。
ゾーン冗長サービス: 多くのAzure サービスはゾーン冗長をサポートします。 これらのサービスは、自動的に可用性ゾーン間でデータをレプリケートし、着信要求を分散し、ゾーン障害時に別のゾーンにフェールオーバーします。 各サービスは、その特定のサービスに適した方法でこれらの機能をサポートします。 既定では一部のサービスはゾーン冗長ですが、他のサービスではゾーンの冗長性を構成する必要がある場合があります。
Zonal services: 一部のAzure サービスはゾーン型であり、特定の可用性ゾーンに固定できることを意味します。 ゾーン サービスを使用してゾーンの回復性を実現するには、複数の可用性ゾーンにサービスの個別のインスタンスをデプロイします。 トラフィックの分散、データのレプリケーション、インスタンス間のフェールオーバーの管理も必要になる場合があります。
一部のサービスは、ゾーン冗長構成またはゾーン構成のいずれかでデプロイできます。 ほとんどの場合、可能であればゾーン冗長サービスをデプロイすることをお勧めします。
詳細については、「可用性ゾーンのサポートの種類」を参照してください。
ゾーン有効化手順
次の手順を使用して、Azureワークロードを体系的に確認し、ゾーンの回復性に優先順位を付け、各コンポーネントのゾーンの回復性を有効にします。
[前提条件]
開始する前に、次の操作を行います。
各ワークロードを識別します。 ワークロードとは、定義されたビジネス成果を達成するために連携して機能するアプリケーション リソース、データ、サポート インフラストラクチャのコレクションを指します。 ワークロードとその定義方法の詳細については、Well-Architected フレームワークのワークロードに関する記事を参照してください。
各ワークロードのユーザー フローとシステム フローに優先順位を付けます。 ワークロードの重要なパスと依存関係を理解して、最初にゾーンの回復性を高めるコンポーネントを決定します。 重要なフロー分析を使用してワークフローに優先順位を付ける方法の詳細については、「 ゾーンの回復性のためのワークロードの優先順位付け」を参照してください。
各ワークロードとフローに重要度評価を割り当てます。 この評価は、潜在的な停止がビジネスに与える影響を理解し、ゾーンの回復性に優先順位を付けるワークロードに関する決定を導くのに役立ちます。 また、ワークロードを再構成する際に許容されるダウンタイムの量も考慮してください。
分類を使用して、重要度に基づいてワークロードを分類できます。 このアプローチにより、最も重要なサービスに注力することができます。
ワークロードを分類するには、次の例の分類法を検討してください。
ワークロードの種類 Description 中断の影響 ミッション クリティカル 高い信頼性、常時可用性、障害回復性、高い運用性が求められるクリティカル フローとクリティカル ワークロード 重要な機能が中断されると、即座に致命的なビジネス上の損害が発生したり、人命がリスクにさらされたりします。 ビジネスクリティカル 重要なビジネス機能を運用する必要不可欠なフローとワークロード 中断は金銭的損失やブランドの毀損をもたらすリスクがあります。 ビジネスオペレーショナル ビジネス運用の効率化に貢献しますが、顧客への直接サービスには関与しません ある程度の中断を許容できます。 管理 ビジネス運用に直結しない社内の業務フローとワークロード 中断を許容できます。 重要度評価に従ってワークロードを分類する方法の詳細については、「各フローに重要度評価を割り当てる」を参照してください。
Azure リソースが存在するリージョンが可用性ゾーンをサポートしていることを確認します。 Azureリージョンの一覧を参照してください。 リージョンが可用性ゾーンをサポートしていない場合は、可用性ゾーンをサポートしているリージョンにリソースを移行し直すことを検討してください。 詳細については、「リソース グループ、サブスクリプション、またはリージョン全体のリソースAzure移動を参照してください。
手順 1: ゾーンの回復性のためにAzure サービスに優先順位を付ける
ビジネスにとって最も重要なワークロード フローを決定したら、それらのフローが依存するAzure サービスに集中できます。 一部のAzure サービスは、他のサービスよりもアプリケーションにとって重要です。 これらのサービスに優先順位を付けて、ゾーン障害が発生した場合にアプリケーションが使用可能で回復性を維持できるようにします。
ワークロードに対する重要度に基づいてサービス グループAzure優先順位を付けるには、次のガイダンスを使用します。 ゾーンの回復性に関するサービスの優先順位を決定するときは、特定のアプリケーション アーキテクチャとビジネス要件を考慮してください。
ネットワーク サービスから始めます。 ワークロードはネットワーク サービスを共有する傾向があるため、これらのサービスの回復性が向上すると、複数のワークロードの回復性が一度に向上する可能性があります。
多くのコアネットワークサービスは自動的にゾーン冗長ですが、Azure ExpressRoute Gateway、Azure VPN Gateway、Azure Application Gateway、Azure Load Balancer、Azure Firewallのようなコンポーネントに注力するべきです。
運用データ ストレージの回復性を向上させます。 運用データ ストアには、複数のワークロードが頻繁に使用する貴重なデータが含まれているため、それらのデータ ストアの可用性を向上すると、多くのワークロードに役立ちます。
運用データ ストレージの回復性を確保するために、Azure SQL Database、Azure SQL Managed Instance、Azure Storage、Azure Data Lake Storage、Azure Cosmos DB、Azure PostgreSQL フレキシブル サーバー、Azure MySQL フレキシブル サーバー、および Azure マネージド Redis などのサービスに重点を置く。
コンピューティング サービスに優先順位を付けます。 多くの場合、これらのサービスはステートレスであるため、簡単にレプリケートしてゾーン間で分散できます。
コンピューティング サービスには、Azure 仮想マシン、Azure Virtual Machine Scale Sets、Azure Kubernetes Service (AKS)、Azure App Service、App Service Environment、Azure Functions、Azure Service Fabric、およびAzure Container Apps。
重要なフローで使用されるビジネス クリティカルなリソースの残りを確認します。 これらのリソースは、前に示したリソースほど重要ではない場合がありますが、アプリケーションの機能で引き続き役割を果たすので、ゾーンの回復性を考慮する必要があります。
ビジネス運用リソースの残りの部分を確認します。 ゾーンに回復性を持たせるかどうかについて、情報に基づいた意思決定を行います。 このレビューには、重要なワークロードとは直接関係しない可能性があるが、アプリケーションの全体的なパフォーマンスと信頼性に貢献するサービスが含まれています。
手順 2: ゾーン構成アプローチを評価する
ワークロードとAzure サービスに優先順位を付けた後、各サービスの可用性ゾーンのサポートを有効にするために必要なアプローチを特定し、ゾーンの回復性を構成するために何を行う必要があるかを理解します。
各Azure信頼性サービス ガイドでは、そのサービスのゾーンの回復性を有効にする方法について説明するセクションを提供します。 このセクションでは、各サービス ゾーンの回復性を高めるために必要な作業を理解し、それに応じて戦略を計画できるようにします。 特定のサービスの詳細については、Azure信頼性サービス ガイドを参照してください。
zone 構成テーブルを使用して、一般的なAzure サービスのアプローチをすばやく理解します。
Important
ワークロードにゾーン (または単一ゾーン) の構成でデプロイされたコンポーネントが含まれている場合は、ゾーンの停止に対してこれらのコンポーネントの回復性を確保することを計画します。 一般的な方法は、個別のインスタンスを別の可用性ゾーンにデプロイし、必要に応じて切り替える方法です。
手順 3: 待機時間をテストする
ワークロード ゾーンの回復性を高める場合は、可用性ゾーン間の待機時間を検討してください。 場合によっては、一部のレガシ システムでは、特にデータ層内で同期レプリケーションを有効にした場合に、ゾーン間トラフィックによって生じる少量の余分な待機時間を許容できない場合があります。 ゾーン間の待機時間がワークロードに影響する可能性があると思われる場合は、ゾーンの回復性を有効にする前と後にテストを実行します。 ゾーン間の待機時間がアプリケーションに与える影響と、ゾーン間の待機時間の問題を軽減する方法の詳細については、 ゾーン リソースとゾーンの回復性に関する記事を参照してください。
Azure サービスのゾーン構成アプローチ
各Azure サービスは、特定の種類の可用性ゾーンのサポートをサポートします。これは、サービスの意図された用途と内部アーキテクチャに基づいています。 可用性ゾーン (または 非ゾーン リソース) を使用するように構成されていないリソースがある場合は、可用性ゾーンのサポートを使用して再構成することをお勧めします。 各サービスの信頼性ガイドには、可用性ゾーンの構成手順に関するガイダンスまたはリンクが記載されています。
このセクションでは、さまざまな種類のゾーン構成アプローチと、各サービスがサポートするアプローチの概要について説明します。
Important
リソースで ゾーン冗長 を有効にすると、そのリソースはゾーン障害に対して自動的に回復性を持つ状態になります。 ゾーン構成を使用してリソースを特定の可用性ゾーンにピン留めする場合、リソースは自動的にゾーン冗長になりません。 ゾーン障害に対する回復性を高める必要があります。 ゾーン ベースのサービスの場合、この記事は、ゾーンにピン留めすることの複雑さとコストを示しています。 ゾーンの回復性を実現するための追加の手順の詳細については、 サービスの信頼性ガイドを参照してください。
zone 構成テーブルには、多くのAzure サービスでサポートされているゾーン構成方法が一覧表示され、そのサービスの各信頼性ガイドへのリンクが含まれています。 信頼性ガイドでは、非ゾーン サービス リソースを構成して可用性ゾーンのサポートを有効にする方法について説明します。
次の表では、可用性ゾーンを有効にするために必要な作業量とダウンタイムのレベルなど、一般的なゾーン構成方法について説明します。 一部のサービスでは、動作の違いにより異なるアプローチが列挙されています。
| 方法 | Description | 一般的な作業レベル | ダウンタイムが必要になる場合があります |
|---|---|---|---|
| 常にゾーンの回復性を備えている | 可用性ゾーンを サポートするリージョンでは、サービスは既定でゾーン回復性があります。 アクションは必要ありません。 | None | いいえ |
| 有効化 | 設定でゾーン冗長性を有効にするなど、最小限の構成変更が必要です。 このプロセスは可用性には影響しませんが、コストやパフォーマンスへの影響を考慮してください。 | Low | いいえ |
| 変更 | 依存リソースの再デプロイやネットワーク設定の変更など、いくつかの構成変更が必要になる可能性があります。 | ミディアム | イエス |
| 再デプロイ | リソース全体、アプリケーション、サービスの再デプロイ、新しいサービスへのデータの移行など、重要な変更が必要です。 | High | イエス |
サービスの可用性ゾーンのサポートを有効にするコストについて説明します。 多くのサービスでは、可用性ゾーンを有効にしてもコストは追加されません。 ただし、一部のサービスでは、特定のレベル、特定の数の容量ユニット、またはその両方が必要です。 可用性ゾーンを使用する場合、他のサービスは異なる料金を請求します。 次のセクションの表に、各サービスの一般的なコストへの影響を示します。
注
この記事の情報は、可用性ゾーンのサポートを有効にする一般的なアプローチをまとめたものです。また、一般的なコストへの影響について概説します。 ただし、一部の要因は、特定のソリューションの動作に影響する可能性があります。 たとえば、一部のサービスは 常にゾーン回復性があると表示されますが、この指定は特定のリージョンまたはサービスの特定のレベルにのみ適用されます。 これらのテーブルを出発点として使用しますが、説明されている他のリソースを確認して、具体的な詳細を理解してください。
Azure サービスのゾーン構成アプローチ
次の表は、多くのAzure サービスの可用性ゾーンのサポートをまとめたものです。また、コストへの影響を含め、各サービスの可用性ゾーンのサポートを有効にする方法を示します。
| サービス | ゾーン冗長に対応 | ゾーン指定に対応 | 一般的なゾーン構成アプローチ | 一般的なコストへの影響 |
|---|---|---|---|---|
| Azure AI 検索 | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure API Management | はい | はい | 変更 | 必要な最小レベル |
| Azure App Configuration | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure App Service | はい | 有効化 | 必要な最小レベルとインスタンス数 | |
| Azure App Service - App Service Environment | はい | 有効化 | 必要な最小インスタンス数 | |
| Azure Application Gateway | はい | はい | 常にゾーンの回復性を備えている | N/A |
| Azure Backup | はい | 再デプロイ | 中程度のコスト増加 | |
| Azure Bastion | はい | はい | 再デプロイ | コストへの影響なし |
| Azure Batch | はい | 再デプロイ | 同じ数の仮想マシン (VM) に対するコストへの影響なし | |
| Azure Blob Storage | はい | 有効化 | 中程度のコスト増加 | |
| Azure Cache for Redis - Enterprise | はい | 再デプロイ | コストへの影響なし | |
| Azure Cache for Redis - Standard および Premium | はい | 有効化 | 必要な最小レベル | |
| Azure Container Apps | はい | 再デプロイ | 必要な最小レプリカ数 | |
| Azure Container Instances | はい | 再デプロイ | コストへの影響なし | |
| Azure Container Registry | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure Cosmos DB for NoSQL | はい | 変更 | 自動スケーリングまたは複数リージョンの書き込みを使用する場合はなし | |
| Azure Data Factory | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure Data Lake Storage | はい | 有効化 | 中程度のコスト増加 | |
| Azure Database for MySQL - フレキシブル サーバー | はい | 再デプロイ | プライマリおよび高可用性 (HA) インスタンスが必要 | |
| Azure Database for PostgreSQL - フレキシブル サーバー | はい | 有効化 | プライマリ インスタンスと HA インスタンスが必要 | |
| Azure Databricks | はい | 有効化 | 同じ数の VM に対するコストへの影響はありません。ストレージのコストを中程度に増やす | |
| Azure Disk Storage (マネージド ディスク) | はい | はい | 有効化 | 中程度のコスト増加 |
| Azure Elastic SAN | はい | 再デプロイ | 中程度のコスト増加 | |
| Azure Event Hubs: 専用レベル | はい | 常にゾーンの回復性を備えている | 必要な最小容量ユニット (CU) | |
| Azure Event Hubs: その他のすべてのレベル | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure ExpressRoute ゲートウェイ | はい | はい | 変更 | レベルによって異なります |
| Azure Files | はい | 有効化 | 中程度のコスト増加 | |
| Azure Firewall | はい | はい | デフォルトでゾーンのレジリエンスを備えた新しいファイアウォール 既存の非ゾーン ファイアウォール: 変更 (自動移行が進行中) |
コストへの影響なし |
| Azure Functions | はい | 再デプロイ | 必要な最小レベルとインスタンス数 | |
| Azure HDInsight | はい | 再デプロイ | 同じ数のノードに対するコストへの影響なし | |
| Azure IoT Hub | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure Key Vault | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure Kubernetes Service (AKS) | はい | 再デプロイ | コストへの影響なし | |
| Azure Load Balancer | はい | はい | 変更 | コストへの影響なし |
| Azure Logic Apps - 従量課金レベル | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure Logic Apps - Standard レベル | はい | 再デプロイ | 必要な最小レベルとインスタンス数 | |
| Azure Managed Grafana | はい | Redeploy | 中程度のコスト増加 | |
| Azure Managed Redis | はい | 有効化 | プライマリ インスタンスと HA インスタンスが必要 | |
| Azure Monitor: Log Analytics | はい | 常にゾーンの回復性を備えている | ||
| Azure NAT Gateway | はい | はい | 再デプロイ | コストへの影響なし |
| Azure NetApp Files | はい | 再デプロイ | レプリケーションの構成に依存 | |
| Azure Private Link service | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure Queue Storage | はい | 有効化 | 中程度のコスト増加 | |
| Azure Service Bus | はい | 常にゾーン回復性あり | N/A | |
| Azure Service Fabric | はい | はい | 再デプロイ | 同じ数の VM に対するコストへの影響なし |
| Azure Site Recovery | はい | 再デプロイ | Site Recoveryのコストへの影響なし、レプリカ ストレージの中程度のコスト増加 | |
| Azure SQL Database: 重要業務層 | はい | 有効化 | コストへの影響なし | |
| Azure SQL Database: 一般目的層 | はい | 有効化 | 中程度のコスト増加 | |
| Azure SQL Database: Hyperscale 層 | はい | 再デプロイ | 必要な最小レプリカ数 | |
| Azure SQL Database: Premium レベル | はい | 有効化 | コストへの影響なし | |
| Azure SQL Managed Instance | はい | 有効化 | 中程度のコスト増加 | |
| Azure Stream Analytics | はい | 常にゾーン回復性あり | N/A | |
| Azure Table Storage | はい | 有効化 | 中程度のコスト増加 | |
| Azure 仮想マシン スケール セット | はい | はい | 再デプロイ | 同じ数の VM に対するコストへの影響なし |
| Azure 仮想マシン | はい | 再デプロイ | 同じ数の VM に対するコストへの影響なし | |
| Azure Virtual Network | はい | 常にゾーンの回復性を備えている | N/A | |
| Azure VMware Solution | はい | はい | 再デプロイ | 同じ数のノードに対するコストへの影響なし |
| パブリック IP アドレス | はい | はい | 常にゾーンの回復性を備えている | N/A |