高可用性マルチリージョン設計に関する推奨事項
この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。
| RE:05 | 特に重要なフローの場合は、さまざまなレベルで冗長性を追加します。 特定された信頼性ターゲットに従って、コンピューティング、データ、ネットワーク、およびその他のインフラストラクチャ層に冗長性を適用します。 |
|---|
関連ガイド:可用性 | ゾーンとリージョンを使用した冗長性
このガイドでは、高可用性マルチリージョン クラウド環境を設計するための推奨事項について説明します。 高可用性は、信頼性のための設計の基本的な基本理念です。 高可用性アーキテクチャは、可能な限りダウンタイムを回避し、ダウンタイムが発生した場合に効率的に復旧するのに役立ちます。
アクティブ/アクティブ / パッシブ は、環境をデプロイするプラットフォームに応じて、さまざまな方法で適用できる一般的なアーキテクチャの種類です。 このガイドでは、複数リージョンのクラウド環境設計に焦点を当てています。 Azure では、 可用性ゾーンを使用して、1 つのリージョン内でアクティブ/アクティブ/パッシブ アーキテクチャを設計することもできます。 可用性ゾーンを使用した高可用性アーキテクチャの設計に関する詳細なガイダンスについては、 Azure Well-Architected Framework ガイドを参照してください。
主要な設計戦略
アクティブ/アクティブ/パッシブは、高可用性クラウド環境を設計するための 2 つの基本的なアプローチです。 アクティブ/アクティブ環境は、ワークロードをデプロイするすべてのリージョンで運用負荷を処理するように設計されています。 アクティブ/パッシブ環境は、プライマリ リージョンでのみ運用環境の負荷を処理するように設計されていますが、必要に応じてセカンダリ (パッシブ) リージョンにフェールオーバーします。 ワークロードに最適な Azure リージョンを選択することは、高可用性マルチリージョン環境を設計する上で重要な部分です。 Azure リージョンの選択に関するガイダンスについては、「 Azure リージョンの選択」ガイドを参照してください。
このセクションでは、各パターンを評価し、ビジネス要件を満たすようにアーキテクチャを調整するときに考慮する必要がある設計オプションについて説明します。
反復可能でスケーラブルな方法でワークロードを設計するためのガイダンスについては、「 デプロイ スタンプ パターン 」を参照してください。 この設計パターンは、効率的な管理のために高可用性設計を最適化するのに役立ちます。
次のセクションでは、2 つのパターンの設計オプションについて説明します。
アクティブ/アクティブ
容量でのアクティブ/アクティブ: 2 つ以上の Azure リージョンのミラー化されたデプロイ スタンプ。それぞれが、サービスを提供するリージョンまたはリージョンの運用ワークロードを処理するように構成され、リージョンが停止した場合に他のリージョンからの負荷を処理するためにスケーラブルです。
ネットワーク: リージョン間でトラフィックを分散するには、 待機時間 または 重み付けされた グローバル ルーティングを使用します。
データ レプリケーションと一貫性: 複数リージョンの読み取りおよび書き込み機能には 、Azure Cosmos DB などのグローバルに分散されたデータ ストアを使用します。 リレーショナル データベースの場合は、 読み取り専用 接続文字列を含む読み取り可能なレプリカを使用します。
この設計の利点: オーバープロビジョニングされた設計よりも運用コストを削減します。
この設計の欠点: 別のリージョンで障害が発生した場合にフル ロードの要求を満たすようにスケールアップするときのユーザー エクスペリエンスが低下する可能性があります。
アクティブ/アクティブなオーバープロビジョニング: 2 つ以上の Azure リージョンのミラー化されたデプロイ スタンプ。各オーバープロビジョニングにより、サービスを提供するリージョンまたはリージョンの運用ワークロードを処理し、リージョンが停止した場合に他のリージョンからの負荷を処理します。
ネットワーク: リージョン間でトラフィックを分散するには、 待機時間 または 重み付けされた グローバル ルーティングを使用します。
データ レプリケーションと一貫性: 複数リージョンの読み取りおよび書き込み機能には 、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 データベース プラットフォームです。これは、アクティブ/アクティブ環境を実行し、リージョンの停止が発生したときのダウンタイムの可能性を最小限に抑えるのに役立ちます。
関連リンク
信頼性チェックリスト
推奨事項の完全なセットを参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示