パッチ盤からケーブルを引っこ抜いてしまいCloudflareに障害発生　ケーブルにラベリングされておらずどれを戻すべきかすぐに分からず

　CDNプロバイダーのCloudflareは、世界協定時4月15日の午後3時31分から午後7時52分（日本時間4月午前0時31分から午前4時52分）まで、ダッシュボードおよびAPIが使えなくなるという障害を発生していました。

　同社のブログ「Cloudflare Dashboard and API Outage on April 15, 2020」によると、同社の2つのコアデータセンターのうちの1つで、パッチ盤から間違ったケーブルを引っこ抜いたことが原因で、対策チームは新型コロナの影響で全員在宅のまま仮想チームを結成し、復旧に当たったと説明されています。

　障害発生から復旧まで何が起きていたのか、同社のブログの説明を中心に追っていきましょう。

パッチ盤からケーブルを引っこ抜かれた

　同社はCDNプロバイダーとして世界中にエッジデータセンターを展開しており、一方でそれを統合するコアデータセンターが2カ所あります。

　このコアデータセンターの1つで、使われていない機材をキャビネットから取り除くという作業が行われていました。このキャビネットには使われていない機材だけでなく、ケーブルの接続を集約するパッチ盤が設置されていました。

　作業を指示された技術者は、キャビネットから指定された機材を取り除いただけでなく、パッチ盤につながっていたケーブルも取り外しました。

　しかしこのケーブルのうち何本かは、このコアデータセンターからほかのCloudflareのデータセンターへ接続するためのケーブルでした（同社のブログでは明確に説明されていませんが、この技術者はCloudflareの技術者ではなく、Cloudflareが契約しているデータセンターの現場技術者ではないかと推測されます）。

　抜いていけないケーブルが引っこ抜かれたのです。

　これによりCloudflareのダッシュボードとAPI、構成変更、キャッシュのパージなどいくつかの機能が即座に停止しました（CDNそのものの機能に影響はなく、データが失われるなどの致命的な状態にはならなかったとのこと）。

　障害はすぐに検知され、対策が始まります。

対策スタッフは在宅のまま仮想チームを結成

　新型コロナウイルスの影響で、同社のスタッフのほとんどが在宅のまま障害対策にあたることになります。

　まずは2つの仮想チームを結成。1つは接続の復旧担当、もう1つはフェイルオーバーによるディザスターリカバリー担当です。

　この障害で、同社は社内におけるCloudflareのサービスに対するモニタリング機能も失っていました。しかしこれは即座にフェイルオーバーし、復旧されます。これにより、Cloudflareそのものは通常と同じように運用監視が可能になりました。下記はブログからの引用です。

This gave us global control and the ability to see issues in any of our network locations in more than 200 cities worldwide. This cutover meant that Cloudflare’s edge service could continue running normally and the SRE team could deal with any problems that arose in the day to day operation of the service.

これによってグローバルなコントロールが可能になり、世界200都市以上のネットワーク拠点の問題を確認できるようになりました。これでCloudflare のエッジサービスは正常に稼働し続け、SRE チームはサービスの日々の運用で発生した問題に対処できるようになりました。

　引き続き、接続復旧担当チームとディザスターリカバリー担当チームは復旧作業を続けますが、同社は20分ごとに、まずどちらの方法で復旧するのか状況判断を行ったと説明します。

　そして結局、失われた接続を復旧する方法を選択します。その理由として、これまで同社が行っていたディザスタリカバリーのテストの経験から、フェイルオーバーは簡単だけれど障害復旧後にフェイルバックする作業が非常に複雑だから、でした。

そして世界協定時で7時51分に基本的な回線が復旧。前述の通り7時52分にはダッシュボードやAPIが機能し始め、障害自体から復旧に成功します。その後も回線復旧作業は続き、世界協定時8時31分には冗長回線を含む4回線全ての接続が復旧しました。

1つのパッチ盤に回線集中、ラベルもなく

　この障害が発生した原因と対策を、同社は次のように説明しています。

　1つ目は、特定のパッチ盤に重要なケーブルを全てまとめていたことです。冗長性のために異なるインターネットプロバイダーを複数用いていたものの、そのケーブルが全て1つのパッチ盤にまとめられていたために、ここが物理的な単一障害点になっていました。そうした集中は避けるべきだったと。

　2つ目はパッチ盤やケーブリングに対するラベリングです。ラベリングが行われていなかったため、作業担当者はどのケーブルをパッチ盤のどこに挿すべきなのかが分からず、復旧が遅れてしまいました。今後はきちんとラベリングするとしています。

　そして3つ目は、作業担当者に対する指示として、ケーブルには触らないように明示しなかったことが挙げられています。

　慎重に設計され、長年にわたって稼働していた大規模システムであっても、どこに単一障害点があるか分からないものです。ネットワークの物理的設計、そして基本であるきちんとしたラベリングなど、同社はネットワークエンジニアリングの基礎をもう一度見つめ直したことでしょう。

この記事の著者

関連記事

• 

  「クラウドは信頼できない」は本当か？　AWS、Office 365、自治体IaaSの障害を経て、私たちが知っておくべきこと

• 

  3月末のGoogle Cloud障害の原因判明　分散アクセスコントロールへの大量の変更要求が引き起こしたメモリ不足

• 

  教育機関向けSaaS「Classi」に不正アクセス　約122万人のユーザーIDなど流出の恐れ