キャッシュとは？

キャッシュとは、リクエストされたデータをより迅速に提供するために一時的にデータを保存する場所を指します。このようにデータを保存するプロセスを Caching と表現します。cache という言葉は IT 以外のコンテキストでも使用されることがあります。たとえば英語では、キャンプやハイキングをする人がトレイルに沿って見えない場所に食料を保存する行為を表現するのに「cache」という単語が使われます。キャッシュは、便宜のために何かを保存する場所と考えてください。

Web サイトを閲覧するユーザーは Web サイトのレンダリングに必要なすべてのデータアセットにローカルアクセスできることが理想的です。しかし、実際にはこのようなアセットはデータセンターやクラウドサービスなど、別の場所に保存されているため、アセットを取得するのに費用がかかります。ユーザー側では、リクエストしたアセットの生成と読み込みにおいてレイテンシが発生します。サイト所有者側では、コンテンツをホストするのに費用がかかるだけでなく、リクエストされたコンテンツをストレージから送信する際にデータ送信コストが発生します。Web サイトへのトラフィックが増えるほど、リクエストに応答するためにコストも増大します。同じコンテンツに対するリクエストでも、その都度コストが発生します。

キャッシュ機能により、コンテンツのコピーを保存してコンテンツ配信を高速化すると同時にコストを削減できます。

キャッシュの仕組み

キャッシュの仕組みを理解するには、HTTP リクエストとレスポンスの仕組みを理解する必要があります。ユーザーがブラウザで Web サイトの URL を入力すると、リクエストがブラウザ (クライアント) からコンテンツの保存場所 (オリジンサーバー) に送信されます。オリジンサーバーはリクエストを処理し、レスポンスをクライアントに送信します。

このプロセスは瞬間的に行われるかのように見えますが、実際にはオリジンサーバーがリクエストを処理し、レスポンスを生成してクライアントに送信するのに時間がかかります。また、Web サイトを構成するあらゆるデータ (画像、HTML Web ページ、CSS ファイルなど) へのリクエストを含め、Web サイトを表示するにはさまざまなリクエストが必要です。

そこで、ローカルキャッシュの出番です。ユーザーのブラウザは、次回サイトにアクセスしたときのパフォーマンスを向上させるために、ロゴ入りのヘッダー画像やサイトのスタイルシートなど、静的アセットの一部をユーザーのコンピューターにキャッシュする場合があります。しかし、このようなキャッシュは1人のユーザーにのみ役立ちます。

サイトにアクセスするすべてのユーザーが利用できるようアセットをキャッシュするには、リバースプロキシのようなリモートキャッシュの使用を検討することができます。リバースプロキシは、クライアントとオリジンサーバーの間に配置され、オリジンサーバーの代わりにリクエストを受信してレスポンスを返すアプリケーションです。リバースプロキシは、Web サイトをホストしているオリジンサーバーまたは別のサーバーにインストールすることができます。リバースプロキシは、オリジンサーバーからコンテンツを取得してキャッシュし、後続のリクエストにキャッシュからコンテンツを返します。

HTTP ヘッダーは、クライアントとオリジンサーバーの間でリクエストとレスポンスの情報を渡すために使用されます。レスポンスに特定の HTTP ヘッダーを設定して、キャッシュされるコンテンツと保存期間をコントロールすることができます。リバースプロキシを使用する場合、リバースプロキシは中継役として機能し、オブジェクトのキャッシュプロセスをコントロールするためにオリジンサーバーから送信された特定のヘッダーを削除し、別のヘッダーを追加してクライアントにレスポンスを返します。リソースをキャッシュする期間をコントロールする方法の詳細については、キャッシュの鮮度に関するドキュメントをご参照ください。

リバースプロキシでキャッシュするメリット

リバースプロキシ経由でリモートキャッシュすることで、アセットのコピーを保存し、あらゆるユーザーからの後続のリクエストに対して、アセットが生成されるのを待つことなく即座に配信することができます。すでに生成された資産をキャッシュすると、オリジンサーバーが余分な作業を行う必要がなく、その資産に対するリクエストが即座に応答することができます。これにより、ユーザーのエクスペリエンスが向上し、オリジンへのトラフィックの支払いが不要なため、コストを削減することができます。オリジンはまだ一部のリクエストを処理する必要がありますが、処理できるリクエスト数は少なくなります。また、リバースプロキシは、レスポンスを送信する前に HTTP データを圧縮することができます。これにより、配信の高速化が可能になります。

リバースプロキシがレスポンス時間を最適化する方法は、コンテンツの需要を分散することです。Web サイトの人気が急上昇し、同時に何千ものリクエストが発生し始めた場合、オリジンサーバーが過負荷になり、Webサイトがクラッシュする可能性があります。キャッシュからコンテンツを配信することで、そのトラフィックがすべて一度にオリジンに到達するのを防ぐことができます。複数の送信元オリジンがある場合、リバースプロキシはそのサーバーの間でリクエストを分散することができます。Web サイトがダウンした場合、ユーザーはキャッシュされたコンテンツにアクセスできるため、ダウンタイムが発生する必要はありません。

Fastly を選んだ理由

Fastly のような CDN サービスは、リバースプロキシですが、規模がより大きくなります。コンテンツの生成と読み込み時間は、クライアントがリクエストに対してレスポンスを受信するスピードに影響を及ぼす要因だけではありません。クライアントとオリジンの物理的な距離は、レスポンス時間も増加します。CDN は、クライアントとオリジンサーバーの間にあるキャッシュサーバーのネットワーク全体で構成されています。ネットワーク内の各キャッシュサーバーは、オリジンからコンテンツをキャッシュし、最も近いクライアントからのリクエストに応答します。

FastlyのCDNネットワークを使用すると、コンテンツを効率的にキャッシュして配信することができます。配信拠点 (POP) の戦略的かつ地理的分散により、キャッシュをユーザーの近くに配信することができます。

Fastly は、Varnish Cache リバースプロキシを高速かつ高度にカスタマイズ可能な基盤となるアーキテクチャとして使用します。CDN に関するガイドでは、予測不可能な性質のため、イベント駆動型コンテンツをキャッシュすることが困難であることについて説明します。しかし、Fastly ではこのようなコンテンツをキャッシュし、コンテンツが変更されたときにプログラムでパージすることができます。

コンテンツをキャッシュする方法に関係なく、コンテンツがどの程度うまく機能しているかを監視することが重要です。一般的に、キャッシュミスよりも多くのキャッシュヒットを表示したいと考えています。キャッシュヒットは、リクエストされたコンテンツがキャッシュ内で見つかったということです。キャッシュミスは、リクエストされたコンテンツがキャッシュ内で見つからないため、オリジンから取得する必要があるということです。Fastlyでは、この情報を手動で追跡できますが、リアルタイム分析ダッシュボードを使用して、キャッシュヒットやミスなどの統計情報を簡単に追跡することができます。

Fastly では、自動的に計算するより便利な統計情報の1つが、キャッシュヒット率です。一般的に、キャッシュヒット率 (CHR) は、キャッシュサーバーが配信するリクエストの割合 (ヒット + ミス) とは、すべてのリクエスト (ヒット + ミス) に対するものです。キャッシュヒット率が高いと、リクエストトラフィックが不要なオリジンに到達するのを防ぐため、キャッシュヒット率をできるだけ高くする必要があります。リアルタイム統計を監視することで、キャッシュ設定を調整して、ミス以上のヒット数を増やすことができます。また、別の統計情報をいくつか監視して、トラフィックをキャッシュする場所、サイトのキャッシ容量、サイトで配信されているエラーなどを確認することもできます。

今後の展望

CDN を使用して大規模なキャッシュする方法と、キャッシュされたコンテンツをパージする理由と方法については、基本ガイドをご参照ください。

コンテンツのキャッシュを開始する準備ができたら、自身のサービスで使用できるキャッシュを設定する実例について、Fastly の CDN の紹介チュートリアルを確認してください。また、キャッシュ設定のベストプラクティスを確認することもおすすめします。Fastly のリアルタイム統計および履歴統計の詳細と、それらを利用してサービスをモニタリングする方法については、Observability ページをご参照ください。

Fastly アカウントをすでにお持ちですか？アカウントの作成は無料です。最大50米ドル分のトラフィックを無料で試すことができます。