| 更新タイプ | 説明 | 影響 | 制御 | バージョンタイプ | ダウンタイム | フェイルオーバー |
|---|---|---|---|---|---|---|
| engine-upgrade | Redisエンジンバージョンのアップグレード （マイナー・メジャーバージョンアップ） |
エンジンバージョンに依存 • マイナー: 通常は最小限 • メジャー: 大幅な変更、要計画・テスト |
ユーザー主導のみ （自動では実行されない） |
マイナー/メジャー |
クラスター構成により異なる • シングルノード: 数分間のダウンタイム • マルチノード: フェイルオーバー時間のみ |
マルチノード構成では発生 シングルノードでは再起動 |
| service-update | セキュリティパッチ・マイナーソフトウェア更新 （セルフサービス更新） |
通常は最小限 セキュリティ・運用性能向上 |
ユーザー選択可能 期限後は自動適用される場合あり |
セキュリティ/マイナー |
ノード置換による短時間ダウンタイム • 1つずつ順次更新 • 数秒間のダウンタイム |
レプリケーショングループでは発生 |
| continuous-managed-maintenance | AWS主導の継続的メンテナンス更新 （OS・インフラレベルの更新） |
システム基盤の改善 セキュリティ・安定性向上 |
完全自動 （ユーザー制御不可） |
N/A |
メンテナンス期間中のノード置換 • 短時間（通常数秒） • 高トラフィック時は延長の可能性 |
レプリケーショングループでは発生 |
重要な補足情報
重要な注意点
-
Engine Upgrade vs Service Update:
- エンジンバージョン変更（engine-upgrade）は完全にユーザー主導で、AWSが自動で実行することはありません
- セルフサービス更新（service-update）はセキュリティパッチやマイナー更新で、ユーザーが制御できますが期限後は自動適用される場合があります
- Continuous Managed Maintenance: AWS主導で実行される基盤レベルのメンテナンスで、ユーザーは制御できません
- 更新の相互排他性: Service UpdatesとContinuous Managed Maintenanceは相互に排他的な仕組みです
- データ永続化: Redisエンジンアップグレード時は既存データの保持に最善の努力をしますが、適切なバックアップ戦略が重要
- コンプライアンス要件: HIPAA、PCI、FedRAMP準拠クラスターはService Updateを推奨期日までに適用する必要があります
ダウンタイムについて
- Service Update時: 1つのノードずつ順次更新され、各ノードで数秒間のダウンタイムが発生
-
Engine Upgrade時:
- レプリケーショングループ（Multi-AZ有効）: 自動フェイルオーバーでダウンタイム最小化
- シングルノード: プライマリが利用不可になる期間が発生
- Continuous Managed Maintenance時: ノード置換により短時間のダウンタイムが発生
- 推奨事項: 高トラフィック時期を避けてメンテナンスをスケジューリング
- メモリ不足時の注意: プライマリノードのメモリ不足や高書き込みトラフィック時は処理時間が延長される可能性
最新情報の確認
この表は2025年1月時点の情報に基づいています。最新の詳細については、Amazon ElastiCache for Redis公式ドキュメントを参照してください。