Amazon S3がダウンした直接の原因は、Amazon S3課金システムのデバッグ作業中に入力したコマンドのミスによって多数のサーバが削除されたことでした。また、それによって引き起こされたサブシステムの再起動に時間がかかったことが、障害を長引かせる要因になっています。

　この記事ではAWSの報告内容を整理し、発生した出来事を時系列でみたあと、障害の背景にあった技術的な要因と対策を紹介します。

コマンドの入力ミスで多数のサーバを削除、復帰にも長時間かかる

　そもそもの障害の発端は、Amazon S3課金システムの処理速度が想定よりも遅くなっていたため、Amazon S3チームがデバッグ作業を行っていたことでした。

・2月28日 午前9時37分（太平洋標準時）

　デバッグ作業において、Amazon S3課金プロセスを実行する一部のサブシステムに対して、少数のサーバを削除するコマンド群（原文では「playbook」と表記されているため、AnsibleのPlaybook、あるいは同様に一連のコマンドを記したスクリプトファイルと思われる）を実行。

　このとき入力されたコマンドの1つに間違いがあり、Amazon S3のメタデータを管理していた「インデックスサブシステム」と、オブジェクトを保存する位置を指定する「配置サブシステム」のサーバ群の大半が削除されてしまいます。


　サブシステムはある程度の障害に対する自動回復の能力を備えていましたが、その限界を超えて多数のサーバが削除されてしまったため、それぞれ完全な再起動（フルリスタート）が必要となります。

　そこで再起動が実行されました。この2つのサブシステムが完全に復帰するまでAmazon S3の処理が停止。同一リージョン内にはAmazon S3のストレージサービスに依存して稼働するほかのサービス、例えばAmazon EC2、Amazon EBS、AWS Lambdaなど多数のサービスにも影響が出ました。

　この再起動とその後の整合性確認の処理には予想以上に時間がかかってしまい、障害が長引く要因となってしまいました。

・12時26分

　約3時間後、インデックスサブシステムが十分な能力を発揮するまでに復帰。そこから約50分後の13時18分には完全に正常状態へ復帰。

・13時54分

　配置サブシステムも復帰。この時点でようやくAmazon S3が通常動作へ復帰し、影響を受けていたそのほかのサービスも復帰を開始しました。

なにが障害をここまで大きくしたのか？