Google App Engineダウンの原因はデータセンターの電源故障。さらに復旧手順のミスが重なった

2010年3月 9日

米国時間の2月24日、グーグルが提供するGoogle App Engineのデータストアが障害により停止するという事故が発生しました。この事故の状況については、そのときの記事「Google App Engineが昨夜ダウン。障害がごく一部に残り、対応チームは現在も作業中」」で詳しく報じました。

それから2週間、グーグルが原因と対策について書いたドキュメントをGoogle Groupに「Post-mortem for February 24th, 2010 outage - Google App Engine | Google Groups」というメッセージとしてポストされました。

原因はデータセンターの電源障害

グーグルの解説によると、今回の障害の直接の原因はプライマリデータセンターの電源障害によるもの。もともとApp Engineのインフラはこうした障害に対して素早く復旧できるように設計されていたそうなのですが、この状況に対するための手順書にも問題があり、それらが重なったことが復旧まで時間がかかった原因だと説明されています。

グーグルは今回の復旧対応について次のように自己分析しています。以下はポストされたメッセージの該当部分を翻訳したものです。

こうした障害に対する手順は用意していたにもかかわらず、呼び出しを受けたスタッフ（オンコールスタッフ）はこの手順について詳しくなく、またこうしたタイプの障害に対応するためのトレーニングも十分に受けていなかった。
最近、改良版マルチホーミングへのデータストアの移行と、こうした重大な障害に対する対応手順の改善を行った。しかしながら、フェイルオーバー中のデータストアに対応する手順を詳しく解説したいくつかのドキュメントが、間違った古いコンフィグレーションを参照していた。このことが対応中の混乱の原因となった。
明確にいつ、どのような状況で、呼び出しを受けたスタッフは突発的なフェイルオーバー時にどうユーザー対応を行うべきなのか、という方針にプロダクションチーム（App Engine担当チームのことか？）が同意していなかった。そのため、一部のデータセンター業務が呼び戻される、といったことがあった。
データセンターの全体ではなくいくつかのマシンに対して発生した電源障害への対応計画に失敗していた（今回のケースでは全体の25％に障害が発生した）。特に今回はこれがデータセンターの障害状況や復帰時間の分析ミスを誘導した。
結果的にはバックアップデータセンターへとトラフィックを変更できたものの、データストア内のわずかなエンティティグループ、約25のアプリケーションに属するそれらがフェイルオーバーの後に不正な状態に陥ってしまった。これはデータストア内の0.00002％以下だったが。

訓練と手順書を改善

グーグルは上記の問題を改善するために、以下の改善をするとのことです。

すべてのオンコールスタッフに対して日常訓練を導入する。複雑な手順やレアケースなども含んだ訓練で、これを完了していないスタッフは、オンコールスタッフのルーチンに入れない。
必要とされるすべての手順書について、すべての手順が適切かを2カ月ごとに監査するようにし、日付を過ぎたドキュメントには破棄の印を付ける。
オンコールスタッフを迅速に支援するための明確なポリシーを決め、障害発生中のユーザー対応などに関する明確な意志決定をする。これにより確実かつ速やかに緊急対応を行うことが可能になる。

グーグルのように最先端かつ自動化が進んだデータセンターといえども、大規模なフェイルオーバーが完全に自動化されているわけではないのですね。しかも、かなりの手順が人手によって行われ、そこにミスが入り込むほど複雑な手順になっている、というのは意外でした。