2025年10月20日、インターネットの広大な領域が突如として沈黙した。Amazon Web Services (AWS)で発生したこの大規模障害は、主要なWebサイトや政府機関のサービスを数時間にわたり麻痺させ、現代社会がいかに脆弱な基盤の上に成り立っているかを露呈させた。Amazonが公開した詳細な事後分析レポートは、その原因が「DynamoDB」という一つのデータベースサービスにおける、極めて稀なDNSの不具合であったことを明らかにしている。本記事では、この技術レポートを基に、たった一つの「レースコンディション」がいかにしてドミノ倒しのように連鎖し、世界規模のシステム障害へと発展したのかを見てみたい。
白日の下に晒された障害の全貌と連鎖の始まり
障害は、2025年10月19日午後11時48分（米国太平洋夏時間、以下PDT）に始まった。AWSの主要リージョンである米国東部（バージニア北部、us-east-1）において、基幹データベースサービスである「Amazon DynamoDB」のAPIエラー率が急増。これが、十数時間に及ぶ悪夢の引き金となった。
この障害の影響は瞬く間にAWSエコシステム全体に拡散した。仮想サーバーサービスの「EC2」、サーバーレスコンピューティングの「Lambda」、コンテナサービスの「ECS」「EKS」、ロードバランサーの「NLB」など、AWSの根幹を成す多数のサービスが次々と機能不全に陥った。結果として、これらのサービスを利用する世界中の企業のウェブサイト、アプリケーション、オンラインサービスが停止。その経済的損失は、数百億ドルから数千億ドルに達する可能性が指摘されているほどだ。
Amazonが公開した事後分析レポートは、障害の原因と、それがどのようにしてこれほど広範囲にカスケード（連鎖）したのかを、驚くほど詳細に記述している。注目すべきは、その根本原因が、外部からの攻撃や大規模なハードウェア故障ではなく、内部の自動化システムに潜んでいた、ごくわずかなタイミングのズレによって引き起こされたという事実である。
根本原因：DynamoDBを襲った「レースコンディション」という悪夢
障害の震源地は、DynamoDBのDNS（Domain Name System）を管理する自動化システムだった。このシステムは、膨大な数のサーバーへのトラフィックを効率的に分散させるため、DNSレコードを常に最新の状態に保つ役割を担っている。システムは、可用性を高める目的で、二つの独立したコンポーネントで構成されていた。
- DNS Planner: 負荷分散装置（ロードバランサー）の状態を監視し、最適なDNS構成の「計画（Plan）」を作成する。
- DNS Enactor: Plannerが作成した「計画」を受け取り、実際にDNSサービス（Amazon Route 53）に適用する実行役。耐障害性のため、複数のAvailability Zoneで冗長に稼働している。
問題は、このPlannerとEnactorの連携部分に潜んでいた「レースコンディション」と呼ばれる不具合だった。レースコンディションとは、複数のプロセスが共有リソースに同時にアクセスし、処理の順序が保証されないことで予期せぬ結果を引き起こす現象だ。陸上競技のレースで、複数の走者が同時にゴールテープを切ろうとして混乱する様に似ている。
運命の歯車が狂った瞬間：障害発生のシーケンス
AWSのレポートによると、障害発生のシーケンスは以下の通りだ。
- 異常な遅延の発生: 3つあるDNS Enactorのうちの1つ（Enactor A）が、DNSレコードの更新作業中に「異常に高い遅延」に見舞われた。
- 新しい計画の生成: Enactor Aが遅延している間も、DNS Plannerは通常通り稼働を続け、新しいDNS計画を次々と生成していた。
- 正常なEnactorの先行: 別の正常なEnactor（Enactor B）が、Plannerによって生成された最新の計画を取得し、迅速にDNSレコードへの適用を完了させた。
- 悲劇的な上書き: Enactor Bが作業を終えた直後、クリーンアップ処理を開始。これは、大幅に古い計画をシステムから削除するプロセスである。ほぼ同じタイミングで、遅延から回復したEnactor Aが、手元にある「はるかに古い計画」をDNSレコードに適用してしまった。通常、適用前に計画の新しさをチェックする機能があったが、Enactor Aが経験した異常な遅延により、そのチェック情報自体が古くなっており（ステイル）、機能しなかった。結果として、最新のDNSレコードが古い情報で上書きされた。
- DNSレコードの完全消去: Enactor Bのクリーンアップ処理は、Enactor Aによってまさに今アクティブになったばかりの計画を「大幅に古い計画」であると誤認し、削除してしまった。
- 名前解決の不能: この削除により、DynamoDBのリージョンエンドポイント（
dynamodb.us-east-1.amazonaws.com）に関連付けられた全てのIPアドレスがDNSレコードから消え去った。システムは「空のDNSレコード」を持つという矛盾した状態に陥り、さらなる自動更新も受け付けなくなった。
この結果、顧客やAWS内部サービスがDynamoDBに接続しようとしても、DNSサーバーが宛先を見つけられず、接続はことごとく失敗。AWSの中枢神経の一つが、完全に沈黙した瞬間だった。
ドミノ倒し：一つの障害はいかにしてAWS全土を焼き尽くしたか
DynamoDBのDNSレコードは、発生から約2時間半後の午前2時25分（PDT）に手動で復旧された。しかし、障害はこれで終わりではなかった。むしろ、本当の悪夢はここから始まった。最初の障害が引き金となり、AWSの複雑に絡み合ったシステム群が次々と連鎖的な機能不全に陥ったのである。
EC2を襲った「うっ血性崩壊」
最初の大きな二次災害は、仮想サーバーEC2で発生した。EC2の物理サーバー（AWS内部では「droplet」と呼ばれる）を管理する「DropletWorkflow Manager (DWFM)」というサブシステムは、その状態管理にDynamoDBを深く利用している。
DynamoDBが利用不能になったことで、DWFMは物理サーバーとの「リース（貸借契約）」を維持できなくなり、リースは徐々にタイムアウトしていった。DynamoDBが復旧すると、DWFMはリージョン内の膨大な数の全サーバーと一斉にリースの再確立を試みた。
しかし、その処理規模はあまりに巨大だった。一つのリースの再確立にかかる時間が長引き、処理が終わる前に別のリースがタイムアウトしてしまうという悪循環に陥った。システムは要求をさばききれず、処理キューが溢れかえり、前進できない状態、すなわち「うっ血性崩壊（congestive collapse）」に突入した。高速道路で出口の渋滞が本線にまで影響を及ぼし、全体が完全に動かなくなる現象に似ている。
AWSのレポートは「この状況には確立された運用復旧手順がなかった」と記しており、エンジニアチームが手探りで、かつ慎重な対応を迫られたことを示唆している。この問題の解決には、さらに約3時間を要した。
ネットワークの渋滞とNLBの混乱
DWFMが正常化した午前5時28分（PDT）、次なる問題が発生した。EC2インスタンスのネットワーク設定を管理する「Network Manager」だ。DWFMの問題で滞っていたネットワーク設定の変更処理が一斉に開始され、システムは膨大なバックログを抱えることになった。
これにより、新たに起動されたEC2インスタンスが正常なネットワーク接続を得るまでに大幅な遅延が発生。この遅延が、今度は「Network Load Balancer (NLB)」に影響を及ぼした。
NLBは、配下のEC2インスタンスが正常に稼働しているかを定期的に確認（ヘルスチェック）し、異常なインスタンスをトラフィックの振り分け先から除外する。しかし、Network Managerの遅延により、起動したばかりの正常なインスタンスがネットワークに接続できていないため、ヘルスチェックに失敗。NLBはこれを「異常」と判断して切り離すが、しばらくしてネットワークが接続されると次のヘルスチェックでは「正常」と判断し、再び組み込む。この「正常」と「異常」を繰り返す「フラッピング」と呼ばれる現象が多発し、NLBのシステム全体に過大な負荷をかけた。結果、NLBを利用するアプリケーションで接続エラーが増加した。
この連鎖的な障害は、EC2やNLBを基盤とするLambda、ECS、Fargateといったさらに上位のサービス群へと波及し、障害の影響範囲と時間を拡大させる主要因となった。
ハイパースケールの脆さと教訓
今回の障害は、現代のデジタルインフラが抱える根本的な課題を浮き彫りにした。技術コミュニティでは、AWSのレポートを基に活発な議論が交わされている。
「大きすぎて潰せない」インフラへの依存というリスク
今日のパブリッククラウド市場は、Amazon (AWS)、Microsoft (Azure)、Google (GCP) の3社が世界市場の3分の2以上を占める寡占状態にある。特にAWSは単独で30%以上のシェアを誇り、事実上の「インターネットの大家」とも言える存在だ。
金融、医療、メディア、そして政府機関までが単一の事業者に依存する構造は、電力網や国際金融システムと同様の「システミック・リスク」を内包している。一つの企業の、たった一つのリージョンにおける不具合が、世界経済に多大な影響を及ぼす。この現実は、多くの企業に分散化戦略の再考を迫るものだろう。
「自動化の皮肉」と失われる機関知
Redditなどの技術コミュニティで指摘されているのが、「自動化の皮肉」という概念だ。これは、システムが高度に自動化され、自己修復能力が高まるほど、平時の運用は楽になる一方で、想定外の事態が発生した際に人間が介入し、問題を解決する能力が低下するというジレンマを指す。
今回の障害対応において、一部の復旧作業に時間を要した背景には、こうした問題があった可能性が議論されている。また、近年のIT業界におけるレイオフや人材流動が、複雑なシステムを隅々まで熟知したベテランエンジニア、つまり「機関知」の喪失に繋がり、障害からの回復力を削いでいるのではないか、という懸念の声も上がっている。
障害から学ぶ「レジリエンス」の科学
この障害は、システムの「レジリエンス（回復力、弾力性）」の重要性を改めて突きつけた。多くの企業は、単一データセンターの障害に備え、同一リージョン内の複数のデータセンター（Availability Zone）にシステムを分散させる「マルチAZ」構成を採用している。
しかし、今回の障害は特定のAZではなく、リージョン全体に影響を及ぼした。これは、マルチAZ構成では防げない障害であり、事業継続のためには、地理的に離れた別のリージョンにバックアップシステムを用意する「マルチリージョン」、さらにはAWSとGoogle Cloudなど複数のクラウド事業者を併用する「マルチクラウド」といった、より高度でコストのかかる戦略が必要であることを示している。完璧なアップタイムは存在しないという前提に立ち、いかに障害を「生き延びるか」を設計する思想が、今後ますます重要になる。
AWSの対応と今後の展望
AWSは事後分析レポートの中で、再発防止策を明確に示している。
- 原因となったDynamoDBのDNS PlannerとEnactorの自動化システムは、全世界で一時的に無効化された。
- レースコンディションを引き起こした根本的な欠陥を修正し、不正確なDNS計画が適用されるのを防ぐための追加の保護メカニズムを導入するまで、自動化は再開されない。
- EC2やNLBについても、同様の連鎖障害を防ぐための改善策を講じるとしている。
この一件は、AWSにとって大きな教訓となったはずだ。しかし、それは同時に、クラウドを利用する全ての企業、そして現代社会全体への警鐘でもある。私たちが享受するデジタルの利便性は、想像を絶するほど複雑で、相互に依存し合った巨大システムの上にかろうじて成り立っている。その均衡は、ほんのわずかなプログラムの不具合と、不運なタイミングの重なりによって、いとも簡単に崩れ去る可能性がある。この障害の詳細な分析は、より堅牢で回復力のある未来のインターネットを築くための、痛みを伴う貴重なマイルストーンとなるだろう。
Sources
