난리남 : aws 장애발생

들어가며

글을 시작하기에 앞서 다시 월욜부터 새로운 회사로의 출근전에 강화를 번개로 다녀왔는데요

좋더라고요

컴퓨터와 잠시 떨어진 여유 굿

 

 

그리고 이건 요즘 꽂힌 입춘이란 노랜데요 가사가 진짜 좋고 와닿더라고요

개발만 하지마시고 이런 감성도 가끔 주입하시길

 

https://youtu.be/niazCi1AqqA?si=jdyYeJN1WOjGmixe

 

 

 

.

.

.

.

.

.

 

 

 

본론

 

2025년 10월 20일 , 캔바에서 오류가 뜨고, 배틀그라운드(PUBG)에 접속하려던 이용자들도 지연과 접속 실패를 겪었고, 삼성닷컴에서도 일시적인 접속 문제가 있었다. 해외에서는 줌, 로블록스, 스냅챗, 디즈니+, 코인베이스 같은 대형 서비스들이 동시에 휘청였다.

 

21세기 히트작인 aws 요놈이 문제였다.

 

출발점 : 다이나모DB(DynamoDB)

이번 사고는 AWS 안에서 다이나모DB(DynamoDB)를 가리키는 DNS가 잘못된 데서 시작됐다.

다이나모DB 엔드포인트 주소를 자동으로 갱신하는 시스템이 돌아가는데, 이 자동화 시스템 안에서 두 개의 구성요소가 타이밍이 엇갈리는 바람에 원래 존재해야 할 DNS 레코드가 비어버리는 상황이 생겼다.

쉽게 말하면 다이나모DB가 어디 있는지 알려주는 전화번호부가 순간적으로 사라진 셈이다.

요청이 오지만 route 53는 뭔지 모름,,

 

때문에 그 시간대에 다이나모 DB에 접근하던 서비스들이 일제히 “대상을 찾을 수 없다”는 실패를하기 시작했다.

 

 

왜 이게 그렇게 크게 번졌나

여기서부터가 이번 장애를 이해하는 핵심이다. 다이나모DB에 접근 하지못하자 문제가 난 건 최종 사용자용 서비스가 아니라 AWS 내부의 제어·상태 관리 계층이었다.

이 계층들은 EC2 인스턴스가 지금 어떤 상태인지(실행 중인지, 중지 중인지, 재시작 중인지), 로드밸런서 타깃이 살아 있는지와 같은 메타데이터를 다이나모DB 테이블에 저장해두고 있었다.

 

EC2가 막힌 이유

EC2는 새 인스턴스를 띄울 때 “대여 가능한 컴퓨터 목록”, 즉 이 리전에서 지금 붙여줄 수 있는 호스트/용량 목록을 먼저 본다.

문제는 이 리스트가 다이나모DB에 올라가 있었는데, 다이나모DB를 못 쓰니까 “새 인스턴스를 어디에 올릴지”를 결정을 못 한 거다.

그래서 콘솔에서는 pending처럼 보이거나 아예 생성이 실패한 것처럼 보였다.  

AWS는 이를 해결하기 위해 DNS를 수동으로 다시 넣어서 해결했다고 한다.

 

해결한줄 알았으나..

 

다이나모가 살아나자 백로그가 한꺼번에 ...

다이나모DB 접근이 살아났을 때, 문제가 끝난 게 아니라 여기서부터 트래픽이 한 번에 튀어올랐다.

이유는 다이나모가 안 되는 동안

• 새 EC2 만들기
• 상태값 갱신
• 헬스 체크 결과 쓰기
• 람다 메타데이터 저장

같은 작업이 전부 실패하거나 대기열에만 쌓여 있었기 때문이었다.

다이나모가 다시 작동하자 이 요청들이 한꺼번에 다시 시도됐다. 

DWFM 계층이 막힌 부분

이 밀려 있던 요청을 받아서 처리하는 내부 워크플로 계층(DWFM처럼 동작하는 작업 처리 레이어)이 여기서 과부하에 걸렸다.

평소에는 초당으로 찔끔찔끔 오던 EC2/상태/구성 관련 요청을 한꺼번에 받아버리니까 이 레이어가 먼저 병목이 났다.

그래서 AWS가 다이나모를 살렸는데도 일부 콘솔이나 EC2 작업이 바로 안 풀리고, 내부 작업 처리 계층을 다시 정리한 다음에야 순차적으로 풀렸다.

 

다시 EC2로 역전파

DWFM 레이어를 살려놓으니까 이번에는 EC2가 네트워크 설정을 저장해두는 쪽으로 트래픽이 몰렸다.

EC2 인스턴스를 올릴 때는 단순히 “하나 올렸다”로 끝나는 게 아니라, ENI(네트워크 인터페이스), 보안그룹, 서브넷, 라우팅, 헬스 관련 메타데이터를 또 저장해야 한다. 앞에서 못 쓰던 게 한꺼번에 쓰이면서 이 구간에서도 장애·지연이 다시 발생했다.

 

로드밸런서(NLB/ALB)로 전파

로드밸런서는 주기적으로 타깃 헬스 체크를 해서 이 타깃은 살아 있음, 이 타깃은 잠깐 빼라 같은 상태를 저장해 둔다. 이 헬스 정보 역시 중앙에서 관리하는 상태 테이블에 적재되는데, 이게 다이나모DB에 올라가 있는 경우에는 헬스 체크 결과를 제때 쓸 수 없어서 헬스가 최신 상태로 유지가 안 된다. 헬스가 안 맞으면 로드밸런서는 안전하게 가려고 타깃을 뺀다든지 요청을 드롭하는 쪽으로 기운다. 그래서 실제 애플리케이션은 멀쩡히 떠 있는데도 요청이 LB 단계에서 떨어지는 이상한 증상이 일부에서 나타났을 수 있다.

 

람다

람다는 함수 코드나 함수 버전에 대한 메타정보를 저장하고 읽는 과정에 다이나모DB를 썼다.

때문에 다이나모에 접속하지 못하는 동안에는 실행이 실패하거나 호출이 지연됐다. 다이나모가 살아난 뒤에는 람다가 다시 이 메타정보를 읽으면서 요청을 처리하기 시작했는데, 그동안 람다 호출이 실패해서 뒤로 밀려 있던 것들이 SQS 같은 큐에 쌓여 있었고, 이걸 하나씩 빼서 처리하는 데 시간이 걸렸다. 

 

ECS/EKS

ECS나 EKS는 결국 밑단에서 EC2 리소스를 써서 클러스터를 구성하는 경우가 많다. EC2 컨트롤 플레인이 막혀 있던 동안에는 이쪽도 신규 태스크/파드 할당이 안 되거나 느려졌고, 이미 떠 있던 것들도 헬스나 상태 갱신이 밀려서 장애처럼 보였다.

 

 

연쇄 장애 정리

 

1단계: DNS 자동화가 다이나모DB 엔드포인트 레코드를 비움
2단계: 다이나모DB에 붙던 내부 상태/제어 계층이 일제히 실패
3단계: 이 계층을 쓰던 EC2, 로드밸런서, 람다, 모니터링이 순차적으로 비정상
4단계: AWS가 DNS 레코드를 수동으로 다시 넣어서 다이나모를 살림
5단계: 죽어 있던 동안 쌓여 있던 요청이 한꺼번에 들어와서 DWFM 계층이 먼저 막힘
6단계: DWFM을 살렸더니 이번엔 EC2 네트워크/구성 저장 쪽으로 몰려서 또 짧은 장애
7단계: 람다가 다시 돌면서 SQS에 있던 람다 관련 백로그를 하나씩 털어내서 체감이 끝까지 길어짐

 

이번 사고가 남긴 교훈

작은 제어 계층의 오류도 다중 의존성을 타면 인터넷 전체 문제처럼 보일 수 있다는 게 확인됐다. DNS 레코드 하나가 잘못됐을 뿐인데 실제로는 EC2, 로드밸런서, 람다, 모니터링, 그리고 그 위 고객 워크로드까지 차례로 흔들렸다.

그리고 AWS 도 생각보다 하나의 서비스에 의존하고있다는점을 알 수 있었다.