Facebook障害：サーバーの稼働と、届くことの違い

要点

サーバーは動いている。それでも、利用者には応答が返らない。2021年10月4日のFacebookの障害には、一見矛盾するこの状態があった。故障していない機械を探し当てられないのなら、機械を再起動するだけでは話は済まない。

会社が翌日に公開した技術報告によると、DNSサーバーは稼働し続けていた。DNSは、サービス名から接続先のアドレスを調べる仕組みだ。その問い合わせ先にインターネットから到達できなくなったことで、Facebook、Instagram、WhatsAppを開こうとする利用者にも問題が及んだ。

発端は定期保守だった。世界各地のデータセンターを結ぶ基幹網について、余っている容量を調べるはずのコマンドが、意図せず接続を切ってしまったという。この種の操作を止めるための監査ツールにも不具合があり、実行を阻止できなかった。

DNSサーバーは基幹網を通じてデータセンターに届かなくなると、設計どおりにBGPの経路広告を撤回した。BGPは、各ネットワークが「この宛先にはこちらから行ける」と経路情報を交換する仕組みである。必要な案内が消えれば、サーバーが稼働していても問い合わせは届かない。

外部からも変化は見えた。Cloudflareの記録では、UTCの15時40分ごろに経路変更が急増し、15時58分にDNS用アドレス群の経路撤回を確認した。ただし、ほかのFacebookのアドレス群には経路が残っていた。全アドレスが一斉に消えたという説明では正確さを欠く。

障害は、修復のためのアクセスにも及んだ。会社は通常のネットワーク経由のアクセスと、別に設けた管理用の帯域外アクセスの両方を失ったと説明している。DNSが使えなくなったことで、内部の調査ツールにも支障が出た。

ここで二つの事実を一つの原因にまとめてはいけない。DNS依存のツールが壊れたことと、帯域外アクセスが失われたことは報告されているが、前者が後者を直接引き起こしたとまでは書かれていない。

アクセスを回復するため、技術者が現地へ派遣された。物理面とシステム面の安全対策が、入場や機器の変更を難しくしたという。とはいえ、誰か一人が車で駆けつけたという場面や、その移動に何時間かかったかは資料からは分からない。

基幹網を戻しても、すべてのサービスを一度に立ち上げるわけにはいかなかった。急激な通信量と電力需要の増加を避けるため、会社は慎重に再起動を進めたと説明する。過去の障害訓練は役立ったが、世界規模の基幹網が完全に失われる事態は訓練していなかった。

Cloudflareは21時ごろにBGPの動きが再開し、21時17分にピークを迎えたと記録した。21時28分には世界的な再接続とDNSの回復が確認できる状態に見えた。それでも、個々のアプリが使えるようになるまでには、さらに時間がかかる可能性があった。

15時58分から21時28分までは330分。この計算は二つの観測の間隔を示すのであって、すべての利用者の利用不能時間ではない。まして、技術者の移動時間ではない。最初の二つの観測が18分離れていることから、内部で検知できた機会がその18分だけだったとも言えない。

繰り返される問い合わせは、外部のDNSにも負荷をかけた。ただ、Cloudflareの1.1.1.1では、大半の問い合わせがなお10ミリ秒未満で処理されていた。一部の遅い応答はさらに遅くなったが、インターネット全体が使えなくなったわけではない。

稼働、到達、利用再開。普段はひと続きに見えるものが、この日は別々の段階になった。当時の二つの記録から分かるのは、その段階を戻る難しさである。Meta Platformsが後に何を改め、現在どのような構成で運用しているかは、別の証拠を必要とする。

2026年10月21日訂正：DNSに依存するツールの不具合と管理アクセスの喪失を区別した。外部観測の間隔を移動時間や全サービス共通の停止時間とする記述、および2021年の資料だけで現在の構成を判断する記述を削除した。