目次
Facebookがおよそ6時間ダウン
2021年10月4日、FacebookやInstagramなどFacebook関連のサービスがおよそ6時間もダウンしてしまいました。その原因について、Facebookのエンジニアが詳細を語っています。
障害の原因
この記事に記載されている障害について、簡単にまとめます。
- Facebookのバックボーンで一部のネットワークをオフラインにしようとするも、誤ってバックボーン全体がオフラインに
- DNSサーバ自体は動作していたけど、DNSサーバへ到達できなくなっていた
- 障害を復旧するために社内ツールの多くが利用できなかった
- オンサイトで対応しようとしたものの、データセンターのセキュリティが強固だったので時間がかかった
Facebookのバックボーンで一部のネットワークをオフラインにしようとするも、誤ってバックボーン全体がオフラインに
障害の主な原因として、以下の記述があります。
This was the source of yesterday’s outage. During one of these routine maintenance jobs, a command was issued with the intention to assess the availability of global backbone capacity, which unintentionally took down all the connections in our backbone network, effectively disconnecting Facebook data centers globally. Our systems are designed to audit commands like these to prevent mistakes like this, but a bug in that audit tool prevented it from properly stopping the command.
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
メンテナンスのためにバックボーンの一部をオフラインにするつもりが、バックボーンのすべてのコネクションを切断してしまったということです。なんのコネクションなのかは具体的なことは記述されていませんが、BGPの問題という話だったので、BGPネイバーをぜんぶ切ってしまったのかなぁと思います。BGPネイバーを切ってしまったら、FacebookのルートがBGPでアドバタイズされなくなって、インターネットからFacebookが見えなくなってしまいます。こんなクリティカルな状況を引き起こしうるコマンドを実行するときのミスを防ぐための監査ツールがあるのですが、うまく機能しなかったようです。
そして、Facebookのバックボーンがオフラインになったことがさらに障害を招いてしまうことに・・・
This change caused a complete disconnection of our server connections between our data centers and the internet. And that total loss of connection caused a second issue that made things worse.
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
DNSサーバ自体は動作していたけど、DNSサーバへ到達できなくなっていた
DNSサーバを世界中のいろんなサイトに分散して配置しているのでしょうが、DNSサーバからもFacebookのルートが無効になったことをアドバタイズしてしまったようですね。
To ensure reliable operation, our DNS servers disable those BGP advertisements if they themselves can not speak to our data centers, since this is an indication of an unhealthy network connection. In the recent outage the entire backbone was removed from operation, making these locations declare themselves unhealthy and withdraw those BGP advertisements. The end result was that our DNS servers became unreachable even though they were still operational. This made it impossible for the rest of the internet to find our servers.
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
DNSサーバがバックボーンネットワークのダウンを検出すると、DNSサーバを配置しているサイト自体のBGPルートのアドバタイズも無効化してしまったようです。Facebookのバックボーンのルートも消えて、世界中のDNSサーバを配置しているサイトのルートも消えたっていうことですね。なので、FacebookのDNSサーバ自体は動作していたけど、DNSサーバへ到達できなくなってしまったようです。当初、「DNSの問題か」と言われていた症状がこのことですね。
障害を復旧するために社内ツールの多くが利用できなかった
当然、すぐに障害には気がついたんでしょうけど、復旧するために社内ツールの多くが利用できなかったとのこと。
All of this happened very fast. And as our engineers worked to figure out what was happening and why, they faced two large obstacles: first, it was not possible to access our data centers through our normal means because their networks were down, and second, the total loss of DNS broke many of the internal tools we’d normally use to investigate and resolve outages like this.
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
特にDNSサーバへの接続が絶たれてしまったことが、社内ツールの多くが利用できなかった主な原因みたいです。また、この障害はユーザ向けのサービスだけじゃなくて、Facebook社内のシステムにもかなり影響が出てしまったようです。
オンサイトで対応しようとしたものの、データセンターのセキュリティが強固だったので時間がかかった
すると、「現場へGO!」になるわけですが・・・
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. They’re hard to get into, and once you’re inside, the hardware and routers are designed to be difficult to modify even when you have physical access to them. So it took extra time to activate the secure access protocols needed to get people onsite and able to work on the servers. Only then could we confirm the issue and bring our backbone back online.
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
「現場へGO!」しても、データセンターのセキュリティはガチガチ。建物に入るのも一苦労。システムを操作するのも大変。復旧までにかなりの時間を要することに。復旧するまでに6時間程度かかってしまったようです。世界中に何十億人もユーザがいるサービスが6時間も止まると、損失も膨大な金額になってしまいますね。明確な損失額を算定するのは無理だと思いますが、何百億円規模になってしまいそう。
不正アクセスではない
ちょうどタイミングよく(悪く?)、Facebookの元社員が内部告発していて公聴会で証言していた時でした。
そのため、「Facebookを狙った不正アクセスか?」という話もありましたが、原因としては、シンプルなオペレーションミスです。それにしても、こんな事態を引き起こしてしまったオペレーションミスをした人は大丈夫かと心配になってしまいますね。
バランスを取るのは難しい
今やシステムのセキュリティ強化は至上命題といっていいぐらいですが、あまりにもセキュリティを強化してしまうと、障害を復旧させるときに思わぬ時間がかかってしまうことになるわけですね。
We’ve done extensive work hardening our systems to prevent unauthorized access, and it was interesting to see how that hardening slowed us down as we tried to recover from an outage caused not by malicious activity, but an error of our own making. I believe a tradeoff like this is worth it — greatly increased day-to-day security vs. a slower recovery from a hopefully rare event like this. From here on out, our job is to strengthen our testing, drills, and overall resilience to make sure events like this happen as rarely as possible.
https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
傍から観ている分には、とても興味深い障害事例ですが、Facebookのシステム管理者の人たちは、大変だったでしょう。お疲れ様でした。詳しい障害原因のレポートに感謝です。
BGPの仕組み
- BGPの概要 ~AS間でルート情報を交換~
- BGPの動作
- BGPの基本設定と確認コマンド
- BGPピアグループ(Peer Group) ~ネイバーの設定をまとめよう~
- BGPネイバーの状態
- BGPコンフェデレーションの設定
- BGPコンフェデレーションの設定例
- BGPネイバー認証
- BGP Well Known Mandatory アトリビュート -ORIGIN/AS_PATH/NEXT_HOP-
- 図解!BGPベストパス選択アルゴリズム
- BGP 基本的な設定についての演習[Cisco]
- BGPの基本的な設定についての演習 ~トラブルシュート~
- BGP KEEPALIVEタイマ/ホールドタイムの設定
- BGPルート 最小送信間隔の設定
- BGPルートダンプニング
- マルチホーム – インターネット接続の冗長化 –
- マルチホームAS BGPルートフィルタのポイント
- マルチホームAS ベストパス選択のポイント
- マルチホームAS IGPとBGPの連携のポイント
- マルチホームAS BGPの設定例
- IP-VPNでのBGPの利用 設定例
- BGPルートフィルタの種類
- BGPルートフィルタ -ディストリビュートリスト-
- BGPルートフィルタ -ディストリビュートリスト設定例-
- BGPルートフィルタ -プレフィクスリスト-
- BGPルートフィルタ -プレフィクスリスト設定例-
- BGPルートフィルタ -フィルタリスト(AS_PATH ACL)-
- BGPルートフィルタ -フィルタリスト(AS_PATH ACL)設定例-
- BGPルートフィルタ -ルートマップ(route-map)-
- BGPルートフィルタ -ルートマップ(route-map)設定例-
- BGP neighbor allowas-inコマンド
- BGP neighbor as-overrideコマンド
- BGPルート RIB Failure
- BGPルート アドミニストレイティブディスタンスの制御
- BGPルートの負荷分散
- BGPルート 条件付き生成
- BGPルート 条件付きアドバタイズ
- BGP ルート集約 自動集約
- BGPルート集約 networkコマンドによる集約
- BGPルート集約 networkコマンドによる集約 設定例
- BGP ルート集約 aggregate-addressコマンドによる集約
- aggregate-addressコマンドのオプション summary-only
- aggregate-addressコマンドのオプション attribute-map
- aggregate-addressコマンドのオプション as-set
- aggregate-addressコマンドのオプション advertise-map
- aggregate-addressコマンド as-set/attribute-map/advertise-map 設定例
- BGP選択型集約の概要
- BGP選択型集約 suppress-map
- BGP選択型集約 unsuppress-map
- BGP 選択型集約 suppress-map/unsuppress-map 設定例
- BGP local-as ~ネイバーに他のASのように見せる~
- BGP neighbor remove-private-ASコマンド
- bgp fast external-fallover
- BGP プレフィクス数の制限
- BGP COMMUNITYアトリビュートの使い方
- BGP Well-known COMMUNITYのルートフィルタ設定例
- BGP プライベートCOMMUNITYによるルート制御の設定例
- [演習]BGP応用 Part1:BGP基本設定
- [演習]BGP応用 Part2:ルート集約
- [演習]BGP応用 Part3:ポリシーベースルーティング
- [演習]BGP応用 Part4:トラブルシューティング
- BGP 設定ミスの切り分けと修正 Part1
- BGP 設定ミスの切り分けと修正 Part2
- BGP 設定ミスの切り分けと修正 Part3
- BGP 設定ミスの切り分けと修正 Part4
- BGP 設定ミスの切り分けと修正 Part5
- BGP 設定ミスの切り分けと修正 Part6
- BGP 設定ミスの切り分けと修正 Part7
- IPv6 BGPの設定例 Part1
- IPv6 BGPの設定例 Part2
- 2021年10月4日 Facebookに何が起こったか?
- IPv4 BGPネイバーでのIPv6プレフィックスの交換