AWS DynamoDB 장애가 남긴 경고: 레이스 컨디션보다 무서운 설계의 빈틈

2025년 10월, 클라우드 세계의 심장부인 AWS US-EAST-1 리전이 멈췄습니다. EC2는 생성을 멈췄고 람다는 응답을 거부했습니다. 모든 도미노의 끝에는 DynamoDB가 있었습니다. AWS는 공식 보고서에서 이를 잠재적 레이스 컨디션이라 명명했습니다. 하지만 단순히 운이 나쁜 타이밍 문제였을까요. 시니어 엔지니어의 눈으로 보면 이 사건은 분산 시스템의 논리적 결함과 복구 메커니즘의 부재가 빚어낸 참사입니다.

복잡한 트래픽 분산 시스템의 민낯

DynamoDB는 고가용성을 위해 DNS 트리 구조와 가중치 기반 레코드를 사용합니다. 트래픽은 세 가지 핵심 컴포넌트에 의해 관리됩니다.

컴포넌트	역할	운영 방식
DNS Planner	트래픽 분산 비율 계산	지역 단위의 최적화 플랜 생성
DNS Enactor	Route 53 레코드 업데이트	3개 AZ에서 독립적으로 실행
DWFM	전체 워크플로우 조정	업데이트 전파 오케스트레이션

시스템은 특정 구간에 문제가 생기면 가중치()를 0으로 만들어 트래픽을 차단하도록 설계되었습니다. 이론은 완벽했지만 실제 운영에서는 예상치 못한 변수가 터졌습니다.

덮어쓰기와 삭제가 만난 최악의 시나리오

사건 당일 부하가 몰리며 Enactor 1의 처리가 늦어졌습니다. 그 사이 Enactor 2는 최신 버전인 플랜 102를 반영했습니다. 여기서 치명적인 연쇄 반응이 일어났습니다.

먼저 지연되었던 Enactor 1이 뒤늦게 깨어나 과거의 데이터인 플랜 100을 최신 정보 위에 덮어썼습니다. 이어지는 클린업 단계에서 Enactor 2는 현재 기준인 플랜 102에 포함되지 않은 낡은 레코드를 삭제하기 시작했습니다. Enactor 1이 방금 살려놓은 데이터는 Enactor 2의 시각에서 삭제 대상일 뿐이었습니다. 결국 DynamoDB의 메인 엔드포인트 DNS 레코드가 증발했습니다.

진짜 문제는 복구 로직의 부재였다

대부분은 여기서 분석을 멈춥니다. 타이밍이 꼬여서 데이터가 지워졌다고 결론짓습니다. 하지만 핵심은 왜 시스템이 비어 있는 레코드를 보고도 스스로 일어서지 못했는가에 있습니다.

엔드포인트가 사라지자 복구를 담당해야 할 시스템들이 줄지어 런타임 예외를 일으켰습니다. Enactor 코드는 레코드가 존재하지 않는 상태를 가정하지 않았습니다. 메모리 관리 오류인 Use-after-free처럼 이미 사라진 대상을 참조하며 시스템이 붕괴되었습니다.

자동화된 롤백 로직은 상황을 더 악화시켰습니다. 복구의 기준이 되는 데이터베이스 자체가 오염된 상태였기 때문입니다. 시스템은 무한 루프에 빠졌고 자동화는 시스템을 고치는 도구가 아닌 파괴하는 무기가 되었습니다.

공식 보고서 너머의 교훈

AWS는 속도 제한 기능을 도입하겠다고 밝혔습니다. 이는 증상을 완화할 뿐 근본적인 처방은 아닙니다. 시스템이 비정상 상태를 인지하고 스스로 치유하는 능력을 갖추지 못한다면 같은 비극은 반복됩니다.

구분	공식 설명	시니어의 통찰
장애 원인	동시 업데이트 충돌	쓰기 시점의 유효성 검증(CAS) 부재
장애 현상	자동화 가동 중단	안전 실패(Safe Default) 설계 미비
대응 방안	업데이트 속도 제한	복구 로직의 멱등성 확보

품위 있게 무너지는 시스템을 설계하라

2025년의 이 사건은 코드 한 줄의 무게를 증명합니다. 수십억 달러 규모의 인프라를 무너뜨린 것은 거창한 해킹이 아니었습니다. 텅 빈 DNS 레코드를 마주했을 때 어떻게 행동할지 정의하지 않은 작은 예외 처리 미흡이 원인이었습니다.

엔지니어링의 정수는 복잡한 기능을 만드는 것이 아닙니다. 예기치 못한 실패 상황에서 품위 있게 무너지고 확실하게 복구되도록 설계하는 능력입니다.

안정성을 위한 필수 체크리스트

• 롤백 검증: 참조할 데이터가 없을 때 시스템이 안전한 기본값으로 동작하는가.
• 원자성 보장: 확인(Check)과 사용(Use) 사이의 간극을 CAS 등으로 보호했는가.
• 의존성 관리: 핵심 DB 연결이 끊겨도 최소한의 기능을 유지하는 전략이 있는가.

진정한 전문가는 시스템이 어떻게 터졌는가를 넘어 왜 복구되지 않았는지를 집요하게 묻는 사람입니다. 당신의 시스템은 지금 안전하게 실패할 준비가 되었습니까.