Amazon Web Services ブログ

ゾーンシフトを用いたクロスゾーン負荷分散

2024 年 11 月 22 日より、クロスゾーン負荷分散を有効にした Application Load Balancer (ALB) の Amazon Application Recovery Controller (ARC) ゾーンシフトサポートを発表しました。これは、以前に発表されたクロスゾーン負荷分散を使用する Network Load Balancer (NLB) のサポートを補完するものです。ゾーンシフトは、クロスゾーン負荷分散が設定されているかどうかに関係なく、NLB と ALB の両方で使用できるようになりました。また、Amazon EC2 Auto Scaling グループ (ASG) や Amazon Elastic Kubernetes Service (EKS) などの他のリソースでもゾーンシフトを使用できます。ブログ記事「単一の アベイラビリティゾーンでのアプリケーション障害からの迅速な復旧」では、ゾーンシフトの仕組みと、クロスゾーン負荷分散が無効になっている場合の関連するベストプラクティスの概要が説明されています。この記事では、クロスゾーン負荷分散を有効にした状態でゾーンシフトを使用する場合の運用上のベストプラクティスを紹介します。

概要

ALB または NLB のゾーンシフトの使用を開始するには、ロードバランサーの zonal_shift.config.enabled 属性を true に設定する必要があります。クロスゾーン負荷分散を使用する NLB では、target_health_state.unhealthy.connection_termination.enabled が false に設定されていることも確認する必要があります。この機能を有効にすると、1 つのアベイラビリティーゾーン (AZ) で障害が発生していることが判明したときに、ゾーンシフトを開始して影響を軽減できます。

ゾーンシフトは、クロスゾーン負荷分散が有効になっている場合、2 つのアクションを実行します。はじめに、指定された AZ のロードバランサーノードの IP アドレスが DNS から削除されるので、新しいクエリがそのエンドポイントで解決されなくなります。これにより、今後クライアントリクエストがそのノードに送信されなくなります。次に、他の AZ のロードバランサーノードに、障害のある AZ のターゲットにリクエストをルーティングしないように指示します。図 1 に示すように、ゾーンシフト中も残りの AZ ではクロスゾーン負荷分散が引き続き使用されます。

A zonal shift is performed on AZ 1 which prevents targets there from receiving requests. Cross-zone load balancing is still utilized in the remaining AZs to route requests.

図 1 – AZ 1 でゾーンシフトが有効なクロスゾーン負荷分散を使用する Application Load Balancer

AZ 障害が発生している間は、ロードバランサーの背後にある ASG のゾーンシフトを実行することもできます。ゾーンシフト中に異常のあるインスタンスを置き換えるように ASG を設定した場合、障害のある AZ ではインスタンスが終了し、他の AZ では新しいインスタンスが起動されることがあります。また、EC2 Auto Scaling がゾーンシフト中にアプリケーションをスケールアウトし、影響を受けていない AZ で新しいインスタンスを起動する可能性もあります。これにより、AZ 間でキャパシティのバランスが崩れる可能性があります。

AZ 障害が復旧したと判断したら、シフトをキャンセルして AZ へのトラフィックをリバランスすることができます。クロスゾーン負荷分散は、ロードバランサーのゾーンシフトを終了するとターゲットごとに受信されるトラフィックの全体的な割合が減少するため、キャパシティが不均衡になった場合にリバランスをより安全に行うのに役立ちます。これは、図 2 に示すように、ロードバランサーがターゲットグループの各ターゲットにトラフィックを均等に分散するためです。

An Application Load Balancer with cross-zone load balancing enabled. This routes the same amount of traffic to each target.

図 2 – クロスゾーン負荷分散が有効化された Application Load Balancer

これとは対照的に、クロスゾーン負荷分散を無効した状態では、トラフィックが各 AZ に均等に分散されます。その後、ロードバランサーはそのゾーン内の利用可能なターゲットにリクエストを分散します。AZ 間のキャパシティの不均衡により、ロードバランサーのゾーンシフトを終了した後に、特定のインスタンスが他のインスタンスよりも多くの負荷を受ける可能性があります。これにより、過負荷が発生し、アプリケーションに影響が及ぶ可能性があります。たとえば、図 3 は AZ 2 のインスタンスが AZ 1 と AZ 3 のターゲットの約 2 倍のトラフィックを受信している様子を示しています。この構成では、target_group_health.dns_failover.minimum_healthy_targets.count を使用して、十分な数の正常なホストが利用できるようになるまで AZ がトラフィックを受け入れないようにすることが重要です。

An Application Load Balancer with cross-zone load balancing disabled. Because there is a capacity imbalance, the instance in AZ 2 receives twice as much traffic as the targets in AZ 1 and AZ 3.

図 3 – クロスゾーン負荷分散が無効化された Application Load Balancer

クロスゾーン負荷分散は、ALBではデフォルトで有効であり、NLBでもオプションで有効にできます。これにより、ALB ターゲットグループの構成を大幅に変更しなくても、ゾーンシフトを活用できます。ALB のゾーンオートシフトをデフォルト設定でオプトインすることもできます。AWS は、お客様に影響を与える可能性のある AZ 障害が社内のテレメトリで示されたときに、オートシフトを開始します。ゾーンオートシフトは、加重ランダムルーティングアルゴリズムと組み合わせて使用できます。これにより、イベント発生時の復旧時間を最小限に抑えることができ、ゾーンシフトの活用に必要な追加のオブザーバビリティが軽減されます。

単一 AZ の影響に対応するには、ゾーンオートシフトと自動ターゲットウェイト (ATW) の異常緩和が推奨されますが、これらのツールでは特定のインフラストラクチャにおけるグレー障害やシングル AZ アプリケーションの障害を検出できない場合があります。たとえば、ある特定の AZ にデプロイされたバグを含むアプリケーションデプロイや、少数のインスタンスに影響する少量のパケットロスによってアプリケーションエラーが発生し始めた場合などです。このような状況を検出するには、追加のオブザーバビリティを開発する必要があるかもしれません。次のセクションでは、クロスゾーン負荷分散を有効にして 単一AZ の障害を検出する方法を調べます。

クロスゾーン負荷分散を有効にしたゾーンシフトの AZ オブザーバビリティ

リクエスト数、障害率、AZ ごとのレイテンシーなどのメトリクスを監視することは、AZ で障害が発生している可能性があるタイミングを判断するための前提条件であり、潜在的な影響を安全に軽減することができます。次の 3 つのシグナルは、ゾーンシフトをいつ使用するかを判断するのに役立ちます。

  1. 可用性またはレイテンシーへの影響を示す AZ ヘルスメトリクス
  2. あるAZ が、他の AZ と比較して、障害率またはレイテンシの点で外れ値である
  3. 障害率または高レイテンシーが、複数のインスタンスで発生している

それでは、各 AZ におけるアプリケーションの状態に関するメトリクスの収集を開始する方法を見てみましょう。

AZヘルスメトリクスの作成

レジリエンスのためのオブザーバビリティのベストプラクティスの1つは、合成カナリアを使って顧客体験をモニタリングすることです。これらは早期警告の指標として機能するので、顧客に気づかれる前に問題を自分自身に知らせることができます。「単一アベイラビリティーゾーンでのアプリケーション障害からの迅速な復旧」の投稿では、図 4 に示すように、Amazon CloudWatch Synthetics を使用して ALB と NLB のゾーンエンドポイントをモニタリングし、AZ ごとのメトリクスを生成しました。

Amazon CloudWatch synthetic canaries testing the ALBs nodes in each AZ

図4 – 各 AZ の Application Load Balancer エンドポイントに対して実行される合成カナリア

クロスゾーン負荷分散を有効にした場合でも、シンセティックは引き続きベストプラクティスです。ただし、ALB や NLB について各ゾーンのエンドポイントをテストしても、どの AZ のターゲットからも応答が得られる可能性があるため、それほど有用ではありません。代わりに ALB の場合は、ALB ロードバランサーの Amazon CloudWatch メトリクスを使用して、特定の AZ のターゲットで障害率やレイテンシーが上昇しているタイミングを特定できます。ALB ターゲットメトリクスには、2XX、3XX、4XX、5XX のカウントと TargetResponseTime のメトリクスがあります。これらのメトリクスはすべて、レスポンスを生成したターゲットの AZ を表すメトリクスディメンションとして AvailabilityZone を備えています。

NLBの場合、ターゲットメトリクスはほとんどがレイヤー4の情報であるため、アプリケーションの状態の変化を判断するのがより難しい場合があります。TCP_Target_Reset_count メトリクスをアプリケーションの正常性の代用として監視することもできますが、それでもまだ不十分な場合があります。NLB またはそのターゲットグループでクロスゾーン負荷分散が有効になっている場合は、ターゲットの AZ をメトリクスディメンションとして提供するカスタムサーバーサイドメトリクスを利用する必要があります。これを実現する方法の詳細については、「カスタムメトリクスの公開」 と「CloudWatch 埋め込みメトリクス」を参照してください。

ロードバランサーの UnhealthyHostCount ターゲットメトリクスをモニタリングすることもできます。AZ 障害が原因でターゲットのヘルスチェックが不合格になった場合、これはその影響を直接示しています。このメトリクスに自動的に対応するには、NLB または ALB ターゲットグループの target_group_health.dns_failover.minimum_healthy_targets.count 属性を使用できます。これにより、正常なホストが少なすぎる場合に、ロードバランサーが AZ から自動的に移動するようになります。

ALB メトリクスまたはカスタムサーバーサイドメトリクスのいずれかを使用して、各 AZ の影響を警告する CloudWatch アラームを作成できます。この例では、クロスゾーン負荷分散を有効にした ALB メトリクスを使用しています。ターゲットからのレイテンシーが特定のしきい値を超えたとき、またはアベイラビリティが指定された値を下回ったときにアラームがトリガーされるように設定しています。

レイテンシーアラームは以下のメトリクスを利用します（図5）：

The ALB target response time metric is used to measure latency.

図5 – 目標応答時間メトリクスを使用して AZ ごとにレイテンシーアラームを定義する

また、可用性アラームはメトリクス計算を使用して AZ の障害率を決定します （図6）：

Using ALB HTTPCode_Target_5xx_Count and RequestCount metrics to determine the fault rate.

図6 – AZ ごとの可用性アラームを定義するためのロードバランサー障害率の決定

最後に、図 7 に示すように、単一の AZ における可用性またはレイテンシーの影響を特定するように CloudWatch 複合アラームを設定します。

A CloudWatch composite alarm looking at either fault rate impact or latency impact.

図7 – 障害率またはレイテンシーへの影響に関する CloudWatch 複合アラーム定義

次に、同じ ALB メトリクスを使用して各 AZ 間の障害率とレイテンシーを比較し、1 つの AZ がいつ外れ値になるかを調べます。

外れ値検出の実行

あるAZ がヘルスメトリクスの外れ値である場合は、その障害分離境界に問題があることを示す良い指標になります。カイ二乗検定や、標準得点、四分位範囲 (IQR)、中央絶対偏差 (MAD) など、さまざまな外れ値検出アルゴリズムを使用してヘルスメトリクスを比較できます。もっと簡単に始めるには、66% のような静的な値を使用する方法があります。つまり、ある AZ が全故障の 66% を占めていれば、それは外れ値とみなされます。

図 8 は、メトリクス計算を使用して計算された CloudWatch メトリクス e1 を示しています。これにより、単一の AZ (この場合は us-east-1b) 全体の障害の割合が決定されます。このメトリクス値が 0.66 より大きい場合にアラームを設定できます。

Determing an single AZ's percentage of the overall fault rate with CloudWatch metrics.

図8 – ある AZ に属する障害の割合を決定する外れ値検出用メトリクスの作成

レイテンシーについては、データポイントにおける標準偏差を決定するために標準得点を使用します。正規分布データの 99.7% は標準偏差が3以内であるため、値が3を超えると値が外れ値であることを示します。この計算では p99 のレイテンシーを調べ、この AZ と比較している他の 2 つの AZ の平均値を使用して ( Metrics () 関数を使用 )、外れ値のレイテンシーが標準偏差を歪めないようにしています。図 9 は CloudWatch メトリクスの計算を使用した計算を示しています。このメトリクスが 3 を超えた場合のアラームを設定できます。

Calculating the z-score for a single AZ using TargetResponseTime metrics.

図9 – あるAZ におけるレイテンシーの標準得点を用いた外れ値検出

複数インスタンスによる影響の特定

ターゲットがヘルスチェックに失敗した場合、UnhealthyHostCount ターゲットメトリクスは、影響が複数のインスタンスによって引き起こされているかどうかを確認するのに役立ちます。構造化された CloudWatch ログを作成している場合は、CloudWatch Contributor Insights を使用することもできます。このサービスは、インサイトルールの UniqueContributors メトリクスを使って、アプリケーションの障害やレイテンシーの原因となった要因を特定するのに役立ちます。図 10 は、Contributor Insights メトリクスの計算を使用した CloudWatch メトリクスの例を示しています。

A CloudWatch Contributor Insights metric math rule to determine how many instances are producing faults in a single AZ.

図10 – あるAZ における障害の要因の数を算出するためのContributor Insights を使用した CloudWatch メトリクス

このメトリクスに値が 1 を超えた場合のアラームを設定して（フリートのサイズによってはもっと大きい数値を使用することもできます）、複数のインスタンスでエラーが発生していることを示すアラームを設定できます。

すべてをまとめる

これで、単一 AZ の影響の特定に役立つ 3 つの条件のアラームが表示されるようになりました。

  1. 特定の AZ における可用性またはレイテンシーの影響
  2. 特定の AZ が障害やレイテンシーにおいて外れ値となっている
  3. 複数のインスタンスで問題が発生している

最後の CloudWatch 複合アラーム ( 図 11 参照 ) では、これらの各アラームからの信号を組み合わせて、ゾーンシフトを使用して対応できる単一AZ の影響が発生したことを通知します。

A CloudWatch composite alarm that ensures there is latency or availabiltiy impact in the AZ, the AZ is an outlier for latency or faults, and multiple instances are seeing impact in that AZ.

図11 – 単一 AZ の影響を決定するための CloudWatch 複合アラームの定義

これらのAZごとのアラームをダッシュボードに追加して、運用担当者が単一 AZ の障害をすばやく特定できるようにすることもできます（図12）。

A CloudWatch dashboard showing 2xx count per AZ, fault rate per AZ, 5xx count per AZ, and target response time at p99 per AZ.

図12 – あるAZ で問題が検知されたことを示す CloudWatch ダッシュボード

結論

この投稿では、クロスゾーン負荷分散を有効にした状態でゾーンシフトがどのように機能するかを確認しました。また、単一の AZ でアプリケーションの状態への影響を監視するための運用上のベストプラクティスについても紹介しました。ゾーンシフトまたはゾーンオートシフトを開始するには、Amazon Application Recovery Controller のドキュメントをご覧ください。

著者について

Michael Haken

Michael Haken

Michael は AWS Strategic Accounts チームのシニアプリンシパルソリューションアーキテクトであり、お客様のイノベーション、ビジネスの差別化、カスタマーエクスペリエンスの変革を支援しています。15 年以上にわたり、金融サービス、公共部門、デジタルネイティブの顧客をサポートしてきました。Michael はバージニア大学 (UVA) で学士号を、ジョンズ・ホプキンス大学でコンピューターサイエンスの修士号を取得しています。仕事以外では、彼は農場で家族や犬と遊んでいます。

翻訳はソリューションアーキテクトの松本が担当しました。原文はこちらです。