要約

  • Fastlyのサービスバージョンは以前の設定を再有効化できるが、APIのactive状態は全実行群の収束を示すリクエスト証拠ではない。
  • 受入台帳には、観測POPごとの旧バージョン最終応答、復旧バージョン、問題行動を通るテスト、別管理となるpurgeまたはキャッシュgenerationを残すべきだ。

中央画面は完了を示し、以前のバージョンがactiveに戻り、全体エラー率も下がる。それでも遠隔の一つのPOPでは、撤回したはずのルールが動く。これはFastlyで報告された事故ではなく、受入試験の仮想場面である。命令の受領と結果を分けるための問いだ。

Fastlyでは、サービスバージョンは特定の設定インスタンスであり、複製、ロック、有効化、無効化ができる。一度にactiveなのは一つで、古いinactiveバージョンを再有効化できる。復旧対象が明確になる一方、API応答時刻を完了時刻と見なしたくなる。

Fastlyの入門チュートリアルは、設定伝播に数分かかる場合があると説明する。分散システムの伝播時間自体は欠陥ではない。中央状態と世界のリクエスト挙動が別の観測であることを意味する。

POPは実行する集団である

FastlyはPOPをキャッシュサーバーのクラスタと説明する。clusteringやshieldingによって、一つのリクエストが複数のサイトやPOPを通ることもある。VCLのserver.datacenter、ComputeのFASTLY_POP、サービスバージョン識別子を使えば、どの設定が、どこで、いつ判断したかを記録できる。

一般的なヘルスチェックでは足りない。カナリアは撤回対象だったパス書換え、アクセス条件、オリジン選択、ヘッダー、キャッシュキー、Compute分岐、セキュリティ判断を実際に通る必要がある。無関係な正常応答はロールバックを証明しない。

最初の時刻は中央の有効化応答であり、決定的なのは旧ルールに従った最後の応答である。その差が収束時間だ。平均ではなく、観測したPOPの最大値を見る。

ログの不在は世界的な不在とは限らない

Fastlyは準リアルタイムのログストリーミングと、応答したデータセンターを記録する変数を提供する。期限後に旧バージョンを示す行は明確な陽性証拠になる。一方でFastlyは、ログ配送はbest effortで保証されず、性能と安定性のために記録が失われ得ると明記する。

したがってログに旧版がないだけでは、全世界で消えたと証明できない。能動プローブ、応答内のPOP・バージョン、実トラフィック、プラットフォーム証拠、未観測集団の一覧を組み合わせる。anycastのため任意のPOPに直接送れない場合は、実際のカバレッジを報告し、不確実性を隠さない。

設定とキャッシュは別の面で戻る

Fastlyのpurge文書では、purge-allは最長2分、URLやsurrogate-key purgeは約150ミリ秒で伝播する。エッジコードからのcache-key purgeはglobalを指定しなければローカルPOPだけに効く。soft purgeは古いオブジェクトをstaleとして利用可能にする場合がある。

shieldがpurge前の内容をedgeへ返し、古い内容が再びキャッシュされる競合も文書化されている。purge-allではVCLとComputeからキャッシュgenerationを読める。設定バージョンが戻っても、オブジェクト、キー、動的データ、オリジン状態まで正しいとは限らない。purgeするなら再充填によるオリジン負荷も管理する。

2021年の出来事から使える範囲

Fastlyは2021年6月8日の世界的障害を、有効な顧客設定変更が未発見のソフトウェアバグを発火させた結果と説明した。09:47 UTCに始まり、10:27に設定を特定、10:36に回復開始、11:00に大部分が回復、12:35に緩和したという。

これは有効な設定が世界規模でプラットフォームと相互作用し、復旧に段階があることを示す。特定POPが撤回済みルールを保持したとは書かれていない。正当な教訓は、ロールバック時間と完了証拠を個別に受け入れることだ。

台帳にはサービス、撤回版と復旧版、中央応答、リクエストで観測した版とPOP、正確なカナリア、trace、キャッシュgeneration、旧応答の最終時刻、復旧応答の初回時刻、カバレッジ、ログ欠落、終了権限者を結合する。

情報源