Amazon ElastiCache高度運用Vol1｜Valkey移行・Serverless・高度運用

1. 本記事の射程 — Valkey移行・Serverless・高度運用への深化

1-1. 本記事の射程と基礎編との境界

Amazon ElastiCacheを本番環境で安定稼働させるための基礎として、クラスタモード設計・Replication Group（Multi-AZ・Auto-Failover）・TLSによる転送暗号化・RBAC認証・バックアップ・基本的なスケール戦略（Out vs Up）があります。
これらの基礎については「AWS Database本番運用 Vol3」§2「ElastiCache for Redis 本番運用」で詳しく解説しています。
本記事はその知識を前提とした「高度運用」の領域を扱います。

本記事では扱わない領域（基礎編の範囲）

以下のトピックは「AWS Database本番運用 Vol3」§2でDEEP解説済みです。本記事では再解説せず、必要に応じて基礎編へのクロスリンクで委ねます。

• クラスタモード設計（シャーディング・スロット分割・ノード数計算）
• Replication Group（Multi-AZ・Auto-Failover）の基礎設定
• TLS in-transit 転送暗号化の基礎設定
• RBAC認証の基礎（ユーザー・パスワード・デフォルトユーザー制御）
• バックアップ・スナップショットの基礎運用
• スケール戦略（Scale Out vs Scale Up）の基礎判断

本記事が扱う領域（高度運用）

基礎の先にある以下の5テーマが本記事の対象です。これらはDB Vol3 §2にはない領域です。

• Valkey移行: Redis OSSライセンス変更に伴い2024年に登場した新エンジン「Valkey」へのエンジン切替と、コスト20〜33%削減の実現
• ElastiCache Serverless: 2023年11月GAの完全従量課金モデルと、ノードベースクラスタとの適切な使い分け
• Global Datastore: クロスリージョン非同期レプリケーションによるDR設計とグローバル読み取り
• データ階層化・オンライン再シャーディング: r6gdノードによる大容量低コスト化と無停止でのシャード変更
• 高度RBAC/ACL設計・詳細監視: 最小権限設計・コマンド制限・CloudWatch詳細指標・スロットリング対応

これら5テーマはElastiCacheの利用が本番稼働域に達した後に直面する、コスト最適化・大規模化・高可用性・運用安定化という実課題に対応しています。
基礎（クラスタモード/Multi-AZ/TLS/RBAC基礎/バックアップ）は基礎編に委ね、本記事では取り上げません。

ElastiCacheとMemoryDBの違い

なお、Amazon MemoryDBはElastiCacheとは異なるサービスです。
MemoryDBは強い一貫性を備えた永続的なインメモリデータベースであり、Redisデータ構造を永続化したい場合や、プライマリデータストアとしてRedis互換が必要な場合に適しています。
ElastiCacheはキャッシュ用途（レイテンシ削減・DBオフロード）を主体とするサービスであり、両者は役割が異なります。
MemoryDBについては「AWS Database本番運用 Vol3」§5で詳述しており、本記事では踏み込みません。

1-2. なぜ今Valkey移行なのか

Redisライセンス変更の経緯

2024年3月、Redis社（旧Redis Labs）はオープンソース版Redisのライセンスを従来のBSD（3条項）から「RSALv2/SSPLv1」のデュアルライセンスに変更しました。
RSALv2（Redis Source Available License v2）は、クラウドプロバイダーがRedisをマネージドサービスとして提供することを制限する内容です。
この変更はAWSを含む多くのクラウドベンダーやエンタープライズユーザーに影響を与えました。

同年3月、AWS・Google Cloud・Oracle・Ericsson・Snapなどが連携し、Linux Foundation傘下でRedisのオープンソースフォークプロジェクト「Valkey」を立ち上げました。
ValkeyはBSDライセンスで提供され、オープンな開発体制で継続的に進化しています。
AWSはValkeyの主要コントリビューターとして開発に参加しており、信頼性と長期サポートの観点からも安心して採用できるエンジンです。

ValkeyとRedis OSSの互換性

ValkeyはRedis OSS 7.2系から派生しており、Redisのコマンドセット・データ構造との高い互換性を維持しています。
String・Hash・List・Set・Sorted Set・Stream・HyperLogLog・Pub/Subなど、Redis互換のデータ型とコマンドがそのまま利用できます。
既存のRedisクライアントライブラリ（Jedis・Lettuce・redis-py・ioredis等）はそのままValkeyへの接続に使用できます。

Valkeyはさらに独自の進化を続けており、マルチスレッドI/O処理の強化やパフォーマンス改善が進んでいます。
AWSのElastiCacheにおいても、Valkeyエンジンは東京リージョンを含む主要リージョンで2024年10月にGA（一般提供）を開始しました。

コスト削減効果

ElastiCacheのエンジンをRedis OSSからValkeyに切り替えることで、以下のコスト削減が見込めます。

• ElastiCache Serverless: 既存のRedis OSSと比較して約33%のコスト削減
• ノードベースクラスタ: オンデマンド・Reserved Instanceともに約20%のコスト削減

AWSは新規ElastiCacheクラスタの作成においてValkeyを推奨エンジンとして位置づけています。
既存のRedis OSSクラスタからもインプレースのエンジン切替による移行が可能であり、データの再移行を必要としないケースもあります。
ライセンスリスクの排除・コスト削減・長期サポートの観点から、Valkeyへの移行を検討するタイミングが来ています。

Valkey移行のタイミングと判断

現在Redis OSSを運用している環境では、以下のタイミングでValkey移行を検討するのが現実的です。

• 新規クラスタ作成時: 最もリスクが低く、そのままValkeyを選択できます
• スケール変更・バージョンアップ時: 既存クラスタのメンテナンス作業に移行を組み合わせる
• コスト最適化プロジェクト時: 定期的なコスト見直しのタイミングで計画的に実施

移行の具体的な手順・互換性テスト・ロールバック対応については§2で詳しく解説します。

1-3. 想定読者

本記事はElastiCacheの基礎構築（クラスタモード・Multi-AZ・TLS・バックアップ）を完了済みで、次の高度化ステップを検討している方を対象としています。

コスト最適化を求めるSRE・インフラエンジニア

既にElastiCache（Redis OSS）を本番運用しており、Valkeyへの移行によるコスト20〜33%削減を検討している方。
ライセンスリスクへの対応も兼ねており、移行の判断基準・手順・検証方法を体系的に把握したい方が対象です。
クラスタモード・TLSの基礎は習得済みであることを前提とします。

キャパシティ計画を最適化したいアーキテクト

ElastiCache ServerlessのECPU課金モデルを評価し、既存のノードベースクラスタとの使い分けを設計判断したい方。
スパイキーな負荷パターンや予測困難なトラフィックへの対応、Reserved Instancesとの組み合わせによるコスト最適化を検討しているアーキテクトを想定しています。

グローバルサービスの基盤担当者

複数リージョンでのサービス提供を行っており、クロスリージョンのキャッシュ可用性（DR設計・グローバル読み取り低レイテンシ化）を求めているチーム。
Global Datastoreの対象範囲・制約・フェイルオーバー手順を知りたい方。

大容量キャッシュを設計している方

キャッシュデータ量が増大しており、r6gdノードのデータ階層化（メモリ+ローカルNVMe SSD）を活用した大容量低コスト化を検討している基盤担当者。
無停止でのオンライン再シャーディングによる柔軟なスケール設計も含めて評価したい方。

ElastiCache運用を成熟させたいチーム

高度なACL/RBAC設計（最小権限・コマンド制限・Secrets Manager連携）や、CloudWatchの詳細メトリクスを活用した監視ダッシュボードの構築を整備したい運用担当者。
スロットリング・ホットキー・大きなキーへの対処を体系化し、ElastiCacheの運用監視を一段深めたい方。

1-4. 本記事の5テーマ地図

本記事は§2から§7にかけて、5テーマ＋統合設計で構成されています。

各テーマは独立して参照できますが、実際の本番導入では段階的な成熟パスを辿ることが多いです。

1. Valkey移行でコスト削減: まずRedis OSSからValkeyへ切り替え、コスト20〜33%削減を実現
2. Serverless/ノードの最適化: 負荷特性に応じてServerlessとノードベースを使い分け
3. Global Datastoreでクロスリージョン可用性: 必要に応じてクロスリージョンDRを追加
4. データ階層化で大容量対応: データ増大時にr6gdノードのデータ階層化を適用
5. 高度監視・ACL設計で安定運用: 詳細監視とACL設計で運用品質を高める

§7では、これら5テーマを組み合わせた統合アーキテクチャと、既存のRedis OSSクラスタから段階的に成熟させるロードマップを整理します。
現時点でどのテーマから始めるべきかの優先順位付けや、機能間の組み合わせ可否についても解説します。

2. Valkey移行 — Redis OSS から Valkey へのエンジン切替とコスト最適化

本章で解説するValkeyへの移行は、ElastiCacheの高度化における最初のステップです。エンジンの切替だけでコスト削減（Serverlessで約33%・node-basedで約20%）を実現できる点が、他の最適化施策と比べて投資対効果が高い特徴があります。移行の背景・コストメリット・互換性・移行手順・ロールバック・移行後の運用差分という流れで、実務で必要となる情報を体系的に整理しています。

2-1. Valkey登場の背景 — ライセンス変更とLinux Foundationフォーク

AWSがElastiCache for Valkeyを2024年10月にGAリリースした背景には、オープンソースコミュニティでの大きな出来事がありました。Redis Inc.は2024年初頭、Redis本体のライセンスをBSDからRSALv2/SSPLv1のデュアルライセンスへ変更しました。この変更により、クラウドプロバイダーがRedisをマネージドサービスとして提供する際の条件が大きく変化することとなりました。

こうした状況に対応するため、AWS・Google Cloud・Ericsson・Snap・Fastlyなどのクラウドベンダーおよびシステムベンダーが中心となり、Linux Foundation主導で2024年3月にValkeyプロジェクトを立ち上げました。ValkeyはRedis 7.2.4をベースとしたオープンソースフォークであり、BSD相当の自由なライセンスのもとで活発なコミュニティ開発が現在も続いています。

AWSはこのValkeyをElastiCacheのエンジンとして採用し、2024年10月にGA（一般提供）を開始しました。東京リージョン（ap-northeast-1）を含む主要リージョンですぐに利用可能です。AWSがElastiCacheのドキュメント内で使用する「Redis OSS」という表記は旧来のRedisエンジンを指し、「Valkey」は新世代エンジンとして明確に区別されています。

Valkeyプロジェクトはオープンソースとして活発に開発が進んでおり、Valkey 7.2・8.0・9.1と短期間に多くの性能改善が加えられています。AWSもLinux Foundationと連携して開発に貢献しており、ElastiCache for Valkeyは最新のValkeyリリースを継続的に取り込む形で提供されています。将来のバージョンアップに伴うさらなる性能・機能向上が期待できる点もValkeyを選択する理由のひとつです。

新規のElastiCacheキャッシュを作成する場合、特段の理由がない限りValkeyの選択を推奨します。既存のRedis OSSクラスタをお持ちの場合も、後述の移行手順で比較的スムーズに切り替えが可能です。

2-2. コストメリットと互換性

Valkeyへの移行における大きな動機のひとつがコスト削減です。AWSの公式情報によると、ElastiCacheでValkeyエンジンを選択した場合、同等のRedis OSSと比較して以下のコスト削減が実現できます。

• ElastiCache Serverless（Valkey）: Redis OSSより約33%低価格
• node-based（セルフデザインクラスタ）: Redis OSSより約20%低価格

この価格差は純粋にエンジン選択によるものです。インスタンスタイプや構成を変更せずとも得られるコスト削減効果であるため、大規模なElastiCache利用環境では移行だけで年間運用コストを大幅に削減できる可能性があります。実際に、AWSのブログではValkeyへの切替とコスト最適化ツールを組み合わせることで最大60%のコスト削減を達成した事例が報告されています。

コスト削減効果はエンジン切替が完了した時点から即日発生します。つまり、移行のROIを評価する際の「回収期間」は移行作業の工数のみであり、追加のインフラ費用なしにコスト削減効果を得られます。特に複数のElastiCacheクラスタを運用している組織では、Valkeyへの一斉移行によるコスト削減効果が大きくなります。

APIレベルの互換性

ValkeyはRedis OSS 7.2との完全なAPIレベルの互換性を持つよう設計されています。既存のRedisクライアントライブラリ（redis-py・Jedis・go-redis・ioredisなど）はそのまま利用でき、アプリケーションコードの変更が不要なケースがほとんどです。

• String・Hash・List・Set・Sorted Set・Stream・HyperLogLog・Bitfieldなどの主要データ構造が同様に使用可能
• MULTI/EXECトランザクション・Lua Script・Pub/Sub機能も対応
• クラスタモード・スタンドアロンモードいずれもサポート

ただし、Redis OSSの旧バージョン固有の機能や、Redis Modules（RedisSearch・RedisBloomなど）はValkeyでは対応状況が異なります。アプリケーションが利用している機能の互換性については、AWSの公式ドキュメントで事前に確認することを推奨します。

Redis Modulesの取り扱い

AWSが管理するElastiCacheでは、Redis Modules（RedisSearch・RedisBloom・RedisTimeSeries等）はRedis OSSでもValkeyでも利用できません。全文検索や高度なクエリ機能が必要な場合は、Amazon OpenSearch ServiceやAmazon MemoryDBの検討が選択肢に挙がります。MemoryDBは永続ストレージとトランザクション保証を提供するサービスで、ElastiCacheとは設計目的が異なります。ElastiCacheとMemoryDBの使い分けについては基礎編の解説を参照してください。

2-3. 移行方式と判断基準

Redis OSSからValkeyへの移行には主に2つの方式があります。本番環境への適用前に、それぞれのメリット・デメリットを把握して移行計画を立てることを推奨します。どちらの方式を選択するかは、許容できるダウンタイム・ロールバック要件・移行コスト・システムの複雑さによって決まります。

方式1: インプレースのエンジン切替（推奨）

AWS Management Console・CLI・またはAPIを使用して、既存のRedis OSSクラスタのエンジンを直接Valkeyへ切り替える方法です。

• ダウンタイム: Redis OSS 5.0.6以降からの切替であれば、Multi-AZが有効な構成では基本的にダウンタイムなしで移行できます。ローリングアップグレードで各ノードを順次切り替えるため、サービスを継続したまま移行が完了します。5.0.6より古いバージョンからの移行ではDNS伝播に伴う30〜60秒程度のフェイルオーバーが生じることがあります
• データ保持: インメモリのデータはそのまま保持されます
• エンドポイント継続: クラスタのエンドポイント（接続文字列）が変わらないため、アプリケーション側の設定変更が不要です

方式2: 新規Valkeyクラスタ作成＋データ移行

新規にValkeyクラスタを作成し、Blue/Greenデプロイメント方式でデータと本番トラフィックを移行するアプローチです。

• 既存のRedis OSSクラスタのスナップショットを取得し、Valkeyクラスタとして復元する方法
• Online Migration機能を利用して、既存のRedis OSSからValkeyへリアルタイムに移行する方法
• Blue/Greenデプロイメントを活用し、本番トラフィックを段階的に切り替える方法

移行中は2つのクラスタが並走するため一時的なコスト増加が発生しますが、旧クラスタを残置したままロールバックが容易であるため、リスクを最小化したい場合に適しています。

Online Migration（オンラインマイグレーション）の活用

Online Migration機能を利用すると、既存のRedis OSSまたはValkey環境（セルフマネージドのRedisを含む）からElastiCacheのValkeyクラスタへ、ダウンタイムなしでデータを移行できます。移行中も元のクラスタへの書き込みが継続して受け付けられ、移行先クラスタへのレプリケーションが完了した後にカットオーバーを実行する仕組みです。オンプレミスのRedisやEC2上のセルフマネージドRedisからElastiCacheへ移行する場合に特に有効な手段です。詳細な手順と制約については、AWSの公式ドキュメントの「Online migration for Valkey or Redis OSS」をご確認ください。

移行方式の選択判断

ダウンタイムを最小化しつつシンプルに移行したい場合はインプレース切替が、ロールバック容易性を重視する場合は新規作成＋移行が適しています。

2-4. 移行手順と互換性検証

事前の互換性テスト（ステージング環境での検証）

本番環境への適用前に、ステージング環境でValkeyへ切り替えた状態での動作検証を必ず実施してください。確認すべきポイントは以下です。

• アプリケーションが使用するすべてのRedisコマンドがValkeyで正常に動作するか
• Pub/Sub・Lua Script・トランザクション（MULTI/EXEC）などの高度な機能の動作確認
• 使用中のRedisクライアントライブラリのバージョンとの互換性
• キャッシュヒット率・レイテンシに変化がないことをベンチマークで確認

互換性チェックに役立つアプローチ

使用しているRedisコマンドの一覧を把握するには、以下の方法が有効です。

• Redis SLOWLOGを活用して実際に使用されているコマンドをサンプリングする
• アプリケーションのログやモニタリングツールでRedisコマンドの種類と頻度を把握する
• Valkey CLIを用いてステージング環境で代表的なコマンドセットを直接テストする

クライアントライブラリの互換性については、使用しているライブラリのリリースノートでValkey対応状況を確認することをお勧めします。redis-py・Jedis・ioredisなどの主要ライブラリは既にValkey対応を明示しています。

インプレース切替の手順概要

1. ステージング環境での動作確認が完了したら、本番環境のメンテナンスウィンドウを設定します
2. AWS Management ConsoleのElastiCacheダッシュボードから対象クラスタを選択し「クラスタの変更」を実行します
3. エンジンを「Valkey」に変更し、対象バージョン（例: Valkey 7.2）を選択します
4. メンテナンスウィンドウでの適用、または即時適用を選択して変更を確定します
5. 切替中はCloudWatchのメトリクス（レイテンシ・エラー率・接続数）を継続監視します
6. 切替後、アプリケーションログとパフォーマンスを一定期間（最低24〜48時間）確認します

AWS CLIを使用したインプレース切替のコマンド例は以下のとおりです。

# 現在のエンジンバージョンを確認
aws elasticache describe-replication-groups \
  --replication-group-id my-redis-cluster \
  --query 'ReplicationGroups[0].{Engine:Engine,Version:CacheEngineVersion}'

# エンジンをValkeyに切替（即時適用）
aws elasticache modify-replication-group \
  --replication-group-id my-redis-cluster \
  --engine valkey \
  --engine-version 7.2 \
  --apply-immediately

--apply-immediately を省略するとメンテナンスウィンドウでの適用となります。本番環境では変更の影響範囲を限定するためにメンテナンスウィンドウの利用を推奨します。

ロールバック（切り戻し）の対応範囲

• Valkey 7.2 → Redis OSS 7.1: インプレースダウングレードが可能です（Console/API/CloudFormation/CDK対応）。ロールバック時もデータは保持されます
• Valkey 8.0以降 → Redis OSS: インプレースのロールバックは現時点では非対応です。必要な場合は、スナップショットからRedis OSS 7.1クラスタとして復元する方法を利用してください

移行のリスク許容度が低い本番環境では、まずValkey 7.2を選択してインプレースロールバック可能な状態を維持しつつ運用し、安定稼働を確認してから上位バージョンへのアップグレードを検討することをお勧めします。

スナップショットを使ったロールバックの流れ（Valkey 8.0以降）

Valkey 8.0以降からのロールバックが必要な場合は、スナップショットを経由した復元を行います。

1. 現在のValkeyクラスタの手動スナップショットを取得します（または自動バックアップから選択します）
2. AWS Management ConsoleまたはCLIから、そのスナップショットをRedis OSS 7.1クラスタとして復元します
3. 新しいRedis OSS 7.1クラスタのエンドポイントにアプリケーションの接続先を切り替えます

スナップショットからの復元ではインメモリの最新書き込みが一部失われる可能性があるため、移行前に必ずスナップショットを取得しておき、ロールバック手順を事前に演習することを推奨します。

2-5. 移行後の運用差分 — Valkeyの特性と活用

マルチスレッドI/Oアーキテクチャ（Valkey 8.0以降）

Valkey 8.0以降では新しいマルチスレッドI/Oアーキテクチャが導入されました。メインスレッドとI/Oスレッドが並行して動作し、コマンドの読み取り・解析・レスポンス書き込み・I/Oイベントのポーリングを分担する設計です。この実装により、Redis OSSと比較して最大230%高いスループットと最大70%低いレイテンシを実現しています。

Valkey 9.1ではI/Oスレッディングの通信モデルがさらに改良され、多様なワークロードにわたってスループットが向上しています。ElastiCacheのValkeyエンジンは、AWSがオープンソースコミュニティと協力してこうした最新の改善を取り込んでいます。

メモリ効率の改善

Valkey 8.0ではデータ構造のメモリ最適化が行われ、Redis OSSと同じノードタイプ・メモリ量でより多くのデータを格納できるようになりました（最大41.4%のメモリ使用量削減）。コスト削減に加えて、同一ノードサイズでのキャッシュ容量が実質的に向上することを意味します。

Valkey固有のモニタリング

Valkey 9.1から、メインスレッドおよびI/Oスレッドの使用率メトリクスが追加されました。これにより実際のワークロード圧力とスレッドの動作状態を区別して監視できます。従来のCloudWatchメトリクス（EngineCPUUtilization・DatabaseMemoryUsagePercentage等）と組み合わせることで、Valkeyエンジンの性能を最大限に引き出した運用が可能になります。

Valkeyエンジンバージョンの主な改善点

ElastiCacheのValkeyは継続的にバージョンアップされており、それぞれのバージョンに主要な改善が含まれています。

ElastiCacheで利用可能なValkeyバージョンの最新状況は、AWSの公式ドキュメントのエンジンバージョン一覧ページでご確認ください。

移行後のコスト確認

Valkeyへの移行後は、AWSコストエクスプローラーやCUDOS（Cloud Intelligence Dashboards）を活用してコスト削減効果を定量的に確認することをお勧めします。ElastiCacheの利用規模が大きいほど、Valkeyへの切替による削減効果が明確に数値として現れます。

AWSコストエクスプローラーでは、サービスを「ElastiCache」に絞り込み、エンジン別の利用コストを比較できます。移行前後の期間を並べて比較することで、Valkeyへの切替によるコスト削減効果を月単位で定量的に把握できます。また、ElastiCacheのタグ機能を活用してキャッシュクラスタをシステム・環境別に分類しておくと、コスト分析がより詳細に行えます。

移行後の性能確認では、ElastiCacheのEngineCPUUtilization・CacheHits・CacheMisses・CurrConnectionsなどのメトリクスが基準値から大きく外れていないことを確認します。特に移行直後の1〜2時間はメトリクスをこまめに確認し、異常を早期に検出できる体制を整えておくことをお勧めします。

3. ElastiCache Serverless — ECPU課金と自動スケール運用

3-1. ElastiCache Serverlessの仕組み

Amazon ElastiCache Serverlessは2023年11月にGAリリースされた、キャパシティプランニング不要の完全マネージドキャッシュサービスです。従来のnode-based（セルフデザインクラスタ）では、ノードタイプの選択・シャード数の設計・スケール操作が必要でしたが、ElastiCache Serverlessではこれらを一切意識する必要がありません。

ElastiCache Serverlessの主な特徴は以下のとおりです。

• 即時自動スケール: トラフィックの増減に応じて、数秒から数分以内に自動でキャパシティを拡縮します。スパイキーな負荷にも即座に追従します
• キャパシティプランニング不要: ノードタイプ・シャード数の設計が不要で、作成時に必要なのはキャッシュ名と対応エンジンの選択のみです
• クラスタモード強制: ElastiCache Serverlessは内部的にクラスタモードで動作します。接続するクライアントはTLS対応かつクラスタモードをサポートするクライアントライブラリを使用する必要があります
• 対応エンジン: Valkey（バージョン7.2以上）、Redis OSS（バージョン4.0.10〜7.1）、Memcached（バージョン1.4.5以上）

ElastiCache Serverless for Valkey（Valkey 8.0）では、ゼロから500万リクエスト/秒（RPS）まで2〜3分ごとに倍増しながらスケールアウトし、13分以内にピーク性能に到達できます。大規模なイベント等で急激なトラフィック増加が予測される場合は、少なくとも60分前に最小ECPUを目標ピーク値に設定しておくことで、スロットリングを回避できます。

AWS CLIを使ったElastiCache Serverlessキャッシュの作成例

ElastiCache Serverlessキャッシュの作成は、コンソールから数クリックで完了するほか、AWS CLIでも実行できます。

# ElastiCache Serverless for Valkeyキャッシュを作成
aws elasticache create-serverless-cache \
  --serverless-cache-name my-valkey-serverless \
  --engine valkey \
  --description "Valkey Serverless cache for production" \
  --cache-usage-limits '{"DataStorage":{"Maximum":10,"Unit":"GB"},"ECPUPerSecond":{"Maximum":5000}}'

--cache-usage-limits で最大データ格納量（GB）と最大ECPU/秒の上限を設定できます。上限を設定しない場合、ElastiCache Serverlessは自動的にスケールします（Serverlessのデフォルト上限の範囲内で）。開発・テスト環境では上限を設定してコストを抑え、本番環境では実際の負荷に応じて上限を調整することをお勧めします。

3-2. ECPU課金モデルと料金計算例

ElastiCache Serverlessの課金は、以下の2要素から構成されます。

① ECPU（ElastiCache Processing Unit）消費量

ECPUはvCPUリソースとネットワーク使用量を組み合わせた処理単位です。リクエストごとのECPU消費量は以下のルールに従います。

• シンプルなSET/GETコマンドで1KB以下のデータを転送する場合: 1リクエスト = 1 ECPU
• データ転送量が1KBを超える場合: 比例してECPU消費量が増加します（例: 2.3KBのGETは2.3 ECPU）
• ECPU消費量の最小単位は1 ECPU/リクエストです（部分的な消費でも最低1 ECPUを消費）

② データ格納量（GB-時間）

キャッシュに格納されているデータ量に応じた時間課金です。

課金対象 = 格納データ量(GB) × 時間(h)
最小課金単位: Valkey/Memcached = 100MB、Redis OSS = 1GB

料金計算例（概算・東京リージョン）

ElastiCache Serverlessの料金はリージョンによって異なります。以下は、AWSの公式料金ページの数値をもとにした概算イメージです。具体的な単価は必ず公式料金ページ（aws.amazon.com/elasticache/pricing/）でご確認ください。

想定ワークロード例:
  - 平均スループット: 1億 ECPU/時間（約2.8万リクエスト/秒・平均1KB前後）
  - キャッシュデータ量: 10 GB

ECPU消費コスト（例）:
  (100,000,000 ECPU ÷ 1,000,000) × 単価($/百万ECPU) = X $/時間

データ格納コスト（例）:
  10 GB × 単価($/GB-時間) = Y $/時間

月額目安: (X + Y) × 730時間/月

実際の料金はワークロードのリクエストサイズ・スループット・データ量によって大きく変動します。Valkeyエンジンを選択するとRedis OSSより約33%低価格で利用できるため、既存のRedis OSSのServerless環境からValkeyへ切り替えるだけでも一定のコスト削減効果があります。

ECPUを消費するリクエストの特性

ECPUの消費量はリクエストの種類とデータサイズに依存します。以下に代表的なパターンを示します。

コスト最適化のポイントとして、キャッシュするデータのシリアライズ形式をコンパクトにする（JSON圧縮・MessagePackなど）ことで、ECPUとデータ格納コストを同時に削減できる場合があります。実際のECPU消費量はCloudWatchのメトリクス（ElastiCacheTotalECPU等）で確認できます。

3-3. node-basedとの使い分け

ElastiCache Serverlessとnode-based（セルフデザインクラスタ）は、ワークロードの特性によって適切に使い分けることが重要です。

ElastiCache Serverlessが適しているケース

node-based（セルフデザインクラスタ）が適しているケース

コスト分岐点の考え方

Serverlessのコストはワークロードに比例するため、常時高いECPU消費が続く本番環境ではnode-basedのほうがコスト効率が高くなる傾向があります。

• 24時間365日ほぼフル稼働のワークロードでは、node-based + リザーブドノード（1年・3年RI）の組み合わせがコスト優位になるケースが多いです
• 利用率が不規則または平均利用率が低い環境では、Serverlessのほうがコスト効率が高くなります
• 移行初期やトラフィックパターンが不明な段階では、まずServerlessで開始してECPU消費量の実績データを取得し、それをもとにnode-basedへの移行要否を判断する方法もお勧めします

Serverless vs node-based コスト比較の考え方

厳密な比較はワークロードと料金に依存しますが、以下の考え方が参考になります。

node-basedのコストはノードタイプ × 台数 × 時間課金（リザーブドノード割引あり）で計算されます。これに対し、Serverlessはトラフィックがなければデータ格納量のみの課金（最小課金はValkeyで100MB）です。

• 利用率が低い（〜30%程度）: Serverlessが有利になる傾向があります
• 利用率が高い（70%以上が常態）: node-based + RIが有利になる傾向があります
• 利用率が中程度（30〜70%）: RI割引率・スパイク頻度・管理コストを含めてケースバイケースで判断します

実際の移行判断にはAWS Pricing Calculatorを使って両者の月額コストを試算し、比較することをお勧めします。

node-basedのスケール戦略（スケールアウト/スケールアップの詳細）については、基礎編の解説を参照してください。

3-4. Serverlessの制約と適用判断

ElastiCache Serverlessにはいくつかの制約があります。本番適用前に公式ドキュメントで最新の対応状況を確認してください。

スケールの上限

ElastiCache Serverlessは、デフォルトで最大30,000 ECPU/秒のスループットをサポートします。Read from Replica機能（READONLYコネクションを使用したレプリカへの読み取り転送）を活用すると、最大90,000 ECPU/秒まで拡張できます。

最大ECPUを設定している場合、その上限に達するとリクエストがスロットリングされます。最大データ格納量を設定している場合は、TTLを持つデータがLRUで削除され、削除できるデータがない場合はOOM（Out of Memory）エラーが返されます。

スロットリング対策

スロットリングはCloudWatchメトリクスの ThrottledRequests で検出できます。スロットリングが多発する場合は以下を検討してください。

• 最大ECPU上限の引き上げ（または上限を設定しない）
• Read from Replica機能の活用（READONLYコネクションでレプリカへの読み取りを転送し、実効スループットを最大3倍に拡大）
• 予測可能なピークがある場合は、ピーク60分前に最小ECPUを引き上げておく
• キャッシュするデータのサイズを削減してECPU消費量を最適化する

Serverless固有の制約事項

• クライアント要件: クラスタモード対応かつTLS必須のクライアントのみ接続可能です。TLS非対応のレガシークライアントは利用できません
• リザーブドノード非対応: node-basedのリザーブドノード割引はServerlessでは適用されません
• 対応エンジンバージョン: Valkey 7.2以上、Redis OSS 4.0.10〜7.1、Memcached 1.4.5以上（詳細はAWS公式ドキュメントで確認することを推奨します）
• 一部機能の制限: ElastiCache Serverlessは内部的にクラスタモードで動作するため、クラスタモード非対応の機能はご利用いただけない場合があります。詳細は公式ドキュメントをご確認ください

ValkeyエンジンとServerlessの組み合わせ

ElastiCache Serverless with Valkeyは、コスト効率（Redis OSSより約33%低価格）と自動スケールの両方のメリットを組み合わせた選択肢です。スパイキーなワークロードを新規で構築する場合、またはRedis OSSからValkeyへの移行と同時にServerlessへの移行も検討する場合は、この組み合わせが有力な候補になります。

既存のRedis OSSクラスタをValkeyへエンジン切替する際（前章で解説）、併せてServerlessへの移行も評価することで、コスト最適化と運用簡素化の両方を一度に実現できる可能性があります。

移行時の注意点: クライアントのクラスタモード対応確認

ElastiCache Serverlessはクラスタモードで動作するため、node-basedのスタンドアロン（クラスタモード無効）から移行する場合は、クライアントライブラリのクラスタモード対応状況を事前に確認することが重要です。

• redis-py: redis.cluster.RedisCluster クラスを使用
• Jedis: JedisCluster クラスを使用
• ioredis: new Redis.Cluster([...]) で接続
• go-redis: redis.NewClusterClient を使用

また、Serverlessはクラスタモードのため、同一コネクション内でのMULTI/EXECトランザクションは単一スロット（同一ハッシュスロット）内のキーに限られます。複数スロットにまたがるキーへのアトミック操作が必要な場合は、ハッシュタグ（{tag}）を使ってキーを同一スロットに配置する設計が必要です。TLS設定については、Serverlessはデフォルトでエンドツーエンドの暗号化が有効化されており、TLS接続が必須です。

CloudWatchによるServerlessの監視

ElastiCache Serverlessでは、従来のnode-basedとは異なるメトリクスセットで監視を行います。主要なメトリクスは以下のとおりです。

• ElastiCacheTotalECPU: 消費ECPUの合計（課金に直結）
• CacheHits / CacheMisses: キャッシュヒット率（Serverless性能の主要指標）
• ThrottledRequests: スロットリングされたリクエスト数（上限への接近を示す）
• BytesUsedForCache: 現在のキャッシュデータ使用量（最大格納量との比較）
• SuccessfulReadRequestLatency / SuccessfulWriteRequestLatency: 読み書きレイテンシ

これらのメトリクスをCloudWatchダッシュボードに集約し、ECPU消費量・キャッシュヒット率・スロットリング発生数を継続的に監視することをお勧めします。

4. Global Datastore とクロスリージョン可用性

4-1. Global Datastoreの仕組み

Global Datastoreは、Amazon ElastiCacheが提供するクロスリージョンレプリケーション機能です。
1つのプライマリリージョンのクラスターから、最大2つのセカンダリリージョンのクラスターへ非同期でデータをレプリケーションします。
プライマリへの書き込みがセカンダリへ伝搬されることで、リージョン障害時のDR（Disaster Recovery）と各リージョンでの低レイテンシ読み取りの両立を実現します。
単一リージョン内のElastiCacheクラスターにはないクロスリージョン可用性を実現する機能として、グローバル展開やマルチリージョンDRの要件がある場合に中心的な役割を担います。

対応エンジンとバージョン

Global DatastoreはElastiCache for ValkeyおよびElastiCache for Redis OSSでサポートされています。
ElastiCache for Memcachedは対象外です。
対応バージョンはValkey 7.2以降、Redis OSS 5.0.6以降です。
ElastiCacheのValkeyエンジンに切り替えた後も引き続きGlobal Datastoreを利用でき、コスト削減（§2参照）とクロスリージョン可用性の両方を同時に享受できます。

書き込みと読み取りの役割分担

プライマリリージョンのクラスターがすべての書き込みを受け付けます。
セカンダリリージョンのクラスターは読み取り専用として機能し、直接書き込むことはできません。
アプリケーションの書き込み先はプライマリリージョンのエンドポイントへ、読み取りはローカルのセカンダリクラスターのエンドポイントへそれぞれ向けるよう設計します。

対応インスタンスタイプ

Global DatastoreはM5・M6g・M7g・R5・R6g・R6gd・R7g・C7gnファミリーのlargeサイズ以上に対応しています。
旧世代のM4・R4等は対象外です。
プライマリとすべてのセカンダリクラスターでノードタイプ・エンジンバージョン・プライマリノード数・シャード数（クラスターモード有効時）を一致させる必要があります。
構成を揃える理由は、フェイルオーバー後にセカンダリが新プライマリとして即時稼働できる状態を保つためです。

利用上の前提条件

• VPCクラスターでのみ利用可能です（EC2-Classicは対象外）。
• クロスアカウントデプロイには対応しておらず、すべてのクラスターが同一のAWSアカウント内に存在する必要があります。
• セカンダリリージョン数は最大2つです（プライマリ1 + セカンダリ最大2の合計3リージョン構成が上限）。

Global Datastoreの作成方法

既存のElastiCacheクラスターからGlobal Datastoreを作成するには、ElastiCacheコンソールの「Global Datastores」メニューから「グローバルデータストアの作成」を選択します。
既存のクラスターをプライマリとして指定し、セカンダリリージョンとセカンダリクラスターの設定を行うと、AWS側でセカンダリクラスターのプロビジョニングとデータ同期が自動的に実行されます。
初回同期時のデータ転送量が多い場合は同期完了まで時間がかかることがあるため、初期セットアップは余裕を持ったタイムラインで計画してください。

4-2. クロスリージョンDR設計とセカンダリ昇格

手動フェイルオーバーの手順

Global Datastoreのリージョン間フェイルオーバーは手動操作で実行します。
プライマリリージョンで障害が検知された場合、ElastiCacheコンソールの「Global Datastores」画面または以下のAWS CLIコマンドでセカンダリクラスターをプライマリへ昇格させます。

aws elasticache failover-global-replication-group \
  --global-replication-group-id my-global-datastore \
  --primary-region ap-northeast-1 \
  --primary-replication-group-id my-primary-cluster

昇格処理は通常1分以内に完了します。
完了後、対象のセカンダリクラスターが書き込み可能なプライマリとして機能し始めます。

単一リージョン内のMulti-AZ自動フェイルオーバーとは仕組みが異なる点に注意が必要です。
Multi-AZの自動フェイルオーバーはElastiCacheが自動実行しますが、Global Datastoreのリージョン間フェイルオーバーは手動操作です。
このため、障害発生時の対応手順を事前に文書化し、チーム全員が実行できる体制を整えておくことが重要です。

エンドポイント切り替えの設計

フェイルオーバー後はアプリケーションの接続先をセカンダリ（昇格後プライマリ）リージョンのエンドポイントへ切り替える必要があります。
Global DatastoreはDNSの自動切り替えを提供しないため、以下のいずれかの方式で対応してください。

• Route 53フェイルオーバールーティング：プライマリエンドポイントのヘルスチェックと連動し、障害検知時に自動でセカンダリリージョンのレコードへ切り替えます。
• AWS Systems Managerパラメータストア：接続先エンドポイントをパラメータとして管理し、フェイルオーバー時に値を更新することでアプリケーション再起動なしに切り替えます。
• AWS AppConfig等の設定管理ツール：環境変数や設定ファイルを外部管理し、コード変更なしに接続先を切り替えられる設計にしておきます。

どの方式を選択するにしても、事前にフェイルオーバー手順をRunbookとして整備し、担当者全員が手順を理解した状態にしておくことが不可欠です。
CloudWatchのアラームダッシュボードにGlobal Datastoreの監視メトリクスを含めておくことで、オンコール担当者がフェイルオーバーの必要性を即座に判断できる環境を整えてください。
Runbookには「リージョン障害を確認してからフェイルオーバーを実行するまでの判断フロー」と「実行後に必要なすべての確認ステップ」を記載しておくと、障害対応時のオペレーションミスを防げます。

RTO（目標復旧時間）の設計指針

フェイルオーバー操作自体は1分未満で完了しますが、実際のRTOはエンドポイント切り替え・ヘルスチェック応答・アプリケーションの再接続確立を含む全体フローで決まります。
本番投入前にテスト環境でフェイルオーバー手順を演習し、RTO実測値を把握しておくことを強く推奨します。
演習で得たRTOをもとに、SLAや障害対応SLO（Service Level Objective）を定義してください。
また、演習は初回導入時だけでなく、定期的（四半期ごと等）に実施して手順の陳腐化を防ぐことも重要です。

RPO（目標復旧点）と非同期レプリケーションの考慮事項

Global Datastoreは非同期レプリケーションを採用しているため、プライマリでの書き込みがセカンダリへ反映されるまでにわずかなラグがあります。
通常はリージョン間のReplicationLagが1秒未満に収まりますが、ネットワーク輻輳時には増大することもあります。
プライマリリージョンで障害が発生した場合、未反映の書き込みデータはセカンダリには存在せずデータロスが発生します。

RPO設計ではReplicationLagの実測値を常に監視し、許容できる最大データロス量をシステム要件として定義してください。
キャッシュ用途（再計算・再取得可能なデータ）ではRPOの許容度が比較的高いケースが多いですが、金融取引データや在庫数量など書き込みロスが許容できないユースケースでは永続化ストアの使用を検討してください。

4-3. 低レイテンシのグローバル読み取り配信

ローカル読み取りのメカニズム

Global Datastoreのセカンダリリージョンでは、プライマリリージョンへのクロスリージョン通信なしにローカルのElastiCacheクラスターから読み取りを行えます。
東京リージョンのアプリケーションは東京のクラスターから、シンガポールリージョンのアプリケーションはシンガポールのクラスターからそれぞれ数ミリ秒の応答時間で読み取りを取得できます。
グローバルに展開するサービスにおいて、地理的な距離を超えた低レイテンシアクセスを実現するための重要な機能です。
特にユーザーの地理的分布が広いサービスでは、リージョンをまたぐ高レイテンシがUXを損なうリスクがあるため、Global Datastoreによるローカル読み取りの価値は大きくなります。

適したユースケース

• グローバルセッションストア：マルチリージョンに展開するWebサービスでユーザーのセッションデータをローカルのElastiCacheから取得します。ログイン状態・買い物カート・一時認証情報などを各リージョンで低レイテンシに参照できます。書き込みはプライマリリージョン経由で行い、非同期でセカンダリへ伝搬されます。
• ユーザープロフィール・コンテンツキャッシュ：読み取り頻度が高いプロフィールデータ・設定情報・商品メタデータ等をグローバルにキャッシュし、各リージョンからローカルで読み取ります。更新はプライマリ経由で行い、更新内容がセカンダリへ順次反映されます。
• DR待機構成（Active-Standby）：通常時はローカル読み取りに活用しながら、プライマリリージョン障害時にセカンダリを昇格させてDRエンドポイントとして機能させます。コストを最小化しながらDR体制を維持できる構成です。

読み取りルーティングの設計

グローバルセッションストアやキャッシュ用途では、アプリケーションが起動するリージョンのElastiCacheエンドポイントをローカル変数として保持する設計が一般的です。
各リージョンでデプロイされたアプリケーションインスタンスがそれぞれのリージョンのEndpointをデフォルトの読み取り先として設定することで、クロスリージョン通信を発生させずに読み取り性能を確保できます。

東京・大阪間の国内DR構成例

東京（ap-northeast-1）をプライマリ、大阪（ap-northeast-3）をセカンダリとする2リージョン構成は、東京リージョン障害に対する国内DRとして有効です。
平時は大阪リージョン向けトラフィックのローカル読み取りにも活用でき、クロスリージョン通信コストを削減できます。
2025年4月には15の追加リージョンでGlobal Datastoreのサポートが開始されており、グローバル展開においても選択肢が広がっています。
対応リージョンは随時拡大されるため、展開を検討しているリージョンでの最新サポート状況はAWS公式ドキュメントで確認してください。
国内2拠点構成（東京＋大阪）はゾーン障害ではなくリージョン全体の障害に対するDRとして機能するため、BCP（事業継続計画）での高可用性要件を満たす手段として有効です。

4-4. 制約・コスト・運用監視

コスト構成

Global Datastoreを利用すると通常のElastiCacheクラスター費用に加えて以下の追加コストが発生します。

• セカンダリクラスターのノード料金：セカンダリリージョンにも常時稼働するクラスターが必要なため、ノード料金がリージョン数分増加します。セカンダリ1リージョンの場合、ノード料金は実質約2倍になります。
• クロスリージョンデータ転送料金：プライマリからセカンダリへのレプリケーションデータに対してクロスリージョン転送料金が課金されます。書き込み量が多いワークロードでは転送料金が相応に増加します。

グローバル可用性・クロスリージョンDR・低レイテンシ読み取りの事業要件と費用対効果を慎重に評価した上で採用可否を判断することをお勧めします。

ReplicationLagの監視

CloudWatchメトリクスのReplicationLagを使用して、クロスリージョンのレプリケーション健全性を継続的に監視します。
Redis OSS 5.0.6以降ではミリ秒精度で計測され、セカンダリクラスターがプライマリからどれだけ遅延しているかを示します。
ElastiCacheコンソールの「Global Datastores」→「Regional Clusters」でも確認できます。

推奨アラームとして、ReplicationLagがワークロード要件に応じた閾値（例: 2〜5秒）を超えた際にCloudWatch Alarmで通知する設定を準備してください。
ラグの急増はネットワーク問題やプライマリクラスターの高負荷を示すシグナルであるため、早期検知によってフェイルオーバー判断や負荷軽減措置を迅速に取れます。
ReplicationLagは単なるネットワーク遅延だけでなく、プライマリクラスターの高負荷（書き込みバーストや大型コマンド実行）でも増大するため、ラグ発生時はプライマリのCPUとメモリ状況も合わせて確認してください。

主要監視メトリクス一覧（Global Datastore）

セカンダリクラスターの健全性確認

フェイルオーバーを確実に実行するためには、セカンダリクラスターが常に健全な状態である必要があります。
セカンダリのCPU・メモリ使用率・接続数等のメトリクスをプライマリと同等に監視してください。
定期的なフェイルオーバー演習と合わせて、セカンダリクラスターの健全性確認を運用手順に組み込んでおくことを推奨します。

旧プライマリの再参加

プライマリリージョン障害から復旧した後は、旧プライマリをセカンダリとしてGlobal Datastoreに再参加させることでクロスリージョン構成を再構築できます。
再参加時には新プライマリ（旧セカンダリ）のデータが旧プライマリへ同期されます。
再参加後は、アプリケーションのエンドポイント設定を元のリージョンへ戻すか、新しいプライマリリージョンのまま継続するかを事業要件に照らして判断してください。

Global Datastoreの設計チェックリスト

Global Datastoreとマルチリージョンアーキテクチャの選択

Global Datastoreはクロスリージョンのレプリケーションにおいて非常に効果的な機能ですが、すべてのマルチリージョン要件に対して唯一の解ではありません。
ユースケースによっては、他のアーキテクチャパターンとの組み合わせや代替手段が適していることがあります。

例えば、読み取りの大半が特定のリージョンに集中する場合は、Global Datastoreのセカンダリリージョンから直接読み取ることで低レイテンシを実現できます。
一方、書き込みも複数リージョンで行う必要があるActive-Active構成（双方向書き込み）は、Global Datastoreの非同期一方向レプリケーションでは実現できません。
その場合は、アプリケーション側でのデータ分散（ユーザーIDのリージョン固定など）やAmazon DynamoDB Global Tablesなど永続ストアレイヤーでの多地点書き込み対応を検討してください。

ElastiCacheのGlobal Datastoreは「読み取りのローカル化とリージョンDR」に特化した機能として位置づけ、マルチリージョン全体の設計の中で適切な役割を割り当てることが重要です。

5. データ階層化とオンライン再シャーディング — 大容量・無停止スケール

5-1. データ階層化（r6gd・メモリ+SSD・大容量低コスト）

データ階層化（Data Tiering）は、r6gdノードファミリーが提供するメモリとローカルNVMe SSDの2層ストレージ構成です。
アクセス頻度の高いホットデータはDRAMメモリへ、アクセス頻度の低いコールドデータはNVMe SSDへ自動的に退避されます。
これにより、大容量のデータセットをメモリのみのノードより低コストで保持できます。

ElastiCache for ValkeyおよびElastiCache for Redis OSSでサポートされています（Memcachedは対象外）。
東京リージョン（ap-northeast-1）でもr6gdノードが利用可能です。
クラスターモード有効（Cluster Mode Enabled）・クラスターモード無効（Cluster Mode Disabled）の両方の構成でデータ階層化を利用できます。

r6gdノードの性能と容量

r6gdノードはメモリとSSDの合計容量がr6gノード（メモリのみ）の最大4.8倍に達します。
最大利用時のコストはr6gと比較して60%以上削減できます。
最大ノードサイズのcache.r6gd.16xlargeを使用した500ノードクラスターでは、最大1ペタバイトのデータを扱えます。
こうした大容量対応により、これまでオンプレミスの大規模KVSが必要だったユースケースをElastiCacheに集約する選択肢が広がっています。

r6gdノードのサイズラインナップはlarge・xlarge・2xlarge・4xlarge・8xlarge・12xlarge・16xlargeが用意されています。
最新の対応インスタンスサイズや料金はAWS公式の料金ページで確認してください。
r6gdはAWS Graviton2プロセッサーを採用しており、同世代のIntelベースのインスタンスと比較してコストパフォーマンスに優れた選択肢です。
Global Datastoreと組み合わせることで、クロスリージョンにわたった大容量低コストアーキテクチャを実現できます。

データ階層化の動作原理

ElastiCacheがアクセスパターンを自動的に分析し、キーのアクセス頻度に応じてメモリとSSDの間でデータを動的に移動します。
アプリケーション側での特別な設定や変更は必要なく、既存のValkey/Redisコマンドをそのまま使用できます。
ただし、SSDに退避されたデータへのアクセスはメモリから直接読み取る場合と比較して若干高いレイテンシが発生します。

ElastiCache for ValkeyまたはRedis OSSクラスターがr6gdファミリーのノードタイプを使用している場合、データ階層化は自動的に有効になります。
クラスター作成時またはノードタイプ変更時にr6gdを選択するだけで機能が有効になります。

5-2. データ階層化の適用判断

適用すべきユースケース

データ階層化が効果的な条件は以下のとおりです。

• 大容量データセット：総データ量が数十GB〜数TB規模で、メモリのみのノードでは費用対効果が合わない場合に有効です。
• アクセスパターンに偏りがあるワークロード：全体のデータセットのうち常時アクセスされるデータが20%以下のケースで最大の効果を発揮します。ユーザー行動履歴の長期キャッシュ・タイムシリーズデータの古いレコード・コンテンツライブラリのニッチカテゴリーデータなどが該当します。
• コスト削減を優先するシナリオ：SSDアクセス時の若干のレイテンシ増加を許容できるユースケースで、最大60%以上のコスト削減効果が見込めます。

適用を避けるべきユースケース

以下のケースではデータ階層化は推奨しません。

• 均一アクセスパターン：すべてのキーに均等にアクセスするワークロードでは、ホット/コールドの区別ができずメモリとSSD間の頻繁なデータ移動オーバーヘッドが発生します。
• マイクロ秒レベルのレイテンシ要求：リアルタイム決済処理・高頻度取引・ゲームのマッチングサーバーなど、マイクロ秒単位の応答が要件の場合はSSD読み取りのレイテンシが許容外になります。
• 小規模データセット：全データがメモリに収まる規模では、データ階層化を使う意義がありません。

ユースケース別の選択ガイド

性能トレードオフの評価方法

本番環境への導入前に、実際のアクセスログを分析して全体データセットの何%がコールドデータになるかを見積もることをお勧めします。
ステージング環境でr6gdノードに移行し、負荷テスト下でのp99レイテンシを計測してSLA要件を満たせることを確認してから本番適用してください。
CloudWatchのキャッシュヒット率やレイテンシのパーセンタイルメトリクスをr6gノード時代と比較することで、データ階層化の採用による実際の性能影響を定量的に評価できます。
比較評価では平均値ではなくp99（99パーセンタイル）を確認することが重要で、SSDアクセスが発生するケースでの最悪値を把握してSLA設計に反映してください。

5-3. オンライン再シャーディング（無停止・スロット再配置・性能影響）

オンライン再シャーディングの概要

オンライン再シャーディング（Online Resharding）は、クラスターモード有効（Cluster Mode Enabled）のElastiCache for ValkeyおよびElastiCache for Redis OSSクラスターで、稼働中のまますシャードを追加・削除してサービスを継続する機能です。
Valkey 7.2以降またはRedis OSS 3.2.10以降で利用できます。

16,384個のハッシュスロットを各シャードに再配分する処理がバックグラウンドで実行されます。
この間もクラスターは読み取り・書き込みリクエストに応答し続けます。
ElastiCacheコンソール・AWS CLI・CloudFormationから操作できます。

スロット再配置の仕組み

シャードを追加する場合、既存シャードが保持するスロットの一部を新シャードへ移行します。
移行は1スロット単位で順次実行され、移行中の各スロットへの書き込みリクエストは元のシャードで処理されます。
移行が完了したスロットへのリクエストは新シャードへ転送されます。
データ移行速度はおよそ1GB/分のペースで進行します。

性能への影響

再シャーディング中も書き込みリクエストは処理されますが、移動中のスロットへの書き込みには若干のスループット低下が発生します。
クラスターがキャパシティ上限に近い状態ではクライアントの書き込みがスロットリングされることがあり、リクエスト処理時間が増加することに注意が必要です。

再シャーディング中は以下のコマンドの使用を避けてください。

• KEYS・SMEMBERS：処理遅延を大幅に増大させます。
• FLUSHDB・FLUSHALL：再シャーディング処理を中断・失敗させます。

スケジューリングの推奨

再シャーディング操作はクラスターに相応の負荷がかかります。本番環境での推奨事項は以下のとおりです。

• 低負荷時間帯（メンテナンスウィンドウ）での実施：トラフィックが少ない時間帯を選ぶことでサービスへの影響を最小化できます。
• 事前のCPU使用率確認：マルチコアインスタンスでは80%未満、シングルコアインスタンスでは50%未満を目安とします。この閾値を超えた状態での再シャーディングはレイテンシへの影響が大きくなります。
• クライアントタイムアウトの延長：負荷増加時の接続エラーを抑制するため、再シャーディング中はクライアントライブラリの接続タイムアウトを通常より長めに設定しておくことを推奨します。
• 段階的スケール：一度に多くのシャードを追加するのではなく、1〜2シャードずつ追加して影響を確認しながら進めることが安全です。

シャード追加と削除の使い分け

• シャード追加（スケールアウト）：データ量またはリクエスト数が増加し、既存シャードのメモリやCPUが逼迫している場合に実施します。新しいシャードへスロットが再配分されて負荷が分散されます。
• シャード削除（スケールイン）：負荷が低下した時期に余剰シャードを削除してコストを最適化します。削除されるシャードのスロットは残存シャードへ再配置されます。

シャード削除時は、削除後に残存シャードのメモリ使用率が許容範囲（DatabaseMemoryUsagePercentageの推奨は75%以下）に収まることを事前に計算して確認してください。
容量を超えた削除はevictionの急増やOOMエラーを引き起こす恐れがあります。
シャードの最大数は250で、これ以上のスケールが必要な場合はノードタイプのアップサイズ（スケールアップ）を組み合わせた設計を検討してください。

5-4. 大規模スケールの運用設計

スケールアウト計画の立て方

オンライン再シャーディングは無停止で実行できますが、計画的に行うことが重要です。
日次・週次のトラフィックトレンドを分析し、シャード追加が必要なタイミングを事前に把握してください。
急激な負荷増加が予想されるイベント（セール・キャンペーン・新機能リリース等）の前にあらかじめシャード数を増やしておくことで、ピーク時の再シャーディングによる性能影響を回避できます。

Auto Scalingの活用

ElastiCache for ValkeyおよびElastiCache for Redis OSS（クラスターモード有効）はAuto Scalingに対応しています。
Application Auto Scalingを利用して、シャード数をCPU使用率・メモリ使用率・キャパシティ消費率に応じて自動的に増減させるターゲット追跡スケーリングポリシーを設定できます。

• ターゲット追跡スケーリング：EngineCPUUtilization・DatabaseMemoryUsageCountedForEvictPercentage・DatabaseCapacityUsageCountedForEvictPercentageのいずれかをターゲットメトリクスとして設定します。
• スケジュールドスケーリング：定期的なトラフィックパターン（平日昼間に増加・夜間に減少など）が予測可能な場合は、スケジュール設定で事前にシャード数を調整できます。
• スケールの上限：最大250シャードまでスケールアウト可能です。最大値をAuto Scalingポリシーで制限できます。

ただし、Auto ScalingによるシャードスケールはElastiCacheが実際の負荷が一定時間継続した場合に実行するため、瞬間的なスパイクへの対応としては即応性が限られます。
予測できる急激なトラフィック増加に対しては手動での事前スケールが有効です。

主要監視メトリクス（大規模クラスター）

大規模クラスターの継続的な健全性確認には以下のCloudWatchメトリクスを監視します。

データ階層化（r6gdノード）を利用する場合は、上記に加えてSSDへの退避状況も参照し、ホットデータとコールドデータの比率がワークロードの想定と合致しているかを確認してください。
SSD退避されるデータ量が想定より多い（コールドデータが多い）場合はコスト効果大、逆に均一アクセスになっている場合はr6gノードへの変更を検討します。

スケールアウト vs スケールアップの基本的な判断軸については、Database本番運用Vol3 §2-6を参照してください。

r6gdノードへの切り替え手順

既存のElastiCacheクラスターをデータ階層化に対応したr6gdノードへ移行するには、以下の手順が一般的です。

1. ノードタイプの変更操作: ElastiCacheコンソールで対象クラスターを選択し「クラスターの変更」からノードタイプをr6gdに変更します。変更はメンテナンスウィンドウで適用するか即時適用を選択できます。
2. ローリング更新: Multi-AZが有効な場合、ローリング更新によってクラスターは書き込みサービスを継続しながら移行されます。
3. データ移行の自動処理: 既存データはr6gdノードに自動的にコピーされます。データ量に応じて移行時間が変わるため、大容量クラスターではメンテナンスウィンドウを十分に確保してください。
4. 移行後の確認: 移行完了後にCloudWatchメトリクスのレイテンシ・ヒット率・eviction数が想定範囲内であることを確認します。

データ階層化・オンライン再シャーディング 運用チェックリスト

データ階層化とシャードスケールの使い分け

ElastiCacheの大容量化には「データ階層化（r6gd）」と「シャード増加（オンライン再シャーディング）」の2つのアプローチがあります。
それぞれ異なる問題を解決するため、ワークロードの特性に応じて適切に選択・組み合わせてください。

• データ階層化（r6gd）が適するケース：単一シャードまたは少数シャードで大量のデータを保持したい場合。アクセスに偏りがあってコールドデータが多い場合に最もコスト効果が高くなります。
• シャード増加が適するケース：リクエスト数（スループット）が増加してCPUやネットワーク帯域がボトルネックになっている場合。データ量とリクエスト数の両方を分散できます。
• 両方の組み合わせ：大容量かつ高スループットが要件の場合は、r6gdノードでシャードを構成したクラスターでオンライン再シャーディングを活用する構成が有効です。r6gdはGlobal Datastoreとも組み合わせ可能です。

定期的なキャパシティレビューとしては、月次でCloudWatchのCPU使用率・メモリ使用率・eviction数・キャッシュヒット率のトレンドを確認し、スケール計画を早期に策定することをお勧めします。
実際のワークロードの伸びを基に6ヶ月・1年後の必要容量を予測し、段階的なスケール計画を立てておくことで、急な容量不足やコスト最適化の機会を逃すリスクを低減できます。
ElastiCacheのAuto Scalingポリシーと合わせて手動スケールの計画を組み合わせることで、予測可能なピークへの対応とコスト効率の両立が可能になります。
データ階層化とオンライン再シャーディングはそれぞれ独立した機能ですが、大容量・高スループット・低コストの三要件を同時に満たすためには両機能を組み合わせた設計が最も効果的です。

6. 高度運用 — RBAC/ACL設計・詳細監視・スロットリング対応

ElastiCacheの本番運用においては、認証・認可の細粒度設計、CloudWatchによる詳細監視、そしてスロットリングや過負荷への対応が運用の成熟度を左右します。TLS設定やRBACの基礎については基礎編で解説済みですので、本§では高度なACL設計・詳細監視ダッシュボード・スロットリング対応に絞って解説します。

6-1. 高度なRBAC/ACL設計

TLS in-transit暗号化やRBACの有効化手順は基礎編（Database本番運用Vol3 §2-3）に委ねます。本節では、RBAC有効化後の運用を深掘りします。

用途別ユーザーの分離設計

ElastiCacheのRBAC（Redis ACL）では、用途ごとに専用ユーザーを作成し最小権限を付与することが推奨されます。代表的な3層設計は以下のとおりです。

read-only-user: @read ~* &*
write-user : @read @write ~app:* &*
admin-user : allcommands allkeys allchannels

• read-only-user：参照系APIサーバーや分析バッチに割り当て、書き込み不可
• write-user：アプリケーションサーバーに割り当て、操作対象キーをプレフィックスで限定（~app:*）
• admin-user：管理ツールや緊急対応用途に限定し、通常のアプリフローでは使用しない

コマンドカテゴリによる制限

ElastiCacheはRedisのACLコマンドカテゴリをサポートしています。主なカテゴリを以下に示します。

本番環境では @dangerous カテゴリのコマンドをアプリユーザーから除外するだけでも、誤操作によるデータ全消去リスクを大幅に低減できます。

Secrets Manager連携による認証情報ローテーション

ElastiCacheのユーザーパスワードをAWS Secrets Managerで管理することで、定期的な自動ローテーションが実現できます。

ローテーションの基本フローは以下のとおりです。

1. Secrets ManagerでElastiCacheユーザー用のシークレットを作成する
2. ローテーションLambda関数を設定し、例えば30日ごとに実行されるようスケジュールする
3. Lambda関数がElastiCacheのパスワードを更新し、同時にSecretsに新パスワードを書き込む
4. アプリケーションはGetSecretValueでSecretsから最新パスワードを取得して接続する

ローテーション中の二重パスワード（current/pending）対応に注意が必要です。ElastiCacheユーザーはパスワードを最大2個まで保持できるため、ローテーション期間中もアプリ側は既存パスワードで接続し続けられます。

IAM認証トークン（ElastiCache Serverless + Redis 7.0以降）

ElastiCache ServerlessおよびRedis 7.0以降のクラスターでは、IAM認証を使ってパスワードレスで接続できます。

# ElastiCacheへのIAM認証トークン取得（aws cliで確認）
aws elasticache generate-auth-token \
  --replication-group-id my-cluster \
  --user-id my-iam-user

IAM認証を使う利点は、IAMポリシーによるアクセス制御とCloudTrailによる接続監査が一元管理できる点です。ただし、接続ライブラリ側のIAM認証トークン対応状況を事前に確認してください。

6-2. 詳細監視ダッシュボード設計

ElastiCacheはCloudWatchに多数のメトリクスを出力します。node-based構成で特に重要な主要メトリクスとアラート閾値の目安を以下に整理します。

主要メトリクスとアラート閾値の目安

これらの閾値はあくまで一般的な目安です。実際の閾値はワークロードの特性（バッチ集中型・リアルタイム型等）によって変動しますので、本番の負荷傾向を観察しながら調整してください。

eviction policy（maxmemory-policy）の選択

メモリが満杯になったときの挙動を制御するmaxmemory-policyは、ユースケースに合わせて適切に選択します。

キャッシュ専用のElastiCacheではallkeys-lruまたはallkeys-lfuが一般的です。noevictionは誤って設定するとアプリに書き込みエラーが返るため、適用前に影響範囲を必ず確認してください。

6-3. スロットリング/過負荷対応

ThrottledCommandsの診断と対応

ThrottledCommandsはElastiCacheがレート制限を超えた際にスロットリングしたコマンド数です。このメトリクスが発生し始めたら以下を確認します。

1. 接続数の確認：CurrConnectionsが急増していないか。接続プール設定の見直しが必要な場合があります。
2. コマンドレートの確認：CmdStat*系メトリクスで特定コマンドが集中していないか。
3. スケールアップ/スケールアウトの検討：処理能力が恒常的に不足している場合は、ノードタイプの変更やシャード追加を検討します。

ホットキー問題の対策

特定のキーに読み書きが集中する「ホットキー」は、クラスターの一部シャードに偏ったCPU・ネットワーク負荷をもたらします。

主な対策は以下のとおりです。

• キー名への後置サフィックス分散：product:1234:shard0〜product:1234:shard7のように複数キーに分散し、アプリ側でランダムまたはラウンドロビンでアクセス
• ローカルキャッシュ（アプリ内メモリ）との二段階キャッシュ：最もホットなキーをアプリプロセスのメモリにも短時間キャッシュし、ElastiCacheへのアクセス頻度を下げる
• 読み取りレプリカへの分散：読み取り系ホットキーはレプリカエンドポイントへルーティング

大きなキー（Large Key）問題の回避

1MB超の大きな値を単一キーに格納すると、シリアライズ/デシリアライズのCPUコストとネットワーク帯域の消費が問題になります。大きなキーが疑われる場合はRedis CLIの--bigkeysオプションで確認できます。

redis-cli -h <endpoint> -p 6379 --bigkeys

対策として、大きなオブジェクトはフィールド分割（HASHによる部分取得）、または値の圧縮（アプリ側でgzip等）を検討します。

SLOWLOGによるスロークエリ検出

ElastiCacheでもSLOWLOGコマンドによってスロークエリを検出できます。

# 閾値を10ms（10000マイクロ秒）に設定し、遅延コマンドを記録
CONFIG SET slowlog-log-slower-than 10000

# 直近のスロークエリを確認
SLOWLOG GET 25

SLOWLOGエントリには実行時間・コマンド・引数が記録されます。定期的にSLOWLOGをチェックし、KEYS *のような全キースキャンや大きなコレクション操作が混在していないか確認します。

接続数上限とConnectionsExceeded対策

CurrConnectionsが急増する主因はアプリの接続プール設計ミス（1リクエストごとに新規接続する等）です。対策として以下を確認します。

• 接続プールライブラリの使用（jedis pool、redis-py ConnectionPool等）
• プールのmaxTotal/maxIdle設定の見直し
• コネクションリークの検出（接続数が増加し続けてリセットされない場合）

ElastiCacheのノードタイプごとに最大接続数の目安が異なります。公式ドキュメントの「ノードタイプ別スペック」で確認してください。

6-4. Serverlessでの監視差異

ElastiCache Serverlessはnode-basedとは異なるキャパシティモデルのため、監視すべきメトリクスも変わります。

ServerlessではElastiCacheProcessingUnitsがコストに直結するため、このメトリクスの急増（バッチ処理の集中実行等）に注意してCloudWatchアラームを設定することを推奨します。ノードタイプを持たないため、EngineCPUUtilizationは参照できない点に注意が必要です。

CloudWatchアラーム設定の例（AWS CLI）

node-based構成でのメモリ使用率アラームを設定する例を示します。

aws cloudwatch put-metric-alarm \
  --alarm-name "ElastiCache-HighMemoryUsage" \
  --metric-name DatabaseMemoryUsagePercentage \
  --namespace AWS/ElastiCache \
  --dimensions Name=CacheClusterId,Value=my-cluster-001 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:my-alert-topic

主なパラメータの意味を以下に整理します。

短期スパイクでアラートが頻発するのを防ぐため、--evaluation-periodsを2〜3に設定して連続超過を条件にすることが多いです。

ダッシュボードの構成例

CloudWatchカスタムダッシュボードに以下のウィジェットを配置することで、ElastiCacheの健全性を一覧で把握できます。

1. メモリ・evictionパネル：DatabaseMemoryUsagePercentageとEvictionsを並べて表示。メモリ増加とeviction発生の相関を確認。
2. ヒット率パネル：CacheHitsとCacheMissesから算出したヒット率の時系列グラフ。
3. 接続・スロットリングパネル：CurrConnectionsとThrottledCommandsを並べて、過負荷の予兆を監視。
4. レイテンシパネル（Serverless）：ElastiCacheProcessingUnitsのコスト推移とSuccessfulReadRequestLatency/SuccessfulWriteRequestLatencyを並べて表示。

特にEvictionsとCurrConnectionsの急増は本番障害の前兆となることが多く、これらのアラームを最初に整備することを推奨します。

7. 統合設計と移行ロードマップ — Valkey + Serverless + 高度運用

§2〜§6で扱った各機能を単独で導入するだけでなく、それらを組み合わせて段階的に運用を成熟させることがElastiCacheの高度運用における最終目標です。本§では各機能の組み合わせ方と、既存Redis OSS環境から段階的に移行するロードマップを提示します。各機能の詳細説明は該当§を参照してください。

7-1. 統合アーキテクチャ

高度運用を実現する統合アーキテクチャの要素を整理します。

Valkey基盤

エンジン選択の起点としてValkeyを採用することで、同等機能をRedis OSSより低コスト（node型で約20%減、Serverlessで約33%減）で運用できます。2024年10月のGA以降、東京リージョンでも利用可能になっており、新規クラスターおよびRedis OSSからの移行両面で選択肢となっています。

Serverless / node-basedの選択

Valkey基盤の上でキャパシティモデルを選択します。

• Serverless：スパイキーな負荷・トラフィック予測が難しい場合。ECPU従量課金で過剰キャパシティを持たずに済む。
• node-based（Reserved Instance）：安定した高スループット・コスト予測が必要な場合。リザーブドインスタンス割引で長期コストを最適化。

Global Datastoreによるクロスリージョン可用性

単一リージョン内のMulti-AZ（基礎編参照）に加え、Global Datastoreでクロスリージョンレプリケーションを導入することで、リージョン障害時のDR（災害復旧）と地理的に近いリージョンからの低レイテンシ読み取りを実現します。

データ階層化（r6gd）による大容量低コスト化

データセットがメモリに収まらなくなった段階でr6gdノードのデータ階層化を導入することで、ホットデータはメモリ・コールドデータはNVMe SSDに自動的に配置し、GBあたりのコストを抑えます。

高度なACL設計と詳細監視

§6で解説した用途別ユーザー設計・Secrets Manager連携・詳細CloudWatchアラームを組み合わせることで、セキュリティと可観測性の両面で運用を成熟させます。

機能間の依存関係

各機能の前提条件をまとめます。

機能間の組み合わせ可否（特にServerlessとデータ階層化の併用、Global DatastoreとValkeyの対応）は、リリース状況によって変わることがあります。実装前に必ず公式ドキュメント（Amazon ElastiCacheユーザーガイド）で最新の対応状況を確認することを推奨します。

7-2. 段階的移行ロードマップ

既存のRedis OSSクラスター（node-based）から高度運用へ至る参考ロードマップを提示します。あくまで参考例であり、実際のチームのユースケース・組織の優先度によって順序や省略するフェーズは異なります。

Phase 1: Redis OSS → Valkey エンジン移行（コスト最適化）

最も即効性の高い取り組みです。既存クラスターのエンジンをValkey互換バージョンに切り替えることで、追加の機能変更なしにコスト削減（node約20%減）を実現できます。

実施ステップの概要：

1. 現行Redis OSSのバージョンと対応するValkeyバージョンを公式ドキュメントで確認
2. ステージング環境でエンジン切替を実施し、アプリの動作を検証（コマンド互換性・クライアントライブラリの確認）
3. 本番環境でのエンジン切替（インプレース方式または新規クラスター作成+データ移行方式を選択）
4. 切替後のメトリクス（ヒット率・レイテンシ・エラー率）を確認し、異常がなければRedis OSSに戻せる準備を整えた上で完了

Phase 2: 負荷特性に応じたServerless / node最適化

Valkey移行後、実際の負荷特性を計測してキャパシティモデルを見直します。

• トラフィックのスパイクが大きく、常時高いキャパシティを維持するコストが問題な場合 → Serverlessへの移行を検討
• 安定した高スループットでコスト予測が重要な場合 → node-based + Reserved Instanceを継続

Serverlessへの移行時は§3で解説したECPUコスト計算と機能制限の事前確認が必要です。

Phase 3: 大容量化・グローバル展開

データ量の増大やグローバルなユーザー展開が必要になった段階で以下を検討します。

• データ量が急増してメモリコストが課題になった場合：r6gdノードのデータ階層化を導入（§5参照）
• リージョン障害に対するDRや海外ユーザーへの低レイテンシ提供が必要な場合：Global Datastoreによるクロスリージョンレプリケーションを導入（§4参照）

Phase 3の施策はシステムのスケールや可用性要件が具体化してから導入するものです。過早な導入はコスト増加の要因になるため、実際のビジネス要件に合わせて判断してください。

データ階層化とGlobal Datastoreはどちらも「より大きなシステム規模」を前提とした機能です。データ階層化は総データサイズがメモリに収まらなくなった段階で効果を発揮し、Global Datastoreはマルチリージョン展開の必要性が生まれた段階で価値を持ちます。Phase 3に進む前に、現行システムの実際のデータサイズ・アクセスパターン・可用性要件を改めて計測・整理することを推奨します。

大容量化の判断基準

以下の条件を複数満たす場合、データ階層化（r6gd）の導入を検討します。

• DatabaseMemoryUsagePercentageが継続して70〜80%を超えている
• アクセスパターンを分析すると、キーの相当数がコールドデータ（長期間アクセスなし）である
• メモリ増強（より大きなノードへのスケールアップ）よりもr6gdのコストが有利である

グローバル展開の判断基準

以下の条件を複数満たす場合、Global Datastoreの導入を検討します。

• RPO（目標復旧ポイント）がリージョン障害に対して厳格に定められている
• 複数リージョンのエンドユーザーに対してキャッシュからの低レイテンシ読み取りが求められる
• 書き込みはプライマリリージョンに集約できる（セカンダリは読み取り専用の構成で受容できる）

Phase 4: 高度なACL + 詳細監視 + スロットリング対応（運用成熟）

どのフェーズにいても並行して進められる取り組みです。

• 用途別ユーザー設計とSecrets Manager連携（§6-1参照）
• CloudWatch詳細メトリクスとアラームの整備（§6-2参照）
• ホットキー・大きなキー・SLOWLOGの定期確認（§6-3参照）

これらは一度きりの作業ではなく、継続的な改善サイクルとして運用プロセスに組み込むことが重要です。

7-3. 機能間の相互作用と設計トレードオフ

統合設計において考慮すべき主なトレードオフを整理します。

Valkey + Serverlessの組み合わせ

ElastiCache ServerlessはValkey/Redis OSS/Memcachedをサポートしています。Valkeyエンジン選択とServerlessの組み合わせは、コスト最適化の観点から有力な選択肢です。ただし、対応バージョンや一部機能の制限については、利用開始前に公式ドキュメントで最新状況を確認することを推奨します。

Global Datastore + Valkeyの対応状況

Global DatastoreはRedis系クラスターを対象としています。Valkeyとの組み合わせについては、AWSの公式ドキュメント（Global Datastore for Redis）で最新の対応状況を確認してください。リリースタイミングによって対応バージョンが変わることがあります。

データ階層化 + Serverlessの組み合わせ可否

データ階層化（r6gdノード）はnode-based構成の機能であり、Serverlessと同時に使用することはできません。大容量データセットをServerlessで扱いたい場合は、Serverless自体の自動スケーリングによるメモリ拡張を活用し、データ階層化はnode-based構成を選択した際に適用します。

Global Datastore + データ階層化の組み合わせ

両機能の組み合わせについても、公式ドキュメントの制約事項を事前に確認してください。機能の組み合わせ可否は、AWSのアップデートに伴い変化することがあります。

7-4. 本番導入の判断チェックポイント

各フェーズを本番環境に適用する前に、以下のチェックリストを確認することを推奨します。

Phase 1（Valkey移行）実施前チェック

• [ ] 現行Redis OSSのバージョンと、対応するValkeyバージョンを確認した
• [ ] アプリケーションで使用するRedisコマンドのValkey互換性を検証した
• [ ] クライアントライブラリがValkeyに対応しているか確認した（設定変更不要なケースが多いが要確認）
• [ ] ステージング環境でのエンジン切替テストが完了し、問題がないことを確認した
• [ ] ロールバック手順（元のRedis OSSへの戻し方）を準備した

Phase 2（Serverless移行）実施前チェック

• [ ] Serverlessが対応していない機能（node固有の設定等）を使用していないか確認した
• [ ] 現行の月次コストとECPUモデルの試算コストを比較し、移行メリットを確認した
• [ ] Serverlessの接続エンドポイント変更に伴うアプリ設定の更新計画を立てた

Phase 3（Global Datastore/データ階層化）実施前チェック

• [ ] セカンダリリージョンへの書き込みレプリケーション遅延（ReplicationLag）が許容範囲内か確認した
• [ ] リージョン間のデータ転送コストを試算した
• [ ] データ階層化（r6gd）のワークロードがデータ階層化の恩恵を受けるか（コールドデータ比率が高いか）確認した

Phase 4（高度ACL/監視）継続チェック

• [ ] 全アプリユーザーが最小権限のACLユーザーで接続しているか確認した
• [ ] Secrets Managerのローテーションが正常に動作しているか確認した
• [ ] CloudWatchアラームが設定され、通知テストが完了しているか確認した
• [ ] SLOWLOGの定期確認をチームの運用プロセスに組み込んだ

ロールバック基準の原則として、各フェーズの移行後24〜72時間はエラーレート・レイテンシ・ヒット率の変化を注視し、基準値から有意に外れた場合は前フェーズの構成に戻せる準備を維持することを推奨します。

各フェーズのコスト・効果サマリ

参考として、各フェーズで期待できる効果を整理します。実際の数値はワークロードや選択するノードタイプによって異なります。

運用サイクルに組み込むべき定期タスク

ElastiCacheの高度運用は一度設定して終わりではなく、継続的な改善が前提です。定期的に実施することを推奨するタスクを示します。

• 月次：CloudWatchアラームの閾値見直し（負荷傾向の変化に合わせて調整）
• 月次：SLOWLOGの確認とボトルネックコマンドの特定
• 四半期：ACLユーザーの棚卸し（不要ユーザーの削除・権限の最小化再確認）
• 四半期：Secrets Managerのローテーション動作確認とパスワード変更ログの監査
• 半期：ノードタイプ・Reserved Instanceの見直し（Valkeyの新バージョン・新インスタンスタイプのチェック）

これらのタスクをチームのRunbookに明示的に記載し、担当者と実施タイミングを決めておくことで、属人的な運用を排除できます。

コスト最適化の判断フロー

移行後にコストが想定より高い場合の判断フローを示します。

1. ElastiCacheProcessingUnits（Serverless）またはCurrConnections・ノード数（node-based）を確認
2. Serverless構成でECPUが高い場合 → ホットキー対策・アプリ側キャッシュとの二段階化を検討
3. node-based構成でノード数が多い場合 → データ階層化（r6gd）による集約またはServerlessへの移行を検討
4. Reserved Instanceの適用漏れがないか確認（On-Demandのまま長期稼働はコスト増の主因）

これらの判断軸をチームで共有しておくことで、コスト最適化の意思決定を迅速に進めることができます。

ElastiCacheの高度運用は一度完成するものではなく、ビジネスの成長と技術スタックの変化に合わせて継続的に見直すものです。Valkeyエンジンの採用からはじまり、Serverless・Global Datastore・データ階層化・高度なACLと詳細監視を段階的に積み重ねることで、コスト効率・可用性・セキュリティの三軸すべてで優れたキャッシュ基盤を構築できます。

8. まとめ — ElastiCache高度運用のベストプラクティス

8-1. 5テーマの要点サマリ

§2 Valkey移行

Redis OSSのライセンス変更（2024年3月）を背景に、Linux Foundation傘下のオープンソースフォーク「Valkey」が2024年10月にElastiCacheでGA（一般提供）されました。
コスト面では、Serverlessで約33%・ノードベースで約20%の削減が見込めます。
Redis OSSとの高い互換性（コマンド・データ構造・クライアントライブラリ）を維持しながら、インプレースのエンジン切替で移行できます。
新規クラスタはValkeyが推奨です。

§3 ElastiCache Serverless

2023年11月GAのElastiCache Serverlessは、ECPU（ElastiCache Processing Unit）消費量とデータ格納量（GB-hr）による完全従量課金モデルです。
キャパシティ計画不要・自動スケールが特長であり、スパイキーな負荷や予測困難なトラフィックパターンに適しています。
安定したハイスループット環境では、Reserved Instancesを活用したノードベースの方がコスト予測性が高い場合もあります。
Serverless vs ノードベースの使い分けは、負荷特性・コスト予測性・機能要件の3軸で判断します。

§4 Global Datastore

Global Datastoreは、プライマリリージョンから最大複数のセカンダリリージョンへキャッシュを非同期レプリケーションします。
リージョン障害時にはセカンダリリージョンへの昇格（手動フェイルオーバー）が可能で、クロスリージョンDRを実現します。
各リージョンからのローカル低レイテンシ読み取りによるグローバル配信も主な用途です。
Multi-AZ（単一リージョン内）との違いを理解し、グローバル展開が必要な場合にのみ採用します。

§5 データ階層化・オンライン再シャーディング

r6gdノードのデータ階層化（メモリ+ローカルNVMe SSD）は、アクセス頻度の低いデータをSSDへ退避しGBあたりコストを削減しながら大容量を実現します。
アクセス頻度が高いデータはメモリに残るため、ホットデータのレイテンシは従来通りです。
オンライン再シャーディングは、稼働中のクラスタで無停止でシャード数を変更でき、柔軟な水平スケールを可能にします。
大規模・大容量キャッシュ環境での有力な選択肢です。

§6 高度RBAC/ACL設計・詳細監視

高度なACL設計では、ユーザー・ロール・コマンドカテゴリの最小権限設定と、Secrets Manager連携による認証情報の自動ローテーションを組み合わせます。
CloudWatchの詳細メトリクス（EngineCPUUtilization・Evictions・CacheHit率・ReplicationLag）をダッシュボード化し、異常の早期検知を実現します。
スロットリング・ホットキー・大きなキーへの対処は、SLOの維持に直結する重要な運用スキルです。

8-2. 高度運用推奨チェックリスト

以下は、基礎編（クラスタモード・Multi-AZ・TLS・バックアップ）が完了していることを前提とした、本記事固有の高度化チェックリストです。
基礎のチェックリストは「AWS Database本番運用 Vol3」§2をご参照ください。

8-3. 関連記事

ElastiCacheの高度運用には、基礎の確立が前提となります。
クラスタモード設計・Multi-AZ・TLS・バックアップなどの基礎については「AWS Database本番運用 Vol3」をご参照ください。
また、用途特化型データベース（Neptune・DocumentDB・Keyspaces・Timestream）の詳細については「AWS Database本番運用 Vol5」もあわせてご覧ください。

ElastiCache高度運用の各テーマは段階的に導入できます。
まずValkey移行でコスト削減を実現し、続いてServerless/ノードの最適化、Global Datastoreによるクロスリージョン可用性、データ階層化、高度監視と順を追って成熟させていくことで、堅牢なキャッシュ基盤が完成します。