Azure Kubernetes Service (AKS) のマルチリージョン デプロイ モデル

Azure Kubernetes Service (AKS) は、コンテナー化されたアプリケーションをデプロイ、管理、スケーリングするためのマネージド Kubernetes 環境を提供します。 AKS で実行されているアプリケーションのリージョンの停止に対する回復性を提供するために、さまざまなマルチリージョン デプロイ モデルを実装できます。 この記事では、これらのモデルの概要、長所と短所、アプリケーションのアップタイムを維持するためのベスト プラクティスについて説明します。

AKS には、クラスターと AKS で実行されているアプリケーションの高可用性 (HA) とディザスター リカバリー (DR) の両方をサポートするさまざまな機能が用意されています。 AKS が信頼性要件をサポートする方法の詳細については、「 AKS の信頼性」を参照してください。

考慮事項

AKS で複数リージョンデプロイ モデルを実装する際の重要な考慮事項を次に示します。

リージョン リソースとグローバル リソース

リージョン リソースは、デプロイ スタンプの一部として単一の Azure リージョンにプロビジョニングされます。 これらのリソースは、他のリージョンのリソースと何も共有せず、個別に削除したり、他のリージョンにレプリケートしたりすることができます。 詳細については、「リージョン リソース」を参照してください。

グローバル リソースは、システムの有効期間を共有し、マルチリージョン デプロイのコンテキスト内でグローバルに使用できます。 詳細については、「グローバル リソース」を参照してください。

グローバル負荷分散

グローバル負荷分散サービスは、トラフィックをリージョンのバックエンド間、クラウド間、またはハイブリッド オンプレミス サービス間で分散します。 これらのサービスは、エンドユーザーのトラフィックを、最も近い使用可能なバックエンドにルーティングします。 可用性とパフォーマンスを最大化するために、サービスの信頼性またはパフォーマンスの変化にも反応します。 グローバル負荷分散を提供する Azure サービスは、次のとおりです。

• Azure Front Door
• Azure Traffic Manager
• リージョン間の Azure Load Balancer
• Azure Kubernetes Fleet Manager

スコープ定義

アプリケーションのアップタイムは、AKS クラスターを管理する際に重要になります。 既定で、AKS では、仮想マシン スケール セット 内の複数のノードを使用して高可用性を提供しますが、これらのノードによってシステムがリージョン障害から保護されることはありません。 アップタイムを最大化するには、次のベスト プラクティスを使用して、事業継続の維持とディザスター リカバリーの準備を事前に計画します。

• 複数リージョン内の AKS クラスターに関する計画を立てる。
• Azure Traffic Manager を使用して、複数のクラスター間でトラフィックをルーティングする。
• コンテナー イメージのレジストリに geo レプリケーションを使用する。
• 複数のクラスター間でのアプリケーション状態に関する計画を立てる。
• 複数のリージョン間でストレージをレプリケートする。

複数リージョンデプロイ モデルの実装

次の表は、AKS の 3 つの主要なマルチリージョン デプロイ モデルとその長所と短所をまとめたものです。

アクティブ/アクティブの高可用性デプロイ モデル

アクティブ/アクティブの高可用性 (HA) デプロイ モデルでは、2 つの異なる Azure リージョン (通常は、カナダ中部とカナダ東部、米国東部 2 と米国中部などのペアになっているリージョン) に、トラフィックをアクティブに処理する 2 つの独立した AKS クラスターがデプロイされます。

このアーキテクチャ例では、次のようになります。

• 2 つの AKS クラスターを個別の Azure リージョンにデプロイします。
• 通常の運用中、ネットワーク トラフィックは両方のリージョン間にルーティングされます。 一方のリージョンが使用できなくなった場合、トラフィックは、要求を発行したユーザーに最も近いリージョンに自動的にルーティングされます。
• リージョンの AKS インスタンスごとにハブスポークのペアがデプロイされます。 各リージョン間のファイアウォール規則は、Azure Firewall Manager ポリシーによって管理されます。
• Azure Key Vault は、シークレットとキーを格納するために、各リージョンにプロビジョニングされます。
• Azure Front Door は、トラフィックを負荷分散し、各 AKS クラスターの前に配置されているリージョンの Azure Application Gateway インスタンスにルーティングします。
• リージョンの Log Analytics インスタンスは、リージョンのネットワーク メトリックと診断ログを格納します。
• ワークロードのコンテナー イメージは、マネージド コンテナー レジストリに格納されます。 1 つの Azure Container Registry が、クラスター内のすべての Kubernetes インスタンスに使用されます。 Azure Container Registry の geo レプリケーションにより、選択した Azure リージョンへのイメージのレプリケートが可能になり、リージョンで停止が発生した場合でも、引き続きイメージにアクセスできます。

AKS でアクティブ/アクティブのデプロイ モデルを作成するには、次の手順を行います。

1. 2 つの異なる Azure リージョンに 2 つの同一のデプロイを作成します。

2. Web アプリの 2 つのインスタンスを作成します。

3. 次のリソースを含む Azure Front Door プロファイルを作成します。

   • エンドポイント。
   • それぞれが優先度 1 の 2 つの配信元グループ。
   • 1 つのルート。

4. Web アプリへのネットワーク トラフィックを Azure Front Door インスタンスからのみに制限します。 5 データベース、ストレージ アカウント、認証プロバイダーなどの他のすべてのバックエンド Azure サービスを構成します。

5. 継続的デプロイを使用して、両方の Web アプリにコードをデプロイします。

詳細については、「AKS の推奨されるアクティブ/アクティブの高可用性ソリューションの概要」を参照してください。

アクティブ/パッシブのディザスター リカバリー デプロイ モデル

アクティブ/パッシブのディザスター リカバリー (DR) デプロイ モデルでは、2 つの異なる Azure リージョン (通常は、カナダ中部とカナダ東部、米国東部 2 と米国中部などのペアになっているリージョン) に、トラフィックをアクティブに処理する 2 つの独立した AKS クラスターがデプロイされます。 特定の時点でトラフィックをアクティブに処理するのは、一方のクラスターのみです。 他方のクラスターには、アクティブなクラスターと同じ構成とアプリケーション データが含まれますが、トラフィック マネージャーによって指示されない限り、トラフィックは受け入れられません。

このアーキテクチャ例では、次のようになります。

• 2 つの AKS クラスターを個別の Azure リージョンにデプロイします。
• 通常の操作中、ネットワーク トラフィックは、Azure Front Door 構成で設定されたプライマリ AKS クラスターにルーティングされます。
  • 優先度は、"1 から 5" の間で設定する必要があり、1 が最も高く、5 が最も低い優先度です。
  • 複数のクラスターを同じ優先度レベルに設定し、クラスターごとに重みを指定できます。
• プライマリ クラスターが使用できなくなった (障害が発生した) 場合、トラフィックは Azure Front Door で選択された次のリージョンに自動的にルーティングされます。
  • このシステムが機能するには、すべてのトラフィックが Azure Front Door を経由する必要があります。
• Azure Front Door は、トラフィックをプライマリ リージョンの Azure App Gateway にルーティングします (クラスターには優先度 1 でマークされている必要があります)。 リージョンで障害が発生した場合、サービスにより、優先度リスト内の次のクラスターにトラフィックがリダイレクトされます。
  • 規則は、Azure Front Door から取得されます。
• ハブスポークのペアは、リージョン AKS インスタンスごとにデプロイされます。 各リージョン間のファイアウォール規則は、Azure Firewall Manager ポリシーによって管理されます。
• Azure Key Vault は、シークレットとキーを格納するために、各リージョンにプロビジョニングされます。
• リージョンの Log Analytics インスタンスは、リージョンのネットワーク メトリックと診断ログを格納します。
• ワークロードのコンテナー イメージは、マネージド コンテナー レジストリに格納されます。 1 つの Azure Container Registry が、クラスター内のすべての Kubernetes インスタンスに使用されます。 Azure Container Registry の geo レプリケーションにより、選択した Azure リージョンへのイメージのレプリケートが可能になり、リージョンで停止が発生した場合でも、引き続きイメージにアクセスできます。

AKS でアクティブ/パッシブのデプロイ モデルを作成するには、次の手順を行います。

1. 2 つの異なる Azure リージョンに 2 つの同一のデプロイを作成します。

2. プライマリ リージョンが非アクティブになったときにプライマリと同じインスタンス数にスケーリングされるように、セカンダリ アプリケーションの自動スケーリング規則を構成します。 非アクティブな間は、スケールアップする必要はありません。 これは、コストの削減に役立ちます。

3. Web アプリケーションの 2 つのインスタンスを (各クラスターに 1 つずつ) 作成します。

4. 次のリソースを含む Azure Front Door プロファイルを作成します。

   • エンドポイント。
   • プライマリ リージョン用の優先度が 1 の配信元グループ。
   • セカンダリ リージョン用の優先度が 2 の 2 番目の配信元グループ。
   • 1 つのルート。

5. Web アプリケーションへのネットワーク トラフィックを Azure Front Door インスタンスからのトラフィックのみに制限します。

6. データベース、ストレージ アカウント、認証プロバイダーなどの他のすべてのバックエンド Azure サービスを構成します。

7. 継続的デプロイを使用して、両方の Web アプリケーションにコードをデプロイします。

詳細については、「AKS の推奨されるアクティブ/パッシブのディザスター リカバリー ソリューションの概要」を参照してください。

パッシブ/コールドのフェールオーバー デプロイ モデル

パッシブ/コールドのフェールオーバー デプロイ モデルは、アクティブ/パッシブのディザスター リカバリー デプロイ モデルと同じ方法で構成されます。ただし、クラスターは、障害発生時にユーザーがアクティブにするまで非アクティブのままです。 必要な構成はアクティブ/パッシブと同様ですが、クラスターをアクティブにしてバックアップをトリガーするための手動介入の複雑さが増すため、このアプローチは "対象外" であると考えられます。

このアーキテクチャ例では、次のようになります。

• 回復性を向上するには、可能であれば異なるリージョンまたはゾーンに、2 つの AKS クラスターを作成します。
• フェールオーバーする必要がある場合、デプロイをアクティブにしてトラフィック フローを引き継ぎます。
• プライマリのパッシブ クラスターがダウンした場合、トラフィック フローを引き継ぐには、コールド クラスターを手動でアクティブにする必要があります。
• この条件は、毎回手動で入力して設定するか、ユーザーが指定した特定のイベントによって設定する必要があります。
• Azure Key Vault は、シークレットとキーを格納するために、各リージョンにプロビジョニングされます。
• リージョンの Log Analytics インスタンスは、各クラスターのリージョンのネットワーク メトリックと診断ログを格納します。

AKS でパッシブ/コールドのフェールオーバー デプロイ モデルを作成するには、次の手順を行います。

1. 異なるゾーンまたはリージョンに 2 つの同一のデプロイを作成します。
2. プライマリ リージョンが非アクティブになったときにプライマリと同じインスタンス数にスケーリングされるように、セカンダリ アプリケーションの自動スケーリング規則を構成します。 非アクティブな間は、スケールアップする必要はなく、コストの削減に役立ちます。
3. Web アプリケーションの 2 つのインスタンスを (各クラスターに 1 つずつ) 作成します。
4. データベース、ストレージ アカウント、認証プロバイダーなどの他のすべてのバックエンド Azure サービスを構成します。
5. コールド クラスターをトリガーする必要がある場合の条件を設定します。 必要に応じて、ロード バランサーを使用できます。

詳細については、「AKS の推奨されるパッシブ/コールドのフェールオーバー ソリューションの概要」を参照してください。

詳細については、次の記事を参照してください。

• AKS の信頼性
• Azure Backup (プレビュー) を使用した AKS のバックアップについて
• Azure Backup (プレビュー) を使用して AKS をバックアップする
• ビジネス継続性、高可用性、ディザスター リカバリー