メインコンテンツまでスキップ

APIのキャッシュについて

KurocoのAPIキャッシュについて

Kurocoでは従量課金で費用がかかるため、メディアサイトなど多量のリクエストが見込まれる用途でご利用される場合は、キャッシュの設定をすることを推奨します。キャッシュを正しく設定することによってレスポンス性能も向上し、同時にコストも抑えられます。

KurocoではAPI毎やエンドポイント毎に、細かくキャッシュを設定出来ます。

キャッシュの設定を検討する

エンドポイント一覧画面の「7日間の利用状況」を見るとエンドポイント毎にキャッシュの利用状況を確認できます。
Image from Gyazo スラッシュ区切りになっている部分の各数値の意味は以下の通りです。

(APIリクエスト数) / (キャッシュされたAPIリクエスト数) / (平均レスポンスサイズ) / (平均実行時間)

APIリクエスト数に対して、キャッシュされたAPIリクエスト数が極端に低い場合はキャッシュの設定を見直しましょう。

また、「利用状況画面」を確認すると月別・日別での「APIリクエスト」「キャッシュされたAPIリクエスト」が金額で出来ます。 詳しくは以下をご参照ください。 利用状況

APIのレスポンスがキャッシュされたものどうか確認する方法

APIのレスポンスがキャッシュされたものどうか確認するにはレスポンスヘッダの以下の項目を確認してください。

x-cache

x-cacheはオブジェクトがキャッシュヒットしたかキャッシュミスしたかを表します。 ヒットした場合は HIT、ヒットしなかった場合はPASSまたはMISS を返します。

age

age は、キャッシュされてからの秒数を表します。

x-cache-hits

X-Cache-Hits はキャッシュされたオブジェクトがヒットした回数を表します。

キャッシュ期間の設定方法

Kurocoでは、各エンドポイント毎にキャッシュ期間の設定をします。 エンドポイント一覧の各エンドポイントの「設定」をクリックします。
Image from Gyazo 設定モーダルの「キャッシュ」欄にキャッシュ時間(秒)を入力します。

Image from Gyazo 「更新」をクリックします。

Image from Gyazo キャッシュ期間は1日・1週間等をお勧めしております。
追加・更新・削除などを行うエンドポイントにはキャッシュ設定欄はありません。

最大値は1年間(31557600秒)になっております。

Stale-While-Revalidate / Stale-If-Error

Kurocoではキャッシュ取得の効率化やエラー時のキャッシュ再利用の設定が可能です。
Stale-While-Revalidateはキャッシュが無効になってもセットされている秒数の間キャッシュを保持して、新しいキャッシュがセットされるまで古いキャッシュを返し続けます。これにより、キャッシュクリア時の負荷や必要のないアクセスを減らすことができます。
Stale-If-Errorはキャッシュが無効になってもセットされている秒数の間キャッシュを保持して、オリジンがエラーを返した場合などに代わりに古いキャッシュを返します。これによりエラーが発生しづらいAPIレスポンスを構築することができます。

キャッシュのクリア

コンテンツ・メンバー等、取得対象のデータに更新があった場合、キャッシュは自動的にクリアされます。
また、以下の方法でキャッシュを強制的にクリア出来ます。

エンドポイント毎のキャッシュクリア

エンドポイント毎のキャッシュをクリアするには、エンドポイント一覧の下記のボタンをクリックします。
Image from Gyazo

ヒント

キャッシュ時間の設定を行なっていないエンドポイントには、このボタンは表示されません。

API毎のキャッシュクリア

APIに含まれる全てのエンドポイントのキャッシュをクリアするには、エンドポイント一覧の下記のボタンをクリックします。
Image from Gyazo

キャッシュ単位について

同じURLであってもクライアントの環境によってレスポンスするオブジェクトが異なる場合、サーバ側は異なるキャッシュを保持しています。
例えば HTTP圧縮に対応しているクライアントにはGZIP圧縮したレスポンスを返し、対応していないクライアントには非圧縮コンテンツを返す必要があります。クライアントがHTTP圧縮に対応しているかどうかは Accept-Encoding ヘッダによって判断され、サーバ側は Accept-Encoding の内容によって別々のキャッシュを保持します。

Kurocoがどのリクエストヘッダを参照し、キャッシュを区別しているかはレスポンスヘッダーのVaryを確認します。
例えば、 vary: Host,Accept-Encoding,Accept,Originとなっている場合は以下のリクエストヘッダ別にキャッシュを保持します。

  • Host
  • Accept-Encoding
  • Accept
  • Origin

また、APIのセキュリティ設定によって、以下のリクエストヘッダも参照されます。

静的トークン・動的トークンを利用する場合

例えば、静的トークン・動的トークンを利用する場合は、レスポンスヘッダのvaryにX-RCMS-API-ACCESS-TOKEN が追加されます。
すなわち、静的トークンの場合は同じ環境の全クライアントで共通のキャッシュが生成され、動的トークンの場合はユーザー毎にキャッシュが生成されます。

Cookie認証の場合

Cookie認証を行なっている場合は、レスポンスヘッダのvaryにUser-Agent および Cookie が追加されます。
(ただし、ボットのユーザーエージェントに対しては Cookie を追加しません)。

API単位のIPアドレス制限による

セキュリティ設定によらず、以下のようにAPI単位のIPアドレス制限を設定している場合は、クライアントのIPアドレス毎にキャッシュが生成されます。
Image from Gyazo

管理画面のアクセス制限(IPアドレス)

以下のように管理画面のアクセス制限(IPアドレス)が設定されている場合は、クライアントのIPアドレス毎にキャッシュが生成されます。
Image from Gyazo

関連項目


サポート

お探しのページは見つかりましたか?解決しない場合は、問い合わせフォームからお問い合わせいただくか、Slackコミュニティにご参加ください。