潜在バグが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」事件は、ほとんどのコンシューマー向けウェブサービスが説明を一切提供していなかった時代に、原因と改善措置について顧客向けに正式に説明するクラウド障害報告の初期のテンプレートとなった。