APIのキャッシュについて
KurocoのAPIキャッシュについて
Kurocoでは従量課金で費用がかかるため、メディアサイトなど多量のリクエストが見込まれる用途でご利用される場合は、キャッシュの設定をすることを推奨します。キャッシュを正しく設定することによってレスポンス性能も向上し、同時にコストも抑えられます。
KurocoではAPI毎やエンドポイント毎に、細かくキャッシュを設定出来ます。
キャッシュの設定を検討する
エンドポイント一覧画面の「7日間の利用状況」を見るとエンドポイント毎にキャッシュの利用状況を確認できます。
スラッシュ区切りになっている部分の各数値の意味は以下の通りです。
(APIリクエスト数) / (キャッシュされたAPIリクエスト数) / (平均レスポンスサイズ) / (平均実行時間)
APIリクエスト数に対して、キャッシュされたAPIリクエスト数が極端に低い場合はキャッシュの設定を見直しましょう。
また、「利用状況画面」を確認すると月別・日別での「APIリクエスト」「キャッシュされたAPIリクエスト」が金額で出来ます。 詳しくは以下をご参照ください。 利用状況
APIのレスポンスがキャッシュされたものどうか確認する方法
APIのレスポンスがキャッシュされたものどうか確認するにはレスポンスヘッダの以下の項目を確認してください。
x-cache
x-cacheはオブジェクトがキャッシュヒットしたかキャッシュミスしたかを表します。
ヒットした場合は HIT
、ヒットしなかった場合はPASS
またはMISS
を返します。
age
age
は、キャッシュされてからの秒数を表します。
x-cache-hits
X-Cache-Hits はキャッシュされたオブジェクトがヒットした回数を表します。
キャッシュ期間の設定方法
Kurocoでは、各エンドポイント毎にキャッシュ期間の設定をします。
エンドポイント一覧の各エンドポイントの「設定」をクリックします。
設定モーダルの「キャッシュ」欄にキャッシュ時間(秒)を入力します。
「更新」をクリックします。
キャッシュ期間は1日・1週間等をお勧めしております。
追加・更新・削除などを行うエンドポイントにはキャッシュ設定欄はありません。
最大値は1年間(31557600秒)になっております。
Stale-While-Revalidate / Stale-If-Error
Kurocoではキャッシュ取得の効率化やエラー時のキャッシュ再利用の設定が可能です。
Stale-While-Revalidateはキャッシュが無効になってもセットされている秒数の間キャッシュを保持して、新しいキャッシュがセットされるまで古いキャッシュを返し続けます。これにより、キャッシュクリア時の負荷や必要のないアクセスを減らすことができます。
Stale-If-Errorはキャッシュが無効になってもセットされている秒数の間キャッシュを保持して、オリジンがエラーを返した場合などに代わりに古いキャッシュを返します。これによりエラーが発生しづらいAPIレスポンスを構築することができます。
キャッシュのクリア
コンテンツ・メンバー等、取得対象のデータに更新があった場合、キャッシュは自動的にクリアされます。
また、以下の方法でキャッシュを強制的にクリア出来ます。
エンドポイント毎のキャッシュクリア
エンドポイント毎のキャッシュをクリアするには、エンドポイント一覧の下記のボタンをクリックします。
キャッシュ時間の設定を行なっていないエンドポイントには、このボタンは表示されません。
API毎のキャッシュクリア
APIに含まれる全てのエンドポイントのキャッシュをクリアするには、エンドポイント一覧の下記のボタンをクリックします。
キャッシュ単位について
同じ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アドレス毎にキャッシュが生成されます。
管理画面のアクセス制限(IPアドレス)
以下のように管理画面のアクセス制限(IPアドレス)が設定されている場合は、クライアントのIPアドレス毎にキャッシュが生成されます。
関連項目
サポート
お探しのページは見つかりましたか?解決しない場合は、問い合わせフォームからお問い合わせいただくか、Slackコミュニティにご参加ください。