潜在的な不具合は適切な引き金を待っている
この欠陥は、ある顧客の設定がたまたまそれを発火させるまで、約4週間にわたって本番環境に存在していた——「まだ事故が起きていない」ことは「リスクが存在しない」ことと同じではないという警告だ。
ケーススタディ · 2021年6月
ある顧客の設定変更が インターネットの5分の1を壊した。
Fastlyのある顧客が行った、それ自体は有効な単一の設定変更が、5週間前から潜んでいた不具合を引き起こし、Fastlyのネットワークの85%をオフラインに追い込んだ——Reddit、Amazon、Twitch、政府系サイト、主要ニュースメディアが世界中で一斉にダウンした。
スクロールしてタイムラインを見る
49分
検知から95%復旧までの時間
85%
エラーを返していたFastlyネットワークの割合
概要
何が起きたのか、一つの表で。
Fastlyはこの事件について財務的な損失額を一切公表していない——これ自体が注目に値する点であり、本ケーススタディは金額ではなく対応速度の教訓として取り上げている。
日付
2021年6月8日、米国東部時間の午前5時50分頃から6時45分頃まで。
原因
5月12日のソフトウェアデプロイによって、特定の顧客設定でのみ発火する潜在的な不具合が持ち込まれていた。6月8日、ある顧客がまさにその条件に一致する有効な設定変更をプッシュしたことで発火した。Fastly自身の総括による。
規模
Fastlyのネットワークの約85%がエラーを返し始め、Reddit、Twitch、Spotify、PayPal、Shopify、Stripe、英国政府サイト(gov.uk)、そしてCNN、ガーディアン、ニューヨーク・タイムズを含む主要ニュースメディアがダウンした——これらのサイトに共通点はなく、唯一の接点は同じCDNを利用していたことだけだった。
復旧
Fastlyは1分以内に障害を検知し、発火要因を特定して無効化し、49分以内にネットワークの95%を通常運用に復旧させた——このリストの中でも、世界規模の障害からの復旧としては最速クラスの部類に入る。
報告された損失額
このリストの他の事例とは異なり、Fastlyまたは第三者によってこの事件の総合的な財務損失額が公表されたことは一度もない——注目度の高い障害であっても、引用可能な金額が一切生まれないケースが少なくないことを示す一例だ。
なぜこれほど早く広がったのか
不具合は古く、引き金は新しかった。
この事件は、共有インフラのリスクと、訓練された優れたインシデント対応がどのようなものかの両方を示している。
一顧客の行動が、全員の障害に
単一テナントによる有効かつ許可された設定変更だけで、共有プラットフォーム全体が他のすべての顧客にとって劣化してしまった——マルチテナント型インフラには、どの一顧客の慎重さにも依存しない爆発半径の制御が必要だ。
迅速な検知がコスト曲線全体を変える
1分での検知と49分での復旧により、この事件は関係するどの企業も具体的な損失を公表していないと見られるほど短時間で収束した——MTTRへの投資が最も必要な時にこそ報われることの証明だ。
よくある質問
Fastly障害について、Q&A。
CDN依存やインシデント対応の事例としてこの障害を引用する際によく出る質問。
これはサイバー攻撃でしたか?
いいえ——Fastlyは、外部からの攻撃ではなく、正当な顧客による設定変更が引き金となったソフトウェアの不具合が原因だとしています。
なぜこの事件には損失額が公表されていないのですか?
Fastlyも影響を受けた顧客サイトも財務的影響を公表していません——障害の継続時間が短かったことが、公にそれを数値化する動機や必要性を薄めた可能性があります。
なぜこれほど多くの無関係なサイトが同時にダウンしたのですか?
これらはすべてFastlyをコンテンツ配信ネットワークとして利用していたため、Fastlyの共有インフラの障害が、各サイト自身の信頼性対策とは関係なく、同じ影響を受けた容量に依存するすべての顧客に影響しました。
これは計算ツールにどう対応しますか?
ウェブサイトダウンタイム計算ツールで短いMTTRを入力し、大規模な障害でも迅速な復旧が総損失をどれだけ抑えるかを確認してください。
あなたの番です