マルチリージョンのアクティブ／アクティブ アーキテクチャ

可用性ゾーンを使用していても、単一のAzureリージョンにデプロイされたワークロードは、リージョン障害の影響を受ける可能性があります。これは、大規模な災害、激しい嵐、大規模なインフラストラクチャ障害などによって引き起こされる、まれではあるものの起こり得る事象です。最高レベルの可用性を実現するために、企業は2つ以上のAzureリージョンにワークロードをデプロイし、リージョン全体がオフラインになってもアプリケーションがユーザーへのサービス提供を継続できるようにします。

マルチリージョン構成には、主に2つのパターンがあります。

• アクティブ-アクティブ — 両方のリージョンにあるリソースが同時に実際のトラフィックを処理します。可用性を最大化できるほか、ユーザーを最も近いリージョンにルーティングすることで、レイテンシーも低減できます。
• アクティブ-パッシブ — セカンダリリージョンのリソースは待機状態になり、フェイルオーバー発生後にのみトラフィックを受け取ります。コストは低くなりますが、復旧時間は長くなります。

最高レベルの可用性が必要な場合は、アクティブ-アクティブが推奨されます。

Azure Traffic Managerは、異なるAzureリージョン（またはオンプレミス）のエンドポイント間でトラフィックを分散する、DNSベースのグローバルロードバランサーです。正常性プローブで各エンドポイントを監視し、ルーティング方法（パフォーマンス、重み付け、優先順位、地理的、多値）に基づいてトラフィックの送信先を決定します。アクティブ-アクティブ構成では、パフォーマンスルーティング方法を使用して、ユーザーを最も近い正常なリージョンに誘導します。

Traffic Managerは、さまざまなシナリオに対応する複数のルーティング方法をサポートしています。

• パフォーマンス — レイテンシーが最も低いエンドポイントへルーティングします（アクティブ-アクティブに最適）
• 重み付け — 割り当てた割合に基づいてトラフィックを分散します（段階的なロールアウトに便利）
• 優先順位 — すべてのトラフィックをプライマリエンドポイントに送信し、障害時はセカンダリに切り替えます（アクティブ-パッシブ）
• 地理的 — ユーザーの地理的位置に基づいてルーティングします（データ主権への対応）

アクティブ-アクティブアーキテクチャでは、どちらのリージョンのユーザーも一貫したデータを読み取れるように、データをリージョン間でレプリケートする必要があります。選択肢には次のものがあります。

• geoレプリケーションを使用するAzure SQL Database — 別のリージョンに読み取り可能なセカンダリを配置します
• マルチリージョン書き込みを使用するAzure Cosmos DB — すべてのリージョンが同時に書き込みを受け付けます
• GRSを使用するAzure Storage — セカンダリリージョンに非同期レプリケーションを行います

選択は、データの一貫性と書き込み可用性に関する要件によって決まります。

Azure Cosmos DBは、マルチリージョン書き込みをサポートしているため、アクティブ-アクティブアーキテクチャに特に適しています。構成したすべてのリージョンが、同時に書き込み操作を受け付けられます。Cosmos DBでは、構成可能な整合性レベル（強い整合性から結果整合性まで）を使用して、レプリカの同期方法を管理します。アクティブ-アクティブのシナリオでは、パフォーマンスと正確性のバランスを取れるセッション整合性または有界整合性が一般的な選択肢です。

Traffic ManagerとAzure Front Doorはいずれもグローバルな負荷分散を提供しますが、動作するレベルが異なります。

• Traffic ManagerはDNSベースです。クライアントを適切なリージョンのエンドポイントへリダイレクトしますが、接続はそのエンドポイントに直接確立されます。DNS層で動作します。
• Azure Front Doorはエニーキャストプロキシです。グローバルなPoPでクライアント接続を終端し、リクエストをオリジンへ転送します。ルーティングに加えて、WAF、SSLオフロード、キャッシュも提供します。

Microsoftは各Azureリージョンに対してリージョンペアを指定しています。これは、同じ地理的範囲内にありながら、リージョン規模の災害に耐えられるよう十分に離れたセカンダリリージョンです。マルチリージョンアーキテクチャを設計する場合は、可能であればペアになっているリージョンをセカンダリとして使用します。計画されたプラットフォームメンテナンスでは、ペアのリージョンのうち一方だけが一度に更新されるため、同時に発生する影響を抑えられます。

アクティブ-アクティブのデプロイでは、同じユーザーのリクエストが、リクエストごとに異なるリージョンで処理される可能性があります。アプリケーションがWebサーバー上のメモリにセッション状態を保存している場合、ユーザーがリージョンを切り替えると問題が発生します。解決策は、Azure Cache for Redisのgeoレプリケーションなどの分散セッションストアを使用し、どのリージョンからでもセッションデータにアクセスできるようにすることです。

アクティブ-アクティブアーキテクチャは、少なくとも2つのリージョンでインフラストラクチャの完全なコピーを稼働させるため、単一リージョンのデプロイよりもコストが高くなります。追加コストには、リージョン間のデータ転送、データベースのgeoレプリケーション、Traffic ManagerまたはFront Doorの料金などがあります。費用対効果分析を実施してください。ミッションクリティカルなワークロードでは、通常、ダウンタイムのコストが2つ目のリージョンのコストを大幅に上回ります。

アクティブ-アクティブアーキテクチャは、必要なときに機能することを確認するため、定期的にテストする必要があります。Azure Chaos Studioなどのカオスエンジニアリングツールを使用すると、1つのリージョンにあるすべてのVMを停止するなどの障害を意図的に発生させ、システムの応答を観察できます。定期的なテストによって、Traffic Managerの正常性プローブが障害を検出すること、フェイルオーバーがRTO内に完了すること、リージョン間でデータの一貫性が保たれることを確認できます。

このレッスンで扱ったMicrosoft Azure Fundamentals（AZ-900）の概念について、理解度を確認します。

このレッスンでは、次のことを学びました。アクティブ-アクティブアーキテクチャは、最大限の可用性を実現するため、複数のリージョンで稼働中のリソースを同時にデプロイします。Azure Traffic Managerは、パフォーマンス、優先順位、重み付け、地理的などの方法でトラフィックをルーティングします。また、リージョン間の一貫性を保つには、データレプリケーション（Cosmos DBのマルチリージョン書き込み、SQLのgeoレプリケーション）が不可欠です。次は、正常性プローブとグレースフルデグラデーションのパターンについて学びます。