Fastly の潜在的バグと集中型 CDN エッジの説明責任

概要

• Fastly によると、2021 年 5 月 12 日に開始されたソフトウェア展開により潜在的なバグが混入した。6 月 8 日、ある顧客が有効な設定変更を行い、そのバグを活性化させる異常な条件が整った。その結果、Fastly のネットワークの 85%がエラーを返す障害が発生した。Fastly は 1 分以内に異常を検知し、49 分以内にネットワークの 95%を正常な状態に復旧させた。
• このインシデントは、BGP 経路漏洩、ピアリング障害、トランジット不足、サイバー攻撃、あるいは無効な顧客操作として公には特定されなかった。独立した観測では、ネットワーク層は正常に見える一方でアプリケーションエラーが発生していた。この区別は重要である。CDN は広範な物理的・キャリアの多様性を持ちながらも、共通のソフトウェア、設定の意味論、展開システム、復旧制御を通じて相関した障害を起こしうる。
• 顧客の結果は、アーキテクチャと運用準備状況に依存した。GOV.UK は常時利用可能なセカンダリ CDN と文書化されたフェイルオーバープロセスを持っていたが、DNS の伝播と縮退モードのトレードオフには依然として時間を要した。GitLab はメインサービスが部分的に依存しているだけだったが、エンジニアが障害発生 CDN を迂回するために使用したかった通常のパイプラインを、外部パッケージ依存が妨げた。
• したがって、説明責任はサービス境界の両側に存在するが、同等ではない。Fastly はプラットフォームコード、テスト、展開の封じ込め、グローバルな障害分離、プロバイダの復旧を管理していた。顧客は依存関係のマッピング、代替配信、オリジンの容量、DNS と証明書の準備、復旧ツール、事業影響許容度を管理していた。取締役会と規制当局は、両方のドメインからテスト済みの証拠を求めるべきであり、高い可用性の割合や 2 番目のベンダとの契約を耐障害性の証明として受け入れるべきではない。

1 つの有効な変更、1 つのグローバルな障害ドメイン

2021 年 6 月 8 日 09:47 UTC、公共 Web の大部分がエラーを返し始めた。ニュースサイト、コマースサービス、開発者プラットフォーム、ストリーミングプロパティ、英国中央政府ウェブサイトが見える被害に含まれた。外部から見ると、この事象は無関係な多くの組織が同時に障害を起こしたように見えた。インフラの観点では、それらは関連していた。それらのサービスへのリクエストは Fastly のコンテンツ配信ネットワークに収束していた。

Fastly の6 月 8 日の障害の概要が中心的な原因説明を提供している。5 月 12 日に開始されたソフトウェア展開がバグをもたらした。それは、特定の条件下で有効な設定変更を顧客が行うまで休眠していた。その後、Fastly のネットワークの 85%がエラーを返したという。監視は発生 1 分後の 09:48 に世界的な異常を特定した。最初の公開ステータス更新は 09:58 に続いた。エンジニアは 10:27 に顧客設定を特定し、復旧は 10:36 に始まり、発生から 49 分以内にネットワークの 95%が正常に動作した。Fastly はインシデントを 12:35 に緩和、12:44 に解決とマークし、その後 17:25 に恒久的なバグ修正の展開を開始した。

アーカイブされたFastly ステータスインシデントは、単純なアップダウンのタイムラインでは見逃される運用上の詳細を追加している。サービスが復旧すると、顧客はより高いオリジン負荷と低いキャッシュヒット率を経験しうる。エッジの復旧は、必ずしも顧客サービス全体の復旧ではなかった。キャッシュはウォームアップする必要があり、通常はエッジで処理されるリクエストが異常な量でオリジンに到達する可能性があり、各顧客自身の依存関係が落ち着く必要があった。プロバイダの復旧は重要なマイルストーンだったが、影響の普遍的な終わりではなかった。

Fastly は謝罪し、インシデントは広範囲かつ深刻だったと述べた。また、貴重な説明責任の声明も行った。トリガーは特定の条件に依存していたが、プロバイダはそれを予期すべきだったというものだ。この一文は、最も簡単だが最も役に立たない説明、つまり顧客が何かを変更したために障害が起きたという説明を否定している。顧客の行動は有効だった。プラットフォームはそれを受け入れた。壊滅的な応答はプロバイダのソフトウェアとその障害の伝播方法に由来した。

公開された説明は意図的に高レベルのままである。影響を受けたサブシステム、正確な設定の組み合わせ、ソフトウェアの欠陥、内部テストのカバレッジ、展開トポロジ、あるいは 1 つの顧客の設定が無関係な顧客サービス全体にエラーを引き起こしたメカニズムは開示されていない。これらの省略は、短い公開レポートでは、特に顧客の機密性とプラットフォームのセキュリティが関係する場合、合理的でありうる。それらはまた、外部からの保証を制限する。一般の人々は観測に対してタイムラインを検証できるが、Fastly の投稿だけから、恒久的な修正がトリガーだけを除去したのか、根本的な欠陥を修復したのか、あるいはこれほどの爆発範囲を許したアーキテクチャを変更したのかを独自に判断することはできない。

そのギャップが結論を形作るべきだ。記録は潜在的なバグ、有効なトリガー、グローバルなエラー動作、迅速な検知、比較的高速な緩和を支持している。バグのあるコードや個々のエンジニアの行動に関する詳細な理論を支持するものではない。説明責任の分析は、制御のレベルにとどまるべきだ。すなわち、テスト設計、設定の分離、展開の安全性、グローバルな障害封じ込め、可観測性、インシデント権限、顧客と取締役に提供される証拠である。

タイムラインは休眠リスクとアクティブな混乱を分ける

多くのユーザーにとってインシデントは 1 時間未満で終わったが、関連する制御ウィンドウはほぼ 4 週間前に始まっていた。欠陥は、目に見える症状を引き起こさずに運用上存在しうる。それが潜在的な障害を困難にし、リリース保証をデプロイ後の最初の数分間の監視以上のものにする理由である。

この一連の流れは、「設定変更が障害を引き起こした」という一般的な言い回しがなぜあまりに大雑把であるかを示している。設定変更は、プログラマビリティを含む価値を持つエッジプラットフォーム上で常に発生している。有効な設定は、通常のリクエストがサーバーの欠陥をトリガーするのと同様に、因果連鎖の最後の刺激となりうる。制御の所有者は、有効な入力を安全にし、処理できない組み合わせを拒否し、あるいは障害をそれを供給したサービスに封じ込める能力を持つ当事者である。

トリガーが無関係だったと主張するのも誤りである。トリガー分析は、再現、検出、ロールバック、将来の保護のために重要である。ポイントは、トリガーの帰属と責任の帰属は異なる質問に答えるということだ。顧客は条件を提供した。Fastly はソフトウェアの振る舞いと共有された本番環境を提供した。Fastly 自身の説明は、その条件は予期されるべきだったと認めている。

休眠期間も同様に重要である。数週間生き延びたリリースは、テストされていない状態に対する証明ではなく、本番での露出を蓄積したにすぎない。設定可能なプラットフォームは組み合わせ問題に直面する。バージョン管理されたソフトウェアは、顧客の VCL、ヘッダー、オリジン、キャッシングルール、シールド、アクセス制御、フィーチャーフラグ、エッジロジックと相互作用する。すべての組み合わせを徹底的にテストすることは不可能かもしれない。それにより、封じ込め、段階的ロールアウト、不変条件チェック、ファジング、代表的な設定コーパス、ランタイム分離、高速な自動ロールバックがより重要になるのであり、重要度が下がるわけではない。

これはアプリケーション障害であり、ルーティング崩壊ではなかった

この障害は、CDN がソフトウェアプラットフォームであると同時に相互接続ビジネスであるため、ピアリングとトランジットの議論に属する。これをピアリングまたはトランジットのインシデントとして書き換えるべきではない。証拠は別の方向を示している。

Kentik の同時期のネットワーク観測では、イベントが 09:49 UTC に始まり、Fastly からのトラフィックが約 75%減少したと測定し、10:39 にトラフィックが戻り始めた。Cisco ThousandEyes のレイヤーごとの分析では、ネットワークパスが機能し続ける中でサービスエラーが観測され、トラフィックが配信プロバイダ間でシフトするにつれて異なる顧客の復旧パターンが説明された。後の ThousandEyes 製品分析は、その区別を直接的に述べている。アプリケーションレイヤーで 503 エラーが発生し、ネットワークレイヤーは正常に見えた。

Fastly 自身のピアリングポリシーは、インターネットサービスプロバイダーやコンテンツネットワークとトラフィックを交換する自律システムとして AS54113 を特定している。そのグローバル POP ドキュメントでは、プレゼンスポイントは密集したインターネットエクスチェンジの場所の近くに配置され、プロバイダの多様性とネットワーク近接性が設計要因に含まれていると説明している。DNS とエニーキャストはユーザーを近くの Fastly キャパシティに誘導する。物理的に局所的な障害では、これらの特性によって、障害のあるリンク、キャリア、施設、または POP を迂回できる。

インシデント前、Fastly は 26 カ国、6 大陸にわたる 68 の POP からなるネットワークを説明しており、トランジット、インターネットエクスチェンジ、クラウドピアリング、プライベート相互接続の組み合わせで接続されていた。そのキャパシティプランニングの説明では、POP と接続の障害をモデル化し、オーバーフロー用の地域的な余裕を維持していると述べていた。これらは意味のある形の回復力である。これらは 1 本のケーブル、1 つのキャリア、1 つの建物、1 つのメトロポリタンサイトへの依存を減らす。

それらは 6 月 8 日の障害モードには対処しなかった。多くの POP が同じ欠陥のあるプラットフォームコードを実行し、共通の設定モデルを受け入れる場合、地理的多様性は欠陥を隔離するのではなく再現する可能性がある。複数のトランジットプロバイダは、確実にエラーを返すエッジノードにユーザーを確実に運ぶことができる。より多くのピアリングセッションは到達可能性とパス選択を改善するが、サービスを提供するアプリケーションが利用不可能なままになる。エニーキャストはリクエストを別の POP に移動できるが、その POP が同じソフトウェアの運命を共有している場合、ユーザーは場所を変えただけで結果は変わらない。

これがピアリングのレンズからの中心的な教訓である。パスの多様性はサービスの多様性ではない。ネットワークオペレーターは長い間、リンクとルートの障害に備えて設計してきた。なぜなら、それらの障害は彼らが運用するレイヤーで可視化されるからだ。クラウドとエッジサービスは、より高次のレイヤーに共通モードを追加する。共有コード、グローバルな設定配布、アイデンティティ、ログ、コントロールプレーン、証明書システム、展開自動化、インシデントツールは、物理的に独立しているように見えるインフラストラクチャを相関づける可能性がある。

したがって、真剣なレジリエンスレビューには、POP やキャリアの数ではなく、障害ドメインマトリックスが必要である。1 つの列には物理設備、電力、ハードウェア、ファイバー、トランジット、ピアリング、ルーティングをリストすべきである。別の列にはソフトウェアバージョン、設定コンパイラ、展開コントローラー、鍵と証明書サービス、ネーミング、可観測性、管理アクセスをリストすべきである。3 つ目の列には、権威 DNS、オリジンホスティング、代替 CDN、WAF ポリシー、オブジェクトストレージ、リリースパイプラインなど、顧客が制御する依存関係をリストすべきである。多様性は、同じイベントがプライマリサービスとその復旧に使用される経路の両方を無効化できない場合にのみ存在する。

分散と集中は共存しうる

この障害は視覚的なパラドックスを生み出した。影響を受けたインフラストラクチャは世界中に分散していたが、単一の潜在的な条件が多くの場所と組織で同時的な障害を引き起こした。分散はリソースがどこにあるかを表す。集中は、障害と広範な被害の間に、どれだけの独立した決定、実装、復旧経路が存在するかを表す。システムは最初の点で高得点を獲得し、2 番目の点で低い得点になる可能性がある。

インシデント後に発表された研究は、その日における Fastly の正確な市場シェアを証明するものではないが、より広範な状況を定量化するのに役立つ。50 カ国におけるサードパーティサービス依存に関する研究では、外部 DNS、CDN、認証局プロバイダーへの広範な依存が明らかになり、国による大きなばらつきと高度に集中したプロバイダーセットが見られた。別の研究「DNS と Web ホスティングプロバイダーの統合の初見」では、その測定において、Tranco トップ 10,000 のインデックスページの約 62%を Cloudflare、Amazon、Akamai、Fastly、Google がまとめてホストしており、多くのサイトの外部リソースの大部分を供給していることがわかった。

これらの測定は方法論的な限界のあるスナップショットである。それらを、Web の 62%が Fastly に依存していたとか、測定されたすべてのホスティング関係が重要だったという主張に変換すべきではない。それらの関連性は構造的なものである。人気のあるサービスはしばしば少数のプロバイダーグループに依存しており、個々のページはそれらのいくつかからのリソースを含む可能性がある。したがって、集中はいくつかのレベルで現れる可能性がある。

• 顧客はルートドキュメントとすべての重要なオブジェクトに 1 つの CDN を使用するかもしれない。
• 顧客は複数の CDN を使用するが、重要なスクリプト、フォント、画像、API、証明書、またはリダイレクト経路を 1 つのプロバイダーに残すかもしれない。
• 名目上独立した 2 つの CDN が、オリジンクラウド、権威 DNS プロバイダー、トランジット経路、設定リポジトリ、アイデンティティシステム、または展開パイプラインを共有するかもしれない。
• 多くの無関係な組織が独立して同じプロバイダーを選択し、単一の顧客が完全に観察できない分野横断的な共通の依存関係を作り出すかもしれない。
• フォールバックは技術的には存在するが、同じイベント中に機能が損なわれる人、資格情報、コード、パッケージリポジトリ、ステータス情報、または通信チャネルを必要とするかもしれない。

市場の集中とアーキテクチャの集中は関連しているが同一ではない。市場には複数の主要サプライヤーが存在する一方で、特定の組織がシングルホームのままである場合もある。逆に、顧客は 2 つのサプライヤーと契約しながら、共有 DNS、共有オリジン、同期された悪い設定、またはテストされていない切り替えを通じて、1 つの論理的な障害ドメインを作り出す可能性がある。取締役会は、ベンダーの数を依存関係分析の代替として使用することに抵抗すべきである。

CDN の社会的リーチも重要である。Fastly は影響を受けた新聞、ショップ、ソフトウェアプロジェクト、政府サービスを所有していなかった。しかし、ユーザーは、ほとんどのユーザーが見ることのない共有された仲介者を通じて、それらの利用不能を経験した。これは委任された運用権限の一形態である。プロバイダーは、各顧客が再現するのに苦労する規模で速度を改善し負荷を吸収できるが、プロバイダーの欠陥は、そうでなければ独立していたはずの障害を同期させることもある。

これによって集中が本質的に無責任になるわけではない。集中した専門知識とインフラストラクチャは、何千もの弱い個別の展開よりも優れたセキュリティ、パフォーマンス、信頼性を生み出すことができる。説明責任の問題は、共通のインフラストラクチャから得られる効率性が、より強力な共通モード制御、透明性のあるインシデント証拠、現実的な離脱またはフォールバックオプションに見合っているかどうかである。集約が重要であればあるほど、プラットフォーム全体の安全性を通常の製品品質の問題として扱うことは説得力を失う。

GOV.UK はバックアップを持っていたが、依然として障害が発生した

Government Digital Service のGOV.UK の公開インシデントレポートは、顧客側の意思決定に関する最も明確な記録の一つである。GOV.UK は発生の 4 分後に影響を検知し、インシデントとコミュニケーションの責任者を設置し、プライマリ CDN を原因として確認し、セカンダリプロバイダーへのフェイルオーバーのための文書化されたプロセスを見つけた。

これは紙だけの冗長性ではなかった。セカンダリ CDN は常時利用可能だったが、通常は本番トラフィックを流していなかった。フェイルオーバーコードは準備されていた。チームはプライマリ CDN が単一障害点になりうることを理解していた。これらの制御により、GOV.UK は、障害中に選択肢を模索する組織よりも実質的に強い立場にあった。

それでも、ユーザーは 1 時間未満の間、GOV.UK の情報とサービスにアクセスできなかった。チームは、セカンダリでは機能が低下するため、検出後 15 分間待ってからフェイルオーバーを決定した。検索や位置情報ベースのサービスなどの動的機能は通常の品質で動作せず、短いプロバイダーの障害中に切り替えが早すぎると、混乱が拡大または悪化する可能性があった。決定後も、DNS の変更が伝播するのに時間がかかった。30 分以内に変更が展開されトラフィックが移動し始めたが、Fastly はすでに復旧しつつあった。その後、チームはよりパフォーマンスの良いプライマリサービスに切り替えた。

これこそが真のレジリエンスの姿である。コスト、状態遷移、判断、遅延を伴う選択肢だ。バックアップは長期の障害のリスクを低減したが、フェイルオーバーを瞬時に、あるいは結果を伴わないものにはしなかった。このインシデントはまた、ユーザーコミュニケーションの依存性を露呈した。Fastly の一般的な 503 ページは GOV.UK のコンテンツ制御の外にあり、有用な公共情報に対する同サービスの基準を下回っていた。

GOV.UK の記録は、いくつかの説明責任のテストを提供する。セカンダリは実際にウォームだったか？ はい。文書化されたプロセスと指名された権限者はいたか？ はい。機能低下は理解されていたか？ はい。切り替えメカニズムはサービスの影響許容度に対して十分に高速だったか？ 観測されたタイムラインは、理論上の保証ではなく、意思決定者が回答するための証拠を提供する。このレポートはまた、取締役会がなぜ単に 2 番目の CDN が契約されているかどうかではなく、意味のあるユーザートラフィックをシフトするための中央値と最悪ケースの時間を尋ねるべきかを示している。

公共サービスにとって、この区別は特に重要である。プレゼンテーションエッジでの障害は、たとえ基盤となる省庁システムが健全であっても、税務ガイダンス、給付情報、健康資料、規制指示、緊急更新をアクセス不能にする可能性がある。エッジは、公共の入口点である場合、装飾ではない。ビジネス影響マッピングは、配信の喪失をユーザーが実際に到達できるサービスの喪失として扱うべきである。

GitLab は復旧経路の内部で依存関係を発見した

GitLab の公開本番インシデント記録は、異なるアーキテクチャと異なる障害を示している。Fastly は GitLab.com のアセットを配信していたため、ブラウザにキャッシュされた JavaScript や画像がないユーザーにとって、メインサイトは大幅に機能低下した。Fastly が最初のエントリーポイントであった About.GitLab.com は完全に利用不能だった。API、Git、Registry、Pages の機能は継続し、サービス経路を分離することの価値を示した。

10:18 UTC、GitLab のエンジニアはアセットに使用する CDN を置き換えるためのマージリクエストを準備した。彼らは通常のパイプラインを通じてそれを適用できなかった。なぜなら、そのパイプライン内のイメージが、同じく Fastly の障害の影響を受けた外部リポジトリからパッケージをインストールしようとしたためである。意図した復旧メカニズムは、変更対象の CDN 設定ではない依存関係を通じて、同じ外部イベントを引き継いだ。

これは推移的な集中の簡潔な例である。アーキテクチャ図では、アプリケーション、設定パイプライン、コンテナイメージ、パッケージインデックス、CDN は異なるボックスとして現れうる。運用上、復旧アクションはそれを実行するために必要なすべてのボックスに依存する。もし 1 つのビルドステップが利用不能な外部サービスに到達するなら、パイプラインは、別の依存関係を除去するためにまさに必要なその瞬間に利用不能になる。

GitLab は、Fastly が復旧する間に、ステージングで、次にカナリアスライスで手動バイパスをテストした。その是正措置には、重要コンポーネントのイミュータブルイメージ、変更を手動で適用するためのランブック、より高速な CDN 復旧のためのバックエンドバケットとロードバランサー、冗長 CDN の検討、外部要因によって通常のワークフローが損なわれる場合の消防訓練が含まれた。これらのアクションは、元のベンダー障害だけでなく、復旧能力に対処しているため価値がある。

GitLab への影響が部分的だったという性質は、バイナリな依存関係の登録に対しても警告を発する。「Fastly: サードパーティ」とマークしてもほとんど意味がない。有用なマップは、どのホスト名、パス、オブジェクト、ユーザージャーニーがプロバイダーを必要とするか、ブラウザがキャッシュされたアセットを使用できるか、API が到達可能なままか、TLS がどこで終端するか、リダイレクトがどのように機能するか、スタッフが障害のあるパスに接触せずにバイパスを展開できるかを特定する。サービスの分解は高価値な機能を保持できるが、それは影響評価が、視覚的またはクライアントサイドのコンポーネントが欠けているときにユーザーが何を達成できるかを反映する場合に限られる。

GitLab と GOV.UK は異なる結果に至った。なぜなら、レジリエンスは実装に固有のものだからだ。プロバイダーのインシデントは共通だった。顧客の爆発半径はそうではなかった。これが、顧客の説明責任は「ベンダーが落ちた」と言って片付けられず、プロバイダーの説明責任は「一部の顧客が 2 番目の CDN を持っていなかった」と言って薄められない理由である。Fastly は共有された障害の防止と復旧を所有していた。各顧客は自らの依存関係の形と準備状況を所有していた。

復旧はキャッシュ効率をオリジンへの負荷に変えうる

CDN は通常、リクエスト負荷の多くからオリジンを保護する。GOV.UK は、リクエストの約 93%がキャッシュから提供されたと述べた。Fastly のシールドのドキュメントは、通常のパターンを説明している。エッジ POP がキャッシュされたオブジェクトを提供し、指定されたシールドがオリジンに到達する前にキャッシュミスを統合できる。このアーキテクチャはパフォーマンスを向上させ、オリジンへのトラフィックを大幅に削減できる。

復旧中、その効率は逆転しうる。キャッシュがコールドだったり、ヒット率が低下すると、より多くのエッジリクエストが上流に流れる。顧客が CDN を完全にバイパスすると、オリジンは、通常のキャパシティプランニングがエッジでの吸収を前提としていたためにサイズ設計されていなかったトラフィックを受信する可能性がある。エラーが繰り返された後に多くのユーザーがリトライすると、サージは通常の需要よりも大きくなりうる。したがって、Fastly のオリジン負荷増加に関するステータス警告は、脚注ではなかった。それは復旧によって生じる二次的なリスクを特定した。

マルチ CDN 設計はこれを考慮しなければならない。ウォームなオブジェクトを持たないセカンダリプロバイダーは、即座に同じオリジンから取得するかもしれない。復旧中の 2 つのプロバイダーは重複したキャッシュミスを生成しうる。シールド設定は負荷を軽減するが、別の重要な集中点を作り出す。レート制限、認証、許可リスト、WAF ルール、オリジン接続制限はベンダー間で異なる可能性がある。ログは、インシデント対応者が一貫したビューを必要とするまさにその時に、異なるフォーマットや異なる速度で到着するかもしれない。

オリジンへの直接フォールバックは自動的により安全というわけではない。オリジンアドレスを公開すると、攻撃面が変わる可能性がある。証明書とホストルーティングが正しくなければならない。オリジンは、通常はエッジで提供されるサービスなしで、需要を吸収し自らを防御できなければならない。静的ページを復元するが、ログイン、チェックアウト、検索、パーソナライゼーション、不正利用制御を無効にするバイパスは、正しい縮退モードかもしれないが、そのモードには明示的なビジネス承認とユーザーコミュニケーションが必要である。

実践的なテストはトラフィックの演習である。組織は危機を伴わずに本番トラフィックの制限された割合を代替経路に振り向けられるか？ 代替経路は同じ重要なコンテンツとセキュリティヘッダーを返すか？ 予想される負荷とリトライサージを処理できるか？ キャッシュの無効化と緊急公開は利用可能か？ エンジニアはプライマリベンダーの障害ドメイン外の資格情報、デバイス、リポジトリ、通信システムを使用してそれを操作できるか？ 復旧手順は第二のインシデントを生み出すことなく可逆的か？

サービスレベルアグリーメントはこれらの質問に答えない。クレジットは事後に狭い契約上の尺度を補償する。それらは失われたトランザクション、遅れた公的通知、あるいは開発者のワークフローを回復しない。フォールバックを行使する代わりに SLA に依存する顧客は、一部の財務上の結果を移転したのであり、継続性のための運用責任を移転したのではない。

マルチ CDN は調達のチェックボックスではなく、運用モデルである

ThousandEyes は、複数の配信プロバイダーを持つ顧客で成功の度合いが異なることを観察した。ルートトラフィックを Fastly から移動させたが、重要なページオブジェクトをそこからロードし続けたところもあった。他は、すべての Fastly 依存関係を取り除くのにより長い時間がかかった。この振る舞いは、設計の罠を示している。最初のリクエストでのトラフィック制御だけでは、後でページが障害のあるプロバイダーからのスクリプト、スタイル、API、画像、フォント、リダイレクト、認証アセットを必要とする場合には不十分である。

実行可能なマルチ CDN 設計は、少なくとも 8 つの厳しい特性を持つ。

第一に、設定は移植可能でなければならない。キャッシュキー、有効期限ルール、古いコンテンツの動作、オリジン選択、リダイレクト、エッジコード、WAF ポリシー、ボット制御、ヘッダー操作はベンダーによって異なる。名目上同等な設定でも、異常なリクエストの下では異なる動作をしうる。移植性には、テストされた意味的な等価性が必要であり、リポジトリで待機している翻訳されたファイルではない。

第二に、命名はタイムリーな変更をサポートしなければならない。低い DNS TTL 値は一部の移行を短縮できるが、リゾルバーとクライアントはすべてが理想的な瞬間にリフレッシュするわけではない。Apex レコード、CNAME チェーン、エニーキャストアドレス、証明書検証は制約を課す。ステアリングレイヤー自体が集中した依存関係になりうる。組織は実際のフェイルオーバー演習から測定された伝播データを必要とする。

第三に、オリジンは両方の配信プロバイダーを受け入れなければならない。ネットワーク許可リスト、相互 TLS、署名付きリクエスト、ヘルスチェック、接続プール、レート制限は、緊急事態の前に機能している必要がある。オリジンに対して認証できない代替 CDN は、在庫であってレジリエンスではない。

第四に、重要なコンテンツは完全でなければならない。ルートページ、重要なオブジェクト、エラーページ、リダイレクト、API、ユーザーコミュニケーションは独立した配信を必要とする。画像のみを提供する第 2 のベンダーはパフォーマンスを向上させるかもしれないが、可用性は向上させない。依存関係のマッピングは、ベンダー契約ではなくユーザージャーニーに従うべきである。

第五に、代替経路にはキャパシティと商業的許可が必要である。休眠状態のプロバイダーは、突然のグローバルなシフトのためにキャパシティを予約していないかもしれない。コミットされたトラフィックレベル、バースト価格、DDoS 想定、サポート応答は事前に合意されるべきである。集中は、最初の実際の負荷で失敗するセカンダリを作成することによっては解決できない。

第六に、テレメトリは生き残らなければならない。外部プローブは異なるアクセスネットワークと地域を通してテストすべきである。両方のプロバイダーからのログは、独立した分析パスに到達しなければならない。ステータスページとページングツールは、それらが報告するサービスの後ろに排他的に配置されるべきではない。顧客は、DNS、ルーティング、TLS、エッジアプリケーション、オリジン、オブジェクトレベルの障害を迅速に区別する必要がある。

第七に、権限は明示的でなければならない。GOV.UK のチームにはインシデントリードがおり、機能低下したフォールバックが好ましいと判断するための閾値があった。そのような意思決定設計がなければ、対応者はトラフィックをシフトし、機能低下を受け入れ、またはより高いコストを負担することを許可されているかどうかを議論して障害対応時間を失う可能性がある。

第八に、フェイルバックはフェイルオーバーと同じ規律を必要とする。キャッシュ、DNS 応答、セッション、証明書、オリジン負荷は、トラフィックが戻る間不安定になりうる。Fastly の最初の復旧と最終的なインシデント解決は別々のマイルストーンだった。顧客は、ベンダーのステータスカラーを自動的に反映するのではなく、成功したユーザージャーニーと安定したキャパシティに基づいて、自身の復旧ポイントを定義すべきである。

これらの要件は、マルチ CDN がすべてのサイトにとって経済的でなくとも、重要なサービスにとっては正当化されうる理由を説明している。小規模な組織は、重複するデリバリーエンジニアリングに資金を提供するよりも、短時間の障害を合理的に受け入れるかもしれない。説明責任は、すべての顧客に同一のアーキテクチャを要求するものではない。明示的な影響許容度、理解された依存関係、バランスの取れた復旧の選択、そして通常のベンダー冗長性がプラットフォーム全体のソフトウェア障害をカバーするという誤った主張がないことを要求する。

Fastly の応答は迅速だったが、公的保証は限定的だった

応答のタイムライン上、Fastly はいくつかの点で良好に機能した。監視は 1 分以内に世界的な問題を検出した。エンジニアは 40 分以内にトリガーとなった設定を特定した。それを無効化することで、49 分以内にネットワークの 95%が回復した。恒久的な修正は同日遅くに展開が開始された。同社は、顧客の変更は有効であり、その条件を予期すべきだったと認めたと伝えた。

これらの事実は過小評価されるべきではない。迅速な検出と復旧は、公衆への被害を実質的に軽減した。分散システムは障害を起こすものであり、インシデントの説明責任は、制御の失敗と同様に制御のパフォーマンスも認識すべきである。深刻な欠陥を露呈しながらも 1 時間以内に封じ込めた組織は、自身のプラットフォーム状態を認識も回復もできない組織とは異なるリスクを示す。

それでも、公開された事後分析は、防止のケースを未解決のままにしている。Fastly は、品質保証とテストがなぜバグを検出しなかったのかを調査し、修復時間を改善する方法を評価し、WebAssembly と Compute@Edge を通じてより大きな分離を追求すると述べている。しかし、結果として得られた調査、アクションの所有者、期限、完了の証拠、あるいは独立した評価は公開されていない。なぜ 1 つの設定が無関係なサービスに影響を与えたのか、展開が POP ごとや顧客コホートごとに行われたのか、あるいは現在、同じクラスの再発を防ぐどのようなガードがあるのかについての公的な説明はない。

これは、Fastly が内部的にそれらのアクションを実行しなかったことを立証するものではない。大規模プロバイダーはしばしば、守秘義務の条件の下で顧客に非公開のレポートを提供する。それは公共の信頼に境界を設ける。部外者は、観測された復旧と表明されたコミットメントを評価できるが、短い投稿を修復完了の証拠として扱うことはできない。

Fastly の2021 年 6 月の四半期報告書は、このイベントを正式なリスク開示に変換した。提出書類は、人為的ミスによって引き起こされた未発見のソフトウェアバグが、有効な顧客設定によってトリガーされたと説明した。顧客がトラフィックを削減または削除し、サービスレベルの請求を行ったと述べた。また、契約帯域幅へのより広範な依存と、プロバイダーの停止、紛争、ネットワークプロバイダーの障害、自然イベント、トラフィック制限、または規制によってその容量が利用できなくなる可能性についても開示した。

「人為的ミスによって引き起こされた」という表現は、同社の技術的な流れよりも情報量が少ない。すべてのソフトウェアは人によって書かれ、操作される。ガバナンスの問題は、どのシステムが通常の人間の行動によって広範で相関した障害を生み出すことを許したかである。個人のエラーという表現は、まさに人とコードが誤りやすいからこそ存在する設計と保証のメカニズムを曖昧にする可能性がある。

経済的記録は信頼性をガバナンス問題にした

Fastly の第 2 四半期の株主向けレターは、この障害がほぼすべての顧客に影響したと述べた。トラフィック量が減少し、顧客クレジットが発行され、トップ 10 の顧客を含む数社のトラフィックがまだ戻っておらず、いくつかの顧客が新規プロジェクトを遅らせた。Fastly のモデルが使用量ベースだったため、トラフィックの減少は直接的に収益圧力につながった。同社は、この障害とトラフィックの遅れが第 3 四半期および通年の見通しに影響すると述べた。

同じレターは、第 2 四半期の収益を 8500 万ドルと報告し、通年の収益ガイダンスを 3 億 4000 万〜3 億 5000 万ドルとし、見通しは障害、トラフィックの増加タイミング、予想される更新を反映していると述べた。これらの要因を公表数値からきれいに分離することはできないため、期待の変化全体を 1 時間のダウンタイムに帰するのは不健全である。防御可能な結論はより狭い。この障害は、技術的なインシデントを超えて経済的影響を拡大したサービス・クレジットと顧客のトラフィック決定を生み出した。

Fastly の2021 年年次報告書は後に、影響を受けた顧客のトラフィックは戻ったが、すべてのトラフィックが障害前の水準に戻ったわけではないと述べた。また、2021 年 1 月に、ソフトウェアアップデートの未発見のバグによって引き起こされたプラットフォーム中断が、サービスレベルの請求につながったことも開示した。2 つのインシデントは同じ技術的原因を持つとは説明されていない。しかし、それらの共存は、ソフトウェアリリースのレジリエンスを、一度限りの運用上の異常ではなく、取締役会の持続的な注意の合理的な主題にする。

同社の2021 年委任状勧誘書類は、6 月の株主総会前に提出され、取締役会はリスクの情報に基づく監視と戦略的リスクエクスポージャーの監視に責任を負い、経営陣は日常的に重要なリスクを管理すると述べた。情報セキュリティリスクの監視を監査委員会に割り当てた。この提出書類は、障害前に取締役会がプラットフォーム全体の可用性リスクについて何を知っていたか、あるいは後で何をレビューしたかを明らかにしていない。それはガバナンスアーキテクチャを確立するものであり、取締役会の実際の調査の質ではない。

製品が共有運用インフラであるプロバイダーにとって、可用性は、監査委員会の表明された権限が情報セキュリティを強調している場合でも、戦略的監視に属する。1 時間の欠陥は、顧客のルーティング決定、サービスクレジットエクスポージャー、収益期待、信頼を変化させた。それはエンジニアリング制御から企業価値への直接の架け橋である。取締役はエッジソフトウェアをデバッグする必要はないが、経営陣がソフトウェアリリースを制限し、テナント構成を分離し、安全に復旧し、修復を検証できるという証拠を必要とする。

説明責任は共有されるが、曖昧にはならない

クラウドインシデントの後、責任が広く拡散し、どの当事者も明確に責任を負わなくなるかのように、共有責任がしばしば持ち出される。より良い方法は、制御能力によって責任を割り当てることである。

Fastly は、欠陥をもたらしたコード展開を制御していた。有効な設定を受け入れ処理したパーサー、コンパイラ、ランタイム、またはその他のプラットフォームメカニズムを制御していた。顧客スコープの変更が無関係な顧客に影響を与えるかどうか、ソフトウェアがどのように POP に到達するか、監視が何を見ることができるか、プラットフォームがどれだけ迅速にトリガーを無効化し修正を展開できるかを制御していた。これらは、顧客が検査も操作もできなかったため、プロバイダーの責任である。

顧客は、特定のユーザージャーニーを Fastly の背後に置く決定、オリジンの容量とセキュリティ、1 つまたは複数の CDN の使用、DNS と証明書の配置、静的フォールバックコンテンツ、代替経路、復旧手順の準備を制御していた。また、重要な内部展開ツールやコミュニケーションツールが同じ依存関係を共有するかどうかも制御していた。これらは、Fastly が各サービスの許容可能な障害時間を決定したり、すべての顧客のフォールバックに資金を提供したりできなかったため、顧客の責任である。

ピアリングパートナーとトランジットプロバイダーは Fastly との間のトラフィックを運んだが、公的記録はそれらを原因として特定していない。それらの多様性は、アプリケーションが故障している間もネットワークを到達可能に保つのに役立ったかもしれない。「インターネット」や BGP に非難を割り当てることは、レイヤーの証拠を消し去ることになる。

トリガーとなった設定を提供した顧客は、自らの有効なサービス変更を制御していた。公的記録はその顧客を特定しておらず、設定を開示しておらず、不正行為を示唆していない。マルチテナントプラットフォームは、有効なテナントアクションが発生することを前提とすべきである。トリガーであるという裏付けのない事実を超えて、その顧客に責任を割り当てるべきではない。

両側の取締役会は、リスク選好と証拠要求を制御していた。Fastly の取締役会は、プラットフォームリリースが独立した爆発半径制御を持つかどうか、テナントアクションがサービス境界を越えうるかどうかを尋ねることができた。顧客の取締役会は、どの重要なサービスがシングルホームであるか、切り替え時間が事業の影響許容度内に収まるかどうかを尋ねることができた。どちらの取締役会も、自らの質問を相手に委託することはできない。

規制当局は、共通のプロバイダーが重要セクターを支える場合に、より狭いが重要な役割を担う。金融安定理事会のサードパーティリスクツールキットは、企業レベルのサードパーティ管理と、当局がシステム上の依存関係を特定する必要性とを区別している。イングランド銀行のアウトソーシングとサードパーティリスクに関する SS2/21は、規制対象企業に対して集中と運用レジリエンスの管理を期待している。EU のデジタルオペレーショナルレジリエンス法は後に、対象となる金融エンティティに対する ICT サードパーティ集中と管理機関の責任への注目を正式化した。

これらの枠組みは、Fastly に対する遡及的な認定をもたらすものではなく、すべての CDN 顧客に同一に適用されるものでもない。それらは政策の方向性を示している。重要なサービスのユーザーは自らの依存関係に対して責任を負い続ける一方で、監督当局は、同時に多くの企業に影響を及ぼしうる障害を持つ共通のプロバイダーに対する可視性も必要としている。企業レベルのフェイルオーバーとシステムレベルの集中は、異なる証拠を必要とする別個の問題である。

潜在的なエッジ障害後に取締役会が要求すべきこと

取締役会へのパッケージは、フリートサイズではなく、障害ドメインマップから始めるべきである。POP の数、キャパシティ、ピアリングの広がりは有用だが、取締役はどの制御がグローバルで、どれが独立して分離されているかを見る必要がある。マップは、ソフトウェアバージョン、設定配布、テナント境界、コントロールプレーン、DNS、証明書、ログ、ステータス通信、オリジンシールド、プロバイダーの復旧ツールを結びつけるべきである。

プロバイダーにとって、証拠は具体的な質問に答えるべきである：

• どのクラスの有効な入力が欠陥を作動させたのか、そしてどの不変条件がそれを拒否または封じ込めるべきだったのか？
• なぜ本番前テスト、本番カナリア、そして 5 月 12 日の展開期間はそれを明らかにできなかったのか？
• 1 つの設定または 1 つのリリースコホートが、自動停止がかかるまでに、何人の顧客、POP、リクエストに影響を与えうるのか？
• カナリアグループはコード、コントロールプレーン、地理、トラフィックにおいて独立しているのか、それともテスト対象のメカニズムを共有しているのか？
• プラットフォームは、障害のあるサービス経路に依存することなく、トリガーとなったテナント設定を無効化できるか？
• ランタイム分離は、不正な状態やソフトウェア例外を、プロセスやフリート全体の障害ではなく、テナントスコープのエラーに変えるか？
• 恒久的な修正とより広範なクラス制御が、意図された場所すべてに展開されていることを示す証拠は何か？
• ノードの健全性だけでなく、顧客体験、オリジン負荷、キャッシュウォームアップ、残留エラーを記述する復旧メトリクスはどれか？

顧客にとって、パッケージは重要なユーザージャーニーと、それぞれが必要とする正確な外部リソースを示すべきである。所有者、影響許容度、フォールバックモード、決定閾値、最後の演習日を明記すべきである。検出、決定、DNS またはステアリングの変更、意味のあるトラフィックの提供、安全な復帰までの時間を別々に測定すべきである。影響許容度後に完了するフェイルオーバーは、まだ効果的な制御ではなく、学習メカニズムである。

NIST の緊急時計画ガイドは、ビジネス影響分析、予防的制御、復旧戦略、計画、テスト、トレーニング、演習、メンテナンスという永続的なシーケンスを提供する。その連邦政府向けの範囲を普遍的な法的義務と誤解すべきではないが、その運用原則は広く通用する。復旧計画は演習とメンテナンスを通じて信頼できるものになる。

NIST のサプライチェーンリスクガイダンスも同様に、取得した技術がどのように開発、統合、展開されるかについての可視性の低下を強調している。CDN 顧客はプロバイダーの内部すべてを検査することはできない。それでも、インシデント条件、重要な依存関係の開示、通知クロック、復旧証拠、重要性に比例した監査権、設定の移植性、データエクスポート、テスト済みの離脱のサポートを要求することはできる。

メトリクスは安易なグリーンシグナルを避けるべきである。「2 つの CDN が契約されている」は弱い。「前回の抜き打ち演習で、8 分以内に代替経路を通じて重要なジャーニーの 90%が提供された」はより強い。「グローバルネットワークが復旧した」は、オリジンが過負荷の顧客にとっては弱い。「通常のエラーバジェットで成功したトランザクションが 30 分間安定している」はより強い。「バグ修正」は、回帰クラス、ロールアウト証拠、クロージャオーナーなしでは弱い。

永続的な教訓は独立した復旧に関するものである

Fastly の 6 月 8 日の障害は、重大で、目に見え、比較的短時間だった。この組み合わせは誤った結論を助長しうる。一つは自己満足である。ほとんどのサービスが 49 分以内に復旧したため、この出来事は印象的な復旧物語になる。もう一つは運命論である。主要プロバイダーが故障しうるため、障害は不可避であり、それ以上の説明責任は役に立たないというものだ。証拠はどちらも支持しない。

迅速な復旧は称賛に値する。Fastly がトリガー条件を予期すべきだったと認めたことも同様である。しかし、潜在的な欠陥は 5 月 12 日から生き残り、1 つの有効な顧客変更がネットワークの大部分に影響を与え、公開された修復記録は薄いままだった。防止、封じ込め、対応、保証は異なる制御である。対応の強力なパフォーマンスは、他の 3 つを完了させない。

顧客にとって、このインシデントは、オリジン、2 番目の契約、または DNS 手順が自動的に独立した復旧経路ではないことを示した。GOV.UK の準備されたセカンダリは、依然として意図的な待機、機能低下したサービス、DNS 伝播を伴った。GitLab の通常の変更経路は、同じイベントの影響を受けた外部パッケージ依存に触れた。これらは緊急時計画に反対する議論ではない。それらは、すべての依存関係を通じて行使されて初めて、緊急時対応が現実のものとなるという証拠である。

ネットワークリスクにとって、この障害は、ピアリングとトランジットの分析がスタックを登らなければならない理由を示した。Fastly の地理的に分散し、多重接続されたエッジは、多くの物理的リスクを低減した。それは、共有ソフトウェアがそのエッジを 1 つの論理的な障害ドメインに変えるのを防がなかった。並外れたパフォーマンスを提供するのと同じ相互接続が、共通のエラーを同等のリーチで配布しうる。

したがって、最終的な説明責任の判断は具体的である。Fastly は、プロバイダー側の欠陥、その伝播、および障害クラスが封じ込められたという証拠に対して責任を負っていた。顧客は、Fastly が故障したときに何が利用不能になったかを知り、その害に見合ったフォールバックを選択することに対して責任を負っていた。取締役は、プロバイダーと顧客の保証が実際に実行可能な復旧境界で合致するかどうかをテストすることに対して責任を負っていた。重要セクターが関与する場合、規制当局は、個々の契約を超えて、単一の企業が見ることのできない共通の依存関係に目を向ける責任を負っていた。

次のエッジ障害後に関連する質問は、ネットワークが分散しているかどうかではない。それは、ソフトウェアの運命、運用権限、復旧能力も独立して分散しているかどうかである。