나는 이 주제에 대해 늘 같은 말을 반복하는 사람임. 아직 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) 단위로 작동하고, 헬스체크나 지연 기반 선택 로직을 통해 적절한 세트를 반환함
나도 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
Hacker News 의견
나는 이 주제에 대해 늘 같은 말을 반복하는 사람임. 아직 Richard Cook의 글을 읽지 않았다면, 지금 이 포스트모템을 멈추고 먼저 How Complex Systems Fail을 읽어보길 권함. 이 글은 복잡한 시스템 실패를 다룬 최고의 기술 글 중 하나임. Cook은 “루트 원인(root cause)”이라는 개념 자체를 거부하는데, 이번 사건에서도 그가 옳다고 생각함
인터넷이 점점 집중화된 단일망(mononet) 으로 변하고 있음. 냉전 시절 분산 네트워크로 태어난 인터넷이 이제는 한 번의 배포 실수로 전 세계 은행·쇼핑·여행이 멈출 수 있는 구조가 됨. 클라우드 메타포는 이미 한계를 넘었음.
스타트업이나 R&D에는 여전히 유용하지만, 성장 단계 기업이나 정부는 자체 서버·자체 클라우드·자체 핵심 서비스를 가져야 함. 기술과 인력은 충분히 있음
AWS의 포스트모템에서 정확한 타임라인 시각화가 인상적이었음. GDC의 전설적인 강연 “I Shot You First”처럼, 시간의 흐름을 기울어진 화살표로 표현하며 “지연이 어디서 발생했는가”를 묻는 방식이 유용했음.
하지만 나를 더 놀라게 한 건, EC2 노드 리스 관리 서비스에 복구 절차(runbook) 가 없었다는 점임. AWS의 핵심 서비스라면 거의 모든 예외 상황이 대비되어 있을 줄 알았음
이번 사건의 핵심은 DNS 시스템의 캐시 무효화(cache invalidation) 문제 변형 같음. 두 개의 DNS Enactor가 서로 다른 타이밍으로 계획(plan)을 적용하면서 레이스 컨디션이 발생했고, 오래된 계획이 새로운 계획을 덮어써 버림
Enactor가 새 값을 적용하기 전에 현재 레코드의 버전 비교(CAS) 를 했어야 함. 효율성은 떨어지더라도 기본적인 안전장치임. DynamoDB 자체에서 처리할 수 있었을 것임
DynamoDB가 지역별로 수십만 개의 DNS 레코드를 관리한다는 설명을 보고 놀랐음.
dynamodb.us-east-1.amazonaws.com이 수십만 IP로 해석될 수 있다니, Route53의 한계를 넘는 수준 같음. 아마도 TTL을 낮게 두고 일부만 갱신하는 방식일 듯함버그는 언제나 존재함. 형식 검증(formal verification) 은 어렵고, 낮은 확률의 버그는 수년 후에야 터지기도 함.
그래서 시스템은 반드시 실패한다고 가정하고, 피해를 제한하는 구조를 설계해야 함. 셀 기반 아키텍처, 단계적 롤아웃, 격리된 존이 그 예임.
AWS도 셀 기반을 시도하지만, 특히 us-east-1에는 레거시 교차 의존성이 남아 있음. 장기적으로는 리전을 완전히 독립적으로 설계해야 함.
이런 작업은 고위 임원 지원이 없으면 진행되지 않지만, 주주 입장에서는 회사 존속 리스크를 줄이는 핵심 투자임
보고서에서 UTC가 아닌 PT 타임존을 쓴 게 의외였음
per-endpoint 버전 관리나 2PC, 단일 writer lease 같은 패턴이 없다는 게 놀라웠음. 그래도 AWS가 이렇게 투명하게 공개한 건 높이 평가함
나는 이번 사건의 직접적 원인이 DynamoDB DNS 관리 시스템의 잠재적 레이스 컨디션이었다고 봄. 오래된 계획이 최신 계획을 덮어써 지역 엔드포인트의 DNS 레코드가 비어버림
참고: How Complex Systems Fail