パフォーマンス向上とバックエンドの負荷軽減を両立させる基本戦略がキャッシュです。本記事では、階層ごとのキャッシュサービスと、その使い分けを整理します。

SAA レベル：基礎概念

キャッシュサービスの役割分担

サービス	キャッシュ対象	主な用途
ElastiCache (Redis/Memcached)	アプリケーションデータ全般	セッション管理、DB問い合わせ結果のキャッシュ
DAX (DynamoDB Accelerator)	DynamoDBの読み取り結果	DynamoDB専用のマイクロ秒単位の高速キャッシュ
CloudFront	静的・動的コンテンツ	エッジロケーションでのコンテンツ配信キャッシュ

SAA 試験のポイント

DAXはDynamoDB専用のキャッシュサービスであり、DynamoDB API互換のインターフェースを持つため、アプリケーションコードの変更を最小限にDynamoDBの読み取り性能を向上できます。RDSやその他のデータソースには使えません。

RedisとMemcachedの違い（ElastiCache）

項目	Redis	Memcached
データ構造	リスト、セット、ソート済みセット等、豊富なデータ構造	シンプルなキーバリューのみ
永続化	可能（スナップショット、AOF）	不可
レプリケーション・高可用性	Multi-AZ、レプリケーション対応	非対応（マルチスレッドでのスケールが強み）

SAP レベル：高度な設計シナリオ

キャッシュパターンの選択

SAP 試験のポイント

キャッシュの実装パターンには大きく2種類あります。**Lazy Loading（遅延読み込み）**はキャッシュミス時にDBから読み取ってキャッシュに書き込む方式で、実装がシンプルですが初回アクセス時のレイテンシとキャッシュの陳腐化（Stale Data）が発生し得ます。Write Throughは書き込み時に常にキャッシュも同時更新する方式で、キャッシュは常に最新ですが、書き込みレイテンシが増加し、参照されないデータもキャッシュされ無駄が生じる可能性があります。

パターン	メリット	デメリット
Lazy Loading	シンプル、必要なデータのみキャッシュ	初回アクセス遅延、データの陳腐化リスク
Write Through	キャッシュが常に最新	書き込みレイテンシ増加、不要なキャッシュの発生

設計上の落とし穴

「常にWrite Throughを使えばキャッシュの陳腐化は起きないので安全」という単純な判断は誤りです。SAPレベルでは、読み取り頻度が高く更新頻度が低いデータにはLazy Loading + TTL設定、リアルタイム性が強く求められるデータにはWrite Through、というアクセスパターンに応じた使い分けが問われます。また、両パターンを組み合わせて使うケースも実務では一般的です。

DAXの適用場面とその限界

DAXは書き込みには効果がなく、読み取り性能のみを向上させる（Query/GetItem/BatchGetItemが対象）
Strongly Consistent Read（強い整合性の読み取り）はキャッシュを経由せず直接DynamoDBにアクセスするため、DAXのキャッシュ効果が得られない点に注意

CloudFrontによるオリジン負荷軽減

キャッシュポリシーとオリジンリクエストポリシーを適切に設定し、キャッシュヒット率を最大化する
Origin Shieldを有効化すると、複数のエッジロケーションからのリクエストを集約する追加のキャッシュ層が生まれ、オリジンへのリクエスト数をさらに削減できる
動的コンテンツであっても、TTLを短く設定した上でキャッシュすることで、瞬間的なトラフィックスパイク（フラッシュクラウド）時のオリジン保護に有効

まとめ

SAA: ElastiCache・DAX・CloudFrontの役割分担、RedisとMemcachedの違いを理解する。
SAP: Lazy LoadingとWrite Throughのトレードオフを踏まえたパターン選定、DAXの適用範囲の限界、Origin Shieldによるオリジン保護設計ができる。

次は **サーバーレスアーキテクチャ（Lambda、Step Functions、EventBridge）**を見ていきましょう。