> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/ja/2025/w43-lessons-learned-from-the-aws-incident.md).

# W43-AWSの障害から学んだ教訓

先週、AWSで15時間に及ぶ重大障害が起きた。世界で1,000社以上のサービスが中断し、数十億ドルの経済損失が生じた。深い教訓を得た。どれほど巧みな設計でも、一つの単一障害点には勝てない。

障害はAWSで最も重要なus-east-1リージョンで起きた。根本原因は、DynamoDBのDNS管理自動化にあった競合状態の欠陥だった。リージョンのエンドポイントのIPレコードを誤って空にし、名前解決ができなくなった。us-east-1は普通のデータセンターではない。AWSの世界的な基盤の「中枢神経」であり、ほぼすべてのリージョンの共通コントロールプレーンが依存している。EC2のスケジューリング、NLB、Lambdaなどの重要サービスも含まれ、連鎖的な崩壊につながった。

さらに皮肉なのは、発生から75分後もAWSのステータスページが「すべて正常」と表示していたことだ。CloudWatch自体もDynamoDBに依存しており、監視システムまで見えなくなった。

復旧も容易ではなかった。DNSレコードはすぐ修復できても、DynamoDBは制御の中核にある。EC2のスケジューラーは数万台のサーバーのリースを再構築し、ネットワーク管理側は輻輳を解消して遅れていた状態情報を配る必要があった。ロードバランサーはインスタンスの健全性を誤判定し、繰り返し除外した。最終的にAWSは自動ヘルスチェックとフェイルオーバーを止め、人が介入することで、崩壊の連鎖を食い止めた。

他社の出来事を見た後は、自分たちのサービスを振り返りたい。システム全体の単一障害点になりやすいのは、むしろ事業の改善であまり注目されない基盤サービスだ。たとえば情報化入口や認証系サービスがある。情報化入口は業務ロジックが単純でも、影響範囲は巨大で、トラフィックの80%を握っている。この種のサービスは、依存を最小にし、エントロピーを最大にする原則に従い、徹底して明確かつ単純に設計すべきだ。

情報化入口のような小さなコンポーネントには、意欲的なエンジニアを引きつける面がある。複数の技術スタック向けに複数バージョンを維持し、リリース周期が長く、ホストとなる業務ページに依存するという、明確な技術的課題があるからだ。今年、私たちがそこで進めたことを振り返ると、方向が正しかったかを検証する必要があると思う。動的更新を実現し、業務改善のリリース周期を短縮し、公開の柔軟性を高めるために、多くの実装を行った。依存を増やし、構造を複雑にし、ロールバックが効くまでの速さも落とした。この方向を進めれば、次は動的コンポーネントを各コンテナーで動かし、実装バージョンを集約して、高い動的性と再利用性を目指すことになるだろう。ただ、情報化入口の改善が最も盛んな時期を過ぎると、機能には負債の影が差し始める。

今年の私の関心は、まだ実装能力の訓練に寄りすぎていた。皆に見栄えだけの技巧を磨く機会を作り、技術的な意思決定の質を高めるという上流の仕事に十分移れていなかった。判断時の明確な枠組み、事実の根拠、論理的な推論が足りなかった。唯一正しかったのは、民主的な集団意思決定を取り入れたことだと思う。

エンジニアは成長の途中で、冗長さを嫌い、すべてを抽象化し、複雑さを重視し、それを技術的価値の基準にする時期を通る。そうした中途段階の認識を捨てる勇気が必要だ。トレードオフを考え抜いた明確さと単純さを目指したい。Unixの設計思想のように、本当に水準の高いものを味わうべきだ。