冗長性のための設計のためのアーキテクチャ戦略

この Azure Well-Architected Framework の信頼性チェックリストの推奨事項に適用されます。

このガイドでは、回復性を最適化するさまざまなワークロード レイヤーで重要なフロー全体に冗長性を追加するための推奨事項について説明します。 コンピューティング、データ、ネットワーク、その他のインフラストラクチャ層に適切なレベルの冗長性を適用することで、定義済みの信頼性の目標の要件を満たします。 この冗長性を適用して、ワークロードを構築するための強力で信頼性の高い基盤を提供します。 インフラストラクチャの冗長性なしでワークロードを構築すると、障害が発生する可能性があるため、ダウンタイムが長くなるリスク が高くなります。

定義

信頼性の観点から、冗長性を使用して、1 つのリソースに影響する問題を封じ込め、それらの問題がシステム全体の信頼性に影響しないようにします。 重要なフローと信頼性の目標について特定した情報を使用して、各フローの冗長性に必要な情報に基づいた上で決断を下します。

たとえば、一度に実行される複数の Web サーバー ノードがあるとします。 サポートするフローが重要な場合は、問題が完全なデータセンターの停止など、プール全体に影響を与える場合にすぐにトラフィックを受け入れることができるレプリカがすべてのノードに必要になる場合があります。 また、大規模な問題はまれであり、レプリカのセット全体をデプロイするとコストがかかるため、問題を解決するまでフローが低下状態で動作するように、限られた数のレプリカをデプロイできます。

パフォーマンス効率の観点から冗長性を設計する場合は、各ノードが最適に実行されるように、負荷を複数の冗長ノードに分散します。 信頼性の観点では、1 つ以上のノードに影響を与える障害や誤動作を吸収するために予備容量を組み込みます。 予備容量が、影響を受けるノードを回復するために必要な期間、障害を吸収できるようにします。 この違いを念頭に置いて、両方の戦略を連携させる必要があります。 パフォーマンスのために 2 つのノード間でトラフィックを分散し、両方とも 60% 使用率で実行され、1 つのノードが失敗した場合、残りのノードは 120%で動作できないため、過剰な負荷が発生するリスクがあります。 負荷を別のノードに分散して、パフォーマンスと信頼性の目標が確実に維持されるようにします。

トレードオフ:

• ワークロードの冗長性が高まるにつれて、コストもかかります。 冗長性の追加は、慎重に検討し、アーキテクチャを定期的に確認して、コストを管理していることを確認してください (特にオーバープロビジョニングを使用する場合)。 回復性戦略としてオーバープロビジョニングを使用する場合は、コストの非効率性を最小限に抑えるために適切に定義されたスケーリング戦略を使ってバランスを取ります。

• 高度な冗長性で構築する場合、パフォーマンスのトレードオフが発生する可能性があります。 たとえば、可用性ゾーンや場所に分散するリソースは、Web サーバーやデータベース インスタンスなどの冗長リソース間の待機時間の長い接続経由でトラフィックを送信する必要があるため、パフォーマンスに影響を与える可能性があります。

• 同じワークロード内でもフローが異なると、信頼性要件が異なる場合があります。 フロー固有の冗長性設計では、設計全体が複雑になる場合があります。

• 待機時間の短い冗長性設計は、地理的な障害などの大規模なイベントが発生した場合に、すべてのインスタンスをオフラインにした場合にそれらのコンポーネントを失うリスクを受け入れることを意味します。 地理的に離れたディザスター リカバリー (DR) 環境は、このリスクを軽減するのに役立ちますが、コストが増加します。

運用上の負担を軽減するために、サーバーレスおよびフル マネージド サービスを優先する

サーバーレス、サービスとしてのソフトウェア (SaaS)、サービスとしてのプラットフォーム (PaaS) ソリューションを利用して、データレプリケーションやフェールオーバー操作を管理することなく、ワークロードに冗長性を簡単に追加できます。 これらのサービスは冗長性を透過的に実装するため、独自の冗長性メカニズムの設計と維持に関する運用上の負担が軽減されます。 サービス オプションを評価する場合は、手動の冗長性構成を必要とするインフラストラクチャ ベースのアプローチよりも、冗長性を自動的に処理するマネージド サービスに優先順位を付けます。

Azure マネージド サービスは、さまざまなモデルを通じて冗長性を提供します。 各モデルは、さまざまなレベルの抽象化と運用のシンプルさを提供します。

冗長性が組み込まれたグローバル サービス: Microsoft Entra ID、Azure DNS、Azure Key Vault などのサービスは、複数のリージョン間で自動冗長性を備えたグローバル サービスとして動作します。 これらのサービスは、冗長性の構成を必要とせずに、固有の回復性を提供します。 フェールオーバーと復旧のシナリオを透過的に自動的に処理します。

抽象化された容量モデル: Azure Cosmos DB、Azure Databricks、Azure OpenAI マネージド エンドポイントなどのオファリングは、容量ユニット、DTU、またはその他の論理メトリックの背後にあるインフラストラクチャの複雑さを抽象化します。 これらのサービスは、簡素化された課金と管理モデルを提示しながら、複数のインスタンス、ゾーン、リージョンにワークロードを自動的に分散します。 個々の冗長インスタンスを管理する代わりに、容量要件を指定します。

ソリューションを設計するときは、インフラストラクチャ ベースの冗長性を実装する前に、各コンポーネントにマネージド サービス オプションが存在するかどうかを評価します。 マネージド サービスは運用上のオーバーヘッドを削減し、多くの場合、カスタム ソリューションよりも堅牢な冗長性実装を提供しますが、制御のトレードオフが伴い、容量の単位ごとにコストが高くなる可能性があります。

複数のコンポーネント インスタンスを使用してワークロードに冗長性を組み込む

ワークロードに必要な回復性を実現するために、インフラストラクチャ コンポーネントとサービスの複数のインスタンスをデプロイします。 この基本的な冗長性戦略により、1 つのインスタンスで障害が発生した場合でも、他のインスタンスがワークロードを引き続き処理できるようになります。 さまざまな方法で複数のインスタンスを実現できます。 一部のシナリオでは、複数の Azure ExpressRoute 回線や複数のリージョンでの Azure Traffic Manager の構成など、複数のリソースを個別にデプロイして、冗長性を手動で構成する必要があります。 その他のサービスは、Azure Virtual Machine Scale Sets を 5 つのインスタンスに設定したり、10 個のインスタンスを実行するように Azure App Service を構成したりするなど、複数のインスタンスを直接サポートするように設計されています。 可能であれば、冗長性管理を簡素化し、信頼性とパフォーマンスの両方のニーズに対応できるため、複数のインスタンスと自動スケール機能の組み込みサポートを提供するサービスを優先します。

冗長インフラストラクチャ コンポーネントをデプロイする場合は、各コンポーネントのインスタンス数が信頼性の目標を満たすかどうかを判断します。 すべてのコンポーネントの複数のインスタンスが必要か、特定の重要なコンポーネントのみが必要かを検討し、回復性の要件を満たすためにそれらのインスタンスの地理的分布を決定します。 冗長インフラストラクチャをデプロイする場合は、次の推奨事項を検討してください。

コンピューティング リソース:

• 冗長性が組み込まれているサービスを優先します。 これらのサービスを使用すると、必要なインスタンスの数を指定でき、それらのインスタンスの配布と管理を処理できます。

• 要求を処理する個々のノードは、いつでも削除または置換されたり、障害が発生したりする可能性があるため、コンピューティング層は "クリーンな状態" を保ってください。

• 冗長性アプローチに合わせてスケーリング戦略を設計してテストします。

データ リソース:

• リージョンの停止や致命的な障害に対する回復性を提供するために、地理的リージョン間でデータをレプリケートします。

• 使用する ステートフル プラットフォーム サービスの組み込みのレプリケーションと冗長性の機能 について説明します。

• お使いのワークロードの機能に同期または非同期データ レプリケーションが必要かどうかを判断します。 詳細については、「可用性ゾーンとリージョンを使用するための推奨事項」を参照してください。

• 地理的に局所的な障害の影響を最小化するために、サービスのサポートに従ってデータを地理的に分散させます。

• データベース インスタンスの障害後にフェールオーバーを自動化します。 複数の Azure PaaS データ サービスで自動フェールオーバーを構成できます。 Azure Cosmos DB などのマルチリージョンの書き込みをサポートするデータ ストアでは、自動フェールオーバーは必要ありません。 詳細については、 DR 戦略の設計に関する推奨事項を参照してください。

• データに最適なデータ ストアを使用します。 ポリグロットな永続化、つまりさまざまなデータ ストア テクノロジを組み合わせて使用するソリューションを使用します。 データには、永続化されたアプリケーション データ以外のものも含まれます。 アプリケーション ログ、イベント、メッセージ、およびキャッシュも含まれています。

• データ整合性の要件を考慮し、要件で許可されている場合は最終的な整合性を使用します。 データが分散している場合は、適切な調整を使用して厳密な整合性保証を強制します。 調整によってスループットが低下し、システムが密に結合され、システムが弱まる可能性があります。 たとえば、1 つの操作で 2 つのデータベースを更新する場合、1 つのトランザクション スコープに配置するのではなく、システムが最終的な整合性に対応できる方が適しています。

• 可用性のためにデータをパーティション分割します。 データベースのパーティション分割によりスケーラビリティが向上し、可用性も向上します。 あるシャードがダウンしても、それ以外のシャードには引き続きアクセスできます。 あるシャードで発生した障害によって中断されるのは、トランザクション全体のサブセットのみです。

• シャーディングがオプションでない場合は、 コマンド クエリ責任分離 (CQRS) パターン を使用して、読み取り/書き込みデータ モデルと読み取り専用データ モデルを分離できます。 より多くの回復性を提供するために、冗長な読み取り専用データベース インスタンスをさらに追加します。

ネットワーク リソース:

• 信頼性が高くスケーラブルなネットワーク トポロジを決定します。 ハブアンドスポーク モデルまたは Azure Virtual WAN モデルを使用して、クラウド インフラストラクチャを論理パターンに整理し、冗長性設計を簡単に構築およびスケーリングできるようにします。

• 適切なネットワーク サービスを選択してリージョン内またはリージョン間で要求のバランスを取り、リダイレクトします。 信頼性目標を達成するために、可能な場合はグローバルまたはゾーン冗長の負荷分散サービスを使用します。

• スケールアウト要件を含め、計画的な使用を考慮するために、仮想ネットワークとサブネットに十分な IP アドレス空間が割り当てられていることを確認します。

• 選択したアプリケーション ホスティング プラットフォームのポート制限内で、アプリケーションをスケーリングできることを確認します。 アプリケーションが複数の送信伝送制御プロトコル (TCP) またはユーザー データグラム プロトコル (UDP) 接続を開始すると、使用可能なすべてのポートが使い果たされ、アプリケーションのパフォーマンスが低下する可能性があります。

• SKU を選択し、帯域幅と可用性の要件を満たすことができるネットワーク サービスを構成します。 VPN ゲートウェイのスループットは、SKU によって異なります。 ゾーン冗長のサポートは、一部のロード バランサー SKU でのみ使用できます。

• ドメイン ネーム システム (DNS) を処理するための設計が回復性に重点を置いて構築され、冗長インフラストラクチャをサポートしていることを確認します。

デプロイ スタンプ パターンを使用して冗長性アプローチを合理化する

個々のインフラストラクチャ コンポーネントとサービスの冗長性を超えて、ワークロード全体またはリソースの論理グループの複数のインスタンスをデプロイすることで、冗長性戦略をワークロード レベルに拡張します。 デプロイ スタンプの設計パターンに従って、ワークロードを特定のユーザーまたは要件のサブセットに配信するために必要なすべてのリソースを含む、反復可能な自己完結型ユニットを作成します。

デプロイ スタンプは、コンポーネント レベルからワークロード レベルの冗長性への移行を表します。 各スタンプは、独立して動作できる必要なすべてのリソース (コンピューティング、ストレージ、ネットワーク、依存関係) を含むスケールの完全な単位として機能します。 このアプローチには、ブラスト半径を含む分離された障害ドメイン、個々のコンポーネントのスケーリングではなく、追加のスタンプデプロイによる水平スケーリング、地理的または要件による柔軟なセグメント化、同一の反復可能なユニットによる簡略化された操作など、主な利点があります。

アクティブ/アクティブ モデル (すべてのスタンプがトラフィックを同時に処理する) またはアクティブ/パッシブ モデル (1 つのスタンプがトラフィックを処理し、他のスタンプがスタンバイ状態のままである) のいずれにでも、各スタンプは、指定されたワークロードを個別に処理できる完全で自己十分なデプロイに設計します。

アクティブ/アクティブ冗長性を使用してダウンタイムをゼロにする

アクティブ/アクティブデプロイでは、ワークロードの複数のインスタンスを同時に実行し、それぞれがアクティブにトラフィックを処理することで、サービスの可用性を最大化します。 このセットアップにより、すべてのインスタンスの生産性を維持することで、迅速なフェールオーバーが保証され、ダウンタイムが排除され、リソースの使用が最適化されます。 1 つのインスタンスが失敗した場合、トラフィックはサービスを中断することなく正常なインスタンスに自動的に再ルーティングされます。

たとえば、ピークシーズン中の e コマース プラットフォームでは、1 つのデプロイで問題が発生した場合でもシームレスな運用を維持できます。 アクティブ/アクティブ構成は、中断のない可用性を必要とするミッション クリティカルなワークロードに最適ですが、インフラストラクチャのコストと複雑さが高くなります。 複数のライブ環境を管理し、データの一貫性を確保し、すべてのインスタンスで更新を調整するには、高度な運用戦略が必要です。

次のセクションでは、アクティブ/アクティブデプロイの構成オプションについて説明します。

• 容量でのアクティブ/アクティブ: 2 つ以上の場所にミラー化されたデプロイ スタンプ。それぞれが、サービスを提供する場所または場所の運用ワークロードを処理するように構成され、リージョンの停止が発生した場合に他の場所からの負荷を処理するためにスケーラブルです。

  • ネットワーキング：待機時間または加重グローバル ルーティングを使用して、場所間でトラフィックを分散します。

  • データレプリケーションと一貫性: 複数リージョンの読み取りおよび書き込み機能には 、Azure Cosmos DB などのグローバル分散データ ストアを使用します。 リレーショナル データベースの場合は、接続文字列が読み取り専用である読み取り可能なレプリカを使用します。

  • この設計の利点: オーバープロビジョニング設計よりも運用コストを削減します。

  • この設計の欠点: 別の場所で障害が発生した場合に、フル ロードの要求を満たすようにスケールアップするときのユーザー エクスペリエンスが低下する可能性があります。

• アクティブ/アクティブオーバープロビジョニング: 2 つ以上の場所にミラー化されたデプロイ スタンプ。それぞれが、サービスを提供する場所または場所の運用ワークロードを処理し、地域的な停止が発生した場合に他の場所からの負荷を処理するためにオーバープロビジョニングされます。

  • ネットワーキング：待機時間または加重グローバル ルーティングを使用して、場所間でトラフィックを分散します。

  • データレプリケーションと一貫性: 複数リージョンの読み取りおよび書き込み機能には 、Azure Cosmos DB などのグローバル分散データ ストアを使用します。 リレーショナル データベースの場合は、接続文字列が読み取り専用である読み取り可能なレプリカを使用します。

  • この設計の利点: 可能な限り最も回復性の高い設計。

  • この設計の欠点: スケーラブルな設計よりも運用コストが高い。

• 両方の設計の一般的な利点: 高い回復性と、ワークロード全体の停止のリスクが低い。

• 両方の設計の一般的な欠点: アプリケーションの状態とデータの同期を管理する必要があるなど、さまざまな要因により、運用コストと管理負担が高くなります。

アクティブ/パッシブ アーキテクチャ設計を使用して DR の回復性を提供する

アクティブ/パッシブ デプロイ構成では、セカンダリ インスタンスをアイドル状態にしたまま、準備ができている状態で、すべてのトラフィックを処理するプライマリ インスタンスを実行して DR を確保するコスト効率の高い方法が提供されます。 これらのスタンバイ インスタンスは、プライマリ インスタンスが失敗した場合、またはメンテナンスが実行された場合にのみアクティブ化されます。 この方法では、信頼性の高いフェールオーバー機能を提供しながら、リソースの使用量を最小限に抑えます。

たとえば、金融取引プラットフォームでは、この設定を使用してサービス継続性を維持できます。 プライマリ システムはすべてのトランザクションを管理しますが、セカンダリ システムはバックグラウンドで同期されたままです。 プライマリ システムがダウンした場合、セカンダリ システムは中断を最小限に抑えて操作をすばやく引き継ぎ、復元します。 このアプローチでは信頼性とコストのバランスが取れるので、アクティブ/アクティブデプロイの複雑さや費用をかけずに短い復旧時間を許容できるワークロードに最適です。

アクティブ/パッシブデプロイでは、次の構成オプションを検討してください。

• ウォーム スペア: 1 つのプライマリの場所と 1 つ以上のセカンダリの場所。 セカンダリロケーションは、可能な限り最小限のコンピューティングとデータのサイズ設定でデプロイされ、負荷なしで実行されます。 この場所は、 ウォーム スペア の場所と呼ばれます。 フェールオーバー後、コンピューティング リソースとデータ リソースは、プライマリ ロケーションからの負荷を処理するようにスケーリングされます。

  • ネットワーキング： 優先度の高 い グローバル ルーティングを使用します。

  • データレプリケーションと一貫性: データベースをパッシブな場所にレプリケートし、 Azure Cosmos DB や Azure SQL Database などの PaaS ソリューションの自動フェールオーバー機能を使用します。

  • この設計の利点: アクティブ/パッシブ設計の中で最短の復旧時間。

  • この設計の欠点: アクティブ/パッシブ設計の中で最も高い運用コスト。

• コールド スペア: 1 つのプライマリの場所と 1 つ以上のセカンダリの場所。 セカンダリの場所は、完全な負荷を処理するようにスケーリングされますが、すべてのコンピューティング リソースは停止されます。 この場所は、 コールド スペア の場所と呼ばれます。 フェールオーバーの前にリソースを開始する必要があります。

  • ネットワーキング： 優先度の高 い グローバル ルーティングを使用します。

  • データレプリケーションと一貫性: データベースをパッシブな場所にレプリケートし、 Azure Cosmos DB や SQL Database などの PaaS ソリューションの自動フェールオーバー機能を使用します。

  • この設計の利点: 暖かい予備の設計より低い操業費用。

  • この設計の欠点: 暖かい予備の設計より長い回復時間。

多くの独立したインフラストラクチャにワークロードを分散する

近くの独立したデータセンターまたはデータセンター セクターにワークロードをデプロイすると、パフォーマンスを損なうことなく冗長性が提供されます。 地理的に近いが物理的に分離された機能を使用することで、このセットアップにより、待機時間への影響を最小限に抑えながら、障害の分離が保証されます。 単一サイト展開の応答性を維持しながら、分散インフラストラクチャの回復性を提供します。 Azure では、可用性ゾーンによってこの機能が提供されます。 可用性ゾーンは、フォールト トレラントで待ち時間の短いワークロードを簡単にデプロイできるように設計された、物理的に独立したデータセンターまたはデータセンター セクターです。

リアルタイム ゲームなどの待機時間の影響を受けやすいアプリケーションでは、このアプローチによりシームレスなフェールオーバーと中断のないユーザー エクスペリエンスが可能になります。 ローカル データセンターに分散されたゲーム サーバーは、障害発生時にトラフィックを即座に再ルーティングできます。透過的な負荷分散とほぼリアルタイムのデータ レプリケーションにより、ゲームプレイの継続性が維持されます。 ただし、大規模な地域イベントは引き続きすべてのサイトに同時に影響を与える可能性があるため、この戦略にはリスクが伴います。

地理的に離れたデプロイでフォールト トレランスを強化する

地理的に分散されたデータセンターにデプロイすると、数百から数千マイル離れたリージョンにワークロードを分散させることで、大規模な災害に対する最も強力な保護が提供されます。 このアプローチにより、自然災害、インフラストラクチャの障害、大都市圏全体に影響を与える可能性のある地政学的な中断などのイベント中のビジネス継続性が保証されます。 Azure では、世界中に分散しているリージョンにワークロードをデプロイできます。 この設計アプローチを使用する場合は、ユーザーに近いが地理的に離れているリージョン (米国西部や米国東部など) を選択します。

たとえば、グローバルな金融プラットフォームでは、1 つの領域で大規模な停止が発生した場合に、影響を受けないリージョンにトラフィックをルーティングすることで、中断のないサービスを維持できます。 このアプローチにより、回復性が最大化され、管轄区域全体の規制コンプライアンスがサポートされますが、待機時間が長くなり、複雑なデータ整合性要件が発生し、運用オーバーヘッドが増加します。 グローバル冗長性の利点と比較して、これらの要因を慎重に検討する必要があります。

Azure ファシリテーション

Azure プラットフォームは、次のアクションを実行することで、ワークロードの回復性を最適化し、冗長性を追加するのに役立ちます。

• 「Azure リージョンの選択」ガイドを使用して、マルチリージョン アーキテクチャに最適な Azure リージョンを選択するのに役立ちます。

• 多くの PaaS および SaaS ソリューションで組み込みの冗長性を提供します。その一部は構成可能です。

• 構成を必要とせずに透過的に冗長性を実装する Microsoft Entra ID、Azure DNS、Key Vault などのグローバルマネージド サービスを提供します。

• 可用性ゾーンとリージョン間の冗長性を使用して、リージョン内の冗長性を設計および実装できます。

• 仮想マシン (VM) をデプロイするときに、コンピューティングを可用性ゾーン間で自動的に均等に分散できる、仮想マシン スケール セットなどのゾーン冗長コンピューティング ソリューションを提供します。

• Azure Application Gateway、AzureFront Door、Azure Load Balancer などのレプリカ対応の負荷分散サービスを提供します。

• SQL Database のアクティブ geo レプリケーションなどの簡単に実装された geo レプリケーション ソリューションを提供します。 Azure Cosmos DB を使用してグローバル分散と透過的なレプリケーションを実装します。 Azure Cosmos DB には、 競合する書き込みを処理するための 2 つのオプションが用意されています。 ワークロードに最適なオプションを選択してください。

• 多くの PaaS データ サービスにポイントインタイム リストア (PITR) 機能を提供します。

• Azure NAT ゲートウェイまたは Azure Firewall を使用してポートの枯渇を軽減します。

DNS 固有の Azure ファシリテーション

• 内部の名前解決シナリオでは、ゾーン冗長と geo 冗長性が組み込まれている Azure DNS Private Zones を使用します。 詳細については、「Azure DNS プライベート ゾーンの回復性」を参照してください。

• 外部の名前解決シナリオでは、ゾーン冗長と geo 冗長性が組み込まれている Azure DNS パブリック ゾーンを使用します。

• パブリックおよびプライベートの Azure DNS サービスはグローバル サービスであり、ゾーン データはグローバルに利用できるため、リージョンの障害に対して回復性があります。

• オンプレミスおよびクラウド環境間のハイブリッド名前解決シナリオでは、Azure DNS Private Resolver を使用します。 ワークロードが可用性ゾーンをサポートするリージョンにある場合、このサービスはゾーン冗長をサポートします。 ゾーン全体が停止した場合、ゾーンの復旧中に操作は必要ありません。 サービスは自動的に自己修復と再調整を行って、正常なゾーンを利用します。 詳細については、「Azure DNS Private Resolver の回復性」を参照してください。

• 単一障害点を排除し、リージョン間でより回復性の高いハイブリッド名前解決を実現するには、複数の Azure DNS プライベート リゾルバーを異なるリージョンにデプロイします。 条件付き転送シナリオでは、DNS フェールオーバーは、リゾルバーをプライマリ DNS サーバーとして割り当てることで実現されます。 別のリージョンの他のリゾルバーをセカンダリ DNS サーバーとして割り当てます。 詳細については、「プライベート リゾルバーを使用して DNS フェールオーバーを設定する」を参照してください。

例

複数リージョンの冗長デプロイの例については、「ベースラインの高可用性ゾーン冗長 Web アプリケーション」を参照してください。

次の図は、別の例を示しています。

関連リンク

冗長性の詳細については、次のリソースを参照してください。

• Azure リージョン ガイド
• Azure Storage の冗長性
• ゾーン冗長ストレージ
• SQL Database のアクティブ geo レプリケーション
• 2 つのマネージド インスタンス間でのレプリケーションの構成

信頼性チェックリスト

レコメンデーションの完全なセットを参照してください。