要約

  • DigitalOceanの説明では、署名付きURLの要求はCDNや独自ドメインを使っていても、その都度Spacesのオリジンへ転送され、Spaces CDNにはキャッシュされない。
  • 通常のキャッシュでクエリ文字列がキーを分散させる問題とは異なる。保持時間を延ばしても、明示されたキャッシュ対象外の条件は変わらない。
  • CDN利用の追加料金がないことは、転送量が無制限という意味ではない。保護されたファイルの費用と継続性は、実際の要求経路で評価すべきである。

「取得できた」の次に確認すること

システムの受け入れ試験では、必要なファイルが取得できれば連携成功と判断しやすい。だが、それだけでは配信の仕事をどこが引き受けたかは分からない。署名付き要求が成功することと、エッジにあるコピーから応答することは、別の検証結果である。

DigitalOceanが9月3日に確認したSpaces CDNの設定ガイドは、その違いを明示する。署名付きURLはCDNまたは独自のホスト名で使える一方、要求はキャッシュされず、毎回オリジンへ転送される。説明されている主な利点はホスト名の統一であり、通常のキャッシュヒットや、それによる遅延短縮ではない。

これは障害を発見したという報告でも、脆弱性の指摘でもない。公開された製品条件を、購入時の前提に反映する話である。アドレスが正常に機能しても、購入者が想定したキャッシュによる負荷吸収が成立するとは限らない。

公開画像と顧客限定の文書が同じドメインに並んでいる場合、この違いは見えにくい。画面上の統一は保たれても、要求の扱いは統一されていない。公開画像の速度測定を、そのまま限定文書の性能やオリジン依存の評価に使うことはできない。

キーの分散より先に、対象かを問う

CDNの効果が乏しいとき、URLの変化がキャッシュ再利用を妨げているという説明はよく使われる。DigitalOceanの機能説明でも、通常のキャッシュはクエリ文字列を含む異なるURLを別の資産として扱う。対象となる要求について、キーの増え方を調べる意味はある。

しかし署名付き要求についての記述は、「別のキーで保存される」ではなく「キャッシュされない」である。まったく同じ署名付きURLを繰り返しても、文書の条件に反してSpaces CDNのヒットが生じると評価する根拠にはならない。

通常のTTLは、キャッシュ対象の内容を更新前にどれだけ保持するかを決める。対象外の要求を対象へ変える設定としては説明されていない。保持時間の調整と要求の適格性を混同すれば、運用側は設定を何度変えても、肝心の配信経路を変えられない。

一方、この結論をすべてのキャッシュに広げるのも誤りである。証拠の範囲はSpaces CDNに限られる。ブラウザー、別の中継層、他のS3互換サービスが同じ条件で動くと示したものではない。別の設計には、その設計固有のアクセス制御、更新、失効の評価が必要になる。

接続形式が保証する範囲

ガイドの手順は、まず非CDNエンドポイントに対してGetObjectの署名付きURLを生成し、次にホスト名をCDNまたは独自ドメインへ置き換えるというものだ。対応するのはバケット名がホスト名に含まれる仮想ホスト形式である。バケット名をパスに置く形式、例えばforcePathStyleを有効にしたURLは、このCDNホスト名の利用に対応しない。

この条件はアドレスが使えるかを規定する。署名付き要求がキャッシュ配信を受けられるかを保証する条件ではない。SDKの互換性確認に合格したからといって、キャッシュ性能の評価にも合格したことにはならない。

製品区分にも境界がある。Spaces Cold StorageはCDN連携と独自CDNエンドポイントに対応していない。ここで評価しているのはStandard Storageでサポートされる構成であり、保存単価を下げるためにクラスを替えても同じ配信条件が残るとは限らない。

この確認に有効な署名の公開は不要である。測定するなら許可された試験ファイルを使い、実際の顧客文書へアクセスできるリンクを共有報告書に残さない。要求の種類を識別して文書と照合するだけでも、最初の誤った前提は取り除ける。

追加料金なしと、計量なしの違い

Spacesの料金説明では、Standard Storageの基本契約は月額5米ドルで、250 GiBの保存容量と、バケット間で共有する1,024 GiBの外向き転送枠を含む。超過転送は1 GiB当たり0.01米ドル。CDNとオリジンの帯域は共通の枠を使い、オリジンからエッジへの転送も計量対象となる。

CDNの有効化に独立した追加料金がないことと、配信量を数えなくてよいことは違う。署名付きダウンロードの予算で、繰り返す需要がSpaces CDNのヒットによって吸収されると先に見積もることはできない。配信バイト数、計量される経路、他のバケットを含む枠の使用量が必要である。

ただし、この説明だけで署名付きダウンロードが常に二重請求になるとは言えない。料金規則は実測した顧客請求書ではない。サイズ、配信量、枠の消費を把握せず、あり得る区間を機械的に足して倍率を断定するのは、仮定を結果として扱うことになる。

料金ページが別に説明するVPC内のDNSリゾルバーを使うプライベートSpaces通信も、区別すべき条件だ。これは内部ネットワーク経路についての説明であり、ファイルのアクセス制限やURLの署名と同義ではない。保護されたインターネット経由の要求が、署名によって内部経路へ変わると推論する根拠はない。

継続性を支えるコピーはどこにあるか

機能説明には、オリジンが一時的に利用できなくても、エッジにキャッシュ済みの内容は配信を続けられるという記述がある。重要なのは「キャッシュ済み」の条件である。CDNという名前の全要求を対象にした無条件の保証ではない。

毎回オリジンへ転送される署名付き要求について、このSpaces CDNのコピーを代替手段として使えるとは確認されていない。それは障害の発生や失敗率を示すものでも、SLAを書き換えるものでもない。ただ、通常のキャッシュに関する継続性の根拠を、そのまま借用できないという限界である。

必要なファイルごとに、配信の条件を対応づけるべき理由はここにある。公開ページの高速な画像は、限定ダウンロードの継続性を検証していない。正常なHTTP応答は有用な観察だが、依存関係の説明を完結させない。

統一されたホスト名には実際の価値がある。既存の署名付き経路が要件を十分満たす場合もある。調達の課題は製品を不適格と決めつけることではなく、名前の便利さを、文書にないキャッシュの保証として評価しないことである。

出典