要約

  • draft-ietf-cdni-ci-triggers-rfc8007bis-20では、下流CDNは取り消し要求に応答しなければならないが、実際の取り消し実装は任意である。受理後でも、待機中の処理が先に始まり、実行中の処理が先に完了し得る。
  • cancelling、cancelled、processed、complete、削除は同じ意味ではない。状態リソースを削除すると、作業を止めないまま最も直接的な証拠を失う場合がある。

コンテンツ事故でパージを送るのは速い。難しいのは、その後に何を事実として扱うかである。

2026年9月のCDNI Control Interface / Triggers第2版・改訂20は、上流CDNから下流CDNへ、コンテンツやメタデータの事前配置、無効化、パージを依頼する仕組みを記述する。事前配置は需要の前に取得する。無効化は再検証なしの利用を禁じるが、保存データの消去までは求めない。パージは対象データを保持しないことを求める。似た操作名でも、変える状態と復旧費用は違う。

取り消しも実行中の時間に従う

下流CDNは取り消し要求に答える。しかし、草案は実際の取り消しを実装任意としている。pendingを見て直ちに取り消しても、その要求が処理される前に元の作業が始まることがある。activeやprocessedの取り消しが受理されても、停止処理の途中で通常完了に達する可能性は残る。

そこで状態が分かれる。cancellingは停止を求められたことを示す。通常完了より前に本当に止まって初めてcancelledになる。元の処理が先に終われば、最後はcompleteまたはfailedになり得る。「間に合うつもりで送った」と「実行が間に合って止まった」は別の時系列である。

パージ対象にも時間境界がある。activeへ入る前に取得済みのデータは対象となり、取得中のデータも対象にすべきだ。一方、開始後に取得したデータは原則として対象外だが、草案は完全に実現できない場合を認める。単一の命令が全キャッシュ活動を同じ瞬間に切断するわけではない。

置き換えでは、この差が障害になる。古いパージの完了を待たず新しい版を事前配置すると、新しいオブジェクトが先に到着し、後から古いパージに消され得る。実行ポリシー拡張の依存関係は、後続処理を先行処理の完了まで待たせる。これは管理上の注記ではなく、二つの正しい命令が逆順の結果を出すことを防ぐ機構だ。

processedは完了ではなく観測限界である

草案のprocessedは、トリガーが作成され、以後の状態更新がなく、完了を確認できない場合に使われる。下流CDNは処理を続け、可能なら完了見込み時刻を示す。成功を婉曲に述べた語ではない。制御インターフェースが最終受領証を返せないという宣言である。

運用側はprocessedを成功キューへ移してはならない。パージなら、最後に得た状態、対象やエラーの情報、オリジンへの要求変化、キャッシュ探査、実際に配信された版を組み合わせる。事前配置なら、対象フットプリントから制御された要求を出し、期待した版が返るかを確かめる。独立観測は絶対確実ではないが、受領証の欠如を肯定的な証明へ変える誤りを防ぐ。

HTTP応答はさらに前段の証拠だ。201 Createdはトリガーリソース作成、202 Acceptedは未完了の受理、削除時の204 No Contentは状態リソース消失を示す。各キャッシュがどのバイトを保持・配信しているかまでは証明しない。

削除は証拠保持の判断でもある

草案では削除は取り消しに似るが、完了後にトリガーリソースが利用不能になる。そのため、終了後の状態が必要なら削除より取り消しを推奨する。

削除しても競争は消えない。pendingが先に始まることも、activeやprocessedが最後まで走ることもある。正当な削除応答を受け取り、状態URIを失い、それでも遠い支流でパージが続くという組み合わせが成立する。

自動失効も同じ問題を静かに起こす。下流CDNは終端状態のリソースを削除し、その後404を返せる。保持期間は公開しなければならず、実行や再配布が続くと合理的に考えられる間はprocessedを失効させるべきではない。UUIDを再利用しないことは別命令との混同を防ぐが、消えた履歴を保存する機能ではない。

カスケードは最も遅い枝まで閉じない

中継CDNがさらに下流へトリガーを配る場合、自身だけの終了でcompleteを報告できない。自身と全対象下流CDNで完了して初めて完了となる。一つでもprocessedなら集約結果もprocessedであり、取り消しは全枝がcancelled、complete、failedのいずれかになるまでcancellingに留まる。

この規則は速い枝が遅い枝を代表することを防ぐ。同時に、元トリガーと各中継リソースの対応、CDN経路、枝ごとのエラー、状態遷移時刻、その後のコンテンツ観測を保存する必要を生む。

ダイヤモンド型では、同じ下流CDNへ複数経路から関連データが届き、遅延差や競合メタデータが生じる。草案はこれを構成エラーとする。拡張状態のオブジェクト数、ノード数、バイト数は異常検知に役立つが任意であり、複数ノードで扱った同一オブジェクトを重複排除しない。厳密な固有オブジェクト台帳ではない。

completeの強さを正確に使う

草案は、カスケード下流を含む全操作が成功するまでcompleteを報告してはならないとする。これは強いプロトコル上の約束であり、無意味な表示ではない。

ただし答えるのは、指定された処理が終わったかという問いである。既知オブジェクトに一つも一致しない無効化やパージも、ゼロ件のまま成功し得る。指定パターンが運用者の意図した集合と異なることもある。CDNIは制御、メタデータ、要求ルーティング、ログを別インターフェースに分ける。制御完了だけでは利用者が受け取った表現まで確定しない。

実務では五つの時点を残すべきだ。元のトリガー、隣接CDNの受理、取り消しまたは削除要求、全カスケード枝の終端状態、独立したコンテンツ効果である。cancelling、processed、単一の2xxだけで不可逆な後続処理を許可しない。事故前に各相手の取り消し、拡張状態、枝エラー伝播を実地確認する。

改訂20はまだInternet-Draftである。凍結したIANA登録にはRFC 8007の型が残り、提案中の.v2はない。調査資料は特定CDNの導入も証明しない。それでも設計上の教訓は明確だ。取り消しの受理は、停止要求が届いた証拠であって、パージが起きなかった証拠ではない。

情報源