Amazon Web Services ブログ
Amazon EC2 Auto Scaling でゾーンシフトが使用可能に
2024 年 11 月 18日、Amazon EC2 Auto Scaling でゾーンシフトのサポートを発表しました。ゾーンシフトを使用すると、Auto Scaling Group (ASG) リソースに影響を与える単一のアベイラビリティーゾーン (AZ) でのアプリケーション障害から迅速に回復できます。この記事では、ASG ゾーンシフトがマルチ AZ のレジリエンス戦略にどのように適合するか、および異なるアーキテクチャでこの機能を使用する際の考慮事項について説明します。
概要
AWS で複数の AZ を使用することは、耐障害性のあるアプリケーションを構築するためのアーキテクチャのベストプラクティスです。アプリケーションを複数の AZ にデプロイすることで、可用性、耐障害性、およびスケーラビリティが向上します。EC2 Auto Scaling を使用すると、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを複数の AZ で動的にスケーリングし、不健全な場合は置き換えることで、アプリケーションの可用性と耐障害性をさらに向上させることができます。
AWS の AZ は 障害分離境界を表しており、これは不適切なデプロイメント、ネットワークの問題、電源喪失、またはオペレーターのエラーなど、様々な原因による障害が単一のAZに封じ込められることを意味します。2023 年に、Amazon Application Recovery Controller (ARC) の一部として、Elastic Load Balancing (ELB) ロードバランサーでトラフィックをシフトすることで、単一 AZ のアプリケーション障害から迅速に回復できるゾーンシフトを開始しました。
EC2 Auto Scaling のゾーンシフトは、単一 AZ 障害に対する回復パターンをすでに実装しているユーザー向けに、この機能を強化します。また、指定した AZ での新規インスタンスの起動を防止することで、ロードバランシングされていないアーキテクチャに対しても回復機能を提供します。ゾーンシフトがない場合、EC2 Auto Scaling は、AZ で一貫した起動失敗を検出すると、ASG に設定された他の AZ でインスタンスを起動しようとします。ただし、グレー障害のような特定の状況では、EC2 Auto Scaling が検出しない単一 AZ での起動後の問題を引き起こす可能性があります。
例えば、単一 AZ で正常に起動されたインスタンスが、Amazon S3、Amazon Virtual Private Cloud (Amazon VPC)インターフェースエンドポイントを介して設定ファイルをダウンロードする際に、エラー率が上昇する場合があります。インスタンスはアプリケーションソフトウェアを正しく設定できず、エラーを含むレスポンスを返します。あるいは、単一 AZ 障害によってプロビジョニング後のヘルスチェックに失敗する可能性があります。これにより、EC2 Auto Scaling は障害が発生した AZ でインスタンスを絶えず再作成することになり、アプリケーションは希望する容量よりも少ない状態で実行されることになります。
イベントによる影響を軽減するためにロードバランサーでゾーンシフトを実行することを選択できますが、影響を受けた AZ で新しいインスタンスが引き続き起動され、リクエストを受信しません。アプリケーションアーキテクチャがロードバランサーを使用していない場合でも、EC2 Auto Scaling のゾーンシフトを使用することで、障害が発生したAZでのインスタンス起動を防止することで、単一AZ障害から回復できます。
EC2 Auto Scalingのゾーンシフトを使用した回復
ASG でゾーンシフトを使用するには、新しい ASG を作成する際か、既存の ASG を更新する際に、AvailabilityZoneImpairmentPolicy パラメータを設定する必要があります。このパラメータには2つのオプションがあります。ゾーンシフトの実行能力を有効または無効にするZonalShiftEnabledと、ImpairedZoneHealthCheckBehaviourです。後者のオプションでは、EC2 Auto Scaling によって不健全と識別されたインスタンスを無視するか置換するかを選択できます。まず、スタンドアロン ASG アーキテクチャでゾーンシフトをどのように使用できるかを見てみましょう。
スタンドアロン ASG のゾーンシフト
このアーキテクチャは、ELBロードバランサーと統合されていないスタンドアロン ASG を使用します。スタンドアロン ASG を持つワークロードは、通常、スケジュールに基づいてターゲットに対して負荷を生成したり、キューからメッセージを処理したりするイベント駆動の作業を実行します。以下の図のアーキテクチャでは、Amazon Simple Queue Service (Amazon SQS) キューからメッセージを読み取り、メッセージデータに対して処理を実行し、結果を Amazon Aurora データベースに書き込む ASG を使用しています。インスタンスは各 AZ の VPC エンドポイントを使用してAmazon SQS と通信します。メッセージのサイズは様々であるため、インスタンスは処理が完了するまでメッセージの可視性タイムアウトを更新するハートビートパターンを使用します。EC2 Auto Scaling は、キューの深さに基づいてインスタンスをスケーリングし、メッセージが適時に処理されることを確実にします。
図1 : 3つのAZにデプロイされ、SQSキューからメッセージを処理するEC2インスタンス
ネットワークの劣化によって AZ 1 のインスタンスが Aurora データベースへの書き込み時に高いエラー率を経験し、その結果 p50 処理レイテンシーが2倍に増加するというシナリオを考えてみましょう。AZ 1 のインスタンスは、タイムアウトするまでハートビートを続け、メッセージを非表示のままにして、他の正常なインスタンスが作業を引き継ぐことを妨げています。その結果、キューの深さが増加し、EC2 Auto Scalingは以下の図に示すように新しいインスタンスをデプロイします。
図2 : キューの深さの増加に応じてAZ 1に新しいインスタンスを起動するEC2 Auto Scaling
新しいインスタンスは AZ 1 に配置され、他のインスタンスと同じ問題を経験するため、キューの深さと処理レイテンシーを減少させることができません。代わりに、正常に処理されなかったメッセージをさらに consume することで問題を悪化させます。AZ 1 のインスタンスは Unhealthy として認識されなかったため、EC2 Auto Scaling はそれらを置き換えるアクションを取りませんでした。この問題を緩和するために、ASG のゾーンシフトを開始できます。これにより、今後のインスタンス起動は AZ 2 または AZ 3 でのみ行われるようになります。
図 3 : ゾーンシフト後、新しいインスタンスは AZ 2と AZ 3 でのみ EC2 Auto Scaling によって起動される
SetInstanceHealth API を使用してインスタンスを不健全とマークする選択肢もあります。これにより EC2 Auto Scaling はこれらのインスタンスを置き換え、追加のレイテンシーとエラーの原因となることを防ぎます。インスタンスのヘルス状態の変更は、更新を伴う操作とみなされ、EC2 Auto Scaling のコントロールプレーンに依存します。そのため、これを回復計画の重要なステップとすることは避けるべきです。障害が収まったと確信できたら、ゾーンシフトをキャンセルでき、EC2 Auto Scaling は自動的に AZ 全体で容量を再バランスします。
ELB を使用する ASG のゾーンシフト
このセクションでは、ELBからトラフィックを受けるASGでゾーンシフトを使用する方法を観察します。また、ImpairedZoneHealthCheckBehavior がこの状況での回復にどのように影響するかを検討します。このアーキテクチャでは、ASG 内のインスタンスは ELB から HTTP リクエストを受信したときにデータベースからデータを読み取ります。
図4 : ALB、ASG、およびAuroraデータベースを使用して3つのAZにデプロイされた3層アプリケーション
このシナリオでは、AZ 1 のインスタンスが EBS ボリュームとの間で増加したレイテンシーを経験し始め、リクエストにエラーで応答し、EC2 インスタンスステータスチェックに失敗します。最初に影響を緩和するために、ロードバランサーでゾーンシフトを開始してユーザーがエラーを受信することを防ぐことができます。その後、トラフィックを受信していない AZ に新しい容量が起動されることを防ぐために、ASG のゾーンシフトを開始できます。
ASG の ImpairedZoneHealthCheckBehavior が IgnoreUnhealthy に設定されている場合、以下の図に示すように、ヘルスチェックに失敗している AZ 1 のインスタンスは EC2 Auto Scaling によって終了されません。これは、AZ 分の容量損失に対処できるように事前にスケールされている場合に役立ちます。EC2 Auto Scaling が追加のインスタンスを起動しようとするのを防ぐことができるためです。また、AZ に容量を残すことで回復をより安全にすることもできます。つまり、障害が収まった後にロードバランサーのゾーンシフトを終了すると、その AZ は直ちにトラフィックの受信を再開できます。
図5 : ALB と ASG でゾーンシフトを実行し、ASG で不健全なインスタンスを無視することを選択
あるいは、オプションを ReplaceUnhealthy に設定することもできます。この場合、EC2 Auto Scaling によって不健全と判断されたインスタンスは置き換えられます。このオプションは、容量の損失に対処するための事前スケーリングがされていない場合に役立ちます。EC2 Auto Scaling は ASGを希望する容量に戻すために、残りの AZ で新しいインスタンスを起動します（以下の図を参照）。ただし、このアプローチにもトレードオフがあります：新しいインスタンスの起動は保証されないため、新しい容量を確保するために時間を要する可能性があります。
図 6 : ALB と ASG でゾーンシフトを実行し、今回は残りの AZ で不健全なインスタンスを置き換える
両方の状況において、クロスゾーン負荷分散が有効か無効かを考慮する必要があります。クロスゾーン負荷分散が有効な場合、各インスタンスは AZ に関係なく、ほぼ同等のトラフィックシェアを受け取ります。つまり、ロードバランサーと ASG の両方のゾーンシフトを同時に安全に終了できます。EC2 Auto Scalingが有効な各AZにわたってインスタンスを再バランスする際、それらは同じ割合のトラフィックを受け取ります。
クロスゾーンロードバランシングが無効な場合、AZ 内のインスタンス数に関係なく、各 AZ は同等の割合のトラフィックを受け取ります。不健全なインスタンスの置き換えを選択した場合、またはイベント中に ASG がスケールした場合、AZ 間の容量が不均衡になっている可能性があります。ロードバランサーのゾーンシフトを終了し、EC2 Auto Scaling が容量の再バランスを開始すると、以下の図のような状況に陥る可能性があります。ここでは、単一または少数のインスタンスが圧倒的な割合の負荷を受けることになります。
図7 : 3 つの AZ で容量が不均衡な 3 層アーキテクチャ
この不均衡は過負荷のリスクをもたらす可能性があるため、そのリスクを理解していることを確認するために、ゾーンシフトを有効にする際には--skip-zonal-shift-validation パラメータを指定する必要があります。ただし、ロードバランサーのtarget_group_health.dns_failover.minimum_healthy_targets.count オプションを使用し、AZ に存在すべきインスタンス数を指定することで、不均衡による過負荷の発生を防ぐことができます。3つのAZを使用し、希望する容量が 12 の場合、値を 4（ASGの総容量の 3 分の 1 を表す）に設定する必要があります。これにより、負荷を処理するのに十分な正常な容量がそこに存在するまで、AZ へのトラフィックのルーティングが防止されます。時間の経過とともに ASG がスケールするにつれて、この数値を動的に調整する必要がある場合があります。過去に設定した最小数が、今日の適切な最小数とは限りません。
ゾーンシフトのベストプラクティス
ベストプラクティスとして、以下を推奨します：
- AZ 1 つ分の容量損失に対処できるよう事前にスケールしておく
- 障害ポリシーを設定して不健全なホストを無視する (`IgnoreUnhealthy` の設定)
- クロスゾーンロードバランシングを有効にする
この構成により、ゾーンオートシフトも安全に使用できます。ゾーンオートシフトが有効な場合、AWS は単一 AZ に影響を与える障害があることを AWS テレメトリが示すたびに、自動的にゾーンシフトを開始および終了します。これは ELB ロードバランサーのゾーンオートシフトと組み合わせて使用できます。
ゾーンオートシフトを使用しない場合でも、EventBridge の通知を使用してゾーンシフトの判断や自動プロセスの開始に役立てることができます。ゾーンシフトを使用する際の完全なベストプラクティスセットについては、EC2 Auto Scaling ゾーンシフトのドキュメントを参照してください。
結論
この記事では、マルチ AZ アーキテクチャにおけるレジリエンス強化の一環として、Amazon EC2 Auto Scaling Groups でゾーンシフトを使用することの利点を示しました。ゾーンシフトを使用できるいくつかのシナリオを探索し、ゾーンシフトを安全かつ効果的に使用するためのベストプラクティスを確認しました。ASG でゾーンシフトの使用を開始するには、ドキュメントを参照してください。
—
翻訳はソリューションアーキテクトの新谷が担当しました。原文はこちらです。