DNSやASの管理者が読むべきFacebookがダウンした理由

2021年10月4日にFacebookがoutage(停止)した事象について、Facebook自身はブログに「バックボーンルータの構成変更が原因」と書いている。

Our engineering teams have learned that configuration changes on the backbone routers that coordinate network traffic between our data centers caused issues that interrupted this communication.

一方、どういうわけかCloudflareが詳しくまとめている。今やDDoS攻撃についてセキュリティ企業のお株を奪うようなレポートを発表し、シリアやスーダンが国家試験のためにインターネットを遮断していることまでブログに書いちゃう彼らだが、Cloudflareを使っていないサービスのoutageについて、彼らは何を知ることができているのだろう。

https://blog.cloudflare.com/october-2021-facebook-outage/

Today at 15:51 UTC, we opened an internal incident entitled "Facebook DNS lookup returning SERVFAIL" because we were worried that something was wrong with our DNS resolver 1.1.1.1. But as we were about to post on our public status page we realized something else more serious was going on.

Cloudflareは1.1.1.1というIPアドレスでパブリックDNSサービスを提供している。Googleの8.8.8.8みたいなものだ。まず、これがFacebookのDNSを解決できていないことに気付いた。

At 15:58 UTC we noticed that Facebook had stopped announcing the routes to their DNS prefixes. That meant that, at least, Facebook’s DNS servers were unavailable. Because of this Cloudflare’s 1.1.1.1 DNS resolver could no longer respond to queries asking for the IP address of facebook.com.

その数分後には、Facebookが発表した通りDNS prefixへのルートのannounceが止まっていることに気付いた。

インターネットはAS(autonomous system:自律システム)と呼ばれるネットワークの塊がBGPと呼ばれるプロトコルで相互にルーティング情報を交換することで互いに接続できるようになっているが、Cloudflareが持っているASからshow ip bgpというコマンドを打ったらFacebookのDNSがあるネットワークが「Network not in table」だった。一方でWebサーバなどがあるネットワークは問題なかったようだ。

PeeringDBを見てみると、Facebookは２つのASを持っているが、片方のASで確かにPublic Peering Infoが2021年10月6日に更新されている。

ネームサーバ（権威サーバ）があるネットワークがルーティングされなくても、キャッシュサーバに残ってるじゃないかと思うが、そう簡単な話ではない。

If the nameservers are unreachable or fail to respond because of some other reason, then a SERVFAIL is returned, and the browser issues an error to the user.

ネームサーバが到達不可能だった場合、SERVFAILを返す。そしてブラウザにはエラーメッセージが表示される。

But that's not all. Now human behavior and application logic kicks in and causes another exponential effect. A tsunami of additional DNS traffic follows.

human behaviorによるリトライと、application logicによるリトライがexponentialに増え、tsunamiのようになり普段の30倍ものトラフィック増を観測した。

At around 21:00 UTC we saw renewed BGP activity from Facebook's network which peaked at 21:17 UTC.

およそ5時間後に、ようやくFacebookのBGPの更新が観測された。この5時間に何が起こっていたかはFacebook自身が書いている。

More details about the October 4 outage

Our primary and out-of-band network access was down, so we sent engineers onsite to the data centers to have them debug the issue and restart the systems. But this took time, because these facilities are designed with high levels of physical and system security in mind.

ネットワークがダウンしたので遠隔で作業できず、エンジニアがデータセンタに向かったがセキュリティが高いため、なかなか作業に取り掛かれない。

But the problem was not over — we knew that flipping our services back on all at once could potentially cause a new round of crashes due to a surge in traffic. Individual data centers were reporting dips in power usage in the range of tens of megawatts, and suddenly reversing such a dip in power consumption could put everything from electrical systems to caches at risk.

サービスを一度に戻すと電源にリスクが生じる。

Helpfully, this is an event we’re well prepared for thanks to the “storm” drills we’ve been running for a long time now. In a storm exercise, we simulate a major system failure by taking a service, data center, or entire region offline, stress testing all the infrastructure and software involved.

こういったstorm(嵐)を想定したdrillを用意し、前々からリージョン単位でオフラインにしたり、ストレステストをしていたので自信をもって回復に必要な作業をできたとのこと。

PeeringDBで日本の企業やサービス名で検索してみると、トラフィックの多そうなところはASを持っている。国内にもBGPを扱う技術者がいるわけだが、めったなことではトラブルにならないので学習する機会も少ないかもしれない中、Cloudflareは実際に打ったCiscoのルータのコマンドやdigというDNSの確認用のコマンドのレスポンスまで乗せていて、教材としての価値がある。