Incident Library

IL-0534 Amazon Web Services · 2017-02-28awsdatabase

US-EAST-1 의 Amazon S3 가 몇 시간 동안 요청을 처리하지 못했고 S3 에 기대는 AWS 서비스도 함께 멈췄다

2017-02-28 오전 Amazon S3 팀은 S3 청구 시스템이 예상보다 느리게 진행되는 문제를 디버깅하고 있었다. PST 오전 9:37 에 권한이 있는 S3 팀원이 정해진 플레이북에 따라 청구 과정이 쓰는 S3 하위 시스템의 서버 몇 대를 빼는 명령을 실행했다. 명령의 입력 하나가 잘못 들어가 의도보다 많은 서버가 빠졌다. 빠진 서버들은 다른 S3 하위 시스템 두 개를 받치고 있었다. 인덱스 하위 시스템은 리전의 모든 S3 객체의 메타데이터와 위치 정보를 관리하며 모든 GET, LIST, PUT, DELETE 요청에 필요하다. 배치 하위 시스템은 PUT 요청에서 새 객체의 저장 공간을 할당하며, 인덱스 하위 시스템이 정상이어야 동작한다. 용량의 큰 부분이 빠지자 두 하위 시스템 모두 전체 재시작이 필요했고, 재시작하는 동안 S3 는 요청을 처리하지 못했다. S3 콘솔, 새 EC2 인스턴스 시작, S3 스냅샷이 필요한 EBS 볼륨, Lambda 처럼 S3 에 기대는 US-EAST-1 의 다른 서비스도 함께 영향을 받았다.

S3 하위 시스템은 큰 용량이 빠지거나 실패해도 고객 영향이 거의 없도록 설계돼 있었다. 하지만 큰 리전에서 인덱스 하위 시스템과 배치 하위 시스템을 완전히 재시작한 것은 여러 해 만이었다. 그사이 S3 가 크게 자라서, 서비스를 다시 띄우고 메타데이터 무결성을 확인하는 안전 점검을 돌리는 데 예상보다 오래 걸렸다. AWS 는 인덱스 하위 시스템을 먼저 재시작해 PST 오후 12:26 에 GET, LIST, DELETE 요청을 처리하기 시작했고, 오후 1:18 에 완전히 회복했다. 배치 하위 시스템은 인덱스 하위 시스템이 동작하자 회복을 시작해 오후 1:54 에 마쳤고, 이때 S3 가 정상으로 돌아왔다. 다른 서비스 일부는 밀린 작업을 처리하느라 더 오래 걸렸다.

장애 시작부터 오전 11:37 까지는 AWS Service Health Dashboard 의 관리 콘솔이 S3 에 기대고 있어서 서비스별 상태를 갱신하지 못했다. AWS 는 용량을 빼는 도구가 너무 많은 용량을 너무 빨리 뺄 수 있었다고 밝혔다.

심각도
–
영향 범위
All Amazon S3 requests in the region, and AWS services that rely on S3 for storage, including the S3 console, new EC2 instance launches, EBS volumes needing data from S3 snapshots, AWS Lambda and the AWS Service Health Dashboard
영향 사용자
–
지역
Northern Virginia (US-EAST-1)
감지까지
–
복구까지
4h 17m

증상

2017-02-28 오전 Northern Virginia 의 US-EAST-1 리전에서 Amazon S3 가 요청을 처리하지 못했다. GET, LIST, PUT, DELETE 요청이 모두 실패했다.

S3 에 데이터를 저장하는 같은 리전의 다른 AWS 서비스도 S3 API 를 쓸 수 없는 동안 영향을 받았다. S3 콘솔, 새 Amazon EC2 인스턴스 시작, S3 스냅샷에서 데이터가 필요한 Amazon EBS 볼륨, AWS Lambda 가 여기에 들었다.

AWS Service Health Dashboard 의 관리 콘솔도 S3 에 기대고 있어서, 장애 시작부터 PST 오전 11:37 까지 서비스별 상태를 갱신할 수 없었다. 그동안 AWS 는 공식 트위터와 대시보드 배너 문구로 상황을 알렸다.

회복은 단계적이었다. PST 오후 12:26 에 GET, LIST, DELETE 요청부터 처리되기 시작했고, 오후 1:18 에 이 세 API 가 정상으로 돌아왔다. PUT 은 오후 1:54 에 정상이 됐다. 다른 AWS 서비스 일부는 장애 동안 밀린 작업이 있어 완전히 회복하는 데 시간이 더 걸렸다.

증상 서비스 중단

원인

원인 운영 실수

구성 요소 오브젝트 스토리지클라우드 블록 스토리지서버리스 함수 플랫폼
기여 요인 파괴적 변경 보호 장치 부재과도한 영향 범위순환 의존
촉발
S3 팀원 한 명이 S3 청구 시스템이 예상보다 느린 문제를 디버깅하고 있었다. 이 팀원은 PST 오전 9:37 에 정해진 플레이북대로 청구 과정이 쓰는 하위 시스템의 서버 몇 대를 빼는 명령을 실행했다. 명령의 입력 하나가 잘못 들어가 의도보다 훨씬 많은 서버가 빠졌다.

감지

–

조치

후속 조치

교훈

–

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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