クラウドは数万台ものサーバが稼働する巨大なデータセンターによって運営されており、そのかなりの部分が自動化されているといわれています。いわれています、というのは、データセンターの運用ノウハウがあまり公開されることはないためですが、例えばマイクロソフトは最新のデータセンターでは管理者一人あたり約5000台のサーバを管理しているとされています。（参考：数十万台のサーバを備える最新データセンター、管理はわずか数十人？ − Publickey）

こうした規模で管理するには、徹底した自動化と効率化が不可欠です。

と同時に、こうした大規模なクラウドでは一部に障害が発生しても全体としては動作し続けるように、設計から実装までさまざまな工夫がされています。

こうした機構を備えたクラウドであっても、まれにダウンすることがあります。2月に起きたのは、グーグルがプログラマ向けに提供しているGoogle App Engineが長時間ダウンするという事故でした。

対応スタッフが訓練不足で、マニュアルも間違っていた

Google App Engineのダウンは、米国時間の2月24日午前8時前（日本時間25日午前1時前）に発生し、3時間以上解決されませんでした。

この障害の原因についての分析と対応策を、グーグルは発生から2週間後に公開しました。（Post-mortem for February 24th, 2010 outage）

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

具体的には、次のような問題が内部で起きていたそうです。

• 障害に対する手順は用意していたにもかかわらず、呼び出しを受けたスタッフ（オンコールスタッフ）はこの手順について詳しくなく、またこうしたタイプの障害に対応するためのトレーニングも十分に受けていなかった。
• 最近、改良版マルチホーミングへのデータストアの移行と、こうした重大な障害に対する対応手順の改善を行った。しかしながら、フェイルオーバー中のデータストアに対応する手順を詳しく解説したいくつかのドキュメントが、間違った古いコンフィグレーションを参照していた。このことが対応中の混乱の原因となった。
• 明確にいつ、どのような状況で、呼び出しを受けたスタッフは突発的なフェイルオーバー時にどうユーザー対応を行うべきなのか、という方針に本番運用チームが同意していなかった。

ふだんの運用は自動化されていたとしても、やはり突発的な障害への対応についてはスタッフのトレーニングとマニュアルでの対応が必要で、しかしそれが不十分だったことが原因だと分析しています。

訓練と手順書を改善

これを踏まえて、グーグルではすべてのオンコールスタッフに対して日常的な訓練を導入し、またすべての手順書を定期的に見直して日付を過ぎたものは確実に破棄する、といった改善策を導入すると表明しています。

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

当たり前ですが、クラウドもまだまだ人の手によって運用されているのですね。

文・新野淳一（ブログ「Publickey」 Blogger in Chief）