導入
同じデータへの問い合わせが繰り返されるなら、データベースまで毎回行かせる必要はありません。SAPでは、データの種類とアクセス層に応じて**複数のキャッシュを重ねる（多層キャッシュ）**発想が問われます。
説明
flowchart LR
U["利用者"] --> CF["CloudFront<br/>エッジキャッシュ<br/>（静的コンテンツ・APIレスポンス）"]
CF --> APP["アプリケーション層"]
APP --> EC["ElastiCache<br/>汎用インメモリキャッシュ<br/>（セッション・クエリ結果）"]
APP --> DAX["DAX<br/>DynamoDB専用キャッシュ"]
EC --> RDS["RDS/Aurora"]
DAX --> DDB["DynamoDB"]
| キャッシュ | 位置 | 得意なこと |
|---|---|---|
| CloudFront | 利用者に最も近いエッジ | 静的アセット、頻繁に変わらないAPIレスポンス |
| ElastiCache（Redis/Memcached） | アプリケーションとDBの間 | セッション管理、頻出クエリ結果のキャッシュ |
| DAX（DynamoDB Accelerator） | DynamoDBの目の前 | DynamoDBへの読み取りをマイクロ秒単位に高速化、コード変更が最小限 |
ElastiCacheはRedisとMemcachedの2つのエンジンを選べます。
| エンジン | 特徴 |
|---|---|
| Redis | レプリケーション・永続化・複雑なデータ構造（リスト/セット/ソート済みセット）に対応、クラスターモードで水平分割可 |
| Memcached | よりシンプルなキー・バリューのみ、マルチスレッドでの水平分割が容易 |
- 「DynamoDBへの読み取りをアプリ変更を最小限に高速化したい」→ DAX
- 「セッション情報を複数のAPIサーバー間で共有したい」→ ElastiCache（Redis）
- 「世界中の利用者に画像・動画を低レイテンシーで届けたい」→ CloudFront
読んでみよう
キャッシュは「どの層で」「何のために」を切り分けて考えるのがコツです。**エッジ（CloudFront）・アプリ層（ElastiCache）・DB直前（DAX）**という3段構えを意識すると、SAPの複合的な性能問題も層ごとに分解して解けます。