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

要約

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

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

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

Fastly の6月8日の停止に関する概要は、中心的な因果関係を説明している。5月12日に開始されたソフトウェアデプロイメントがバグを導入した。それは、顧客が特定の条件下で有効な構成変更をプッシュするまで休眠状態のままであった。Fastly によると、ネットワークの85%がエラーを返すようになった。モニタリングはグローバルな障害を09:48、発生から1分後に特定した。最初の公開ステータス更新は09:58に行われた。エンジニアは10:27に顧客構成を特定し、10:36に復旧が開始され、発生から49分以内にネットワークの95%が正常動作に戻った。Fastly は12:35にインシデントの軽減を宣言し、12:44に解決とし、17:25に恒久的なバグ修正のデプロイを開始した。

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

Fastly は謝罪し、インシデントが広範かつ深刻であったと述べた。また、貴重な説明責任についての声明も行った。トリガーは特定の条件に依存していたが、プロバイダーはそれを予期すべきだったというものだ。この言葉は、顧客が何かを変更したために停止が発生したという最も簡単だが最も有用ではない説明を退けている。顧客のアクションは有効であった。プラットフォームはそれを受け入れた。壊滅的な応答は、プロバイダーのソフトウェアとその障害の伝播の仕方から生じたのだ。

公開された説明は意図的に高いレベルのままである。影響を受けたサブシステム、正確な構成の組み合わせ、ソフトウェアの欠陥、内部テストカバレッジ、デプロイメントトポロジー、あるいは一つの顧客の構成が無関係な顧客のサービス全体にエラーを引き起こしたメカニズムについては開示されていない。こうした省略は、特に顧客の機密性やプラットフォームのセキュリティが関係する場合、短い公開レポートでは妥当であり得る。しかし、それらは外部からの保証を制限する。一般の人は観測結果と照らし合わせてタイムラインを検証できるが、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 と接続性の障害をモデル化し、オーバーフローのための地域別の余力を維持していると述べていた。これらは意味のあるレジリエンスの形態である。これらは一本のケーブル、一つのキャリア、一つの建物、一つの大都市拠点への依存を減らす。

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

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

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

分散と集中は共存し得る

この停止は視覚的なパラドックスを生み出した。影響を受けたインフラストラクチャは世界中に分散していたが、単一の潜在的な条件が多くの場所や組織にわたって同時に障害を発生させた。分散はリソースがどこにあるかを示し、集中は一つの障害と広範な被害との間にどれだけの独立した決定、実装、復旧経路が存在するかを示す。システムは前者で高いスコアを得ながら、後者では低いスコアになり得る。

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

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

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

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

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 の記録は、いくつかの説明責任テストを提供している。セカンダリは実際にウォームだったのか？ はい。文書化されたプロセスと指名された権限者はいたか？ はい。縮退は理解されていたか？ はい。切り替えメカニズムはサービスが許容する影響時間に対して十分に高速だったか？ 観測されたタイムラインは、意思決定者に回答のための証拠を提供しており、理論上の保証ではない。また、このレポートは、取締役会が単にセカンド CDN が契約されているかどうかではなく、有意義なユーザートラフィックを移行するための中央値および最悪ケースの時間を問うべき理由を示している。

公共サービスにとって、この区別は特に重要である。プレゼンテーションエッジでの停止は、基盤となる部門システムが健全であっても、税務ガイダンス、給付情報、健康関連資料、規制指示、緊急時の最新情報にアクセス不能にし得る。エッジは、公共のエントリーポイントである場合、装飾ではない。事業継続性のマッピングは、配信の喪失をユーザーが実際に到達できるサービスの喪失として扱うべきである。

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

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

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

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

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

GitLab の影響が部分的だったことは、二者択一的な依存関係台帳に対しても警告を発している。「Fastly：サードパーティ」とマークするだけではほとんど意味がない。有用なマップは、どのホスト名、パス、オブジェクト、ユーザージャーニーがプロバイダーを必要としているか、ブラウザがキャッシュされたアセットを使用できるか、API が到達可能なままか、TLS の終端場所、リダイレクトの仕組み、スタッフが障害パスに接触することなくバイパスをデプロイできるかどうかを特定する。サービス分解は高価値機能を維持できるが、それは影響評価が、ビジュアルやクライアントサイドのコンポーネントが欠落したときにユーザーが何を達成できるかを反映している場合に限る。

GitLab と GOV.UK が異なる結果に至ったのは、レジリエンスが実装に固有のものだからである。プロバイダーのインシデントは共通だったが、顧客の影響範囲はそうではなかった。だからこそ、ベンダーが落ちたと言って顧客の説明責任を免れることはできず、一部の顧客がセカンド CDN を欠いていたと言ってプロバイダーの説明責任を希釈することもできない。Fastly は共有障害の予防と復旧を所有し、各顧客は自らの依存の形状と準備態勢を所有していた。

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

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

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

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

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

実践的なテストはトラフィック演習である。組織は危機を招くことなく、本番トラフィックの一定割合を代替パスに振り向けられるか？ 代替パスは同じ本質的なコンテンツとセキュリティヘッダーを返すか？ 期待される負荷とリトライ急増を処理できるか？ キャッシュ無効化と緊急パブリッシングは利用可能か？ エンジニアは一次ベンダーの故障ドメイン外の認証情報、デバイス、リポジトリ、コミュニケーションシステムを用いて操作できるか？ 復旧ステップは二次インシデントを発生させることなく可逆か？

サービスレベル契約はこれらの問いに答えない。クレジットは事後的に狭い契約上の基準を補償する。それらは、逃したトランザクション、遅延した公告、あるいは開発者のワークフローを復元しない。SLA に依存してフォールバックを演習しない顧客は、一部の財務的影響を移転したのであって、継続性の運用責任を移転したのではない。

マルチ CDN は調達のチェックボックスではなく、オペレーティングモデルである

ThousandEyes は、複数の配信プロバイダーを持つ顧客の成功率が異なることを観測した。ルートトラフィックを Fastly から移したものの、重要なページオブジェクトを引き続きそこからロードする顧客もいた。他の顧客は、すべての Fastly 依存関係を取り除くのにより長い時間がかかった。この挙動は設計上の罠を示している。最初のリクエストでのトラフィック誘導だけでは不十分であり、その後のページでスクリプト、スタイル、API、画像、フォント、リダイレクト、あるいは認証アセットを機能不全のプロバイダーから要求する可能性がある。

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

第一に、構成はポータブルでなければならない。キャッシュキー、TTL ルール、古いコンテンツの動作、オリジン選択、リダイレクト、エッジコード、WAF ポリシー、ボット制御、ヘッダー操作はベンダーによって異なる。名目上同等の構成でも、異常なリクエスト下では異なる振る舞いをすることがある。ポータビリティには、テスト済みの意味論的な同等性が必要であり、リポジトリで待機している翻訳済みのファイルではない。

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

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

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

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

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

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

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

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

Fastly の応答は迅速だったが、広く一般に保証するものではなかった

応答のタイムラインにおいて、Fastly はいくつかの点で優れたパフォーマンスを示した。モニタリングはグローバルな問題を1分以内に検知した。エンジニアは40分以内にトリガーとなった構成を特定した。それを無効化することで、49分以内にネットワークの95%が復旧した。恒久修正は同日遅くにデプロイが開始された。同社は顧客の変更が有効であったこと、そしてその条件を予期すべきであったことを認めた。

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

それにもかかわらず、公開されたポストモーテムは予防のケースを未解決のままにしている。それによると、Fastly は品質保証とテストがそのバグを検出しなかった理由を調査し、復旧時間を改善する方法を評価し、WebAssembly と Compute@Edge を通じてより大きな分離を追求するという。しかし、結果としての調査、アクションオーナー、期限、完了の証拠、独立した評価は公開されていない。なぜ一つの構成が無関係なサービスに影響したのか、デプロイが POP 別または顧客コホート別に段階的だったのか、同じクラスの再発を今は何が防いでいるのかについて、公的な説明はない。

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

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

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

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

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

同じレターは、第2四半期の収益を8500万ドルと報告し、通年の収益ガイダンスを3億4000万ドルから3億5000万ドルに設定しつつ、見通しが停止、トラフィックの回復タイミング、予想される更新を反映していると述べた。これらの要因は公表数字から明確に分離できないため、期待の変化全体を1時間のダウンタイムに帰するのは不適切であろう。防御可能な結論はより狭い範囲のものである。すなわち、この停止はサービス提供クレジットと顧客のトラフィック決定を生み出し、その経済的影響を技術的インシデントを超えて拡大させた。

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

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

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

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

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

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

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

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

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

両側の取締役会は、リスク選好と証拠要求を制御していた。Fastly の取締役会は、プラットフォームリリースに独立した影響範囲の制御があるか、テナントアクションがサービス境界を越え得るかを問うことができた。顧客の取締役会は、どの重要なサービスがシングルホームなのか、切り替えまでの時間がビジネスの影響許容度内に収まっているかを問うことができた。どちらの取締役会も、自らの問いをもう一方に外部委託することはできない。

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

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

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

取締役会向け資料は、フリートの規模ではなく、故障ドメインマップから始めるべきである。POP 数、容量、ピアリングの広がりは有用だが、取締役はどの制御がグローバルで、どれが独立して隔離されているかを見るべきである。このマップは、ソフトウェアバージョン、構成配布、テナント境界、コントロールプレーン、DNS、証明書、ロギング、ステータスコミュニケーション、オリジンシールディング、プロバイダーの復旧ツールを接続するべきである。

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

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

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

NIST のコンティンジェンシープランニングガイドは、事業影響分析、予防的管理、復旧戦略、計画、テスト、訓練、演習、保守という永続的な手順を提供する。その連邦政府向けの範囲は普遍的な法的義務と誤解されるべきではないが、運用原則はよく通用する。復旧計画は演習と保守を通じて信頼できるものになる。

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

指標は安易なグリーンシグナルを避けるべきである。「2つの CDN が契約済み」は弱い。「前回の予告なし演習で、クリティカルなジャーニーの90%が8分以内に代替手段で提供された」はより強い。「グローバルネットワークが復旧」は、オリジンが過負荷の顧客にとって弱い。「正常なエラーバジェットで成功したトランザクションが30分間安定」はより強い。「バグ修正済み」は、回帰クラス、ロールアウトの証拠、完了責任者がなければ弱い。

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

Fastly の6月8日の停止は深刻で、目に見え、比較的短時間だった。この組み合わせは誤った結論を促し得る。一つは自己満足である。つまり、ほとんどのサービスが49分以内に復旧したため、このイベントは印象的な復旧物語になる。もう一つは運命論である。つまり、主要プロバイダーが故障し得るため、停止は不可避であり、これ以上の説明責任は無益だとする。証拠はどちらも支持しない。

迅速な復旧は評価に値する。トリガーとなる条件を予期すべきだったという Fastly の認める点も同様だ。しかし、潜在的な欠陥は5月12日から生き残り、一つの有効な顧客の変更がネットワークの大部分に影響を及ぼし、公開された是正記録は薄いままだった。予防、封じ込め、応答、保証は異なる制御である。応答における優れたパフォーマンスは、他の三つを閉じるものではない。

顧客にとって、このインシデントは、オリジン、二つ目の契約、DNS 手順が自動的に独立した復旧経路にはならないことを示した。GOV.UK の準備されたセカンダリも、意図的な待機、縮退したサービス、DNS 伝播を伴った。GitLab の通常の変更経路は、同じイベントの影響を受けた外部パッケージの依存関係に触れた。これらはコンティンジェンシープランニングに反対する議論ではない。それらは、コンティンジェンシーがすべての依存関係を通じて演習されて初めて現実のものとなるという証拠である。

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

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

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