IL-0150 Amazon Web Services · 2025-10-19awskubernetesnetworking
DynamoDB 는 리전마다 아주 많은 로드 밸런서를 운영하고, 이를 위해 DNS 레코드 수십만 개를 자동화로 관리한다. DNS 관리 시스템은 두 구성 요소로 나뉜다. DNS Planner 는 로드 밸런서의 상태와 용량을 살펴 엔드포인트마다 로드 밸런서와 가중치로 이뤄진 새 DNS 계획을 주기적으로 만든다. DNS Enactor 는 그 계획을 Amazon Route53 에 반영하며, 세 가용 영역에서 서로 독립적으로 하나씩 돈다. Enactor 는 새 계획을 적용하기 전에 그 계획이 이전에 적용된 것보다 새로운지 한 번만 확인한다.
장애 직전 Enactor 하나가 여러 엔드포인트에서 이례적으로 긴 지연을 겪으며 재시도를 반복했다. 그사이 Planner 는 더 새로운 계획을 여러 세대 만들었고, 다른 Enactor 가 가장 새로운 계획을 빠르게 모든 엔드포인트에 적용했다. 두 번째 Enactor 는 적용을 마친 뒤 훨씬 오래된 계획을 지우는 정리 작업을 돌렸다. 바로 그때 지연됐던 첫 번째 Enactor 가 훨씬 오래된 계획을 리전 엔드포인트에 덮어썼다. 시작할 때 한 확인의 결과는 이미 낡아 있어서 덮어쓰기를 막지 못했다. 정리 작업이 이 오래된 계획을 지우자 리전 엔드포인트의 IP 주소가 모두 사라졌다. 활성 계획이 지워져 시스템이 일관되지 않은 상태가 됐고, 어떤 Enactor 도 다음 계획을 적용하지 못해 운영자가 손으로 바로잡아야 했다.
00시 38분 엔지니어들이 DynamoDB 의 DNS 상태를 원인으로 찾았다. 01시 15분 임시 조치로 일부 내부 서비스가 DynamoDB 에 연결되고 핵심 내부 도구가 살아났다. 02시 25분 DNS 정보가 모두 복구됐고, 02시 25분부터 02시 40분 사이 캐시된 DNS 레코드가 만료되면서 고객도 다시 연결됐다.
EC2 는 DynamoDB 가 돌아온 뒤에도 회복하지 못했다. AWS 는 EC2 물리 서버를 droplet 이라 부르고, 이를 관리하는 시스템이 DropletWorkflow Manager, 줄여서 DWFM 이다. DWFM 은 droplet 마다 자신이 관리 중이라는 표시인 리스를 유지하려고 몇 분마다 상태를 확인한다. 이 확인이 DynamoDB 에 기대고 있어 장애 동안 리스가 하나씩 만료됐다. 리스가 없는 droplet 은 새 인스턴스를 올릴 후보가 되지 못해 EC2 API 가 "insufficient capacity" 오류를 냈다. 02시 25분 DWFM 이 리스를 다시 맺기 시작했지만 droplet 이 너무 많아 작업이 타임아웃 전에 끝나지 못했고, 재시도 작업이 큐에 쌓이며 DWFM 이 혼잡 붕괴 상태에 빠졌다. 정해진 복구 절차가 없어 엔지니어들은 조심스럽게 여러 조치를 시도했고, 04시 14분 들어오는 작업을 스로틀링하고 DWFM 호스트를 골라 재시작했다. 05시 28분 모든 droplet 의 리스가 다시 맺어졌다.
그 뒤 Network Manager 가 밀린 네트워크 구성 전파를 한꺼번에 처리하면서 06시 21분부터 전파 지연이 커졌다. 새 인스턴스는 떴지만 네트워크 연결이 없었다. NLB 헬스 체크 시스템은 이런 인스턴스를 서비스에 넣었다가 헬스 체크 실패로 빼기를 되풀이했고, 늘어난 부하로 헬스 체크 자체가 느려지면서 가용 영역 DNS 장애 조치가 자동으로 일어나 용량이 서비스에서 빠졌다. 10시 36분 네트워크 전파 시간이 정상이 됐고, 11시 23분부터 요청 스로틀링을 풀어 13시 50분 EC2 가 완전히 회복됐다. EKS, ECS, Fargate 는 14시 20분에 복구됐다.
2025년 10월 19일 23시 48분 PDT 부터 us-east-1 리전에서 공개 엔드포인트로 DynamoDB 에 연결하려던 모든 시스템이 DNS 조회에 실패했다. 고객 트래픽과 DynamoDB 에 기대는 AWS 내부 서비스가 함께 실패했다.
EKS, ECS, Fargate 에서는 10월 19일 23시 45분부터 10월 20일 14시 20분 PDT 까지 컨테이너 시작 실패와 클러스터 스케일링 지연이 이어졌다. EC2 는 10월 19일 23시 48분부터 10월 20일 13시 50분 PDT 까지 API 오류와 지연이 늘고 새 인스턴스 시작이 실패했다. 새 인스턴스 시작은 "request limit exceeded" 또는 "insufficient capacity" 오류로 실패했다. 이미 떠 있던 EC2 인스턴스는 영향을 받지 않았다.
증상은 세 시기로 나뉘었다. 23시 48분부터 02시 40분까지는 DynamoDB API 오류율이 올랐다. 02시 25분부터 10시 36분까지는 새 EC2 인스턴스 시작이 실패했고, 10시 37분부터 시작은 성공했지만 일부 새 인스턴스는 13시 50분까지 네트워크 연결에 문제가 있었다. 05시 30분부터 14시 09분까지는 일부 Network Load Balancer 에서 연결 오류가 늘었다.
NLB 헬스 체크는 실패와 성공을 오갔다. 네트워크 구성이 아직 다 전파되지 않은 새 EC2 인스턴스를 헬스 체크 시스템이 서비스에 넣으면서, 실제로는 정상인 NLB 노드와 백엔드 대상이 DNS 에서 빠졌다가 다음 헬스 체크가 성공하면 돌아오기를 되풀이했다. Lambda, Amazon Connect, STS, IAM 사용자의 콘솔 로그인, Redshift, AWS Support 도 오류와 지연을 겪었다.
원인 ? 소프트웨어 결함
영향받은 AWS 서비스의 엔지니어링 팀이 23시 48분 장애가 시작되자 바로 투입돼 조사했고, 00시 38분 DynamoDB 의 DNS 상태를 원인으로 찾았다. NLB 헬스 체크 문제는 06시 52분 모니터링 시스템이 감지했다.
DNS 자동화가 스스로 고칠 수 없는 상태에 빠지면 사람이 손대기 전까지 리전 엔드포인트가 통째로 사라진다. 계획이 더 새로운지 적용 전에 한 번만 확인하면, 처리가 길게 지연됐을 때 그 확인 결과는 낡은 정보가 된다.
기반 서비스가 돌아와도 그 위의 시스템은 밀린 작업 때문에 혼잡 붕괴에 빠질 수 있다. 이번에는 정해진 복구 절차가 없어 엔지니어들이 여러 조치를 조심스럽게 시도한 끝에 04시 14분에야 스로틀링과 호스트 재시작으로 풀었다. EKS 처럼 EC2 인스턴스 시작에 기대는 서비스는 DynamoDB 가 회복된 뒤에도 EC2 와 네트워크 전파가 정상화될 때까지 컨테이너 시작과 스케일링이 막혔다. 헬스 체크에 따른 자동 장애 조치는 상태 정보가 흔들릴 때 정상 용량까지 빼 버릴 수 있다.
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 클라우드 로드 밸런서
같은 원인 · 공통 애플리케이션 데이터베이스
같은 원인 · 공통 클라우드 로드 밸런서