Amazon S3ダウンの原因、コマンドの入力ミスで多数のサーバを削除。サブシステム再起動に時間がかかり障害が長引く。AWSの報告を読み解く

AWSの米国東部リージョン（US-EAST-1、バージニア北部）において2月28日に発生したAmazon S3の障害の原因と対策などについて、AWSが報告を公開しました。

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

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

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

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

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

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

（新野注：原文は「one of the inputs to the command was entered incorrectly」とあり、playbookの内容を間違えたのか、あるいはそれを実行するためのコマンドを間違えたのかは判然としません）

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

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

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

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

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

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

障害の引き金になったのはコマンドの入力ミスによる多数のサーバの削除でした。しかしこのミスに対する自己修復機能が働かなかったこと、そして再起動と整合性確認に長時間かかってしまったことについて、AWSは報告で次のように書いています。

S3 subsystems are designed to support the removal or failure of significant capacity with little or no customer impact. We build our systems with the assumption that things will occasionally fail, and we rely on the ability to remove and replace capacity as one of our core operational processes.

S3サブシステムはその能力に甚大な障害や削除が発生したとしてもお客様に影響しない、もしくは小さな影響しかしないように設計されています。私たちは、こうした障害が起こりうるとしてシステムを構築しており、私たち自身も重要な運用プロセスの一部として、こうした削除や置換に対応する能力に依存しています。

While this is an operation that we have relied on to maintain our systems since the launch of S3, we have not completely restarted the index subsystem or the placement subsystem in our larger regions for many years.

Amazon S3サービス開始以来、システムのメンテナンスもこれに依存した運用をしてきており、大規模なリージョンにおけるインデックスサブシステムや配置サブシステムの完全なリスタートは何年も行われたことがありませんでした。

つまり、今回のような少数のサーバを削除するような操作は通常のメンテナンスとしてこれまでずっと行われてきていたと。

S3 has experienced massive growth over the last several years and the process of restarting these services and running the necessary safety checks to validate the integrity of the metadata took longer than expected.

S3はこの数年で急激な成長を遂げ、これらサービスの再起動とセーフティチェックのための整合性の検証にかかる時間が予想よりも長くかかってしまいました。

だからこそ想定しなかった再起動が発生したときに、どれくらい時間がかかってしまうのか予想できなかったし、それを短時間に圧縮するような改善も行われてこなかった、ということなのでしょう。

サーバの削除を慎重にし、S3の分割管理を改善

AWSは今回の障害を受けて、以下のような改善を行っていくと説明しています。

• ツールがサーバを削除する速度を遅くすると同時に、システムの稼働維持に最低限必要な台数を超えたサーバを削除しないようにセーフティガードを追加した。ほかのツールにも同様のセーフティガードを導入した。
• S3のサブシステムを改善し、復旧時間がもっと短くなるようにした。
• S3は「セル」と呼ばれる要素に分割されて管理されているが、それでも今回の復帰に時間がかかりすぎることが判明した。そのため、今年後半に予定されていたさらなるセル分割作業の優先順位を高め、すぐさま取りかかるようにした。