概要

ElastiCache（Redis）のパッチ適用時にフェイルオーバーが発生し、数秒〜数十秒の接続断が起きる。Cluster Mode Enabled にすれば解決するのでは？と考えがちだが、実際には効果がない。正しい対策はアプリケーション側での吸収。

Cluster Mode vs Multi-AZ の違い

項目 Cluster Mode Multi-AZ
目的 水平スケーリング（シャーディング） 高可用性（障害耐性）
データ分散 複数シャードにデータ分割 データ分散とは無関係
書き込みスケール シャード数分スケール スケールしない
フェイルオーバー Multi-AZ 有効時のみ自動 Primary 障害時にレプリカへ自動昇格

Cluster Mode は「データをどう分割するか」、Multi-AZ は「障害時にどう復旧するか」。直交する設定。

パッチ適用時に起きること

Multi-AZ 環境でのパッチ適用フロー:

1. Replica にパッチ適用（Replica 一時停止）
2. Replica 復帰
3. Replica を Primary に昇格（フェイルオーバー）← ここで数秒の接続断
4. 旧 Primary にパッチ適用
5. 旧 Primary が Replica として復帰

ステップ3のフェイルオーバー時に数秒〜数十秒の接続断が発生する。

Cluster Mode Enabled にしても解決しない

構成 パッチ時の挙動
Disabled + Multi-AZ シャード内でフェイルオーバー → 数秒の断
Enabled + Multi-AZ 各シャードで同じフェイルオーバーが起きる → 同じ

Cluster Mode はシャーディングの仕組みであって、パッチ時のダウンタイム回避には効果がない。

正しい対策: アプリケーション側で吸収する

Redis クライアントの設定

# Rails + redis-rb の例
redis = Redis.new(
  url: ENV['REDIS_URL'],
  reconnect_attempts: 3,        # フェイルオーバー時に自動再接続
  reconnect_delay: 0.5,         # リトライ間隔（秒）
  reconnect_delay_max: 2.0,     # 最大リトライ間隔
  connect_timeout: 3,           # 接続タイムアウト（短めに）
  read_timeout: 1,
  write_timeout: 1
)

フォールバック設計

Redis 参照
  ├── 成功 → キャッシュから返す
  └── 失敗（接続断）
       ├── リトライで復帰 → キャッシュから返す
       └── リトライ上限超過 → DB にフォールバック

Redis がダウンしてもアプリが 500 にならない設計が重要。

AWS 側の設定

  • メンテナンスウィンドウ: 低トラフィック時間帯に設定
  • SNS 通知: パッチ適用タイミングを事前把握
  • auto-minor-version-upgrade: パッチ適用タイミングをコントロール

小規模環境の推奨構成

Cluster Mode: Disabled
Multi-AZ:     Enabled
構成:         Primary 1台 + Replica 1台（別AZ）

小規模でデータが1ノードに収まるなら、Cluster Mode Enabled にする必要はない。複雑さ（クライアントの Cluster プロトコル対応、マルチキー操作の制約、スロット管理）が増すだけで、パッチ時のダウンタイム回避にも効果がない。

まとめ

  • パッチ時のフェイルオーバー（数秒の接続断）は Cluster Mode では解決しない
  • アプリ側の reconnect/retry 設定とフォールバック設計で吸収するのが正解
  • 小規模なら Cluster Mode Disabled + Multi-AZ が最もシンプルで十分