Incident Library

IL-0337 Amazon Web Services · 2011-04-21awsnetworking

US East 리전 한 가용 영역에서 네트워크 변경으로 EBS 노드가 복제본과 끊겨 EBS 볼륨이 멈췄다

EBS 클러스터는 가용 영역 하나 안에서 돌고, 클러스터의 EBS 노드들이 볼륨 데이터의 복제본을 나눠 저장한다. 노드들은 대역폭이 큰 주 네트워크와 용량이 작은 보조 복제 네트워크로 서로 이어진다. 노드는 복제 상대와 연결이 끊기면 상대가 죽었다고 보고 빈 공간이 있는 새 노드를 찾아 데이터를 다시 복제하는데, AWS 는 이를 재미러링이라고 부른다. 2011년 4월 21일 오전 12시 47분 PDT, 주 네트워크 용량 증설 중 트래픽 전환을 잘못 해 트래픽이 보조 네트워크로 몰렸다. 클러스터 일부의 노드는 두 네트워크를 다 잃고 서로 완전히 고립됐다. 잘못된 전환을 되돌려 연결이 돌아오자 많은 노드가 한꺼번에 재미러링할 공간을 찾았다. 클러스터의 여유 용량은 금세 바닥났고, 노드들은 빈 공간을 계속 찾는 루프에 갇혔다. 공간을 찾지 못한 노드는 충분히 백오프하지 않고 계속 다시 찾았다. EBS 노드에는 많은 복제 요청을 한꺼번에 닫을 때 노드를 죽이는 경쟁 조건 버그가 있었다. 평소에는 아주 드물게 나타나던 이 버그가 이때는 자주 터져 stuck 볼륨이 더 늘었다.

망가진 클러스터는 리전마다 한 벌씩 있는 EBS 컨트롤 플레인까지 끌어내렸다. create volume API 의 긴 타임아웃 때문에 쌓인 호출이 스레드를 다 써서 다른 가용 영역의 API 도 실패했다. 오전 2시 40분에 영향받은 가용 영역의 새 Create Volume 요청을 막자 2시 50분에 API 가 회복했다. 5시 30분쯤에는 복제본 협상 호출이 불어나 리전 전체의 API 가 다시 나빠졌고, 팀은 8시 20분부터 망가진 클러스터와 컨트롤 플레인 사이의 통신을 끊었다. 11시 30분에 노드들이 빈 공간도 없는 다른 서버에 헛되이 연락하지 못하게 바꾸자 클러스터는 더 나빠지지 않았다. 낮 12시 04분에는 장애가 그 가용 영역 안에 갇혔다.

남은 약 13% 의 stuck 볼륨을 살리려면 저장 용량이 더 있어야 했다. 실패한 노드는 데이터를 다 살릴 때까지 다시 쓰지 않았으므로, US East 리전 곳곳의 여유 서버를 물리적으로 옮겨 설치해야 했다. 노드 사이 통신을 줄여 둔 탓에 새 용량을 클러스터에 붙이는 데도 시간이 걸렸다. 4월 22일 오전 2시쯤 새 용량이 들어가기 시작해 낮 12시 30분까지 약 2.2% 를 뺀 볼륨이 복구됐다. 4월 23일에는 그 가용 영역 전용으로 떼어 둔 EBS 컨트롤 플레인과 더 세밀한 스로틀로 밀린 상태 변경을 처리했다. 오후 6시 15분에 그 가용 영역의 EBS API 접근이 돌아왔다. 남은 2.2% 는 장애 초반에 떠 둔 S3 스냅샷으로 복구해, 4월 24일 낮 12시 30분에는 1.04% 만 남았다. 끝내 0.07% 는 일관된 상태로 복구하지 못했다. RDS 에서는 그 가용 영역 single-AZ 인스턴스의 0.4% 가 EBS 볼륨을 되살리지 못했고, multi-AZ 인스턴스 2.5% 는 그전까지 만난 적 없는 버그 때문에 자동 장애 전환을 하지 못해 사람이 개입해야 했다.

심각도
–
영향 범위
EBS volumes in one Availability Zone (about 13% stuck, 0.07% not restorable in a consistent state) and the EC2 instances using them; EBS APIs and launches of EBS-backed EC2 instances across the Region; RDS single-AZ instances in the zone (peak 45% stuck) and 2.5% of multi-AZ instances in the Region that did not fail over
영향 사용자
–
지역
US East Region, one Availability Zone
감지까지
–
복구까지
–

증상

2011년 4월 21일 오전 12시 47분 PDT, US East 리전의 한 가용 영역에서 EBS 볼륨 일부가 읽기와 쓰기를 처리하지 못하게 됐고, 그 볼륨을 쓰던 EC2 인스턴스도 읽거나 쓰려다 함께 멈췄다. 리전 전체에서 EBS API 의 오류율과 지연도 높아졌다.

AWS 는 이 상태의 볼륨을 "stuck" 볼륨이라고 불렀다. 재미러링은 노드가 복제 상대를 잃은 뒤 새 노드를 찾아 데이터를 다시 복제하는 일이다. 재미러링 중인 볼륨은 새 primary 복제본이 정해질 때까지 접근이 막히기 때문에, 그 볼륨에 I/O 를 하던 EC2 인스턴스에서는 볼륨이 멈춘 것으로 보였다. 영향받은 가용 영역 볼륨의 약 13% 가 이 상태가 됐다.

클러스터의 여유 용량이 바닥나자 클러스터는 "create volume" API 요청을 처리하지 못했다. 이 API 의 타임아웃이 길어 느린 호출이 쌓였고, EBS 컨트롤 플레인이 리전 전체에서 함께 쓰는 스레드 풀이 바닥나 다른 가용 영역의 API 요청까지 실패했다. 첫 번째 API 장애는 오전 12시 50분부터 2시 40분까지 이어졌다.

오전 5시 30분쯤 리전 전체에서 EBS API 의 오류율과 지연이 다시 올랐다. EBS 노드가 계속 죽으면서, 어떤 복제본을 primary 로 삼을지 EBS 컨트롤 플레인과 협상하는 호출이 재시도와 새 요청으로 불어났다. 그 부하에 눌린 컨트롤 플레인은 제대로 응답하지 못했다.

영향받지 않은 가용 영역에서도 EBS 기반 EC2 인스턴스를 새로 띄우면 장애 시작부터 정오 PDT 까지 약 11시간 동안 오류율과 지연이 크게 높았다. 새 인스턴스를 볼륨에 붙일 때만 쓰는 EBS 컨트롤 플레인 API 하나가 원인이었다. 처음에는 알람이 이 API 를 따로 구분할 만큼 세밀하지 않아, 인스턴스 실행 오류가 망가진 클러스터에서 나온 일반 오류에 가려졌다.

RDS 는 데이터베이스와 로그를 EBS 에 저장하기 때문에 영향받은 가용 영역의 RDS 데이터베이스 일부에 접속할 수 없었다. 그 가용 영역의 single-AZ 인스턴스 가운데 45% 가 한때 I/O 가 멈춘 상태였고, 리전의 multi-AZ 인스턴스 중 2.5% 는 I/O 가 멈춘 뒤에도 보조 복제본으로 자동 장애 전환을 하지 않았다.

목요일에 일부 고객은 영향받은 가용 영역이 아닌 곳에서도 stuck 볼륨이 생겼다고 알렸다. 다른 가용 영역의 stuck 볼륨 비율은 가장 높을 때도 0.07% 미만이었다. 이 볼륨들은 EBS 컨트롤 플레인의 지연과 오류 때문에 평소 늘 일어나는 재미러링의 복구가 늦어져 생겼다. 컨트롤 플레인이 나빠진 동안 고객은 다른 정상 가용 영역에서 볼륨이나 EBS 로 부팅하는 EC2 인스턴스를 새로 만들어 바꾸기 어려웠다.

증상 스토리지 연결 끊김네트워크 도달 불가컨트롤 플레인 지연오류율 상승장애 조치 실패데이터 유실

원인

원인 운영 실수

구성 요소 클라우드 블록 스토리지데이터베이스
기여 요인 자동화 증폭재시도 폭주여유 용량 부재과도한 영향 범위잡음에 묻힌 신호
촉발
US East 리전의 한 가용 영역에서 주 EBS 네트워크의 용량을 올리는 작업 중, 이중화된 라우터 하나에서 트래픽을 빼는 단계를 잘못 실행했다. 트래픽은 주 네트워크의 다른 라우터가 아니라 용량이 작은 보조 EBS 네트워크로 갔다.

감지

–

조치

후속 조치

교훈

AWS 는 이 사고를 촉발한 것은 네트워크 설정 변경이었지만, 앞으로의 일은 비슷한 실패가 나도 EBS 가 견디게 만드는 데 둔다고 했다. 여유 용량이 더 있었다면 망가진 클러스터가 재미러링 요청을 빨리 흡수해 폭주를 피했을 것이라고 봤다. 가용 영역들을 완전히 독립된 것처럼 만들려면 더 투자해야 한다는 것을 이 사고로 배웠다고 했다. 장애 중에 고객이 영향받은 자원을 다른 정상 가용 영역에서 바꾸기 어려웠던 일이 다시 일어나지 않게 하는 것을 최우선으로 꼽았다. 여러 가용 영역에 걸친 배포를 쉽게 설계하고 운영하도록 고객을 돕는 일도 더 잘해야 한다고 했다. 여러 종류의 볼륨 복구에 쓴 방식을 자동화해 두었다면 복구 시간을 크게 줄였을 것이라고 했다. 장애 중 고객 소통은 더 자주, 더 많은 정보를 담아야 한다고 봤다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 클라우드 블록 스토리지, 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.