可用性ゾーンとリージョンを使用するためのアーキテクチャ戦略

このガイドでは、可用性ゾーンまたはリージョン間でワークロードをデプロイするタイミングを決定するための推奨事項について説明します。

Azure のソリューションを設計するときは、リージョン内の複数の可用性ゾーンにデプロイするか、複数のリージョンにデプロイするかを決定する必要があります。 この決定は、ソリューションの信頼性、コスト、パフォーマンス、およびソリューションを運用するチームの能力に影響します。 このガイドでは、決定に影響を与える主要なビジネス要件、検討できるアプローチ、各アプローチに関連するトレードオフ、および Azure Well-Architected Framework の主要な柱に対する各アプローチの影響について説明します。

ソリューションに使用する Azure リージョンは重要な選択です。 Azure リージョンの選択ガイド では、複数の地理的リージョンで選択して運用する方法について説明します。 ソリューション内でリージョンと可用性ゾーンを使用する方法は、Well-Architected フレームワークのいくつかの柱にも影響します。

• 確実： デプロイ アプローチは、さまざまな種類のリスクを軽減するのに役立ちます。 一般に、より地理的に分散した領域にワークロードを分散させることで、より高い回復性を実現できます。

• コストの最適化: 一部のアーキテクチャアプローチでは、他のアプローチよりも多くのリソースをデプロイする必要があり、リソース コストが増加する可能性があります。 その他の方法では、地理的に分離された可用性ゾーンまたはリージョン間でデータを送信する必要があり、ネットワーク トラフィックの料金が発生する可能性があります。 また、リソース管理の継続的なコストを考慮することも重要です。これは、多くの場合、包括的なビジネス要件がある場合に高くなります。

• パフォーマンス効率: 可用性ゾーンは、高帯域幅で待機時間の短いネットワーク リンクを介して接続されます。 ほとんどのワークロードでゾーン間の同期レプリケーションと通信を有効にするには、このリンクで十分です。 ただし、ワークロードをテストし、ゾーン間のネットワーク待機時間の影響を受けやすいと判断した場合は、ワークロードのコンポーネントが通信するときの待機時間を最小限に抑えるために、ワークロードのコンポーネントを物理的に近くに配置することを検討する必要があります。

• オペレーショナル エクセレンス: 複雑なアーキテクチャでは、デプロイ、構成、管理にさらに多くの労力がかかります。 高可用性ソリューションの場合は、セカンダリ リソース セットにフェールオーバーする方法を計画する必要がある場合もあります。 フェールオーバー、フェールバック、トラフィックの透過的なリダイレクトは、特に手動の手順が必要な場合に複雑になる可能性があります。 デプロイと管理のプロセスを自動化することをお勧めします。 詳細については、 コードとしての OE:05 インフラストラクチャ、OE:09タスク自動化、OE:10オートメーション設計、OE:11展開プラクティスなど、オペレーショナル エクセレンスの柱ガイドを参照してください。

セキュリティの柱は、ソリューションの設計方法に関係なく適用されます。 通常、可用性ゾーンとリージョンの使用に関する決定は、セキュリティ体制を変更しません。 Azure では、すべてのリージョンと可用性ゾーンに同じセキュリティの厳しさが適用されます。

定義

Azure でのリージョンと可用性ゾーンの編成方法を理解する

Azure には、世界中に多数のデータセンターがあります。 Azure リージョン は、一連のデータセンターを含む地理的境界です。 Azure リージョンと可用性ゾーンを完全に理解している必要があります。

Azure リージョンには、リージョン アーキテクチャとも呼ばれるさまざまな構成 があります。

多くの Azure リージョンには 可用性ゾーンが用意されています。これは、データセンターの個別のグループです。 リージョン内では、可用性ゾーンは、他の可用性ゾーンへの待機時間の短い接続を実現するのに十分近いですが、複数のゾーンがローカルの停止や天候の影響を受ける可能性を減らすには十分に離れています。 可用性ゾーンには、独立した電源、冷却、およびネットワーク インフラストラクチャがあります。 これらは、1 つのゾーンで障害が発生した場合、残りのゾーンが引き続きリージョンのサービス、容量、高可用性をサポートできるように設計されています。

次の図は、Azure リージョンの例を示しています。 リージョン 1 とリージョン 2 では、可用性ゾーンがサポートされています。

可用性ゾーンを含む Azure リージョンにデプロイする場合は、複数の可用性ゾーンをまとめて使用できます。 複数の可用性ゾーンを使用すると、アプリケーションの個別のコピーとデータを、大規模な大都市圏の個別の物理データセンター内に保持できます。

ソリューションで可用性ゾーンを使用するには、次の 2 つの方法があります。

• ゾーン リソース は、特定の可用性ゾーンに固定されます。 高い信頼性の要件を満たすために、異なるゾーン間で複数のゾーン展開を組み合わせることができます。 データ レプリケーションを管理し、ゾーン間で要求を分散する責任があります。 単一の可用性ゾーンで障害が発生した場合は、別の可用性ゾーンへのフェールオーバーを担当します。

• ゾーン冗長リソース は、複数の可用性ゾーンに分散されます。 Microsoft は、ゾーン間での要求の分散とデータのレプリケーションを管理します。 単一の可用性ゾーンで停止が発生した場合、Microsoft はフェールオーバーを自動的に管理します。

Azure サービスでは、これらのアプローチのいずれかまたは両方がサポートされています。 サービスとしてのプラットフォーム (PaaS) ソリューションでは、通常、ゾーン冗長デプロイがサポートされます。 サービスとしてのインフラストラクチャ (IaaS) ソリューションは、通常、ゾーンデプロイをサポートします。 Azure サービスが可用性ゾーンと連携する方法の詳細については、可用性 ゾーンをサポートする Azure サービスに関するページを参照してください。

Microsoft は、サービス更新プログラムの展開中に中断が最も少ない方法を使用しようとします。 たとえば、Microsoft は、一度に 1 つの可用性ゾーンに更新プログラムをデプロイすることを目的としています。 この方法では、更新プログラムの処理中にワークロードが他のゾーンで実行され続けることができるため、更新プログラムがアクティブなワークロードに与える影響を軽減できます。 ただし、最終的には、プラットフォームのアップグレード中にワークロードが機能し続けるのは、ワークロード チームの責任です。 たとえば、柔軟なオーケストレーション モードまたはほとんどの Azure PaaS サービス で仮想マシン スケール セットを使用する場合、Azure はリソースをインテリジェントに配置して、プラットフォームの更新の影響を軽減します。 リソースのインスタンスをさらにデプロイする オーバープロビジョニングを検討して、一部のインスタンスが他のインスタンスがアップグレードされている間も使用可能なままになるようにします。 Azure で更新プログラムをデプロイする方法の詳細については、「 安全なデプロイプラクティスを進める」を参照してください。

多くのリージョンにも ペアリージョンがあります。 ペアになっているリージョンでは、特定の種類のマルチリージョン デプロイ アプローチがサポートされます。 一部の新しいリージョンには 複数の可用性ゾーンがあり、ペアになっているリージョンはありません。 これらのリージョンにマルチリージョン ソリューションをデプロイすることはできますが、使用する方法は異なる場合があります。

Azure でのリージョンと可用性ゾーンの使用方法の詳細については、 Azure リージョンと可用性ゾーンに関するページを参照してください。

共有の責任について

共同責任の原則では、クラウド プロバイダーとユーザーの間で責任がどのように分割されるかについて説明します。 使用するサービスの種類によっては、サービスの運用に対して多かれ少なかれ責任を負う場合があります。

Microsoft は可用性ゾーンとリージョンを提供し、要件を満たすようにソリューションを設計する方法を柔軟に提供します。 マネージド サービスを使用する場合、Microsoft はリソースに対してより多くの管理責任を負います。 これらの責任には、データ レプリケーション、フェールオーバー、フェールバック、分散システムの運用に関連するその他のタスクが含まれる場合があります。

独自のコードでは、 エラーを適切に処理するために推奨されるプラクティスと設計パターンに従う必要があります。 これらのプラクティスは、可用性ゾーンまたはリージョンのフェールオーバーが発生したときに発生する操作など、フェールオーバー操作中に特に重要です。ゾーンまたはリージョン間のフェールオーバーでは、多くの場合、アプリケーションがサービスへの接続を再試行する必要があるためです。

主要なビジネス要件とワークロード要件を特定する

ソリューションで可用性ゾーンとリージョンを使用する方法について十分な情報に基づいて決定するには、要件を理解する必要があります。 ソリューション デザイナーとビジネス関係者の間で話し合いを行う場合は、これらの要件を推進する必要があります。

リスク許容度

組織によってリスク許容度が異なります。 1 つの組織内でも、多くの場合、リスク許容度はワークロードによって異なります。 ほとんどのワークロードでは、非常に高い可用性は必要ありません。 ただし、一部のワークロードは非常に重要であるため、地理的に広い地域に影響を与える大規模な自然災害など、可能性の低いリスクでも軽減する価値があります。

次の表に、クラウド環境で考慮する必要がある一般的なリスクをいくつか示します。

すべてのワークロードで発生する可能性のあるすべてのリスクを軽減することが理想的です。 ただし、このアプローチは実用的でもコスト効率も高くありません。 軽減すべきリスクに関する情報に基づいた意思決定を行うことができるように、ビジネス利害関係者とオープンな議論を行う必要があります。

回復性の要件

目標復旧時間 (RTO) や目標復旧ポイント (RPO) など、ワークロードの回復性要件を理解することが重要です。 これらの目標は、除外する方法を決定するのに役立ちます。明確な要件がない場合は、どのアプローチに従うのかを十分な情報に基づいて判断することはできません。 詳細については、「フローを 識別および評価するためのアーキテクチャ戦略」を参照してください。

サービス レベルの目標

ソリューションの予想されるアップタイム サービス レベル目標 (SLO) を理解する必要があります。 たとえば、ソリューションが 99.9% アップタイムを満たす必要があるビジネス要件があるとします。

Azure では、サービスごとにサービス レベル アグリーメント (SLA) が提供されます。 SLA は、サービスから期待されるアップタイムのレベルと、その予想される SLA を達成するために満たす必要がある条件を示します。 ただし、Azure SLA でサービスの可用性を定義する方法は、ワークロードの正常性を評価する方法と必ずしも一致しない場合があることに注意してください。

アーキテクチャ上の決定は、ソリューションの 複合 SLO に影響します。 一般に、ソリューションに組み込む冗長性が高いほど、SLO が高くなる可能性があります。 多くの Azure サービスでは、ゾーン冗長またはマルチリージョン構成でサービスをデプロイするときに、より高い SLA が提供されます。 使用する各 Azure サービスの SLA を確認して、サービスの回復性と SLA を最大化する方法を理解していることを確認します。

データの保存場所

組織によっては、データを格納および処理できる物理的な場所に制限を設ける場合があります。 これらの要件は、法的基準または規制基準に基づく場合があります。 その他のシナリオでは、組織は顧客の懸念を避けるためにデータ所在地ポリシーを採用することを決定する場合があります。 厳密なデータ所在地の要件がある場合は、単一リージョンのデプロイを使用するか、Azure リージョンとサービスのサブセットを使用することが必要になる場合があります。

ユーザーの場所

ユーザーが配置されている場所を理解することで、ニーズに合わせて待機時間と信頼性を最適化する方法について、情報に基づいた意思決定を行うことができます。 Azure には、地理的に分散したユーザー ベースをサポートするための多くのオプションが用意されています。

ユーザーが 1 つの領域に集中している場合、単一リージョンのデプロイによって運用要件が簡素化され、コストが削減されます。 ただし、単一リージョンのデプロイが信頼性要件を満たしているかどうかを検討する必要があります。 ミッション クリティカルなアプリケーションの場合は、ユーザーが併置されている場合でも、マルチリージョンデプロイを使用する必要があります。

ユーザーが地理的に分散している場合は、複数のリージョンにワークロードをデプロイすることが理にかなっている可能性があります。 Azure サービスには、複数リージョンのデプロイをサポートするためのさまざまな機能が用意されており、グローバル Azure フットプリントを使用してユーザー エクスペリエンスを向上させ、アプリケーションをユーザー ベースに近づけることができます。 デプロイ スタンプ パターンまたは Geodes パターンを使用することも、複数のリージョンにリソースをレプリケートすることもできます。

ユーザーが地理的に異なる地域にある場合でも、複数リージョンのデプロイが必要かどうかを検討してください。 Azure Front Door が提供するアクセラレーションなど、グローバル トラフィック アクセラレーションを使用して、1 つのリージョン内で要件を満たすことができるかどうかを検討します。

予算

制約付き予算で運用する場合は、冗長なワークロード コンポーネントのデプロイに関連するコストを考慮することが重要です。 これらのコストには、追加のリソース料金、ネットワーク コスト、より多くのリソースとより複雑な環境を管理するための運用コストが含まれる場合があります。

複雑さ

ソリューション アーキテクチャで不要な複雑さを回避することをお勧めします。 導入する複雑さが増すほど、アーキテクチャに関する意思決定が困難になります。 複雑なアーキテクチャは、運用が難しく、セキュリティで保護するのが難しく、パフォーマンスが低下することがよくあります。 シンプルさの原則に従っていることを確認します。

サンプル シナリオ

リージョンと可用性ゾーンを提供することで、Azure ではニーズに合ったデプロイ アプローチを選択できます。 各アプローチには特定の利点があり、関連するコストが発生します。

使用できるデプロイ方法を説明するために、シナリオの例を考えてみましょう。 何らかの種類のストレージにデータを書き込むアプリケーションを含む新しいソリューションをデプロイするとします。

この例は、特定の Azure サービスに固有ではありません。 基本的な概念を示す例を提供することを目的としています。

このソリューションをデプロイする方法は複数あります。 アプローチごとに異なる一連の利点が提供され、異なるコストが発生します。 大まかに言うと、 ローカル冗長、 ゾーン (固定)、 ゾーン冗長、または 複数リージョンの デプロイを検討できます。 次の表は、重要な問題の一部をまとめたものです。

次の表は、使用できるアプローチの一部と、それらがアーキテクチャに与える影響をまとめたものです。

この記事の残りの部分では、前の表に示した各方法について説明します。 アプローチの一覧は完全ではありません。 複数のアプローチを組み合わせるか、ソリューションのさまざまな部分で異なるアプローチを使用することもできます。

デプロイ方法 1: ローカル冗長デプロイ

リソースをデプロイするときに複数の可用性ゾーンまたはリージョンを指定しない場合、Azure では、リソースが 1 つのデータセンターにデプロイされているか、リージョン内の複数のデータセンターに分割されるかについて保証されません。 一部のシナリオでは、Azure が可用性ゾーン間でリソースを移動する場合もあります。

ほとんどの Azure リソースは既定で高可用性であり、SLA が高く、プラットフォームが管理するデータセンター内に冗長性が組み込まれています。 ただし、信頼性の観点からは、リージョンの一部で障害が発生した場合、ワークロードが影響を受ける可能性があります。 その場合は、ソリューションが使用できないか、データが失われる可能性があります。

待機時間の影響を受けやすいワークロードの場合、この方法ではパフォーマンスが低下する可能性もあります。 ワークロード コンポーネントが同じデータセンターに併置されない可能性があるため、リージョン内トラフィックの待機時間が発生する可能性があります。 また、Azure は可用性ゾーン間でサービス インスタンスを透過的に移動する可能性があり、パフォーマンスに若干の影響を与える可能性があります。 ただし、このパフォーマンス低下は、ほとんどのワークロードにとって問題ではありません。

次の表は、重要な問題の一部をまとめたものです。

次の表は、アーキテクチャの観点からの懸念事項の一部をまとめたものです。

リージョン間でのバックアップを使用したローカル冗長デプロイ

インフラストラクチャとデータの定期的なバックアップをセカンダリ リージョンに実行することで、ローカル冗長デプロイを拡張できます。 このアプローチにより、プライマリ リージョンでの停止を軽減するための保護レイヤーが追加されます。

このアプローチを実装する場合は、RTO と RPO を慎重に検討する必要があります。

• 復旧時間: リージョンの障害が発生した場合は、別の Azure リージョンでソリューションをリビルドする必要があり、復旧時間に影響します。 大規模な障害が発生した場合に別のリージョンにすばやく再デプロイできるように、コードとしてのインフラストラクチャ (IaC) アプローチを使用してソリューションを構築することを検討してください。 障害が発生した場合でもソリューションの再デプロイに使用できるように、デプロイ ツールとプロセスがアプリケーションと同じくらい回復性があることを確認します。 ソリューションを動作状態に戻すために必要な手順を計画してリハーサルします。

• 復旧ポイント: バックアップの頻度によって、発生する可能性があるデータ損失の量が決まります。これは 復旧ポイントと呼ばれます。 通常、バックアップの頻度を制御して、RPO を満たすことができます。

次の表は、重要な問題の一部をまとめたものです。

次の表は、アーキテクチャの観点からの懸念事項の一部をまとめたものです。

展開方法 2: ゾーン (固定) デプロイ

ゾーンデプロイでは、リソースを特定の可用性ゾーンにデプロイするように指定します。 この方法は、 ゾーン固定 デプロイと呼ばれることもあります。

ゾーン方式を使用すると、コンポーネント間の待機時間が短縮されます。 ただし、それ自体では、ソリューションの回復性は向上しません。 回復性を高めるためには、コンポーネントの複数のインスタンスを複数の可用性ゾーンにデプロイし、各インスタンス間でトラフィックをルーティングする方法を決定する必要があります。 この例では、 アクティブ/パッシブ トラフィック ルーティングアプローチを示します。

前の例では、ロード バランサーが複数の可用性ゾーンにデプロイされています。 ゾーンの停止がそのゾーンにデプロイされているネットワーク リソースにも影響を与える可能性があるため、異なる可用性ゾーン内のインスタンス間でトラフィックをルーティングする方法を検討することが重要です。 また、リージョンにまったくデプロイされていない Azure Front Door や Azure Traffic Manager などのグローバル ロード バランサーの使用を検討することもできます。

ゾーン デプロイ モデルを使用する場合は、多くの責任を負います。

• 各可用性ゾーンにリソースをデプロイし、それらのリソースを個別に構成および管理する必要があります。

• 可用性ゾーン間でデータをレプリケートする方法とタイミングを決定し、レプリケーションを構成して管理する必要があります。

• ロード バランサーを使用するなどして、要求を適切なリソースに配布する責任があります。 ロード バランサーが回復性の要件を満たしていることを確認する必要があります。 また、アクティブ/パッシブまたはアクティブ/アクティブのどちらの要求分散モデルを使用するかを決定する必要があります。

• 可用性ゾーンで障害が発生した場合は、フェールオーバーを処理して、別の可用性ゾーン内のリソースにトラフィックを送信する必要があります。

複数の可用性ゾーンにまたがるアクティブ/パッシブデプロイは、 リージョン内 DR または メトロ DR と呼ばれることもあります。

次の表は、重要な問題の一部をまとめたものです。

次の表は、アーキテクチャの観点からの懸念事項の一部をまとめたものです。

このアプローチは、通常、仮想マシン (VM) に基づくワークロードに使用されます。 ゾーン展開をサポートするサービスの完全な一覧については、 可用性ゾーン のサービスとリージョンのサポートに関する説明を参照してください。

ゾーンデプロイを計画するときは、使用する Azure サービスが、使用する予定の可用性ゾーンでサポートされていることを確認します。 各可用性ゾーンで使用できる VM SKU を一覧表示するには、「 VM SKU の可用性を確認する」を参照してください。

展開方法 3: ゾーン冗長デプロイ

この方法を使用すると、アプリケーション層が複数の可用性ゾーンに分散されます。 要求が到着すると、サービスに組み込まれているロード バランサーによって、各可用性ゾーン内のインスタンス全体に要求が分散されます。 サービス自体は可用性ゾーンにまたがっています。 可用性ゾーンで障害が発生した場合、ロード バランサーは、正常な可用性ゾーン内のインスタンスにトラフィックを転送します。

ストレージ層は、複数の可用性ゾーンにも分散されます。 アプリケーションのデータのコピーは、 同期レプリケーションを介して複数の可用性ゾーンに分散されます。 アプリケーションがデータを変更すると、ストレージ サービスは変更を複数の可用性ゾーンに書き込みます。 トランザクションは、これらの変更がすべて完了した場合にのみ完了と見なされます。 このプロセスにより、各可用性ゾーンにデータの up-to-date コピーが常に含まれるようにします。 可用性ゾーンで障害が発生した場合は、別の可用性ゾーンを使用して同じデータにアクセスできます。

ゾーン冗長アプローチを使用すると、データセンターの停止などの問題に対するソリューションの回復性が向上します。 ただし、データは同期的にレプリケートされるため、アプリケーションは、大都市圏の異なる部分にある複数の異なる場所にデータが書き込まれるのを待つ必要があります。 ほとんどのアプリケーションでは、ゾーン間通信の待機時間はごくわずかです。 ただし、待機時間の影響を受けやすいワークロードによっては、可用性ゾーン間の同期レプリケーションがアプリケーションのパフォーマンスに影響する可能性があります。

次の表は、重要な問題の一部をまとめたものです。

次の表は、アーキテクチャの観点からの懸念事項の一部をまとめたものです。

このアプローチは、Azure Virtual Machine Scale Sets、Azure App Service、Azure Functions、Azure Kubernetes Service (AKS)、Azure Storage、Azure SQL、Azure Service Bus、およびその他の多くのサービスを含む多くの Azure サービスで可能です。 ゾーンの冗長性をサポートするサービスの完全な一覧については、 可用性ゾーン のサービスとリージョンのサポートに関する説明を参照してください。

リージョン間でのバックアップを使用したゾーン冗長デプロイ

インフラストラクチャとデータの定期的なバックアップをセカンダリ リージョンに実行することで、ゾーン冗長デプロイを拡張できます。 このアプローチにより、ゾーン冗長アプローチの利点が得られ、完全なリージョン停止が発生する可能性が非常に低い場合を軽減するための保護レイヤーが追加されます。

このアプローチを実装する場合は、RTO と RPO を慎重に検討する必要があります。

• 復旧時間: リージョンの停止が発生した場合は、別の Azure リージョンでソリューションをリビルドすることが必要になる場合があります。これは復旧時間に影響します。 大規模な障害発生時に別のリージョンにすばやく再デプロイできるように、IaC アプローチを使用してソリューションを構築することを検討してください。 障害が発生した場合でもソリューションの再デプロイに使用できるように、デプロイ ツールとプロセスがアプリケーションと同じくらい回復性があることを確認します。 ソリューションを稼働状態に戻すために必要な手順を計画してリハーサルします。

• 復旧ポイント: バックアップの頻度によって、 復旧ポイントと呼ばれる、発生する可能性があるデータ損失の量が決まります。 通常、RPO を満たすようにバックアップの頻度を制御できます。

次の表は、重要な問題の一部をまとめたものです。

次の表は、アーキテクチャの観点からの懸念事項の一部をまとめたものです。

展開方法 4: 複数リージョンのデプロイ

複数の Azure リージョンを一緒に使用して、幅広い地理的領域にソリューションを分散できます。 このマルチリージョン アプローチを使用して、ソリューションの信頼性を向上させたり、地理的に分散したユーザーをサポートしたりできます。 複数のリージョンにデプロイすることで、1 つのリージョンで一時的なリソース容量の制約が発生するリスクも軽減できます。 データ所在地がソリューションにとって重要な懸念事項である場合は、要件を満たす場所にのみデータが格納されるようにするために使用するリージョンを慎重に検討してください。

アクティブリージョンとパッシブリージョン

マルチリージョン アーキテクチャは複雑であり、マルチリージョン ソリューションを設計する方法は多数あります。 一部のワークロードでは、複数のリージョンで同時に要求をアクティブに処理する (アクティブ/アクティブなデプロイ) の方が理にかなっています。 他のワークロードの場合は、1 つの プライマリ リージョン を指定し、フェールオーバーに 1 つ以上の セカンダリ リージョン (アクティブ/パッシブ デプロイ) を使用することをお勧めします。 このセクションでは、あるリージョンがアクティブで、もう 1 つがパッシブである 2 番目のシナリオについて説明します。 アクティブ/アクティブマルチリージョン ソリューションの詳細については、「 デプロイ スタンプ パターン と Geode パターン」を参照してください。

データのレプリケーション

リージョン間通信は、リージョン内通信よりもはるかに低速です。 一般に、2 つのリージョン間の地理的距離が大きいほど、データが移動する必要がある物理的な距離が長くなるため、ネットワーク待機時間が長くなります。 2 つのリージョン間で接続するときの予想されるネットワーク待機時間の詳細については、 Azure ネットワークラウンドトリップ待機時間の統計を参照してください。

リージョン間のネットワーク待機時間は、追加の待機時間がデータ レプリケーションやその他のトランザクションに与える影響を慎重に検討する必要があるため、ソリューション設計に大きな影響を与える可能性があります。 多くのソリューションでは、リージョン間のトラフィックがパフォーマンスに及ぼす影響を最小限に抑えるために、リージョン間アーキテクチャでは 非同期 レプリケーションが必要です。

非同期データ レプリケーション

リージョン間で非同期レプリケーションを実装する場合、アプリケーションはすべてのリージョンが変更を確認するまで待機しません。 プライマリ リージョンで変更がコミットされると、トランザクションは完了と見なされます。 変更は後でセカンダリ リージョンにレプリケートされます。 この方法により、リージョン間の接続待機時間がアプリケーションのパフォーマンスに直接影響を与えることはありません。 ただし、レプリケーションの遅延により、リージョン全体の停止によってデータが失われる可能性があります。 このデータ損失は、プライマリ リージョンで書き込みが完了した後、変更が別のリージョンにレプリケートされる前に、リージョンで障害が発生する可能性があるために発生する可能性があります。

次の表は、重要な問題の一部をまとめたものです。

次の表は、アーキテクチャの観点からの懸念事項の一部をまとめたものです。

同期データ レプリケーション

同期マルチリージョン ソリューションを実装する場合、アプリケーションは、各 Azure リージョンで書き込み操作が完了するのを待ってから、トランザクションが完了したと見なす必要があります。 書き込み操作を待機することによって発生する待機時間は、リージョン間の距離によって異なります。 多くのワークロードでは、リージョン間の待機時間により、同期レプリケーションが遅すぎて役に立たなくなります。

次の表は、重要な問題の一部をまとめたものです。

次の表は、アーキテクチャの観点からの懸念事項の一部をまとめたものです。

リージョン アーキテクチャ

マルチリージョン ソリューションを設計する場合は、使用する予定の Azure リージョンがペアになっているかどうかを検討してください。

リージョンがペアになっていない場合でも、マルチリージョン ソリューションを作成できます。 ただし、マルチリージョン アーキテクチャを実装するために使用する方法は異なる場合があります。 たとえば、Storage では、ペアになっているリージョンで geo 冗長ストレージ (GRS) を使用できます。 GRS を使用できない場合は、ストレージ オブジェクト レプリケーションなどの機能を使用するか、複数のリージョンに書き込むようにアプリケーションを設計することを検討してください。

マルチゾーンとマルチリージョンのアプローチを組み合わせる

ビジネス要件でこのようなソリューションが必要な場合は、マルチゾーンステートメントとマルチリージョン ステートメントを組み合わせる必要があります。 たとえば、ゾーン冗長コンポーネントを各リージョンにデプロイし、リージョン間のレプリケーションを構成することもできます。 一部のソリューションでは、このアプローチは非常に高い信頼性を提供します。 ただし、この種類のアプローチの構成は複雑になる可能性があり、このアプローチはコストがかかる場合があります。

Azure サービスがデプロイ アプローチをサポートする方法

使用する Azure サービスの具体的な詳細を理解することが重要です。 たとえば、一部の Azure サービスでは、最初にリソースをデプロイするときに可用性ゾーンの構成を設定する必要があります。一方、他のサービスでは後でデプロイ アプローチの変更をサポートします。 同様に、一部のサービス機能は、すべてのデプロイ アプローチで使用できない場合があります。

Azure サービスごとに考慮する特定のデプロイ オプションとアプローチの詳細については、 信頼性ハブを参照してください。

ユース ケースの例

このセクションでは、一般的なユース ケースと、各ワークロードで通常考慮する必要がある主な要件について説明します。 ワークロードごとに、この記事で説明されている要件とアプローチに基づいて、1 つ以上の推奨されるデプロイ アプローチが提供されます。

企業向けの基幹業務アプリケーション

Contoso, Ltd. は、大規模な製造会社です。 同社は、財務プロセスの一部のコンポーネントを管理するための基幹業務 (LOB) アプリケーションを実装しています。

ビジネス要件: システムが管理する情報を置き換えるのが難しいため、データを確実に保持する必要があります。 アーキテクトは、可能な限り少ないダウンタイムとデータ損失が発生するシステムを必要とします。 Contoso の従業員は稼働日を通してシステムを使用するため、チーム メンバーの待機を避けるためには高パフォーマンスが重要です。 財務チームがソリューションの支払いを行う必要があるため、コストも懸念事項です。

推奨されるアプローチ:リージョン間のバックアップを使用したゾーン冗長デプロイ では、高パフォーマンスで複数の回復性レイヤーが提供されます。

内部アプリケーション

4番目のコーヒーは中小企業です。 この会社では、従業員がタイムシートの送信に使用できる新しい内部アプリケーションを開発しています。

ビジネス要件: このワークロードでは、コスト効率が主な懸念事項です。 Fourth Coffee はダウンタイムのビジネスへの影響を評価し、アプリケーションが回復性やパフォーマンスに優先順位を付ける必要はないことを判断しました。 会社は、Azure 可用性ゾーンまたはリージョンで障害が発生すると、アプリケーションが一時的に使用できなくなるリスクを受け入れます。

推奨されるアプローチ:

• リージョン間のバックアップを使用したローカル冗長デプロイ は、コストが最も低くなりますが、重大なリスクもあります。

• リージョン間のバックアップを使用したゾーン冗長デプロイ では、回復性が向上しますが、コストは若干高くなります。

レガシ アプリケーションの移行

Fabrikam, Inc.は、オンプレミスのデータセンターから Azure にレガシ アプリケーションを移行しています。 VM に基づく IaaS アプローチを使用する予定です。 アプリケーションはクラウド環境用に設計されていないため、アプリケーション層とデータベースの間の通信は非常に 煩雑です。

ビジネス要件: このアプリケーションでは、パフォーマンスが優先されます。 回復性も重要であり、Azure データセンターで障害が発生した場合でも、アプリケーションは引き続き動作する必要があります。

推奨されるアプローチ:

• Fabrikam では、まず ゾーン冗長デプロイを試す必要があります。 パフォーマンスが要件を満たしていることを確認する必要があります。

• ゾーン冗長ソリューションのパフォーマンスが許容できない場合は、 ゾーン (固定) デプロイを検討し、複数の可用性ゾーン (リージョン内 DR) にまたがるパッシブ デプロイを検討する必要があります。

医療アプリケーション

Lamna Healthcare Company は、Azure に新しい電子医療記録システムを実装しています。

ビジネス要件: このソリューションが格納するデータの性質上、データ所在地は非常に重要です。 Lamna は、データを特定の場所に残す必要があることを義務付ける厳格な規制フレームワークの下で動作します。

推奨されるアプローチ:

• Lamna のデータ所在地の要件に適合する複数のリージョンがある場合は、マルチゾーンマルチリージョンデプロイ。

• ニーズに合ったリージョンが 1 つだけの場合は、 ゾーン冗長デプロイ 、または単一リージョン ソリューションを提供する リージョン間でのバックアップを使用したゾーン冗長デプロイ を検討する必要があります。

銀行システム

Woodgrove Bank は、Azure にデプロイされた大規模なソリューションからコア バンキング操作を実行します。

ビジネス要件: このシステムはミッション クリティカルです。 障害が発生すると、お客様に大きな財務上の影響が生じる可能性があります。 その結果、ウッドグローブ銀行のリスク許容度は非常に低くなります。 システムには、可能な限り最高レベルの信頼性が必要であり、アーキテクチャでは、軽減できる障害のリスクを軽減する必要があります。

推奨されるアプローチ: ミッション クリティカルなシステムの場合は、 マルチゾーンマルチリージョン展開 を使用し、リージョンが会社のデータ所在地の要件に適合していることを確認する必要があります。

サービスとしてのソフトウェア

Proseware, Inc.は、世界中の企業が使用するソフトウェアを構築しています。 会社のユーザー ベースは地理的に広く分散されています。

ビジネス要件: Proseware では、各顧客が顧客に近いデプロイ リージョンを選択できるようにする必要があります。 この選択を有効にすることは、待機時間と顧客のデータ所在地の要件にとって重要です。

推奨されるアプローチ:

• マルチゾーン マルチリージョンデプロイ は、通常、サービスとしてのソフトウェア (SaaS) プロバイダーに適しています。特に 、デプロイ スタンプ パターン内で使用される場合です。

• Azure Front Door などのグローバル トラフィック 高速化ソリューションを使用した単一リージョンのゾーン冗長デプロイ。

次のステップ

次の参照アーキテクチャとシナリオ例は、マルチゾーンおよびマルチリージョン ソリューション用です。

• ベースラインの高可用性ゾーン冗長 Web アプリケーション
• 高可用性マルチリージョン Web アプリケーション
• 複数リージョンの N 層アプリケーション
• 高可用性と DR 用に構築された多層 Web アプリケーション

複数の可用性ゾーンにソリューションを実装するには、次の Azure サービスを使用します。

• Azure Site Recovery: 可用性ゾーン間で Azure VM DR を有効にする
• Azure NetApp Files: Azure NetApp Files のクロスゾーン レプリケーションについて
• Azure Storage の冗長性