次の方法で共有

Azure Kubernetes Service (AKS) の高可用性とディザスター リカバリーの概要

  • [アーティクル]

クラウドでアプリケーションを作成および管理する場合、機能停止や災害による中断のリスクが常に伴います。 ビジネス継続性 (BC) を確保するには、高可用性 (HA) とディザスター リカバリー (DR) を計画する必要があります。

HA は、信頼性が高く、ダウンタイムを最小限に抑えるシステムまたはサービスの設計と実装を指します。 HA は、目的の機能をシステムまたはサービスが確実に実行できるようにするツール、テクノロジー、プロセスの組み合わせです。 HA は、DR 計画の重要なコンポーネントです。 DR は、障害から復旧し、事業運営を通常の状態に復元するプロセスです。 DR は、BC (大規模な中断が発生した場合にビジネス機能を維持する、または即座に再開するプロセス) のサブセットです。

この記事では、AKS にデプロイされるアプリケーションについて推奨されるプラクティスをいくつか取り上げますが、考えられるソリューションの完全な一覧を意味するものではありません。

テクノロジの概要

Kubernetes クラスターは、次の 2 つのコンポーネントに分割されています。

  • コントロール プレーン。中心的な Kubernetes サービスと、アプリケーションのオーケストレーションを提供します。
  • ノード。アプリケーション ワークロードを実行します。

Kubernetes のコントロール プレーンとノードのコンポーネントの図。

AKS クラスターを作成すると、Azure プラットフォームによってコントロール プレーンが自動的に作成されて構成されます。 AKS には、クラスター管理用に Free レベルと Standard レベルの 2 つの価格レベルが用意されています。 詳しくは、AKS クラスター管理での Free と Standard の価格レベルに関する記事をご覧ください。

コントロール プレーンとそのリソースは、クラスターを作成したリージョンにのみ存在します。 AKS は、専用の API サーバーやスケジューラなどを備えたシングル テナント コントロール プレーンを提供します。ノードの数とサイズを定義すると、Azure プラットフォームによって、コントロール プレーンとノードの間のセキュリティで保護された通信が構成されます。 コントロール プレーンとの対話は、kubectl や Kubernetes ダッシュボードなどの Kubernetes API を介して行われます。

アプリケーションとサポート対象のサービスを実行するには、Kubernetes のノードが必要です。 AKS クラスターには少なくとも 1 つのノードがあり、これは Kubernetes ノードのコンポーネントとコンテナー ランタイムを実行する Azure Vrtual Machine (VM) となります。 ノードの Azure VM サイズでは、CPU、メモリ、サイズ、使用可能なストレージの種類 (高性能の SSD や通常の HDD など) を定義します。 アプリケーションで大容量の CPU やメモリ、または高性能ストレージが必要かどうかに応じて VM とストレージのサイズを計画します。 AKS では、クラスターのノードの VM イメージは、Ubuntu Linux、Azure Linux、または Windows Server 2022 に基づいています。 AKS クラスターを作成したり、ノード数をスケールアウトしたりすると、Azure プラットフォームによって、要求された数の VM が作成され構成されます。

AKS のクラスターおよびワークロード コンポーネントの詳細については、AKS での Kubernetes の中心的な概念に関するページを参照してください。

重要な考慮事項

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

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

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

復旧目標

完全なディザスター リカバリー計画では、アプリケーションに実装される各プロセスのビジネス要件を指定する必要があります。

  • 回復ポイントの目標 (RPO)は、データ損失が許容される最大継続時間です。 RPO は、分、時間、日などの時間単位で測定されます。
  • 目標復旧時間 (RTO) は、ダウンタイムが許容される最大継続時間です。"ダウンタイム" は仕様によって定義されます。 たとえば、障害発生時に許容されるダウンタイムの期間が "8 時間" の場合、RTO は 8 時間です。

可用性ゾーン

可用性ゾーンを使用すると、同じリージョン内の複数のゾーン間でデータを分散できます。 リージョン内では、可用性ゾーンは、他の可用性ゾーンへの待機時間の短い接続を行えるほど十分に近接していますが、複数の可用性ゾーンがローカルな停止や気象の影響を受ける可能性を減らせるほど十分に離れています。 詳細については、「可用性ゾーンとリージョンを使用するための推奨事項」を参照してください。

ゾーンの回復性

AKS クラスターは、ゾーン障害に対する回復性があります。 ゾーンで障害が発生した場合、クラスターは残りのゾーンで引き続き実行されます。 クラスターのコントロール プレーンとノードはゾーン間で分散され、ノードの分散は Azure プラットフォームによって自動的に処理されます。 詳細については、AKS ゾーンの回復性に関する記事を参照してください。

負荷分散

グローバル負荷分散

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

リージョン負荷分散

リージョン負荷分散サービスは、仮想ネットワーク内のトラフィックを、リージョン内の仮想マシン (VM) 間、またはゾーンおよびゾーン冗長のサービス エンドポイント間で分散します。 リージョン負荷分散を提供する Azure サービスは、次のとおりです。

可観測性

効果的な運用を可能にし、信頼性を最大化するには、アプリケーションとインフラストラクチャからデータを収集する必要があります。 Azure には、AKS ワークロードの監視と管理に役立つツールが用意されています。 詳細については、「監視リソース」を参照してください。

スコープ定義

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

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

デプロイ モデルの実装

デプロイメント モデル 長所 デメリット
アクティブ/アクティブ • フェールオーバー中にデータの損失または不整合が発生しない
• 高い回復性
• パフォーマンスが高いリソースの使用率の向上		 • 複雑な実装と管理
• 高コスト
• 負荷分散とトラフィック ルーティングの形成が必要
アクティブ/パッシブ • 実装と管理の簡略化
• 低コスト
• 負荷分散とトラフィック マネージャーが不要		 • フェールオーバー中にデータの損失または不整合が発生する可能性がある
• 復旧時間とダウンタイムの増加
• リソースの過小使用
パッシブ/コールド • 最低コスト
• 同期、レプリケーション、負荷分散、またはトラフィック マネージャーが不要
• 優先順位が低く重要ではないワークロードに適している		 • フェールオーバー中にデータの損失または不整合が発生するリスクが高い
• 復旧時間とダウンタイムが最長
• クラスターをアクティブ化し、バックアップをトリガーするには、手動による介入が必要

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

アクティブ/アクティブの高可用性 (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 には、特定の VM SKU に関する使用制限など、リソースと機能に対して既定の制限とクォータが設定されています。

リソース 制限
グローバルで見たサブスクリプションあたりの最大クラスター数 5,000
1 リージョン 1 サブスクリプションあたりの最大クラスター数 1 100
Virtual Machine Scale Sets と Standard Load Balancer SKU を使用したクラスターあたりの最大ノード数 5000 (すべてのノード プール対象)
注: クラスターあたり最大 5000 ノードまでスケールアップできない場合は、大規模なクラスターのベスト プラクティスを参照してください。
ノード プールあたりの最大ノード数 (Virtual Machine Scale Sets ノード プール) 1000
クラスターあたりの最大ノード プール数 100
ノードあたりの最大ポッド数: Kubenet ネットワーキング プラグインを使用した場合1 最大値: 250
Azure CLI の既定値: 110
Azure Resource Manager テンプレートの既定値: 110
Azure portal デプロイの既定値: 30
ノードあたりの最大ポッド数: Azure Container Networking Interface (Azure CNI) を使用した場合2 最大値: 250
Windows Server コンテナーに推奨される最大値: 110
既定値: 30
Open Service Mesh (OSM) AKS アドオン Kubernetes クラスターのバージョン: AKS でサポートされているバージョン
クラスターあたりの OSM コントローラー数: 1
OSM コントローラーあたりのポッド数: 1600
OSM によって管理される Kubernetes サービス アカウント数: 160
Standard Load Balancer SKU を使用したクラスターあたりの最大負荷分散 kubernetes サービス数 300
仮想マシン可用性セットと Basic Load Balancer SKU を使用したクラスターあたりの最大ノード 100

1 要求に応じて追加できます。
2 Windows Server コンテナーでは Azure CNI ネットワーク プラグインを使用する必要があります。 Kubenet は Windows Server コンテナーではサポートされていません。

Kubernetes コントロール プレーンのサービス レベル 制限
Standard レベル 負荷に基づいて Kubernetes API サーバーを自動的にスケーリングします。 より大きなコントロール プレーン コンポーネントの制限と API サーバー/etcd インスタンス。
Free レベル 50 件の変更と 100 件の読み取り専用の呼び出しという配信要求制限付きの制限されたリソース。 クラスターあたり 10 個のノードという推奨ノード制限。 実験、学習、簡単なテストに最適です。 運用環境や重要なワークロードにはお勧めしません。

詳細については、AKS サービスのクォータと制限に関する記事を参照してください。

バックアップ

Azure Backup では、バックアップ拡張機能を使用して、AKS クラスター リソースと、クラスターにアタッチされた永続ボリュームのバックアップがサポートされています。 Backup コンテナーは、拡張機能を介して AKS クラスターと通信して、バックアップと復元の操作を実行します。

詳細については、次の記事をご覧ください。