本文へスキップ
BecomeCoder

AWS SAA（ソリューションアーキテクト）コース　·　第9章　高性能・スケーラビリティの設計　·　レッスン51

キャッシュ戦略

導入

同じデータを毎回オリジンサーバーやデータベースまで取りに行くのは無駄です。一度取得した結果を手元に置いておき、次回はそこから即座に返す——これが キャッシュ です。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） や無効化の仕組みを組み合わせます。

具体例

ニュースアプリの1回のアクセスが、複数のキャッシュ層をどう通るか追ってみましょう。それぞれ別の負荷を肩代わりしています。

  1. トップページの画像・CSS・記事本文（静的）→ CloudFront … 世界中のエッジにキャッシュ済み。遠い国のユーザーも近い拠点から即座に受け取り、オリジンまで届かない。
  2. 「アクセスランキング」の集計結果（全員に同じ）→ ElastiCache … 毎回DBで重い集計を走らせず、数分間キャッシュ。DBの読み取り負荷が激減。
  3. ユーザーごとの「おすすめ記事」（DynamoDB管理）→ DAX … 読み取りが集中するので、DynamoDBの前にDAXを置きマイクロ秒で返す。

こうしてほとんどのリクエストがオリジン（DBやアプリ）まで届かず、少ないサーバーで大量アクセスをさばけます。効果はキャッシュヒット率で測り、更新が多いデータにはTTLを短く設定して古さとのバランスを取る。「静的の世界配信＝CloudFront、DB読み取り軽減＝ElastiCache、DynamoDB高速化＝DAX」と層ごとに結びつけます。

読んでみよう

「静的コンテンツの配信を高速化したい／世界中のユーザーに配りたい」→CloudFront、「データベースへの読み取り負荷を減らしたい」→ElastiCache、「DynamoDBの読み取りをマイクロ秒レベルで高速化したい」→DAX、と役割ごとに即座に結びつけられるようにしておきましょう。

次のレッスンへ →