Azure Kubernetes Service (AKS) に推奨されるアクティブ/アクティブ高可用性ソリューションの概要

Azure Kubernetes Service (AKS) でアプリケーションを作成する場合、リソースの作成時に Azure リージョンを選択すると、単一リージョン アプリになります。 障害が発生してリージョンが使用できなくなった場合、アプリケーションも使用できなくなります。 セカンダリ Azure リージョンで同じデプロイを作成すると、アプリケーションは単一リージョンの障害の影響を受けにくくなり、事業継続が保証され、リージョン全体のデータ レプリケーションを使用して、最後のアプリケーション状態を回復できます。

AKS ソリューションを回復できるようにするパターンは複数ありますが、このガイドでは、AKS に推奨されるアクティブ/アクティブ高可用性ソリューションの概要を説明します。 このソリューションでは、2 つの独立した同一の AKS クラスターを、ペアになっている 2 つの Azure リージョンにデプロイし、両方のクラスターでトラフィックをアクティブに提供します。

Note

以下のユース ケースは、AKS 内での標準的な実現方法と見なすことができます。 これは、社内で検討され、Microsoft パートナーと共に検査されたものです。

アクティブ/アクティブ高可用性ソリューションの概要

このソリューションは、トラフィックをアクティブに提供するように構成された 2 つの同一の AKS クラスターに依存します。 グローバル トラフィック マネージャー (Azure Front Door など) を 2 つのクラスターの前に配置して、トラフィックをそれらの間に分散させます。 クラスターを同一の構成にして、ソリューションが機能するために必要なすべてのアプリケーションのインスタンスをホストする必要があります。

可用性ゾーンは、同じリージョン内で AKS クラスターの高可用性とフォールト トレランスを確保するもう 1 つの方法です。 可用性ゾーンを使うと、1 つの Azure リージョン内の複数の分離された場所に、クラスター ノードを分散できます。 これにより、1 つのゾーンが停電、ハードウェア障害、またはネットワークの問題によってダウンした場合でも、クラスターは引き続き実行され、アプリケーションにサービスを提供できます。 可用性ゾーンを使うと、ノード間の待ち時間と競合が減るため、クラスターのパフォーマンスとスケーラビリティも向上します。 AKS クラスター用に可用性ゾーンを設定するには、ノード プールを作成または更新するときに、ゾーン番号を指定する必要があります。 詳しくは、Azure 可用性ゾーンの概要に関する記事をご覧ください。

Note

可用性ゾーンは、多くのリージョンでサポートされています。 ワークロードの回復性と可用性を向上させるには、可用性ゾーンをサポートするリージョンの使用を検討してください。 詳しくは、「リージョン全体でのサービスの中断から復旧する」をご覧ください。

シナリオと構成

このソリューションを実装するのが最適なのは、ステートレス アプリケーションをホストしていて、水平方向のスケーリングなどの他のテクノロジも両方のリージョンにデプロイされている場合、またはそのどちらか一方が使われている場合です。 ホストされるアプリケーションが 1 つのリージョンでのみアクティブなリソース (データベースなど) に依存しているシナリオでは、アクティブ/アクティブよりダウンタイムが多いためにコストを削減できる可能性があるアクティブ/パッシブ ソリューションを実装することをお勧めします。

コンポーネント

アクティブ/アクティブの高可用性ソリューションでは、多くの Azure サービスが使われます。 このセクションでは、このマルチクラスター アーキテクチャに固有のコンポーネントについてのみ説明します。 他のコンポーネントについて詳しくは、AKS のベースライン アーキテクチャに関する記事をご覧ください。

複数のクラスターとリージョン: 複数の AKS クラスターを、それぞれ別の Azure リージョンにデプロイします。 通常の動作の間は、Azure Front Door の構成により、ネットワーク トラフィックはすべてのリージョン間にルーティングされます。 1 つのリージョンが使用できなくなった場合、トラフィックはユーザーの読み込み時間が最も速いリージョンにルーティングされます。

リージョンごとのハブスポーク ネットワーク: リージョン単位のハブスポーク ネットワーク ペアが、リージョンの AKS インスタンスごとにデプロイされます。 Azure Firewall Manager ポリシーによって、すべてのリージョンのファイアウォール ポリシーが管理されます。

リージョン キー ストア: リージョンごとに Azure Key Vault をプロビジョニングして、AKS インスタンスに固有の機密性の高い値とキーを格納し、そのリージョンで見つかるサービスをサポートします。

Azure Front Door: Azure Front Door は、トラフィックを負荷分散し、各 AKS クラスターの前に配置されているリージョンの Azure Application Gateway インスタンスにルーティングします。 Azure Front Door を使うと、"レイヤー 7" のグローバル ルーティングが可能です。

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

次のステップ

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