요약

  • AWS는 미국 동부 리전 내 한 가용 영역에서 잘못 실행된 네트워크 트래픽 전환이 다수의 Elastic Block Store(EBS) 노드를 격리시켰다고 밝혔다. 연결이 복구되자 많은 노드가 동시에 대체 복제본 생성을 시도했고, 여유 용량을 소진시키며 재시도를 증폭시켰다. AWS는 이를 리미러링 스톰(re-mirroring storm)이라 불렀다.

  • 핵심 스토리지 장애는 한 가용 영역 안에 머물렀으나, EBS의 지역 조정 계층 혼잡으로 인해 유한한 기간 동안 다른 곳에서 API 오류와 지연이 발생했다. AWS는 해당 가용 영역의 볼륨 약 13%가 안정화에 실패해 정체 상태에 있었고, 동일 볼륨 모집단의 0.07%는 결국 일관된 상태로 복구할 수 없었다고 보고했다.

  • 책임성 교훈은 법적이 아니라 운영적이다. 복구 수요가 제한되고, 여유 용량이 입증되며, 공유 통제 경로가 부하를 덜 수 있고, 장애 도메인을 격리할 수 있으며, 공급자와 고객 팀이 자원 및 서비스 수준에서 완결을 증명할 수 있을 때에만 보호가 완전해진다.

하나의 가용 영역, 하나 이상의 장애 표면

장애는 2011년 4월 21일 Amazon Web Services의 미국 동부 리전 내 한 가용 영역에서 시작됐다. AWS의 사후 보고서는 초기 결함을 그 유한한 장애 도메인 내부에 두었다. 이는 전역적 AWS 중단을 설명하지 않았으며, 가용한 기록도 그렇게 해석할 근거가 없다.

이 경계가 중요한 이유는 사건이 서로 다른 두 범위를 가졌기 때문이다. 영향받은 가용 영역의 스토리지 노드는 직접적인 연결 및 복제 위기를 겪었다. 한편 유한한 기간 동안 지역 EBS 컨트롤 플레인, 즉 운영을 조정하는 계층도 혼잡해져 직접 영향받은 영역 외부에서 API 오류와 지연을 낳았다.

가용 영역은 리전 내에서 공급자가 정의한 장애 도메인이다. 고객은 함께 장애가 나서는 안 되는 워크로드를 영역 단위로 분리한다. 2011년 사건은 물리적·스토리지 분리가 장애 및 복구 과정에서 사용되는 모든 조정 서비스의 완전한 분리를 자동으로 의미하지는 않음을 보여준다.

이 구분은 두 가지 상반된 오류를 막는다. 사건을 단순한 단일 영역 문제로 축소하면 지역 컨트롤 플레인 효과와 하류 불확실성이 과소평가된다. 반대로 리전 전체 스토리지 상실로 확대하면 기록을 과장하는 것이며, 기반이 된 클러스터 장애와 AWS가 공표한 비율은 모두 영향받은 가용 영역에 묶여 있었다.

이 사건은 단일 중단 시간 레이블로도 설명되지 않는다. AWS는 추가 열화가 억제된 시점, 이후의 API 복구, 장기간의 복제본 재구축, 백로그 처리, 잔여 집합의 수동 복구를 기술했다. 이는 서로 다른 운영 이정표이며, "서비스 복구"의 교환 가능한 정의가 아니다.

고객에게 보이는 증상은 자원과 의존 경로에 따라 달랐다. 일부 볼륨은 입출력이 정체됐고, 일부 볼륨 생성 요청은 오류나 지연을 겪었으며, 일부 데이터베이스 인스턴스는 스토리지 장애나 장애 조치 마찰에 직면했다. 공개 서비스들은 중단을 보고했지만, 자료들은 모든 영향받은 애플리케이션에 동일한 메커니즘이 작동했다고 확인해 주지 않는다.

이 계층적 범위가 첫 번째 책임성 시험이다. 유용한 인시던트 기록은 어느 장애 도메인이 실패했는지, 어느 공유 서비스가 압박을 전파했는지, 어느 자원이 손상된 상태로 남았는지, 각 시점에서 "복구"가 무엇을 의미했는지 말해야 한다. 포괄적인 녹색 상태 표시는 이러한 구분을 대체할 수 없다.

고정된 자료 집합에서 AWS 자신의 공개 메커니즘 설명이 가장 강하고, 고객 수준 집계는 약하다. AWS는 내부 서술을 제공했고, Heroku는 직접적인 하류 운영자 증거를 제공했다. TechCrunch는 당시 공개 영향을 기록했으며, The Register와 InfoQ는 각자 독립적 역할에서 복구와 기술적 함의를 검토했다.

고정된 자료 집합 어느 곳도 영향받은 고객 수, 상실된 기록 수, 상실된 바이트 수, 총 경제적 피해를 확정하지 않는다. 이 미지들로 인해 사건이 소멸되지는 않는다. 다만 책임 있는 분석이 사실 주장을 멈춰야 하는 한계를 정의한다.

AWS가 설명한 스토리지 아키텍처

Elastic Block Store, 즉 EBS는 컴퓨팅 인스턴스가 사용하는 영구 블록 스토리지를 제공했다. "블록"이란 애플리케이션이 공유 파일 서비스가 아니라 주소 지정 가능한 저장 단위를 본다는 뜻이다. 영구성이란 볼륨이 특정 컴퓨팅 인스턴스의 수명과 무관하게 데이터를 유지하도록 설계됨을 의미한다.

AWS는 EBS를 분산 시스템으로 설명했다. 데이터는 가용 영역 내 스토리지 노드들에 복제되어 단일 하드웨어 구성요소가 유일한 사본을 갖지 않도록 했다. 따라서 복제는 보호 메커니즘이었지만, 복제본이 없거나 도달 불가능하거나 더 이상 신뢰되지 않을 때마다 조정 작업을 만들어 내기도 했다.

AWS가 기술한 2011년 설계는 각 가용 영역 내부에 클러스터를 두었다. 지역 컨트롤 플레인이 요청과 기능(예: 프라이머리 복제본 선택)을 조정했다. 컨트롤 플레인은 의사결정과 오케스트레이션 계층이며, 일반적인 애플리케이션 읽기·쓰기를 운반하는 데이터 경로와 다르다.

AWS는 또한 EBS 노드가 사용하는 두 네트워크 경로를 설명했다. 고대역폭 주 네트워크가 일반 트래픽을 운반했다. 더 낮은 용량의 복제 네트워크는 예비 연결과 오버플로우 능력을 제공했다. 두 번째 경로는 보호 장치였지만, 주 경로가 운반하던 모든 트래픽을 흡수하도록 크기가 정해지지는 않았다.

존재와 용량의 이 차이가 핵심이다. 보조 경로는 존재하고 연결되어 기술적으로 기능하면서도, 주요 우회가 만드는 동시 수요를 감당하지 못할 수 있다. 중복성은 대안의 존재 여부를 답한다. 복구 엔지니어링은 그 대안이 얼마나 많은 작업을, 얼마나 오래, 어떤 동시성 조건에서 견딜 수 있는지를 묻는다.

스토리지 클러스터는 복제본 교체를 위해 여유 용량에도 의존했다. 노드가 유효한 피어가 없다고 판단하면 다른 노드의 공간을 찾아 새 사본 생성을 시작했다. 이 동작은 교체 수요가 예상 범위 내에 머무는 일반적인 장애에서 내구성을 보호했다.

대규모로는 같은 동작이 시스템의 부하 프로파일을 바꿀 수 있었다. 복제본 생성은 네트워크 대역폭, 디스크 연산, 조정, 가용 스토리지를 소모한다. 고립된 장애 이후 위험을 줄이도록 설계된 메커니즘은, 수요가 제한·조율되지 않으면 상관된 사건을 강화할 수 있다.

컨트롤 플레인은 또 다른 공유 자원이었다. 오래 대기한 요청은 워커 스레드를 점유할 수 있으며, 워커 스레드는 동시 작업을 처리하는 유한한 실행 슬롯이다. 충분히 많은 느린 연산이 슬롯을 붙잡으면, 리전의 무관하거나 건강한 부분조차 제어 요청이 지연되거나 실패할 수 있었다.

이 설명을 현재의 AWS 아키텍처로 읽어서는 안 된다. 이는 AWS가 2011년 사건 이후 기술한 시스템에 대한 서술이다. 자료 집합에는 현재 아키텍처 증거가 없으며, 본 글은 EBS, 그 네트워크, 컨트롤 플레인이 지금 어떻게 작동하는지에 대한 어떤 주장도 하지 않는다.

이 역사적 경계는 공정한 분석에 중요하다. 사건의 가치는 낡은 구성요소가 여전히 존재한다고 주장하는 데 있지 않다. 사건이 노출하는 내구적 시스템 질문에서 나온다. 즉, 많은 구성요소가 동시에 보호 메커니즘을 작동시킬 때 그 메커니즘이 통제 상태를 유지할 수 있는가?

격리를 만든 트래픽 전환

AWS에 따르면 영향받은 가용 영역에서 네트워크 용량 변경이 진행 중이었다. 4월 21일 태평양 시각 오전 12시 47분에 트래픽이 잘못 전환됐다. 고대역폭 주 네트워크의 다른 라우터로 옮겨지는 대신, 더 낮은 용량의 복제 네트워크로 옮겨졌다.

복제 네트워크는 그 주 트래픽을 감당할 수 없었다. 혼잡으로 많은 EBS 노드가 어느 경로로도 효과적으로 통신하지 못했다. 노드의 관점에서 복제된 볼륨을 유지해야 할 피어들이 사라졌거나 도달 불가능해 보였다. 초기 사건은 네트워크 라우팅 조치였지, 스토리지의 동시 물리적 파괴가 아니었다.

이 때문에 사건을 단순한 케이블이나 라우터 장애로 이해할 수 없다. 중요한 상태 변화는 트래픽 배치, 링크 용량, 복제본 도달성, 자동 복구 동작의 관계 속에서 일어났다. 연결이 단순히 사라진 것이 아니라, 서로 다른 용량 가정을 가진 경로로 유도되었다.

AWS는 트래픽 전환이 잘못 실행되었다고 말했으나, 공개 서술은 개별 운영자, 승인자, 관리자 또는 팀을 유책한 존재로 지목하지 않았다. 따라서 증거는 개인 귀속이 아니라 프로세스와 통제 분석을 지지한다. 이는 과실, 불법성, 계약 위반을 확립하지 않는다.

트래픽 변경은 기술적 폭발 반경, 즉 영향을 줄 수 있는 시스템 범위를 지닌 운영 의사결정이다. 그 안전은 명령 구문의 정확성 이상에 달려 있다. 엔지니어는 대상 경로의 용량, 의존 스토리지 노드의 동작, 롤백 조건, 롤백 자체가 유발할 부차 부하를 알아야 한다.

이 변경은 "백업"이라는 레이블이 모호한 이유도 보여준다. 저용량 경로는 특정 복제 흐름이나 임시 오버플로우에는 적합할 수 있다. 그것이 전체 생산 부하 하의 주 네트워크 대체물이라는 보장은 없다. 문서와 변경 통제는 그 양적 경계를 명시적으로 표현해야 한다.

첫 번째 장애는 잘못된 트래픽 배치였다. 더 큰 연속성 장애는 시스템의 격리 반응이 새 수요를 만들면서 나타났다. 이 구분이 중요하다. 초기 네트워크 상태를 수복하는 것은 필요했지만, 이미 움직이기 시작한 분산적 결과를 즉시 되돌릴 수는 없었다.

촉발 행위에만 집중하면 조직은 더 나은 승인 체크리스트가 완전한 해법이라고 결론지을 수 있다. 기록은 더 넓은 결론을 지지한다. 변경 안전, 복구 동시성, 예비 스토리지, 재시도 동작, 컨트롤 플레인 용량이 모두 최종 범위와 기간에 관여했다.

연결 복구가 서비스 복구를 의미하지 않은 이유

AWS는 트래픽 전환을 롤백하고 네트워크 연결을 복구했다. 그러나 많은 EBS 노드는 이미 대체 복제본을 찾아 생성해야 하는 상태에 들어가 있었다. 대규모 노드 집단이 동시에 그 작업을 하자 평상시의 복구 동작이 동기화된 수요 급증이 되었다.

AWS는 그 결과를 "리미러링 스톰"이라 불렀다. 리미러링이란 기존 복제본이 사용 불가하거나 안전하지 않다고 간주될 때 새 복제본을 만드는 것이다. 많은 노드가 그 작업을 함께 시도하며 유한한 여유 용량을 두고 경쟁하고 더 많은 조정·재시도 트래픽을 반복 생성할 때 스톰이 발생한다.

이 표현은 위기가 단순한 장애가 아니라 복구에 있음을 짚어준다. 시스템은 보호를 재확립하려 했다. 그러나 집계 요청률이 가용 스토리지와 조정 서비스가 흡수할 수 있는 수준을 넘었다. 보호 자동화는 상관된 수요 아래서 스스로 증폭되었다.

노드들이 새 복제본을 만들 장소를 찾으면서 여유 스토리지 용량이 고갈됐다. 평상시 교체율에는 충분해 보이던 용량 풀이 대규모 재구축에는 충분하지 않았다. 따라서 시스템에는 평상시 활용률이 아니라 장애 시나리오를 기준으로 측정된 헤드룸이 필요했다.

AWS는 백오프 부족도 보고했다. 백오프는 실패한 연산을 재시도하기 전에 의도적으로 지연과 조율을 적용하는 것이다. 지연이 부족하면 많은 클라이언트나 노드가 함께 재시도하여 같은 경합을 재현하고 공유 자원의 회복을 방해한다.

AWS에 따르면 저확률 경쟁 상태(race condition)가 노드 장애를 추가로 증폭했다. 경쟁 상태는 결과가 동시 연산의 타이밍이나 순서에 좌우될 때 발생한다. 평상시 트래픽에서 드문 조건은 수천 개의 복구 작업이 겹치면 훨씬 자주 나타날 수 있다.

이 메커니즘들은 하나의 피드백 루프를 이루었다. 격리는 복제본 탐색을 촉발했다. 탐색은 여유 공간과 조정 자원을 소모했다. 실패하거나 지연된 시도는 재시도를 낳았다. 재시도는 경합을 높였고, 높아진 경합은 추가 연산을 느리게 하거나 실패시켜 더 많은 복구 작업을 만들었다.

InfoQ의 독립 기술 분석도 재복제, 용량 고갈, 컨트롤 플레인 효과, 점진적 복구의 상호작용을 강조했다. 이는 분산 시스템 패턴 해석에 도움이 되지만, 내부 인과 사실의 출처는 AWS이다. 두 역할은 합쳐져서는 안 된다.

이 피드백 루프는 롤백만으로는 완결 시험이 될 수 없는 이유를 설명한다. 원래 네트워크 경로 복구는 초기 조건을 제거했지만, 복제본 결손, 대기 작업, 고갈된 용량, 이미 복구를 시도 중이던 노드의 상태를 제거하지는 못했다. 라우팅이 올바른 시스템도 운영적으로 불안정할 수 있다.

이 구분은 복원력 시험 방식을 바꾼다. 트래픽이 원래 경로로 돌아왔을 때 멈추는 장애 조치 훈련은 사건의 일부만 시험한다. 완전한 훈련은 이후의 수리 물결을 관찰해야 하며, 여기에는 스토리지 할당, 네트워크 활용, 재시도 동기화, 컨트롤 플레인 큐가 포함된다.

따라서 복구 동시성은 관리 대상 수량이어야 한다. 운영자는 얼마나 많은 수리를 시작할 수 있는지, 새 작업을 얼마나 빨리 받아들일지, 중요 연산을 위해 용량을 어떻게 예약할지에 대한 한계를 필요로 한다. 그렇지 않으면 시스템은 구성요소의 동시 행동을 통해 암묵적으로 동시성을 결정한다.

시스템에는 목표의 위계도 필요하다. 추가 복제본 상실 방지, 일관된 데이터 보존, 기존 볼륨 서비스, 새 볼륨 생성, 완전한 중복성 재구축은 자원을 두고 경쟁할 수 있다. 명시적 우선순위가 없으면 가장 크게 재시도하는 집단이 더 안전하거나 긴급한 작업에 필요한 용량을 소모할 수 있다.

이 사건은 복제가 그릇되었다는 것을 보여주지 않는다. 복제에는 복구 비용이 있다는 것을 보여준다. 더 강한 결론은 중복성과 중복성을 회복시키는 기계를 함께 설계해야 한다는 것이며, 장애 시점의 워크로드는 평상시 운영과 근본적으로 다를 수 있기 때문이다.

지역 컨트롤 플레인이 피해 범위에 포함된 순간

AWS는 느린Create Volume호출과 긴 타임아웃이 지역 EBS 컨트롤 플레인의 스레드 풀을 점유했다고 보고했다. 스레드가 고갈되자 요청을 신속히 처리할 수 없었다. 직접 영향받은 가용 영역 외부의 고객들은 유한한 기간 동안 EBS API 오류와 지연 증가를 겪었다.

스레드 풀은 유한한 워커 집합이다. 각 워커는 작업을 처리하지만, 느린 작업은 완료되거나 타임아웃될 때까지 워커를 붙잡을 수 있다. 충분히 많은 호출이 붙잡혀 있으면, 요청된 기반 자원이 다른 곳에 있더라도 공유 풀은 건강한 작업을 더 이상 받아들이지 못할 수 있다.

이 메커니즘은 공유 운명 전파의 한 형태다. 스토리지 클러스터는 가용 영역별로 조직되었지만, 지역 조정 계층이 한 열화된 클러스터의 작업이 다른 영역을 위해 작동하는 제어 연산에 영향을 줄 수 있는 경로를 만들었다. 장애 도메인 레이블만으로는 그 의존성이 드러나지 않았다.

AWS는 이후 복제본 협상이 계속되면서 컨트롤 플레인 부하가 다시 오르는 것도 기술했다. 운영자는 압박을 줄이고 시스템의 건강한 부분을 보호하기 위해 열화된 클러스터를 격리했다. 격리는 방임이 아니라, 공유 제어 자원을 소비할 수 있는 구성요소의 집합을 좁힌 봉쇄 조치였다.

이 일련 과정은 부하 감축이 장애 도메인을 이해해야 하는 이유를 보여준다. 일반적인 요청 거부는 총 작업량을 줄일 수 있지만, 목표 지향적 입장 통제는 손상된 클러스터를 제한하면서 건강한 영역의 운영을 보존할 수 있다. 핵심 통제는 공유 워커가 소모되기 전에 출처, 긴급도, 예상 비용을 구분하는 능력이다.

타임아웃 정책도 똑같이 중요하다. 긴 타임아웃은 인내심 있어 보여도, 규모 속에서는 희소한 실행 슬롯을 점유해 전반적 응답성을 악화시킬 수 있다. 짧은 타임아웃은 공격적 재시도를 만든다. 건전한 설계에는 멱등성도 필요하다. 즉, 요청을 안전하게 반복해도 효과가 중복되지 않아야 한다.

지역 효과가 사건을 모든 볼륨의 지역적 상실로 바꾸지는 않는다. 이는 API 표면이 핵심 스토리지 클러스터보다 넓은 장애를 겪었음을 보여준다. 정확한 보고는 두 진술을 동시에 유지해야 한다. 핵심 장애는 영역 단위였고, 일부 컨트롤 플레인 결과는 그 영역 경계를 넘었다.

책임성에 필요한 아키텍처 도표는 데이터 복제본의 위치만이 아니라, 새 복제본을 누가 할당하는지, 어떤 큐와 워커 풀이 공유되는지, 요청이 어떻게 분류되는지, 클러스터가 비정상 행동을 보일 때 어떤 격리 스위치가 남아 있는지를 포함해야 한다.

서비스는 여러 장애 도메인을 광고하면서 오케스트레이션, 신원, 메타데이터, 네트워킹에 숨은 공통 의존성을 유지할 수 있다. 교훈은 공유 서비스가 항상 잘못되었다는 것이 아니다. 그 용량과 장애 동작이 보이고, 시험되고, 동시 복구 수요에 맞춰 제한되어야 한다는 것이다.

봉쇄, 복구, 그리고 긴 꼬리

AWS는 사건이 4월 21일 태평양 시각 오후 12시 4분까지 영향받은 가용 영역으로 봉쇄됐다고 보고했다. 봉쇄란 계속되는 교란이 같은 방식으로 확산되지 않는다는 뜻이며, 모든 영향받은 볼륨, API 요청, 의존 서비스가 복구됐다는 뜻이 아니었다.

안정화 시점에 AWS는 영향받은 가용 영역의 볼륨 약 13%가 정체되어 있었다고 말했다. 분모는 정확하다. 영향받은 가용 영역의 볼륨이다. 고객의 13%, 미국 동부 리전의 13%, 전체 AWS 스토리지의 13%, 데이터의 13%가 아니다.

AWS는 물리적 스토리지 용량을 추가하고 노드와 복제본을 통제된 단계로 되돌리는 작업을 진행했다. 새 용량은 교체 사본의 공간을 만들었고, 스로틀링은 동시 재구축이 과부하를 재현할 위험을 줄였다. 복구는 따라서 자원과 순서 지정 둘 다를 필요로 했다.

운영자는 컨트롤 플레인 백로그도 처리해야 했다. 복구된 API 엔드포인트는 오래된 요청이 아직 대기 중이거나 개별 자원이 열화된 상태에서도 새 작업을 받아들일 수 있다. 그 결과 서비스 수준 복구와 자원 수준 복구는 수 시간 혹은 수일간 갈라질 수 있다.

일부 연산은 수동 주의를 필요로 했다. 자동화는 통상 사례를 복구할 수 있지만, 잔여 집단은 모호한 상태, 손상된 일관성, 일반 조치로는 안전하게 해결할 수 없는 실패한 의존성을 가질 수 있다. 이 긴 꼬리가 고객 불확실성과 운영 리스크가 집중되는 지점인 경우가 많다.

복구는 주말 내내 이어졌다. AWS의 연표와 The Register·InfoQ의 독립적 검토가 이를 뒷받친다. 이 수일에 걸친 과정을 모든 고객이 같은 기간 동안 계속 오프라인이었다는 주장으로 납작하게 만들어서는 안 된다. 증거는 장기화된 복구 작업을 지지할 뿐, 보편적 기간을 지지하지 않는다.

단계들은 측정 문제도 노출한다. 운영자는 네트워크 복구, API 가용성, 복제본 복원, 수동 복구 완료 중 어느 것이든 보고할 수 있다. 각 이정표는 서로 다른 질문에 답한다. 고객은 플랫폼이 지역 임계를 넘었는지가 아니라 자신의 서비스가 안전한지 판단할 수 있는 자원 수준 증거를 필요로 한다.

견고한 완결 모델은 최소 네 개 모집단을 추적해야 한다. 정상 서비스 중인 자원, 중복성이 줄어든 채 서비스 중인 자원, 접근 불가하나 복구 가능한 자원, 일관된 복구가 더 이상 불가능한 자원이다. 이들 상태 간 이동은 관찰 가능하고 감사 가능해야 한다.

인시던트 중 추가된 용량은 가치 있지만, 긴급 조달은 사전 프로비저닝된 복구 헤드룸과 같지 않다. 전달, 설치, 검증, 안전한 입장에는 모두 시간이 걸린다. 책임 있는 설계는 기존 예비분이 어떤 시나리오를 흡수할 수 있는지, 언제부터 특별한 물리적 개입이 필요한지를 명시해야 한다.

스로틀링에는 트레이드오프도 있다. 느린 재구축은 중복성 축소 기간을 늘리고, 빠른 재구축은 또 다른 용량 붕괴를 위험한다. 올바른 비율은 긴급성만으로 정할 수 없다. 측정된 여유 공간, 네트워크 처리량, 컨트롤 플레인 건강, 추가 구성요소 실패 위험과 연계되어야 한다.

이것이 복구를 관리된 생산 워크로드로 만든다. 복구에는 예측, 예산, 우선순위, 관측 가능성, 정지 조건이 필요하다. 평상시 서비스 트래픽과 마찬가지다. 복구를 예외적 배경 작업으로 취급하면, 시스템이 놀라움을 흡수하기 가장 어려운 순간에 그 최대 수요가 통제되지 않은 채 남는다.

일관성과 잔여 데이터 결과

AWS는 리미러링 기간 동안 시스템이 쓰기 가능한 프라이머리 복제본을 선택할 수 있을 때까지 영향받은 볼륨 접근이 계속 차단될 수 있다고 말했다. 프라이머리는 쓰기를 허용받은 사본이다. 시스템이 그 사본을 안전하게 식별할 수 없을 때 쓰기를 막는 것은 분기된 이력과 불일치 데이터를 방지한다.

이 보호 장치는 가용성 트레이드오프를 만든다. 시스템이 의도적으로 안전하지 않은 쓰기를 피하고 있는 경우에도 볼륨은 접근 불가할 수 있다. 고객 관점에서 사용 불가 스토리지는 여전히 심각한 장애다. 데이터 무결성 관점에서 모호한 쓰기의 거부는 더 큰 불일치를 예방할 수 있다.

AWS는 최종적으로 영향받은 가용 영역의 볼륨 0.07%가 일관된 상태로 복구될 수 없었다고 보고했다. 다시, 분모는 영향받은 가용 영역의 볼륨이다. 리전, AWS 고객, 기록, 바이트의 0.07%가 아니다.

The Register는 이 결과를 보도하며 늦은 복구와 커뮤니케이션을 검토했지만, 그 비율은 AWS 귀속 수치로 남았다. 독립 보도는 공개적 결과를 보이게 한다. 그러나 운영자 지표를 독립적으로 측정된 모집단으로 바꾸지는 않는다.

자료 집합은 관련된 바이트나 기록 수, 그 볼륨을 소유한 고객 수, 경제적 영향을 공개하지 않는다. "일부 볼륨이 일관되게 복구될 수 없었다"는 입증 가능하다. 데이터량, 고객 손실, 사업 피해에 대한 정량 주장은 그렇지 않다.

볼륨 손실과 애플리케이션 손실의 구분도 중요하다. 애플리케이션에는 독립 백업, 복제된 기록, 재구성 가능한 데이터가 있을 수 있다. 반대로 작은 영향받은 볼륨이 중요한 상태를 담고 있을 수도 있다. 인프라 비율은 고객별 증거 없이 사업 영향으로 변환될 수 없다.

AWS는 그 계정에서 설명한 서비스 크레딧을 제공했지만, 크레딧은 모든 결과가 보상되었다는 증명이 아니다. 계약 구제, 기술적 복원, 고객 사업 영향, 법적 책임은 별개의 질문이다. 본 글은 과실, SLA 위반, 책임에 관해 어떤 결론도 내리지 않는다.

데이터 무결성에는 "복제가 재개되었다"보다 강한 완결 산출물이 필요하다. 운영자는 모든 볼륨에 권위 있는 프라이머리가 있는지, 복제본이 일치하는지, 미결 쓰기가 정산되었는지, 복구 불가 사례가 영향받은 고객에게 직접 통지되었는지 알아야 한다.

고객 역시 자신이 통제하는 데이터에 대한 복원 증거를 필요로 한다. 공급자의 복제는 서비스 수준 장애 양상을 보호할 뿐, 애플리케이션 인지 백업·보존·복구 시험을 자동으로 대체하지 않는다. 이는 책임의 분담이지 비난의 전가가 아니다.

RDS가 보여준 의존성의 제품 경계 넘기

AWS에 따르면 Relational Database Service, 즉 RDS는 데이터베이스와 로그 스토리지를 EBS에 의존했다. 따라서 관리형 데이터베이스는 고객이 주로 데이터베이스 제품과 상호작용하고 EBS 볼륨을 직접 관리하지 않더라도 스토리지 장애를 상속받을 수 있었다.

영향받은 영역의 단일 가용 영역 데이터베이스 인스턴스는 스토리지 입출력 정체를 겪었다. 데이터베이스 서비스는 엔진을 관리한다고 해서 기반 스토리지를 도달 가능하게 만들 수 없었다. 제품 추상화는 고객 운영을 줄였지만, 서비스 아래의 물리적·제어 의존성을 제거하지는 못했다.

다중 가용 영역(Multi-AZ) 구성은 별도 영역에 또 다른 데이터베이스 인스턴스를 제공하도록 설계됐다. AWS는 이전에 겪어보지 못한 버그가 그 일부 인스턴스의 자동 장애 조치를 막았다고 보고했다. 해당 하위 집합에는 수동 개입이 필요했다.

이 사실은 Multi-AZ 설계가 무용했다거나 모든 Multi-AZ 인스턴스가 실패했다는 것을 확립하지 않는다. 더 좁은 지점을 확립한다. 즉, 보호 기능에는 자체 제어 경로와 예기치 않은 조건이 있었다. 데이터나 인스턴스 계층의 중복성은 여전히 신뢰 가능한 탐지와 장애 조치 오케스트레이션에 의존했다.

TechCrunch의 당시 보도는 사건이 진행되는 동안 RDS와 Multi-AZ 복구 마찰을 포착했다. 내부 의존성과 버그 서술의 출처는 AWS로 남는다. 독립 보도는 공개 연표와 영향 맥락을 지지할 뿐 내부 메커니즘을 증명하지 않는다.

서비스 소유자에게 주는 교훈은 구매한 인터페이스 아래의 관리형 제품 의존성을 지도화하는 것이다. 데이터베이스 팀은 스토리지 노드를 운영하지 않을 수 있지만, 백업, 장애 조치, 스냅샷, 제어 API, 프라이머리 스토리지가 영역 또는 지역 제어 서비스를 공유하는지 이해해야 한다.

테스트는 활성 데이터베이스 인스턴스의 상실 이상을 다뤄야 한다. 압박 하의 컨트롤 플레인, 지연된 스토리지 연산, 모호한 프라이머리 선택, 자체적으로 장애난 공급자 서비스를 필요로 하는 장애 조치 동작을 포함해야 한다. 그렇지 않으면 테스트는 실제 사건에서 가장 가능성 높은 결합 조건을 가정으로 지워버린다.

다중 리전 아키텍처는 다섯 출처의 사실적 범위 밖에 있다. 본 글은 그것이 모든 효과를 반드시 예방했을 것이라 주장하지 않는다. 애플리케이션 상태, 트래픽 관리, 제어 서비스, 백업 신선도, 운영 준비성이 지리적 분리가 사용 가능한 연속성이 되는지를 결정한다.

획일적 서사를 만들지 않은 하류 증거

Heroku는 4월 21일 광범위한 애플리케이션 중단을 직접 보고했다. 영향받은 플랫폼 운영자로서 그 서술은 인프라 장애가 또 다른 서비스 계층으로 전파되어 그 플랫폼에 의존한 애플리케이션에 영향을 줬음을 확립한다.

Heroku의 증거는 AWS의 내부 촉발, 영향받은 볼륨 비율, 지역 컨트롤 플레인 메커니즘을 확립하지 않는다. 그 사실들은 AWS의 사후 서술에 고정되어 있다. 이러한 역할을 분리하면 하류 증상을 상류 엔지니어링 세부의 증명으로 쓰는 일을 피할 수 있다.

TechCrunch는 사건이 진행되는 동안 Reddit, Foursquare, Quora 및 기타 서비스가 영향을 받았다고 보도했다. 이 당시 보도는 눈에 보이는 공개 영향과 사용자가 겪은 불확실성을 보여준다. 영향받은 서비스나 고객의 완전한 목록은 아니다.

이름이 지정된 서비스들을 각자의 증거 없이 하나의 기술 서사로 묶어서는 안 된다. 어떤 서비스는 사용 불가 볼륨에, 다른 서비스는 관리형 데이터베이스에, 또 다른 서비스는 플랫폼 의존성이나 운영 대응에 의존했을 수 있다. 중단 기간과 데이터 결과도 달랐을 수 있다.

복구 품질에도 같은 주의가 적용된다. 서비스가 웹으로 돌아왔다고 해서 모든 백그라운드 작업, 큐, 데이터 복제본, 고객 거래가 완료되었다는 증명이 되지 않는다. 공개 가용성은 하나의 관찰이지 각 애플리케이션의 종단 간 감사가 아니다.

그럼에도 하류 서술은 운영자의 포스트모텀만으로는 얻을 수 없는 것을 더한다. 인프라 장애가 조직 경계를 넘어 고객 대면 연속성 손실로 바뀌는 과정을 보여준다. 서비스 소유자가 내부적으로 들여다볼 수 없는 시스템에 의존하는 경우가 많기에, 이 번역이 책임성의 핵심이다.

효과적인 의존성 레지스터는 공급업체 이름 이상을 식별해야 한다. 중요 기능을 영역, 볼륨, 데이터베이스, 제어 API, 신원 서비스, 복구 도구, 백업 위치에 매핑해야 한다. 각 의존성이 열화될 때 조치할 수 있는 팀도 이름으로 지정해야 한다.

중소기업은 특별한 증거 문제에 직면한다. 공급자 내부 계층의 직접 텔레메트리가 없을 수 있지만, 여전히 자신의 서비스 약속에 책임이 있다. 이들의 통제는 공급자 상태 증거와 애플리케이션 프로브, 백업 테스트, 명확한 열화 결정을 결합해야 한다.

이는 모든 고객이 하이퍼스케일 공급자를 재현해야 한다는 주장이 아니다. 비례적 지식에 대한 주장이다. 팀은 어느 의존성이 실패할 때 어느 사업 기능이 멈추는지, 그 상태를 얼마나 견딜 수 있는지, 어떤 시험된 대안이 진정으로 독립적인지 알아야 한다.

커뮤니케이션은 복구 통제의 일부다

복잡한 인시던트 동안 상태 커뮤니케이션은 단순한 홍보가 아니다. 고객이 기다릴지, 장애 조치할지, 쓰기를 정지할지, 백업에서 복원할지, 사업 연속성 절차를 가동할지 결정하게 한다. 범위가 잘못 지정된 정보는 위험을 더하거나 희소한 복구 용량을 낭비하는 행동을 유도할 수 있다.

The Register의 보도는 긴 복구 동안의 불확실성을 조명하고 완전한 포스트모텀 이전의 커뮤니케이션 측면을 비판했다. 그 비판은 분석이지 내부 엔지니어링 메커니즘의 증명이 아니다. 고객이 전반적 서비스 개선과 특정 볼륨의 상태를 구분해야 했으므로 관련이 있다.

지역 상태는 영역별·자원별 인시던트에는 지나치게 거칠 수 있다. 고객은 API가 요청을 수락하는지, 기존 볼륨이 도달 가능한지, 완전한 복제를 갖는지, 데이터에 수동 복구가 필요한지 알아야 한다. 이는 하나의 상태 비트가 아니다.

연표는 봉쇄와 복원도 구분해야 한다. 많은 자원이 여전히 손상된 상태에서 "인시던트가 봉쇄되었다"는 진술은 정확할 수 있다. 이 표현은 무엇이 멈췄고 무엇이 여전히 고장이며 어떤 모집단이 아직 작업 중인지 독자에게 알려지지 않을 때만 기만적이 된다.

AWS는 더 자주 커뮤니케이션하고 더 나은 가시성을 제공하겠다고 말했다. 이 자료 집합에서 그것은 발표된 개선 방향이다. 특정 도구가 완성되었거나 효과적으로 시험되었거나 현재 서비스 설계로 남아 있다는 독립 증거가 아니다.

자원 수준 커뮤니케이션은 공급자 내부에서도 운영적 가치가 있다. 팀은 열화, 재구축 중, 복원, 복구 불가 자원의 공통 집계를 필요로 한다. 엔지니어링, 지원, 고객 커뮤니케이션이 서로 다른 모집단을 사용하면 조직은 완결을 일관되게 증명할 수 없다.

신뢰할 수 있는 인시던트 기록은 모든 비율에 이름 붙은 분모와 시점을 붙여야 한다. 그 수치가 추정치인지, 안정된 집계인지, 최종 결과인지 명시해야 한다. 이 규율은 13% 정체 모집단과 0.07% 불일치 복구 모집단이 혼동되는 것을 막는다.

따라서 커뮤니케이션 품질은 측정 가능하다. 유용한 지표에는 업데이트 간격, 범위 정밀도, 자원 수준 상태 커버리지, 정정 지연, 엔지니어링 확실성과 고객 통지 사이의 시간이 있다. 목표는 끊임없는 메시징이 아니라 고객이 행동해야 하는 순간의 의사결정급 증거다.

AWS가 바꾸겠다고 밝힌 것들

AWS는 복구 용량 버퍼를 늘리겠다고 발표했다. 그 방향은 평상시 예비 용량과 상관된 리미러링이 만드는 훨씬 큰 수요 사이의 불일치를 겨냥했다. 버퍼는 정의된 시나리오에 묶이고 부하 하에서 검증될 때만 의미가 있다.

운영자는 또한 재시도 백오프를 개선하고 보고된 경쟁 상태를 수정하겠다고 말했다. 이 조치들은 증폭을 겨냥했다. 즉, 동기화된 반복 작업을 줄이고 스트레스 하에서 더 자주 나타난 동시성 결함을 제거한다.

AWS는 타임아웃 개선과 가용 영역 인지 부하 감축을 기술했다. 함께, 이 통제들은 느린 작업이 공유 자원을 무기한 점유하는 것을 막고 열화된 영역이 지역 컨트롤 플레인 용량을 굶기기 전에 제한할 수 있었다.

사후 방향에는 더 많은 컨트롤 플레인 기능을 클러스터별 서비스 쪽으로 옮기는 것도 포함됐다. 더 큰 지역성은 공유 운명을 줄일 수 있으나, 다섯 출처 기록은 최종 설계나 그 효과를 확립하지 않는다. 이는 발표된 대응으로 이해되어야 하며, 검증된 현재 아키텍처가 아니다.

AWS는 더 많은 복구 통제를 자동화하고, Multi-AZ 도구를 개선하고, 더 자주 커뮤니케이션하겠다고 말했다. 자동화는 응답 시간을 줄일 수 있지만, 명시적 한계와 안전한 정지 조건을 담을 때만 그렇다. 통제되지 않은 빠른 복구는 문제를 해결하는 대신 재현한다.

이 약속들은 AWS가 공개한 장애 메커니즘과 부합하므로 분석적으로 관련이 있다. 그러나 약속은 완결 증거가 아니다. 완결에는 구현 기록, 시험 결과, 관측된 용량 여유, 상관된 복구 훈련에서 통제가 안전하게 작동한다는 증거가 필요하다.

따라서 본 글은 AWS가 이 조치들을 완료했거나 독립 당사자가 검증했거나 그것이 현재 제품의 일부로 남아 있다고 주장하지 않는다. 발표된 개선 방향을 역사 기록의 일부로 보고하며, 그로부터 보증 질문을 도출한다.

공급자와 고객 책임의 분리

AWS는 포스트모텀에 기술된 서비스 장애, EBS 복구 동작의 설계, 내부 네트워크와 컨트롤 플레인의 용량 및 격리, 자원 복구에 대해 제공한 증거를 소유했다. 이 책임들은 아키텍처 선택이 존재한다는 이유로 고객에게 전가되지 않았다.

공급자 책임에는 상관된 수요 아래에서 보호 메커니즘을 안전하게 만드는 것이 포함된다. 즉, 동시성 한계를 설정하고, 복구 헤드룸을 예약하고, 비정상 클러스터를 격리하며, 제어 서비스가 건강한 장애 도메인에 계속 사용 가능함을 증명하는 것이다. 일관되게 복원할 수 없는 잔여 자원을 식별하는 것도 포함된다.

고객은 당시 이용 가능한 제품과 증거 안에서 다른 표면을 통제했다. 애플리케이션 의존성, 백업 구성, 장애 도메인 배치, 공급자 자원이 열화될 때 사용할 절차를 선택했다. 이 선택들은 공급자 인시던트를 일으키지 않으면서 결과를 바꿀 수 있었다.

고객 책임을 고객 과실으로 다시 써서는 안 된다. 설계에는 완전한 독립을 비현실적으로 만드는 제약, 비용 한계, 제품 의존성이 있을 수 있다. 책임 있는 질문은 의사결정자가 노출을 이해했는지, 명시적으로 수용했는지, 의존한다고 주장한 통제를 시험했는지이다.

마찬가지로 공급자 책임을 근거 없는 법적 판단으로 부풀려서는 안 된다. 공개 자료는 과실, 불법성, 규제 위반, SLA 위반, 계약상 책임, 전체 상실을 확립하지 않는다. 운영적 책임성은 어떤 통제가 실패했는지, 조직적으로 누가 그것을 소유했는지, 어떤 증거가 수리를 입증할지를 묻는다.

두 당사자는 의존성 계약에서 만난다. 공급자는 고객이 설계할 수 있을 만큼 충분히 장애 도메인, 복구 상태, 서비스 한계를 명확히 설명해야 한다. 고객은 "클라우드 중복성"이라는 일반적 약속에 의존하는 대신 그 기술적 속성을 사업 허용치, 백업, 에스컬레이션 트리거로 번역해야 한다.

소유권에는 평상시 운영뿐 아니라 복구 의사결정도 포함되어야 한다. 누군가는 재구축을 스로틀하고, 클러스터를 격리하고, 새 할당을 제한하고, 가용성보다 일관성을 우선할 권한을 가져야 한다. 이 결정들이 인시던트 중에 즉흥적으로 이루어진다면 통제 표면은 불완전하다.

고객도 대등한 결정권을 필요로 한다. 서비스 소유자는 누가 쓰기를 동결할 수 있고, 열화 모드를 가동할 수 있고, 트래픽을 옮길 수 있고, 데이터를 복원할 수 있고, 한계를 알릴 수 있는지 알아야 한다. 이용 불가한 승인이나 연습되지 않은 조율을 필요로 하는 기술적 대안은 신뢰할 수 있는 복구 용량이 아니다.

양측에는 완결의 공유 개념도 필요하다. 공급자에게 완결은 모든 영향받은 자원이 분류되고 통지되는 것이다. 고객에게 완결은 애플리케이션 정산, 백업 검증, 대기 작업 처리, 사업 기록 완전성 확인이다.

따라서 책임성 명제는 비난보다 더 좁고 더 강하다. 복구 수요가 알려진 범위에 들어맞고, 공유 의존성을 보호할 수 있고, 결정에 소유자가 있으며, 완료가 자원 수준 증거로 입증될 때에만 중복성이 완전해진다.

실천 가능한 복구 보증 프로그램

첫 번째 보증 과제는 복구 범위(envelope)를 정의하는 것이다. 범위는 시스템이 치유하도록 설계된 가장 큰 상관된 장애, 치유가 소모하는 자원, 허용되는 동시성, 보호된 서비스와 완전한 중복성이 돌아와야 하는 시간을 명시한다.

범위는 정량적이어야 한다. 교체 스토리지 용량, 복제 대역폭, 컨트롤 플레인 워커 가용성, 큐 깊이, 재시도율, 열화 자원 수를 포함할 수 있다. 용량이 "충분하다"는 진술은 그 한계와 가정이 이름으로 지정되기 전에는 시험 불가능하다.

테스트는 고객 데이터를 사용하지 않고 상관된 복제본 상실을 주입해야 한다. 시험은 재복제가 조율된 상태로 유지되는지, 백오프가 재시도를 분산시키는지, 예비 용량이 중요한 포그라운드 연산을 위해 남아 있는지 측정해야 한다. 연결이 돌아왔을 때 멈추지 않고 수리 백로그가 닫힐 때까지 계속해야 한다.

컨트롤 플레인 격리에는 별도 훈련이 필요하다. 하나의 열화된 클러스터가 느리고 비싼 호출을 만드는 동안 건강한 영역이 평상시 운영을 계속해야 한다. 검토자는 큐 분리, 워커 예약, 영역 인지 감축, 타임아웃 동작, 과부하 출처를 격리하는 운영자의 능력을 확인해야 한다.

경쟁 상태에는 스트레스와 반복이 필요하다. 평온한 훈련에서 한 번 성공하는 코드 경로는 연산이 이례적인 순서로 겹칠 때 실패할 수 있다. 시험은 타이밍, 재시도 물결, 노드 재시작, 부분 연결을 변화시키면서 상태 전이가 추가 노드 장애를 만드는지 기록해야 한다.

용량 증거는 안정 상태와 수리 상태 모두를 다뤄야 한다. 높은 평상시 활용률은 재구축에 필요한 공간을 소모할 수 있다. 예비 정책은 헤드룸이 물리적으로 존재하는지, 평상시 할당으로부터 어떻게 보호되는지, 복구 안전을 위해 운영자가 언제 성장을 제한해야 하는지 명시해야 한다.

훈련은 우선순위도 시험해야 한다. 보호된 기존 볼륨, 중복성이 줄어든 볼륨, 새 볼륨 생성, 스냅샷, 제어 연산이 경쟁할 수 있다. 팀은 어떤 작업이 먼저 스로틀되는지, 데이터 무결성 위험이 올라가면 그 선택이 어떻게 바뀌는지 알아야 한다.

자원 수준 정산이 최종 관문이다. 모든 테스트 볼륨은 알려진 상태로 끝나야 한다. 건강, 의도적 열화, 다른 출처에서 복원, 복구 불가 선언이다. 완전한 자원 원장 없이 집계 가용성만으로는 긴 꼬리가 닫혔다고 증명할 수 없다.

고객은 애플리케이션 계층에서 인접 훈련을 실행해야 한다. 스토리지 의존성을 잃고, 관리형 데이터베이스의 동작을 관찰하고, 백업 복원을 시험하고, 대기 쓰기를 정산하며, 단순 도달 가능성이 아니라 사업 서비스가 신뢰할 수 있게 되기까지의 시간을 측정해야 한다.

백업 테스트는 실패한 경로와 독립적이어야 한다. 같은 열화된 컨트롤 플레인을 필요로 하는 스냅샷이나 사본은 필요할 때 사용할 수 없을 수 있다. 시험은 접근 자격 증명, 보존, 복원 도구, 데이터 일관성, 파괴적 복구 선택을 내릴 권한을 가진 사람을 확인해야 한다.

커뮤니케이션도 훈련에 포함되어야 한다. 엔지니어는 정확한 범위, 분모, 불확실성, 다음 이정표를 담은 업데이트를 발행해야 한다. 고객 팀은 그 업데이트로부터 결정을 내려야 한다. 기술적 복구가 결국 성공하더라도, 추측해야 하는 지점은 증거 공백이다.

프로그램은 산출물을 보존해야 한다. 부하 그래프, 큐 이력, 용량 여유, 결정 로그, 자원 정산, 고객 대면 통지. 이 기록들은 복원력 주장을 다른 팀이 검토하고 반박할 수 있는 것으로 만든다.

보증은 불확실성도 보존해야 한다. 테스트가 완전한 지역 컨트롤 플레인 장애나 동시 두 번째 장애를 다루지 않는다면 보고서는 그렇게 말해야 한다. 시험된 조건에서 떨어진 광범위한 복원력 레이블보다 정직한 통제 경계가 더 나은 결정을 지지한다.

알려진 미지와 절제된 결론

다섯 출처 기록은 잘못된 트래픽 전환에서 노드 격리, 대규모 리미러링, 용량 고갈, 컨트롤 플레인 혼잡, 봉쇄, 단계적 복구, 작은 잔여 일관성 결과에 이르는 순서를 지지한다. 그 내부 순서의 주 출처는 AWS이다.

기록은 변경을 실행하거나 승인한 사람을 식별하지 않는다. 특정 경영 결정이 과실이었는지 확립하지 않는다. 법적, 규제적, 계약적, 정량 재무 결론을 지지하지 않는다.

영향받은 고객 수, 상실된 바이트, 상실된 기록, 완전한 영향 서비스 목록을 드러내지 않는다. 이 총계의 부재는 볼륨 비율을 사람, 거래, 경제적 가치로 번역할 수 없음을 의미한다.

기록은 이름 지정된 모든 웹사이트나 Heroku 애플리케이션이 동일한 장애 경로, 기간, 데이터 결과, 복구 품질을 겪었다는 것을 보여주지 않는다. 하류 증거는 의존성과 공개 영향을 보여줄 뿐 기술적 획일성을 보여주지 않는다.

Multi-AZ나 다중 리전 설계가 모든 효과를 제거했을 것임을 증명하지 않는다. 공개된 지역 컨트롤 플레인 장애와 Multi-AZ 장애 조치 버그는 보호 기능이 자체 의존성과 오케스트레이션 경로로 함께 시험되어야 하는 이유를 보여준다.

AWS가 발표한 개선 조치의 구현이나 효과를 검증하지 않는다. 또한 2011년 아키텍처, 동작, 통제, 고객 선택이 현재 AWS를 기술한다는 것을 확립하지 않는다. 현재 검토에는 새로운 아키텍처와 테스트 증거가 필요하다.

그 경계 안에서 결론은 단호하다. 시스템은 복제본과 대체 경로를 갖고 있다는 것만으로 복원력을 갖지 않는다. 복구의 워크로드를 통제하고, 격리를 보존하고, 안전한 우선순위를 선택하고, 모든 영향받은 자원의 상태를 증명할 수 있을 만큼만 복원력을 갖는다.

2011년 인시던트는 예비 복구 용량을 책임성 통제로 만들었다. 용량은 보호가 실패를 증폭시키지 않고 복원될 수 있는지를 결정했다. 증거는 운영자와 고객이 봉쇄와 완결을 구분할 수 있는지를 결정했다. 둘 다 사후 엔지니어링이 아니라 연속성 거버넌스에 속한다.

이미지 안내

스토리지 복구 용량과 단계적 격리를 주제로 한 AI 생성 개념적 편집 일러스트. AWS가 아니며, 실제 AWS 시설이 아니고, 2011년 4월 인시던트가 아니며, 검증된 EBS 또는 가용 영역 토폴로지가 아니고, 원인·규모·영향·데이터 결과·복구 조치의 증거가 아니다.

Codex 내장 이미지 생성을 통한 AI 생성 편집 일러스트. 기본 생성 1회와 정밀 편집 1회로 생성된 장비 표식을 제거하고 생성된 원거리 얼굴 프로필을 가렸다.

출처

  1. Amazon Web Services, "Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region," 2011년 4월 29일.https://aws.amazon.com/tw/message/65648/

  2. Heroku, "April 21 Outage Post-Mortem and Analysis," 2011년 4월 27일.https://www.heroku.com/blog/post_mortem_on_april_21_outage/

  3. TechCrunch, "Amazon EC2 goes down, taking with it Reddit, Foursquare and Quora," 2011년 4월 21일.https://techcrunch.com/2011/04/21/amazon-ec2-goes-down-taking-with-it-reddit-foursquare-and-quora-2/

  4. The Register, "Amazon: Some data won't be recovered after cloud outage," 2011년 4월 26일.https://www.theregister.com/off-prem/2011/04/26/amazon-some-data-wont-be-recovered-after-cloud-outage/388333

  5. InfoQ, "Amazon EC2 Outage Explained and Lessons Learned," 2011년 4월.https://www.infoq.com/news/2011/04/Amazon-EC2-Outage-Explained/