本文へスキップ
BecomeCoder

AWS SAP（ソリューションアーキテクト プロフェッショナル）コース　·　第6章　新規ソリューションの設計②：データストアとデータベース　·　レッスン33

キャッシュとデータ配信 ― ElastiCache / DAX / CloudFront

導入

同じデータへの問い合わせが繰り返されるなら、データベースまで毎回行かせる必要はありません。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

具体例

ニュースメディアの1リクエストが、3層のキャッシュをどう通るかを追うと、多層キャッシュの効果が見えます。

  1. 記事のトップ画像・CSS（静的）→ CloudFront … 世界中のエッジにキャッシュ済みで、DBもアプリも通らず即返る。
  2. 「今日の人気ランキング」（全員に同じ・DBの重い集計）→ ElastiCache（Redis） … アプリとDBの間で結果を数分キャッシュ。RDSへの重いクエリが激減。ついでにログインセッションもRedisで全APIサーバー間共有。
  3. ユーザーごとの「おすすめ記事」（DynamoDB管理）→ DAX … DynamoDBの目の前に置き、読み取りをマイクロ秒に。しかもアプリのコード変更は最小限。

こうして大半のリクエストがDBまで届かず、少ないリソースで大量アクセスを捌けます。ポイントは「どの層で・何のために」を切り分けること。エッジ＝CloudFront、アプリ層＝ElastiCache、DynamoDB直前＝DAX、の3段構えで複合的な性能問題を層ごとに分解できます。

読んでみよう

キャッシュは「どの層で」「何のために」を切り分けて考えるのがコツです。エッジ（CloudFront）・アプリ層（ElastiCache）・DB直前（DAX）という3段構えを意識すると、SAPの複合的な性能問題も層ごとに分解して解けます。

次のレッスンへ →