アベイラビリティ ゾーンとリージョンを使用するための推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:05 | 異なるレベルで冗長性を追加します (特に、重要なフローの場合)。 特定された信頼性目標に従って、コンピューティング、データ、ネットワーク、その他のインフラストラクチャ層に冗長性を適用します。 |
|---|
関連ガイド: 高可用性マルチリージョン デザイン | 冗長性
このガイドでは、可用性ゾーンまたはリージョン間でワークロードをデプロイするタイミングを決定するための推奨事項について説明します。
Azure のソリューションを設計する場合、1 つのリージョン内の複数の可用性ゾーン間でデプロイするか、複数のリージョンにデプロイするかを決定する必要があります。 この決定は、ソリューションの信頼性、コスト、パフォーマンス、ソリューションを運用するチームの能力に影響します。 このガイドでは、決定に影響を与える主要なビジネス要件、検討できるアプローチ、各アプローチに関連するトレードオフ、Azure Well-Architected フレームワークの中心的な柱に対する各アプローチの影響に関する情報を提供します。
ソリューションに使用する最適な Azure リージョンに関する決定は、重要な選択事項です。 Azure リージョンの選択ガイドでは、複数の地理的リージョンで選択して操作する方法について説明しています。 ソリューション内でリージョンと可用性ゾーンを使用する方法を選択すると、Well-Architected フレームワークのいくつかの柱にも影響します。
- 信頼性: デプロイ アプローチを選択すると、さまざまな種類のリスクを軽減するのに役立ちます。 一般に、より地理的に分散した地域間でワークロードを分散させることで、より高い回復性を実現できます。
- コストの最適化: 一部のアーキテクチャ アプローチでは、他のアプローチ方法よりも多くのリソースをデプロイする必要があるため、リソース コストが増加する可能性があります。 その他のアプローチでは、地理的に分離された可用性ゾーンまたはリージョン間でデータを送信する必要があるため、ネットワーク トラフィックの料金が発生する可能性があります。 また、リソースの管理の継続的なコストを考慮することも重要です。これは通常、包括的なビジネス要件がある場合に高くなります。
- パフォーマンス効率: 可用性ゾーンは、帯域幅が広い低遅延のネットワーク リンクを介して接続されます。これは、ほとんどのワークロードでゾーン間の同期レプリケーションと通信を有効にするのに十分です。 ただし、ワークロードがテスト済みで、ゾーン間のネットワーク待ち時間の影響を受けやすい場合は、ワークロードのコンポーネントを物理的に近づけて配置して通信時の待ち時間を最小限に抑えることを検討する必要があります。
- オペレーショナル エクセレンス: 複雑なアーキテクチャでは、デプロイ、構成、管理にさらに労力がかかります。 また、高可用性ソリューションの場合は、リソースのセカンダリ セットにフェールオーバーする方法を計画することが必要になる場合があります。 フェールオーバー、フェールバック、トラフィックの透過的なリダイレクトは、特に手動の手順が必要な場合に複雑になる可能性があります。 デプロイと管理のプロセスを自動化することをお勧めします。 詳細については、｢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 がサービスに更新を展開する場合、最も中断が少ない方法であるアプローチを使用しようとします。 たとえば、Microsoft は、更新を一度に単一の可用性ゾーンにデプロイすることを目的としています。 このアプローチでは、更新処理中もその他のゾーンでワークロードを引き続き実行できるため、更新がアクティブなワークロードに与える影響を軽減できます。 ただし、最終的にはワークロード チームが、プラットフォームのアップグレード中にワークロードが機能し続けるようにする責任を負います。 たとえば、フレキシブル オーケストレーション モードを使用した Virtual Machine Scale Sets またはほとんどの Azure PaaS サービスを使用する場合、Azure により、リソースがインテリジェントに配置され、プラットフォームの更新の影響が軽減されます。 また、一部のインスタンスが使用可能なままでありながら、その他のインスタンスがアップグレードされるようにするために、オーバープロビジョニング (リリースのより多くのインスタンスをデプロイすること) を検討することもできます。 Azure で更新をデプロイする方法の詳細については、「安全なデプロイ プラクティスの推進」を参照してください。
多くのリージョンには、ペアになっているリージョンもあります。 ペアになっているリージョンは、ある種のマルチリージョン デプロイのアプローチをサポートします。 いくつかの新しいリージョンには複数の可用性ゾーンがあり、ペアになっているリージョンはありません。 これらのリージョンにマルチ リージョン ソリューションをデプロイすることはできますが、使用するアプローチは異なる場合があります。
Azure がリージョンと可用性ゾーンを使用する方法の詳細については、「Azure リージョンと可用性ゾーンとは」を参照してください。
共同責任について理解する
共同責任原則では、クラウド プロバイダー (Microsoft) と顧客の間で責任を分担する方法について説明します。 利用するサービスの種類によっては、サービスの運用に多かれ少なかれ責任を負う可能性があります。
Microsoft は、可用性ゾーンとリージョンを提供することで、顧客の要件を満たすソリューションの設計方法に柔軟性を持たせています。 マネージド サービスを利用する場合、Microsoft は顧客のリソースの管理責任をさらに引き受け、データ レプリケーション、フェールオーバー、フェールバック、および分散システムの運用に関連するその他のタスクを含む可能性もあります。
独自のコードでは、エラーを適切に処理するために推奨されるプラクティスと設計パターンを使用する必要があります。 これらのプラクティスは、可用性ゾーンまたはリージョンのフェールオーバーが発生した場合など、フェールオーバー操作中にさらに重要になります。なぜなら、ゾーンまたはリージョン間のフェールオーバーでは通常、アプリケーションがサービスへの接続を再試行する必要があるためです。
主要なビジネス要件とワークロード要件を特定する
ソリューションで可用性ゾーンとリージョンを使用する方法について十分な情報を得たうえでの決定を下すには、要件を理解する必要があります。 これらの要件は、ソリューション デザイナーとビジネス利害関係者との間の議論によって推進される必要があります。
リスク許容度
組織が異なると、リスク許容度も異なります。 1 つの組織内でさえ、多くの場合、リスク許容度はワークロードごとに異なります。 ほとんどのワークロードでは、極度な高可用性は必要ありません。 ただし、一部のワークロードは非常に重要であるため、広範な地理的地域に影響を与える大規模な自然災害など、発生する可能性が低いリスクを軽減することに価値があることを把握することが重要です。
次の表に、クラウド環境で考慮する必要がある一般的なリスクのいくつかを示します。
| リスク | 例 | 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 のグローバル展開を使用してユーザー エクスペリエンスを向上させ、アプリケーションをユーザー ベースに近接できます。 デプロイ スタンプ パターンまたは Geode パターンを使用したり、リソースを複数のリージョン間でレプリケートしたりできます。
ユーザーが地理的に異なる地域にいる場合でも、複数リージョンのデプロイが必要かどうかを検討してください。 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 またはメトロ DR と呼ばれることもあります。
次の表は、柱となる懸念の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 単一の可用性ゾーンにデプロイする場合: 低い信頼性。ゾーン デプロイでは、データセンターまたは可用性ゾーンの停止に対する回復性は提供されません。 高い回復性を実現するには、複数の可用性ゾーン間で冗長リソースをデプロイする必要があります。 複数の可用性ゾーンにデプロイする場合: 高い信頼性。データセンターまたは可用性ゾーンの停止に対してサービスの回復性を高めることができます。 |
| コストの最適化 | 単一の可用性ゾーンにデプロイする場合: 低コスト。単一ゾーン デプロイで必要なのは、各リソースのインスタンス 1 つのみです。 複数の可用性ゾーンにデプロイする場合: 高コスト。リソースの複数のインスタンスをデプロイすると、それぞれが個別に課金されます。 |
| パフォーマンス効率 | 高パフォーマンス。 要求を処理するコンポーネントが同じ可用性ゾーン内にある場合、待ち時間が非常に短くなる可能性があります。 |
| オペレーショナル エクセレンス | 低い運用効率。 サービスの複数のインスタンスを構成して管理する必要があります。 可用性ゾーン間でデータをレプリケートする必要があります。 可用性ゾーンの停止中、フェールオーバーはお客様の責任となります。 |
次の表は、アーキテクチャの観点からいくつかの懸念をまとめたものです。
| アーキテクチャ上の懸念 | 影響 |
|---|---|
| データ所在地への準拠 | 高 。 このアプローチを使用するソリューションをデプロイすると、選択した Azure リージョンにデータが保存されます。 |
| リージョン別の提供状況 | 可用性ゾーンを含むリージョン。 このアプローチは、可用性ゾーンをサポートする任意のリージョンで使用できます。 |
このアプローチは通常、仮想マシンに基づくワークロードに使用されます。 ゾーン デプロイをサポートするサービスの完全なリストについては、「可用性ゾーン サービスとリージョンのサポート」を参照してください。
ゾーン デプロイを計画する場合、使用する Azure サービスが、使用する予定の可用性ゾーンでサポートされていることを確認します。 たとえば、各可用性ゾーンで使用可能な仮想マシン SKU を一覧表示するには、「VM SKU の可用性の確認」を参照してください。
ヒント
特定の可用性ゾーンにリソースをデプロイする場合、ゾーン番号を選択します。 ゾーン番号のシーケンスは、Azure サブスクリプションごとに異なります。 複数の Azure サブスクリプション間でリソースをデプロイする場合、各サブスクリプションで使用する必要があるゾーン番号を確認してください。 詳細については、「物理ゾーンと可用性ゾーン」を参照してください。
デプロイ アプローチ 3: ゾーン冗長デプロイ
このアプローチを使用する場合、アプリケーション層が複数の可用性ゾーン間で分散されます。 要求が到着すると、サービスに組み込まれているロード バランサー (それ自体が複数の可用性ゾーンにまたがっています) により、各可用性ゾーン内のインスタンス間で要求が分散されます。 可用性ゾーンで停止が発生した場合、ロード バランサーにより、正常な可用性ゾーン内のインスタンスにトラフィックが転送されます。
ストレージ層も、複数の可用性ゾーン間で分散されます。 アプリケーションのデータのコピーが、同期レプリケーションを介して複数の可用性ゾーン間で分散されます。 アプリケーションによってデータに変更が加えられると、ストレージ サービスにより、複数の可用性ゾーンに変更が書き込まれます。このトランザクションは、これらの変更がすべて完了した場合にのみ完了と見なされます。 このプロセスにより、各可用性ゾーンにデータの最新のコピーが常に存在することが保証されます。 可用性ゾーンで停止が発生した場合は、別の可用性ゾーンを使用して同じデータにアクセスできます。
ゾーン冗長アプローチを使用すると、データセンターの停止などの問題に対するソリューションの回復性が高まります。 ただし、データは同期的にレプリケートされるため、アプリケーションは、大都市圏のさまざまな地域にある可能性のある複数の異なる場所間でデータが書き込まれるのを待つ必要があります。 ほとんどのアプリケーションでは、ゾーン間通信に関連する待ち時間はごくわずかです。 ただし、待ち時間の影響を受けやすいワークロードの場合、可用性ゾーン間の同期レプリケーションがアプリケーションのパフォーマンスに影響する可能性があります。
次の表は、柱となる懸念の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 高い信頼性。 サービスには、データセンターまたは可用性ゾーンの停止に対する回復性があります。 データは可用性ゾーン間で同期的にレプリケートされ、遅延はありません。 |
| コストの最適化 | 中程度のコスト。 使用するサービスによっては、ゾーン冗長を有効にするために、より高いサービス レベルに対するコストが発生する場合があります。 |
| パフォーマンス効率 | ほとんどのワークロードの場合: 許容されるパフォーマンス。このアプローチは、満足できるパフォーマンスを実現できる可能性が高いです。 待ち時間の影響を受けやすいワークロードの場合: 低いパフォーマンス。一部のコンポーネントは、ゾーン間トラフィックまたはデータ レプリケーション時間が原因で待ち時間の影響を受ける可能性があります。 |
| オペレーショナル エクセレンス | 高い運用効率。 通常、管理する必要があるのは、各リソースの 1 つの論理インスタンスのみです。 ほとんどのサービスでは、可用性ゾーンの停止中、フェールオーバーは Microsoft の責任であり、自動的に実行されます。 |
次の表は、アーキテクチャの観点からいくつかの懸念をまとめたものです。
| アーキテクチャ上の懸念 | 影響 |
|---|---|
| データ所在地への準拠 | 高 。 このアプローチを使用するソリューションをデプロイすると、選択した Azure リージョンにデータが保存されます。 |
| リージョン別の提供状況 | 可用性ゾーンを含むリージョン。 このアプローチは、可用性ゾーンをサポートする任意のリージョンで使用できます。 |
このアプローチは、Azure Virtual Machine Scale Sets、Azure App 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 つのリージョンがアクティブで、もう 1 つがパッシブである 2 番目のシナリオについて説明します。 アクティブ/アクティブなマルチリージョン ソリューションの詳細については、「デプロイ スタンプ パターン」と「Geode パターン」を参照してください。
データのレプリケーション
リージョン間の通信は、リージョン内の通信よりも非常に遅くなります。 一般に、2 つのリージョン間の地理的距離が大きいほど、そのデータが移動する必要がある物理的な距離が長くなるため、ネットワーク待ち時間が長くなります。 2 つのリージョン間で接続するときに予想されるネットワーク待ち時間については、「Azure ネットワーク ラウンドトリップ待ち時間統計」を参照してください。
リージョン間のネットワーク待ち時間は、ソリューション デザインに大きな影響を与える可能性があります。なぜなら、追加の待ち時間がデータ レプリケーションやその他のトランザクションに与える影響を慎重に検討する必要があるからです。 多くのソリューションでは、リージョン間のトラフィックがパフォーマンスに与える影響を最小限に抑えるために、リージョン間アーキテクチャでは非同期レプリケーションが必要です。
非同期データ レプリケーション
リージョン間で非同期レプリケーションを実装する場合、アプリケーションはすべてのリージョンが変更を確認するまで待ちません。 プライマリ リージョンで変更がコミットされると、トランザクションは完了したと見なされます。 この変更は、後でセカンダリ リージョンにレプリケートされます。 このアプローチにより、リージョン間の接続待ち時間がアプリケーションのパフォーマンスに影響を直接与えないようにします。 ただし、レプリケーションの遅延が原因で、リージョン全体の停止の結果としてデータが失われる可能性があります。 このデータ損失が発生する可能性がある理由は、プライマリ リージョンで書き込みが完了した後だが、変更を別のリージョンにレプリケートする前に、リージョンで停止が発生する可能性があるからです。
次の表は、柱となる懸念の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 高い信頼性。 このソリューションには、データセンター、可用性ゾーン、またはリージョン全体の停止に対する回復性があります。 データはレプリケートされますが、同期していない可能性があるため、フェールオーバー シナリオではデータ損失が発生する可能性があります。 |
| コストの最適化 | 高コスト。 リージョンごとに個別のリソースをデプロイする必要があり、リソースごとにデプロイとメンテナンスのコストが発生します。 リージョン間のデータ レプリケーションでも、莫大なコストが発生する可能性があります。 |
| パフォーマンス効率 | 高パフォーマンス。 アプリケーション要求ではリージョン間トラフィックは必要ないため、通常、トラフィックの待ち時間は短くなります。 |
| オペレーショナル エクセレンス | 低い運用効率。 複数のリージョン間でリソースをデプロイおよび管理する必要があります。 また、リージョンの停止中のリージョン間のフェールオーバーに対して責任を負う必要もあります。 |
次の表は、アーキテクチャの観点からいくつかの懸念をまとめたものです。
| アーキテクチャ上の懸念 | 影響 |
|---|---|
| データ所在地への準拠 | リージョンの選択に依存。 このアプローチでは、ワークロードを実行する複数のリージョンを選択する必要があります。 データ所在地の要件と互換性のあるリージョンを選択してください。 |
| リージョン別の提供状況 | 多くの Azure リージョンはペアになっています。 一部の Azure サービスでは、ペアのリージョンを使用してデータが自動的にレプリケートされます。 ペアがないリージョンでワークロードを実行する場合、データをレプリケートするために別のアプローチを使用することが必要な場合があります。 |
同期データ レプリケーション
同期マルチリージョン ソリューションを実装する場合、アプリケーションは、トランザクションが完了したと見なされる前に、各 Azure リージョンで書き込み操作が完了するのを待つ必要があります。 書き込み操作を待つことによって発生する待ち時間は、リージョン間の距離によって異なります。 多くのワークロードでは、リージョン間の待ち時間のために同期レプリケーションが遅すぎて役に立たなくなる可能性があります。
次の表は、柱となる懸念の一部をまとめたものです。
| 重要な要素 | 影響 |
|---|---|
| 信頼性 | 非常に高い信頼性。 このソリューションには、データセンター、可用性ゾーン、またはリージョン全体の停止に対する回復性があります。 データはリージョン間で常に同期されるため、リージョンの全体的な喪失が発生したとしても、データは別のリージョンで完全な状態で使用できます。 |
| コストの最適化 | 高コスト。 リージョンごとに個別のリソースをデプロイする必要があり、リソースごとにデプロイとメンテナンスのコストが発生します。 リージョン間のデータ レプリケーションでも、莫大なコストが発生する可能性があります。 |
| パフォーマンス効率 | 低パフォーマンス。 アプリケーション要求には、リージョン間トラフィックが必要です。 リージョン間の距離によっては、同期レプリケーションによって要求の待ち時間が大幅に長くなる場合があります。 |
| オペレーショナル エクセレンス | 低い運用効率。 複数のリージョン間でリソースをデプロイおよび管理する必要があります。 また、リージョンの停止中のリージョン間のフェールオーバーに対して責任を負う必要もあります。 |
次の表は、アーキテクチャの観点からいくつかの懸念をまとめたものです。
| アーキテクチャ上の懸念 | 影響 |
|---|---|
| データ所在地への準拠 | リージョンの選択に依存。 このアプローチでは、ワークロードを実行する複数のリージョンを選択する必要があります。 データ所在地の要件と互換性のあるリージョンを選択してください。 |
| リージョン別の提供状況 | 多くの Azure リージョンはペアになっています。 一部の Azure サービスでは、ペアのリージョンを使用してデータが自動的にレプリケートされます。 ペアがないリージョンでワークロードを実行する場合、データをレプリケートするために別のアプローチを使用することが必要な場合があります。 |
リージョンのアーキテクチャ
マルチリージョン ソリューションを設計する場合、使用する予定の Azure リージョンがペアになっているかどうかを検討してください。
リージョンがペアになっていない場合でも、マルチリージョン ソリューションを作成できます。 ただし、マルチリージョン アーキテクチャを実装するために使用する方法は異なる場合があります。 たとえば、Azure Storage では、ペアのリージョンで geo 冗長ストレージ (GRS) を使用できます。 GRS を使用できない場合は、Azure Storage のオブジェクト レプリケーションなどの機能を使用することを検討するか、複数のリージョンに書き込むようにアプリケーションを設計してください。
マルチゾーンとマルチリージョンのアプローチを組み合わせる
ビジネス要件のためにこのようなソリューションが必要な場合は、マルチゾーン ステートメントとマルチリージョン ステートメントを組み合わせる必要があります。 たとえば、ゾーン冗長コンポーネントを各リージョンにデプロイし、さらに、リージョン間のレプリケーションも構成できます。 一部のソリューションでは、このアプローチにより、信頼性が非常に高くなります。 ただし、この種のアプローチの構成は複雑になる可能性があり、このアプローチはコストがかかる場合があります。
重要
ミッション クリティカルなワークロードでは、複数の可用性ゾーンと複数のリージョンの両方を使用する必要があります。 ミッション クリティカルなワークロードを設計するときに検討する必要がある考慮事項の詳細については、「ミッション クリティカルなワークロードのドキュメント」を参照してください。
Azure サービスがデプロイ アプローチをサポートする方法
使用する Azure サービスの具体的な詳細を理解することが重要です。 たとえば、一部の Azure サービスでは、最初にリソースをデプロイするときに可用性ゾーンを構成する必要がありますが、その他の Azure サービスでは、後でデプロイ アプローチを変更することがサポートされます。 同様に、一部のサービス機能が一部のデプロイ アプローチで使用できない場合があります。
Azure サービスごとに考慮する必要がある特定のデプロイ オプションとアプローチの詳細については、「信頼性ハブ」を参照してください。
例
このセクションでは、一般的なユース ケースと、ワークロードごとに通常考慮する必要がある主な要件について説明します。 ワークロードごとに、この記事で説明されている要件とアプローチに基づいて、推奨される 1 つ以上のデプロイ アプローチが用意されています。
企業向けの基幹業務アプリケーション
Contoso, Ltd. は、大規模な多国籍の製造企業です。 同社は、財務プロセスの一部のコンポーネントを管理するために基幹業務アプリケーションを実装しています。
ビジネス要件: システムが管理する情報を置き換えるのは難しいため、データを確実に保持する必要があります。 アーキテクトは、システムで発生するダウンタイムとデータ損失をできるだけ少なくする必要があると言っています。 Contoso の従業員は稼働日全体を通してシステムを使用するため、チーム メンバーの待ち時間が発生しないようにするにはハイ パフォーマンスが重要です。 財務チームがソリューションに対して支払う必要があるため、コストも懸念事項になります。
推奨されるアプローチ: リージョン間のバックアップを使用したゾーン冗長デプロイは、ハイ パフォーマンスの複数の回復性レイヤーを提供します。
内部アプリケーション
Fourth Coffee は中小企業です。 同社は、従業員がタイムシートを送信するために使用できる新しい内部アプリケーションを開発しています。
ビジネス要件: このワークロードでは、コスト効率が主な懸念事項です。 Fourth Coffee はダウンタイムのビジネスへの影響を評価し、アプリケーションで回復性やパフォーマンスを優先する必要はないと判断しました。 同社は、Azure 可用性ゾーンまたはリージョンで停止が発生するとアプリケーションが一時的に使用できなくなるリスクを受け入れています。
推奨されるアプローチ:
- リージョン間のバックアップを使用したローカル冗長デプロイは、コストが最も低くなりますが、重大なリスクもあります。
- リージョン間のバックアップを使用したゾーン冗長デプロイは、回復性が高まりますが、コストが若干高くなります。
レガシ アプリケーションの移行
Fabrikam, Inc. は、オンプレミスのデータセンターから Azure にレガシ アプリケーションを移行しています。 この実装では、仮想マシンに基づく IaaS アプローチを使用します。 このアプリケーションはクラウド環境用として設計されておらず、アプリケーション層とデータベースの間の通信は非常に頻度が高いです。
ビジネス要件: パフォーマンスは、このアプリケーションの優先事項です。 回復性も重要であり、Azure データセンターで停止が発生した場合でも、アプリケーションは動作し続ける必要があります。
推奨されるアプローチ:
- Fabrikan は、最初にゾーン冗長デプロイを試す必要があります。 同社は、パフォーマンスが要件を満たしていることを確認する必要があります。
- ゾーン冗長ソリューションのパフォーマンスを許容できない場合、複数の可用性ゾーン間のパッシブ デプロイ (リージョン内 DR) を使用したゾーン (ピン留め) デプロイを検討してください。
医療アプリケーション
Lamna Healthcare Company は、Azure に新しい電子カルテ システムを実装しています。
ビジネス要件: このソリューションが保存するデータの性質上、データ所在地が非常に重要です。 Lamna は、データを特定の場所に残す必要があることを義務付ける厳格な規制フレームワークに基づいて事業を営んでいます。
推奨されるアプローチ:
- マルチゾーン マルチリージョン デプロイ: Lamna のデータ所在地の要件に適合する複数のリージョンがある場合。
- ニーズに合ったリージョンが 1 つのみである場合、ゾーン冗長デプロイを検討してください。または、リージョン間のバックアップを使用したゾーン冗長デプロイは単一リージョン ソリューションを提供しています。
銀行取引システム
Woodgrove Bank は、Azure にデプロイされた大規模なソリューションからコア銀行業務を運営しています。
ビジネス要件: これはミッション クリティカルなシステムです。 停止が発生すると、顧客に対して大きな財務上の影響が生じる可能性があります。 その結果、Woodgrove Bank のリスク許容度は非常に低くなります。 このシステムには、可能な限り最高レベルの信頼性が必要であり、アーキテクチャにより、軽減可能な障害のリスクを軽減する必要があります。
推奨されるアプローチ: ミッション クリティカルなシステムの場合は、マルチゾーン マルチリージョン デプロイを使用します。 リージョンが同社のデータ所在地の要件に適合していることを確認してください。
サービスとしてのソフトウェア (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 の冗長性
信頼性チェックリスト
レコメンデーションの完全なセットを参照してください。