日本時間3月1日未明に米国東部（バージニア北部、US-EAST-1）リージョンにおいて発生いたしましたサービス障害に関する追加情報についてお伝えいたします。
この度、Amazon Simple Storage Service (S3) チームが S3 の請求システムの処理に通常よりも時間がかかるという問題のデバッグを進めておりました。
その過程におきまして、9:37AM PST(日本時間 2:37AM)に、適切に権限を与えられたS3チームメンバーが確立された手順に従い、S3 の請求システムが利用するS3サブシステムを構成する少数のサーバを削除するコマンドを実行いたしましたが、その際、コマンドへの入力が不適切であったため、想定よりも多くのサーバが削除される結果となりました。
今回誤って削除されたサーバは２つのS3サブシステムに関わるもので、１つは、Index（インデックス） サブシステムであり、当該リージョンにおいて全てのS3オブジェクトのメタデータやローケーション情報を管理し、全てのGET, LIST, PUT および DELETE リクエストを提供するものでした。もう１つは、Placement(配置) サブシステムであり、新規ストレージのアロケーションを管理し、Indexサブシステムに処理を要求するものでした。こちらは PUTリクエストの際、新規オブジェクトのためにストレージを割り当てるために利用されるサブシステムとなります。
キャパシティのかなりの部分が削除されるとこれらのシステムは再起動が必要となり、サブシステムが再起動している間、S3 はサービスリクエストを処理できない状態となっておりました。
また、S3 API が利用できなくなったことから、S3コンソール、Amazon Elastic Compute Cloud (EC2)の新規インスタンスの起動、Amazon Elastic Block Store (EBS) ボリューム (S3スナップショットからデータが必要であった場合)、AWS Lambdaを含め、US-EAST-1リージョンにおける、ストレージとしてS3を利用するその他のAWSサービスにも影響がございました。
S3 サブシステム群は、削除や顕著なキャパシティ障害の際にも、お客様への影響が軽微または影響のないよう設計されております。また、私どものシステムは障害が発生した場合のリカバリ対策も含めて構築しており、コアオペレーショナルプロセスの１つとしてキャパシティの削除や置き換えを行える能力に重きを置いてきました。本オペレーションは、S3のサービス開始以来システムを維持するために頼ってきたものではありますが、一方、長年にわたり広域なリージョンにあるIndexサブシステムやPlacementサブシステムを完全に再起動する機会はありませんでした。S3 は過去数年にわたる大規模な成長を経て、サービス再起動のプロセスおよびメタデータの正常性確認に求められる安全性のチェックに想定以上の時間を要する結果となりました。
今回影響を受けた2つのサブシステムのうち最初にIndex サブシステムの再起動を行いまして、12:26PM PST（日本時間 5:26AM）までに S3 GET, LIST および DELETE リクエストを提供するための十分なキャパシティを確保いたしました。 その後、1:18PM PST（日本時間 6:18AM）までに Indexサブシステムの復旧が完了し、GET, LIST および DELETE API が通常稼働する状態となりました。
S3 PUT API は Placementサブシステムを必要としますが、Placementサブシステムは Indexサブシステムの機能回復後に復旧が開始され、1:54PM PST（日本時間 6:54AM）に復旧が完了しております。この時点で、S3 が通常稼働し、その他のAWSサービスも復旧を開始いたしました。尚、幾つかのサービスには S3 障害の間にバックログが蓄積されていたことから完全復旧までに時間を要したものがございます。
この度の結果をもちまして、改善のため現在幾つかの変更を進めております。
今回のケースはキャパシティ削除がキーとなるオペレーションであったことから、ツールが短期間の間に多くのキャパシティを削除することが許可されておりました。当該ツールを改修し、キャパシティ削除をより時間をかけて実施するように変更するとともに、サブシステムが必要とするキャパシティレベルを下回らないようキャパシティ低下を予防するセーフガードを設けております。本改修により、今後、今回と同様にツールへのインプットに誤りがあったケースにも同事象を発生させないよう予防いたします。また、他のツールにつきましても同様にセーフティチェックを設けているか確認を進めております。
次に、重要な S3 サブシステムの復旧時間の改善についても変更を進めております。
あらゆる障害から迅速にサービスを復旧するためにこれまでに複数の技術を採用しております。最も重要なものの１つとしまして、サービスをセルと呼ばれる小さなパーティションに分解する取り組みが挙げられます。サービスをセルの単位に分解することで、エンジニアチームが大規模なサービスであってもサブシステムであっても復旧プロセスを徹底的にテスト、評価できるようになります。S3が大規模化していることから、チームは影響範囲を狭め復旧を改善するために、サービスのパーツをより小さなセルへ分解する多くの活動を行っております。
しかしながら、今回の障害の間、Indexサブシステムの復旧時間は私どもの想定よりもまだ長いものでしたので、今年中に計画しておりましたIndexサブシステムのさらなるパーティショニングを直ちに実施するよう優先度を変更しております。
また、今回の障害発生から 11:37AM PST（日本時間 4:37AM）までの間、AWS Service Health Dashboard (SHD) の管理コンソールが Amazon S3 上にあったことから、SHDにおいて各サービスのステータスをアップデートできない状態にありました。そのため、SHD上で各サービスのステータスがアップデートされるまでの間、AWS Twitter feed (@AWSCloud) と SHD上のバナーテキストによってステータスのコミュニケーションを実施いたしました。
障害等が発生した際に SHD はお客様に重要な可視性を提供するものと理解しておりますため、SHD 管理コンソールを複数のAWSリージョンで稼働するよう変更しております。
末筆となりますが、この度の障害によりお客様に多大なるご迷惑をおかけいたしましたことをお詫び申し上げます。
これまで長年にわたり Amazon S3 可用性の維持に努めて参りまして、本サービスがお客様並びにエンドユーザ様のビジネスにどれほどクリティカルであるかを理解しております。
この度の事象から学んだこと全てに取り組み、今後の改善に役立てて参ります。