Meta世界障害（2021）— BGPが消えた6時間

何が起きたか（日時・影響範囲）

2021年10月4日 15:39 UTC頃、Facebook（現Meta）のFacebook・Instagram・WhatsApp・Messenger・Oculusなど月間35億人規模のサービス群が世界同時に停止し、復旧まで約6時間を要しました。外部の経路観測では、同社のBGP経路——とりわけ権威DNSサーバーへの経路——がインターネットの経路表から一斉に消えたことが確認され、facebook.comは世界中のリゾルバで解決不能になりました。公式ポストモーテム（engineering.fb.com）によれば、原因は攻撃ではなく、定期メンテナンス中に発行された1本のコマンドでした。

タイムライン

Meta公式は分単位の時系列を公表していないため、時刻は外部の経路観測（Cloudflare等）に基づく概数です（すべてUTC）。

根本原因の技術解説

Metaのネットワークは、大規模データセンター群、ユーザーに近い小規模エッジ拠点（PoP）、両者を結ぶ自社バックボーンで構成されます。権威DNSサーバーはエッジ側に置かれ、周知のIPアドレスをBGPで（Anycastとして）世界へ広告します。

引き金は、グローバルバックボーンの容量余裕を評価する意図で発行されたコマンドです。これが誤って全バックボーン接続を落とし、全データセンターが相互にも、インターネットからも切断されました。この種のコマンドを事前検査する監査ツールはありましたが、ツール自体のバグにより実行を止められませんでした。

そこへ第二の故障が重なります。Metaの権威DNSサーバーは「自分からデータセンターへ到達できなければ、自分が不健全」とみなしてBGP広告を取り下げる設計でした。局所障害であれば、壊れた拠点だけが経路から抜け、トラフィックは健全な拠点へ逃げる合理的なフェイルアウトです。しかし今回はバックボーン全体が消えたため、全エッジ拠点が同時に「自分が不健全」と判定し、権威DNSの経路が地球上から消えました。サーバーは稼働したまま、到達経路だけが失われたのです。この判定が依拠する暗黙の前提——自分以外のどこかは健全——を、相関障害が同時に破壊した構図です。

さらにDNSの全喪失は、障害調査・復旧に使う社内ツール群を巻き込みました。通常手段でデータセンターに入れず現地対応へ切り替えましたが、施設は物理・システム両面で強固に防御されており、正規の緊急アクセス手順の発動にも余分な時間を要しました。

なぜ防げなかったか

横にスクロール

個々の設計は単体では合理的で、テストでも正しく動作します。敗因は、全バックボーン喪失という相関障害が、各設計の暗黙の前提（故障は部分的・脅威は外部・ツールは正しい）を同時に無効化したことです。公式はセキュリティ強化が復旧を遅らせた事実を認めた上で、日常の防御力との交換条件として妥当だったと総括しています。

教訓（原則として一般化）

• コントロールプレーンとデータプレーンの分離: 名前解決・監視・管理ツールを、守るべきサービスと運命共同体にしない。「復旧の道具は壊れた系に依存しない」ことを依存グラフで検証する。
• アウトオブバンド管理経路: 本番ネットワークから独立した管理経路・コンソールを常備し、緊急アクセス手順を平時から演習しておく。
• ヘルスチェックの相関障害耐性: 「不健全なら自分を外す」には、全体同時撤退への歯止め（撤退数の上限、最後の広告を維持するfail-static等）を組み込む。
• ガードレールの多層化: 監査ツールも故障する。ドライラン・段階適用・複数人承認を重ね、ガード自体をテスト対象にする。
• 復帰時の突入負荷管理: 全断からの一斉復帰は電力やキャッシュに突入負荷を生む（各データセンターで数十MW規模の変動）。Metaは拠点全停止を模擬するstorm演習の経験で段階復旧を成立させた。

BGP・DNSなど経路制御と名前解決の原理はネットワーク、変更管理やインシデント対応の設計はDevOpsの各トピックも参照してください。