2011年のストレージ障害でGmailの受信トレイが空に、復元できたのはオフラインのテープバックアップだけだった

2011年2月27日、Gmailのユーザーはログインすると受信トレイが空になっていることに気づき始めた。原因は、予期しない不具合を抱えた定例のストレージソフトウェア更新だった。Googleは問題が表面化するとすぐに配備を停止し、旧バージョンに戻したが、被害はすでに生じていた。当初の推定でGmailのユーザーベースの0.08%にあたるアカウント、およそ15万件からメールが削除され、後に0.02%へと下方修正された。

事後分析で気まずかったのは、コピーが役に立たなかった理由だった。Gmailはすべてのメールボックスの複数のコピーを複数のデータセンターに保持している。しかしレプリカは、同じソフトウェアで動作している限り独立ではない。「まれなケースでは、ソフトウェアの不具合がデータの複数のコピーに影響することがあります」とGoogleのエンジニアリング担当バイスプレジデント、ベン・トレイナーは書いている。無傷のコピーがあったのはテープ上だけだった。オフラインであるため、不具合の影響を受けなかった。テープは遅く、そのため復元にはミリ秒ではなく約30時間を要した。影響を受けたユーザーの残り0.012%は3月1日までにテープから復元された。

Googleは「メールが失われたことは決してない」と強調し、データ損失インシデントの基準からすればこの話は良い結末を迎えた。しかしこの出来事は、クラウドのレプリケーションが安全を意味するという直感を打ち砕いた。メールの消失やログインの問題に関する苦情は4日目にまで続いた。これは今も、相関したレプリカ障害の標準的な引用例であり続けている。冗長性が守るのはマシンの故障であり、同じ不具合がどこでも動作することではない。

当初の推定でユーザーの0.08%（約15万アカウント、後に0.02%へ修正）が受信トレイが空になるのを目にし、テープからの復元には約30時間を要した。

ストレージの更新はデータを削除しうる不具合を持ち込み、欠陥が発見される前に配備が稼働中のシステムに到達した。

Gmailの複数のコピーはすべて同じストレージソフトウェアで動作していたため、1つの不具合がデータセンターをまたいだ複数のレプリカに影響しうる状態だった。

不具合が届きえなかった唯一のコピーはオフラインのテープだった。Googleがレプリケーションにもかかわらず維持していた復旧経路であり、これがメールボックスを救った。

テープからの復元は本質的に遅く、1回の不適切な配備をユーザーに見える形での数日間の被害に引き延ばした。

レプリカが守るのはハードウェアの故障であり、ソフトウェアではない。不具合は複数のコピーを一度に破損させうるため、ソフトウェアの影響範囲の外に復旧経路を1つ確保しておくべきだ。Gmailの場合、それがオフラインのテープだった。

Googleはテープからの復元を完了し、この障害について異例なほど率直な説明をOfficial Gmail Blogで公開した。このインシデントは、信頼性エンジニアリングにおいて、少なくとも1つの復旧媒体を本番ソフトウェアの障害領域の外に置くべきだという定番の論拠となった。これを機にテープはクラウド時代の語彙に入った。Gmailのレプリケーションモデル自体は変わらなかった。変わったのは、複数コピーシステムにおける相関したソフトウェア障害に対する警戒心だった。