Azure Kubernetes Service (AKS) のアクティブ/パッシブ ディザスター リカバリー ソリューションの概要
[アーティクル] 2024/08/02
2 人の共同作成者
フィードバック
この記事の内容
アクティブ/パッシブ ソリューションの概要
シナリオと構成
コンポーネント
フェールオーバー プロセス
フェールオーバー テスト戦略
次のステップ
さらに 2 個を表示
Azure Kubernetes Service (AKS) でアプリケーションを作成する場合、リソースの作成時に Azure リージョンを選択すると、単一リージョン アプリになります。 災害時にリージョンが使用できなくなったとき、アプリケーションも使用できなくなります。 セカンダリ Azure リージョンで同じデプロイを作成すると、アプリケーションは単一リージョンの障害の影響を受けにくくなり、事業継続が保証され、リージョン全体のデータ レプリケーションを使用して、最後のアプリケーション状態を回復できます。
このガイドでは、AKS のアクティブ/パッシブ ディザスター リカバリー ソリューションの概要を説明します。 このソリューションでは、2 つの独立した同一の AKS クラスターを、ペアになっている 2 つの Azure リージョンにデプロイし、一方のクラスターのみがトラフィックをアクティブに提供します。
注意
以下の実習は、内部で検討され、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 では、クラスターでカオス実験を作成する機能が提供されます。
別のソリューションを検討する場合は、次の記事を参照してください。