すべてを冗長化

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

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

Recommendations

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

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

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

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

ヒント

多くのワークロードでは、ゾーン冗長アーキテクチャが最適なトレードオフを提供します。 ビジネス要件により、リージョン全体の停止という起こりそうもないリスクを軽減する必要があることが示されており、そのようなアプローチに伴うトレードオフを受け入れる準備ができている場合は、マルチリージョン アーキテクチャを検討してください。

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

VM をロード バランサーの内側に配置する。 ミッション クリティカルなワークロードには、単一 VM を使用しないでください。 代わりに、複数の VM をロード バランサーの内側に配置します。 VM が使用できなくなると、ロード バランサーは、残りの正常な VM にトラフィックを分散します。 この構成をデプロイする方法については、「スケーラビリティと可用性のための複数の VM」や「multi-vm-blueprint」に関する記事をご覧ください。

データベースをレプリケートする。 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 を使用する場合は、次の推奨事項を考慮してください。

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

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

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

Traffic Manager の冗長性を確保する。 Traffic Manager が障害ポイントになる可能性があります。 Traffic Manager の SLA を確認し、Traffic Manager を使用するだけで、高可用性のビジネス要件を満たすかどうかを確かめてください。 満たされない場合は、フェールバックとして別のトラフィック管理ソリューションを追加することを検討してください。 Azure Traffic Manager サービスで障害が発生した場合は、他のトラフィック管理サービスを参照するように、DNS の CNAME レコードを変更します