Facebook、10月4日の障害について詳細な情報を公開。キャパシティ評価コマンドがバックボーンネットワークを全切断

投稿: 2021年10月06日
タグ: 
  Web  ニュースネタ

Facebook は10月4日に発生した数時間の障害について、以下記事で より詳細な情報を公開しました。

More details about the October 4 outage
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/open_in_new
  • 障害のトリガーとなったのは定常実行しているコマンド実行
  • コマンド実行によってバックボーンネットワークの全ての接続が切断
  • バックボーン経由で通信できなくなった DNSサーバーが BGPアドバタイズした結果、Facebook の DNSサーバーに到達不能に
  • データセンター現地での障害対応が必要になった
  • 障害の発端はグローバルに展開されたバックボーンネットワークの可用性を確認するコマンド実行

    Facebook のネットワーク構成は以前から Engineering Blog で何度か紹介されており、以下記事に記載されているように クライアントからの通信がデータセンターに到達するのにバックボーンネットワークを経由する構成になっているようです。

    画像_2021-10-06.jpg
    Steering oceans of content to the world
    https://engineering.fb.com/2017/08/21/networking-traffic/steering-oceans-of-content-to-the-world/open_in_new

    定常的に実行しているバックボーンのキャパシティ評価のコマンドを実行したところ、バックボーンの全ての接続が切断されたとのことです。
    さらに、コマンドの不備を監査するシステムの不具合により、コマンドが正常に止められることなく実行されたと記載されています。 今回の記事からは「なぜコマンド実行がバックボーンネットワークの切断を引き起こしたか」は読み取れませんが、 『悪意のある行動(malicious activity)』が原因ではなく、『自身で作ってしまった問題(an error of our own making)』とのことです。

    DNSサーバー自体が Facebook データセンターと通信できなくなり、BGPのアドバタイズが停止

    Facebook の DNSサーバーは自身のデータセンターと接続できない場合、不健全であると判定し、BGPルートのアドバタイズを停止する仕組みになっており、 その結果、Facebook の DNSサーバーに誰も到達できなくなり、facebook.com の名前解決ができなくなったようです。
    BGPアドバタイズと DNSリクエストの推移は Cloudflare社の以下記事がとても分かりやすいです。

    Understanding How Facebook Disappeared from the Internet
    https://blog.cloudflare.com/october-2021-facebook-outage/open_in_new

    一部の DNS を切り離すのに必要な仕組みですが、バックボーンが全部死んで全DNSも道連れになるというのは想定になかったようです。

    現地データセンターでのトラブルシュートが必要になったため復旧まで長時間化

    当該記事によると、プライマリのネットワークに加えて別のネットワークもダウンしたことで障害対応でデータセンターの現地に行かざるを得なかったようです。 さらに、データセンターは物理的にもシステム的にも高いセキュリティのため、データセンターに入るにも入ってから機器設定を変更するにも時間がかかったようです。

    ※ 実プロジェクトでも稀に見る(見たくない) 光景で、担当者の焦りが想像できます。。

    サービスを一気に立ち上げることによるトラフィック急増を回避

    バックボーンネットワークの接続が復旧してもサービスを一度に立ち上げるとトラフィックの急増で新たな障害が発生する可能性があるため、 負荷を管理しながら順次サービス再開したとのことです。
    この点も大規模サービスではあるあるといいつつも普段からストレステストをしていたことで大きな問題はなかったよ、と記載されています。 また、今後は『グローバルバックボーンがオフラインになること(今回の障害) をシミュレートする方法を検討する』とのことです。

    非常に広範囲な障害で、かつ現地にオンサイトしなければいけない、という状況下で約6時間で復旧したと考えると大変さが偲ばれます。

    公開されることはないでしょうが、根本原因であったバックボーンネットワーク全ての接続を切断するコマンドがどんなものだったのか気になります。
    また、そもそもの話として ビジネスは B2B(広告販売) とはいいつつ、実際のユーザーは Consumer 中心の Facebook が障害レポートを即日公開する、というのは好感が持てます。

    エンジニア目線では、この規模の障害で現地オンサイトが必要な状況で6時間で順次復旧したというのは最善の結果だったのでは(もちろん不具合や構成には課題はありますが)、と思ってしまいます。