NX開発推進部の齋藤です。
今回は Amazon Elastic Container Service (ECS) で発生した接続不安定障害とその対応策（アベイラビリティゾーンの再調整）について紹介します。
この記事は ECS をある程度運用したことがある方を対象にしています。
【背景】
現在運用中の Web サイトは、次の構成で稼働しています。
図1: NLB を使用した Web サイトの構成（簡略図）
(図は簡略化していますが、) ECSのコンテナをアベイラビリティゾーン別で2台起動しています。
この構成の特徴は、固定 IP が必要なため、別アカウントの Application Load Balancer (ALB) からの通信を受ける目的で Network Load Balancer (NLB) を採用している点です。
アベイラビリティゾーンごとに固定IPを設定し、ALBからそのIPに転送しています。
ある日、Web サイトへの接続が不安定になる障害が発生しました。
調査の結果、ECSのタスクがパッチリタイアメントにより自動再起動され、その際にアベイラビリティゾーンへの配置が偏っていたことが原因であると判明しました。
図2: アベイラビリティゾーンの偏りが発生した状態
この偏りにより、NLB の振り分けが正しく行われず、一部のゾーンでは 504 エラーが発生し、接続が困難な状況となりました。
図3: 障害発生時のシステム構成
【対応】
応急処置として、サービスの強制デプロイを実施し、新しいタスクが複数のアベイラビリティゾーンに均等に分散されるようにしました。その結果、問題は解消されました。
図4: 対応後のアベイラビリティゾーン分散
【恒久対応】
今後同様の障害が再発しないよう、サービス設定においてアベイラビリティゾーンの再調整 (availabilityZoneRebalancing) を有効化しました。
この設定は、ECS タスクの配置がアベイラビリティゾーン間で不均衡になった場合に、自動で均等化を試みる機能です。
この設定を有効化することで、アベイラビリティゾーン間の偏りが是正されやすくなります。その結果、今回のような障害は発生しにくくなると考えられます。
$ aws ecs update-service \ --service {service_name} \ --cluster {cluster_name} \ --availability-zone-rebalancing "ENABLED" |
本来であればインフラはCDKで管理しているのですが、この設定はまだ対応していないためCLIでの設定となっています。
上記の対応により、今後、障害発生時でもタスクの配置が均等に行われることが期待されます。
CDK での availabilityZoneRebalancing 対応状況
以下のGitHub Issue にて、CDKでの availabilityZoneRebalancing 対応が進められており、関連するPRがすでにマージされています。
GitHub Issue（CDKのECS AZ Rebalancing対応）
このため、今後のAWS CDKアップデートで、availabilityZoneRebalancing のオプションが追加される可能性が高いと考えられます。
参考
アベイラビリティーゾーン間での Amazon ECS サービスの調整
追記：障害の直接原因と availabilityZoneRebalancing の位置づけ
2025-4-8 追記
追加調査の結果、今回の障害の直接的な原因は、NLB のクロスゾーン負荷分散が無効になっていたことだと判明しました。
ALB とは異なり、NLB のクロスゾーン負荷分散はデフォルトで無効です。この点を認識しておらず、設定を見落としていました。
したがって、NLB のクロスゾーン負荷分散を有効化すれば、本記事で紹介した availabilityZoneRebalancing を有効化しなくても、今回の障害自体は解消されると考えられます。
ただし、アベイラビリティゾーン間のタスク配置が不均衡な状態を放置すると、特定の AZ で障害が発生した場合にサービスへの影響が大きくなる可能性があります。
そのため、可用性をさらに高める観点から、availabilityZoneRebalancing を有効化することにも依然として価値があると考えます。
この記事を書いた人
最近書いた記事
2025.03.28Amazon ECSのアベイラビリティゾーン再調整について
2024.05.27LangChainまとめ
2023.12.07pytestのmockerについて