← 메인으로

AWS DynamoDB 서비스 장애 상세 분석 (2025년 10월)

게시일: 2025년 10월 24일 | 원문 작성일: 2025년 10월 22일 | 원문 보기

핵심 요약

2025년 10월 19일~20일, AWS의 버지니아 북부(us-east-1) 리전에서 대규모 서비스 장애가 발생했습니다. DynamoDB DNS 관리 시스템의 레이스 컨디션이 발단이 되어 DynamoDB, EC2, Lambda 등 주요 서비스들이 연쇄적으로 영향을 받았습니다.

주요 내용:

  • 장애 기간: 2025년 10월 19일 오후 11시 48분 ~ 10월 20일 오후 2시 20분 (PDT 기준, 약 14시간 반)
  • 근본 원인: DynamoDB DNS 관리 자동화 시스템의 잠재적 레이스 컨디션으로 인해 DNS 레코드가 빈 값으로 덮어써지면서 서비스 엔드포인트 해석 실패
  • 영향 범위: DynamoDB, EC2, Lambda, ECS/EKS, NLB, STS, Connect, Redshift 등 us-east-1 리전의 거의 모든 주요 서비스
  • 재발 방지 조치: DNS 관리 자동화 전면 중단 후 레이스 컨디션 수정, NLB에 velocity control 추가, EC2 복구 워크플로 테스트 강화

장애 타임라인

시간 (PDT)이벤트영향
10/19 11:48 PMDynamoDB DNS 레코드가 빈 값으로 덮어써짐DynamoDB 엔드포인트 해석 불가
10/20 12:38 AM엔지니어들이 DNS 문제 식별-
10/20 1:15 AM임시 복구 조치로 일부 내부 서비스 연결 복구내부 도구 복구
10/20 2:25 AMDynamoDB DNS 정보 완전 복구DynamoDB 주요 장애 해소
10/20 2:40 AMDNS 캐시 만료로 고객 접속 정상화-
10/20 5:28 AMEC2 DWFM 리스 복구 완료EC2 인스턴스 런칭 재개
10/20 10:36 AMNetwork Manager 네트워크 전파 정상화신규 인스턴스 네트워크 연결 정상
10/20 1:50 PMEC2 스로틀 완전 해제EC2 완전 복구
10/20 2:09 PMNLB 자동 헬스체크 failover 재활성화NLB 완전 복구
10/20 2:20 PM전체 서비스 복구 완료-

DynamoDB: 장애의 시작점

DNS 관리 아키텍처

AWS의 대규모 서비스들은 DNS를 활용해 수십만 개의 로드밸런서 엔드포인트를 관리합니다. DynamoDB의 DNS 관리는 두 개의 독립적인 컴포넌트로 구성됩니다:

graph LR A["DNS Planner"] -->|DNS Plan 생성| B["DNS Enactor AZ-1"] A -->|DNS Plan 생성| C["DNS Enactor AZ-2"] A -->|DNS Plan 생성| D["DNS Enactor AZ-3"] B -->|Route53 업데이트| E["Route53"] C -->|Route53 업데이트| E D -->|Route53 업데이트| E E --> F["DynamoDB Endpoint<br/>dynamodb.us-east-1.amazonaws.com"]
컴포넌트역할
DNS Planner로드밸런서 헬스와 용량을 모니터링하고 주기적으로 각 엔드포인트에 대한 새로운 DNS 플랜(로드밸런서 세트 + 가중치) 생성
DNS Enactor3개 가용영역(AZ)에서 독립적으로 중복 실행되며, DNS 플랜을 Route53에 적용. Route53 트랜잭션을 통해 동시 업데이트 시에도 일관성 보장

레이스 컨디션의 발생

⚠️ 문제가 된 시나리오

DNS Enactor들이 서로 다른 세대의 플랜을 처리하는 과정에서 타이밍 문제가 발생했습니다:

sequenceDiagram participant P as DNS Planner participant E1 as DNS Enactor 1 (느린) participant E2 as DNS Enactor 2 participant R as Route53 Note over E1: 플랜 N 처리 시작<br/>(비정상적으로 느림) P->>P: 플랜 N+1, N+2, N+3... 계속 생성 E2->>P: 최신 플랜(N+10) 가져옴 E2->>R: 모든 엔드포인트에 N+10 적용 (빠르게 완료) E2->>E2: Clean-up 프로세스:<br/>오래된 플랜들 삭제 준비 Note over E1: 여전히 플랜 N 처리 중 E1->>R: 플랜 N을 regional endpoint에 적용<br/>(최신 플랜 N+10을 덮어씀) Note over R: ❌ 플랜 N+10 → 플랜 N으로 롤백됨 E2->>P: 플랜 N 삭제 (오래된 플랜이므로) Note over R: ❌❌ 활성 플랜이 삭제되어<br/>DNS 레코드가 빈 값으로 Note over R: 시스템이 비일관 상태가 되어<br/>자동 복구 불가능

문제의 핵심은:

  • Enactor 1이 비정상적으로 느리게 작동하며 오래된 플랜 N을 처리하는 동안
  • Enactor 2는 최신 플랜(N+10)을 빠르게 적용한 후 오래된 플랜들을 삭제하기 시작
  • Enactor 1의 처음에 했던 “더 최신 플랜인지 확인”하는 체크는 이미 오래 전에 끝났고, 이제는 stale한 정보
  • 결과적으로 Enactor 1이 최신 플랜을 오래된 플랜으로 덮어쓰고, 그 플랜은 즉시 삭제되면서 모든 IP 주소가 제거됨

영향 및 복구

10월 19일 오후 11시 48분부터 DynamoDB의 퍼블릭 엔드포인트로 연결을 시도하는 모든 시스템이 DNS 실패를 경험했습니다. 이는 고객 트래픽뿐만 아니라 DynamoDB에 의존하는 내부 AWS 서비스들도 포함됩니다.

  • 12:38 AM: 엔지니어들이 DynamoDB DNS 문제 식별
  • 1:15 AM: 임시 완화 조치로 일부 내부 서비스와 주요 내부 도구 복구
  • 2:25 AM: 모든 DNS 정보 복구 완료
  • 2:40 AM: 캐시된 DNS 레코드 만료로 고객들이 DynamoDB 접속 가능해짐

EC2: 연쇄 장애

DWFM(DropletWorkflow Manager) 리스 문제

EC2는 물리 서버(“droplet”)를 관리하기 위해 DWFM을 사용합니다. 각 DWFM은 관리하는 droplet과 리스를 유지하며, 몇 분마다 상태 체크를 수행합니다. 이 상태 체크는 DynamoDB에 의존하고 있었습니다.

10/19 11:48 PM: DynamoDB 장애로 DWFM 상태 체크 실패 시작

10/19 11:48 PM - 10/20 2:24 AM: EC2 fleet 전체의 droplet 리스가 서서히 타임아웃

10/20 2:25 AM: DynamoDB 복구 후 DWFM이 리스 재설정 시도

문제는 여기서 발생했습니다. droplet 수가 너무 많아서 리스를 재설정하는 작업이 타임아웃되기 전에 완료되지 못했고, 작업이 계속 재시도되면서 DWFM이 “congestive collapse” 상태에 빠졌습니다.

복구 과정

  • 4:14 AM: 엔지니어들이 들어오는 작업을 스로틀링하고 DWFM 호스트를 선택적으로 재시작
  • 5:28 AM: 모든 droplet과의 리스 재설정 완료, 새로운 인스턴스 런칭 재개 (단, 여전히 스로틀링 중)

Network Manager 백로그

DWFM 복구 직후, Network Manager가 지연되었던 네트워크 설정 전파를 처리하기 시작했습니다. 엄청난 백로그로 인해:

  • 6:21 AM: Network Manager가 증가된 레이턴시 경험
  • 새로운 EC2 인스턴스는 런칭되지만 네트워크 연결이 없는 상태
  • 10:36 AM: 네트워크 설정 전파 시간 정상화
  • 1:50 PM: 모든 스로틀링 해제 및 EC2 완전 복구

NLB(Network Load Balancer): 헬스체크 문제

Network Manager의 지연은 NLB에도 영향을 미쳤습니다. NLB는 별도의 헬스체크 서브시스템을 사용하는데, 이 시스템이 네트워크 상태가 아직 완전히 전파되지 않은 새 EC2 인스턴스를 서비스에 투입하면서 문제가 발생했습니다.

graph TD A["헬스체크 서브시스템"] -->|신규 EC2 투입| B["헬스체크 수행"] B -->|네트워크 미전파| C["헬스체크 실패"] C --> D["노드 제거"] B -->|다음 체크 시 성공| E["노드 재투입"] E --> B C -->|반복| F["헬스체크 시스템 부하 증가"] F --> G["헬스체크 지연"] G --> H["자동 AZ DNS failover 발동"] H --> I["Multi-AZ LB 용량 감소"] I --> J["고객 연결 에러 증가"]
  • 5:30 AM - 2:09 PM: 일부 NLB에서 연결 에러 증가
  • 9:36 AM: 엔지니어들이 자동 헬스체크 failover 비활성화
  • 2:09 PM: EC2 복구 후 자동 DNS 헬스체크 failover 재활성화

기타 영향받은 서비스

서비스영향 시간주요 증상
Lambda10/19 11:51 PM - 10/20 2:15 PM함수 생성/업데이트 실패, SQS/Kinesis 이벤트 소스 지연, 호출 에러. SQS 큐 처리 서브시스템 장애로 복구 지연
ECS/EKS/Fargate10/19 11:45 PM - 10/20 2:20 PM컨테이너 런칭 실패 및 클러스터 스케일링 지연
Amazon Connect10/19 11:56 PM - 10/20 1:20 PM통화, 채팅, 케이스 처리 에러 증가. 인바운드 발신자는 통화 중 신호나 에러 메시지 경험
STS10/19 11:51 PM - 10/20 9:59 AMAPI 에러 및 레이턴시. 1:19 AM 복구 후 8:31-9:59 AM에 NLB 문제로 재발
AWS Console 로그인10/19 11:51 PM - 10/20 1:25 AMIAM 사용자 및 Identity Center 인증 실패
Redshift10/19 11:47 PM - 10/21 4:05 AM클러스터 생성/수정 및 쿼리 에러. EC2 런칭 문제로 교체 워크플로 막혀 일부 클러스터 장기간 사용 불가. 전 리전에서 IAM 사용자 쿼리 실행 불가(Redshift 버그)

AWS의 재발 방지 조치

1. DynamoDB DNS 관리

2. Network Load Balancer (NLB)

  • 헬스체크 실패로 AZ failover 발생 시 단일 NLB가 제거할 수 있는 용량을 제한하는 velocity control 메커니즘 추가

3. EC2

  • DWFM 복구 워크플로를 검증하는 추가 테스트 스위트 구축
  • EC2 데이터 전파 시스템의 스로틀링 메커니즘 개선 - 대기 큐 크기 기반 rate limiting으로 고부하 시 서비스 보호

4. 전체 서비스 차원

  • 모든 AWS 서비스 전반에 걸쳐 유사한 이벤트의 영향을 피하는 방법 검토
  • 복구 시간을 더욱 단축할 수 있는 방법 모색

결론

AWS는 이번 장애로 영향을 받은 고객들에게 사과했습니다. AWS 서비스는 높은 가용성을 자랑하지만, 이번 이벤트가 많은 고객들에게 심각한 영향을 미쳤다는 점을 인정했습니다.

이번 사고는 몇 가지 중요한 교훈을 남깁니다:

  • 단일 서비스 장애의 도미노 효과: DynamoDB라는 핵심 서비스의 DNS 문제가 EC2, Lambda, NLB 등 거의 모든 서비스에 연쇄적으로 영향을 미쳤습니다
  • 레이스 컨디션의 위험성: 오랜 기간 잠재되어 있던 레이스 컨디션이 특정 타이밍에 치명적인 결과를 초래할 수 있습니다
  • 복구의 복잡성: 초기 문제(DynamoDB DNS) 해결 후에도 각 서비스의 백로그와 부하 문제로 완전 복구까지 추가 시간이 필요했습니다
  • Congestive collapse: 시스템이 복구를 시도하는 과정에서 오히려 더 악화되는 상황에 대한 대비가 필요합니다

AWS는 이번 이벤트로부터 배운 점들을 활용해 향후 가용성을 더욱 개선하겠다고 약속했습니다.

참고: 이 글은 Amazon Web Services가 2025년 10월 버지니아 북부(us-east-1) 리전에서 발생한 DynamoDB 서비스 장애에 대해 발표한 포스트모템 리포트를 번역하고 요약한 것입니다.

원문: https://aws.amazon.com/message/101925/

생성: Claude (Anthropic)

총괄: 존 (디노이저denoiser)