AWSのS3クラウドストレージが4時間にわたってダウンした件は、当然ながら、強い批判を浴びた。AWSは検証レポートを発表し、この事件について原因と経過を詳しく説明した。技術的情報と将来に向けての防止策も含まれている。
直接の原因は、やや平凡な理由だが、ヒューマンエラーだった。あるエンジニア―ここではジョー（仮名）と呼んでおく―が間違ったコマンドを入力してしまったということだ。ジョーはあるサブシステムをシャットダウンするつもりだった。それ自体は日常行われるオペレーションだった。しかし月曜日、バージニア州北部データセンターではルーチンワークが大変な問題を引き起こした。
ジョーは正規の特権ユーザーであるため、システムをシャットダウンするコマンドを入力する資格があった。ただしこの作業はAmazonが「確立された手順書（established playbook）」に従ったもので、ここではS3サブシステムの少数のサーバーを停止することが意図されていた。ところがジョーは誤って多数のサーバーを停止するコマンドを入力してしまった。
素人の表現でいえば、地獄のような騒ぎが持ち上がった。
Amazonはもっと技術的な表現をしているが、問題のエラーはカスケードしてバージニア州北部データセンター全体に影響を与えることになった。ジョーのエラーは決定的に重要なサブシステムを停止してしまい、センターのデータ保存能力の大きな部分を失わせた。システムは再起動を余儀なくされたが、この間S3はリクエストを処理することができなくなった。AWS自身のダッシュボードも機能を失い（これはかなり恥ずかしい事態だ）、S3の稼働状態を確認できなくなった。
そして外部の世界も影響を感じ始めた。一般ユーザーはお気に入りのサイトが開かなかったり、アプリが異常な動作をしたりするのに気づいた。
昼頃、AWSはサービスの復旧に全力を上げていたが、なにぶんシステムの規模が大きすぎた。AWSは何年にもわたってダウンしたことがなく、従って全システムの再起動を行ったこともなかった。S3はいわば自分自身の成功の犠牲になった。再起動をかけるとシステムは安全性のチェックとメタデータの整合性の確認を始めた。ところがこれは予想外に時間を必要とした。
こうしたヒューマンエラーによる事故の再発を防ぐためにAWSでは運営手順に変更を加えるという。レポートによれば「この〔事故の原因となった〕ツールに修正を加え、作動速度を遅くし安全策を追加した。〔停止要求に対し〕配下の最小限のレベルにおけるサブシステムのみを停止させるようにした」という。これでジョーのような慌て者が同様のミスをするのは防げるだろう。
しかしAWSでは、もっと根本的にS3のサブシステムの構成の見直しも行っている。サブシステムをセル（cell）と呼ばれるさらに多数の区画に分割し、一挙に大量のサーバーが停止されないようにするという。これは過去にも試みられたことがあったはずだ。ともかくS3のサブシステムは許容可能な時間で再起動するには大きすぎた。
AWSのレポートは謝罪と改善の約束で締めくくられている。単純なヒューマンエラーで始まったものの、影響が連鎖反応で急速にデータセンター全体に拡大して大事故となった。AWSのシステムがこの種の深刻なエラーを想定せず、したがってそのカスケードを防ぐ機能が組み込まれていなかったのが惨事の根本的な原因だったようだ。
画像： Colin Anderson/Getty Images
[原文へ]
（翻訳：滑川海彦@Facebook Google+）
