잠재 버그가 Gmail의 일상적인 데이터센터 유지보수를 3시간 전 세계 장애로 바꾸다

2009년 2월 24일, Gmail이 전 세계 사용자에게서 작동하지 않았다. Google의 Apps 고객 대상 사고 보고서에 따르면 장애는 대략 GMT 오전 9시부터 정오까지 — 약 3시간 — 이었으며, 복구가 순차적으로 이루어져 개별 사용자의 접속 불가 기간은 각기 달랐다. 데이터 손실은 없었다.

작동 원리는 최근의 두 가지 결정이 상호작용한 것이었다. Google은 사용자 데이터가 어디에 위치하는지 최적화하는 새 소프트웨어를 배포했다. 그날 아침 엔지니어들은 유럽의 한 데이터센터에서 일상적인 유지보수를 시작했다. 트래픽이 자동으로 다른 곳으로 이동하므로 보이지 않게 설계된 작업이었다. 그러나 그 이동이 새로운 지역성 코드의 잠재 버그를 촉발했다. 목적지가 과부하되었고, 트래픽이 자동으로 다시 이동하면서 과부하가 데이터센터에서 데이터센터로 하류로 연쇄 확산되었다. 엔지니어들이 연쇄 확산을 통제하는 데 약 1시간이 걸렸고, 모든 것을 재분배하는 데는 더 오래 걸렸다.

Google은 당시로서는 이례적으로 공개적으로 사후 처리를 했다. Gmail 사이트 신뢰성 관리자 Acacio Cruz는 같은 날 공식 Gmail 블로그에서 연쇄 확산을 설명했고, Google은 Apps 고객을 위한 공식 사고 보고서를 발표했다. 또한 해당 서비스에 아직 존재하지 않았던 것 — 공개 상태 대시보드 — 을 구축하겠다고 약속하며, 클라우드 제공자가 장애 중에 고객에게 침묵과 수리만이 아니라 신속한 정보를 제공할 의무가 있음을 인정했다.

2009년 2월 24일 Gmail이 최대 3시간 동안 접속 불가, 데이터센터별로 복구가 순차적으로 이루어짐; 데이터 손실 없음

장애 조치 경로 — 트래픽을 두 번째 데이터센터로 이동하는 것 — 가 새로운 데이터 지역성 소프트웨어에 대해 검증되지 않았기 때문에 잠재 버그가 유지보수 중에만 발동했다.

과부하 대응이 장애를 증폭시켰다. 사용자가 자동으로 다시 이동하면서 각 목적지가 동일한 과부하 상태에 도달해 하류로 확산되었다.

유지보수 설계는 데이터센터 간의 깔끔한 인계를 전제했지만, 새로운 최적화 코드가 장애 조치가 기반으로 삼았던 전제를 바꾸어 놓았다.

커뮤니케이션이 사고보다 늦었다. Google 자체의 사후 분석은 장애를 신속히 인정할 필요가 있음을 인정했고, 이것이 직접적으로 Apps 상태 대시보드로 이어졌다.

장애 조치 경로는 주 경로만큼 충분한 테스트가 필요하다. 데이터 위치를 재배치하는 새 코드가 일상적인 유지보수를 연쇄 확산으로 바꾸어 놓았다. 그리고 클라우드 장애에는 공개된 사고 보고서가 필요하다.

Google은 버그를 수정하고 변경 사항을 배포했으며, 사고 보고서를 발표하고 몇 주 후 Google Apps 상태 대시보드를 출시하여 공개 장애 커뮤니케이션을 제도화했다. 'gfail' 사건은 대부분의 소비자 웹 서비스가 아무런 설명도 제공하지 않던 시기에 원인과 개선 조치를 고객에게 공식적으로 설명하는 클라우드 사고 보고의 초기 템플릿이 되었다.