AWS、米国東部でのAmazon S3ダウンのきっかけはコマンド入力ミスと説明なぜ自動修復は機能しなかった?

米Amazon Web Services(AWS)は2017年3月2日(現地時間、以下同)、2月28日に数時間にわたって発生した米国東部(US-EAST-1)リージョンにおけるストレージシステム(Amazon S3)の障害について、同社のWebサイトにその経緯を説明した。

» 2017年03月03日 07時32分 公開
[三木泉@IT]

 米Amazon Web Services(AWS)は2017年3月2日(現地時間、以下同)、2月28日に数時間にわたって発生した米国東部(US-EAST-1)リージョンにおけるストレージシステム(Amazon S3)の障害について、同社のWebサイトでその経緯と対策を説明した。これによると、きっかけは運用担当者のコマンド入力ミスだという。だが、真の問題はサービスの急速な成長に対応しきれなかったことのようだ。以下では、この説明を要約してお届けする。

 2月28日の朝、S3に関する請求処理の速度を改善するため、S3側の関連サブシステムを担う少数のサーバを、手順書に基づいて運用担当者が削除しようとした。だが、コマンド入力ミスで、想定よりも多くのサーバを削除してしまった。その中にはインデックスサーバ(メタデータ情報管理サーバ)と、メタデータを使って書き込みデータの物理的な配置を制御するサーバが含まれていた。誤削除の範囲が大きかったため、双方のシステムについて完全な再起動が必要となった。これに長い時間がかかり、その間US-EAST-1におけるS3、およびこれに依存するサービスが利用できなくなってしまったのだという。

[追記]AWSは、今回の障害の発端となったコマンドについて、サーバを「remove」するものと表現している。この言葉使いからは、仮想インスタンスの削除なのか、物理サーバのネットワーク接続を切ることなのかは判断しきれない。

 すなわち、ヒューマンエラーやハードウェア障害などの理由で一部のサーバがダウンしても、自動的に他のサーバの数を増やす、あるいは完全に再起動して、システムを自動的に修復するプロセスは機能していたことになる。問題は、サービスにほとんど影響を与えずに修復できるはずの自動復旧プロセスに、数時間を要したことにある。

 AWSは、過去数年、今回のような再起動の経験がない間に、S3の規模が急速に拡大したことで、修復および情報の一貫性チェックに、想定よりも大幅に長い時間がかかったと説明している。

 AWSは次の対策を講じるという。

  • 今回使用された運用ツールを改善し、サーバの削除スピードを落とすとともに、機能を最低限実行するのに必要なサーバ容量を下回る変更が行えないような制限を加える
  • 他の運用ツールについても、同様な問題がないかチェックする
  • S3の主要サブシステムをより迅速に修復するための改善を進める。規模拡大に対応して、AWSでは各サービスをできるだけ小さな単位にリファクタリングし、特定障害の影響範囲を縮小するとともに、復旧所要時間を短縮する取り組みを続けてきた。だが今回の件では、この取り組みが十分でないことが明らかになった。S3チームはインデックスシステムのより細かな分割を、2017年中に実行する予定だったが、この作業の優先度を高め、直ちに取り掛かる

 US-EAST-1はAWSの最初のリージョンであるとともに、他のリージョンに比べて安価に設定されているサービスが多い。また新サービスも、いち早く投入される。このためユーザー数も多い。そして今回は、AWSの大部分のサービスが依存するAmazon S3の根幹といえるインデックスサーバで問題が起こったため、障害の影響が大きくなってしまった側面があるようだ。

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。