{"id":"IL-0446","org":"ITANDI","date":"2020-01-28","docs":["https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#load-balancer-http-error-codes","https://aws.amazon.com/jp/about-aws/whats-new/2019/07/amazon-ecs-services-now-support-multiple-load-balancer-target-groups/","https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#availability-zones"],"title":{"en":"About 20% of requests to an ITANDI ECS service got ALB 5XX errors, apparently from one zone, right after a deploy","ko":"ECS 서비스에 배포한 직후 요청의 20% 쯤이 ALB 의 5XX 를 받았고, 오류는 ap-northeast-1d 에서만 나는 것처럼 보였다"},"domain":["aws","networking"],"impact":{"scope":"About 20% of the roughly 10,000 requests a minute to one service got 5XX responses from the ALB","users":"unknown","region":"ap-northeast-1 (errors appeared through ap-northeast-1d)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"When a graph shows something that should be impossible on the network, suspect the AWS side as well.","ko":"네트워크 구성상 있을 수 없는 그래프가 보이면 AWS 쪽도 의심해 봐야 한다."},"related":[],"sources":[{"url":"https://tech.itandi.co.jp/entry/2020/02/aws-alb-error-burst-triage","kind":"blog","archived":"https://web.archive.org/web/20260225140120/https://tech.itandi.co.jp/entry/2020/02/aws-alb-error-burst-triage"}],"summary":{"en":"The service runs on AWS ECS (Fargate) and is deployed with CircleCI and Terraform: merging a pull request makes Terraform recreate the ECS tasks with the new container image. Right after one such deploy, about 20% of requests got 5XX from the ALB, apparently only through ap-northeast-1d. Restarting tasks, changing the ALB's subnet in 1d, moving tasks out of 1d, removing 1d from the ALB, changing the idle timeout and rolling back the deploy all failed to stop the errors.\n\nThe team then rebuilt the load balancer without switching all traffic at once. It created a new ALB with exactly the same VPC, subnets, backends and security groups, attached it to the same ECS service (one ECS service can have several load balancer target groups), and added a second weighted DNS record in the hosted zone pointing at the new ALB with one tenth of the traffic. By about 4 a.m. the new ALB had returned no ELB 5XX at all, so the weights were set to 10 for the new ALB and 0 for the old one. The old ALB was kept and the team asked AWS Support to investigate. AWS Support answered that a load balancer node had developed a fault at the time of the deploy, which caused the errors.","ko":"이탄지의 한 서비스는 AWS ECS Fargate 에서 돈다. 풀 리퀘스트를 머지하면 CircleCI 와 Terraform 이 ECS 태스크를 다시 만들어 새 컨테이너 이미지를 적용한다. 운영에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 치솟아 분당 1만 건쯤 되는 요청의 20% 쯤이 5XX 를 받았다. CloudWatch 에서는 ap-northeast-1d 에서 들어온 요청만 5XX 를 받는 것처럼 보였다.\n\n팀은 ECS 태스크를 재시작하고, ELB 의 1d 서브넷을 교체하고, 1d 의 ECS 태스크 6개를 1a 와 1c 로 옮기고, ELB 에서 1d 서브넷을 뺐다. 이어서 유휴 타임아웃을 바꾸고 ECS 태스크를 배포 전으로 되돌렸지만 복구되지 않았다. 새벽 3시쯤 팀은 ELB 를 다시 만들기로 했다. VPC, 서브넷, 백엔드, SecurityGroup 이 똑같은 새 ELB 를 만들어 ECS 서비스에 함께 붙였다. 그리고 호스트 존에 새 ELB 를 가리키는 가중치 레코드를 더해 트래픽의 1/10 만 새 ELB 로 보냈다. 새 ELB 에서는 ELB_5XX 가 하나도 나오지 않았고, 팀은 가중치를 새 쪽 10, 옛 쪽 0 으로 바꿨다.\n\n팀은 옛 ELB 를 지우지 않고 AWS 지원팀에 조사를 맡겼다. AWS 지원팀은 배포한 시점에 로드 밸런서 노드에 결함이 생겨 이 일이 났다고 답했다."},"trigger":{"en":"A deploy recreated the ECS tasks, and at that moment communication between the ALB and its backends became unstable.","ko":"CircleCI 와 Terraform 으로 운영 ECS 에 배포해 ECS 태스크가 다시 만들어졌고, 그 시점에 ELB 와 백엔드 사이의 통신이 불안정해졌다."},"severity":"unknown","symptoms":["high-error-rate"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"The team saw HTTPCode_ELB_5XX_Count jump on the ALB right after the deploy, together with target connection errors.","ko":"팀은 운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟은 것을 보고 알았다."},"components":["cloud-load-balancer","ecs"],"root_cause":"cloud-provider","remediation":[{"text":{"en":"Restarted the ECS tasks, which did not help","ko":"ECS 태스크를 가장 먼저 재시작했지만 복구되지 않았다."}},{"text":{"en":"Moved the ALB's ap-northeast-1d subnet to another subnet in the same zone, which did not help","ko":"ELB 의 서브넷 가운데 1d 를 같은 1d 의 다른 서브넷으로 바꿨다. dig 로 ELB 이름을 조회해 IP 가 바뀐 것을 확인했지만 해결되지 않았다."}},{"text":{"en":"Moved the six ECS tasks running in 1d to 1a and 1c, which did not help","ko":"ECS 서비스 설정을 바꿔 ECS 태스크 15개 가운데 1d 에서 돌던 6개를 1a 와 1c 로 옮겼지만 해결되지 않았다."}},{"text":{"en":"Removed the 1d subnet from the ALB, which did not help","ko":"1d 에서 도는 ECS 태스크가 없어진 뒤 ELB 에서 1d 서브넷을 뺐지만 복구되지 않았다."}},{"text":{"en":"Changed the ALB idle timeout, which did not help","ko":"배포로 ECS 태스크가 무거워져 ELB 와 백엔드 사이에 타임아웃이 났을 가능성을 보고 ELB 의 유휴 타임아웃 설정을 바꿨지만 복구되지 않았다."}},{"text":{"en":"Rolled the ECS tasks back to the version before the deploy, which did not help","ko":"ECS 태스크를 배포 전으로 되돌렸지만 복구되지 않았다."}},{"text":{"en":"Created a new ALB with the same VPC, subnets, backends and security groups","ko":"VPC, 서브넷, 백엔드, SecurityGroup 이 옛 ELB 와 똑같은 새 ELB 를 만들었다."}},{"text":{"en":"Attached both ALBs to the ECS service","ko":"ECS 서비스 하나에 ELB 여러 개를 붙일 수 있으므로 ECS 서비스에 새 ELB 를 함께 붙였다."}},{"text":{"en":"Sent one tenth of the traffic to the new ALB with a weighted DNS record","ko":"서비스의 호스트 존에 옛 ELB 를 가리키는 레코드와 같은 레코드를 새 ELB 쪽으로 하나 더 만들었다. 두 레코드에 가중치를 줘서 트래픽의 1/10 만 새 ELB 로 보냈다."}},{"text":{"en":"Moved all traffic to the new ALB after it returned no 5XX","ko":"새 ELB 에서 ELB_5XX 가 하나도 나오지 않아 옛 ELB 에 문제가 있다고 보고 가중치를 새 쪽 10, 옛 쪽 0 으로 바꿨다."}}],"action_items":[],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"Right after a deploy to the production ECS (Fargate) service, HTTPCode_ELB_5XX_Count on the service's ALB jumped. The service receives about 10,000 requests a minute, and roughly 20% of them got a 5XX.\n\nTarget connection errors appeared at the same time. Restarting the ECS tasks did not bring the service back.\n\nIn CloudWatch, the ELB 5XX responses appeared to come only from traffic through ap-northeast-1d, one of the three availability zones of the ALB. AWS documentation lists problems in the backends as the cause of ELB 5XX, but an error in only one zone of three looked impossible unless created on purpose. Checks of the subnet ACLs, the ECS security groups and CloudTrail found nothing wrong.\n\nAssuming a network problem on the AWS side in 1d, the team moved the ALB's 1d subnet to another subnet in 1d (dig confirmed the ALB name now resolved to different IPs), moved the 6 of 15 ECS tasks running in 1d to 1a and 1c, and removed the 1d subnet from the ALB. None of this helped. Assuming the deploy was at fault, the team changed the ALB idle timeout in case slower tasks were timing out, and then rolled the ECS tasks back to the version before the deploy. The errors continued; by then it was about 3 a.m.","ko":"운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟았다. 분당 1만 건쯤 요청을 받는 서비스에서 요청의 20% 쯤이 5XX 를 받았고, 같은 때 타깃 연결 오류도 났다.\n\nCloudWatch 로 보니 ELB 가 쓰는 가용 영역 셋 가운데 ap-northeast-1d 에서 들어온 요청만 ELB 5XX 를 받는 것처럼 보였다.\n\n배포 직후였으므로 팀은 처음에 배포를 의심하고 ECS 태스크부터 재시작했지만 복구되지 않았다. 문서에 따르면 ELB 의 5XX 는 백엔드에 문제가 있을 때 나온다. 그러나 팀은 가용 영역 셋 가운데 1d 만 5XX 를 내는 상황은 일부러 만들지 않으면 생기지 않는다고 봤다. 그래서 서브넷 ACL, ECS 의 SecurityGroup 같은 네트워크 설정과 CloudTrail 을 확인했지만 문제는 나오지 않았다.\n\n팀은 AWS 쪽 네트워크를 의심하고 1d 를 떼어 내려 했다. 먼저 ELB 의 1d 서브넷을 같은 1d 의 다른 서브넷으로 바꿨다. 이어서 1d 의 ECS 태스크를 다른 가용 영역으로 옮기고, ELB 에서 1d 서브넷을 뺐다. 그래도 복구되지 않았다. 다시 배포를 의심해 ELB 의 유휴 타임아웃을 바꾸고 ECS 태스크를 배포 전으로 되돌렸지만 역시 복구되지 않았다."},"updated_at":"2026-11-14T12:34:09.529015Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0446","org_slug":"itandi"}