Azure Kubernetes Service (AKS) のパッシブ/コールド ソリューションの概要
Azure Kubernetes Service (AKS) でアプリケーションを作成する場合、リソースの作成時に Azure リージョンを選択すると、単一リージョン アプリになります。 災害時にリージョンが使用できなくなったとき、アプリケーションも使用できなくなります。 セカンダリ Azure リージョンで同じデプロイを作成すると、アプリケーションは単一リージョンの障害の影響を受けにくくなり、事業継続が保証され、リージョン全体のデータ レプリケーションを使用して、最後のアプリケーション状態を回復できます。
このガイドでは、AKS 用のパッシブ/コールド ソリューションの概要について説明します。 このソリューションでは、2 つの独立した同一の AKS クラスターを、ペアになっている 2 つの Azure リージョンにデプロイし、アプリケーションが必要とされるときは、一方のクラスターのみがトラフィックをアクティブに提供します。
Note
以下の実践手順は、社内で検討され、Microsoft パートナーと共に検査されたものです。
パッシブ/コールド ソリューションの概要
このアプローチでは、2 つの独立した AKS クラスターを 2 つの Azure リージョンにデプロイします。 アプリケーションが必要とされたら、パッシブ クラスターをアクティブ化してトラフィックを受け取ります。 パッシブ クラスターがダウンした場合は、コールド クラスターを手動でアクティブ化して、トラフィックのフローを引き継ぐ必要があります。 この条件は、毎回手動で入力して、または特定のイベントを指定するように、設定できます。
シナリオと構成
このソリューションは、"必要に応じて使用する" ワークロードとして実装するのが最善であり、1 日の特定の時間帯に、またはオンデマンドでワークロードを実行する必要があるシナリオに役立ちます。 パッシブ/コールド アプローチには次の例のようなユース ケースがあります。
- 大きなデータセットに対して複雑でリソースを大量に消費するシミュレーションを実行する必要がある製造会社。 この場合、ハイ パフォーマンスのコンピューティングとストレージ サービスを提供するクラウド リージョンに、パッシブ クラスターを配置します。 パッシブ クラスターは、ユーザーまたはスケジュールによってシミュレーションがトリガーされたときにだけ使われます。 トリガーしてもクラスターが機能しない場合は、コールド クラスターをバックアップとして使用でき、代わりにそこでワークロードを実行できます。
- サイバー攻撃や自然災害が発生した場合に、重要なシステムとデータのバックアップを維持する必要がある政府機関。 この場合は、一般に公開されていない安全で分離された場所に、パッシブ クラスターを配置します。
コンポーネント
パッシブ/コールド ディザスター リカバリー ソリューションでは、多くの Azure サービスが使われます。 このアーキテクチャの例には次のコンポーネントが含まれます。
複数のクラスターとリージョン: 複数の AKS クラスターを、それぞれ別の Azure リージョンにデプロイします。 アプリが必要とされると、ネットワーク トラフィックを受け取るためにパッシブ クラスターがアクティブ化されます。
Key Vault: シークレットとキーを格納するために、Azure Key Vault を各リージョンにプロビジョニングします。
Log Analytics: リージョンの Log Analytics インスタンスは、リージョンのネットワーク メトリックと診断ログを格納します。 共有インスタンスには、すべての AKS インスタンスのメトリックと診断ログが格納されます。
ハブスポークのペア: リージョン AKS インスタンスごとにハブスポークのペアがデプロイされます。 Azure Firewall Manager ポリシーが、各リージョン間のファイアウォール規則を管理します。
コンテナー レジストリ: ワークロードのコンテナー イメージは、マネージド コンテナー レジストリに格納されます。 このソリューションでは、クラスター内のすべての Kubernetes インスタンスに対して 1 つの Azure Container Registry インスタンスが使用されます。 Azure Container Registry の geo レプリケーションにより、選択した Azure リージョンへのイメージのレプリケートが可能になり、リージョンで障害が発生した場合でも、イメージへの継続的なアクセスを提供します。
フェールオーバー プロセス
特定の Azure リージョンの問題が原因でパッシブ クラスターが正常に機能していない場合は、コールド クラスターをアクティブにして、すべてのトラフィックをそのクラスターのリージョンにリダイレクトできます。 パッシブ クラスターが非アクティブになっている間、再び動作し始めるまでは、このプロセスを使用できます。 コールド クラスターは、オフになっていて、セットアップ プロセスを完了する必要があるため、オンラインになるまでに数分かかる場合があります。 この方法は、一刻を争うアプリケーションには適していません。 その場合は、アクティブ/アクティブ フェールオーバーを検討することをお勧めします。
アプリケーション ポッド (リージョン)
Kubernetes デプロイ オブジェクトは、ポッド (ReplicaSet) の複数のレプリカを作成します。 使用できない場合は、残っているレプリカの間でトラフィックがルーティングされます。 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 では、クラスターでカオス実験を作成する機能が提供されます。
次のステップ
別のソリューションを検討する場合は、次の記事を参照してください。