導入
同じデータを毎回オリジンサーバーやデータベースまで取りに行くのは無駄です。一度取得した結果を手元に置いておき、次回はそこから即座に返す——これが キャッシュ です。SAAでは「どの層でキャッシュするか」を使い分ける力が問われます。
説明
AWSのアーキテクチャでは、リクエストの通り道の複数箇所にキャッシュを置くことができます。これを 多層キャッシュ と呼びます。
flowchart LR
U["利用者"] --> CF["CloudFront<br/>（エッジキャッシュ）"]
CF --> ALB["ロードバランサー"]
ALB --> EC["ElastiCache<br/>（DB前段のキャッシュ）"]
EC --> DB["RDS/Aurora"]
ALB --> DAX["DAX<br/>（DynamoDB前段のキャッシュ）"]
DAX --> DDB["DynamoDB"]
| レイヤ | サービス | キャッシュする内容 | 効果 |
|---|---|---|---|
| エッジ（世界中の配信拠点） | CloudFront | 画像・動画・静的コンテンツ、APIレスポンスも可 | 利用者に地理的に近い場所から配信、オリジンの負荷とレイテンシーを削減 |
| アプリ〜DB間 | ElastiCache（Redis / Memcached） | クエリ結果、セッション情報 | データベースへのアクセス回数を減らし、応答を高速化 |
| DynamoDB専用 | DAX（DynamoDB Accelerator） | DynamoDBへの読み取り結果 | マイクロ秒単位の応答、DynamoDB自体への読み取り負荷を削減 |
キャッシュの効果は キャッシュヒット率（要求されたデータがキャッシュに存在した割合）で測ります。ヒット率が高いほど、オリジンやデータベースへの負荷とレイテンシーが下がります。ただし、キャッシュしたデータは元データと食い違う（古くなる）リスクもあるため、更新頻度の高いデータには 有効期限（TTL） や無効化の仕組みを組み合わせます。
読んでみよう
「静的コンテンツの配信を高速化したい／世界中のユーザーに配りたい」→CloudFront、「データベースへの読み取り負荷を減らしたい」→ElastiCache、「DynamoDBの読み取りをマイクロ秒レベルで高速化したい」→DAX、と役割ごとに即座に結びつけられるようにしておきましょう。