Written with AI assistance from the source video. The video is the authority.
50:56The PrimeTime
Log in to leave a comment
No posts yet
2025年10月、クラウド世界の心臓部である AWS US-EAST-1 リージョンが停止しました。EC2 は生成を止め、Lambda は応答を拒否しました。すべてのドミノ倒しの終着点には DynamoDB がありました。AWS は公式レポートでこれを 潜在的なレースコンディション と名付けました。しかし、それは単に運の悪いタイミングの問題だったのでしょうか。シニアエンジニアの視点で見れば、この事件は分散システムの論理的欠陥と復旧メカニズムの欠如が招いた惨事です。
DynamoDB は高可用性のために DNS ツリー構造と重み付けベースのレコードを使用しています。トラフィックは 3 つの中核コンポーネントによって管理されます。
| コンポーネント | 役割 | 運用方式 |
|---|---|---|
| DNS Planner | トラフィック分散比率の計算 | リージョン単位の最適化プラン作成 |
| DNS Enactor | Route 53 レコードの更新 | 3つの AZ で独立して実行 |
| DWFM | 全体ワークフローの調整 | アップデート伝播のオーケストレーション |
システムは、特定の区間に問題が発生すると重み付けを 0 にしてトラフィックを遮断するように設計されていました。理論は完璧でしたが、実際の運用では予想外の変数が噴出しました。
事件当日、負荷が集中したことで Enactor 1 の処理が遅れました。その間に Enactor 2 は最新バージョンであるプラン 102 を反映しました。ここで致命的な連鎖反応が起こりました。
まず、遅延していた Enactor 1 が後から動き出し、過去のデータであるプラン 100 を最新情報の上に上書きしました。続くクリーンアップ段階で、Enactor 2 は現在の基準であるプラン 102 に含まれていない古いレコードを削除し始めました。Enactor 1 がたった今復元したデータは、Enactor 2 の視点からは削除対象に過ぎなかったのです。結局、DynamoDB のメインエンドポイント DNS レコードが消失しました。
多くの人はここで分析を止めます。タイミングが狂ってデータが消えたのだと結論づけます。しかし、核心は なぜシステムが空のレコードを見て自ら立ち上がることができなかったのか にあります。
エンドポイントが消滅すると、復旧を担当すべきシステムたちが次々とランタイム例外を引き起こしました。Enactor のコードは、レコードが存在しない状態を想定していませんでした。メモリ管理エラーである Use-after-free のように、すでに消え去った対象を参照しようとしてシステムが崩壊しました。
自動化されたロールバックロジックは状況をさらに悪化させました。復旧の基準となるデータベース自体が汚染された状態だったからです。システムは無限ループに陥り、自動化はシステムを修復する道具ではなく、破壊する武器へと変わりました。
AWS はレート制限機能を導入すると発表しました。これは症状を緩和するだけで、根本的な処方箋ではありません。システムが異常状態を認識し、自ら癒やす能力を備えない限り、同じ悲劇は繰り返されます。
| 区分 | 公式の説明 | シニアの洞察 |
|---|---|---|
| 障害原因 | 同時更新の衝突 | 書き込み時の有効性検証 (CAS) の欠如 |
| 障害現象 | 自動化の稼働停止 | 安全な失敗 (Safe Default) 設計の未備 |
| 対応策 | アップデート速度制限 | 復旧ロジックのべき等性の確保 |
2025年のこの事件は、コード一行の重みを証明しています。数十億ドル規模のインフラを崩壊させたのは、大層なハッキングではありませんでした。空っぽの DNS レコードに直面したとき、どのように行動すべきかを定義していなかった、小さな例外処理の不備が原因でした。
エンジニアリングの真髄は、複雑な機能を作ることではありません。予期せぬ失敗状況において「気高く」崩壊し、確実に復旧するように設計する能力です。
安定性のための必須チェックリスト
真のプロフェッショナルは、システムがいかに壊れたかを超え、なぜ復旧しなかったのかを執拗に問い続ける人です。あなたのシステムは今、安全に失敗する準備ができていますか。