2025년 10월, 전 세계 수많은 서비스가 멈추는 초유의 AWS 장애 사태가 발생했어요. 무려 15시간 넘게 이어진 이번 클라우드 서비스 장애는 단순한 기술 문제를 넘어, 우리 삶 깊숙이 파고든 클라우드 의존성의 민낯을 보여주었는데요. 이번 사태의 원인과 우리가 얻을 수 있는 중요한 교훈들을 함께 살펴보겠습니다.
AWS 장애, 무엇이 문제였을까요?
이번 AWS 장애의 근본 원인은 DynamoDB DNS 관리 시스템의 소프트웨어 버그 때문이었다고 해요. 이 시스템은 로드 밸런서의 안정성을 모니터링하며, AWS 네트워크 내 엔드포인트에 대한 새로운 DNS 구성을 주기적으로 생성하는 역할을 하는데요. 여기서 ‘경쟁 조건(race condition)’이라는 오류가 발생했습니다.
경쟁 조건은 프로세스가 가변적인 이벤트의 타이밍이나 순서에 따라 달라질 때 발생하는 오류인데요. DNS Enactor와 DNS Planner라는 두 가지 DynamoDB 구성 요소의 타이밍이 어긋나면서 문제가 커졌습니다. 오래된 계획이 최신 계획을 덮어쓰고, 그 오래된 계획마저 삭제되면서, 지역 엔드포인트의 모든 IP 주소가 제거되는 최악의 상황이 발생한 거죠. 결국 이 하나의 문제로 전체 DynamoDB 시스템이 마비되었답니다.
단일 장애점이 부른 연쇄 마비
DynamoDB 장애는 Amazon의 US-East-1 지역 엔드포인트에 의존하는 시스템에 치명적인 영향을 미쳤습니다. 이 지역은 AWS에서 가장 오래되고 많이 사용되는 허브 중 하나인데요. 특정 지역에 대한 집중도가 높다 보니, 이곳의 문제가 전 세계적으로 파급력을 가지게 된 거예요.
DynamoDB 복구 이후에도 US-East-1 지역의 EC2 서비스에 과부하가 발생했고, 네트워크 로드 밸런서에도 문제가 이어지면서 AWS 고객들은 지속적인 연결 오류를 겪었습니다. Redshift 클러스터 생성, Lambda 호출, Fargate 작업 시작 등 다양한 AWS 네트워크 기능들이 영향을 받았고, 이는 고객 서비스 마비로까지 이어졌습니다.
클라우드 시대의 ‘블랙아웃’ 경험
이번 사태는 클라우드 서비스를 이용하는 모든 기업에게 중요한 경고등을 켰어요. 단일 장애점이 네트워크 설계에서 얼마나 위험한지 여실히 보여주는 사례가 되었죠. 네트워크 정보 회사 Ookla는 “실패를 완전히 막는 것보다는, 실패를 제어하는 것이 중요하다”고 강조했어요.
특히 US-East-1 지역에 대한 과도한 의존성과 해당 지역을 우회할 수 없는 점이 문제로 지적되었는데요. 이는 멀티 리전 설계, 종속성 다양화, 그리고 체계적인 사고 대비의 중요성을 다시 한번 일깨워주는 교훈이 된답니다. 우리도 사용하는 클라우드 서비스의 복원력을 미리 확인해야겠죠?
미래 클라우드 서비스의 나아갈 길
Amazon은 이번 AWS 장애 사태 이후, 문제의 원인이 된 DynamoDB DNS Planner와 Enactor 자동화 기능을 전 세계적으로 비활성화하고, 경쟁 조건을 해결하기 위한 작업에 착수했습니다. 또한, EC2와 네트워크 로드 밸런서에도 개선 작업을 진행하고 있다고 해요.
이번 사태는 클라우드 서비스가 국가 및 경제 복원력의 시스템적 구성 요소로 다루어져야 한다는 인식을 심어주었습니다. 앞으로는 단순한 버그 예방을 넘어, 네트워크 설계 자체에서 단일 장애점을 제거하고, 분산된 시스템을 통해 안정성을 확보하는 것이 클라우드 서비스의 핵심 과제가 될 거예요. 우리 모두의 삶과 밀접한 클라우드 서비스가 더욱 안전해지길 기대합니다.