Azure Application Gateway for Containers の信頼性

Azure Application Gateway for Containers は、Kubernetes で実行されているワークロード用のマネージド アプリケーション レイヤー (レイヤー 7) の負荷分散と動的トラフィック管理サービスです。 受信要求はクラスター内のバックエンド ターゲットにルーティングされます。

Azureを使用する場合、信頼性は共有責任です。 Microsoftには、回復性と回復性をサポートするためのさまざまな機能が用意されています。 使用するすべてのサービスでこれらの機能がどのように機能するかを理解し、ビジネス目標とアップタイムの目標を達成するために必要な機能を選択する必要があります。

この記事では、Azure Application Gateway for Containers が一時的な障害、可用性ゾーンの障害、リージョン全体の障害、およびサービス メンテナンスを処理する方法について説明します。 また、バックアップと復元のオプションと、サービス レベル アグリーメント (SLA) に関する重要な情報についても説明します。

信頼性のための運用環境のデプロイに関する推奨事項

Application Gateway for Containers は既定で高可用性です。 運用環境のワークロードの場合:

トポロジ、トラフィック フロー、信頼性、セキュリティ、および運用に関するアーキテクチャとガイダンスの例については、「Azure Kubernetes Service に Application Gateway for Containers をデプロイする」を参照してください。

信頼性アーキテクチャの概要

このセクションでは、信頼性の観点から最も関連性の高いサービスのしくみの重要な側面について説明します。 このセクションでは、デプロイして使用するリソースと機能の一部を含む論理アーキテクチャについて説明します。 また、物理アーキテクチャについても説明します。このアーキテクチャでは、サービスの内部での動作について詳しく説明します。

論理アーキテクチャ

Application Gateway for Containers のデプロイには、Azure と Kubernetes クラスターの両方にあるリソースが含まれます。

• Azure リソース:コントロール プレーンは、構成に基づいてゲートウェイのプロキシ構成を調整します。 Azureマネージド データ プレーンは、クラスターの外部で実行され、アプリケーション トラフィックを処理します。
• Kubernetes リソース: ルーティングやその他の構成は、Kubernetes リソースを使用して定義します。 ALB コントローラーはクラスターで実行され、それらのリソースを監視し、Azure の Application Gateway for Containers に構成を反映します。

2 つの デプロイ戦略から選択できます。 Bring Your Own (BYO) 戦略では、Application Gateway for Containers、関連付け、フロントエンド リソースのライフサイクルを、Azure ツールを使用して管理します。 ALB コントローラーによって管理される戦略では、ALB コントローラーは、定義した Kubernetes リソースに基づいて、それらのAzureリソースのライフサイクルを管理します。

コンポーネントの詳細については、「 Application Gateway for Containers コンポーネント」を参照してください。

Application Gateway for Containers をデプロイして構成すると、受信要求が バックエンド ターゲットにルーティングされます。バックエンド ターゲットは、Kubernetes 内で実行されているアプリケーションを表します。

ALB コントローラーまたはコントロール プレーンが使用できない場合、データ プレーンは最後に正常に適用された構成を使用してトラフィックを処理し続けます。 障害発生中、構成の更新は反映されず、サービスはスケールアウト イベントに必要な構成をプログラムできません。

物理アーキテクチャ

Azureは、アプリケーション トラフィックに基づいてデータ プレーン インフラストラクチャを管理し、自動的にスケーリングします。 Application Gateway for Containers は、常に高可用性構成でデプロイされます。可用性ゾーンをサポートするリージョンでは、ゲートウェイはゾーン冗長です。可用性ゾーンをサポートしていないリージョンでは、Azureは可用性セットを使用します。

一時的な障害に対する回復性

一時的な障害は、コンポーネントにおける短い断続的な障害です。 これらはクラウドのような分散環境で頻繁に発生し、運用の通常の範囲であり、 一時的な障害は、短時間の経過後に自分自身を修正します。 アプリケーションで一時的な障害を処理できることは重要です。通常は、影響を受ける要求を再試行します。

クラウドでホストされるすべてのアプリケーションは、クラウドでホストされている API、データベース、およびその他のコンポーネントと通信する際に、Azure の一時的な障害処理のガイダンスに従う必要があります。 詳細については、一時的なエラーへの対処に関するレコメンデーションを参照してください。

Application Gateway for Containers を使用する場合は、次のベスト プラクティスを検討してください。

• 再試行ロジックを実装します。 一時的な接続エラーの後に要求を再試行するようにクライアントを構成します。

• 許容値を設定した正常性プローブを構成します。 カスタム正常性プローブを構成する場合は、一時的な障害を許容するように 異常判定しきい値 を設定します。 異常しきい値は、バックエンド ターゲットが異常とマークされるきっかけとなる、連続して失敗したプローブの数を指定します。 既定の正常性プローブでは、3 回で異常と判定するしきい値が使用されます。これは、単一の一時的なプローブ障害がバックエンドを異常とマークするのを防ぐのに役立ちます。

可用性ゾーンの障害に対する回復性

可用性ゾーン は、Azure リージョン内のデータセンターの物理的に分離されたグループです。 1 つのゾーンで障害が発生した際には、サービスを残りのゾーンのいずれかにフェールオーバーできます。

可用性ゾーンをサポートする Azure リージョンに Application Gateway for Containers をデプロイすると、Microsoftは、コントロール プレーンとデータ プレーンを複数のゾーンにわたってゾーン冗長として自動的に構成します。 サービスが使用するゾーンをどれにするかは選択できません。

Requirements

リージョンのサポート: ゾーンの冗長性を使用するには、Application Gateway for Containers と可用性ゾーンの両方をサポートするリージョンを選択します。 Application Gateway for Containers で利用可能なリージョンを確認し、可用性ゾーンをサポートするリージョンの一覧と比較します。

Considerations

Kubernetes プラットフォームとの共同責任: Microsoft は、ゾーン障害時の Application Gateway for Containers のトラフィック リダイレクトを管理します。 Azure Kubernetes Service (AKS)の場合、Microsoftは Kubernetes コントロール プレーンを管理します。 クラスターのノード プールと、管理する他のリソース、およびゾーン停止中のアプリケーションの動作に対して、ゾーンの回復性を構成する責任があります。

• クラスター: 管理する AKS ノード プールとその他のゾーン バインド クラスター リソースが可用性ゾーンにまたがるように構成します。 AKS はコントロール プレーンを管理します。 AKS ノード プールの可用性ゾーンの構成に関するページを参照してください。

• ワークロード: 複数のポッド レプリカのデプロイ、それらの複数ゾーンへの分散、そしてゾーン障害時にトラフィックを処理するための正常なバックエンド ワークロードの可用性確保を担当します。 可用性ゾーンにまたがるノード プール、トポロジ分散制約、ポッドのアンチアフィニティを使用できます。

• Kubernetes 構成オブジェクト: Application Gateway for Containers では、クラスター API に保存される Kubernetes 構成オブジェクトが使用されます。 それらの可用性は、Kubernetes コントロール プレーンとクラスターで管理する構成によって異なります。

• ALB コントローラー: 構成を調整するには、Kubernetes クラスターに ALB コントローラーをデプロイします。 これは、Application Gateway for Containers データ パスの一部ではありません。

  ALB コントローラーは 2 つのレプリカを実行し、1 つはリーダーとして機能し、もう 1 つはセカンダリとして機能します。 リーダーが使用できなくなった場合、セカンダリがリーダーになり、構成の伝達を続けることができます。 クラスターがそれらをどのようにスケジュールするかに応じて、両方のレプリカが同じ可用性ゾーンで実行される場合があります。 ゾーン冗長性のためにクラスターとコントローラー ポッドを構成する必要があります。 ポッド トポロジの分散制約またはポッドのアンチアフィニティを使用して、レプリカをゾーン間で分散します。 詳細については、AKS ノード プールの可用性ゾーンを構成するを参照してください。

Cost

Application Gateway for Containers の可用性ゾーンのサポートでは、標準のサービス価格を超える追加料金は発生しません。 価格の詳細については、Azure Application Gateway価格に関するページを参照してください。

可用性ゾーンのサポートを設定する

サポートされているリージョンに新しいゲートウェイをデプロイすると、既定ではゾーン冗長になります。 Azure リソースでゾーン冗長を有効にする必要はありません。

ゾーンの回復性のために Kubernetes クラスター、ALB コントローラー、バックエンド ワークロードを構成する必要があります。

すべてのゾーンが正常な場合の動作

このセクションでは、可用性ゾーンをサポートするリージョンに Application Gateway for Containers をデプロイし、サービスで使用されるすべてのゾーンが動作する場合に想定される内容について説明します。

• ゾーンをまたいだ動作:Azure マネージド Application Gateway for Containers データ プレーンは、受信要求を複数のゾーンにまたがるインフラストラクチャ全体に分散します。

  バックエンド ワークロードをゾーン間で実行するように構成し、そのトラフィックを受信するための正常なターゲットを提供する責任があります。

• ゾーン間データ レプリケーション: Application Gateway for Containers では、アプリケーション データは格納されません。 プラットフォームは、ゾーン冗長コントロール プレーンを介して構成状態を管理し、耐久性と回復力を提供します。

ゾーン障害時の動作

このセクションでは、可用性ゾーンをサポートするリージョンに Application Gateway for Containers をデプロイし、サービスで使用されるゾーンの 1 つが停止した場合に想定される内容について説明します。

• 検出と応答: Application Gateway for Containers は、ゾーンの停止中に、残りの正常なゾーンのインフラストラクチャにトラフィックをリダイレクトします。 ゲートウェイのトラフィック再配布に対してアクションを実行する必要はありません。

  ただし、Kubernetes クラスターとバックエンド アプリケーションに障害が及ぼす影響については、ユーザーが責任を負います。

• 通知： ゾーンがダウンしても、Microsoft から自動的に通知されることはありません。 ただし、Azure Service Health を使用して、ゾーン障害を含むサービスの全体的な正常性を把握し、Service Health アラートを設定して問題を通知することができます。

• アクティブな要求: 障害が発生したゾーンへの既存の接続は切断されます。 クライアントは、 一時的な障害に対する回復性に関するガイダンスに従って要求を再試行する必要があります。 残りの正常なゾーンのインフラストラクチャへの新しい接続が確立されます。

• 予想されるデータ損失: Application Gateway for Containers では、アプリケーション データは格納されません。 プラットフォームは、ゾーン冗長コントロール プレーンを介して構成状態を管理し、永続性と回復性を提供します。

• 予想されるダウンタイム: 障害が発生したゾーンへの接続が切断されると、クライアントで短時間の中断が発生する可能性があります。 クライアントは要求を再試行して、残りの正常なゾーンのインフラストラクチャへの新しい接続を確立する必要があります。

  Azureマネージド コントロール プレーンは、単一ゾーンの停止中も引き続き使用できます。 ただし、構成更新プログラムを適用できるかどうかは、Kubernetes コントロール プレーンと ALB コントローラーの可用性によっても異なります。

• 再配布: Application Gateway for Containers は、残りの正常なゾーンのインフラストラクチャにトラフィックをリダイレクトします。

ゾーンの回復

Application Gateway for Containers は、基盤側の問題から自動的に回復します。 Azureは、ゲートウェイ インフラストラクチャの復旧を管理します。

ゾーンエラーのテスト

Application Gateway for Containers プラットフォームは、トラフィック ルーティングと、ゲートウェイ自体のゾーン障害への応答を管理します。 ゲートウェイの応答を開始または管理する必要はありません。 管理する Kubernetes クラスターがある場合は、Azure Chaos Studioを使用して、ゾーン障害に対するクラスターの応答をテストできます。 詳細については、「可用性ゾーンの耐障害性をテストする」を参照してください。

リージョン全体の障害に対する回復性

Application Gateway for Containers は、単一リージョンのサービスです。 ゲートウェイをデプロイしたAzureリージョンが使用できなくなった場合、そのゲートウェイは使用できなくなります。

回復性のためのカスタム マルチリージョン ソリューション

Application Gateway for Containers には、組み込みのマルチリージョンデプロイまたはフェールオーバー ソリューションは用意されていません。 リージョン障害に備えて設計するには、リージョンごとに個別のゲートウェイと Kubernetes クラスターをデプロイして構成します。 リージョン ゲートウェイ間のトラフィックをルーティングし、フェールオーバーを構成する責任があります。

• リージョン間で一貫して Application Gateway for Containers を構成します。 デプロイを簡略化し、構成の整合性を維持するために、Bicep や Terraform などのツールを使用して、インフラストラクチャをコード (IaC) として定義します。

• Azure Front DoorやAzure Traffic Managerなどのグローバル トラフィック管理サービスを選択して構成し、クライアントをリージョン ゲートウェイにルーティングします。 これらのサービスでは、さまざまなルーティング モデルと正常性プローブ構成が使用されます。 使用できないゲートウェイをトラフィックが迂回するように選択したサービスを構成し、そのドキュメントを確認してルーティング動作とフェールオーバーに関する考慮事項を理解します。 Azure Front Doorには、分散型サービス拒否 (DDoS) 保護、Web アプリケーション ファイアウォール (WAF) 機能、ルールベースのルーティングなどの機能も用意されています。

• バックエンド アプリケーションを各リージョンにデプロイし、障害発生時に正常なワークロードを提供するように構成します。 アプリケーションがデータやその他の Azure サービスに依存している場合は、それらのサービスもマルチリージョンの可用性に対応できるように設計および構成してください。 各サービスの信頼性ガイダンスを確認して、マルチリージョンのオプションと制限事項を理解してください。

バックアップと復元

Application Gateway for Containers では、アプリケーション データは格納されません。 Azure Resource Managerは、ゲートウェイのAzure リソース構成を格納します。 これらのリソースは、構成を再デプロイすることで再作成できます。

ゲートウェイのデプロイ方法とトラフィックのルーティング方法を定義する構成と Kubernetes リソースを保持する責任があります。

• Bicepや Terraform などのコードとしてのインフラストラクチャ (IaC) でAzureリソースとその設定を定義し、定義をバージョン管理に保持します。 これらを使用して、ゲートウェイ リソースを再デプロイできます。

• ApplicationLoadBalancer、Gateway、HTTPRoute リソースなど、ゲートウェイを構成する Kubernetes リソースをバックアップします。 ルーティング構成を再作成する必要がある場合は、それらをクラスターに復元します。

• カスタム規則や Web アプリケーション ファイアウォール ポリシーなど、関連する構成をバージョン管理または標準の構成バックアップ プロセスを通じて保持します。 デプロイ パイプラインを使用して、Azureと Kubernetes リソースを一貫して再作成できます。

サービス メンテナンスに対する回復性

Microsoftは、サービスの高可用性を維持しながら、Application Gateway for Containers のメンテナンスを管理します。

各関連付けに必要な /24 の最小サブネット サイズには、メンテナンス期間が考慮されています。そのため、メンテナンス用に追加のサブネット IP アドレス空間を割り当てる必要はありません。

詳細については、「 Application Gateway for Containers のスケーリングと可用性」を参照してください。

サービス水準合意書

Azure サービスのサービス レベル アグリーメント (SLA) では、各サービスの予想される可用性と、その可用性の期待を達成するためにソリューションが満たす必要がある条件について説明します。 詳細については、オンラインサービスのSLAを参照してください。

Application Gateway for Containers SLA は、コントロール プレーンとデータ プレーンを個別に測定します。 両方のプランが全体的な SLA 計算に組み込まれます。

関連するコンテンツ

• Azure Kubernetes Service に Application Gateway for Containers をデプロイする
• Azure での信頼性