可用性ゾーンとリージョンを使用するための推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:05 | 特に重要なフローの場合は、異なるレベルで冗長性を追加します。 特定された信頼性ターゲットに従って、コンピューティング、データ、ネットワーク、およびその他のインフラストラクチャ層に冗長性を適用します。 |
|---|
関連ガイド:高可用性マルチリージョン 設計 | 冗長性
このガイドでは、可用性ゾーンまたはリージョン間でワークロードをデプロイするタイミングを決定するための推奨事項について説明します。
Azure 用のソリューションを設計するときは、リージョン内の複数の可用性ゾーンにデプロイするか、複数のリージョンにデプロイするかを決定する必要があります。 この決定は、ソリューションの信頼性、コスト、パフォーマンス、およびソリューションを運用するチームの能力に影響します。 このガイドでは、決定に影響を与える主要なビジネス要件、考慮できるアプローチ、各アプローチに関連するトレードオフ、および Azure Well-Architected Framework のコア柱に対する各アプローチの影響について説明します。
ソリューションに使用する最適な Azure リージョンに関する決定は、重要な選択です。 「 Azure リージョンの選択」ガイド では、複数の地理的リージョンで選択および運用する方法について説明します。 ソリューション内でリージョンと可用性ゾーンを使用する方法を選択すると、Well-Architected Framework のいくつかの柱にも影響します。
- 信頼性: デプロイ アプローチの選択は、さまざまな種類のリスクを軽減するのに役立ちます。 一般に、ワークロードをより地理的に分散した領域に分散することで、より高い回復性を実現できます。
- コストの最適化: 一部のアーキテクチャ アプローチでは、他の方法よりも多くのリソースをデプロイする必要があり、リソース コストが増加する可能性があります。 その他の方法として、地理的に分離された可用性ゾーンまたはリージョン間でデータを送信する方法があり、ネットワーク トラフィック料金が発生する可能性があります。 また、包括的なビジネス要件がある場合、通常は高いリソース管理の継続的なコストを考慮することも重要です。
- パフォーマンス効率: 可用性ゾーンは、高帯域幅、低待機時間のネットワーク リンクを介して接続されます。これは、ほとんどのワークロードでゾーン間の同期レプリケーションと通信を有効にするのに十分です。 ただし、ワークロードがテストされ、ゾーン間のネットワーク待機時間に影響を受ける場合は、ワークロードのコンポーネントが通信するときの待機時間を最小限に抑えるために、ワークロードのコンポーネントを物理的に近くに配置することを検討する必要があります。
- オペレーショナル エクセレンス: 複雑なアーキテクチャでは、デプロイ、構成、管理に多くの労力がかかります。 さらに、高可用性ソリューションの場合は、セカンダリ リソース セットにフェールオーバーする方法を計画する必要がある場合があります。 フェールオーバー、フェールバック、透過的なトラフィックのリダイレクトは、特に手動の手順が必要な場合に複雑になる可能性があります。 デプロイと管理のプロセスを自動化することをお勧めします。 詳細については、コードとしての OE:05 インフラストラクチャ、OE:09タスク自動化、OE:10 オートメーション設計、OE:11 デプロイ プラクティスなど、オペレーショナル エクセレンスの柱ガイドを参照してください。
ソリューションを設計する場合は、セキュリティの柱が適用されます。 通常、可用性ゾーンとリージョンの使用に関する決定は、セキュリティ体制を変えません。 Azure では、すべてのリージョンと可用性ゾーンに同じセキュリティの厳密性が適用されます。
ヒント
多くの運用環境のワークロードでは、 ゾーン冗長デプロイ によって最適なトレードオフのバランスが提供されます。 非同期データ バックアップを使用して、この方法 を別のリージョンに拡張できます。 どちらの手法を選択すればよいかわからない場合は、まずこの種類のデプロイを試してください。
これらのアプローチが提供する特定の利点が必要ですが、関連するトレードオフに注意する必要がある場合は、他のワークロード アプローチを検討してください。
定義
| 期間 | 定義 |
|---|---|
| アクティブ/アクティブ | ソリューションの複数のインスタンスが同時に要求をアクティブに処理するアーキテクチャ。 |
| アクティブ/パッシブ | ソリューションの 1 つのインスタンスがプライマリとして指定され、トラフィックを処理し、 プライマリ が使用できない場合にトラフィックを処理するために 1 つ以上の セカンダリ インスタンスがデプロイされるアーキテクチャ。 |
| 非同期レプリケーション | データが 1 つの場所に書き込まれ、コミットされるデータ レプリケーション アプローチ。 後で、変更は別の場所にレプリケートされます。 |
| 可用性ゾーン | リージョン内のデータセンターの分離されたグループ。 各可用性ゾーンは他の可用性ゾーンとは独立しており、独自の電源、冷却、ネットワーク インフラストラクチャがあります。 多くのリージョンで可用性ゾーンがサポートされています。 |
| データセンター | Azure リソースとワークロードをサポートするためのサーバー、ネットワーク機器、およびその他のハードウェアを含む施設。 |
| ローカル冗長デプロイ | 可用性ゾーンを参照せずにリソースを 1 つのリージョンにデプロイするデプロイ モデル。 可用性ゾーンをサポートするリージョンでは、リソースがリージョンのいずれかの可用性ゾーンにデプロイされる場合があります。 |
| 複数リージョンのデプロイ | リソースが複数の Azure リージョンにデプロイされるデプロイ モデル。 |
| ペアになっているリージョン | 2 つの Azure リージョン間のリレーションシップ。 一部の Azure リージョン は、特定の種類のマルチリージョン ソリューションを有効にするために、別の定義済みリージョンに接続されています。 新しい Azure リージョンはペアになっていません。 |
| Region | データセンターのセットを含む地理的境界。 |
| リージョン アーキテクチャ | 可用性ゾーンの数や、リージョンが別のリージョンとペアになっているかどうかなど、Azure リージョンの特定の構成。 |
| 同期レプリケーション | データが複数の場所に書き込まれ、コミットされるデータ レプリケーションアプローチ。 書き込み操作全体が完了したと見なされる前に、各場所で書き込み操作の完了を確認する必要があります。 |
| ゾーン (固定) デプロイ | リソースが特定の可用性ゾーンにデプロイされるデプロイ モデル。 |
| ゾーン冗長デプロイ | リソースが複数の可用性ゾーンにデプロイされるデプロイ モデル。 ゾーンで障害が発生した場合、Microsoft はデータの同期、トラフィックの分散、フェールオーバーを管理します。 |
主要な設計戦略
Azure には大きなグローバル フットプリントがあります。 Azure リージョン は、一連のデータセンターを含む地理的境界です。 Azure リージョンと可用性ゾーンを完全に理解している必要があります。
Azure リージョンには、リージョン アーキテクチャとも呼ばれるさまざまな構成 があります。
多くの Azure リージョンでは、データセンターの分離されたグループである 可用性ゾーンが提供されています。 リージョン内では、可用性ゾーンは他の可用性ゾーンへの待機時間の短い接続に十分近いですが、複数の可用性ゾーンがローカルの停止や天候の影響を受ける可能性を減らすには十分に離れています。 可用性ゾーンには、独立した電源、冷却、ネットワーク インフラストラクチャがあります。 これらは、1 つのゾーンで障害が発生した場合、リージョンのサービス、容量、高可用性が残りのゾーンでサポートされるように設計されています。
次の図は、Azure リージョンの例をいくつか示しています。 リージョン 1 とリージョン 2 では、可用性ゾーンがサポートされています。
可用性ゾーンを含む Azure リージョンにデプロイする場合は、複数の可用性ゾーンを一緒に使用できます。 複数の可用性ゾーンを使用すると、アプリケーションとデータの個別のコピーを、大都市圏の個別の物理データセンター内に保持できます。
ソリューションで可用性ゾーンを使用するには、次の 2 つの方法があります。
- ゾーン リソースは、特定の可用性ゾーンに固定されます。 高い信頼性の要件を満たすために、異なるゾーン間で複数のゾーンデプロイを組み合わせることができます。 データ レプリケーションを管理し、ゾーン間で要求を分散する責任があります。 1 つの可用性ゾーンで停止が発生した場合は、別の可用性ゾーンへのフェールオーバーを行う必要があります。
- ゾーン冗長 リソースは、複数の可用性ゾーンに分散されます。 Microsoft は、ゾーン間での要求の分散と、ゾーン間でのデータのレプリケーションを管理します。 1 つの可用性ゾーンで障害が発生した場合、Microsoft はフェールオーバーを自動的に管理します。
Azure サービスでは、これらのアプローチの一方または両方がサポートされています。 サービスとしてのプラットフォーム (PaaS) サービスでは、通常、ゾーン冗長デプロイがサポートされます。 サービスとしてのインフラストラクチャ (IaaS) サービスでは、通常、ゾーンデプロイがサポートされます。 Azure サービスと可用性ゾーンの連携の詳細については、「可用性ゾーンの サポートを使用した Azure サービス」を参照してください。
Microsoft がサービスに更新プログラムをデプロイする場合、最も破壊的でないアプローチを使用しようとします。 たとえば、一度に 1 つの可用性ゾーンに更新プログラムをデプロイすることを目指しています。 この方法では、更新プログラムの処理中にワークロードが他のゾーンで引き続き実行できるため、アクティブなワークロードに対する更新の影響を軽減できます。 ただし、最終的には、プラットフォームのアップグレード中にワークロードが機能し続けるのは、ワークロード チームの責任です。 たとえば、フレキシブル オーケストレーション モードまたはほとんどの Azure PaaS サービス で仮想マシン スケール セットを使用する場合、Azure はリソースをインテリジェントに配置して、プラットフォームの更新の影響を軽減します。 さらに、 リソースのインスタンスをさらにデプロイするオーバープロビジョニングを 検討して、他のインスタンスのアップグレード中に一部のインスタンスを引き続き使用できるようにすることもできます。 Azure による更新プログラムのデプロイ方法の詳細については、「 安全なデプロイプラクティスの推進」を参照してください。
多くのリージョンにも ペアのリージョンがあります。 ペアリージョンでは、特定の種類のマルチリージョンデプロイアプローチがサポートされています。 一部の新しいリージョンには 、複数の可用性ゾーンがあり、ペアのリージョンがありません。 これらのリージョンにマルチリージョン ソリューションをデプロイすることはできますが、使用する方法が異なる場合があります。
Azure でのリージョンと可用性ゾーンの使用方法の詳細については、「Azure リージョンと可用性ゾーンとは」を参照してください。
共有責任を理解する
共有責任の原則では、クラウド プロバイダー (Microsoft) とユーザーの間で責任がどのように分割されるかについて説明します。 使用するサービスの種類によっては、サービスの運用に対して多かれ少なかれ責任を負う場合があります。
Microsoft では、要件を満たすようにソリューションを柔軟に設計するための可用性ゾーンとリージョンを提供しています。 マネージド サービスを使用する場合、Microsoft はリソースに対してより多くの管理責任を負います。これには、データ レプリケーション、フェールオーバー、フェールバック、分散システムの運用に関連するその他のタスクも含まれる場合があります。
独自のコードでは、 エラーを適切に処理するために推奨されるプラクティスと設計パターンが必要です。 これらのプラクティスは、可用性ゾーンまたはリージョンのフェールオーバーが発生したときに発生するなど、フェールオーバー操作中にさらに重要になります。これは、通常、ゾーンまたはリージョン間のフェールオーバーでは、アプリケーションがサービスへの接続を再試行する必要があるためです。
主要なビジネス要件とワークロード要件を特定する
ソリューションで可用性ゾーンとリージョンを使用する方法に関する情報に基づいた意思決定を行うには、要件を理解する必要があります。 これらの要件は、ソリューション デザイナーとビジネス関係者間のディスカッションによって推進される必要があります。
リスク許容度
組織によってリスク許容度が異なります。 organization内であっても、多くの場合、リスク許容度はワークロードごとに異なります。 ほとんどのワークロードでは、非常に高可用性は必要ありません。 ただし、一部のワークロードは非常に重要であるため、広範な地理的領域に影響を与える大規模な自然災害など、発生する可能性が低いリスクを軽減する価値さえあります。
次の表に、クラウド環境で考慮する必要がある一般的なリスクをいくつか示します。
| リスク | 例 | Likelihood |
|---|---|---|
| ハードウェアの停止 | ハード ディスクまたはネットワーク機器に関する問題。 ホストの再起動。 |
高。 回復性戦略では、これらのリスクを考慮する必要があります。 |
| データセンターの停止 | データセンター全体の電源、冷却、またはネットワーク障害。 大都市圏の一部における自然災害。 |
Medium |
| リージョンの停止 | 地理的に広い地域に影響を与える大規模な自然災害。 リージョン全体で 1 つ以上の Azure サービスを使用できなくなるネットワークまたはサービスの問題。 |
低 |
すべてのワークロードで発生する可能性のあるすべてのリスクを軽減するのが理想的ですが、これを行うのは実用的でもコスト効率も高くはありません。 軽減する必要があるリスクに関する情報に基づいた意思決定を行えるように、ビジネス関係者とオープンなディスカッションを行う必要があります。
ヒント
信頼性のターゲットに関係なく、すべてのワークロードにディザスター リカバリーのための軽減策が必要です。 ワークロードで高い信頼性の目標が必要な場合は、軽減戦略を包括的に行い、可能性の低いイベントのリスクを軽減する必要があります。 その他のワークロードの場合は、受け入れる準備ができているリスクと軽減する必要があるリスクについて、情報に基づいた意思決定を行います。
回復性の要件
目標復旧時間 (RTO) や目標復旧ポイント (RPO) など、ワークロードの回復性要件を理解することが重要です。 これらの目的は、除外する方法を決定するのに役立ちます。明確な要件がない場合は、どのアプローチに従うのかを情報に基づいて決定することはできません。 詳細については、「 ターゲットの機能要件と非機能要件」を参照してください。
サービスレベルの目標
ソリューションの予想されるアップタイム サービス レベル目標 (SLO) を理解する必要があります。 たとえば、ソリューションが 99.9% のアップタイムを満たす必要があるビジネス要件があるとします。
Azure では、サービスごとにサービス レベル アグリーメント (SLA) が提供されます。 SLA は、サービスに期待されるアップタイムのレベルと、期待される SLA を達成するために満たす必要がある条件を示します。 ただし、Azure SLA がサービスの可用性を示す方法が、ワークロードの正常性を考慮する方法と必ずしも一致するとは限らないことに注意してください。
アーキテクチャ上の決定は、ソリューションの 複合 SLO に影響します。 一般に、ソリューションに組み込む冗長性が高いほど、SLO が高くなる可能性が高くなります。 多くの Azure サービスでは、ゾーン冗長またはマルチリージョン構成でサービスをデプロイするときに、より高い SLA が提供されます。 使用する各 Azure サービスの SLA を確認して、サービスの回復性と SLA を最大化する方法を理解していることを確認します。
データの保存場所
一部の組織では、データを格納および処理できる物理的な場所に制限があります。 これらの要件は、法的または規制上の基準に基づく場合があります。 他の状況では、organizationは、顧客の懸念を避けるためにデータ所在地ポリシーを採用することを決定する場合があります。 厳密なデータ所在地要件がある場合は、単一リージョンのデプロイを使用するか、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 App Service、Azure Functions、Azure Kubernetes Service、Azure Storage、Azure SQLなど、多くの Azure サービスで可能です。Azure Service Bus、その他多数。 ゾーンの冗長性をサポートするサービスの完全な一覧については、「 可用性ゾーン サービスとリージョンのサポート」を参照してください。
リージョン間のバックアップを使用したゾーン冗長デプロイ
インフラストラクチャとデータの定期的なバックアップをセカンダリ リージョンに実行することで、ゾーン冗長デプロイを拡張できます。 このアプローチにより、ゾーン冗長アプローチの利点が得られ、リージョン全体の停止が発生する可能性が極めて低い場合を軽減するための保護レイヤーが追加されます。
このアプローチを実装するときは、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」を参照してください。
フィードバックの送信と表示