We've been making changes to how we organize and display our docs. Our work isn't done but we'd love your feedback.
Getting started
Basics
Domains & Origins
Performance

Configuration
Basics
Conditions
Dictionaries
Domains & Origins
Request settings
Cache settings
Headers
Responses
Performance
Custom VCL
Image optimization
Video

Security
Access Control Lists
Monitoring and testing
Securing communications
Security measures
TLS
Web Application Firewall

Integrations
Logging endpoints
Non-Fastly services

Diagnostics
Streaming logs
Debugging techniques
Common errors

Account info
Account management
Billing
User access and control

Reference

    CDN とキャッシュの仕組み

      Last updated April 24, 2018

    Fastly はコンテンツ配信ネットワーク、つまり CDN です。 CDN は、一度生成したコンテンツはしばらくの間、再度生成する必要はないという原則に基づいているため、コピーをキャッシュ内に保持することが出来ます。 キャッシュ サーバーは、小さなファイルを非常に高速に配信できるよう最適化されています。 一般的に CDN は、世界中のデータセンターにキャッシュを保持します。エンドユーザーが CDN を利用しているサイトにアクセスすると、実際にはオリジナルのコンテンツを保持しているサーバーではなく、ネットワーク的に近くのキャッシュサーバーにアクセスします。 これにより、例えばヨーロッパのユーザーがアメリカのサイトからコンテンツを取得する場合、200ミリから500ミリセカンド程度早くコンテンツを取得出来ることになります。また、CDN はキャッシュミスの影響を最小限に抑えるように設計されています。キャッシュミスは、ユーザーがコンテンツをリクエストした際に、キャッシュサーバー上にキャッシュが存在しない場合に発生します。これは有効期限が切れていた、過去に一度もそのコンテンツがリクエストされていない、キャッシュスペースがいっぱいになって古いキャッシュコンテンツが削除された、場合などに発生します。

    キャッシュ可能なオブジェクト

    CDN は、静的なリソース(CSS ファイル、Javascript、アニメーション GIF など)のキャッシュを管理するのに適しています。また、ビデオやオーディオメディアなどの配信に負荷のかかるファイルをオフロードするためにもよく利用されます。

    Fastly の(リバースプロキシとも呼ばれる)アーキテクチャは、静的なコンテンツだけではなく、お客様が一歩進んでウェブページ全体をキャッシュできるように設計されており、トラフィックをさらに効率的に処理します。

    キャッシュの管理

    キャッシングはサイトを高速に配信するための強力な武器となります。ただし、キャッシュ内のオブジェクトが永続的にそこにとどまるわけではありません。新しいコンテンツを配信できるように期限切れにする必要があります。そのコンテンツがキャッシュに残っているべき期間はほんの数秒、または数分、1年以上かもしれません。

    どのコンテンツをキャッシュして、どこで、どのくらいの期間保持するかはどのように管理すればよいでしょうか?ポリシーを設定することで、キャッシュされたデータを制御することが出来ます。 ほとんどのキャッシュポリシーは、Web サーバーによってコンテンツと共に送信される( Web サーバーの設定、またはアプリケーションで指定されている)一連の HTTP ヘッダーの内容をもとに設定されます。これらのヘッダーはクライアント(ブラウザ)を考慮して設計されていますが、 Fastly のような CDN もこれらのヘッダーをキャッシュポリシーのガイドとして使用します。

    Expires ヘッダー

    Expires ヘッダーは、コンテンツをキャッシュ(通常はブラウザーのキャッシュ)する時間を伝えるキャッシュ関連の HTTP ヘッダーです。Expires に指定された日時以降に、ブラウザはコンテンツをサーバーに再度リクエストします。欠点はそれが静的な日付であるため、サーバー側で更新を行わなかった場合、指定された日時を過ぎると、ブラウザは毎回リクエストを送信することになります。

    Fastly ではリクエストヘッダーの中に次の項目で説明するヘッダーが見つからない場合、Expires ヘッダ値をキャッシュの TTL として利用します。

    Cache-Control ヘッダー

    (HTTP 1.1仕様で導入された) Cache-Control ヘッダーは、ブラウザと、エンドユーザーとオリジンの中間にあるキャッシュサーバーで動作します。:

    max-age s-maxageprivate Cache-Control ヘッダーだけが Fastly のキャッシュの TTL に影響します。他のすべての Cache-Control ヘッダーはキャッシュに影響は与えずに、そのままブラウザに渡されます。Fastly がこれらのヘッダーをどのように取り扱うか、また Expires および Surrogate-Control ヘッダーとどのように相互作用するかについては、キャッシュコントロール チュートリアルを参照してください。

    Surrogate (サロゲート)ヘッダー

    サロゲートヘッダーは、比較的新しくキャッシュ管理のためヘッダーとして追加されました。詳細は W3C テクニカルノートに記載されています。これらのヘッダーは、処理パス内のプロキシキャッシュのための特定のキャッシュポリシーを提供します。Surrogate-ControlCache-Control に設定可能なほとんどの値の他に、より複雑な動作を指定する値が設定可能です。オプションの詳細についてはテクニカルノートを参照して下さい。

    Surrogate ヘッダーを利用すると、ブラウザに慎重なキャッシュの取り扱いをさせることが出来ます。例えば Cache-Control:no-cache を利用する場合、ブラウザはコンテンツが必要になる度に、コンテンツが更新されていないか再度確認を行います。これにより、ユーザーには常に最新のコンテンツが表示されます。同時に Surrogate-Control ヘッダーに長い max-age を設定することで、オリジンソースの前にあるプロキシキャッシュがブラウザからのトラフィックのほとんどを処理し、プロキシのキャッシュが期限切れになった場合にのみオリジンソースにコンテンツをリクエストします。

    Fastly で利用可能な Surrogate ヘッダーで、最も便利なヘッダーの一つが Surrogate-Key です。Fastly がリクエストを処理し Surrogate-Key ヘッダーを見つけると、スペースで区切られた値をタグのリストとして使用し、キャッシュ内のリクエスト URL に関連付けます。Fastly's Purge API と組み合わせると、該当のタグがつけられた全ての URL を1回の API コールでキャッシュから(通常は約1ミリ秒程度で)無効化することが出来ます。なお、 Surrogate-Control は最も優先されるキャッシュの指定方法となります。

    Fastly と Cache Control ヘッダー

    Cache-Control ドキュメントで説明されているように、Fastly はヘッダーの値を次のような優先順位でキャッシュ情報として利用します。

    オリジンシールド

    キャッシュしたオブジェクトに設定された有効期限が経過した後に、それらのオブジェクトに対して次のリクエストを受けると、そのリクエストはオリジンサーバーに送られます。正しくキャッシュ設定が行われている場合、この処理で問題は発生しません。 ただし、人気のあるオブジェクトが一斉にキャッシュ期限切れになると、キャッシュノードがオリジンからオブジェクトを再取得するために、バックエンドに大量のトラフィックが流入する可能性があります。

    ほとんどの場合、フェッチされるオブジェクトはリクエストごとに異なるわけではないので、すべてのキャッシュノードがバックエンドからそれぞれコピーを取得する必要はありません。オリジンシールドを利用すると、シールドノードがオリジンのアプリケーションからコンテンツを取得する唯一のノードになります。キャッシュ内のオブジェクトが期限切れになった場合、他のすべてのキャッシュノードはシールドノードからオブジェクトを取得するため、オリジンでのトラフィックが大幅に削減されます。 オリジンシールドの設定は、Fastlyのコントロールパネルから、特定のデータセンター(オリジンアプリケーションに地理的に近いものが最も有効)を指定することで行います。

    そのリソース

    Back to Top