--- title: "1つの間違ったコマンド、4時間：2017年のAmazon S3の話" url: https://www.thinnd.site/ja/monogatari/machigai-no-1komando-4jikan-amazon-s3-2017/ language: ja author: "Nhu Duy Thin (Thinnd)" published: 2026-10-29 updated: 2026-10-29 section: "ストーリー" tags: ["障害", "Amazon S3", "AWS", "ポストモーテム", "運用ツール", "影響範囲"] summary: "2017年2月28日、US-EAST-1リージョンで遅い課金処理をデバッグしていたとき、S3チームの権限を持つメンバーが、あるサブシステムから少数のサーバーを外すコマンドを実行しましたが、入力の打ち間違いで、意図より多くのサーバーが外れ、S3のインデックスと配置のサブシステムも含まれました。この2つは完全な再起動が要り、AWSは、大きなリージョンではそれを何年も完全には行っていなかったと述べています。そのためS3は、始まりから約4時間17分後の太平洋時間午後1時54分にやっと正常に戻りました。AWSは、容量をよりゆっくり外すようツールを変え、サブシステムを必要な最小容量より下げる削除をすべて遮るようにしました。" license: "Cite with the author name and the canonical URL above." --- # 1つの間違ったコマンド、4時間：2017年のAmazon S3の話 > これは**実話ですが、私自身の話ではありません**。**AWS自身が公表した事後報告**（末尾にリンク、直接読みました）に沿って振り返ります。報告はコマンドを実行した人の名前を挙げていないので、私も名前を付けず、その人が何を考えたかも推測しません。 > > この記事は[GitLab 2017](https://www.thinnd.site/ja/monogatari/gitlab-2017-machigatte-deta-wo-keshita-hi/)の話と1点で違います：これはバックアップが壊れていた話ではなく、**1つの打ち間違いで、あまりに多くを外せるツール**の話です。記事の時刻は、報告と同じ太平洋時間（PST）です。 --- ## 先に要点 - **2017年2月28日**の**午前9:37**、S3チームの権限を持つメンバーが、課金に関わるサブシステムから**少数のサーバー**を外すコマンドを実行しました。**入力の1つの打ち間違い**で、**意図より多くのサーバー**が外れました。 - 外れたサーバーは、S3の中核の2つのシステム、**インデックス**と**配置**を支えていました。両方が**完全に再起動**される必要がありました。 - US-EAST-1のS3は、約**4時間17分**後の**午後1:54**にやっと**正常に戻りました**。 - 注目点：**コマンドは作られたとおりに動いた**のです。外しすぎを止めるものがなかっただけ。**AWS自身のサービス状態の表示板**も、S3に依存していました。 - AWSはツールを、**よりゆっくり外し**、**最小を下回って外さない**ように変えました。 --- ## むずかしい言葉をやさしく | 用語 | やさしい意味 | |---|---| | **Amazon S3** | AWSのクラウドのファイル保存サービス。非常に多くのサイトやアプリが使う。 | | **リージョン** | ある地域にあるデータセンターのまとまり。US-EAST-1は、AWSの大きなリージョン。 | | **サブシステム** | サービスの内部の、1つの仕事をする部分。 | | **インデックスのサブシステム** | 保存された各オブジェクトの情報を持つ：どこにあるか。 | | **配置のサブシステム** | 新しいオブジェクトの保存先を選ぶ。インデックスに依存する。 | | **影響範囲（ブラスト半径）** | 1つの障害が、周りをどれだけ壊しうるか。 | | **手順書（プレイブック）** | 運用作業のために用意された手順。 | --- ## 1. いつもの運用作業 その朝、S3チームは、US-EAST-1で**遅く動く課金処理をデバッグ**していました。権限を持つチームメンバーが、**既存の手順書**に従い、課金に関わるサブシステムから少数のサーバーを外し、効果があるか見ようとしました。 特に変わったことはありません。サブシステムからサーバーを外すのは、運用者の日常の仕事で、手順書もありました。大事な点です：**これは、許された操作で、手順に従い、権限のある人が行った**ものでした。 --- ## 2. 午前9:37：入力の打ち間違い 報告によると、コマンドは**9:37**に実行され、**入力の1つが間違って入力されました**。結果：**意図より多くのサーバーが外れました**。 報告は、どの入力か、どう間違ったか、なぜかを述べていません。私は推測しません。自信を持って言えるのは、**ツールがその値を受け取って実行した**ことで、「このコマンドは何台を外し、それは安全か」を確かめる関門はなかったということです。 外れたサーバーは、**課金のシステムでなく、2つの中核システムのもの**でした： - **インデックス：** リージョン内のすべてのオブジェクトのメタデータと位置の情報を持つ。取得、一覧、書き込み、削除の依頼に必要。 - **配置：** 書き込みの依頼で、新しいオブジェクトの保存先を割り当てる。インデックスが正しく動くことに依存する。 それだけの容量が外れると、**両方が完全に再起動される**必要がありました。 --- ## 3. 再起動：何年もやっていなかったこと これは、報告の中で私が最も考える価値があると思う細部です。AWSは、大きなリージョンで、これらのシステムを**何年も完全には再起動していなかった**と書いています。その間にS3は**大きく成長**し、安全な再起動に必要な**メタデータの整合性を確かめる安全確認**が、再起動を**予想より長く**しました。 言い換えれば：**復旧する力は、今の規模では一度も試されていなかった**のです。GitLabの教訓と響き合います：復元を試したことのないバックアップは、使えるか分からず、実際の規模で動かしたことのない再起動の手順は、どのくらいかかるか分かりません。 --- ## 4. 時系列 すべて太平洋時間、2017年2月28日、US-EAST-1リージョン。 | 時刻 | 何が起きたか | |---|---| | **9:37** | コマンドが実行され、意図より多くのサーバーが外れる | | **11:37** | サービス状態の表示板で、個別のサービスの状態を再び更新できる | | **12:26** | インデックスのサブシステムに、取得、一覧、削除を処理できる容量が戻る | | **午後1:18** | インデックスのサブシステムが完全に復旧 | | **午後1:54** | 配置のサブシステムの復旧が終わり、S3が正常に動く | 9:37から午後1:54までは**約4時間17分**です。報告は、各再起動それぞれの所要時間を挙げていません。 --- ## 5. 誰が影響を受けたか、そして表示板の皮肉な細部 報告によると、影響を受けたサービスには、S3のコンソール、**新しい仮想マシン（EC2）の起動**、S3に保存されたスナップショットのデータが要る**EBSボリューム**、**AWS Lambda**がありました。一部のサービスは、中断の間にたまった作業があり、回復に追加の時間が要りました。 **皮肉な細部：** AWSの**サービス状態の表示板**の管理コンソールも、**S3に依存して**いました。11:37まで、個別のサービスの状態を更新できなかったので、AWSは、**Twitterのアカウントとページ上部の文言**で伝えるしかありませんでした。 一般的な教訓（私の推論）：**障害を知らせるツールは、壊れているものそのものの上に置かない。** --- ## 6. 1つの間違ったコマンドが、大きな障害になった理由 報告から、1つの打ち間違いを4時間の中断に変えた5つの層が見えます。*この読み方は私のものです。* | 層 | 報告が示すこと | |---|---| | **外しすぎを許すツール** | 1つの打ち間違いで、意図より多くが外れ、止める最小がなかった。AWSは後にこの守りを加えた | | **外すのが速すぎた** | AWSは後に、よりゆっくり外すようツールを変えた | | **大きな影響範囲** | リージョン全体の2つの中核システムで、多くの他のサービスが依存。AWSは後に、独立したセルに分けた | | **実際の規模で試されていない復旧** | 何年も完全には行っていなかったため、再起動が予想より遅かった | | **壊れたものに依存する報告ツール** | 表示板はS3を使っていた。AWSは後に、複数のリージョンにまたがるよう変えた | 共通点：**各層は、単独では妥当**で、重なったときだけ障害になります。 --- ## 7. AWSが直したこと 報告によると： - **よりゆっくり外す。** 容量を外すツールは、より低い速さで外すよう変えられました。 - **最小。** サブシステムを**必要な最小容量**より下げる削除をすべて遮る仕組みが加わりました。 - **他のツールの見直し。** AWSは、他の運用ツールに、同様の安全確認がないか調べています。 - **影響範囲を小さくし、復旧を短く。** サブシステムを独立したセルに分けます。年内の予定だったインデックスのサブシステムの分割は、前倒しですぐに始められました。 - **複数のリージョンにまたがって動く表示板。** 全体として、AWSは**誰かが打ち間違えるのを禁じること**に重点を置かず、**打ち間違いが大きな害を生めないようにすること**に重点を置きました。 --- ## 8. GitLabの話との比較 2つは「1つの間違ったコマンド」という型を共有しますが、教訓の場所は違います： | | GitLab（2017年1月） | Amazon S3（2017年2月） | |---|---|---| | 間違ったコマンド | 副サーバーでなく主サーバーのデータディレクトリを消した | 入力の打ち間違いで、意図より多くのサーバーが外れた | | 主な弱点 | バックアップが使えず、データが失われた | 最小のないツール、大きな影響範囲、遅い再起動 | | 公の場での対応 | 共有文書、ライブ配信、長い事後分析 | 事後報告とツールの変更 | | 教訓 | 復旧は試されなければならない | 削除の力を持つツールには、関門と最小が要る | 合わせて：**間違ったコマンドを打ちにくくし、その結果を小さくする。** --- ## 9. 私が学ぶこと：外せるツールへの問い *この部分は私の提案で、AWSの結論ではありません。* **外す、消す、止める**ことができるツールを書く、または使うなら、問います： 1. **最小はあるか？** ツールは、システムを安全な水準より下げる操作をすべて遮るか。 2. **速度の制限はあるか？** ゆっくり外せば、運用者が間違いに気づく時間ができる。 3. **事前の確認はあるか？** 一覧表示のみのモード：外す前に「これはN台を外す」。 4. **影響範囲はどれだけか？** 1つの間違ったコマンドで、最大どれだけ壊れるか。 5. **実際の規模で復旧を試したか？** システム全体を最後に再起動したのはいつか。 6. **障害を知らせるツールは、独立して動くか？** 7. **危険な操作を、2人目が見られるか？** --- ## 10. AIがツールを動かせるとき この話は2017年ですが、型はとても現代的です：**外す力を持つツールが、間違った入力を受け取り、何も止めない。** AIエージェントでは、間違った入力は、誘導された指示から来るかもしれず、エージェントは「何かおかしい」とは感じません。 それが[AIアプリのOWASP Top 10](https://www.thinnd.site/ja/gijutsu/ai-apuri-no-owasp-top10-mijika-na-rei/)の**過剰な権限（LLM06）**です：過剰な機能、過剰な権限、過剰な自律。そこでの対策は、AWSの教訓と重なります：機能を限り、最小限の権限、影響の大きい行動は承認を求める。記事[MCPとは何か](https://www.thinnd.site/ja/gijutsu/mcp-towa-konsento-de-setsumei/)はヒューズについて述べ、S3の最小こそ、1つのヒューズです。 --- ## 11. バランスの取れた見方 - **主な情報源は1つです。** 私はAWS自身の報告に拠っており、報告はAWSの立場から書かれています。 - **報告は多くの細部を省いています。** 名前も、具体的な打ち間違いの値も、各再起動の所要時間もないので、推測しません。 - **比較と「5つの層」の表は、私の読み方です。** - **障害は10年近く前のことです。** システムは大きく変わりましたが、原因（最小がない、大きな影響範囲、試されていない復旧、壊れたものに依存するツール）は、今もとても身近です。 - **コマンドを実行した人がどう感じたかは分かりません**ので、記事はそれを描きません。 --- ## 12. 結論 1つの打ち間違い、4時間、そしてインターネットの一部が遅くなりました。けれど、AWSが直すと選んだのは、「運用者に打ち間違えるなと言う」ことではありません。間違ったコマンドが外しすぎないよう**ツール**を、結果が小さくなるよう**システム**を直したのです。それが、最も学ぶ価値のある考え方です。 今日の小さな一歩：使っている、外す、または消すことができるツールを1つ見つけ、**最小**と**プレビューのモード**があるか確かめてください。なければ、やることに加えます。 --- ## 参考資料 - [AWS：Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region](https://aws.amazon.com/message/41926/) - ブログ内の関連記事：[エンジニアが間違ったデータを消した日：GitLab 2017年の話](https://www.thinnd.site/ja/monogatari/gitlab-2017-machigatte-deta-wo-keshita-hi/)、[AIアプリのOWASP Top 10](https://www.thinnd.site/ja/gijutsu/ai-apuri-no-owasp-top10-mijika-na-rei/)、[MCPとは何か？コンセントで説明する](https://www.thinnd.site/ja/gijutsu/mcp-towa-konsento-de-setsumei/)