Heroku는 모든 고객을 단일 AWS 리전에서 운영했다 — 그리고 EBS가 80시간 동안 고장 났다

2011년 4월 21일 8:15 UTC, Heroku 전반에 모니터링 경보가 울렸다. 웹, 캐싱, 라우팅 서비스에 타임아웃이 발생하고 있었다. 원인은 상류에 있었다. AWS의 자체 설명에 따르면, 12:47 AM PDT에 미국 동부의 한 가용 영역에서 AWS 네트워크 변경이 이루어져 기본 EBS 트래픽이 용량이 더 작은 복제 네트워크로 옮겨졌고, 이로 인해 EBS 노드가 고립되면서 재미러링 폭풍이 촉발되어 해당 영역 볼륨의 13%가 멈춰 있었다.

EC2 자체는 약 12시간 만에 복구되었지만, EBS는 80시간 넘게 성능 저하 상태로 남았다. 전체 플랫폼을 미국 동부에서 운영하고 데이터베이스를 EBS에 두었던 Heroku에는 장애 조치할 곳이 없었다. 두 번째 리전이 없었기 때문이다. 대부분의 애플리케이션은 16시간 이내에 복구되었고, 공유 데이터베이스 서버를 사용하는 무료 앱은 최대 3일이 걸렸다.

Heroku의 사후 분석은 뻔한 변명을 거부했다. "Heroku는 고객에게 영향을 준 다운타임에 대해 100% 책임을 집니다." Heroku가 도출한 세 가지 교훈은 다음과 같다. 한 리전 내의 가용 영역은 팀이 가정했던 방식으로 위험을 분할하지 못한다는 것, 블록 스토리지는 클라우드 친화적인 기술이 아니라는 것, 그리고 인프라를 추상화하겠다고 약속한 플랫폼은 그 인프라가 실패할 때 그 결과를 감당해야 한다는 것이다.

대부분의 앱은 16시간 이내에 복구되었고, 공유 데이터베이스를 사용하는 무료 앱은 최대 3일 동안 다운 상태로 유지되었으며, 미국 동부 EBS는 80시간 이상 성능 저하 상태였다

전체 플랫폼이 단일 AWS 리전에 있었고, 가용 영역은 Heroku가 분할되어 있다고 가정했던 장애 모드를 공유하고 있는 것으로 드러났다.

상태 저장 서비스는 EBS 위에 있었는데, EBS는 EC2가 복구된 후에도 오랫동안 고장 상태로 남았다. 이는 Heroku가 우회할 수도, 장애 도중에 교체할 수도 없었던 의존성이었다.

표준 대응 절차, 즉 비정상 인스턴스를 종료하고 교체한 뒤 AWS를 기다리는 방식은 장애가 한두 시간 지속된다고 가정했다. 이번 장애는 며칠 동안 지속되었다.

멀티 리전은 가용성 측면의 이득이 적은 대형 프로젝트로 수년간 우선순위에서 밀려 있었다. 4월의 장애는 그 가치를 단 한 번의 주말에 재평가하게 만들었다.

하나의 클라우드 리전 내 가용 영역은 이중화가 아니다. 모든 고객이 같은 리전의 같은 블록 스토리지에서 운영된다면, 상류의 네트워크 실수 하나가 모두의 장애가 된다.

Heroku는 멀티 리전을 훨씬 더 높은 우선순위로 다루고 EBS에 대한 의존성을 줄이겠다고 밝혔으며, 플랫폼이 IaaS 수준의 장애에서 살아남을 수 있도록 하는 아키텍처 변경을 시작했다. AWS의 이 사건 요약은 업계에서 가장 널리 읽힌 장애 분석 중 하나가 되었고, "모든 것을 한 리전에 두지 말라"는 표준 클라우드 조언이 되었다. 그럼에도 Heroku는 이후 수년간 강한 단일 리전 체제를 유지했고, Heroku가 확인한 집중 문제는 이후의 장애에서도 계속 다시 나타났다.