Fastly世界障害（2021）— 潜伏バグと1顧客の設定

何が起きたか（日時・影響範囲）

2021年6月8日 09:47 UTC、CDN大手Fastlyのエッジネットワークが世界規模で異常を起こし、公式総括「Summary of June 8 outage」によればネットワークの約85%がエラーを返しました。世界中で HTTP 503 が観測され、報道では英政府の gov.uk、Reddit、Amazon、主要報道機関など多数のサイトが一斉に閲覧不能となりました。原因は攻撃ではなく、5月12日のソフトウェアデプロイで持ち込まれたバグが、ある1顧客の正当（valid）な設定変更をきっかけに発火したものでした。

タイムライン

公式ブログが公表した時系列（すべてUTC）です。

公式総括は「障害を1分以内に検知し、原因を特定・隔離して当該設定を無効化した。49分以内にネットワークの95%が平常どおり稼働した」と述べています。

根本原因の技術解説

公式の説明では、5月12日に開始したデプロイに「特定の顧客設定が特定の状況下で有効になった場合にのみ発火しうるバグ」が含まれていました。6月8日の朝（UTC）、ある顧客がその条件を満たす正当な設定変更をプッシュし、これがバグを発火させてネットワークの85%がエラーを返しました。該当コンポーネントの詳細や顧客名は公表されていません。

技術的な焦点は、1顧客の変更が全世界へ波及した構造です。Fastlyのエッジクラウドは、顧客の配信設定を数秒〜十数秒で全キャッシュノードへ反映できる即時性を特徴とします。平常時は利点であるこの伝播の速さは、設定そのものが「バグを発火させる入力」になった瞬間、故障の拡散速度に変わります。さらにCDNはマルチテナントの共有データプレーンであり、1テナントの設定が引き起こす異常は、同じノードを通る他テナントの配信も巻き込みます。これが共有プラットフォームのブラスト半径です。

注目すべきは、復旧の決め手が根本修正ではなく「引き金となった設定の無効化」だった点です。修正版の展開（17:25開始）を待たず、トリガー入力の遮断だけで49分・95%復旧を達成しています。

なぜ防げなかったか

横にスクロール

第一に、発火条件が「特定の顧客設定 × 特定の状況」という組み合わせだったことです。ソフトウェアは展開後27日間正常に動作し、リリース前後の検証を通過していました。Fastlyも「なぜ品質保証とテストの過程でバグを検出できなかったのか」を調査すると表明しています。一般化すれば、テストがコードへの入力を網羅しても、全顧客の設定項目の直積という巨大な組み合わせ空間までは覆えない、という問題です。

第二に、デプロイと発火の時間的分離です。カナリアリリースは「展開直後に異常が出る」ことを前提とした防御であり、トリガーが27日後に外部から届く潜伏バグは観測窓をすり抜けます。

第三に、引き金を引いた顧客に落ち度がないことです。変更は仕様上正当であり、不正入力へのバリデーションでは捉えられません。

教訓（原則として一般化）

• 設定を入力とみなす: 顧客設定やフラグはユーザー入力と同じ故障面です。スキーマ検証に加え、設定のファジングやプロパティベーステストで「正当だが想定外」の組み合わせを機械的に探索します。
• 設定変更にも段階適用: コードだけでなく設定の伝播にもカナリア（少数ノード→全体）を挟み、即時性とのトレードオフを設計判断として明示します。
• 顧客単位の隔離: プロセス分離やセル型アーキテクチャで、1テナントの異常が共有データプレーン全体へ波及しない構造にし、ブラスト半径を限定します。
• 切り戻しを原因特定より先に: 「直前に何が変わったか」の自動相関と、疑わしい変更を安全に無効化する手段が49分復旧の本質です。検知1分は監視の、49分は運用設計の成果でした。

CDNや配信の原理はネットワーク、カナリアや段階的ロールアウトの設計はDevOpsの各トピックも参照してください。