最初に分けるのは、公開情報と個別の応答
会社紹介の画像と、ログイン後の個人情報では、公開範囲やキャッシュの方針を分けて検討します。URLだけでなく、認証状態、問い合わせ内容、更新頻度を並べ、どの応答を複数の利用者で共有できるかを確認します。
エッジでのキャッシュは、保存済みの応答を再利用する仕組みです。利用者固有の内容を含む場合は、キャッシュを使わない経路やキーの設計を含めて、意図しない共有を防ぐ方針を決めます。
ファイルの性質から、更新方法を選ぶ
| ファイルの性質から、更新方法を選ぶ | 公開画像・スタイル | 更新するページ | 利用者ごとの応答 |
|---|---|---|---|
| 先に確かめること | 同じURLの内容を差し替えるか | 情報をいつ切り替える必要があるか | 認証やリクエストによって内容が変わるか |
| 設計する項目 | 版を含むファイル名と参照元 | 保存時間と更新時の確認方法 | キャッシュの可否と応答を分ける条件 |
| 公開前の見方 | 新しい資産が取得できるか | 本文と参照資産の版がそろうか | 別の利用者へ情報が混ざらないか |
資産を先に置き、ページを切り替える
- 公開する版をそろえる
ページと参照する画像・スタイルを一覧にし、旧版へ戻す場合の組み合わせも記録します。
- 参照先の資産を先に確認する
版を付けたファイルを配置する案では、そのURLで実体を取得できることを確かめてからページを切り替えます。
- 利用者と同じURLで確認する
更新直後だけでなく、想定する保存時間やキャッシュ更新の扱いに沿って確認します。戻す必要があれば、ページと資産の対応を維持して復旧します。
キャッシュキーを決める前の確認項目
- 応答を変える条件
- 言語、クエリ、Cookie、ヘッダーのうち、実際に内容へ影響するものを洗い出します。不要な条件まで分けると再利用の機会が減ります。
- 保存時間の優先関係
- CloudFrontの最小TTLが0より大きい場合は、オリジン側のno-cache・no-store・privateより保存が優先されるため、組み合わせを確認します。
- 障害時の表示
- 取得失敗や古い参照先が残った場合に、利用者が再読み込みや戻る操作を選べる表示を用意するか検討します。
配信の設計で迷いやすいこと
キャッシュを長くすれば、すべてのページに適していますか。
更新の頻度や公開範囲によって適切な扱いは異なります。長く保存する資産と、早く更新したい本文を分け、許容できる古さを決めてから設定します。
URLを変えずに画像を更新できますか。
同じURLでも更新はできますが、キャッシュに旧版が残る場合を考慮する必要があります。版を含むURLへ変える案と、既存URLのキャッシュを更新する案を比較し、参照元を含む手順を決めます。