要約

  • Fastly はエッジの未命中と shield の命中を別々に数える。オリジンを呼ばない配信でも未命中が集計され、比率はオリジン呼び出し回避率と一致しない。
  • Fastly の POP 間通信はリクエスト数と課金対象帯域に入る。全体の節約はあり得るが、すべての顧客で実証されたわけではない。
  • エッジ命中時のヘッダーには過去の shield イベントが残り得る。キャッシュ可能な取得だけを数える指標にも範囲があり、どちらも単独で請求を示さない。

低く見える比率が答えない質問

配信を買う側は、キャッシュ命中率が高ければオリジンを守り、費用も抑えたと考えたくなる。だが Fastly のshielding 概念ガイドには、その三つを分ける具体例がある。

利用者のリクエストを受けたエッジ POP に内容がなくても、中間の shield POP にあれば Fastly 内で配信が完了する。オリジンを呼び出す必要はない。一方、キャッシュ比率の計算ではエッジの未命中と shield の命中をともに記録する。オリジンへ届く場合は両方で未命中を数える。

一回の配信と一回のキャッシュ判定は別の単位である。上流キャッシュが役立っても、集計比率は購入側の予想より低く見える可能性がある。だからといって低い比率がいつも良いという意味ではない。キー、鮮度、需要には本当の問題があるかもしれない。

オリジン呼び出しの減少にも別の説明があり得る。成功する利用者リクエストが減れば、負荷も減る。本稿は顧客の通信を測っていない。公開された数え方が示すのは、一つの比率で全結果を証明できないという限界である。

オリジンが休んでも CDN は働く

shielding の設定ガイドは、shield への入力通信を通常の通信として課金し、他の POP のキャッシュを満たす転送も含むと説明する。概念ガイドも、Fastly POP 間の通信がリクエスト数と課金帯域に入ると明記する。

したがって shield 命中は、オリジンへの一回を避けると同時に、CDN 内の有料の仕事を残し得る。矛盾ではない。アーキテクチャは仕事の場所を変えたのであって、利用者へ内容を届ける通信を全部消したわけではない。

Fastly は追加帯域料金がオリジンの帯域とサーバー負荷の節約で相殺される可能性を説明し、現実的な構成では全体費用が下がることも多いとする。この潜在的な利点は無視すべきでない。しかし実際の比較には、顧客の通信構成と CDN、オリジン両側の商業条件が必要となる。

文書の極端な例は、すべてを PASS とするサービスだ。多くのリクエストが二つの POP に提示されるため、リクエスト数と配信帯域はほぼ倍になるとされる。金額が全顧客で倍になる規則でも、誤った二重請求の発見でもない。本稿は割引、契約コミットメント、オリジン単価、通信量を調べていない。

比較表の分母を決める責任

命中率上昇だけを評価する購買表は、二つ目の判定を数えた shield を不利に扱うかもしれない。オリジン呼び出し減少だけを評価する表は、追加の CDN 転送を落とすかもしれない。どちらも数字を正しく読み、購入結果を誤って説明できる。

有用な受入比較では、利用者需要と時間範囲を明示し、shield とオリジンの活動を分ける。バイト項目に何が入るかも残す。応答本文のバイトは本文とヘッダーの合計ではなく、リクエスト数は一意な利用者数ではない。似た名前で単位を置き換えてはいけない。

中間キャッシュを買うのに、全部のカウンター低下を要求する必要はない。仕事を再配置する機能なのだから、再配置が配信目的と費用目的を満たすかを示すことが重要だ。本稿に顧客の節約額はなく、都合のよい数字で未提出の証拠を補わない。

ヘッダーが記憶する過去の経由

概念ガイドにはもう一つの境界がある。X-Served-By、X-Cache-Hits、X-Cache は複数 POP の項目を持ち得る。しかし現在のリクエストがエッジ命中なら、shield 項目は以前に内容をキャッシュしたときのイベントに由来する場合がある。今回も shield を訪れたとは限らない。

二項目の応答をすべて新しい課金転送と数えると、履歴情報から現在のイベントを作ってしまう。ヘッダーは時間の意味を保って読むと役立つが、各項目を請求明細に変える根拠にはならない。

X-Served-By の説明も、キャッシュ識別子や拠点コードが再利用され得ると注意する。生成時に正確な名前を、時間をまたぐ永続的な設備識別子にしてはいけない。この記事は顧客ヘッダーの収集も CDN の経路試験も実施していない。

HIT は複数状態の短い表示

X-Cache の説明では、PASS が MISS、エッジで生成する合成内容が HIT と報告される。古い内容やバックグラウンド再検証による命中も HIT となる。複数項目は shielding、Next-gen WAF at Edge、処理の再起動に由来することもある。

つまり HIT を、今回のリクエストが想像どおりの保存済みオブジェクトを取り出したという万能な言葉にはできない。非 MISS がキャッシュで満たされ転送されなかったという説明にも、再起動の留保がある。留保を消せば文章は単純になるが、証拠は正確にならない。

これはコードの手順ではなく契約評価の話だ。ヘッダー表示は課金単位ではない。運用者は応答の理解に使えるが、財務が各項目を現在の仕事の独立した証明として足し合わせるべきではない。

生の指標にも範囲がある

リアルタイム分析と履歴統計の参考文書は、shield とオリジンを別々に数える。shield_fetches は shielding の POP 間リクエスト、cache_fetches の項目は完了してキャッシュ可能な内容を返した取得を対象とする。後者はすべてのリクエストではない。

ほかの項目も命中、未命中、リクエストや応答の本文、ヘッダーバイトを分ける。同じ期間と定義で使えば、仕事の場所を説明する助けとなる。それだけで請求書、純節約、性能証明になるわけではない。

shielding への反対論ではない。買うべきは実際の効果である。エッジ未命中と shield 命中は、オリジンを避け、比率に未命中を足し、有料の CDN 転送を残すという三つを同時に説明し得る。よい受入は三つを共存させる。

出典