アベイラビリティ ゾーンとリージョンを使用するための推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:05 | 異なるレベルで冗長性を追加します (特に、重要なフローの場合)。 特定された信頼性目標に従って、コンピューティング、データ、ネットワーク、およびその他のインフラストラクチャ層に冗長性を適用します。 |
|---|
このガイドでは、可用性ゾーンまたはリージョン間でワークロードをデプロイするタイミングを決定するための推奨事項について説明します。
Azure のソリューションを設計するときは、リージョン内の複数の可用性ゾーンにデプロイするか、複数のリージョンにデプロイするかを決定する必要があります。 この決定は、ソリューションの信頼性、コスト、パフォーマンス、およびソリューションを運用するチームの能力に影響します。 このガイドでは、決定に影響を与える主要なビジネス要件、検討できるアプローチ、各アプローチに関連するトレードオフ、および Azure Well-Architected Framework の主要な柱に対する各アプローチの影響に関する情報を提供します。
ソリューションに使用する最適な Azure リージョンに関する決定は、重要な選択です。 Azure リージョンの 選択ガイド では、複数の地理的リージョンで選択して運用する方法について説明します。 ソリューション内でリージョンと可用性ゾーンを使用する方法を選択すると、適切に設計されたフレームワークのいくつかの柱にも影響します。
- 信頼性: デプロイ アプローチの選択は、さまざまな種類のリスクを軽減するのに役立ちます。 一般に、より地理的に分散した領域にワークロードを分散させることで、より高い回復性を実現できます。
- コストの最適化: アーキテクチャアプローチによっては、他のアーキテクチャよりも多くのリソースをデプロイする必要があり、リソース コストが増加する可能性があります。 その他の方法では、地理的に分離された可用性ゾーンまたはリージョン間でデータを送信する必要があり、ネットワーク トラフィックの料金が発生する可能性があります。 また、リソース管理の継続的なコストを考慮することも重要です。これは、通常、包括的なビジネス要件がある場合に高くなります。
- パフォーマンス効率: 可用性ゾーンは、高帯域幅で待機時間の短いネットワーク リンクを介して接続されます。これは、ほとんどのワークロードでゾーン間の同期レプリケーションと通信を有効にするために十分です。 ただし、ワークロードがテスト済みで、ゾーン間のネットワーク待ち時間に影響を受けやすい場合は、ワークロードのコンポーネントが通信するときの待機時間を最小限に抑えるために、ワークロードのコンポーネントを物理的に近づけて配置することを検討する必要があります。
- オペレーショナル エクセレンス: 複雑なアーキテクチャでは、デプロイ、構成、管理に多くの労力がかかります。 さらに、高可用性ソリューションの場合は、リソースのセカンダリ セットにフェールオーバーする方法を計画することが必要になる場合があります。 フェールオーバー、フェールバック、トラフィックの透過的なリダイレクトは、特に手動の手順が必要な場合に複雑になる可能性があります。 デプロイと管理のプロセスを自動化することをお勧めします。 詳細については、コードとしての OE:05 インフラストラクチャ、OE:09 タスク自動化、OE:10 オートメーション設計、OE:11 展開プラクティスなど、オペレーショナル エクセレンスの柱ガイドを参照してください。
ソリューションを設計する場合でも、セキュリティの柱が適用されます。 通常、可用性ゾーンとリージョンの使用に関する決定は、セキュリティ体制を変更しません。 Azure では、すべてのリージョンと可用性ゾーンに同じセキュリティの厳しさが適用されます。
ヒント
多くの運用ワークロードでは、 ゾーン冗長デプロイ によって最適なトレードオフのバランスが提供されます。 非同期データ バックアップを使用して 、このアプローチを別のリージョンに拡張できます。 どちらの手法を選択すればよいかわからない場合は、まずこの種類の展開を試してください。
これらのアプローチが提供する特定の利点が必要な場合は、他のワークロード アプローチを検討しますが、関連するトレードオフに注意してください。
定義
| 相談 | 定義 |
|---|---|
| アクティブ/アクティブ | ソリューションの複数のインスタンスが同時に要求をアクティブに処理するアーキテクチャ。 |
| アクティブ/パッシブ | ソリューションの 1 つのインスタンスが プライマリ として指定され、トラフィックを処理し、プライマリが使用できない場合にトラフィックを提供するために 1 つ以上の セカンダリ インスタンスがデプロイされるアーキテクチャ。 |
| 非同期レプリケーション | データが 1 つの保存先に書き込まれ、コミットされるデータ レプリケーションアプローチ。 後で、変更が別の保存先にレプリケートされます。 |
| 可用性ゾーン | リージョン内のデータセンターの分離されたグループ。 各可用性ゾーンは他の可用性ゾーンとは独立しており、独自の電源、冷却、およびネットワーク インフラストラクチャを備えています。 多くのリージョンでは、可用性ゾーンがサポートされています。 |
| データセンター | Azure のリソースとワークロードをサポートするためのサーバー、ネットワーク機器、およびその他のハードウェアを含む機能。 |
| ローカル冗長デプロイ | リソースが可用性ゾーンを参照せずに 1 つのリージョンにデプロイされるデプロイ モデル。 可用性ゾーンをサポートするリージョンでは、リソースがリージョンの任意の可用性ゾーンにデプロイされる場合があります。 |
| 複数リージョンのデプロイ | リソースが複数の Azure リージョンにデプロイされるデプロイ モデル。 |
| ペアになっているリージョン | 2 つの Azure リージョン間の関係。 一部の Azure リージョン は、特定の種類のマルチリージョン ソリューションを有効にするために、別の定義済みリージョンに接続されています。 新しい Azure リージョンはペアになっていません。 |
| リージョン | 一連のデータセンターを含むgeography 型の境界。 |
| リージョン アーキテクチャ | 可用性ゾーンの数や、リージョンが別のリージョンとペアになっているかどうかなど、Azure リージョンの特定の構成。 |
| 同期レプリケーション | データが複数の保存先に書き込まれ、コミットされるデータ レプリケーションアプローチ。 書き込み操作全体が完了したと見なされる前に、各保存先で書き込み操作の完了を確認する必要があります。 |
| ゾーン(ピン留め)デプロイ | リソースが特定の可用性ゾーンにデプロイされるデプロイ モデル。 |
| ゾーン冗長デプロイ | リソースが複数の可用性ゾーンにデプロイされるデプロイ モデル。 Microsoft は、ゾーンで障害が発生した場合のデータ同期、トラフィック分散、フェールオーバーを管理します。 |
主要な設計戦略
Azure には大きなグローバル フットプリントがあります。 Azure リージョン は、一連のデータセンターを含む地理的境界です。 Azure リージョンと可用性ゾーンを完全に理解している必要があります。
Azure リージョンには、リージョン アーキテクチャとも呼ばれる さまざまな構成があります。
多くの Azure リージョンでは、データセンターの分離されたグループである可用性ゾーンが提供されています。 リージョン内では、可用性ゾーンは、他の可用性ゾーンへの待機時間の短い接続を行えるほど十分に近接していますが、複数の可用性ゾーンがローカルな停止や気象の影響を受ける可能性を減らせるほど十分に離れています。 可用性ゾーンは、独立した電源、冷却、ネットワーク インフラストラクチャを備えています。 これらは、あるゾーンで障害が発生した場合に、リージョン サービス、容量、高可用性が残りのゾーンによってサポートされるように設計されています。
次の図は、Azure リージョンの例を示しています。 リージョン 1 と 2 は、可用性ゾーンをサポートしています。
可用性ゾーンを含む Azure リージョンにデプロイする場合は、複数の可用性ゾーンをまとめて使用できます。 複数の可用性ゾーンを使用することで、大都市圏の別々の物理データセンター内にアプリケーションとデータそれぞれのコピーを保持することができます。
ソリューションで可用性ゾーンを使用するには、次の 2 つの方法があります。
- ゾーン リソース は、特定のアベイラビリティ ゾーンに固定されます。 高い信頼性の要件を満たすために、異なるゾーン間で複数のゾーン展開を組み合わせることができます。 ユーザーは、データ レプリケーションを管理し、ゾーン間で要求を分散する責任があります。 単一のアベイラビリティ ゾーンで障害が発生した場合は、ユーザーが別のアベイラビリティ ゾーンへのフェールオーバーを行います。
- ゾーン冗長リソース は、複数のアベイラビリティ ゾーンに分散されます。 Microsoft は、ゾーン間での要求の分散と、ゾーン間でのデータのレプリケーションを管理します。 単一のアベイラビリティ ゾーンで停止が発生した場合、Microsoft はフェールオーバーを自動的に管理します。
Azure サービスは、これらのアプローチの 1 つまたは両方をサポートしています。 サービスとしてのプラットフォーム (PaaS) サービスは通常、ゾーン冗長デプロイをサポートしています。 サービスとしてのインフラストラクチャ (IaaS) サービスは通常、ゾーン デプロイをサポートしています。 Azure サービスが可用性ゾーンと連携する方法の詳細については、可用性ゾーンをサポートする Azure サービスに関するページを参照してください。
Microsoft がサービスに更新プログラムを展開する場合、ユーザーに最も影響を与えるのが最も少ない方法を使用しようとします。 たとえば、一度に 1 つの可用性ゾーンに更新プログラムをデプロイすることを目指しています。 この方法では、更新プログラムの処理中にワークロードが他のゾーンで実行され続けることができるため、更新プログラムがアクティブなワークロードに与える影響を軽減できます。 ただし、最終的には、プラットフォームのアップグレード中にワークロードが機能し続けるのは、ワークロード チームの責任です。 たとえば、柔軟なオーケストレーション モードまたはほとんどの Azure PaaS サービスで仮想マシン スケール セットを使用する場合、Azure はリソースをインテリジェントに配置して、プラットフォームの更新の影響を軽減します。 さらに、オーバープロビジョニング (リソースのインスタンスのデプロイ) を検討して、一部のインスタンスがメイン他のインスタンスがアップグレードされている間に使用可能になるようにします。 Azure で更新をデプロイする方法の詳細については、「安全なデプロイ プラクティスの推進」を参照してください。
多くのリージョンには、ペアになっているリージョンもあります。 ペアになっているリージョンは、ある種のマルチリージョン デプロイのアプローチをサポートします。 いくつかの新しいリージョンには複数の可用性ゾーンがあり、ペアになっているリージョンはありません。 これらのリージョンにマルチ リージョン ソリューションをデプロイすることはできますが、使用するアプローチは異なる場合があります。
Azure でのリージョンと可用性ゾーンの使用方法の詳細については、「Azure リージョンと可用性ゾーンとは」を参照してください 。
共有の責任について
共同責任の原則では、クラウド プロバイダー (Microsoft) とユーザーの間で責任がどのように分割されるかについて説明します。 利用するサービスの種類によっては、サービスの運用に多かれ少なかれ責任を負う可能性があります。
Microsoft は、可用性ゾーンとリージョンを提供することで、顧客の要件を満たすソリューションの設計方法に柔軟性を持たせています。 マネージド サービスを利用する場合、Microsoft は顧客のリソースの管理責任をさらに引き受け、データ レプリケーション、フェールオーバー、フェールバック、および分散システムの運用に関連するその他のタスクを含む可能性もあります。
独自のコードでは、エラーを適切に処理するための推奨プラクティスと設計パターンが必要です。 これらのプラクティスは、可用性ゾーンまたはリージョンのフェールオーバーが発生したときに発生するなど、フェールオーバー操作中にさらに重要になります。ゾーンまたはリージョン間のフェールオーバーでは、通常、アプリケーションがサービスへの接続を再試行する必要があるためです。
主要なビジネス要件とワークロード要件を特定する
ソリューションで可用性ゾーンとリージョンを使用する方法について十分な情報に基づいて決定するには、要件を理解する必要があります。 これらの要件は、ソリューション デザイナーとビジネス利害関係者間の議論によって推進される必要があります。
リスク許容度
組織によってリスク許容度が異なります。 組織内でも、多くの場合、リスク許容度はワークロードごとに異なります。 ほとんどのワークロードでは、非常に高い可用性は必要ありません。 ただし、一部のワークロードは非常に重要であるため、地理的に広い地域に影響を与える大規模な自然災害など、発生する可能性が低いリスクを軽減する価値さえあります。
次の表に、クラウド環境で考慮する必要がある一般的なリスクをいくつか示します。
| リスク | 例 | Likelihood |
|---|---|---|
| ハードウェアの停止 | ハード ディスクまたはネットワーク機器に関する問題。 ホストの再起動。 |
高 。 回復性戦略では、これらのリスクを考慮する必要があります。 |
| データセンターの停止 | データセンター全体の電源、冷却、またはネットワーク障害。 大都市圏の一部における自然災害。 |
Medium |
| リージョンの停止 | 地域全体に影響を与える大規模な自然災害。 リージョン全体で 1 つ以上の Azure サービスを使用できなくなるネットワークまたはサービスの問題。 |
低 |
すべてのワークロードで発生する可能性のあるすべてのリスクを軽減するのが理想的ですが、これを行うには実用的またはコスト効率が高いわけではありません。 軽減する必要があるリスクに関する情報に基づいた意思決定を行えるように、ビジネス利害関係者とオープンなディスカッションを行することが重要です。
ヒント
信頼性のターゲットに関係なく、すべてのワークロードにディザスター リカバリーのための軽減策が必要です。 ワークロードで高い信頼性の目標が必要な場合は、軽減戦略を包括的に行い、可能性の低いイベントのリスクを軽減する必要があります。 他のワークロードの場合は、受け入れる準備ができているリスクと軽減する必要があるリスクについて、情報に基づいて決定します。
回復性の要件
目標復旧時間 (RTO) や目標復旧ポイント (RPO) など、ワークロードの回復性要件を理解することが重要です。 これらの目標は、除外する方法を決定するのに役立ちます。明確な要件がない場合は、どのアプローチに従うのかを十分な情報に基づいて判断することはできません。 詳細については、「対象の機能要件と非機能要件」を参照してください。
サービスレベルの目標
ソリューションの予想されるアップタイム サービス レベル目標 (SLO) を理解する必要があります。 たとえば、ソリューションが 99.9% のアップタイムを満たす必要があるビジネス要件があるとします。
Azure では、サービスごとにサービス レベル アグリーメント (SLA) が提供されます。 SLA は、サービスに期待されるアップタイムのレベルと、期待される SLA を達成するために満たす必要がある条件を示します。 ただし、Azure SLA がサービスの可用性を示す方法が、ワークロードの正常性を考慮する方法と常に一致するとは限らないことに注意してください。
アーキテクチャ上の決定は、ソリューションの 複合 SLO に影響します。 一般に、ソリューションに組み込む冗長性が高いほど、SLO が高くなる可能性があります。 多くの Azure サービスでは、ゾーン冗長またはマルチリージョン構成でサービスをデプロイするときに、より高い SLA が提供されます。 使用する各 Azure サービスの SLA を確認して、サービスの回復性と SLA を最大化する方法を理解していることを確認します。
データの保存場所
組織によっては、データを格納および処理できる物理的な場所に制限を設ける場合があります。 これらの要件は、法的基準または規制基準に基づく場合があります。 その他の状況では、組織は、顧客の懸念を回避するためにデータ所在地ポリシーを採用することを決定する場合があります。 厳密なデータ所在地の要件がある場合は、単一リージョンのデプロイを使用するか、Azure リージョンとサービスのサブセットを使用することが必要になる場合があります。
Note
データ所在地の要件について、根拠のない前提を立てないでください。 特定の規制基準に準拠する必要がある場合は、これらの標準で実際に指定されていることを確認します。
ユーザーの場所
ユーザーが配置されている場所を理解することで、ニーズに合わせて待機時間と信頼性を最適化する方法について、情報に基づいた意思決定を行うことができます。 Azure には、地理的に分散したユーザー ベースをサポートするための多くのオプションが用意されています。
ユーザーが 1 つの領域に集中している場合、単一リージョンのデプロイによって運用要件が簡素化され、コストが削減されます。 ただし、単一リージョンのデプロイが信頼性要件を満たしているかどうかを検討する必要があります。 ミッション クリティカルなアプリケーションの場合は、ユーザーが併置されている場合でも、マルチリージョンデプロイを使用する必要があります。
ユーザーが地理的に分散している場合は、複数のリージョンにワークロードをデプロイすることが理にかなっている可能性があります。 Azure サービスには、複数リージョンのデプロイをサポートするためのさまざまな機能が用意されており、Azure のグローバル フットプリントを使用してユーザー エクスペリエンスを向上させ、アプリケーションをユーザー ベースに近づけることができます。 デプロイ スタンプ パターンまたは Geodes パターンを使用することも、複数のリージョンにリソースをレプリケートすることもできます。
ユーザーが地理的に異なる地域にある場合でも、複数リージョンのデプロイが必要かどうかを検討してください。 Azure Front Door によって提供されるアクセラレーションのように、グローバル トラフィック アクセラレーションを使用して、1 つのリージョン内で要件を達成できるかどうかを検討します。
予算
制約付き予算で運用する場合は、冗長なワークロード コンポーネントのデプロイに関連するコストを考慮することが重要です。 これらのコストには、追加のリソース料金、ネットワーク コスト、より多くのリソースとより複雑な環境を管理するための運用コストが含まれる場合があります。
複雑性
ソリューション アーキテクチャで不要な複雑さを回避することをお勧めします。 導入する複雑さが増すほど、アーキテクチャに関する意思決定が困難になります。 複雑なアーキテクチャは、運用が難しく、セキュリティで保護するのが難しく、パフォーマンスが低下することがよくあります。 シンプルさの原則に従ってください。
Azure ファシリテーション
リージョンと可用性ゾーンを提供することで、Azure ではニーズに合ったデプロイ アプローチを選択できます。 選択できるアプローチは多数あり、それぞれに利点があり、コストが発生します。
使用できるデプロイ方法を説明するために、シナリオの例を考えてみましょう。 ある種のストレージにデータを書き込むアプリケーションを含む新しいソリューションをデプロイすることを検討しているとします。
この例は、特定の Azure サービスに固有ではありません。 基本的な概念を説明するための簡単な例を提供することを目的としています。
このソリューションをデプロイする方法は複数あります。 アプローチごとに異なる一連の利点が提供され、異なるコストが発生します。 大まかに言うと、ローカル冗長、ゾーン (固定)、ゾーン冗長、または複数リージョンのデプロイを検討できます。 次の表は、重要な問題の一部をまとめたものです。
| 重要な要素 | ローカル冗長 | ゾーン (ピン留め) | ゾーン冗長 | 複数リージョン |
|---|---|---|---|---|
| 信頼性 | 低信頼性 | アプローチに依存 | 高いまたは非常に高い信頼性 | 高いまたは非常に高い信頼性 |
| コストの最適化 | 低コスト | アプローチに依存 | 中程度のコスト | 高コスト |
| パフォーマンス効率 | 許容されるパフォーマンス (ほとんどのワークロード) | 高性能 | 許容されるパフォーマンス (ほとんどのワークロード) | アプローチに依存 |
| オペレーショナル エクセレンス | 運用要件が低い | 高い運用要件 | 運用要件が低い | 高い運用要件 |
次の表は、使用できるアプローチの一部と、それらがアーキテクチャに与える影響をまとめたものです。
| アーキテクチャに関する懸念事項 | ローカル冗長 | ゾーン (ピン留め) | ゾーン冗長 | 複数リージョン |
|---|---|---|---|---|
| データ所在地のコンプライアンス | 高 | 高 | 高 | リージョンによって異なります |
| リージョン別の提供状況 | すべてのリージョン | 可用性ゾーンがあるリージョン | 可用性ゾーンがあるリージョン | リージョンによって異なります |
この記事の残りの部分では、前の表に示した各方法について説明します。 アプローチの一覧は完全ではありません。 複数のアプローチを組み合わせるか、ソリューションのさまざまな部分で異なるアプローチを使用することもできます。
デプロイ方法 1: ローカル冗長デプロイ
リソースをデプロイするときに複数の可用性ゾーンまたはリージョンを指定しない場合、Azure では、リソースが 1 つのデータセンターにデプロイされているか、リージョン内の複数のデータセンターに分割されるかについて保証されません。 状況によっては、Azure によって可用性ゾーン間でリソースが移動される場合もあります。
ほとんどの Azure リソースは既定で高可用性を備えています。SLA が高く、プラットフォームによって管理されるデータセンター内に冗長性が組み込まれています。 ただし、信頼性の観点からは、リージョンの一部で障害が発生した場合、ワークロードが影響を受ける可能性があります。 その場合は、ソリューションが使用できないか、データが失われる可能性があります。
待機時間の影響を受けやすいワークロードの場合、この方法ではパフォーマンスが低下する可能性もあります。 ワークロード コンポーネントが同じデータセンターに併置されない可能性があるため、リージョン内トラフィックの待機時間が発生する可能性があります。 また、Azure は可用性ゾーン間でサービス インスタンスを透過的に移動する可能性があり、パフォーマンスに若干の影響を与える可能性があります。 ただし、これはほとんどのワークロードにとって問題ではありません。
次の表は、重要な問題の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 信頼性が低い。 データセンターで障害が発生した場合、サービスは停止の影響を受けます。 ただし、他の種類の障害に対する回復性を備えるアプリケーションを構築することはできます。 |
| コストの最適化 | コストが最も低い。 各リソースのインスタンスは 1 つだけ必要であり、リージョン間の帯域幅コストは発生しません。 |
| パフォーマンス効率 | ほとんどのワークロードの場合:許容可能なパフォーマンス。 この方法は、満足できるパフォーマンスを提供する可能性があります。 待機時間の影響を受けやすいワークロードの場合:パフォーマンスが低い。 コンポーネントが同じ可用性ゾーンに配置されるとは限らないため、待機時間の影響を受けやすいコンポーネントのパフォーマンスが低下する可能性があります。 |
| オペレーショナル エクセレンス | 高い運用効率。 デプロイして管理する必要があるのは、各リソースの 1 つのインスタンスだけです。 |
次の表は、アーキテクチャの観点から、いくつかの懸念事項をまとめたものです。
| アーキテクチャに関する懸念事項 | 影響 |
|---|---|
| データ所在地のコンプライアンス | 高 。 この方法を使用するソリューションをデプロイすると、選択した Azure リージョンにデータが格納されます。 |
| リージョン別の提供状況 | 高 。 この方法は、任意の Azure リージョンで使用できます。 |
リージョン間でのバックアップを使用したローカル冗長デプロイ
インフラストラクチャとデータの定期的なバックアップをセカンダリ リージョンに実行することで、ローカル冗長デプロイを拡張できます。 このアプローチにより、プライマリ リージョンでの停止を軽減するための保護レイヤーが追加されます。 次のように表示されます。
このアプローチを実装するときは、RTO と RPO を慎重に検討する必要があります。
- 復旧時間: リージョンの停止が発生した場合は、別の Azure リージョンでソリューションのリビルドが必要になることがあります。これは復旧時間に影響します。 大規模な障害が発生した場合に別のリージョンにすばやく再デプロイできるように、コードとしてのインフラストラクチャ (IaC) アプローチを使用してソリューションを構築することを検討してください。 障害が発生した場合でもソリューションの再デプロイに使用できるように、デプロイ ツールとプロセスの回復性がアプリケーションと同じであることを確認します。 ソリューションを動作状態に戻すために必要な手順を計画してリハーサルします。
- 復旧ポイント: バックアップの頻度によって、発生する可能性があるデータ損失の量 (復旧ポイント) が決まります。 通常、バックアップの頻度を制御して、RPO を満たすことができます。
次の表は、重要な問題の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 中程度の信頼性。 データセンターで障害が発生した場合、サービスは停止の影響を受けます。 データは地理的に分離されたリージョンに非同期的にバックアップされるため、データ損失を最小限に抑えることで、リージョン全体の停止の影響が軽減されます。 リージョン全体の停止では、操作を別のリージョンに手動で復元できます。 ただし、復旧プロセスは複雑になる可能性があり、他のリージョンに手動で復元するには時間がかかる場合があります。 |
| コストの最適化 | 低コスト。 通常、バックアップを別のリージョンに追加すると、ローカル冗長リソースをデプロイするよりも少しだけコストがかかります。 |
| パフォーマンス効率 | ほとんどのワークロードの場合:許容可能なパフォーマンス。 この方法は、満足できるパフォーマンスを提供する可能性があります。 待機時間の影響を受けやすいワークロードの場合:パフォーマンスが低い。 コンポーネントが同じ可用性ゾーンに配置されるとは限らないため、待機時間の影響を受けやすいコンポーネントのパフォーマンスが低下する可能性があります。 |
| オペレーショナル エクセレンス | リージョン内の停止中:運用効率が低い。 フェールオーバーはユーザーの責任であり、手動操作と再デプロイが必要になる場合があります。 |
次の表は、アーキテクチャの観点から、いくつかの懸念事項をまとめたものです。
| アーキテクチャに関する懸念事項 | 影響 |
|---|---|
| データ所在地のコンプライアンス | リージョンの選択によって異なります。 データは、主に指定した Azure リージョンに格納されます。 ただし、バックアップを保存するには別のリージョンを選択する必要があるため、データ所在地の要件と互換性のあるリージョンを選択することが重要です。 |
| リージョン別の提供状況 | 高 。 この方法は、任意の Azure リージョンで使用できます。 |
展開方法 2: ゾーン (固定) デプロイ
ゾーンデプロイでは、リソースを特定の可用性ゾーンにデプロイするように指定します。 この方法は、ゾーン固定デプロイと呼ばれることもあります。
ゾーン方式を使用すると、コンポーネント間の待機時間が短縮されます。 ただし、それ自体では、ソリューションの回復性は向上しません。 回復性を高めるためには、コンポーネントの複数のインスタンスを複数の可用性ゾーンにデプロイし、各インスタンス間でトラフィックをルーティングする方法を決定する必要があります。 この例では、アクティブ/パッシブ トラフィック ルーティングアプローチを示します。
前の例では、ロード バランサーが複数の可用性ゾーンにデプロイされています。 ゾーンの停止がそのゾーンにデプロイされているネットワーク リソースにも影響を与える可能性があるため、異なる可用性ゾーン内のインスタンス間でトラフィックをルーティングする方法を検討することが重要です。 また、リージョンにまったくデプロイされていない Azure Front Door や Azure Traffic Manager などのグローバル ロード バランサーの使用を検討することもできます。
ゾーン デプロイ モデルを使用する場合は、多くの責任を負います。
- 各可用性ゾーンにリソースをデプロイし、それらのリソースを個別に構成および管理する必要があります。
- 可用性ゾーン間でデータをレプリケートする方法とタイミングを決定し、レプリケーションを構成して管理する必要があります。
- ロード バランサーなどを使用して、要求を適切なリソースに配布する必要があります。 ロード バランサーが回復性の要件を満たしていることを確認する必要があります。 また、アクティブ/パッシブまたはアクティブ/アクティブのどちらの要求分散モデルを使用するかを決定する必要があります。
- 可用性ゾーンで障害が発生した場合は、フェールオーバーを処理して、別の可用性ゾーン内のリソースにトラフィックを送信する必要があります。
複数の可用性ゾーンにまたがるアクティブ/パッシブデプロイは、リージョン内 DR または Metro DR と呼ばれることもあります。
次の表は、重要な問題の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 単一の可用性ゾーンにデプロイする場合:信頼性が低い。 ゾーン展開では、データセンターまたは可用性ゾーンの停止に対する回復性は提供されません。 高い回復性を実現するには、複数の可用性ゾーンに冗長リソースをデプロイする必要があります。 複数の可用性ゾーンにデプロイする場合:高い信頼性。 サービスは、データセンターまたは可用性ゾーンの停止に対する回復性を高めることができます。 |
| コストの最適化 | 単一の可用性ゾーンにデプロイする場合:低コスト。 単一ゾーンデプロイでは、各リソースのインスタンスが 1 つだけ必要です。 複数の可用性ゾーンにデプロイする場合:高コスト。 リソースの複数のインスタンスをデプロイすると、それぞれに個別に課金されます。 |
| パフォーマンス効率 | 高パフォーマンス。 要求を処理するコンポーネントが同じ可用性ゾーンにある場合、待機時間は非常に短くなる可能性があります。 |
| オペレーショナル エクセレンス | 低い運用効率。 サービスの複数のインスタンスを構成して管理する必要があります。 可用性ゾーン間でデータをレプリケートする必要があります。 可用性ゾーンの停止中は、フェールオーバーがユーザーの責任となります。 |
次の表は、アーキテクチャの観点から、いくつかの懸念事項をまとめたものです。
| アーキテクチャに関する懸念事項 | 影響 |
|---|---|
| データ所在地のコンプライアンス | 高 。 この方法を使用するソリューションをデプロイすると、選択した Azure リージョンにデータが格納されます。 |
| リージョン別の提供状況 | 可用性ゾーンを持つリージョン。 この方法は、可用性ゾーンをサポートする任意のリージョンで使用できます。 |
このアプローチは、通常、仮想マシンに基づくワークロードに使用されます。 ゾーン展開をサポートするサービスの完全な一覧については、可用性ゾーン のサービスとリージョンのサポートに関する説明を参照してください。
ゾーンデプロイを計画するときは、使用する Azure サービスが、使用する予定の可用性ゾーンでサポートされていることを確認します。 たとえば、各可用性ゾーンで使用できる仮想マシン SKU を一覧表示するには、「VM SKU の可用性を確認する」を参照してください。
ヒント
特定の可用性ゾーンにリソースをデプロイするときは、ゾーン番号を選択します。 ゾーン番号のシーケンスは、Azure サブスクリプションごとに異なります。 複数の Azure サブスクリプションにリソースをデプロイする場合は、各サブスクリプションで使用する必要があるゾーン番号を確認します。 詳細については、「物理ゾーンと可用性ゾーン」を参照してください。
展開方法 3: ゾーン冗長デプロイ
この方法を使用すると、アプリケーション層が複数の可用性ゾーンに分散されます。 要求が到着すると、(それ自体が可用性ゾーンにまたがる) サービスに組み込まれているロード バランサーによって、各可用性ゾーン内のインスタンス間で要求が分散されます。 可用性ゾーンで障害が発生した場合、ロード バランサーは、正常な可用性ゾーン内のインスタンスにトラフィックを転送します。
ストレージ層は、複数の可用性ゾーンにも分散されます。 アプリケーションのデータのコピーは、同期レプリケーションを介して複数の可用性ゾーンに分散されます。 アプリケーションがデータに変更を加えると、ストレージ サービスによって変更が複数の可用性ゾーンに書き込まれます。トランザクションは、これらの変更がすべて完了した場合にのみ完了と見なされます。 このプロセスにより、各可用性ゾーンにデータの最新のコピーが常に存在することが保証されます。 可用性ゾーンで障害が発生した場合は、別の可用性ゾーンを使用して同じデータにアクセスできます。
ゾーン冗長アプローチを使用すると、データセンターの停止などの問題に対するソリューションの回復性が向上します。 ただし、データは同期的にレプリケートされるため、アプリケーションは、大都市圏のさまざまな部分にある可能性のある複数の異なる場所にデータが書き込まれるのを待つ必要があります。 ほとんどのアプリケーションでは、ゾーン間通信に関係する待機時間はごくわずかです。 ただし、待機時間の影響を受けやすいワークロードによっては、可用性ゾーン間の同期レプリケーションがアプリケーションのパフォーマンスに影響する可能性があります。
次の表は、重要な問題の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 高い信頼性。 サービスは、データセンターまたは可用性ゾーンの停止に対する回復性があります。 データは可用性ゾーン間で同期的にレプリケートされ、遅延はありません。 |
| コストの最適化 | 中程度のコスト。 使用するサービスによっては、ゾーンの冗長性を有効にするために、より高いサービス レベルに対して一部のコストが発生する場合があります。 |
| パフォーマンス効率 | ほとんどのワークロードの場合:許容可能なパフォーマンス。 この方法は、満足できるパフォーマンスを提供する可能性があります。 待機時間の影響を受けやすいワークロードの場合:パフォーマンスが低い。 一部のコンポーネントは、ゾーン間トラフィックまたはデータ レプリケーション時間のために待機時間の影響を受ける可能性があります。 |
| オペレーショナル エクセレンス | 高い運用効率。 通常は、各リソースの 1 つの論理インスタンスのみを管理する必要があります。 ほとんどのサービスでは、可用性ゾーンの停止中に、フェールオーバーは Microsoft の責任であり、自動的に実行されます。 |
次の表は、アーキテクチャの観点から、いくつかの懸念事項をまとめたものです。
| アーキテクチャに関する懸念事項 | 影響 |
|---|---|
| データ所在地のコンプライアンス | 高 。 この方法を使用するソリューションをデプロイすると、選択した Azure リージョンにデータが格納されます。 |
| リージョン別の提供状況 | 可用性ゾーンを持つリージョン。 この方法は、可用性ゾーンをサポートする任意のリージョンで使用できます。 |
このアプローチは、Azure Virtual Machine Scale Sets、Azure アプリ Service、Azure Functions、Azure Kubernetes Service、Azure Storage、Azure SQL、Azure Service Bus など、多くの Azure サービスで可能です。 ゾーンの冗長性をサポートするサービスの完全な一覧については、可用性ゾーン のサービスとリージョンのサポートに関する説明を参照してください。
リージョン間でのバックアップを使用したゾーン冗長デプロイ
インフラストラクチャとデータの定期的なバックアップをセカンダリ リージョンに実行することで、ゾーン冗長デプロイを拡張できます。 このアプローチにより、ゾーン冗長アプローチの利点が得られ、完全なリージョン停止が発生する可能性が非常に低い場合を軽減するための保護レイヤーが追加されます。
このアプローチを実装するときは、RTO と RPO を慎重に検討する必要があります。
復旧時間: リージョンの停止が発生した場合は、別の Azure リージョンでソリューションのリビルドが必要になることがあります。これは復旧時間に影響します。 大規模な障害発生時に別のリージョンにすばやく再デプロイできるように、IaC アプローチを使用してソリューションを構築することを検討してください。 障害が発生した場合でもソリューションの再デプロイに使用できるように、デプロイ ツールとプロセスの回復性がアプリケーションと同じであることを確認します。 ソリューションを稼働状態に戻すために必要な手順を計画してリハーサルします。
復旧ポイント: バックアップの頻度によって、発生する可能性があるデータ損失の量 (復旧ポイント) が決まります。 通常、RPO を満たすようにバックアップの頻度を制御できます。
ヒント
このアプローチは、多くの場合、すべてのアーキテクチャ上の問題に対して適切なバランスを提供します。 使用する方法がわからない場合は、この種類のデプロイから始めます。
次の表は、重要な問題の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 非常に高い信頼性。 サービスは、データセンターまたは可用性ゾーンの停止に対する回復性があります。 ほとんどのサービスでは、データはゾーン間で自動的にレプリケートされ、遅延はありません。 データは、地理的に分離されたリージョンに非同期的にバックアップされます。 このバックアップは、データ損失を最小限に抑えることで、リージョン全体の停止の影響を軽減します。 リージョン全体の停止後、操作を別のリージョンに手動で復元できます。 ただし、復旧プロセスは複雑になる可能性があり、他のリージョンに手動で復元するには時間がかかる場合があります。 |
| コストの最適化 | 中程度のコスト。 通常、バックアップを別のリージョンに追加すると、ゾーンの冗長性を実装するよりも少しだけコストがかかります。 |
| パフォーマンス効率 | ほとんどのワークロードの場合:許容可能なパフォーマンス。 この方法は、満足できるパフォーマンスを提供する可能性があります。 待機時間の影響を受けやすいワークロードの場合:パフォーマンスが低い。 一部のコンポーネントは、ゾーン間トラフィックまたはデータ レプリケーション時間のために待機時間の影響を受ける可能性があります。 |
| オペレーショナル エクセレンス | 可用性ゾーンの停止中:高い運用効率。 フェールオーバーは Microsoft の責任であり、自動的に行われます。 リージョンの停止中:運用効率が低い。 フェールオーバーはユーザーの責任であり、手動操作と再デプロイが必要になる場合があります。 |
次の表は、アーキテクチャの観点から、いくつかの懸念事項をまとめたものです。
| アーキテクチャに関する懸念事項 | 影響 |
|---|---|
| データ所在地のコンプライアンス | リージョンの選択によって異なります。 データは主に指定した Azure リージョンに格納されますが、バックアップを格納するには別のリージョンを選択する必要があります。 データ所在地の要件と互換性のあるリージョンを選択します。 |
| リージョン別の提供状況 | 可用性ゾーンを持つリージョン。 この方法は、可用性ゾーンをサポートする任意のリージョンで使用できます。 |
展開方法 4: 複数リージョンのデプロイ
複数の Azure リージョンを一緒に使用して、幅広い地理的領域にソリューションを分散できます。 このマルチリージョン アプローチを使用して、ソリューションの信頼性を向上させたり、地理的に分散したユーザーをサポートしたりできます。 複数のリージョンにデプロイすることで、1 つのリージョンで一時的なリソース容量の制約が発生するリスクも軽減できます。 データ所在地がソリューションにとって重要な懸念事項である場合は、使用するリージョンを慎重に検討して、要件を満たす場所にのみデータが格納されるようにします。
アクティブリージョンとパッシブリージョン
マルチリージョン アーキテクチャは複雑であり、マルチリージョン ソリューションを設計する方法は多数あります。 一部のワークロードでは、複数のリージョンで同時に要求をアクティブに処理する (アクティブ/アクティブなデプロイ) の方が理にかなっています。 他のワークロードの場合は、1 つの プライマリ リージョン を指定し、フェールオーバーに 1 つ以上 のセカンダリ リージョン (アクティブ/パッシブ デプロイ) を使用することをお勧めします。 このセクションでは、あるリージョンがアクティブで、もう 1 つがパッシブである 2 番目のシナリオについて説明します。 アクティブ/アクティブなマルチリージョン ソリューションの詳細については、「デプロイ スタンプ パターンと Geode パターン」を参照してください。
データのレプリケーション
リージョン間の通信は、リージョン内の通信よりもはるかに遅くなります。 一般に、2 つのリージョン間の地理的距離が大きいほど、データが移動する必要がある物理的な距離が長くなるため、ネットワーク待機時間が長くなります。 2 つのリージョン間で接続するときの予想されるネットワーク待機時間については、Azure ネットワークラウンドトリップ待機時間の統計情報を参照してください。
リージョン間のネットワーク待機時間は、追加の待機時間がデータ レプリケーションやその他のトランザクションに与える影響を慎重に検討する必要があるため、ソリューション設計に大きな影響を与える可能性があります。 多くのソリューションでは、リージョン間のトラフィックがパフォーマンスに及ぼす影響を最小限に抑えるために、リージョン間アーキテクチャでは非同期レプリケーションが必要です。
非同期データ レプリケーション
リージョン間で非同期レプリケーションを実装する場合、アプリケーションはすべてのリージョンが変更を確認するまで待機しません。 プライマリ リージョンで変更がコミットされると、トランザクションは完了と見なされます。 変更は後でセカンダリ リージョンにレプリケートされます。 この方法により、リージョン間の接続待機時間がアプリケーションのパフォーマンスに直接影響を与えることはありません。 ただし、レプリケーションの遅延により、リージョン全体の停止によってデータが失われる可能性があります。 このデータ損失は、プライマリ リージョンで書き込みが完了した後、変更を別のリージョンにレプリケートする前に、リージョンで障害が発生する可能性があるために発生する可能性があります。
次の表は、重要な問題の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 高い信頼性。 このソリューションは、データセンター、可用性ゾーン、またはリージョン全体の停止に対する回復性があります。 データはレプリケートされますが、同期できない可能性があるため、フェールオーバー シナリオではデータ損失が発生する可能性があります。 |
| コストの最適化 | コストが高い。 リージョンごとに個別のリソースをデプロイする必要があり、各リソースにはデプロイとメインのコストが発生します。 リージョン間のデータ レプリケーションでも、大きなコストが発生する可能性があります。 |
| パフォーマンス効率 | 高パフォーマンス。 アプリケーション要求ではリージョンをまたがるトラフィックは必要ないため、通常、トラフィックの待機時間は短くなります。 |
| オペレーショナル エクセレンス | 低い運用効率。 複数のリージョンにまたがってリソースをデプロイおよび管理する必要があります。 また、リージョンの停止中にリージョン間のフェールオーバーを行う必要もあります。 |
次の表は、アーキテクチャの観点から、いくつかの懸念事項をまとめたものです。
| アーキテクチャに関する懸念事項 | 影響 |
|---|---|
| データ所在地のコンプライアンス | リージョンの選択によって異なります。 この方法では、ワークロードを実行する複数のリージョンを選択する必要があります。 データ所在地の要件と互換性のあるリージョンを選択します。 |
| リージョン別の提供状況 | 多くの Azure リージョン がペアになっています。 一部の Azure サービスでは、ペアになっているリージョンを使用してデータが自動的にレプリケートされます。 ペアがないリージョンでワークロードを実行する場合は、別の方法を使用してデータをレプリケートすることが必要になる場合があります。 |
同期データ レプリケーション
同期マルチリージョン ソリューションを実装する場合、アプリケーションは、各 Azure リージョンで書き込み操作が完了するのを待ってから、トランザクションが完了したと見なす必要があります。 書き込み操作を待機することによって発生する待機時間は、リージョン間の距離によって異なります。 多くのワークロードでは、リージョン間の待機時間により、同期レプリケーションが遅すぎて役に立たなくなります。
次の表は、重要な問題の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 非常に高い信頼性。 このソリューションは、データセンター、可用性ゾーン、またはリージョン全体の停止に対する回復性があります。 データはリージョン間で常に同期されるため、リージョン全体の損失が発生した場合でも、データは別のリージョンで使用でき、完全になります。 |
| コストの最適化 | コストが高い。 リージョンごとに個別のリソースをデプロイする必要があり、各リソースにはデプロイとメインのコストが発生します。 リージョン間のデータ レプリケーションでも、大きなコストが発生する可能性があります。 |
| パフォーマンス効率 | 低パフォーマンス。 アプリケーション要求にはリージョン間トラフィックが必要です。 リージョン間の距離によっては、同期レプリケーションによって要求に大幅な待機時間が追加される場合があります。 |
| オペレーショナル エクセレンス | 低い運用効率。 複数のリージョンにまたがってリソースをデプロイおよび管理する必要があります。 また、リージョンの停止中にリージョン間のフェールオーバーを行う必要もあります。 |
次の表は、アーキテクチャの観点から、いくつかの懸念事項をまとめたものです。
| アーキテクチャに関する懸念事項 | 影響 |
|---|---|
| データ所在地のコンプライアンス | リージョンの選択によって異なります。 この方法では、ワークロードを実行する複数のリージョンを選択する必要があります。 データ所在地の要件と互換性のあるリージョンを選択します。 |
| リージョン別の提供状況 | 多くの Azure リージョン がペアになっています。 一部の Azure サービスでは、ペアになっているリージョンを使用してデータが自動的にレプリケートされます。 ペアがないリージョンでワークロードを実行する場合は、別の方法を使用してデータをレプリケートすることが必要になる場合があります。 |
リージョン アーキテクチャ
マルチリージョン ソリューションを設計するときは、使用する予定の Azure リージョンがペアになっているかどうかを検討してください。
リージョンがペアになっていない場合でも、マルチリージョン ソリューションを作成できます。 ただし、マルチリージョン アーキテクチャを実装するために使用する方法は異なる場合があります。 たとえば、Azure Storage では、ペアになっているリージョンで geo 冗長ストレージ (GRS) を使用できます。 GRS を使用できない場合は、Azure Storage オブジェクト レプリケーションなどの機能を使用するか、複数のリージョンに書き込むようにアプリケーションを設計することを検討してください。
マルチゾーンとマルチリージョンのアプローチを組み合わせる
ビジネス要件でこのようなソリューションが必要な場合は、マルチゾーンステートメントとマルチリージョン ステートメントを組み合わせる必要があります。 たとえば、ゾーン冗長コンポーネントを各リージョンにデプロイし、リージョン間のレプリケーションを構成することもできます。 一部のソリューションでは、このアプローチは非常に高い信頼性を提供します。 ただし、この種類のアプローチの構成は複雑になる可能性があり、このアプローチはコストがかかる場合があります。
重要
ミッション クリティカルなワークロードでは、複数の可用性ゾーン と 複数のリージョンの両方を使用する必要があります。 ミッション クリティカルなワークロードを設計するときに指定する必要がある考慮事項の詳細については、ミッション クリティカルなワークロードのドキュメントを参照してください。
Azure サービスがデプロイ アプローチをサポートする方法
使用する Azure サービスの具体的な詳細を理解することが重要です。 たとえば、一部の Azure サービスでは、最初にリソースをデプロイするときに可用性ゾーンの構成を構成する必要があります。また、後でデプロイ アプローチの変更をサポートするサービスもあります。 同様に、一部のサービス機能は、すべてのデプロイ アプローチで使用できない場合があります。
Azure サービスごとに考慮する特定のデプロイ オプションとアプローチの詳細については、信頼性ハブを参照してください。
例
このセクションでは、一般的なユース ケースと、各ワークロードで通常考慮する必要がある主な要件について説明します。 ワークロードごとに、この記事で説明されている要件とアプローチに基づいて、1 つ以上の推奨されるデプロイ アプローチが提供されます。
企業向けの基幹業務アプリケーション
Contoso, Ltd. は、大規模な製造会社です。 同社は、財務プロセスの一部のコンポーネントを管理するための基幹業務アプリケーションを実装しています。
ビジネス要件: システムが管理する情報を置き換えるのが難しいため、データを確実に保持する必要があります。 アーキテクトは、システムで発生するダウンタイムをできるだけ少なくし、データ損失をできるだけ少なくする必要があると言います。 Contoso の従業員は稼働日を通じてシステムを使用するため、チーム メンバーの待機を回避するには高パフォーマンスが重要です。 財務チームがソリューションに対して支払う必要があるため、コストも問題になります。
推奨されるアプローチ: リージョン 間のバックアップを使用したゾーン冗長デプロイでは、高パフォーマンスで複数の回復性レイヤーが提供されます。
内部アプリケーション
4番目のコーヒーは中小企業です。 この会社では、従業員がタイムシートの送信に使用できる新しい内部アプリケーションを開発しています。
ビジネス要件: このワークロードでは、コスト効率が主な懸念事項です。 Fourth Coffee はダウンタイムのビジネスへの影響を評価し、アプリケーションが回復性やパフォーマンスに優先順位を付ける必要はないことを判断しました。 会社は、Azure 可用性ゾーンまたはリージョンで障害が発生すると、アプリケーションが一時的に使用できなくなるリスクを受け入れます。
推奨されるアプローチ:
- リージョン 間のバックアップを使用したローカル冗長デプロイは、コストが最も低くなりますが、重大なリスクもあります。
- リージョン 間のバックアップを使用したゾーン冗長デプロイでは、回復性が向上しますが、コストは若干高くなります。
レガシ アプリケーションの移行
Fabrikam, Inc.は、オンプレミスのデータセンターから Azure にレガシ アプリケーションを移行しています。 この実装では、仮想マシンに基づく IaaS アプローチが使用されます。 アプリケーションはクラウド環境用に設計されておらず、アプリケーション層とデータベースの間の通信は非常に 煩雑です。
ビジネス要件: パフォーマンスは、このアプリケーションの優先順位です。 回復性も重要であり、Azure データセンターで障害が発生した場合でも、アプリケーションは引き続き動作する必要があります。
推奨されるアプローチ:
- Fabrikan では、まずゾーン冗長デプロイを試す必要があります。 パフォーマンスが要件を満たしていることを確認する必要があります。
- ゾーン冗長ソリューションのパフォーマンスが許容できない場合は、ゾーン (固定) デプロイを検討し、複数の可用性ゾーン (リージョン内 DR) にまたがるパッシブ デプロイを使用します。
医療アプリケーション
Lamna Healthcare Company は、Azure に新しい電子医療記録システムを実装しています。
ビジネス要件: このソリューションが格納するデータの性質上、データ所在地は非常に重要です。 Lamna は、特定の場所でデータを再メインする必要があることを義務付ける厳格な規制フレームワークの下で動作します。
推奨されるアプローチ:
- Lamna のデータ所在地の要件に適合する複数のリージョンがある場合は、マルチゾーンマルチリージョンデプロイ。
- ニーズに合ったリージョンが 1 つだけの場合は、ゾーン冗長デプロイ、またはリージョン間のバックアップを使用したゾーン冗長デプロイを検討すると、単一リージョン ソリューションが提供されます
銀行取引システム
Woodgrove Bank は、Azure にデプロイされた大規模なソリューションからコア バンキング操作を実行します。
ビジネス要件: これはミッション クリティカルなシステムです。 障害が発生すると、お客様に大きな財務上の影響が生じる可能性があります。 その結果、ウッドグローブ銀行のリスク許容度は非常に低くなります。 システムには、可能な限り最高レベルの信頼性が必要であり、アーキテクチャでは、軽減できる障害のリスクを軽減する必要があります。
推奨されるアプローチ: ミッション クリティカルなシステムの場合は、マルチゾーンマルチリージョンデプロイを 使用します。 リージョンが会社のデータ所在地の要件に適合していることを確認します。
サービスとしてのソフトウェア (SaaS)
Proseware, Inc.は、世界中の企業が使用するソフトウェアを構築しています。 会社のユーザー ベースは地理的に広く分散されています。
ビジネス要件: Proseware では、各顧客が顧客に近いデプロイ リージョンを選択できるようにする必要があります。 この選択を有効にすることは、待機時間と顧客のデータ所在地の要件にとって重要です。
推奨されるアプローチ:
- マルチゾーン のマルチリージョンデプロイは、通常、SaaS プロバイダー (特にデプロイ スタンプ パターン内で使用される場合) に適しています。
- Azure Front Door などのグローバル トラフィック 高速化ソリューションと組み合わせた単一リージョンのゾーン冗長デプロイ。
関連リンク
マルチゾーンおよびマルチリージョン ソリューションの参照アーキテクチャとシナリオ例を次に示します。
- ベースライン高可用性ゾーン冗長 Web アプリケーション
- 可用性の高い複数リージョンの Web アプリケーション
- マルチリージョン n 層アプリケーション
- HA/DR 用に構築された多階層 Web アプリケーション
多くの Azure サービスでは、次の例を含む複数の可用性ゾーンの使用方法に関するガイダンスが提供されています。
- Azure Site Recovery: 可用性ゾーン間の Azure VM ディザスター リカバリーを有効にする
- Azure NetApp Files: Azure NetApp Files のクロスゾーン レプリケーションについて
- Azure Storage の冗長性
信頼性チェックリスト
推奨事項の完全なセットを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示