하루위키
IT·서비스종결

2017 아마존 AWS S3 대규모 장애, 엔지니어 명령어 오입력으로 인터넷 절반이 흔들린 사태

2017-02-28 — 2017-03-03

최종 갱신

이 문서는 실제 사건·사고를 시간순으로 정리합니다. 편집 시 신뢰할 수 있는 출처를 반드시 밝혀 주세요.

1. 개요[편집]

2017년 2월 28일 아마존웹서비스(AWS) 북버지니아 리전의 S3 스토리지 팀원이 서버 일부를 제거하는 명령어를 잘못 입력해 필요 이상의 서버가 내려가면서 슬랙, 트렐로, 퀴라, 벤모 등 수많은 웹사이트와 서비스가 약 4시간 동안 먹통이 됐고, 피해액이 수억 달러로 추정돼 클라우드 집중 위험이 부각됐다.

2. 전개 과정[편집]

6개 기록 · 2017-02-28 ~ 2017-03-03

  1. S3 청구 시스템 점검 중 서버 제거 명령어 잘못 입력(태평양시 09:37)

    2017년 2월 28일 태평양표준시 오전 9시 37분 AWS S3 팀의 승인된 담당자가 S3 청구 시스템이 느리게 동작하는 문제를 디버깅하던 중 정해진 절차서에 따라 소수의 서버를 제거하는 명령어를 실행했다. 그러나 입력값 하나가 잘못 입력돼 의도한 것보다 훨씬 많은 서버가 한꺼번에 내려갔다. 제거된 서버에는 객체의 메타데이터와 위치 정보를 관리하는 인덱스 서브시스템과 새 객체의 저장 공간을 배정하는 배치 서브시스템의 용량이 포함돼 있었다. 두 서브시스템이 최소 용량 아래로 떨어지면서 북버지니아(US-EAST-1) 리전 S3가 읽기·쓰기 요청을 처리하지 못하게 됐다. 사건은 단순한 오타 하나가 전 세계 서비스에 파급될 수 있다는 점을 극적으로 보여줬다.

  2. 슬랙·트렐로·퀴라·벤모 등 확산, AWS 상태 대시보드마저 오작동

    S3 장애는 S3를 저장소로 쓰는 EC2 신규 인스턴스 실행, EBS 볼륨 복원, 람다 함수 등 AWS 내부 서비스까지 연쇄적으로 영향을 줬다. 외부에서는 슬랙, 트렐로, 스프링클러, 벤모, 퀴라 같은 서비스와 접속 장애를 추적하는 사이트 다운디텍터까지 느려지거나 멈췄다고 보도됐다. 이미지와 파일을 S3에서 불러오는 수많은 웹사이트에서 사진이 깨지거나 페이지가 열리지 않는 현상이 나타났다. AWS가 서비스 상태를 알리는 대시보드 역시 S3에 의존해 정상 표시가 불가능했고, 이용자들은 한동안 공식 상황을 확인하기 어려웠다. 이 때문에 장애 신호를 전달해야 할 도구가 장애 원인과 같은 시스템에 묶여 있다는 구조적 문제가 지적됐다.

  3. S3 인덱스·배치 서브시스템 순차 복구, 약 4시간 만에 정상화

    AWS는 두 서브시스템을 모두 완전히 재시작해야 했는데, 이 대규모 재시작은 수년 동안 해본 적이 없는 절차였다. S3가 폭발적으로 성장하는 동안 인덱스 서브시스템이 담당하는 메타데이터 양이 크게 늘어 재시작과 안전성 검사에 예상보다 오랜 시간이 걸렸다. 태평양시 오후 12시 26분 인덱스 서브시스템이 읽기·목록·삭제 요청 처리를 재개했고, 1시 18분 인덱스가 완전히 복구됐다. 이어 1시 54분 배치 서브시스템이 복구되면서 S3가 정상 동작으로 돌아왔다. 그 뒤에도 S3에 의존하는 다른 AWS 서비스들은 밀린 요청을 처리하느라 추가 시간이 필요했다.

  4. AWS, 사후 보고서 공개하며 오입력 책임 인정

    2017년 3월 2일 아마존은 사후 분석 보고서를 공개해 승인된 팀원이 명령어 입력값을 잘못 넣어 의도보다 큰 규모의 서버가 제거됐다고 공식 인정했다. 보고서는 사고의 직접 원인인 명령어 실수뿐 아니라, 도구가 한 번에 너무 많은 용량을 제거하는 것을 막지 못했다는 설계상의 허점도 함께 설명했다. 아마존은 사과하며 이번 일이 고객의 사업에 미친 영향을 인지한다고 밝혔다. 언론은 개인의 실수보다 안전장치 부재가 근본 문제라고 분석했고, 일부 매체는 이를 단 하나의 오타가 인터넷을 흔든 사건이라고 보도했다. 보고서는 클라우드 장애 사후 분석의 투명한 공개 사례로도 자주 언급된다.

  5. 재발 방지책: 용량 제거 속도 제한, 최소 용량 보호, 대시보드 다중 리전화

    AWS는 재발 방지를 위해 용량을 제거하는 도구를 수정해 서버를 더 천천히 제거하고, 서브시스템이 최소 필요 용량 아래로 내려가지 못하도록 막는 안전장치를 추가했다고 밝혔다. 또 다른 운영 도구들에도 비슷한 보호 장치가 있는지 점검하는 감사를 시작했다. 인덱스 서브시스템을 더 작은 단위의 셀로 나누는 작업을 앞당겨, 장애가 나더라도 영향을 받는 범위를 줄이겠다고 설명했다. 서비스 상태 대시보드는 여러 리전에 걸쳐 동작하도록 구성을 바꿔 S3 장애와 함께 먹통이 되지 않게 했다. 이러한 조치는 이후 클라우드 업계의 장애 폭발 반경 축소 설계 논의에 자주 인용됐다.

  6. S&P 500 기업 1억 5천만 달러 손실 추산, 클라우드 집중 위험 논란

    사이버 위험 평가업체 사이언스(Cyence)는 이번 장애로 S&P 500 기업들이 입은 손실이 약 1억 5천만 달러에 이를 것으로 추산했다. 웹 성능 모니터링 업체 아피카(Apica)는 인터넷 상위 100대 소매업체 중 54곳의 웹사이트 성능이 20% 이상 느려졌다고 밝혔다. 장애는 대략 반나절 가까이 이어졌고 수십만 개 웹사이트와 서비스가 직·간접 영향을 받은 것으로 추산됐다. 이 사건으로 소수 클라우드 업체와 특정 리전에 인터넷이 지나치게 의존하는 구조의 위험, 그리고 다중 리전·다중 클라우드 설계의 필요성이 본격 논의됐다. 같은 US-EAST-1 리전은 이후에도 대형 장애의 진원지가 되며 이 논쟁이 반복됐다.

3. 같이 보기[편집]

181
알리익스프레스 프로모션 배너

자주 묻는 질문

2017 아마존 AWS S3 대규모 장애, 엔지니어 명령어 오입력으로 인터넷 절반이 흔들린 사태, 어떤 사건인가요?
2017년 2월 28일 아마존웹서비스(AWS) 북버지니아 리전의 S3 스토리지 팀원이 서버 일부를 제거하는 명령어를 잘못 입력해 필요 이상의 서버가 내려가면서 슬랙, 트렐로, 퀴라, 벤모 등 수많은 웹사이트와 서비스가 약 4시간 동안 먹통이 됐고, 피해액이 수억 달러로 추정돼 클라우드 집중 위험이 부각됐다.
2017 아마존 AWS S3 대규모 장애, 엔지니어 명령어 오입력으로 인터넷 절반이 흔들린 사태, 언제 일어났나요?
2017-02-28부터 2017-03-03까지 이어진 사건입니다.
2017 아마존 AWS S3 대규모 장애, 엔지니어 명령어 오입력으로 인터넷 절반이 흔들린 사태, 지금 상태는 어떤가요?
종결된 사건입니다. 2017-03-03에 마무리되었습니다.

개선 제안

이 문서에 대한 개선을 제안할 수 있어요. 제안은 관리자 검토 후 반영됩니다.

개선 제안하기