Dev Study
AWSサービスの内部原理 コース

44. ステージキャッシュ — 専用キャッシュインスタンスとキャッシュキー

API Gatewayのステージキャッシュを、「実体のあるインスタンス」「TTL」「キャッシュキー」「無効化とフラッシュ」の5つの図で追っていく。

① キャッシュの正体は「実体を持つサーバー」

ステージでキャッシュ有効化容量を選ぶ(0.5GBなど)
容量を変更すると…
cache clusterそのステージ専用の実体サーバー
容量=保存量だけでなく CPU・メモリ・帯域も決まる
既存インスタンスを削除
新容量で作り直しキャッシュ済みデータは全部消える
  • 削除にも作成と同程度(約4分)かかる
  • Lambda編と同じ原理:マネージドサービスの裏には、確保・起動に時間のかかる計算資源の実体がある

ステージのキャッシュ有効化は論理フラグではなく、専用インスタンス(cache cluster)のプロビジョンそのもの。だから作成・削除に時間がかかり、容量変更は「作り直し」になる。

② TTLの間はキャッシュが応答する(既定はGETだけ)

クライアント
TTL内はここで応答(オリジンを呼ばない)→ 呼び出し回数減・レイテンシ低下
ステージキャッシュTTL: 既定300秒 / 最大3600秒 / 0=無効
統合エンドポイント(オリジン)TTL切れ・ミス時だけ到達
  • 既定の対象はGETのみ:同じ入力なら同じ結果を返す安全なメソッドだから。副作用のあるPOSTなどは既定外(メソッド単位のオーバーライドで拡張可)
  • キャッシュはベストエフォート:必ずヒットする保証はない
  • 実際のヒット状況は CloudWatch の CacheHitCount / CacheMissCount で確認

TTLの間、API Gatewayはオリジンを呼ばずにキャッシュから返す。ただしヒットは保証されないベストエフォートで、既定でキャッシュされるのは安全なGETメソッドのみ。

③ キャッシュキー=「何を同じリクエストとみなすか」

①type=admin & department=A
②type=admin & department=B
①(A部門)の応答がキャッシュされ
キャッシュキー: type=admin①も②も同一視 → 1つのエントリ
②(B部門)にもA部門の応答が返る他部門のデータ混入
  • キーに選べるのは、メソッドリクエスト/統合リクエストのパラメータ(クエリ文字列・ヘッダ・URLパス)
  • 少なくとも1つのキー指定が必須
  • HTTPのVaryヘッダと同じ問題:Varyはオリジンが宣言する暗黙の仕組みだが、API Gatewayは設計者に明示的に選ばせる

選んだキーの値だけで応答を区別し、選ばなかった違いは同一視される。応答に影響するパラメータをキーに入れ忘れると、他人(他部門)のデータが混ざる。

④ リクエスト単位の無効化(max-age=0)とIAM保護

クライアントCache-Control: max-age=0
新しい応答で既存のキャッシュエントリを置換
統合エンドポイント(オリジン)最新の応答を返す
キャッシュこのリクエストではスキップ
危険:多数が一斉に使うとオリジンへ集中API全体のレイテンシが跳ね上がる → IAMで保護
  • IAMアクション execute-api:InvalidateCache で無効化権限を保護できる(ポリシー設定 or コンソールの「認可を必須にする」)
  • 権限のない無効化リクエストの扱いは3択:FAIL_WITH_403(403で失敗)/ SUCCEED_WITH_RESPONSE_HEADER(警告ヘッダ付きで処理)/ SUCCEED_WITHOUT_RESPONSE_HEADER(警告なしで無視して処理)

Cache-Control: max-age=0 を付けたリクエストはキャッシュを飛ばしてオリジンから直接応答を受け、その結果で既存エントリを置き換える。HTTP標準の「再検証の強制」をそのまま実装した形だ。

⑤ フラッシュ=盾を一度に外す(cache stampede)

flush-stage-cache統合先の更新後、確実に最新応答を届けたいとき
素通りして
空のキャッシュ直後は全リクエストがミス
オリジンへリクエスト殺到負荷急増・レイテンシが一時的に増える
  • キャッシュ一般で言う cache stampede(空の瞬間にオリジンへ殺到する現象)そのもの
  • 個別無効化(max-age=0)の一斉集中と同じ理由で負荷が跳ねる
  • 盾を一度に外せば、その負荷はまとめてオリジンへ返ってくる

flush-stage-cacheはステージ全体のキャッシュを一気に空にする。直後はすべてがミスになり、キャッシュが再び埋まるまでリクエストがオリジンへ殺到する——キャッシュが「オリジンの盾」であることの裏返しだ。

公式ドキュメントで詳しく ↗