拠点を1つから256に増やすと、当たり率は96.1%から51.4%に落ちました。
元への問い合わせは12.44倍です。速くなる代わりに、後ろ側の負荷が増えます。
既定は24時間です。中身が30分に1回変わるなら、その間の要求は古い内容を受け取ります。
Amazon CloudFrontは、既定で24時間ためておきます。公式は既定では、各ファイルは期限が切れるまで24時間、拠点にとどまると述べています。
その間に中身が変われば、古いものが届きます。どれくらいの割合になるのか実際に流して数えました。
24時間ぶん。要求 43146件、中身が変わったのは 51回（平均30分に1回） 作り直しの間隔を変えて、古い内容を返した割合を見る 作り直しの間隔 作り直した回数 古い内容を返した割合 古さの平均 10秒 7212回 0.3% 0.1分 60秒 1395回 1.8% 0.4分 300秒 287回 9.2% 1.8分 1800秒 48回 36.3% 11.0分 3600秒 24回 49.3% 21.9分
1時間の期限では、49.3%が最新ではありませんでした。平均の古さは21.9分です。
60秒まで縮めると1.8%です。ただし作り直しの回数は24回から1395回に増えます。
この表は、片方を良くすると必ずもう片方が悪くなる形をしています。中間の答えはありません。
だから先に決めるのは「何分まで古くてよいか」です。そこから間隔が決まり、回数は結果として出ます。
同じ形の判断はRedisの記事で扱った当たり率の頭打ちとも重なり、いくら詰めても取り切れない部分が残ります。
期限を延ばすほど、古い内容が届く割合が増える。
By default, each file stays in an edge location for 24 hours before it expires.原文AWS ドキュメント「What is Amazon CloudFront?」 この内容の有効期限2027-02-18
拠点ごとに別々にためます。増やすほど当たり率が下がり、元へ取りに行く回数が増えます。
Amazon CloudFrontは、元からの転送に料金がかかりません。公式はAWSの元を使う場合、元からCloudFrontへの転送は常に無料であると述べています。
料金はかからなくても、回数は増えます。拠点の数を変えて実際に振って数えました。
500,000 件の要求を 20,000 種類の中身に振る（よく使われるものに偏らせる）
配る拠点の数を変えて、拠点ごとに持ち合う場合の当たり率と元への問い合わせ回数を見る
拠点の数 1拠点あたりの要求 当たり率 元への問い合わせ 1拠点だけの場合との比
1拠点 500,000件 96.1% 19,519回 1.00倍
4拠点 125,000件 88.5% 57,668回 2.95倍
16拠点 31,250件 77.1% 114,403回 5.86倍
64拠点 7,813件 64.5% 177,705回 9.10倍
256拠点 1,953件 51.4% 242,890回 12.44倍
1拠点なら当たり率は96.1%です。256拠点では51.4%まで落ちます。
同じ中身でも、拠点ごとに1回は元へ取りに行きます。だから問い合わせは12.44倍になりました。
転送料はかからなくても、元が処理する回数は増えます。元が受けられる量を先に確かめることになります。
元が置くだけの場所なら問題になりません。Amazon S3の記事で見たように、読みは重ねやすいためです。
元が毎回計算する作りだと話が変わります。その場合は、拠点を増やす判断が元を増やす判断になります。
The data transfer from your origin to CloudFront is always free when using AWS origins like Amazon Simple Storage Service (Amazon S3), Elastic Load Balancing, or Amazon API Gateway.原文AWS ドキュメント「What is Amazon CloudFront?」 この内容の有効期限2027-02-18
期限は0秒から上限なしまで置けます。両端は別の仕組みになり、費用の形も変わります。
Amazon CloudFrontの期限は、両端まで振り切れます。公式は最小の期限は0秒で、最大の期限はないと述べています。
0秒なら毎回その場で作るのと同じです。両端を並べて実際に比べてみました。
24時間ぶん。1ページへの要求 43146件、中身が変わったのは 51回 その場で作ると 220ms、できているものを返すだけなら 8ms やり方 平均の応答 作り直した回数 古い内容を返した割合 毎回その場で作る 220.0ms 43146回 0.0% 60秒で作り直す 8.0ms 1395回 1.8% 1時間で作り直す 8.0ms 24回 49.3% 先に作っておくだけ 8.0ms 1回 99.4%
毎回その場で作れば、古い内容は0.0%です。ただし応答は220.0msで、作り直しが43,146回になります。
60秒で作り直せば、応答は8.0msのまま古さは1.8%です。ここが実用の範囲でした。
毎回作る形では、費用は元の計算量に乗ります。要求が増えれば、そのまま増えます。
置いて返す形では、費用は配った量と要求の回数に乗ります。元の計算は作り直しの回数ぶんだけです。
3つの計測はいずれも手元で書いた模型で、実際のAmazon CloudFrontを使ったものではありません。220msと8msは置いた値で、実測の応答時間ではありません。拠点ごとの当たり率は、要求が拠点に均等に散ると置いた結果です。実際には近い拠点に寄るため、寄りが強いほど当たり率は上がります。中身が30分に1回変わるという前提も置いたものです。ここで見せているのは、期限を延ばすと古さが増えるという点と、拠点を増やすと元への問い合わせが増えるという点の2つです。
The minimum expiration time is 0 seconds; there isn't a maximum expiration time.原文AWS ドキュメント「What is Amazon CloudFront?」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る