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 を使用した例

前回ご紹介したコメント 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 ヘッダーを使用することでキャッシュを無効にすることもできます。