AWS S3の長時間サービス停止の原因はエンジニアの入力ミス

Amazon.com傘下のAWSが、2月28日にS3で起きた約4時間のサービス停止の原因と対策について説明した。原因はデバッグの際の入力ミスで、意図した以上の台数のサーバの接続を解除してしまったというものだった。

[佐藤由紀子，ITmedia]

　米Amazon.com傘下のAWSは3月2日（米太平洋時間）、2月28日にクラウドストレージサービス「S3」の北バージニアリージョン（US-EAST-1）で起きた大規模なサービス停止の原因と対策を発表した。

　28日午前11時20分ごろ発生したこの問題は復旧までに約4時間かかり、同サービスを利用するIFTTT、Quora、Medium、Imgur、GitHubなど、多数のサービスが影響を受けた。

ダウン中のステータス告知

　原因は、エンジニアの入力ミスだった。

　同日の午前9時37分、S3の課金システムのデバッグ中、S3のサブシステム用の少数のサーバの接続を解除しようとした際、コマンドの入力を誤り、意図したよりも多数のサーバを解除してしまった。その中の2つのサーバが、同リージョン内のすべてのS3オブジェクトのメタデータと位置情報を管理するインデックスサブシステムと、運営にとって重要な配置用サブシステムだったため問題が大きくなった。

　問題解決のためにはこれらのサーバを再起動する必要があり、再起動するまでの間、S3でサービスリクエストが受けられなくなっていた。S3 APIも利用できなかったため、EC2、EBS、AWS Lambdaにも影響が及んだ。

　S3のサブシステムは、ある程度のサーバ解除では影響が出ないよう設計されているが、ここ数年で利用が急拡大したため、再起動にかかる時間が予想以上に長くなっていたと同社は説明する。

　今回の事故を受け、サーバ接続解除だけでなく、システム変更に関わるすべての入力でミスを防ぐようツールを変更した。また、S3の主要サブシステムのリカバリ時間を短縮するための改善も行った。

　また、AWSのService Health Dashboard（SHD）もこの問題の影響で正しく表示できなかった（その間公式Twitterアカウントで進捗をツイートしていた）ため、SHDのコンソールを複数のAWSリージョンで稼働するよう変更した。

　同社は顧客に謝罪し、今回の事故から学んだことを最大限に生かしてサービスを改善していくと約束した。