API キャッシュコントロールの実装

このガイドでは、API キャッシュコントロールの実装方法について説明します。API キャッシュを有効にし、キャッシュされたデータでパージが正しく機能した場合、Cache-Control や Surrogate-Control など、特定のヘッダーを設定して、データがキャッシュされたときに変更することができます。

Cache-Control ヘッダーの仕組み

一般的に、GET リクエストはキャッシュされ、PUT、POST、DELETE リクエストはキャッシュされないと考えられます。理想的な REST API では、このルールが適用されます。しかし実際のところ、API の大部分では、一部のリクエストに追加のキャッシュルールが必要になります。

そのため、API を Fastly に移行する際に Cache-Control ヘッダーを設定することをお勧めします。RFC 7234 (HTTP 仕様) で定義されている Cache-Control には、キャッシュされたデータの適切な処理に関する、多くの異なるオプションが含まれます。具体的には、Cache-Control ヘッダーは、ユーザーエージェント (Web ブラウザなど) にサーバーレスポンスのキャッシュをどのように処理するかを伝えます。例:

• Cache-Control: private
• Cache-Control: max-age=86400

1つ目の例の private は、この情報は単一のユーザー特有のものであり、他のユーザーではキャッシュされるべきではないことを、ユーザーエージェントに伝えます。2つ目の例の max-age=86400 は、レスポンスのキャッシュは可能である一方、86,400秒 (1日) で有効期限が切れることをユーザーエージェントに伝えます。

Fastly は Cache-Control ヘッダーに従うようにデフォルト設定されていますが、別のプロキシ固有ヘッダーである Surrogate-Control ヘッダーを利用することもできます。Cache-Control ヘッダーに似ている Surrogate-Control ヘッダーは、Fastly のようなリバースプロキシキャッシュに指示を与えることができます。Cache-Control ヘッダーと Surrogate-Control ヘッダーは、併せて使用することができます。Cache-Control ヘッダーと Surrogate-Control ヘッダーの詳細については、キャッシュデータのフレッシュネスのドキュメントをご確認ください。

更新された例

前回ご紹介したコメント API の例で Cache-Control ヘッダーを使用する方法を説明します。特定の記事のコメントリストを提供する API エンドポイントがこちらです。

GET /article/:article_id/comments

ユーザーが記事へコメントを投稿すると、このエンドポイントからのレスポンスは、コメントモデルにより、Fastly キャッシュからパージされます。コンテンツが変化するタイミングを予測するのは困難です。そのため、以下のポイントを守ることが重要です。

1. コンテンツに変更がなければ、コンテンツが Fastly に適切な期間キャッシュされること。
2. コンテンツに変更があれば、必要以上にクライアントによりキャッシュされないこと。

目的は API レスポンスがクライアントにタイムリーに届くことですが、クライアントに最新の情報を届けることも同じく重要です。1つ目のポイントは、Surrogate-Control ヘッダー、2つ目のポイントは、Cache-Control ヘッダーを使用することによって解決できます。

Surrogate-Control: max-age=86400
Cache-Control: max-age=60

これらのヘッダーは、コンテンツのキャッシュが最大1日間可能であることを Fastly に伝えます。さらに、コンテンツは60秒間キャッシュ可能で、60秒後には元のソース (この場合は Fastly キャッシュ) に戻るべきであるとクライアントに伝えます。

キャッシュコントロールの実装

API の移行は、経験豊富なチームにとっても容易な作業ではありません。API を Fastly に移行する際、タスクを3つの戦略的なエンドポイント移行に分けることをお勧めします。それにより、API 全体の有効性を保持すると同時に、移行プロセスの管理をより円滑に進めることが可能です。

API の準備

部分的な移行中に API にキャッシュを回避させるために、API エンドポイントのすべてが特定のコントロールヘッダーを返す必要があります。

Cache-Control: private

このヘッダーは、API 上のエンドポイントへのリクエストがキャッシュを回避してオリジンに直接送られることを Fastly に伝えます。これにより、Fastly を介して API を配信し、予定通りに機能させることができます。

Fastly でトラフィックを配信

次のステップでは、API のトラフィックを配信する Fastly サービスを設定します。設定を保存すると、すぐ速度に改善がみられるはずです。これは、Fastly のキャッシュサーバーが API のオリジンサーバーへの長期接続を保持し、複数の TCP 接続の確立による待ち時間のレイテンシオーバーヘッドを減少させるためです。

エンドポイントの移行

これで、キャッシュ可能な API エンドポイントごとに、キャッシュのインスタントパージを1つずつ実装できます。これが行われる順序は API により異なりますが、まず最も遅いエンドポイントを最初に行うことにより、最も改善が必要なエンドポイントを劇的に改善することができます。各エンドポイントに個別に対応できるため、エンジニアリングプロセスが容易になります。

エンドポイントの除外

最後のステップは、Fastly にキャッシュして欲しくない API エンドポイントの決定です。エンドポイントのキャッシュを無効化するには、エンドポイントの新しい条件を追加する必要があります。API の準備で学んだとおり、Cache-Control: private ヘッダーを使用することでキャッシュを無効にすることもできます。