ビジネス+IT

ビジネス課題別で探す

ITジャンル別で探す

会員限定

2017年03月10日

Amazon S3がダウン! なにが障害をここまで大きくしたのか? AWSの報告を読み解く

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

執筆:Publickey 新野淳一

photo

Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region


 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が通常動作へ復帰し、影響を受けていたそのほかのサービスも復帰を開始しました。

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

BCP(事業継続) ジャンルのセミナー

一覧へ

BCP(事業継続) ジャンルのトピックス

一覧へ

BCP(事業継続) ジャンルのIT導入支援情報

一覧へ

関連キーワード

AWS記事 新野淳一 アマゾン

PR

注目のIT導入支援情報

一覧へ

注目のイベント・セミナー情報

一覧へ

イベント・セミナー情報の登録(無料)

記事アクセスランキング

イベント・セミナー情報アクセスランキング