新規投稿のお知らせを受信されたい方は、サブスクリプションをご登録ください:

2020年7月17日に発生したCloudflareの障害について

2020-07-18

3分で読了
この投稿はEnglish繁體中文한국어简体中文でも表示されます。

本日、バックボーンネットワークで発生した設定エラーにより、インターネットプロパティとCloudflareサービスが27分間にわたり、停止する障害が発生しました。その結果、当社ネットワーク全体で約50%のトラフィックが減少しました。バックボーンの構造上、この停止がCloudflareネットワーク全体に影響を与えることはなく、特定の地域での影響に抑えられました。

この障害は、ニューアークとシカゴ間のバックボーンセグメントとは無関係の問題に取り組んでいる最中に発生したもので、当社のネットワークエンジニアリングチームが、輻輳を軽減するためにアトランタでルーター設定を更新したことが原因です。この設定には、当社のバックボーン全体のトラフィックすべてがアトランタに送信される原因となったエラーが含まれていました。これにより、急速にアトランタのルーターの負荷が増加し、バックボーンに接続されるCloudflareネットワークのロケーションで障害が発生しました。

影響を受けた地域は、サンノゼ、ダラス、シアトル、ロサンゼルス、シカゴ、ワシントンDC、リッチモンド、ニューアーク、アトランタ、ロンドン、アムステルダム、フランクフルト、パリ、ストックホルム、モスクワ、サンクトペテルブルク、サンパウロ、クリチバ、ポルトアレグレです。他の場所では、通常通りの稼働が継続されました。

これは、攻撃や違法行為によって発生したものでないことをここに明記いたします。

この障害によりご迷惑をおかけしたことを心よりお詫び申し上げます。このような事態を二度と起こさないために、グローバルにバックボーン設定を変更いたしました。

Cloudflareのバックボーン

Cloudflareはバックボーンを世界中にあるデータセンター間で運用しています。バックボーンは様々なデータセンターを接続する一連のプライベート回線で、データセンター間でより高速で信頼性の高いルーティングを確保するために使用しています。こうしたリンクのおかげで、当社は異なるデータセンター間のトラフィックをパブリックインターネットを経由することなく、実行することができるのです。

たとえば、当社はニューヨークにあるWebサイトの配信元サーバーにアクセスするためにこれを使い、当社のプライベートバックボーンを介して、サンノゼとカリフォルニアの両方、さらにフランクフルトやサンパウロにまでリクエストを運びます。パブリックインターネットの回避というオプションが追加され、プライベートネットワークがインターネット輻輳ポイントを回避するために使うことができるため、質の高いサービスを提供することが可能となります。バックボーンを使うと、インターネットリクエストとトラフィックをどこでどのようにルーティングするかという点で、パブリックインターネットを使うよりもはるかに優れたコントロールが実現します。

タイムライン

記載の時間は全て協定世界時(UTC)です。

まず、ニューアークとシカゴ間のバックボーンリンクで問題が起き、これがアトランタとワシントンDC間でのバックボーンの輻輳につながりました。

この問題に対応するために、アトランタで設定変更が行われました。21:12に、この変更によって停止が始まりました。停止が確認されると、アトランタのルーターを無効化し、トラフィックが正常に流れ始めたのが、21:39です。

その後まもなく、ログとメトリクスを処理するコアデータセンターの一つで輻輳が発生し、ログの一部が削除されました。この期間、エッジネットワークは正常に稼働を続けていました。

  • 20:25: ニューアークとシカゴ間のバックボーンリンクが喪失

  • 20:25: アトランタとワシントンDC間のバックボーンが輻輳を始める

  • 21:12 から 21:39: アトランタでバックボーン全体からトラフィックが集中する

  • 21:39 から 21:47: アトランタでバックボーンが削除され、サービスが復旧する

  • 21:47 から 22:10: 中心となった輻輳がログの削除を引き起こし、エッジは通常稼働を続行

  • 22:10: ログとメトリクスを含め、完全復旧する

こちらは、Cloudflareの社内トラフィックマネージャーツールの影響を示したものです。上部の赤色とオレンジ色の部分は、アトランタのCPU使用率が過負荷に達していることを示しています。そして、白い部分は影響を受けたデータセンターでトラフィックが処理できなくなったため、CPUがゼロ近くまで低下したことを示しています。こちらは、障害の発生期間です。

影響を受けなかったデータセンターでは、インシデント(障害発生)中でもCPU使用率に何も変化が起きなかったことがわかります。緑色は、インシデント中でもこうしたデータセンターでは、なんの変化も起きなかったという事実を示しています。

何が起きたのか、Cloudflareがどう対処したか

アトランタでバックボーン輻輳が発生していたので、当社チームはアトランタのバックボーントラフィックを一部削除することにしました。しかし、バックボーンからアトランタのルーティングを削除するのではなく、1行変更したために、バックボーンへのBGPルーティング全ての漏えいが開始されました。

{master}[edit]
atl01# show | compare 
[edit policy-options policy-statement 6-BBONE-OUT term 6-SITE-LOCAL from]
!       inactive: prefix-list 6-SITE-LOCAL { ... }

term全体はこちらの通りです。

from {
    prefix-list 6-SITE-LOCAL;
}
then {
    local-preference 200;
    community add SITE-LOCAL-ROUTE;
    community add ATL01;
    community add NORTH-AMERICA;
    accept;
}

from {

このtermは、local-preference (ローカルプリファレンス)値を設定し、いくつかのコミュニティを追加、そしてprefix-list(プリフィクスリスト)に一致するルーティングを受け入れます。ローカルプリファレンスとは、iBGPセッションの推移的プロパティです(次のBGPピアに転送されます)。

プリフィクスリストの無効化ではなく、termを無効にすることが、正しい変更でした。

プリフィクスリストの条件を削除することで、ルーターはBGPルーティングの全てを他のバックボーンルーター全てに送信するように指示し、ローカルプリファレンスは200に増加しました。残念なことに、今回エッジルーターがコンピュートノードから受信したローカルルーティングは、ローカルプリファレンスが100でした。ローカルプリファレンスは高い方が優先されるため、ローカルコンピュートノード向けのトラフィックは全てアトランタコンピュートノードへと流れてしまいました。

ルーティングが送信されると、アトランタはバックボーンからトラフィックが集中し始めました。

当社は、以下の変更を行いました。

  • バックボーンBGPセッションに最大プリフィクスの制限を導入。この導入によりアトランタのバックボーンがシャットダウンされてしまいますが、当社のネットワークはバックボーンなしでも適切に機能するネットワークの構築ができます。この変更は、7月20日月曜日にリリースされます。

  • ローカルサーバールーティングのBGPローカルプリファレンスを変更。この変更により、一か所のロケーションのトラフィックが同様の方法で、他のロケーションのトラフィックを収集できなくなります。この変更は、インシデント発生後に展開されています。

まとめ

当社のバックボーンで障害が発生するのは初めてのことであり、チームは迅速に対応して影響を受けたロケーションのサービス復旧させましたが、関係者の皆様にご迷惑をおかけするのは非常に心苦しい限りでした。お客様およびユーザーの皆様、障害発生中にインターネットプロパティへのアクセスができなくなり、ご迷惑をおかけしたことを深くお詫び申し上げます。

バックボーン設定に変更を加え、このようなことが再び起こることがないよう対策を講じました。さらなる変更は月曜日に再開される予定です。

Cloudflareは企業ネットワーク全体を保護し、お客様がインターネット規模のアプリケーションを効率的に構築し、あらゆるWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃を退けハッカーの侵入を防ぎゼロトラスト導入を推進できるようお手伝いしています。

ご使用のデバイスから1.1.1.1 にアクセスし、インターネットを高速化し安全性を高めるCloudflareの無料アプリをご利用ください。

より良いインターネットの構築支援という当社の使命について、詳しくはこちらをご覧ください。新たなキャリアの方向性を模索中の方は、当社の求人情報をご覧ください。
Post MortemOutage

Xでフォロー

Cloudflare|@cloudflare

関連ブログ投稿

2024年9月20日 14:00

Cloudflare incident on September 17, 2024

On September 17, 2024, during planned routine maintenance, Cloudflare stopped announcing 15 IPv4 prefixes, affecting some Business plan websites for approximately one hour. During this time, IPv4 traffic for these customers would not have reached Cloudflare and users attempting to connect to websites using addresses within those prefixes would have received errors. ...