2011년의 한 스토리지 버그가 Gmail 받은편지함을 비웠고, 오프라인 테이프 백업만이 메일을 되살렸다

2011년 2월 27일, Gmail 사용자들은 로그인했을 때 받은편지함이 비어 있는 것을 발견하기 시작했다. 원인은 예기치 않은 버그를 포함한 일상적인 스토리지 소프트웨어 업데이트였다. Google은 문제가 드러나자마자 배포를 중단하고 이전 버전으로 되돌렸지만, 피해는 이미 발생한 뒤였다. 처음 추정으로 Gmail 사용자 기반의 0.08%에 해당하는 계정, 대략 15만 개 계정에서 메일이 삭제되었으며, 이 수치는 나중에 0.02%로 하향 수정되었다.

사후 분석에서 불편한 부분은 왜 사본들이 도움이 되지 않았는가였다. Gmail은 모든 사서함의 여러 사본을 여러 데이터 센터에 보관한다. 그러나 복제본은 같은 소프트웨어를 실행할 때 독립적이지 않다. Google의 엔지니어링 부사장 Ben Treynor는 "드문 경우에는 소프트웨어 버그가 데이터의 여러 사본에 영향을 줄 수 있다"고 썼다. 깨끗한 사본은 테이프에만 있었다. 오프라인이었기에 버그로부터 면역이 있었다. 테이프는 느리기 때문에 복구에는 밀리초가 아니라 약 30시간이 걸렸다. 영향을 받은 나머지 0.012%의 사용자는 3월 1일까지 테이프에서 복구되었다.

Google은 "이메일은 결코 유실되지 않았다"고 강조했고, 데이터 손실 사고의 기준으로 보면 이 이야기는 잘 끝났다. 그러나 이 사건은 클라우드 복제가 안전을 의미한다는 직관에 구멍을 냈으며, 사라진 메일과 로그인 문제에 대한 불만은 나흘째까지 이어졌다. 이 사건은 상관된 복제본 실패의 표준 사례로 남아 있다. 중복성은 기계가 고장 나는 것에 대비하는 것이지, 같은 버그가 모든 곳에서 실행되는 것에 대비하는 것이 아니다.

처음 추정으로 사용자의 0.08%(약 15만 개 계정, 나중에 0.02%로 수정)가 빈 받은편지함을 보았고, 테이프 복구에는 약 30시간이 걸렸다.

스토리지 업데이트가 데이터를 삭제할 수 있는 버그를 도입했고, 결함이 발견되기 전에 배포가 운영 시스템에 도달했다.

Gmail의 여러 사본은 모두 같은 스토리지 소프트웨어를 실행했기 때문에 하나의 버그가 데이터 센터 전반의 여러 복제본에 영향을 줄 수 있었다.

버그가 닿을 수 없었던 유일한 사본은 오프라인 테이프였다. Google이 복제에도 불구하고 유지한 복구 경로였고, 이것이 사서함을 구했다.

테이프에서의 복구는 본질적으로 느렸고, 한 번의 잘못된 배포가 사용자에게 보이는 피해로 며칠간 이어졌다.

복제본은 하드웨어 고장을 막아 주지만 소프트웨어 고장은 막지 못한다. 버그는 여러 사본을 동시에 손상시킬 수 있으므로, 소프트웨어의 영향 범위 밖에 복구 경로를 하나 이상 두어야 한다. Gmail의 경우 그것이 오프라인 테이프였다.

Google은 테이프에서 복구를 완료하고 Official Gmail Blog에 이례적으로 솔직한 실패 경위를 게시했다. 이 사건은 신뢰성 엔지니어링에서 운영 소프트웨어의 실패 영역 밖에 적어도 하나의 복구 매체를 두어야 한다는 상시적 논거가 되었다. 이 사건 덕분에 테이프는 클라우드 시대의 어휘에 들어왔다. Gmail의 복제 모델 자체는 바뀌지 않았고, 바뀐 것은 다중 사본 시스템에서 상관된 소프트웨어 결함에 대한 경계심이었다.