すべてを冗長化

単一障害点をなくすために、冗長性をアプリケーションに組み込みます

耐障害性のあるアプリケーションでは障害が回避されます。 アプリケーションのクリティカル パスを特定してください。 パスの各ポイントに冗長性が確保されていますか。 サブシステムで障害が発生した場合に、アプリケーションは他にフェールオーバーしますか。

Recommendations

ビジネス要件を考慮する。 システムにどのくらいの冗長性を組み込むかは、コストと複雑さの両方に影響します。 アーキテクチャには、目標復旧時間 (RTO) や目標復旧時点 (RPO) などのビジネス要件の情報が必要です。 また、パフォーマンス要件と、複雑なリソースのセットを管理するチームの能力も考慮する必要があります。

マルチゾーンおよびマルチリージョンのアーキテクチャを検討してください。 可用性ゾーンとリージョンが復元力とさまざまなアーキテクチャ上のトレードオフをどのように提供するかを必ず理解してください。

Azure 可用性ゾーンは、リージョン内の分離されたデータ センターのセットです。 可用性ゾーンを使用すると、単一のデータ センターまたは可用性ゾーン全体の障害に対する回復力を高めることができます。 可用性ゾーンを使用すると、コスト、リスク軽減、パフォーマンス、回復可能性の間でトレードオフを行うことができます。 たとえば、アーキテクチャでゾーン冗長サービスを使用すると、Azure は地理的に離れたインスタンス間で自動データ レプリケーションとフェールオーバーを提供し、さまざまな種類のリスクを軽減します。

ミッションクリティカルなワークロードがあり、リージョン全体の停止のリスクを軽減する必要がある場合は、マルチリージョン デプロイを検討してください。 複数リージョンのデプロイは地域的な災害から身を守ることができますが、コストがかかります。 複数リージョンのデプロイは、単一リージョンのデプロイよりも高価であり、管理がより複雑です。 フェールオーバーとフェールバックを処理するための操作手順が必要になります。 RPO の要件によっては、リージョン間のデータ レプリケーションを有効にするために、パフォーマンスが若干低下することを受け入れる必要がある場合があります。 追加コストと複雑さが理にかなっているかどうかは、ビジネス シナリオによって異なります。

可用性ゾーンとリージョンを使用するようにソリューションを設計する方法の詳細については、「可用性ゾーンとリージョンを使用 するための推奨事項」を参照してください。

VM をロード バランサーの内側に配置する。 ミッション クリティカルなワークロードには、単一 VM を使用しないでください。 代わりに、複数の VM をロード バランサーの内側に配置します。 VM が使用できなくなると、ロード バランサーは、残りの正常な VM にトラフィックを分散します。

データベースをレプリケートする。 Azure SQL Database と Azure Cosmos DB は、リージョン内のデータを自動的にレプリケートし、可用性ゾーン間でレプリケートするように構成して、復元性を高めることができます。 リージョン間で geo レプリケーションを有効にすることも選択できます。 Azure SQL Database と Azure Cosmos DB の geo レプリケーションにより、1 つ以上のセカンダリ リージョンにデータの読み取り可能セカンダリ レプリカが作成されます。 プライマリ リージョンで障害が発生した場合、データベースは書き込みのためにセカンダリ リージョンにフェールオーバーできます。 レプリケーション構成によっては、レプリケートされていないトランザクションにより一部のデータ損失が発生する可能性があります。

IaaS データベース ソリューションを使用している場合は、SQL Server Always On 可用性グループなど、レプリケーションとフェールオーバーをサポートするものを選択します。

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

マルチリージョン ソリューション

次の図は、Azure Traffic Manager を使用してフェールオーバーを処理する複数リージョン アプリケーションを示しています。

フェールオーバー ルーティング メカニズムとしてマルチリージョン ソリューションで Traffic Manager または Azure Front Door を使用する場合は、次のレコメンデーションを考慮してください。

フロントエンドおよびバックエンドのフェールオーバーを同期する。 ルーティング メカニズムを使用してフロント エンドをフェイルオーバーします。 あるリージョンでフロントエンドがアクセス不能になった場合、フェイルオーバーにより新しいリクエストがセカンダリ リージョンにルーティングされます。 バックエンド コンポーネントとデータベース ソリューションによっては、バックエンド サービスとデータベースのフェイルオーバーを調整する必要がある場合があります。

自動フェールオーバーを使用するが、フェールバックは手動で行う。 フェイルオーバーには自動化を使用しますが、フェイルバックには使用しません。 自動フェールバックには、完全に正常な状態に戻る前に、プライマリ リージョンに切り替えられてしまうリスクがあります。 そうではなく、手動でフェールバックする前に、すべてのアプリケーション サブシステムが正常であることを確認してください。 また、フェイルバックする前にデータの一貫性を確認する必要があります。

これを実現するには、フェールオーバー後にプライマリ エンドポイントを無効にします。 プローブの監視間隔が短く、許容される障害数が少ない場合は、フェールオーバーとフェールバックが短時間で行われます。 場合によっては、無効化が時間内に完了しない場合があります。 未確認のフェールバックを回避するには、すべてのサブシステムが正常であることを確認できる正常性エンドポイントを実装することも検討してください。 「正常性エンドポイントの監視パターン」を参照してください。

ルーティングソリューションに冗長性を取り入れる. ミッションクリティカルな Web アプリケーション向けに グローバル ルーティング冗長ソリューション を設計することを検討してください。