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 インスタンスのメトリックと診断ログが格納されます。
Container Registry: ワークロードのコンテナー イメージは、マネージド コンテナー レジストリに格納されます。 このソリューションでは、クラスター内のすべての Kubernetes インスタンスに対して 1 つの Azure Container Registry インスタンスが使用されます。 Azure Container Registry の geo レプリケーションにより、選択した Azure リージョンへのイメージのレプリケートが可能になり、リージョンで障害が発生した場合でも、イメージへの継続的なアクセスを提供します。
フェールオーバー プロセス
あるリージョンでサービスまたはサービス コンポーネントが使用できなくなった場合、そのサービスが利用可能なリージョンにトラフィックをルーティングする必要があります。 複数リージョンのアーキテクチャには、さまざまな障害点が含まれています。 このセクションでは、潜在的な障害点について説明します。
アプリケーション ポッド (リージョン)
Kubernetes デプロイ オブジェクトは、ポッドの複数のレプリカ (ReplicaSet) を作成します。 1 つが使用できない場合、トラフィックは残っているレプリカの間にルーティングされます。 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 では、クラスターでカオス実験を作成する機能が提供されます。
次のステップ
別のソリューションを検討する場合は、次の記事を参照してください。
Azure Kubernetes Service