AWS ElastiCache Redis エラー 111 の解決方法：ポート 6379 での Connection Refused

アプリケーションが Redis に接続できない場合

重要なアップデートをリリースした直後、スムーズな起動の代わりにログが接続エラーで埋め尽くされることがあります。アプリケーションが Redis と通信できません。エンドポイントを確認し、AWS コンソールでステータスが「利用可能（Available）」であることを確認しても、クライアントは次のようなエラーをスローし続けます。

Error 111 connecting to cluster.xxxxx.cache.amazonaws.com:6379. Connection refused.

AWS において「Connection Refused（接続拒否）」というメッセージは、通常、ネットワークレイヤーがパケットを能動的に拒否していることを示します。パケットが静かにドロップされることが多い「Timeout（タイムアウト）」とは異なり、「Refused」エラーは通常、リクエストが送信先に到達したものの追い返されたことを意味します。これは、セキュリティグループの設定不備、ローカルファイアウォール、または TLS の不一致を指し示しています。

クイックフィックス

Amazon ElastiCache コンソールを開き、クラスターを選択します。
[ネットワークとセキュリティ] タブで、クラスターにアタッチされている VPC セキュリティグループを確認します。
EC2 コンソール -> [セキュリティグループ] に移動します。
Redis クラスターで使用されているセキュリティグループ（例: sg-redis-01234567）を見つけます。
インバウンドルールを追加します。

タイプ: カスタム TCP
- ポート範囲: 6379
- ソース: アプリケーションサーバーのセキュリティグループ ID（例: sg-web-8899aabb）または特定の VPC CIDR（例: 10.0.0.0/16）
ルールを保存し、すぐに接続をテストします。

接続が失敗する理由

ElastiCache の Redis ノードは、厳密に VPC 内部に存在します。パブリック IP アドレスは持ちません。AWS はデフォルトで「すべて拒否」のファイアウォール戦略を採用しています。アプリケーションのセキュリティグループからのアクセスを明示的に許可しない限り、Redis クラスターはポート 6379 でのすべてのトラフィックを無視します。

このエラーの一般的な原因には以下が含まれます。

デフォルトグループの失念: ポート 6379 のルールがない「default」セキュリティグループを使用している。
分離: まだ許可されていない新しいサブネットにアプリケーションをデプロイした。
パブリックアクセスの試行: ローカルのラップトップから接続しようとしている。ElastiCache は、VPN や SSH トンネルなしではパブリックインターネット経由で到達できません。

詳細な修正方法

1. セキュリティグループの連鎖（Chaining）

10.0.1.55/32 のような IP アドレスをハードコーディングすることは、将来的な障害の原因となります。代わりに、セキュリティグループの参照を使用してください。これにより、Auto Scaling グループがサーバーを追加または削除しても、「Web」セキュリティグループを持つすべてのインスタンスが接続できるようになります。

# ベストプラクティスの設定:
# App Security Group: sg-webapp-01234
# Redis Security Group: sg-redis-56789

# アクション:
# Redis SG にインバウンドルールを追加:
# Protocol: TCP | Port: 6379 | Source: sg-webapp-01234

2. VPC 間（Cross-VPC）の問題の解決

アプリが VPC-A にあり、Redis が VPC-B にある場合、単純なセキュリティグループルールだけでは不十分です。ブリッジが必要になります。まず、VPC ピアリング接続が「アクティブ（Active）」であることを確認します。次に、両方の VPC が pcx-xxxx ゲートウェイ経由で互いを見つけられるようにルートテーブルを更新します。最後に、Redis のセキュリティグループがリモート CIDR ブロックからのトラフィックを許可していることを確認します。

3. 転送中の暗号化（TLS）の処理

セットアップ中に「転送中の暗号化（Encryption in Transit）」を有効にした場合、標準の redis-cli コマンドは失敗します。サーバーは安全なハンドシェイクを期待しており、プレーンテキストの接続を拒否します。--tls フラグを含める必要があります。

# TLS が有効な場合は失敗します:
redis-cli -h cluster.xxxxx.cache.amazonaws.com -p 6379

# 暗号化されたクラスターにはこれが必要です:
redis-cli -h cluster.xxxxx.cache.amazonaws.com -p 6379 --tls

redis-cli の古いバージョン（バージョン 6 未満）はこのフラグをサポートしていない場合があることに注意してください。stunnel をインストールするか、ユーティリティをアップグレードする必要があるかもしれません。

経路が開いているか確認する方法

アプリケーションサービスの再起動を繰り返すのはやめましょう。EC2 インスタンスから以下のコマンドを使用して、問題を切り分けます。

方法 A: Netcat

nc -zv cluster.xxxxx.cache.amazonaws.com 6379

「succeeded!」というメッセージが表示されれば、ドアは開いています。ハングする場合は、ネットワークの遮断が発生しています。

方法 B: Telnet

telnet cluster.xxxxx.cache.amazonaws.com 6379
# Trying 10.0.x.x...
# Connected to cluster.xxxxx.cache.amazonaws.com.

方法 C: Redis Ping

redis-cli -h cluster.xxxxx.cache.amazonaws.com -p 6379 ping
# Expected: PONG

最終トラブルシューティングチェックリスト

VPC の一致: クライアントとクラスターは同じ VPC 内にありますか？そうでない場合は、ピアリングまたは Transit Gateway の設定を確認してください。
ポートの正確性: 6379 ではなく、誤ってポート 6380 をホワイトリストに登録していませんか？
ソース ID: インバウンドルールは、具体的に クライアントのセキュリティグループ ID に設定されていますか？
エンドポイント: クラスターモードがオンの場合、**設定エンドポイント（Configuration Endpoint）**にアクセスしていますか？
NACL: ネットワーク ACL（Network Access Control Lists）を確認してください。これらはステートレスであり、インバウンドポートが開いていても、アウトバウンドの戻りトラフィックをブロックする可能性があります。