Fastly の潜在バグと集中型 CDN エッジのアカウンタビリティ

要約

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

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

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

Fastly の6月8日障害の要約は、中心的な因果関係の説明を提供している。5月12日に開始されたソフトウェアデプロイメントがバグを導入した。それは、顧客が特定の条件下で有効な設定変更をプッシュするまで休眠状態にあった。Fastly によると、ネットワークの85%がエラーを返した。監視は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 およびウェブホスティングプロバイダの統合に関する最初の考察では、Cloudflare、Amazon、Akamai、Fastly、Google が合わせて Tranco 上位10,000のインデックスページの約62%をホストし、多くのサイトの外部リソースの大部分を供給していることがわかった。

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

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

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

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

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

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

Government Digital Service のGOV.UK の公開インシデントレポートは、顧客側の意思決定の最も明確な記録の1つである。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 は異なるボックスとして表示される。運用上、回復アクションはそれを実行するために必要なすべてのボックスに依存する。1つのビルドステップが利用できない外部サービスに到達する場合、別の依存関係を削除するために正確に必要な瞬間にパイプラインは利用できなくなる。

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

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

GitLab と GOV.UK は異なる結果に達した。なぜなら、回復力は実装にローカルだからである。プロバイダインシデントは共通であった。顧客の爆発半径はそうではなかった。これが、ベンダーがダウンしたから顧客のアカウンタビリティを否定できず、一部の顧客にセカンド CDN がなかったからプロバイダのアカウンタビリティを希釈できない理由である。Fastly は共有障害の予防と復旧を所有していた。各顧客はその依存関係の形状と準備状況を所有していた。

回復はキャッシュ効率をオリジン負荷に変える可能性がある

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

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

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

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

実践的なテストはトラフィック演習である。組織は危機なしに本番トラフィックの限定された割合を代替パスに誘導できるか？代替は同じ必須コンテンツとセキュリティヘッダーを返すか？期待される負荷と再試行の急増を処理できるか？キャッシュ無効化と緊急公開は利用可能か？エンジニアはプライマリベンダーの障害ドメイン外の資格情報、デバイス、リポジトリ、通信システムを使用してそれを操作できるか？復旧手順はセカンドインシデントを作成せずに元に戻せるか？

サービスレベル契約はこれらの質問に答えない。クレジットは事後に狭い契約上の尺度を補償する。彼らは失われた取引、遅延した公的通知、または開発者ワークフローを復元しない。SLA に依存し、フォールバックを実行しない顧客は、継続性に対する運用上の責任ではなく、いくつかの金銭的結果を移転したことになる。

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

ThousandEyes は、複数の配信プロバイダを持つ顧客が異なるレベルの成功を収めたことを観測した。一部はルートトラフィックを Fastly から遠ざけたが、重要なページオブジェクトを Fastly から読み込み続けた。他の顧客はすべての Fastly 依存関係を削除するのに時間がかかった。この動作は設計の落とし穴を示している。最初のリクエストでのトラフィックステアリングは、ページが後で障害のあるプロバイダからのスクリプト、スタイル、API、イメージ、フォント、リダイレクト、認証アセットを必要とする場合には十分ではない。

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

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

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

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

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

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

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

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

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

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

Fastly の対応は迅速だったが、公的保証は狭かった

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

これらの事実は最小化されるべきではない。迅速な検出と復旧は公的被害を実質的に軽減した。分散システムは確かに障害を起こし、インシデントアカウンタビリティは制御の失敗と同様に制御のパフォーマンスを認識すべきである。深刻な欠陥を露呈し、1時間以内に封じ込める組織は、自社のプラットフォーム状態を確認または元に戻せない組織とは異なるリスクを示す。

それでも公開ポストモーテムは予防ケースを未解決のままにしている。それは、品質保証とテストがバグを検出しなかった理由を調査し、改善時間を評価する方法を評価し、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つのインシデントは同じ技術的原因を持つとは説明されていない。しかし、それらの共存は、ソフトウェアリリースの回復力を1回限りの運用上の異常ではなく、持続的な取締役会の注目に値する合理的な主題にする。

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

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

アカウンタビリティは共有されるが、曖昧ではない

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

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

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

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

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

双方の取締役会は、リスクアペタイトと証拠要求を管理した。Fastly の取締役会は、プラットフォームリリースに独立した爆発半径制御があるかどうか、テナントアクションがサービス境界を越えることができるかどうかを尋ねることができる。顧客の取締役会は、どの重要なサービスがシングルホームであるか、切り替え時間がビジネスの影響許容度内にあるかどうかを尋ねることができる。どちらの取締役会もその質問を他方に委任することはできない。

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

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

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

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

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

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

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

NIST の緊急時計画ガイドは、耐久性のあるシーケンスを提供する。ビジネス影響分析、予防制御、回復戦略、計画、テスト、トレーニング、演習、保守。その連邦範囲は普遍的な法的義務と誤解されるべきではないが、運用原則はうまく伝わる。回復計画は、演習と保守を通じて信頼性が高くなる。

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

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

永続的な教訓は独立した回復についてである

Fastly の6月8日の障害は深刻で、目に見え、比較的短かった。その組み合わせは間違った結論を促す可能性がある。1つは自己満足である。ほとんどのサービスが49分以内に戻ったため、イベントは印象的な回復ストーリーになる。もう1つは運命論である。主要プロバイダが障害を起こす可能性があるため、障害は避けられず、これ以上のアカウンタビリティは役に立たない。証拠はどちらも支持しない。

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

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

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

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

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