{"id":"IL-0534","org":"Amazon Web Services","date":"2017-02-28","docs":[],"title":{"en":"Amazon S3 in US-EAST-1 could not serve GET, LIST, PUT or DELETE requests for hours while its index subsystem restarted","ko":"US-EAST-1 의 Amazon S3 가 몇 시간 동안 요청을 처리하지 못했고 S3 에 기대는 AWS 서비스도 함께 멈췄다"},"domain":["aws","database"],"impact":{"scope":"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","users":"unknown","region":"Northern Virginia (US-EAST-1)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://aws.amazon.com/message/41926/","kind":"official-status","archived":"https://web.archive.org/web/20261017051320/https://aws.amazon.com/message/41926/"}],"summary":{"en":"On the morning of February 28th, 2017 the S3 team was debugging why the S3 billing system was progressing more slowly than expected. At 9:37AM PST a team member ran a command from an established playbook to remove a small number of servers from one S3 subsystem used by billing, but one input was entered incorrectly and a larger set of servers was removed than intended. Those servers supported two other subsystems. The index subsystem manages the metadata and location of every S3 object in the region and is needed for all GET, LIST, PUT and DELETE requests; the placement subsystem allocates storage for new objects during PUT requests and needs a working index subsystem. Losing a large part of their capacity forced both subsystems into a full restart, and S3 could not serve requests until it finished. Other AWS services in US-EAST-1 that rely on S3 for storage were impaired while the S3 APIs were down.\n\nS3 subsystems are built to lose large amounts of capacity with little customer impact, and removing capacity is a routine operation, but the index and placement subsystems had not been fully restarted in the larger regions for many years. S3 had grown a great deal, so restarting them and running the safety checks that validate the integrity of the metadata took longer than expected. The index subsystem could serve GET, LIST and DELETE requests at 12:26PM PST and was fully recovered at 1:18PM PST; the placement subsystem then recovered by 1:54PM PST, when S3 was operating normally. The tool used for the removal had allowed too much capacity to be taken away too quickly. The SHD administration console also depended on S3, so service status could not be updated on the dashboard until 11:37AM PST.","ko":"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 의 다른 서비스도 함께 영향을 받았다.\n\nS3 하위 시스템은 큰 용량이 빠지거나 실패해도 고객 영향이 거의 없도록 설계돼 있었다. 하지만 큰 리전에서 인덱스 하위 시스템과 배치 하위 시스템을 완전히 재시작한 것은 여러 해 만이었다. 그사이 S3 가 크게 자라서, 서비스를 다시 띄우고 메타데이터 무결성을 확인하는 안전 점검을 돌리는 데 예상보다 오래 걸렸다. AWS 는 인덱스 하위 시스템을 먼저 재시작해 PST 오후 12:26 에 GET, LIST, DELETE 요청을 처리하기 시작했고, 오후 1:18 에 완전히 회복했다. 배치 하위 시스템은 인덱스 하위 시스템이 동작하자 회복을 시작해 오후 1:54 에 마쳤고, 이때 S3 가 정상으로 돌아왔다. 다른 서비스 일부는 밀린 작업을 처리하느라 더 오래 걸렸다.\n\n장애 시작부터 오전 11:37 까지는 AWS Service Health Dashboard 의 관리 콘솔이 S3 에 기대고 있어서 서비스별 상태를 갱신하지 못했다. AWS 는 용량을 빼는 도구가 너무 많은 용량을 너무 빨리 뺄 수 있었다고 밝혔다."},"trigger":{"en":"While debugging an S3 billing system that was progressing more slowly than expected, an authorized S3 team member followed an established playbook to remove a small number of servers from one S3 subsystem used by the billing process, and entered one input of the command incorrectly.","ko":"S3 팀원 한 명이 S3 청구 시스템이 예상보다 느린 문제를 디버깅하고 있었다. 이 팀원은 PST 오전 9:37 에 정해진 플레이북대로 청구 과정이 쓰는 하위 시스템의 서버 몇 대를 빼는 명령을 실행했다. 명령의 입력 하나가 잘못 들어가 의도보다 훨씬 많은 서버가 빠졌다."},"severity":"unknown","symptoms":["service-unavailable"],"timeline":{"detected_after":null,"resolved_after":"4h 17m"},"date_kind":"incident","detection":null,"components":["object-storage","block-storage","serverless-functions"],"root_cause":"human-operation","remediation":[{"text":{"en":"Restarted the index subsystem, which served GET, LIST and DELETE again from 12:26PM PST","ko":"인덱스 하위 시스템을 먼저 재시작했다. PST 오후 12:26 에 GET, LIST, DELETE 요청을 처리할 만큼 용량이 올라왔고, 오후 1:18 에 완전히 회복했다."}},{"text":{"en":"Restarted the placement subsystem after the index subsystem worked, restoring PUT by 1:54PM PST","ko":"인덱스 하위 시스템이 동작하자 배치 하위 시스템을 회복시켰고, PST 오후 1:54 에 회복을 마쳐 S3 가 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"Change the capacity removal tool to remove capacity more slowly","ko":"용량을 빼는 도구가 용량을 더 천천히 빼도록 고쳤다."}},{"text":{"en":"Add safeguards that stop capacity removal when it would take a subsystem below its minimum required capacity","ko":"어떤 하위 시스템이든 필요한 최소 용량 밑으로 떨어지게 하는 용량 제거를 막는 안전장치를 더했다."}},{"text":{"en":"Audit other operational tools for similar safety checks","ko":"다른 운영 도구에도 비슷한 안전 점검이 있는지 감사한다."}},{"text":{"en":"Improve the recovery time of key S3 subsystems and start the planned further partitioning of the index subsystem into cells now","ko":"핵심 S3 하위 시스템의 회복 시간을 줄인다. 그해 후반에 계획했던 인덱스 하위 시스템의 추가 분할 작업도 앞당겨 바로 시작한다."}},{"text":{"en":"Run the SHD administration console across multiple AWS regions","ko":"AWS Service Health Dashboard 의 관리 콘솔이 여러 AWS 리전에서 돌도록 바꿨다."}}],"contributing":["no-safeguard-on-destructive-change","blast-radius-too-wide","circular-dependency"],"recurrence_of":null,"symptoms_text":{"en":"From 9:37AM PST on February 28th, 2017, Amazon S3 in the Northern Virginia (US-EAST-1) Region could not serve requests. AWS services in the region that store data in S3 failed with it, including the S3 console, new Amazon EC2 instance launches, Amazon EBS volumes that needed data from an S3 snapshot, and AWS Lambda.\n\nS3 came back in steps. At 12:26PM PST the index subsystem had activated enough capacity for GET, LIST and DELETE requests, and those APIs were fully normal at 1:18PM PST. PUT requests also need the placement subsystem, which started recovering only after the index subsystem worked and finished at 1:54PM PST. Other AWS services that had built up a backlog of work during the disruption took longer to recover fully.\n\nUntil 11:37AM PST AWS could not update the status of individual services on the AWS Service Health Dashboard (SHD), because the SHD administration console itself depends on Amazon S3. Status went out through the AWS Twitter feed and SHD banner text instead.","ko":"2017-02-28 오전 Northern Virginia 의 US-EAST-1 리전에서 Amazon S3 가 요청을 처리하지 못했다. GET, LIST, PUT, DELETE 요청이 모두 실패했다.\n\nS3 에 데이터를 저장하는 같은 리전의 다른 AWS 서비스도 S3 API 를 쓸 수 없는 동안 영향을 받았다. S3 콘솔, 새 Amazon EC2 인스턴스 시작, S3 스냅샷에서 데이터가 필요한 Amazon EBS 볼륨, AWS Lambda 가 여기에 들었다.\n\nAWS Service Health Dashboard 의 관리 콘솔도 S3 에 기대고 있어서, 장애 시작부터 PST 오전 11:37 까지 서비스별 상태를 갱신할 수 없었다. 그동안 AWS 는 공식 트위터와 대시보드 배너 문구로 상황을 알렸다.\n\n회복은 단계적이었다. PST 오후 12:26 에 GET, LIST, DELETE 요청부터 처리되기 시작했고, 오후 1:18 에 이 세 API 가 정상으로 돌아왔다. PUT 은 오후 1:54 에 정상이 됐다. 다른 AWS 서비스 일부는 장애 동안 밀린 작업이 있어 완전히 회복하는 데 시간이 더 걸렸다."},"updated_at":"2026-11-14T12:34:17.720936Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0534","org_slug":"amazon-web-services"}