目次
1. 結論
Amazon ElastiCacheは、「システムの反応速度を極限まで高めるブースター」です。ディスクベースのデータベース（RDS等）へのアクセスを減らし、メモリ上でデータを処理することで、読み取り性能を劇的に向上させます。高性能な（レスポンスの速い）アーキテクチャを設計する際の第一選択肢です。
2. 高性能アーキテクチャでの役割
- 読み取りの高速化: 頻繁にアクセスされるデータ（ホットデータ）をキャッシュに置くことで、ミリ秒未満のレイテンシーを実現。
- データベースのオフロード: RDSなどのプライマリDBへの負荷を肩代わりし、DB側のリソース不足によるパフォーマンス低下を防ぐ。
- スループットの向上: Redisのリードレプリカを利用することで、毎秒数百万リクエストという膨大な読み取りトラフィックを並列処理できる。
- 計算結果のキャッシュ: 複雑なクエリの実行結果を保存しておくことで、二度目以降のアクセスで計算時間をゼロにする。
3. キーワードでの判断
| 問題文のキーワード | 疑うべきサービス/機能 | 判断理由 |
|---|---|---|
| 「ミリ秒未満の応答時間が求められる」 | ElastiCache | インメモリ処理が必要 |
| 「データベースのCPU使用率が高く、読み取りを高速化したい」 | ElastiCache | キャッシュによる負荷分散 |
| 「リアルタイムのランキング表示（リーダーボード）」 | ElastiCache (Redis) | 高速なソート済みセット機能 |
4. ひっかけポイント
- DAXとの使い分け:
- DAX: DynamoDB専用。アプリのコード変更がほぼ不要。
- ElastiCache: RDSやS3など汎用的。アプリ側でキャッシュロジックの実装が必要。
- Memcached vs Redis: 高性能かつ「高可用性（フェイルオーバー）」を求めるならRedis。
- ライトスルー vs レイジーローディング: パフォーマンスとデータ整合性のトレードオフを理解する。
5. 覚え方
- 「本棚（RDS）ではなく、机の上のメモ帳（キャッシュ）」。
- 毎回本棚まで行くよりも、机の上にあるメモを見る方が圧倒的に速い。
6. 関連サービス
| サービス名 | 関連する理由 |
|---|---|
| RDS | 高性能化のためにキャッシュを導入する最も一般的なバックエンド。 |
| Auto Scaling | ステートレス化により、パフォーマンスを維持したまま台数を増やせる。 |
| ALB | 高速なレスポンスをユーザーに届けるための入り口。 |
7. Obsidian管理メモ
- 復習ポイント: 「ミリ秒未満（Sub-millisecond）」という言葉が出たら、ディスクではなくメモリ（ElastiCache/DAX）を使っているか確認。
- 関連ノート: データベースのパフォーマンス最適化
8. HTMLファイル名
amazon-elasticache-high-performance-guide.html
