要約

  • Workers Cacheを有効にしたWorkerへのリクエストには標準のリクエスト料金が適用され、通常無料の静的ファイルも対象になる。キャッシュヒットでコード実行とCPU料金を省いても、リクエストの計数は残る。
  • 計算量の多い公式事例では11.20ドルを節約する。一方、静的ファイルが多い別の公式事例に同じルールを適用すると、月間の含有枠がすべて残っている条件で1.50ドル増える。

プロセッサーを休ませることには成功した。料金計には新しい仕事ができた。

CloudflareのWorkers Cacheは、Workerのコードを動かす前に保存済みの応答を探す。見つかればそのまま返し、コードを実行しない。重複計算を避ける効果は明快だ。同時に、この機能を有効にしたWorkerへのすべてのリクエストが標準リクエスト料金の対象になる。通常は無料の静的ファイルもそこに入る。

公式文書には「別料金はない」という説明と、この課金範囲がともに記載されている。新しい料金項目を作らなくても、既存の項目に入れる利用を増やせば金額は変わる。購入側が確認するのは単価だけでは足りない。

5ドルの事例を6.50ドルにする条件

Workers Paid Standardは、アカウント当たり月額最低5ドル。月1,000万リクエストとCPU 3,000万ミリ秒を含む。超過分は100万リクエスト当たり0.30ドル、CPU 100万ミリ秒当たり0.02ドルだ。枠はアカウント単位であり、Workerを増やすたびに追加されるものではない。

料金ページの公式事例2は、月1,500万リクエストを扱う。1,200万件は静的ファイル、300万件は動的処理で、後者の平均CPU時間は7ミリ秒。静的ファイルは無料で、動的リクエストとそのCPU 2,100万ミリ秒は含有枠に収まる。掲載された合計は5ドルだ。

このトラフィックを変えず、Worker全体でWorkers Cacheを有効にした場合を計算する。有料Standardアカウント一つを使い、月間の枠がすべて利用でき、他の利用や製品、税・割引調整がないものとする。今度は1,500万件すべてが課金計数に入る。枠を超える500万件に1.50ドルがかかる。

動的応答が一度もキャッシュに当たらなくても、CPUは2,100万ミリ秒で含有枠以下にとどまる。CPU超過料金は引き続きゼロ。ヒットが増えてCPUをさらに減らしても、この項目をゼロより下へ下げることはできない。合計は6.50ドルとなる。

これは公式事例2の数量に公開されたキャッシュ規則を当てはめた独自の条件付き計算だ。実際の顧客請求書を観測した数字ではない。もともと料金に含まれていた計算を減らす一方、無料だったリクエストが請求に入る。この仕組みを切り分けている。

CPUに料金が付いていれば、節約先がある

別の公式事例はキャッシュによる金銭的な効果を示す。月1億リクエスト、それぞれ平均CPU 7ミリ秒なら、基本5ドル、リクエスト超過27ドル、CPU超過13.40ドルで合計45.40ドル。

ヒット率80%のキャッシュを使う事例では、コードが実行されるのは2,000万件になる。CPUは1億4,000万ミリ秒、CPU超過料金は2.20ドルまで下がる。リクエスト料金は27ドルのまま。合計34.20ドルだ。

節約額は11.20ドルで、総額のおよそ4分の1に当たる。80%というヒット率が示すのはコードを実行せず返した応答の割合だ。請求書には応答の配信も残り、CPUの含有枠は使用量の減少率と金額の減少率の関係を変える。

計算負荷が高く、すでにCPU超過料金を払っている動的サービスには、キャッシュで削れる支出がある。静的ファイルが中心で、動的処理も枠内だったサービスでは、先に課金対象の拡大が表れる可能性がある。同じ機能でも、出発点の経済性が違う。

どこで有効にするかも購買判断になる

ここでのWorkers Cacheは実行前に応答を探す固有の機能である。Workerのコード内で使う従来のCache APIや、一般的なゾーン単位のCDNキャッシュとは範囲が違う。文書によれば、ゾーンのCache RulesやPage Rulesで設定するものでもない。

通常のStandardサービスバインディングでは追加のリクエスト料金が生じないWorker間呼び出しも、この機能を有効にしたWorkerでは対象になる。アプリを複数のWorkerに分けるとき、どこで機能を有効にするかが費用設計に加わる。実際の経路と設定なしに、部品の数だけから連鎖全体の料金は出せない。

階層化キャッシュや同時リクエストの集約は、重複実行をさらに減らせる。それでも、配信されたリクエストは独自に数えられる。プラットフォームは計算だけでなく応答の配信も売っている。

実際の請求額には、トラフィックの内訳、CPU利用、他の処理が消費したアカウント枠、適用契約が必要だ。その数字がそろえば、どちらの効果が上回るかを判断できる。

「ヒット率が上がった」と報告する会議には、もう一つ質問を置きたい。「新しく有料になったリクエストはどれか」。プロセッサーは休んでよい。予算の担当者にはまだ計算が残る。

出典