Amazon ElastiCache ベストプラクティス

Valkey / Redis OSS / Memcached を対象に、設計・接続・運用・セキュリティ・コストの観点で整理したもの。

---

目次

1. エンジンとデプロイ方式の選定
2. アーキテクチャ設計
3. キャッシュ設計
4. クライアント・接続のベストプラクティス
5. コマンドの使い方
6. セキュリティ
7. 監視とアラーム
8. バックアップとメンテナンス
9. コスト最適化
10. Memcached を使う場合の補足
11. 本番チェックリスト

---

1. エンジンとデプロイ方式の選定

エンジン

• データ構造（Sorted Set, Stream 等）、レプリケーション、フェイルオーバー、スナップショットが必要なら Valkey / Redis OSS を選ぶ
• Redis OSS 7.x → Valkey はアプリのコード変更なしで移行できるケースがほとんど

Serverless と ノードベース（Self-designed）

---

2. アーキテクチャ設計

クラスターモード

• 原則クラスターモード有効で構築する。シャード追加で水平スケールでき、書き込み性能・メモリ容量の上限を引き上げられる
• クラスターモード対応のクライアントライブラリを使う
• 複数キー操作（MGET、トランザクション、Lua）は同一スロットのキーに限られるため、関連キーにはハッシュタグ {user:123}:profile のように付けて同じスロットに寄せる
• ただしハッシュタグの乱用はホットシャードの原因になるので、キーの分散も意識する

高可用性

• Multi-AZ + 自動フェイルオーバーを有効化（本番では必須）
• 各シャードに最低 1 台、可能なら 2 台のレプリカを異なる AZ に配置
• 読み取りをレプリカに振る場合、単一レプリカだけに向けない（障害時に読めなくなる）。2 台以上のレプリカ、またはレプリカ + プライマリに分散する
• レプリカからの読み取りは結果整合である点をアプリ側で許容できるか確認する
• Serverless ではレプリカ用ポート 6380 で読むと同一 AZ のノードから優先的に読み取れ、レイテンシを下げられる
• TestFailover API で定期的にフェイルオーバーを試験し、アプリが再接続できることを確認する

サイジング（ノードベース）

• メモリはデータ量だけでなく、レプリケーション・スナップショット・フェイルオーバー時のオーバーヘッドを考慮する
• reserved-memory-percent はデフォルトの 25% を基本とする（バックアップや同期時の fork 用バッファ）
• 本番は r 系（メモリ最適化）・Graviton（r7g など）を基本に選定。t 系はバースト型のため本番の主要用途には不向き
• データ量が大きく、アクセスが一部のキーに偏るなら データ階層化（r6gd） で SSD を活用してコストを下げる
• 複数のシャードに均等に負荷が分散しているか（ホットキー・ホットシャードがないか）を確認する

---

3. キャッシュ設計

キャッシュ戦略

TTL と追い出し

• 基本的にすべてのキーに TTL を付ける（Write-Through のキーにも付ける）
• 大量のキーが同時に期限切れになるのを避けるため、TTL にランダムなジッターを加える
• maxmemory-policy は用途に合わせて設定
  • 純粋なキャッシュ: allkeys-lru / allkeys-lfu
  • TTL 付きキーのみ追い出したい: volatile-lru / volatile-lfu
  • データを失いたくない用途（セッション等）: 追い出しが起きないようキャパシティを確保し、Evictions を監視
• サンダリングハード（キャッシュスタンピード）対策: ミス時の DB 再取得をロック（SET NX）や早期再計算で 1 リクエストに絞る

キーと値の設計

• ビッグキーを避ける（1 つの値が数 MB 以上、要素数が非常に多いコレクション等）。レイテンシ悪化・ネットワーク帯域の圧迫・フェイルオーバー遅延の原因
• 大きいコレクションは分割する。値は必要に応じて圧縮する
• キー名には用途がわかるプレフィックスを付ける（例: session:, product:）が、長すぎるキー名はメモリを浪費する

---

4. クライアント・接続のベストプラクティス

• 長寿命の接続を再利用する（コネクションプーリング）。接続確立はキャッシュ側の CPU を消費するため、リクエストごとに接続しない
• NewConnections が高止まりしていないか監視する（接続の作り直しが多い兆候）
• エンドポイントは DNS 名で接続し、IP をハードコードしない（フェイルオーバー時に IP が変わる）
  • クラスターモード有効: 設定エンドポイント
  • クラスターモード無効: プライマリエンドポイント / リーダーエンドポイント
• DNS の TTL を尊重するようクライアント（特に JVM の DNS キャッシュ）を設定する
• 接続タイムアウト・コマンドタイムアウトを適切に設定し、無期限に待たない
• リトライは指数バックオフ + ジッターで行い、障害時にリトライが集中しないようにする
• パイプラインを使って往復回数を減らす（大量の小さいコマンドを送る場合）
• クラスター構成の変更（シャード追加、フェイルオーバー）時に MOVED / ASK を正しく処理できるクライアントを使う
• AWS が推奨する GLIDE（Valkey GLIDE）など、クラスター・フェイルオーバー対応が成熟したクライアントを検討する

---

5. コマンドの使い方

• KEYS は本番で使わない → SCAN を使う
• SMEMBERS, HGETALL, LRANGE 0 -1 など大きなコレクションを一括取得するコマンドは避け、SSCAN / HSCAN などで分割取得する
• 大きなキーの削除は DEL ではなく UNLINK（非同期削除）を使う
• FLUSHALL / FLUSHDB は ASYNC オプションを付ける
• Lua スクリプト
  • 長時間実行するスクリプトは避ける（実行中は他のコマンドがブロックされる）
  • 使用するキーは必ず KEYS 引数で事前に宣言し、すべて同じスロットに属するようにする
• Pub/Sub: 高スループットなら Sharded Pub/Sub（SPUBLISH / SSUBSCRIBE）を使う。従来の Pub/Sub はクラスター全ノードにブロードキャストされ EngineCPUUtilization が上がる
• スローログ（SLOWLOG）を CloudWatch Logs / Kinesis Data Firehose に配信し、遅いコマンドを継続的に把握する

---

6. セキュリティ

• VPC 内に配置し、プライベートサブネットのみを使う。パブリックアクセスはさせない
• セキュリティグループでアクセス元をアプリケーションのセキュリティグループのみに限定する
• 転送中の暗号化（TLS）を有効化
• 保存時の暗号化を有効化（必要に応じてカスタマー管理の KMS キーを使用）
• 認証
  • Valkey / Redis OSS 6 以降は RBAC（ユーザーグループ + ACL） を使い、アプリごとに最小権限のユーザーを作る
  • IAM 認証を使うとパスワード管理が不要になる
  • AUTH トークン/パスワードを使う場合は Secrets Manager で管理し、ローテーションする
• CONFIG, FLUSHALL, KEYS などの危険なコマンドはアプリ用ユーザーの ACL で禁止する
• CloudTrail で ElastiCache API の操作履歴を記録する

---

7. 監視とアラーム

主要な CloudWatch メトリクス

• ElastiCache のイベント（フェイルオーバー、メンテナンス等）を SNS / EventBridge で通知する
• エンジンログ・スローログを有効化し、ログを集約する

---

8. バックアップとメンテナンス

• 自動バックアップを有効化し、保持期間を要件に合わせて設定する（純粋なキャッシュで再生成可能なら不要な場合もある）
• バックアップはプライマリへの負荷を避けるためレプリカから取得されるように構成する。メモリに余裕がないと fork 時に性能劣化・スワップが起こる
• メンテナンスウィンドウとバックアップウィンドウを低トラフィック時間帯に設定し、両者を重ねない
• サービス更新（セキュリティパッチ等）は期限前に計画的に適用する
• スケーリングはオンラインリサイズ（シャード追加/削除、ノードタイプ変更）を使い、低負荷時に実施する
• エンジンのメジャーバージョンアップは、まずステージング環境で互換性と性能を検証する

---

9. コスト最適化

• Redis OSS から Valkey へ移行すると料金が下がる（Serverless・ノードベースとも Valkey の方が安価）
• Graviton ベースのノード（r7g, m7g 等）を選ぶ
• 安定したワークロードにはリザーブドノードを購入する
• 使用率が低いクラスターは縮小し、データ量が大きい場合はデータ階層化を検討する
• Serverless は最大使用量の上限を設定して想定外の課金を防ぐ
• 開発・検証環境はレプリカなし・小さいノードにする

---

10. Memcached を使う場合の補足

• データはノード間で分散されるだけでレプリケーションされない。ノード障害でデータが消える前提で設計する
• Auto Discovery 対応クライアントを使い、ノード追加/削除に自動追従する
• ノード追加時のキー再配置を最小にするため、コンシステントハッシュを使う
• ノードは複数 AZ に分散配置する

---

11. 本番チェックリスト

• エンジンは Valkey を第一候補として検討した
• Serverless / ノードベースの選定理由が明確
• クラスターモード有効（ノードベースの場合）
• Multi-AZ + 自動フェイルオーバー有効、シャードごとに 1 台以上のレプリカ
• reserved-memory-percent と maxmemory-policy を用途に合わせて設定
• すべてのキーに TTL（+ ジッター）を設定
• コネクションプーリング、タイムアウト、指数バックオフ付きリトライを実装
• DNS エンドポイントで接続し、IP をハードコードしていない
• KEYS など重いコマンドを使っていない、ビッグキーがない
• 高スループットの Pub/Sub は Sharded Pub/Sub
• VPC・セキュリティグループで閉域化、転送中/保存時の暗号化有効
• RBAC または IAM 認証で最小権限
• 主要メトリクスに CloudWatch アラーム、イベント通知を設定
• スローログ・エンジンログを配信
• バックアップ・メンテナンスウィンドウを設定、フェイルオーバーテスト済み
• リザーブドノード・Graviton・データ階層化などコスト最適化を検討

---

参考

• Overall best practices - Amazon ElastiCache
• Best practices when working with Valkey and Redis OSS node-based clusters