▲

미국 동부(버지니아 북부, US-East-1) 리전에서 발생한 Amazon DynamoDB 서비스 중단 요약

 (aws.amazon.com)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 2025년 10월 19~20일, AWS N. Virginia 리전(us-east-1) 에서 Amazon DynamoDB를 비롯한 여러 핵심 서비스가 장시간 장애를 겪음
  • 장애는 DynamoDB의 자동 DNS 관리 시스템 내 잠재적 경쟁 조건(race condition) 으로 인해 잘못된 빈 DNS 레코드가 생성되면서 시작됨
  • 이로 인해 EC2 인스턴스 생성 실패, Network Load Balancer(NLB) 연결 오류, Lambda·ECS·Redshift 등 다수 서비스의 API 지연 및 실패가 연쇄적으로 발생
  • AWS는 문제 원인을 DynamoDB DNS Enactor 간 비정상 동시 업데이트 충돌로 규명하고, 수동 복구를 통해 10월 20일 오후 2시 20분경 완전 복구
  • 이번 사건은 AWS 내부 자동화 시스템 간 상호 의존성의 복잡성을 드러내며, 향후 DNS·EC2·NLB 복원력 강화를 위한 구조적 개선이 예고됨

사건 개요

  • 장애는 2025년 10월 19일 오후 11시 48분(PDT)에 시작되어 10월 20일 오후 2시 20분(PDT)에 종료
    • 세 차례의 주요 영향 구간이 존재:
      1. 10월 19일 11:48PM~10월 20일 2:40AM: DynamoDB API 오류율 급증
      2. 10월 20일 5:30AM~2:09PM: NLB 연결 오류 증가
      3. 10월 20일 2:25AM~10:36AM: EC2 신규 인스턴스 생성 실패 및 네트워크 연결 문제
  • 장애는 DynamoDB DNS 관리 시스템의 결함에서 시작되어 EC2, NLB, Lambda, Redshift 등 다수 서비스로 확산

DynamoDB 장애 원인 및 영향

  • DynamoDB의 자동 DNS 관리 시스템 내 잠재적 결함이 트리거되어, dynamodb.us-east-1.amazonaws.com의 DNS 레코드가 비어 있는 상태로 잘못 갱신됨
    • 시스템은 두 구성요소로 분리되어 있음:
      • DNS Planner: 로드밸런서 상태를 모니터링하고 새로운 DNS 계획 생성
      • DNS Enactor: Route53에 변경사항을 적용하는 역할
  • 세 개의 가용 영역(AZ)에 독립적으로 배치된 DNS Enactor 간 경쟁 조건(race condition) 이 발생
    • 첫 번째 Enactor가 지연된 상태에서 오래된 계획을 적용
    • 두 번째 Enactor가 최신 계획을 적용 후 오래된 계획을 삭제하면서, 모든 IP 주소가 제거되고 시스템이 불일치 상태로 전환
    • 자동 복구 실패로 인해 수동 조작(manual intervention) 이 필요
  • 11:48PM 장애 발생 직후, DynamoDB에 의존하는 모든 서비스와 고객 트래픽이 연결 실패
    • 글로벌 테이블을 사용하는 고객은 다른 리전의 복제본으로 요청 가능했으나, 복제 지연(replication lag) 발생
  • 12:38AM에 AWS 엔지니어가 DNS 상태를 문제 원인으로 확인
    • 1:15AM 임시 복구 조치로 일부 내부 서비스 연결 복원
    • 2:25AM DNS 정보 완전 복원, 2:40AM 모든 연결 정상화

Amazon EC2 영향 및 복구 과정

  • 10월 19일 11:48PM~10월 20일 1:50PM 동안 EC2 API 오류율 상승, 인스턴스 생성 실패, 지연 증가 발생
    • 기존 실행 중인 인스턴스는 영향 없음
  • EC2 인스턴스 관리에는 DropletWorkflow Manager(DWFM) 와 Network Manager 두 하위 시스템이 사용됨
    • DWFM은 물리 서버(‘droplet’)의 상태를 관리하며, 주기적으로 상태 점검 수행
    • Network Manager는 인스턴스 네트워크 구성을 전파
  • DynamoDB 장애로 DWFM의 상태 점검이 실패하면서 droplet 임대(lease)가 만료
    • 2:25AM DynamoDB 복구 후 DWFM이 재연결 시도했으나, 대규모 droplet 수로 인해 혼잡 붕괴(congestive collapse) 발생
    • 4:14AM 엔지니어가 DWFM 호스트를 선택적으로 재시작하여 큐를 정리하고 복구 진행
    • 5:28AM 모든 droplet 임대 복원, 신규 인스턴스 생성 재개
  • 이후 Network Manager가 지연된 네트워크 상태 전파(backlog)를 처리하면서 네트워크 연결 지연 발생
    • 10:36AM 네트워크 전파 시간 정상화
    • 11:23AM 요청 제한(throttling) 완화 시작, 1:50PM EC2 완전 복구

Network Load Balancer(NLB) 영향

  • 10월 20일 5:30AM~2:09PM 동안 일부 고객이 NLB 연결 오류 증가 경험
    • NLB는 다중 테넌트 구조로, 백엔드 EC2 인스턴스에 트래픽을 라우팅
  • 장애 원인은 네트워크 상태 전파 지연으로 인한 헬스체크 실패
    • 새로 추가된 EC2 인스턴스의 네트워크 구성이 완료되지 않아 헬스체크가 실패
    • 헬스체크 결과가 불안정하게 반복되어 NLB 노드가 DNS에서 제거되었다가 복귀하는 현상 발생
  • 6:52AM 모니터링 시스템이 문제 감지, 엔지니어가 대응 시작
    • 헬스체크 서브시스템 부하 증가로 자동 AZ DNS 장애 조치(failover) 발생
    • 9:36AM 자동 장애 조치 비활성화로 모든 정상 노드 복귀
    • 2:09PM EC2 복구 후 자동 장애 조치 재활성화

기타 AWS 서비스 영향

  • AWS Lambda:
    • 10월 19일 11:51PM~10월 20일 2:15PM 동안 API 오류 및 지연
    • DynamoDB 장애로 함수 생성·갱신 실패, SQS/Kinesis 이벤트 처리 지연
    • 7:04AM NLB 헬스체크 실패로 내부 시스템 축소, 비동기 호출 제한
    • 2:15PM 모든 백로그 처리 완료 및 정상화
  • ECS, EKS, Fargate:
    • 10월 19일 11:45PM~10월 20일 2:20PM 동안 컨테이너 실행 실패 및 클러스터 확장 지연
  • Amazon Connect:
    • 10월 19일 11:56PM~10월 20일 1:20PM 동안 통화·채팅·케이스 처리 오류
    • DynamoDB 복구 후 대부분 기능 정상화, 그러나 7:04AM 이후 NLB 및 Lambda 영향으로 재차 오류 발생
    • 1:20PM 완전 복구
  • AWS STS:
    • 10월 19일 11:51PM~10월 20일 9:59AM 동안 인증 API 오류 및 지연
    • DynamoDB 복구 후 일시 정상화, NLB 문제로 재차 오류 발생
  • IAM 로그인 및 Identity Center:
    • 10월 19일 11:51PM~10월 20일 1:25AM 동안 인증 실패 증가
    • DynamoDB 복구 후 정상화
  • Amazon Redshift:
    • 10월 19일 11:47PM~10월 20일 2:21AM 동안 쿼리 및 클러스터 수정 실패
    • DynamoDB 복구 후 일부 클러스터는 EC2 장애로 여전히 비정상
    • 10월 21일 4:05AM 완전 복구
    • IAM API 의존성으로 인해 글로벌 리전에서도 일시적 쿼리 실패 발생
  • 기타 서비스:
    • Managed Workflows for Apache Airflow, Outposts, AWS Support Center 등도 영향

사후 조치 및 개선 계획

  • DynamoDB DNS Planner 및 Enactor 자동화 전면 비활성화, 재활성화 전 경쟁 조건 수정 및 보호 장치 추가 예정
  • NLB: 헬스체크 실패 시 단일 NLB가 제거할 수 있는 용량을 제한하는 속도 제어 메커니즘 도입
  • EC2:
    • DWFM 복구 워크플로우를 포함한 새로운 테스트 스위트 구축
    • 데이터 전파 시스템의 스마트 스로틀링 개선으로 대기 큐 크기에 따른 요청 제한 기능 추가
  • AWS는 전체 서비스 간 상호 의존성 분석을 통해 복구 시간 단축 및 유사 사고 방지 방안을 추가 검토 중

결론 및 사과

  • AWS는 이번 사건으로 고객에게 미친 영향에 대해 공식 사과
  • 자사 서비스의 높은 가용성을 유지해왔으나, 이번 장애가 고객 비즈니스에 중대한 영향을 미쳤음을 인정
  • 본 사건을 교훈 삼아 자동화 시스템의 복원력 및 장애 대응 절차 강화를 약속
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 나는 이 주제에 대해 늘 같은 말을 반복하는 사람임. 아직 Richard Cook의 글을 읽지 않았다면, 지금 이 포스트모템을 멈추고 먼저 How Complex Systems Fail을 읽어보길 권함. 이 글은 복잡한 시스템 실패를 다룬 최고의 기술 글 중 하나임. Cook은 “루트 원인(root cause)”이라는 개념 자체를 거부하는데, 이번 사건에서도 그가 옳다고 생각함

    • Cook의 글은 괜찮지만, 사실상 직관적인 주장들의 나열처럼 느껴짐. 진짜 깊이 이해하려면 참고문헌을 다 읽어야 할 듯함. MIT의 시스템 수업 6.033에서도 비슷한 주제를 다루는 1962년 논문과 다른 고전 논문을 읽게 함. 이런 문제는 결국 ‘Wicked problem’ 수준의 복잡성에 도달한 사례라고 봄
    • Cook의 글에서 인상 깊었던 부분은, 사고 후 시스템을 “더 안전하게” 고치려는 시도가 오히려 안전성을 낮출 수 있음이라는 점이었음. 인간 오류를 막기 위한 조치들이 시스템의 결합도와 복잡성을 높여, 잠재적 실패 지점을 늘리고 탐지·차단을 더 어렵게 만든다는 설명이 특히 와닿았음
    • 또 다른 관점으로는 ‘Normal Accidents’ 이론이 있음. 구성 요소들이 강하게 결합되고 상호작용이 복잡하며 실패의 결과가 심각할수록 시스템은 본질적으로 더 위험해진다는 주장임. Normal Accidents 위키 참고
    • 나는 두 문서를 다 완독하진 않았지만, 단지 시스템이 복잡하다고 해서 실패의 루트 원인을 규정할 수 없다는 주장에는 동의하지 않음. 스포츠에서도 득점은 여러 요인의 결과지만, 결국 ‘득점자’는 존재함. 넓은 시야는 좋지만, 핵심 원인을 짚는 것도 실용적임
    • 나는 온콜(oncall) 근무를 하는 계약자임. 대부분의 회사가 온콜을 진지하게 다루지 않음. 문서화도 부족하고, 다른 사람의 복잡한 코드를 읽을 시간도 주지 않음. AWS처럼 온콜을 학습과 책임의 일부로 여기는 문화를 꼭 경험해보고 싶음

  • 인터넷이 점점 집중화된 단일망(mononet) 으로 변하고 있음. 냉전 시절 분산 네트워크로 태어난 인터넷이 이제는 한 번의 배포 실수로 전 세계 은행·쇼핑·여행이 멈출 수 있는 구조가 됨. 클라우드 메타포는 이미 한계를 넘었음.
    스타트업이나 R&D에는 여전히 유용하지만, 성장 단계 기업이나 정부는 자체 서버·자체 클라우드·자체 핵심 서비스를 가져야 함. 기술과 인력은 충분히 있음

  • AWS의 포스트모템에서 정확한 타임라인 시각화가 인상적이었음. GDC의 전설적인 강연 “I Shot You First”처럼, 시간의 흐름을 기울어진 화살표로 표현하며 “지연이 어디서 발생했는가”를 묻는 방식이 유용했음.
    하지만 나를 더 놀라게 한 건, EC2 노드 리스 관리 서비스에 복구 절차(runbook) 가 없었다는 점임. AWS의 핵심 서비스라면 거의 모든 예외 상황이 대비되어 있을 줄 알았음

    • 이런 상황은 두려워할 게 아니라 복잡계의 본질적 패턴으로 인식해야 함. 잠재적 실패는 프랙탈처럼 존재하고, 모든 경우의 수에 대한 런북을 갖추는 건 불가능함

  • 이번 사건의 핵심은 DNS 시스템의 캐시 무효화(cache invalidation) 문제 변형 같음. 두 개의 DNS Enactor가 서로 다른 타이밍으로 계획(plan)을 적용하면서 레이스 컨디션이 발생했고, 오래된 계획이 새로운 계획을 덮어써 버림

    • 이건 대중용 설명일 뿐, 실제 내부에서는 사건 해결 후 재발 가능성 평가와 완화책(runbook) 작성이 이루어짐. 이후 조직 차원의 학습과 공유가 이어짐
    • 나는 이 레이스 컨디션 자체가 루트 원인이라고 봄. 그 버그만 없었어도 사건은 없었을 것임
    • DNS Planner와 Enactor를 왜 분리했는지 의문임. 하나의 서비스였다면 이런 경쟁 상태가 더 명확히 드러났을 것임. 마이크로서비스 남용이 복잡성을 키운 결과일 수도 있음
    • 비슷한 문제를 겪은 적이 있는데, 원인은 JVM GC 지연과 고장난 하드웨어였음. 이번에도 그런 가능성이 있음
    • 그런데 AWS는 이런 지연이 다시 발생했을 때의 예방책을 명시하지 않았음

  • Enactor가 새 값을 적용하기 전에 현재 레코드의 버전 비교(CAS) 를 했어야 함. 효율성은 떨어지더라도 기본적인 안전장치임. DynamoDB 자체에서 처리할 수 있었을 것임

  • DynamoDB가 지역별로 수십만 개의 DNS 레코드를 관리한다는 설명을 보고 놀랐음. dynamodb.us-east-1.amazonaws.com이 수십만 IP로 해석될 수 있다니, Route53의 한계를 넘는 수준 같음. 아마도 TTL을 낮게 두고 일부만 갱신하는 방식일 듯함

    • 실제로 AWS의 DNS는 그렇게 동작함. Route53은 리소스 레코드 세트(RRSet) 단위로 작동하고, 헬스체크나 지연 기반 선택 로직을 통해 적절한 세트를 반환함
    • CDN도 비슷하게 동작함. 시스템 메트릭을 수집해 네트워크별 최적 PoP을 계산함. bunny.net SmartEdge가 좋은 예시임
    • 나도 S3로 테스트해봤는데, 몇 초 만에 수백 개의 서로 다른 IP를 받았음. 단일 리전에서도 이런 다양성이 있음

  • 버그는 언제나 존재함. 형식 검증(formal verification) 은 어렵고, 낮은 확률의 버그는 수년 후에야 터지기도 함.
    그래서 시스템은 반드시 실패한다고 가정하고, 피해를 제한하는 구조를 설계해야 함. 셀 기반 아키텍처, 단계적 롤아웃, 격리된 존이 그 예임.
    AWS도 셀 기반을 시도하지만, 특히 us-east-1에는 레거시 교차 의존성이 남아 있음. 장기적으로는 리전을 완전히 독립적으로 설계해야 함.
    이런 작업은 고위 임원 지원이 없으면 진행되지 않지만, 주주 입장에서는 회사 존속 리스크를 줄이는 핵심 투자임

  • 보고서에서 UTC가 아닌 PT 타임존을 쓴 게 의외였음

    • “epoch fail?”이라는 농담이 나올 정도지만, 대부분의 고객이 미국 기반이라 PT가 더 직관적일 수 있음
    • 아마도 야간 대응의 어려움을 강조하려는 의도였을 수도 있음

  • per-endpoint 버전 관리나 2PC, 단일 writer lease 같은 패턴이 없다는 게 놀라웠음. 그래도 AWS가 이렇게 투명하게 공개한 건 높이 평가함

    • 실제로 DNS 변경 API는 CAS를 수행하지만, 여러 비동기 writer가 논리적 순서 없이 경쟁하면서 문제가 생김. zone serial이나 sentinel record를 이용해 순서를 직렬화했어야 함

  • 나는 이번 사건의 직접적 원인이 DynamoDB DNS 관리 시스템의 잠재적 레이스 컨디션이었다고 봄. 오래된 계획이 최신 계획을 덮어써 지역 엔드포인트의 DNS 레코드가 비어버림

    • 하지만 “루트 원인”이라는 개념에는 주의가 필요함. 이번은 메타안정적 붕괴(metastable collapse) 였고, 핵심 문제는 복구 절차(runbook)의 부재였음.
      참고: How Complex Systems Fail
답변달기