高可用性マルチリージョン設計に関する推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:05 | 異なるレベルで冗長性を追加します (特に、重要なフローの場合)。 特定された信頼性目標に従って、コンピューティング、データ、ネットワーク、その他のインフラストラクチャ層に冗長性を適用します。 |
|---|
関連ガイド: 冗長性 | 可用性ゾーンとリージョンの使用
このガイドでは、高可用性マルチリージョン クラウド環境を設計するための推奨事項について説明します。 高可用性は、信頼性を考慮した設計の基本原則です。 高可用性アーキテクチャは、ダウンタイムを可能な限り回避し、ダウンタイムが発生した場合に効率的に復旧するのに役立ちます。
"アクティブ/アクティブ" と "アクティブ/パッシブ" は、環境をデプロイするプラットフォームに応じてさまざまな方法で適用できる一般的なアーキテクチャの種類です。 このガイドは、マルチリージョン クラウド環境の設計に焦点を当てています。 Azure では、可用性ゾーンを使用して、単一リージョン内でアクティブ/アクティブまたはアクティブ/パッシブ アーキテクチャを設計することもできます。 可用性ゾーンを使用した高可用性アーキテクチャの設計に関する詳細なガイダンスについては、Azure Well-Architected フレームワーク ガイドを参照してください。
主要な設計戦略
アクティブ/アクティブとアクティブ/パッシブは、高可用性クラウド環境を設計するための 2 つの基本的なアプローチです。 アクティブ/アクティブ環境は、ワークロードをデプロイするすべてのリージョンで運用負荷を処理できるように設計されています。 アクティブ/パッシブ環境は、プライマリ リージョンでのみ運用負荷を処理できるように設計されていますが、必要に応じてセカンダリ (パッシブ) リージョンにフェールオーバーします。 ワークロードに最適な Azure リージョンを選択することは、高可用性マルチリージョン環境を設計する際の重要な部分です。 Azure リージョンの選択に関するガイダンスについては、Azure リージョンの選択ガイドを参照してください。
このセクションでは、各パターンを評価し、ビジネス要件を満たすようにアーキテクチャを調整するときに考慮する必要がある設計オプションについて説明します。
反復可能でスケーラブルな方法でワークロードを設計するためのガイダンスについては、「デプロイ スタンプ パターン」を参照してください。 この設計パターンは、高可用性設計を最適化し、効率的に管理するのに役立ちます。
以下のセクションでは、2 つのパターンの設計オプションについて説明します。
アクティブ/アクティブでデプロイする (ゼロ ダウンタイム用)
容量に応じたアクティブ/アクティブ: 複数の Azure リージョンにミラー化されたデプロイ スタンプ。それぞれがサービスを提供する 1 つ以上のリージョンの運用ワークロードを処理できるように、また、リージョンが停止した場合は他のリージョンから負荷を処理できるようにスケーラブルに構成されています。
データのレプリケーションと整合性: マルチリージョンの読み取りおよび書き込み機能には、Azure Cosmos DB のようなグローバル分散型データ ストアを使用します。 リレーショナル データベースの場合は、接続文字列が読み取り専用である読み取り可能なレプリカを使用します。
この設計の利点: オーバープロビジョニング型設計よりも運用コストが低くなります。
この設計の欠点: 別のリージョンで停止が発生した場合、全負荷の要求を満たすためにスケールアップするときにユーザー エクスペリエンスが低下する可能性があります。
オーバープロビジョニングされたアクティブ/アクティブ: 複数の Azure リージョンにミラー化されたデプロイ スタンプ。それぞれがサービスを提供する 1 つ以上のリージョンの運用ワークロードを処理できるように、また、リージョンが停止した場合は他のリージョンから負荷を処理できるようにオーバープロビジョニングされています。
データのレプリケーションと整合性: マルチリージョンの読み取りおよび書き込み機能には、Azure Cosmos DB のようなグローバル分散型データ ストアを使用します。 リレーショナル データベースの場合は、接続文字列が読み取り専用である読み取り可能なレプリカを使用します。
この設計の利点: 可能な限り最も回復性がある設計。
この設計の欠点: スケーラブルな設計よりも運用コストが高くなります。
両方の設計に共通する利点: 回復性は高く、ワークロードが完全に停止するリスクは低くなっています。
両方の設計に共通する欠点: アプリケーションの状態とデータの同期管理の必要性など、さまざまな要因により、運用コストと管理負担が増加します。
アクティブ/パッシブでデプロイする (ディザスター リカバリー用)
ウォーム スペア: 1 つのプライマリ リージョンと 1 つ以上のセカンダリ リージョン。 セカンダリ リージョンは、可能な限り最小限のコンピューティングとデータのサイズ設定でデプロイされ、負荷なしで実行されます。 このリージョンは "ウォーム スペア" リージョンと呼ばれます。 フェールオーバー時には、プライマリ リージョンからの負荷を処理できるようにコンピューティング リソースとデータ リソースがスケーリングされます。
ネットワーク: 優先グローバル ルーティングを使用します。
データのレプリケーションと整合性: データベースをパッシブ リージョンにレプリケートし、Azure Cosmos DB や Azure SQL Database などのサービスとしてのプラットフォーム (PaaS) ソリューションの自動フェールオーバー機能を使用します。
この設計の利点: アクティブ/パッシブ設計の中で最も短い復旧時間。
この設計の欠点: アクティブ/パッシブ設計の中で運用コストが最も高くなります。
コールド スペア: 1 つのプライマリ リージョンと 1 つ以上のセカンダリ リージョン。 セカンダリ リージョンは全負荷を処理できるようにスケーリングされますが、すべてのコンピューティング リソースは停止されます。 このリージョンは "コールド スペア" リージョンと呼ばれます。 フェールオーバーの前にリソースを開始する必要があります。
ネットワーク: 優先グローバル ルーティングを使用します。
データのレプリケーションと整合性: データベースをパッシブ リージョンにレプリケートし、Azure Cosmos DB や Azure SQL Database などの PaaS ソリューションの自動フェールオーバー機能を使用します。
この設計の利点: ウォーム スペア設計よりも運用コストが低くなります。
この設計の欠点: ウォーム スペア設計よりも復旧時間が長くなります。
災害発生時の再デプロイ: 1 つのプライマリ リージョンと 1 つ以上のセカンダリ リージョン。 必要なネットワークのみがセカンダリ リージョンにデプロイされます。 ワークロードをフェール オーバーするには、オペレーターがセカンダリ リージョンでプロビジョニング スクリプトを実行する必要があります。 この設計は "災害発生時の再デプロイ" と呼ばれます。
ネットワーク: 優先グローバル ルーティングを使用します。
データのレプリケーションと整合性: 新しいデータベース インスタンスをデプロイし、バックアップからデータをリハイドレートします。
この設計の利点: 運用コストが最低です。
この設計の欠点: 復旧時間が最も長くなります。
アクティブ/パッシブ設計の一般的な利点: アクティブ/アクティブ設計よりも運用コストが低く、日常の管理負担が軽減されます。 アプリケーションの状態を同期する必要はありません。
アクティブ/パッシブ設計の一般的な欠点: 復旧プロセスがより長く、より複雑になります。 フェールオーバーを成功させるために手動介入が必要になる可能性が高くなります。
Note
高可用性設計に関係なく、Azure DevOps インフラストラクチャ、ジャンプ ボックス、監視、ワークロードの管理に必要なその他の重要なサービスなどのサポート サービスの冗長性を必ず構成してください。
Azure ファシリテーション
Azure Front Door は、Azure Traffic Manager のグローバル ルーティング機能をコンテンツ配信システムや Web アプリケーション ファイアウォールと組み合わせて、高可用性ワークロードの管理を支援します。
Azure Cosmos DB はグローバルに分散された NoSQL Database プラットフォームであり、アクティブ/アクティブ環境を実行し、リージョンの停止が発生した場合のダウンタイムの可能性を最小限に抑えるのに役立ちます。
関連リンク
信頼性チェックリスト
レコメンデーションの完全なセットを参照してください。