次の方法で共有


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

次のステップ

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