キャッシュ戦略が適切に考慮されているか？¶
Type: DeepDive
Category: パフォーマンス・スケーラビリティ
Audience: 設計リーダー / SRE / インフラ設計者 / レビュー担当者
背景・概要¶
キャッシュは読み取り負荷の軽減やレスポンス高速化に有効な戦略。特に一覧APIや参照が多い設定情報、マスターデータなどではキャッシュ有無によって性能が数十倍変わることもある
設計時点で「どこに・何を・どれくらいの有効期限で」キャッシュするか、明示しておくことが望ましい
例¶
- 検索APIのフィルター条件に使用するマスターデータをRedisにキャッシュ、有効期限は1日
- 外部APIから取得するユーザー情報をGCP Cloud Tasksを使って非同期キャッシュ更新
- Cloud CDN・Amazon CloudFront・Azure Front DoorなどのCDNで静的レスポンス（PDFプレビューなど）を配信し、トラフィックを削減
よくある失敗例¶
- 毎回同じマスターデータをDBから取得していて、リスト画面のレスポンスが遅延
- キャッシュ更新タイミングと整合性が曖昧で、古いデータが表示され続ける
- キャッシュにミスヒットし続けて逆に負荷が高くなる（キー不整合など）
FAQ¶
Q. どの層にキャッシュすればいい？
A. 要件に応じて選択する
- クライアント（表示高速化）
- APIサーバー（アプリロジック中の共有）
- DB or KVS（高頻度読み込みの最適化）
Q. TTL(Time to Live)はどれくらいが適切？
A. データの更新頻度・整合性要件に依存。ユーザー権限のような頻繁に変わらないが正確さが重要な情報は短めにし、マスターデータは長めでもOK