日常的なコマンドも、依然として本番環境への変更である
オペレーターは即興で操作していたのではなく、既定のプレイブックに従っていました——それでも1つの入力ミスが過大な影響範囲をもたらしました。だからこそ、「日常的な」運用コマンドであっても、入力の検証と影響範囲の制限が重要なのです。
ケーススタディ · 2017年2月
1つの入力ミスが、 インターネットの一角を停止させた。
日常的なデバッグ作業で入力された1つの誤った値により、AWS S3のサブシステムから想定をはるかに超える数のサーバーが削除されてしまいました。さらに、影響を受けたシステムは何年も完全な再起動をしていなかったため、復旧には想定よりもはるかに長い時間がかかりました。
スクロールしてタイムラインを見る
約4時間
US-EAST-1リージョンでの継続時間
1億5000万ドル
S&P500企業への推定コスト
概要
1つの表でわかる、事の経緯。
出典は本文中にリンクしています。AWS自身が公開したインシデント後の公式サマリーを含みます。
日付
2017年2月28日、太平洋標準時午前9時37分頃から発生。
何が起きたか
権限を持つエンジニアが、S3の課金システムをデバッグするための既定のプレイブックに従い、少数のサーバーを削除するためのコマンドを実行しましたが、1つの入力値が誤って入力されたため、想定よりはるかに多くのサーバーが削除され、2つの中核的なS3サブシステムがオフラインになりました。これはAWS自身のサマリーによる説明です。
規模
この障害はUS-EAST-1リージョンで約4時間続き、インターネットの広範な部分に影響を及ぼしました。無関係な多数のウェブサイト、アプリケーション、さらにはAWS自身のステータスツールまでもがストレージや設定のためにS3に依存していたためです——AWSは自社のサービスダッシュボードすら更新できませんでした。そのダッシュボード自体が影響を受けたリージョンに依存していたためです。
復旧のボトルネック
影響を受けたサブシステムは何年もの運用を経て非常に大規模になっており、その規模での完全な再起動を一度も経験したことがなかったため、再起動プロセスには想定をはるかに超える時間がかかりました——これは元のミスの繰り返しではなく、キャパシティおよび運用テストにおけるギャップです。
報告されたコスト
ウォール・ストリート・ジャーナルは、サイバーリスクモデリング企業Cyenceによる推計として、この障害がS&P500企業に合計約1億5000万ドルのコストをもたらしたと報じました——これは広く引用されているものの、第三者によるモデル推計であり、各社の個別開示の合計ではありません。
なぜこれほど高コストになったのか
影響範囲は、インターネット全体の依存関係グラフそのものでした。
ここで生じたコストのほとんどは、課金サブシステムのAWS自身の顧客が負担したものではありません——それは、S3にどれほど深く依存しているかを自覚していなかった、それ以外のすべての人々が負担したのです。
一度も再起動されないシステムは、テストされていないシステムである
復旧が想定より長引いたのは、影響を受けたサブシステムが現在の規模で再起動されたことが一度もなかったためです——テストされていない復旧経路は、キャパシティの増大が静かに生み出す、隠れたMTTR(平均修復時間)リスクの原因です。
サードパーティへの依存は、障害が起きるまで見えない
AWSの課金サブシステムと直接の関係を持たない企業までもがダウンしました。これは、それらの企業自身のインフラが、気づかぬうちに同じリージョンのストレージ層に依存していたためです——単一ベンダーの1つのリージョンから受ける実際の影響範囲は、想定するのではなく、実際にマッピングすべきだという教訓です。
FAQ
AWS S3障害についての質問。
この事件をクラウド依存やベンダーリスクの事例として引用する際によくある質問。
これはAWSへの攻撃でしたか?
いいえ——AWSは、外部からの攻撃ではなく、日常的なデバッグ手順中に発生した内部の運用ミスが原因であるとしています。
なぜ1億5000万ドルという数字はAWS自身の数字ではなく、第三者による推計なのですか?
AWSは自社の障害についてコスト推計を公表していません。1億5000万ドルという数字は、Cyenceのサイバーリスクモデリングによるもので、ウォール・ストリート・ジャーナルが報じたものです。そのため、監査済みの合計額ではなく、あくまで方向性を示す数字です。
AWSはその後何を変更しましたか?
AWSの公式サマリーでは、必要最低限のレベルを下回るキャパシティの削除を防ぐ安全策や、サブシステムの再起動時間を改善するなど、ツールに対する変更について説明されています。
これは計算ツールにどう対応しますか?
社内インフラへの影響をモデル化するか、ベンダー障害による顧客向け影響をモデル化するかに応じて、ITダウンタイム計算ツールまたはウェブサイトダウンタイム計算ツールをご利用ください。
あなたの番です