ついて説明する必要があり、よくわからないので文章でまとめて欲しいと言われたので、ブログでまとめます。専門でやっている人にとっては良く知られた言葉ですが、一般的には意識するケースはあまり多くないため、良い機会だと考えい私の知識のおさらいを兼ねてまとめます。CDNによるキャッシュの基礎についてWEBシステムでCDNを用いるメリットは主に2つです。高速化とセキュリティです。セキュリティは本記事からは割愛しますが、簡単に言うと、「攻撃者は常に勤勉である」ということです。攻撃者は常に最新の知識でシステムをたゆまなく狙います。そのための防御も、本質的には同じレベルの知識を持っている人を配置する必要がありますが、これは一般企業には大きな負担ですし、防御できる識者は、全企業に配置できるほど存在していません。このため、攻撃者とWEBサーバの間に専門家が責任を持つ防御システムを配置する必要があります。高速化の最大の要因はキャッシュです。Edgeと言われるCDNのサーバがコンテンツをキャッシュし、ユーザーのリクエストに対して、一般的にはよりNetwork的に近しいデータセンターからコンテンツを配信してあげることで通信を高速化させます。一般的にという点が重要です。時にはユーザーとしてオリジンの方がよりNetwork的に近いケースがあります。この場合CDNは意味をなさないかといえばそうではありません。WEBサーバはとても多くのことを一度に処理しますが、メインはプログラムの実行に多くのコンピュートリソースを費やします。これと同時並行でユーザーからのリクエストへの対応(TLS暗号化処理含む)を行っています。これを分業制にして、ユーザーからのリクエストの処理に特化した基盤を用意することで、ウェブサーバは本来行うべき仕事に集中させることが出来、リクエストの処理に特化した基盤は、それに特化している分より高速に動作します。これによりCDNはWEBサイト全体を高速化させます。キャッシュされたコンテンツをどの期間有効とさせるか?を秒数で設定する物です。この値が残っている間は(1秒につき1減っていくと想定して)オリジンが保有するコンテンツは使用される、CDNからキャッシュがユーザーのリクエストに対して配信されます。キャッシュを運用する際にはキャッシュTTLの設定がつきものです。デフォルト値というものは存在しますが、配信するコンテンツ事、Webサイトのユーザー数毎で最適な値は異なるのでメトリクスを見ながらTTLをチューニングしていく必要があります。オリジンのコンテンツは更新されているにも関わらず、CDNが古いコンテンツを配信し続けるケースがあるからです。Purgeこの際意図的にAPI経由などで今あるキャッシュを捨てる必要性が出てきます。これを行うのがCacheのPurgeです。これによりCDN側のキャッシュを捨てて、ユーザーからのリクエストの際は再度オリジンから新しいコンテンツを配信し、そのコンテンツを新しいTTLでCDN側でキャッシュさせます。ニュースサイトの場合、トップページは頻繁に変わりますので、そのページだけキャッシュさせない、などのチューニングが必要となります。Browserコンテンツのキャッシュには2種類存在します。今まで説明を行ってきたのはEdgeです。ブラウザもCDNとは無縁で単独でキャッシュの機能を持ちます。読み込むサイトや画像などはブラウザ内部でキャッシュを行い、読み込みを行わなくてもWEBサイトが表示される仕組みです。CloudflareではCDN側のキャッシュ(Edge)とブラウザのキャッシュ両方に個別のTTLをセットすることが出来ます。Cacheは時として課題を引き起こします。キャッシュTTLが無視されるケース著作権に厳しいコンテンツなどは意図的にTTLを0にして、ブラウザにコンテンツをキャッシュさせないケースもあります。CacheBrowserはユーザーの環境で動作します。Header等ブラウザの挙動を書き換えるツールを用いることでキャッシュの挙動を変更させることは実は難しくはありません。TTLはあくまで目安であり、それを保証するものではないことに注意してください。TTLの間コンテンツを維持するように努めます。それでもキャッシュが削除されてしまうケースがあります。Evictionという現象です。管理者が能動的にCacheを削除するのがPurge、意図せず削除されてしまうのがEvictionです。Cloudflareに限らずすべてのCDNでCacheを保存するストレージは有限であり、これを複数のユーザーで共有します。このためTTLの間キャッシュを保持することが出来ないケースもあります。CDNによっては、ユーザーアカウント毎にキャッシュストレージ容量を購入することでその現象を回避させることが出来ます。Cloudflareには有償でそのオプションが存在しています。キャッシュは利用されればされるほど(HIT)、WEBサイト全体のパフォーマンスは向上します。キャッシュが捨てられてしまった後ユーザーからのリクエストが来た場合、キャッシュの利用ができないため(MISS)、オリジンへ取りに行くため配信は遅延します。このためなるべくキャッシュはEdgeに残しておき高いHIT率を維持したいのがユーザーの本音です。Evictionの詳細メカニズムが開示されているケースはなく、Cloudflareも同様ですが、一般的にはアクセス数が少ないもの、より古いもの(TTLが短い=残り保存秒数が少ない)ものから削除されます。Cloudflareではこれを防ぐ仕組みを3つ提供しています。Evictionの影響がユーザーパフォーマンスに強く影響を与えているかを確認してください。以下のサイトなどでパフォーマンスを確認できます。https://pagespeed.web.dev/影響が限定的である場合気にする必要はありません。テストを行う際、コンテンツに対してある程度のアクセス数を発生させてください。Evictionが発生するケースがあるため、例えば負荷ツールなどを用いて、数十/秒でアクセスしてみて下さい。CacheまずCDNのEdge数は非常に多く、それぞれのセンターが個別にCache用ストレージを持っていることに留意してください。このため、一度コンテンツがキャッシュされたとしても、複数回のアクセスが別のEdgeセンターにルーティングされた場合CacheはMISSとなります。これは仕様通りの動作です。複数Cacheを束ねる親玉、大きいストレージを持ちそこから各Edgeにキャッシュを配信させてあげる存在です。Cacheにキャッシュを取りに行きます。そこでもキャッシュが存在しない場合、末端のEdgeの代理としてキャッシュをオリジンに取りに行きます。これはOriginへの接続回数を減らす効果も持つため、全体をパフォーマンス向上させることが期待できます。Cacheが存在しています。各EdgeセンターでEvictionが発生したとしてもその影響を軽減できます。Reserveはアカウント専用にCacheを保存する専用ストレージを作成するオプションです。これを用いることでその容量の範囲内ではEvictionが発生しなくなります。ReserveはR2というCloudflareが提供するオブジェクトストレージ上に作成されます。専用の領域を確保するためEvictionの問題解決には役に立ちますが別の複合化したパフォーマンスの課題に対しては効果の検証が必要です。オリジンにR2を使用しており、Edge→R2への通信も高速化したいという要件がある場合、同じ場所に専用Cacheストレージが出来るため、そのパフォーマンスは改善しない可能性があります。(暖気)例えばビデオ配信のように、ある特定の時間から一斉配信を開始させるがその前にキャッシュをさせておきたい場合、Workersを例えば5秒cronで起動して定期的に読み込ませておく手法も有効です。triggerを用いた場合、特定のEdgeでのみ実行されるケースがあり、その場合コンテンツは特定のEdgeでのみキャッシュされます。Workersを作成し複数拠点からブラウザでアクセスさせてみて下さい。エバンジェリストバッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。