🎯 結論ファースト:3分で分かる障害の全体像
US-EAST-1は「本社ビル」
AWSの最古参リージョン。IAMやRoute 53などグローバルサービスの「本店」として機能し、世界中が依存。
DNSの「住所録」が消えた
DynamoDBのDNS管理システムで競合状態が発生。エンドポイントのIPアドレス情報が全消失した。
連鎖的に崩壊
DynamoDB → EC2 → NLB → Lambda... 内部サービスの密結合により、ドミノ倒しのように障害が拡大。
世界中に影響
FortniteやRoblox、金融サービスまで。約14時間にわたり世界中のサービスが混乱した。
🎭 たとえ話で理解する障害のメカニズム
🏙️ US-EAST-1は、AWSという巨大企業の「本社ビル」のようなもの。
📇 社員証の発行(IAM)、全社電話帳(Route 53)、経理システム(DynamoDB)など、会社全体を動かす重要部門が集中しています。
💥 本社ビルが火事になったら、支店は仕事ができなくなりますよね?それが今回起きたこと。
📞 「dynamodb.us-east-1.amazonaws.com」という名前から、実際の「IPアドレス」を調べるのがDNS。
📕 これは「田中さんの電話番号は090-XXXX-XXXXです」と書かれた電話帳のようなもの。
🚫 この電話帳のページが白紙になったら、誰にも電話できなくなります。それが今回起きたこと。
👨🍳 シェフAとシェフBが同じ鍋を使おうとしている状況を想像してください。
🍲 シェフA「塩を入れた!」→ シェフB「古いスープを捨てるね」→ シェフBは新しいスープも一緒に捨ててしまった!
😱 お互いの作業タイミングがズレたことで、本来残すべきものまで消えてしまう。これが「競合状態」です。
🔌 本社ビルの電気が止まっても、各支店にはUPS(無停電電源装置)があります。
⏱️ 障害発生後も「キャッシュ」のおかげで、しばらくは動き続けました。
🪫 でもバッテリーには限りがあり、切れた瞬間に次々とサービスがダウン。約5分後から影響が顕在化しました。
☎️ 電話がつながらない時、あなたは何度もかけ直しますよね?
📈 世界中の何百万ものシステムが同時に「リトライ」し始めると...
🌊 それ自体がDDoS攻撃のような状態に。復旧作業をさらに困難にしました。
🦟 ハチに一度刺されただけで、全身がショック状態になることがあります。
💉 DNSという「一箇所」の障害が、免疫系(=依存関係)を通じて全身(=AWS全体)に広がった。
🏥 堅牢なはずのシステムが、予期せぬ一点から崩壊する「クランブルポイント」の典型例です。
🏗️ なぜUS-EAST-1が「単一障害点」なのか
💥 障害の連鎖フロー
DNS消失
DynamoDBの住所が消えた
DynamoDB停止
接続不能に
EC2起動失敗
リース管理がダウン
NLB異常
ヘルスチェック失敗
グローバル影響
世界中のサービス停止
🔬 障害の技術的詳細
📋 第1幕:DNS競合状態(レースコンディション)
🏗️ システム構成
DNS Planner:DNSプラン(どのIPアドレスを使うか)を作成
DNS Enactor:3つのAZで冗長的に動作し、プランを適用
⚡ 何が起きたか?
Enactor A(遅延)
古いプランを適用中...
時間がかかって遅れた
Enactor B(高速)
新しいプランを適用完了!
古いプランを削除しよう
🖥️ 第2幕:EC2の輻輳崩壊
🔧 DWFM(DropletWorkflow Manager)とは
EC2インスタンスを動かす物理サーバー(Droplet)を管理するシステム。各サーバーとの「リース契約」をDynamoDBで管理。
💥 何が起きたか
DynamoDB停止中にリースが大量失効。復旧後、全サーバーが一斉にリース再取得を試み、処理が追いつかず「輻輳崩壊」に。新規EC2起動が「Insufficient Capacity」エラーに。
🌐 Network Managerも連鎖
DWFM復旧後、遅延していたネットワーク設定が殺到。新規インスタンスがネットワークに接続できない状態が続いた。
⚖️ 第3幕:NLBのヘルスチェック連鎖障害
🏥 ヘルスチェックとは
「このサーバーは元気ですか?」を定期的に確認するシステム。異常があればサービスから除外する。
💥 何が起きたか
ネットワーク未完了のEC2を「正常」と誤認してサービスに投入。その後のチェックで「異常」と判定。正常↔異常を繰り返す「フラッピング」状態に。
⚡ 結果
ヘルスチェックシステム自体が過負荷に。自動フェイルオーバーが誤作動し、本来正常なキャパシティまで除外されてしまった。
⏱️ 障害タイムライン(日本時間)
🌍 影響を受けた主なサービス
📚 この障害から学ぶ教訓
技術的負債の怖さ
US-EAST-1への依存は、AWSの初期設計から続く「技術的負債」。後発のAzureやGCPがより分散化されたアーキテクチャを採用しているのとは対照的です。
自動化の落とし穴
可用性向上のための「複雑な自動化」が、予期しない競合状態を生み、システムを破壊する「クランブルポイント」になりうる。
密結合のリスク
内部サービス間の依存関係が複雑すぎると、一箇所の障害が連鎖的に全体に波及する。疎結合の設計が重要。
組織知の重要性
The Registerは、検知から原因特定までの遅れを「シニアエンジニアの離職による組織知の喪失」が一因と指摘。暗黙知の形式知化が不可欠。
🛡️ AWSが発表した再発防止策
DynamoDB DNS管理
自動化の一時停止
DNS PlannerとDNS Enactorの自動化を世界中で無効化
競合状態の修正
レースコンディションのシナリオを修正し、追加の保護措置を導入
NLB(Network Load Balancer)
速度制御メカニズム追加
ヘルスチェック失敗時のAZフェイルオーバーで、単一NLBが除外できるキャパシティを制限
Amazon EC2
テストスイートの強化
DWFMリカバリーワークフローを検証する追加テストを構築
スロットリング改善
待機キューサイズに基づく受信作業の制限で、高負荷時のサービス保護を強化