Amazon ElastiCache入門｜RedisとMemcachedの違いとクラウドキャッシュ設計の基礎知識

DBへのクエリが増えてきて「レスポンスが遅くなってきた」「RDSのCPUが常に高止まりしている」——そんな悩みを抱えているエンジニアは多いはずです。オンプレ環境ではMemcachedやRedisをサーバーに直接インストールして使っていたケースも多いですが、クラウド移行後はどう運用すればいいのか、悩みどころです。

この記事では、AWSのマネージドキャッシュサービス Amazon ElastiCache について、RedisとMemcachedの違い・選び方、クラスターの作成手順、料金の仕組み、実務でのキャッシュ活用パターンまで、オンプレ経験者にもわかりやすく解説します。

なぜ ElastiCache なのか？オンプレのキャッシュとの違い

オンプレ環境でキャッシュと言えば、アプリサーバー上にMemcachedをインストールしたり、別途Redisサーバーを立てたりという構成が一般的でした。うまく動いているうちはいいのですが、いざ障害が起きると「どのノードが落ちているのか」「レプリケーションは正常か」の確認が手間でした。

Amazon ElastiCache が解決するのはまさにこの運用コストです。クラスターの作成・監視・フェイルオーバー・パッチ適用をAWSが管理してくれるため、エンジニアはキャッシュロジックの設計に集中できます。

特に注目すべきはフェイルオーバーの自動化です。オンプレでプライマリRedisが落ちると、手動でレプリカへの切り替えが必要な場合がほとんどでした。ElastiCacheのRedis（クラスターモード無効）であれば、プライマリ障害を検知して自動的にレプリカを昇格させます。深夜の障害対応に追われるリスクが大幅に減ります。

Redis と Memcached の違いと選び方

ElastiCacheは Redis と Memcached の2種類のエンジンをサポートしています。「どっちを使えばいいのか」は最初に必ず迷うポイントです。

実務の場面では、ほとんどのケースでRedisを選ぶことをお勧めします。理由はシンプルで、「セッション管理」「DBクエリのキャッシュ」「ランキングやカウンター」と用途が広がったときにRedisしか対応できないからです。最初にMemcachedを選ぶと、後で機能不足に気づいて移行作業が発生します。

Memcachedを選ぶ理由があるとすれば、「超シンプルなオブジェクトキャッシュだけしか使わない」「マルチスレッドで特定ワークロードを最大限に活かしたい」という場合に限られます。

ElastiCache（Redis）の基本的な使い方

1. クラスターの作成

AWSマネジメントコンソールにログインし、「ElastiCache」を開きます。

・クラスターの作成を開始: 左メニューから「Redis clusters」→「Create cluster」をクリック
・Cluster mode: 最初は「Disabled（無効）」を選択（シンプルなプライマリ＋レプリカ構成）
・クラスター名: 例 myapp-cache（英数字とハイフンのみ）
・ノードタイプ: 開発環境なら cache.t3.micro、本番なら cache.r7g.large 以上が目安
・レプリカ数: 本番なら最低2個（プライマリ1 + レプリカ2 のMulti-AZ構成）

設定の中で特に重要なのが サブネットグループ の選択です。ElastiCacheはVPC内に配置されるため、事前にプライベートサブネットにまたがるサブネットグループを作成しておく必要があります。

2. セキュリティグループの設定

ElastiCacheへのアクセスはRedisのデフォルトポート 6379 で行われます。アプリサーバー（EC2）が属するセキュリティグループからのインバウンドだけを許可するよう設定します。

# ElastiCache用セキュリティグループのインバウンドルール設定例（AWS CLI）
aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxx \
  --protocol tcp \
  --port 6379 \
  --source-group sg-yyyyyyyy

インターネットからElastiCacheへの直接接続は絶対に許可しないでください。ElastiCacheは必ずVPC内のプライベートサブネットに配置し、アプリサーバー経由でのみアクセスする設計が基本です。

3. EC2からの接続確認

クラスターの「プライマリエンドポイント」をコンソールから確認し、EC2インスタンスから接続テストを行います。

# EC2にredis-cliをインストール（Amazon Linux 2023の場合）
sudo dnf install -y redis6

# ElastiCacheのプライマリエンドポイントへ接続
redis-cli -h myapp-cache.xxxxxx.ng.0001.apne1.cache.amazonaws.com -p 6379

# 接続確認
127.0.0.1:6379> PING
PONG

# キーをセットして確認
127.0.0.1:6379> SET testkey "hello"
OK
127.0.0.1:6379> GET testkey
"hello"

「PONG」が返ってくれば接続成功です。エンドポイントは「プライマリエンドポイント」と「リーダーエンドポイント」の2種類があります。書き込みはプライマリ、読み取り専用の処理はリーダーエンドポイントに向けると、レプリカへ負荷を分散できます。

料金の仕組みとコスト感覚

ElastiCacheの料金は主に ノードの稼働時間 で決まります（2026年4月時点・東京リージョンの価格）。

本番環境でMulti-AZ構成（プライマリ1 + レプリカ2）を組む場合、3ノード分の料金がかかります。cache.r7g.large × 3ノードなら月額約$360（東京リージョン）が目安です。

コストを抑えるなら リザーブドキャッシュノード の活用が有効です。1年または3年の予約購入で、オンデマンドと比べて最大55%割引になります。本番環境で長期稼働が確定しているノードは積極的に予約購入を検討しましょう。

なお、同一VPC内からのElastiCacheへのデータ転送は無料です。ただしAZをまたぐ通信（EC2とElastiCacheが別AZにある場合）はデータ転送料が発生するため、同一AZ内に配置するか、アーキテクチャを見直すことを検討してください。

応用・実務Tips

セッション管理への活用

Webアプリケーションのセッションデータをサーバーローカルに持つと、オートスケール時にセッションが失われる問題が発生します。ElastiCache（Redis）にセッションを外部化することで、どのアプリサーバーインスタンスがリクエストを受けても同じセッション情報を参照できます。

・PHPの場合: session.save_handler = redis と session.save_path にElastiCacheエンドポイントを設定するだけで対応可能
・Node.jsの場合: connect-redis パッケージでExpressセッションをRedisに接続
・SpringBootの場合: spring-session-data-redis を依存関係に追加してセッション外部化

DBクエリキャッシュ（Read-Through パターン）

RDSへの負荷が高い場合、クエリ結果をElastiCacheにキャッシュする Read-Throughパターン が効果的です。

# Read-Throughパターンの疑似コード（Python例）
import redis
import json

r = redis.Redis(host='myapp-cache.xxxx.cache.amazonaws.com', port=6379)

def get_user(user_id):
    cache_key = f"user:{user_id}"
    cached = r.get(cache_key)

    if cached:
        return json.loads(cached)  # キャッシュヒット

    # キャッシュミス → DBから取得
    user = db.query(f"SELECT * FROM users WHERE id = {user_id}")

    # 結果をキャッシュに保存（TTL: 300秒）
    r.setex(cache_key, 300, json.dumps(user))

    return user

TTL（Time To Live）の設定が重要です。短すぎるとキャッシュヒット率が下がり、長すぎるとデータの鮮度が失われます。ユーザープロフィールなど更新頻度が低いデータは長め（数分〜数時間）、在庫数や価格など更新頻度が高いデータは短め（数秒〜数十秒）に設定するのが一般的です。

LinuxMasterとの連携

EC2上でLinuxサーバーを構築している方は、ElastiCacheクラスターとの疎通確認やnetstatでの接続状態確認など、Linuxの基本操作が役立ちます。Linuxの基礎については、姉妹サイトLinuxMaster.JPで詳しく解説しています。

よくあるトラブルと対処法

接続できない（Connection refused / タイムアウト）

ElastiCacheへの接続が「Connection refused」や「タイムアウト」になる場合、まずセキュリティグループを確認します。EC2のセキュリティグループからElastiCacheへのポート6379の通信が許可されているかを確認してください。

・確認コマンド: nc -zv [エンドポイント] 6379 で疎通確認
・よくある原因①: EC2とElastiCacheが異なるVPCにある（VPCピアリングが必要）
・よくある原因②: サブネットグループの設定ミスでプライベートサブネットが選ばれていない
・よくある原因③: ElastiCacheのセキュリティグループが対象のEC2セキュリティグループを参照していない

メモリ不足（eviction が多発する）

CloudWatchで Evictions メトリクスが上昇している場合、キャッシュに格納するデータ量がノードのメモリ上限に達しています。

・短期対処: maxmemory-policy を allkeys-lru に設定し、使用頻度の低いキーから自動削除
・根本対処: ノードタイプをメモリの大きいものへスケールアップ、またはクラスターモードでシャード追加
・CloudWatchで監視すべきメトリクス: FreeableMemory、Evictions、CurrConnections

レプリカラグが大きい

ReplicationLag メトリクスが大きくなっている場合、プライマリへの書き込みが多すぎてレプリカへの同期が追いついていない状態です。書き込み処理の見直しや、クラスターモードへの移行によるシャード分散を検討してください。

本記事のまとめ

Amazon ElastiCacheは、「DBが遅い」「アプリサーバーが落ちるとセッションが消える」という典型的な課題に対して、最も費用対効果の高いアプローチのひとつです。オンプレでRedisを動かした経験があれば、ElastiCacheの概念は直感的に理解できるはずです。まずは開発環境で cache.t3.micro のクラスターを立ち上げ、アプリからのキャッシュ接続を試してみてください。

関連記事

• Amazon Route 53入門 DNS設定からドメイン管理まで オンプレ経験者のための実践ガイド
• Amazon VPC入門 サブネット設計からインターネット接続まで現場で使えるネットワーク構築の基礎
• Amazon RDS入門 クラウドDB移行の基礎知識