目的

express.jsで実装したバックエンドをECSにデプロイしているプロジェクトで、サーバー側でキャッシュを保持したく導入を試みます。

ElastiCacheとElastiCache Serverlessの違い

運用モデルとスケーリングの仕組みに大きな違いがあります。

ElastiCache は、あらかじめノードのサイズや数を指定して構築する「プロビジョニング型」のインメモリキャッシュサービスです。ユーザー自身がキャパシティやスケーリングを管理する必要があり、継続的に一定の負荷がかかるシステムや、細かな構成の調整が必要な場面に適しています。

一方、ElastiCache Serverless は、サーバーのサイズや台数を指定せずに使える「サーバーレス型」の ElastiCache です。アクセス量に応じて自動的にスケーリングされるため、突発的なトラフィックにも柔軟に対応できます。

ElastiCache Serverless for Valkeyの準備

ElastiCache Serverless for Valkey
エンジン：Valkey（選択時に Redis か Valkey を選択）
VPC 配置：作成済みのECSと同一の VPC に作成
サブネットグループ：作成済みのECSと同一 VPC のサブネットを指定
セキュリティグループ
インバウンドルール：ポート 6379（Valkey の標準ポート）を開放
許可元：ECS タスクに割り当てるセキュリティグループ

バックエンドの実装

1. クライアント側ライブラリの選定

ElastiCacheのコンソール画面にライブラリvalkey-glideを推奨しているのでこちらで実装を進めることにしました。

AWSが推奨している理由などは以下の記事にて確認しました。

コンソール画面に実装はほとんど記載されていたのでそのままコピペでECSにデプロイします。

import {GlideClient} from "@valkey/valkey-glide";

const addresses = [
    {
        host: "address.example.com",
        port: 6379
    }
];

const client = await GlideClient.createClient({
    addresses: addresses,
    useTLS: true
});

ElastiCache ServerlessはTLS接続が必須になります。
そのためクライアント側もTLS: trueで接続する必要があります。

⚠️ 問題発生

「接続ができない」

const client = await GlideClient.createClient({
    addresses: addresses,
    useTLS: true
});

この実装部分で以下のようなエラー（※正確なものではないが覚えている単語のみ）が起こります。

ERROR: invalid certification.

しかし、調査したところ証明書などを準備する必要はなく、このままで接続ができるはずでした。

他のリソースで接続の確認

Lambda

今回の場合、ECSの代わりとしてLambdaで同じ実装を行いました。

LambdaはECSと同じくバックエンドの実装を行えるサービスになります。

Lambda 結果

接続ができました。
Lambdaで実現できるのであればECSでも可能なのでは..
しかし、改めて確認を行いましたが問題点は見つからず、実現が難しく思いましたので推奨ではありませんが、コンソールに記載であったもう一つのnodeライブラリで確認を行うことにしました。

※先にお伝えしますが、　valkey-glideでの実現はできませんでした。

ライブラリ「 ioredis 」の導入

valkey-glideについてのドキュメントも少なく、これ以上の調査も厳しく感じたので、こちらもコンソール画面の「ライブラリ」に載っているioredisを使用することにしました。

ElastiCache Serverlessを使用しているのでtlsを追加する必要があります。
こちらにAWSでの利用について記載がありました。

ioredis.ts

const cluster = new Redis.Cluster(
  [
    {
      host: "clustercfg.myCluster.abcdefg.xyz.cache.amazonaws.com",
      port: 6379,
    },
  ],
  {
    dnsLookup: (address, callback) => callback(null, address),
    redisOptions: {
      tls: {},
      username: "default", 
      password: "my-top-secret",
    },
  }
);

こちらのライブラリに変更することでECSからの接続が可能になりました。

ユーザーとグループユーザーの作成

Local環境での実装

Dockerでローカル実装用のValkeyを立ち上げる

docker-compose.yml

  backend:
    build:
      context: ./backend
      dockerfile: Dockerfile
    container_name: backend
    ports:
      - "3000:3000"
    depends_on:
      - valkey
    environment:
      VALKEY_HOST: valkey
      VALKEY_PORT: 6379
    volumes:
      - ./backend:/app
    networks:
      - app-network
    restart: unless-stopped

  valkey:
    image: valkey/valkey:latest
    container_name: valkey
    ports:
      - "6379:6379"
    volumes:
      - valkey-data:/data
    networks:
      - app-network

補足: valkey は Redis の代替で、ポート番号も 6379 を使用します。

※各構成要素の説明（Docker知識の浅いためメモ）

networks
app-network という名前で明示的にネットワークを定義。
これにより、backend から valkey をサービス名（ホスト名）でアクセス可能。
volumes
valkey 用に valkey-data ボリュームを定義。
/data にマウントされ、Valkey のデータが保持される（例：SAVE コマンド実行時など）。

Dockerfile（valkey）

FROM valkey/valkey:latest

COPY ./valkey.conf /etc/valkey/valkey.conf
CMD ["valkey-server", "/etc/valkey/valkey.conf"]

valkey.conf の具体的な設定内容例

bind 0.0.0.0
protected-mode yes

今回の問題

ElastiCache Serverless for Valkey は Redis Cluster モード互換 であり、ioredis.Cluster を用いた接続が前提になります。

その場合、ローカル環境でも「Redis Cluster 構成の Valkey を複数ノードで立てて再現」する必要があります。

しかし、複数ノード立ち上げるとPCが重くなるなど懸念する点もあり。
選択肢としては以下の2点になります。

ローカル実行だけRedis.Cluster ではなく Redis に切り替える（スタンドアロンモード）
複数ノード立ち上げる

Redis.Cluster ではなく Redis に切り替える

Redis.Cluster ではなく Redis に切り替える（スタンドアロンモード）
または、1コンテナ内で複数 Valkey を起動して疑似クラスタ化

// 環境変数で切り替え
if (isClusterMode) {
  redis = new Redis.Cluster([...]);
} else {
  redis = new Redis({ host: 'localhost', port: 6379 });
}

複数ノード立ち上げる

version: '3.8'

services:
  valkey-node-1:
    build: .
    ports:
      - "6380:6379"
    volumes:
      - ./valkey.conf:/valkey.conf
    command: ["valkey-server", "/valkey.conf"]
    networks:
      valkey-cluster:
        ipv4_address: 172.20.0.11

  valkey-node-2:
    build: .
    ports:
      - "6381:6379"
    volumes:
      - ./valkey.conf:/valkey.conf
    command: ["valkey-server", "/valkey.conf"]
    networks:
      valkey-cluster:
        ipv4_address: 172.20.0.12

  valkey-node-3:
    build: .
    ports:
      - "6382:6379"
    volumes:
      - ./valkey.conf:/valkey.conf
    command: ["valkey-server", "/valkey.conf"]
    networks:
      valkey-cluster:
        ipv4_address: 172.20.0.13

  cluster-init:
    image: valkey/valkey:latest
    depends_on:
      - valkey-node-1
      - valkey-node-2
      - valkey-node-3
    entrypoint: [ "sh", "-c", "sleep 5 && /create-cluster.sh" ]
    volumes:
      - ./create-cluster.sh:/create-cluster.sh
    networks:
      valkey-cluster:

networks:
  valkey-cluster:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/16