🔬

AWS大規模障害の深層分析：DynamoDBのDNS障害が暴いた構造的リスク

に公開
AWS
DNS
DynamoDB
SRE
障害対応
idea

はじめに：AWS障害の再検証

2025年10月20日のAWS大規模インシデント直後、筆者は速報として「AWS障害はなぜグローバルに拡大したか？ US-EAST-1の「単一障害点」構造を徹底分析」を公開しました。

その後、AWSからは、自らの設計上の問題を率直に認める、厳しい内容の公式発表が出され、ITmediaもこれを基にした記事をまとめています。

本記事は、これらの公開情報に加え、筆者がこれまで自身のブログで展開してきた以下の継続的な分析を前提としています。より深い文脈をご理解いただくため、未読の方は先に目を通されることをお勧めします。

本稿では、これまでの議論の集大成として、インシデントの根本原因とAWSが抱える構造的な課題について、最終的な分析を提示します。

技術的深掘り：障害はなぜグローバルに拡大したか

AWSの公式発表における障害の起点時刻は 10月20日 15:48 (JST) とされています（原文表記は10月19日 23:48 PDT）。しかし、その最初のインパクトは、直後の 15:53頃 に外部で観測されていました。これは、任天堂がNintendo Switchのネットワーク障害として発表した時刻（Impress Game Watch誌も報道）と一致します。

この5分間のタイムラグは、各所のDNSキャッシュが有効であった時間と考えれば、容易に説明がつきます。つまり、AWS内部でDNSレコードが消失してから、キャッシュが切れたクライアントが名前解決に失敗し始めるまでに、約5分の遅延があったと推測できます。

任天堂のサービスがAWS上で稼働していること、そして障害発生の同期性を鑑みると、この15:53という時刻が、DynamoDBのDNSレコード喪失がユーザーレベルで顕在化した「第一撃」を捉えたものである可能性は極めて高いと考えられます。

この時間軸を念頭に置き、公式発表を基に障害が連鎖した詳細なメカニズムを解き明かします。

第1幕：DynamoDB DNSレコード消失

障害の直接的トリガーは、DynamoDBのDNS管理システムにおける競合状態（Race Condition）でした。

  • アーキテクチャ: システムは、DNSプランを作成する「DNS Planner」と、3つのAZで冗長的に動作しプランを適用する「DNS Enactor」で構成されます。
  • 競合シナリオ:
    1. あるDNS Enactor（A）が、古いプランの適用に手間取り、遅延します。
    2. その間に、別のEnactor（B）がより新しいプランの適用を迅速に完了させ、古いプランを削除するクリーンアップ処理を呼び出します。
    3. まさにその時、遅延していたEnactor（A）がチェックをすり抜け、古いプランをリージョンエンドポイントに適用（上書き）してしまいます。
    4. 直後、Enactor（B）のクリーンアップ処理が、上書きされたばかりの古いプランを「古すぎる」と判断し、削除します。
  • 結果: DynamoDBのリージョンエンドポイントからIPアドレスが消失。さらに、システムが不整合な状態に陥り、手動介入が必要となりました。このシナリオの「やばさ」は、 システムが自らの整合性を守るための機構を、自分自身で無効化してしまった 点にあります。

可用性向上のために導入された 「複雑な自動化」 は、 システムを破壊しうる新たな「クランブルポイント」 になり得るという、クラウド時代の深刻な教訓を示しています。DNSの本来のシンプルで堅牢な設計を、内部で複雑に管理しようとした結果、その基盤が崩壊してしまったと言えるでしょう。

人間の熟練したエンジニアであれば、パージする前にパージしても残るレコードがあるかを検証したはずです。しかし、自動化された仕組みは、パージしても残るものがあるかを検証せずただ削除します。 結果として、DNSのエントリは誰もいない状態、言わば nobody化 します。こうなってしまえば、DNSは機能しません。

これは、 「壊れていないものをいじるな (If it ain't broke, don't fix it)」というエンジニアリングの基本原則が、複雑な自動化ロジックによって破られた瞬間です。システムの生存を最優先する「最終保護ルール」（前近代的システムで言う「秘伝のタレ」）が欠落していた結果、論理的な処理が自律的な自己破壊装置（Autonomic Self Destroyer） として機能してしまいました。

第2幕：EC2の段階的機能不全

DynamoDBの復旧後も、EC2では障害が続きました。これは二段階の内部的な機能不全によるものでした。

  1. DWFMの輻輳崩壊: EC2の物理サーバーを管理する DropletWorkflow Manager (DWFM) は、サーバーとのリース管理をDynamoDBに依存しています。DynamoDB障害でリースが大量に切れ、復旧後に再確立を試みるも、処理のタイムアウトが頻発し 輻輳崩壊（Congestive Collapse） に陥りました。これにより、新規インスタンスの起動が「Insufficient Capacity」エラーで失敗し続けました。

  2. Network Managerのバックログ: DWFMが復旧すると、今度は遅延していた大量のネットワーク設定変更のバックログが Network Manager に殺到。これにより新規インスタンスのネットワーク接続が確立されない問題が発生しました。

第3幕：NLBのヘルスチェック連鎖障害

EC2のネットワーク伝播遅延は、Network Load Balancer (NLB) にも波及しました。

  • 原因: NLBのヘルスチェックシステムが、ネットワーク未完了のEC2インスタンスを正常と誤認しサービスに投入。その後のヘルスチェックが失敗と成功を繰り返す「フラッピング」状態に陥りました。
  • 結果: ヘルスチェックシステム自体の負荷が増大し、自動AZフェイルオーバーが誤作動。キャパシティが意図せず削減され、コネクションエラーが増加しました。

構造的問題の核心：2つの単一障害点

今回の障害は、単なるバグではなく、AWSのアーキテクチャに内在する2つの構造的な問題点を浮き彫りにしました。

1. 管理システムの脆弱性：DNSが「クランブルポイント」と化すまで

堅牢なはずのDNSが、その管理システムの脆弱性によってシステム全体を崩壊させかねない一点の弱点と化してしまいました。これは、構造物が予期せぬ一点から脆く崩れ去る 「クランブルポイント（Crumble Point）」 や、あるいは「ハチの一刺し」が全身の アナフィラキシーショック を引き起こす現象にもなぞらえることができます。特に、容量管理の単純化のために「単一のリージョンDNSプラン」を採用していたことが、障害の影響をこの一点に集中させる結果となりました。

2. 地理的・アーキテクチャ的SPOF：「ホームリージョン」という負債

「DNSからDynamoDBへ」という技術的な依存関係が、「US-EAST-1のホームリージョン構造」と組み合わさることで、障害は「技術的な失敗」から「構造的な災害」へとエスカレートしました。IAM、STS、Redshiftの一部機能などがUS-EAST-1に依存していたため、グローバルな影響が発生しました。

提言：AWSがとるべき3つの根本療法

AWS自身も公式発表の中で、今回の障害が単なる競合状態の問題だけでなく、より根深い構造的問題に起因することを認めています。その厳しい自己評価を踏まえ、本稿では再発防止に不可欠な3つの根本療法を提言します。

1. 🏛️ US-EAST-1の「脱・ホームリージョン化」

グローバルサービスのコントロールプレーンを、単一リージョン依存から脱却させ、真に地理的に分散されたアーキテクチャ（例：3つ以上のリージョンでのアクティブ/アクティブ構成）へ移行することが求められます。

2. 🛡️ コントロールプレーンの「疎結合化」

主要な内部サービス間の依存関係を徹底的に見直し、分離を進めるべきです。例えば、DWFMがDynamoDBにアクセスできない場合でも、ローカルキャッシュ等で数時間分の 「生存リース」 を維持できるような、耐故障性の高いバッファ層を設けるといった対策が考えられます。

3. 🧪 組織知の維持と「堅牢性証明」

今回の障害では、検知から原因特定までに長時間を要した点も指摘されています。The Registerなどの海外メディアは、これを単なる技術的問題ではなく、経験豊富なシニアエンジニアの離職による「組織知（Institutional Knowledge）」の喪失が一因ではないかと厳しく指摘しています。

複雑な大規模システムでは、設計書にない「暗黙知」を持つ人材の経験が、予期せぬ障害への対応速度を左右します。この観点を踏まえると、以下の対策が不可欠です。

  • 自動化システムに対する「堅牢性証明」: DNSレコードの全削除のような破壊的な操作には、多重のヒューマンレビューや段階的な検証を必須とする設計原則を導入し、個人の経験への依存を減らす。
  • 組織知の形式知化と継承: SREの原則に基づき、シニアエンジニアが持つ暗黙知を、設計上の制約条件や定期的な障害訓練（ゲームデー）のシナリオとして形式知化する。さらに、それを組織全体で継承し、人材の流動性に左右されない回復力（レジリエンス）を構築するプロセスを確立する。

まとめ：構造的負債の解消に向けて

今回のインシデントは、クラウドの利便性の裏に潜む、密結合や特定リージョンへの依存という構造的リスクを改めて示しました。AWSは対策として、DNS自動化の一時停止と修正、NLBの速度制御メカニズムの追加、EC2の回復力向上のためのテスト強化などを約束しています。これらは重要な一歩ですが、本稿で提言したような、より長期的なアーキテクチャレベルでの負債解消こそが、真の可用性を実現する唯一の道です。

Discussion