導入
DBの前にキャッシュを1枚挟むだけで、レイテンシーと負荷の両方を劇的に改善できます。SAAの性能・コスト最適化ドメインの定番テーマ、ElastiCacheです。
説明
Amazon ElastiCache は、フルマネージドのインメモリデータストアです。DBの前段に置き、頻繁にアクセスされるデータをメモリ上にキャッシュすることで、読み取りレイテンシーの短縮とDB負荷の軽減を同時に実現します。
2つのエンジンから選べます。
| エンジン | 特徴 | 向いているケース |
|---|---|---|
| Redis | 永続化・レプリケーション・Multi-AZ・複雑なデータ構造（リスト、ソート済みセットなど）に対応 | セッションストア、リーダーボード、高可用性が必要なキャッシュ |
| Memcached | シンプルなキーバリューキャッシュ。マルチスレッドで水平分割しやすい | 単純なキャッシュをとにかく高速・シンプルに使いたい |
代表的な使い方がセッションストアです。Webサーバーをスケールアウトする構成（第2章のAuto Scaling等）では、各インスタンスがセッション情報をローカルに持つと、次のリクエストが別インスタンスに飛んだときに情報が失われます。セッションをElastiCacheに外出しすれば、どのインスタンスが応答してもセッションを共有できます。
flowchart LR
User["ユーザー"] --> ALB["ロードバランサー"]
ALB --> EC2a["EC2 #1"]
ALB --> EC2b["EC2 #2"]
EC2a --> Cache["ElastiCache (Redis)<br/>セッション/キャッシュ"]
EC2b --> Cache
Cache -.->|"キャッシュミス時のみ"| DB["RDS/Aurora"]
具体例
Auto ScalingでWebサーバーを増減する構成で、ある不具合が起きました。ユーザーがログインしてカートに商品を入れたのに、次のページで急にログアウト状態に戻るというのです。
原因は、各EC2がセッション情報を自分のメモリに持っていたこと。ロードバランサーが次のリクエストを別のEC2に振り分けると、そのEC2はユーザーのセッションを知らないため、ログインが切れて見えたのです。
解決策がElastiCache（Redis）へのセッション外出しです。
- セッション情報を各EC2ではなく共有のElastiCacheに保存
- どのEC2が応答しても、同じElastiCacheを見るのでセッションが保たれる
- ついでに、よく読まれるDBの結果もキャッシュし、DB負荷とレイテンシーを下げる
エンジン選びは要件で。「高可用性（Multi-AZ）・永続化・リーダーボードのような複雑なデータ構造」が要るならRedis、「とにかくシンプルなキャッシュを水平分割で」ならMemcached。「セッションをインスタンス間で共有」「DBの読み取り負荷を減らす」はElastiCacheのサインです。
読んでみよう
「Redis vs Memcached」は頻出の対比です。高可用性（Multi-AZ）・永続化・レプリケーションが必要ならRedis、シンプルな水平分割キャッシュならMemcached、と覚えてください。「DBの読み取り負荷を減らしたい」「セッション情報をインスタンス間で共有したい」という文言はElastiCacheのサインです。