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) を作成します。 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 では、クラスターでカオス実験を作成する機能が提供されます。
次のステップ
別のソリューションを検討する場合は、次の記事を参照してください。
Azure Kubernetes Service