IL-0446 ITANDI · 2020-01-28 (게시일)awsnetworking
ECS 서비스에 배포한 직후 요청의 20% 쯤이 ALB 의 5XX 를 받았고, 오류는 ap-northeast-1d 에서만 나는 것처럼 보였다
이탄지의 한 서비스는 AWS ECS Fargate 에서 돈다. 풀 리퀘스트를 머지하면 CircleCI 와 Terraform 이 ECS 태스크를 다시 만들어 새 컨테이너 이미지를 적용한다. 운영에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 치솟아 분당 1만 건쯤 되는 요청의 20% 쯤이 5XX 를 받았다. CloudWatch 에서는 ap-northeast-1d 에서 들어온 요청만 5XX 를 받는 것처럼 보였다.
팀은 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 으로 바꿨다.
팀은 옛 ELB 를 지우지 않고 AWS 지원팀에 조사를 맡겼다. AWS 지원팀은 배포한 시점에 로드 밸런서 노드에 결함이 생겨 이 일이 났다고 답했다.
- 심각도
- –
- 영향 범위
- About 20% of the roughly 10,000 requests a minute to one service got 5XX responses from the ALB
- 영향 사용자
- –
- 지역
- ap-northeast-1 (errors appeared through ap-northeast-1d)
- 감지까지
- –
- 복구까지
- –
증상
운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟았다. 분당 1만 건쯤 요청을 받는 서비스에서 요청의 20% 쯤이 5XX 를 받았고, 같은 때 타깃 연결 오류도 났다.
CloudWatch 로 보니 ELB 가 쓰는 가용 영역 셋 가운데 ap-northeast-1d 에서 들어온 요청만 ELB 5XX 를 받는 것처럼 보였다.
배포 직후였으므로 팀은 처음에 배포를 의심하고 ECS 태스크부터 재시작했지만 복구되지 않았다. 문서에 따르면 ELB 의 5XX 는 백엔드에 문제가 있을 때 나온다. 그러나 팀은 가용 영역 셋 가운데 1d 만 5XX 를 내는 상황은 일부러 만들지 않으면 생기지 않는다고 봤다. 그래서 서브넷 ACL, ECS 의 SecurityGroup 같은 네트워크 설정과 CloudTrail 을 확인했지만 문제는 나오지 않았다.
팀은 AWS 쪽 네트워크를 의심하고 1d 를 떼어 내려 했다. 먼저 ELB 의 1d 서브넷을 같은 1d 의 다른 서브넷으로 바꿨다. 이어서 1d 의 ECS 태스크를 다른 가용 영역으로 옮기고, ELB 에서 1d 서브넷을 뺐다. 그래도 복구되지 않았다. 다시 배포를 의심해 ELB 의 유휴 타임아웃을 바꾸고 ECS 태스크를 배포 전으로 되돌렸지만 역시 복구되지 않았다.
증상 오류율 상승
원인
원인 클라우드 제공자 장애
- 촉발
- CircleCI 와 Terraform 으로 운영 ECS 에 배포해 ECS 태스크가 다시 만들어졌고, 그 시점에 ELB 와 백엔드 사이의 통신이 불안정해졌다.
감지
팀은 운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟은 것을 보고 알았다.
조치
- ECS 태스크를 가장 먼저 재시작했지만 복구되지 않았다.
- ELB 의 서브넷 가운데 1d 를 같은 1d 의 다른 서브넷으로 바꿨다. dig 로 ELB 이름을 조회해 IP 가 바뀐 것을 확인했지만 해결되지 않았다.
- ECS 서비스 설정을 바꿔 ECS 태스크 15개 가운데 1d 에서 돌던 6개를 1a 와 1c 로 옮겼지만 해결되지 않았다.
- 1d 에서 도는 ECS 태스크가 없어진 뒤 ELB 에서 1d 서브넷을 뺐지만 복구되지 않았다.
- 배포로 ECS 태스크가 무거워져 ELB 와 백엔드 사이에 타임아웃이 났을 가능성을 보고 ELB 의 유휴 타임아웃 설정을 바꿨지만 복구되지 않았다.
- ECS 태스크를 배포 전으로 되돌렸지만 복구되지 않았다.
- VPC, 서브넷, 백엔드, SecurityGroup 이 옛 ELB 와 똑같은 새 ELB 를 만들었다.
- ECS 서비스 하나에 ELB 여러 개를 붙일 수 있으므로 ECS 서비스에 새 ELB 를 함께 붙였다.
- 서비스의 호스트 존에 옛 ELB 를 가리키는 레코드와 같은 레코드를 새 ELB 쪽으로 하나 더 만들었다. 두 레코드에 가중치를 줘서 트래픽의 1/10 만 새 ELB 로 보냈다.
- 새 ELB 에서 ELB_5XX 가 하나도 나오지 않아 옛 ELB 에 문제가 있다고 보고 가중치를 새 쪽 10, 옛 쪽 0 으로 바꿨다.
후속 조치
–
교훈
네트워크 구성상 있을 수 없는 그래프가 보이면 AWS 쪽도 의심해 봐야 한다.
출처
참고 문서
- 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
관련 사례
같은 원인 · 공통 클라우드 로드 밸런서
IL-0463Harness Secure Connect 의 내부 로드 밸런서에 닿을 수 없게 되어 Secure Connect 를 쓰는 git 커넥터 검사와 CI 파이프라인이 실패했다Harness · 2026같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 클라우드 로드 밸런서
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0446
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0446/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.