英語で読む

次の方法で共有


Azure Kubernetes Service (AKS) のアクティブ/パッシブ ディザスター リカバリー ソリューションの概要

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 では、クラスターでカオス実験を作成する機能が提供されます。

次のステップ

別のソリューションを検討する場合は、次の記事を参照してください。