Azure Kubernetes Service (AKS) のアクティブ/パッシブ ディザスター リカバリー ソリューションの概要
Azure Kubernetes Service (AKS) でアプリケーションを作成する場合、リソースの作成時に Azure リージョンを選択すると、単一リージョン アプリになります。 災害時にリージョンが使用できなくなったとき、アプリケーションも使用できなくなります。 セカンダリ Azure リージョンで同じデプロイを作成すると、アプリケーションは単一リージョンの障害の影響を受けにくくなり、事業継続が保証され、リージョン全体のデータ レプリケーションを使用して、最後のアプリケーション状態を回復できます。
このガイドでは、AKS のアクティブ/パッシブ ディザスター リカバリー ソリューションの概要を説明します。 このソリューションでは、2 つの独立した同一の AKS クラスターを、ペアになっている 2 つの Azure リージョンにデプロイし、一方のクラスターのみがトラフィックをアクティブに提供します。
Note
以下の実習は、内部で検討され、Microsoft パートナーと共に審査されています。
アクティブ/パッシブ ソリューションの概要
このディザスター リカバリー アプローチでは、2 つの独立した AKS クラスターが 2 つの Azure リージョンにデプロイされています。 ただし、一度にアクティブにトラフィックを提供するクラスターは 1 つだけです。 セカンダリ クラスター (アクティブにトラフィックを提供しない) には、プライマリ クラスターと同じ構成とアプリケーション データが含まれていますが、Azure Front Door Traffic Manager によって指示されない限り、トラフィックを受け入れません。
シナリオと構成
このソリューションの実装が最も適しているのは、1 つのリージョンでトラフィックをアクティブに提供するリソース (データベースなど) に依存するアプリケーションをホストする場合です。 水平スケーリングなど、両方のリージョンにデプロイされたステートレス アプリケーションをホストする必要があるシナリオでは、アクティブ/パッシブでは待機時間が追加されるため、アクティブ/アクティブ ソリューションを検討することをお勧めします。
コンポーネント
アクティブ/パッシブ ディザスター リカバリー ソリューションでは、多くの Azure サービスが使用されます。 このアーキテクチャの例には次のコンポーネントが含まれます。
複数のクラスターとリージョン: 複数の AKS クラスターを、それぞれ別の Azure リージョンにデプロイします。 通常の操作中、ネットワーク トラフィックは、Azure Front Door 構成で設定されたプライマリ AKS クラスターにルーティングされます。
構成済みのクラスター優先順位付け: 各クラスターに対して 1 から 5 の優先順位レベルを設定します (1 が最も優先度が高く、5 が最も低くなります)。 複数のクラスターを同じ優先度レベルに設定し、クラスターごとに重みを指定できます。 プライマリ クラスターが使用できなくなった場合、トラフィックは Azure Front Door で選択された次のリージョンに自動的にルーティングされます。 このシステムが機能するには、すべてのトラフィックが Azure Front Door を経由する必要があります。
Azure Front Door: Azure Front Door は負荷を分散し、プライマリ リージョンの Azure Application Gateway インスタンスにトラフィックをルーティングします (クラスターには優先度 1 のマークを付ける必要があります)。 リージョンに障害が発生した場合、サービスにより、優先度リスト内の次のクラスターにトラフィックがリダイレクトされます。
詳細については、「優先順位に基づくトラフィック ルーティング」をご覧ください。
ハブスポークのペア: リージョン AKS インスタンスごとにハブスポークのペアがデプロイされます。 Azure Firewall Manager ポリシーが、各リージョン間のファイアウォール規則を管理します。
Key Vault: シークレットとキーを格納するために、Azure Key Vault を各リージョンにプロビジョニングします。
Log Analytics: リージョンの Log Analytics インスタンスは、リージョンのネットワーク メトリックと診断ログを格納します。 共有インスタンスには、すべての AKS インスタンスのメトリックと診断ログが格納されます。
コンテナー レジストリ: ワークロードのコンテナー イメージは、マネージド コンテナー レジストリに格納されます。 このソリューションでは、クラスター内のすべての Kubernetes インスタンスに対して 1 つの Azure Container Registry インスタンスが使用されます。 Azure Container Registry の geo レプリケーションにより、選択した Azure リージョンへのイメージのレプリケートが可能になり、リージョンで障害が発生した場合でも、イメージへの継続的なアクセスを提供します。
フェールオーバー プロセス
あるリージョンでサービスまたはサービス コンポーネントが使用できなくなった場合、そのサービスが利用可能なリージョンにトラフィックをルーティングする必要があります。 複数リージョンのアーキテクチャには、さまざまな障害点が含まれています。 このセクションでは、潜在的な障害点について説明します。
アプリケーション ポッド (リージョン)
Kubernetes デプロイ オブジェクトは、ポッド (ReplicaSet) の複数のレプリカを作成します。 使用できない場合は、残っているレプリカの間でトラフィックがルーティングされます。 Kubernetes ReplicaSet は、指定された数のレプリカを稼働状態に維持しようとします。 1 つのインスタンスがダウンした場合は、新しいインスタンスを再作成する必要があります。 Liveness probe は、ポッドで実行されているアプリケーションまたはプロセスの状態を確認できます。 ポッドが応答していない場合、liveness probe によってポッドが削除され、ReplicaSet によって新しいインスタンスが強制的に作成されます。
詳細については、Kubernetes の ReplicaSet に関するページをご覧ください。
アプリケーション ポッド (グローバル)
リージョン全体が使用できなくなると、クラスター内のポッドは要求を処理できなくなります。 この場合、Azure Front Door インスタンスによってすべてのトラフィックが残りの正常なリージョンにルーティングされます。 これらのリージョンの Kubernetes クラスターとポッドによって、引き続き要求が処理されます。 残りのクラスターへのトラフィックと要求の増加を補うために、次のガイダンスに注意してください。
- リージョンのフェールオーバーによるトラフィックの急激な増加を吸収するために、ネットワークとコンピューティングのリソースを適切なサイズに設定してください。 たとえば、Azure コンテナー ネットワーク インターフェイス (CNI) を使用する場合は、トラフィック負荷が急増したすべてのポッド IP をサポートできるサブネットがあることを確認してください。
- ポッドの水平オートスケーラーを使用して、ポッド レプリカ数を増やし、リージョンの需要の増加を補います。
- AKS クラスター オートスケーラーを使用して、Kubernetes インスタンス ノード数を増やし、増加したリージョンの需要を補います。
Kubernetes ノード プール (リージョン)
リソースを計算するために、局所的なエラー (たとえば、Azure サーバーの 1 つのラックで電源が使用できなくなったなど) が発生することがあります。 AKS ノードがリージョンの単一障害点にならないようにするには、Azure Availability Zones を使用します。 Availability Zones を使用すると、各可用性ゾーン内の AKS ノードが、別の可用性ゾーンで定義されているものから物理的に分離されます。
Kubernetes ノード プール (グローバル)
リージョン全体で障害が発生した場合は、Azure Front Door により、残りの正常なリージョンにトラフィックがルーティングされます。 繰り返しますが、残りのクラスターへのトラフィックや要求の増加を補ってください。
フェールオーバー テスト戦略
現在、テスト目的でデプロイのリージョン全体を停止するメカニズムは AKS 内にありませんが、Azure Chaos Studio では、クラスターでカオス実験を作成する機能が提供されます。
次のステップ
別のソリューションを検討する場合は、次の記事を参照してください。