AWS Certified Solutions Architect - Associate (SAA-C03) #10 Domain 3-2 高性能アーキテクチャ — キャッシング
#9 コンピューティングの選択 に続いて、高性能ドメインの 2 つ目の手段である キャッシング を扱います。キャッシングは「同じデータを繰り返し高いコストで取得するのではなく、近い場所に保存しておいて速く取り出そう」という原理です。SAA では どこにキャッシュするか (アプリケーションのそばのインメモリ vs ユーザーに近いエッジ) でサービスが分かれます。
ElastiCache — インメモリデータキャッシュ #
ElastiCache は マネージドのインメモリキャッシュ です。データベースの前に置いて繰り返しの照会の負荷を吸収し、応答をマイクロ秒~ミリ秒に引き上げます。2 つのエンジンがあり、その違いが試験によく出ます。
| 項目 | Redis | Memcached |
|---|---|---|
| 永続性 (persistence) | 対応 | なし |
| 複製・Multi-AZ | 対応 (高可用性) | なし |
| データ構造 | 多様 (list, set, sorted set, pub/sub) | 単純な key-value |
| マルチスレッド | いいえ | はい |
| バックアップ/スナップショット | 対応 | なし |
- Redis — 永続性・複製・Multi-AZ・バックアップ・豊富なデータ構造が必要なら Redis です。セッション保存、リーダーボード、pub/sub などの高度な機能に適しています。
- Memcached — 単純な key-value キャッシュであり、マルチスレッドで水平拡張 (シャーディング) し、永続性・複製が不要なときに適しています。
「高可用性/永続性/複製が必要なキャッシュ」は Redis、「単純・マルチスレッドのキャッシュ」は Memcached で答えます。
キャッシュ戦略 #
- Lazy Loading (遅延ロード) — キャッシュになければ (miss) DB から読み込んでキャッシュに充填します。実際にリクエストされたデータだけがキャッシュされますが、最初のリクエストは遅く、古いデータが残ることがあります。
- Write-Through — データを書き込むときにキャッシュも一緒に更新します。キャッシュは常に最新ですが、使われないデータまでキャッシュされることがあります。
- TTL — キャッシュ項目に有効期限を設けて古いデータを自動的に削除します。
DAX — DynamoDB 専用の高速化 #
DynamoDB Accelerator (DAX) は DynamoDB の前に置く インメモリキャッシュ で、読み取り応答をミリ秒から マイクロ秒 に下げます。重要な点は DAX が DynamoDB 専用 だということです。RDS や他の DB のキャッシュとしては使えません。「DynamoDB の読み取りをマイクロ秒に」という手がかりなら DAX です。
CloudFront — エッジコンテンツキャッシュ (CDN) #
CloudFront は世界中の エッジロケーション にコンテンツをキャッシュして、ユーザーと 物理的に近い場所 から応答させる CDN です。ElastiCache がアプリケーションのそばのキャッシュなら、CloudFront は ユーザーに近いキャッシュ です。
- オリジン (Origin) — S3、ALB、または外部サーバーを元として置きます。
- 効果 — レイテンシの低減 + オリジン負荷の軽減。静的コンテンツだけでなく動的コンテンツも高速化します。
- OAC (Origin Access Control) — S3 オリジンを CloudFront からのみアクセスできるようにロックし、バケットの直接公開を防ぎます。
- 署名付き URL/Cookie — 特定のユーザーにのみコンテンツへのアクセスを許可します。
- エッジロジック — CloudFront Functions / Lambda@Edge でエッジでリクエストを変形します。
「世界中のユーザーに レイテンシを減らして コンテンツを配信」「オリジン負荷を減らせ」「S3 を直接公開せずに配信」という要件なら CloudFront です。
CloudFront vs Global Accelerator #
どちらもユーザー体験を速くしますが、方式が異なります。
| サービス | 方式 | 適する |
|---|---|---|
| CloudFront | コンテンツをエッジに キャッシュ | 静的/動的な Web コンテンツの配信 |
| Global Accelerator | キャッシュなしで AWS バックボーンへルーティング | 非 HTTP (TCP/UDP)、固定 IP、速い障害切り替え |
キャッシングが核心なら CloudFront、「キャッシングではないがグローバルネットワーク経路の最適化・固定 anycast IP」が必要なら Global Accelerator です。
stateless のためのセッションの外部保存 #
#6 Auto Scaling でインスタンスが頻繁に増減しました。セッションをインスタンスのメモリに置くと、そのインスタンスが消えるときにセッションも消えます。そのためセッションを ElastiCache (Redis) のような外部ストレージ へ逃がして、アプリケーション層を stateless にします。こうすると、どのインスタンスがリクエストを受けても同じセッションを読みます。
試験の出題パターン #
- 「世界中のユーザーに コンテンツを近く、レイテンシ低減。」 → CloudFront
- 「DB の 読み取り負荷を低減、インメモリキャッシュ。」 → ElastiCache
- 「永続性/複製/Multi-AZ のキャッシュ。」 → Redis
- 「単純・マルチスレッド のキャッシュ、永続性不要。」 → Memcached
- 「DynamoDB の読み取りをマイクロ秒 に。」 → DAX
- 「セッション状態 を外部保存して stateless。」 → ElastiCache (Redis)
- 「S3 を直接公開せずに CDN 配信。」 → CloudFront + OAC
よく出会う落とし穴 #
1) Memcached に永続性・複製があると思う #
永続性・複製・Multi-AZ・バックアップは Redis です。Memcached は単純なキャッシュです。
2) CloudFront と ElastiCache を混同する #
CloudFront は ユーザーに近いエッジ CDN、ElastiCache は アプリケーションのそばのインメモリキャッシュ です。解く問題が異なります。
3) DAX を RDS のキャッシュに使う #
DAX は DynamoDB 専用 です。リレーショナル DB のキャッシュは ElastiCache です。
4) CloudFront で非 HTTP トラフィックを高速化しようとする #
CloudFront は Web コンテンツのキャッシングです。TCP/UDP の一般トラフィックの経路最適化は Global Accelerator です。
まとめ #
この記事で押さえたこと:
- ElastiCache — インメモリキャッシュ。Redis (永続性・複製・Multi-AZ) vs Memcached (単純・マルチスレッド)
- DAX — DynamoDB 専用のマイクロ秒キャッシュ
- CloudFront — エッジ CDN。レイテンシ低減 + オリジン負荷の軽減。OAC で S3 を保護
- CloudFront vs Global Accelerator — キャッシング vs ネットワーク経路の最適化
- セッションを ElastiCache に外部保存 してアプリケーションを stateless に
次へ — Domain 3-3 ストレージの選択 #
キャッシングを押さえたので、次は データをどこにどんなストレージで置くのか です。
#11 Domain 3-3 ストレージの選択 では、ブロック (EBS)・ファイル (EFS・FSx)・オブジェクト (S3) の区分、EBS ボリュームタイプ、EFS と FSx (Windows・Lustre) の用途、そして S3 ストレージクラス (Standard・Intelligent-Tiering・IA・Glacier) とライフサイクルポリシーを整理します。