独自設計型クラスターを使用する際のアップグレードに関する考慮事項

エンジンのバージョニングは、パッチの適用方法をできる限り制御できるように設計されています。ただし、ElastiCache には、システムまたはキャッシュソフトウェアに重大なセキュリティ脆弱性が発生する可能性が低い場合に、お客様に代わってクラスターにパッチを適用するための権限あります。

Valkey 用の ElastiCache バージョン 7.2 および Redis OSS 用の ElastiCache バージョン 6.0 以降、ElastiCache は複数のパッチバージョンを提供するのではなく、マイナーリリースごとに 1 つのバージョンを提供します。

Redis OSS エンジンバージョン 5.0.6 以降では、最小限のダウンタイムでクラスターバージョンをアップグレードできます。このクラスターは、アップグレード中のすべての読み取りと、数秒かかるフェイルオーバー操作中を除き、ほとんどすべてのアップグレード中の書き込みに対応します。

5.0.6 より前のバージョンで ElastiCache クラスターをアップグレードすることもできます。関連するプロセスは同じですが、DNS の伝播中にフェイルオーバー時間が長くなる可能性があります (30 秒～1 分)。

Redis OSS 7 以降、ElastiCache は、Valkey または Redis OSS (クラスターモードが無効) と Valkey または Redis OSS (クラスターモードが有効) の切り替えをサポートしています。

Amazon ElastiCache for Redis OSS エンジンのアップグレードプロセスは、既存のデータを保持するために最善を尽くすように設計されており、Redis OSS レプリケーションを成功させる必要があります。

エンジンをアップグレードすると、ElastiCache は既存のクライアント接続を終了します。エンジンのアップグレード中のダウンタイムを最小限に抑えるため、エラー再試行とエクスポネンシャルバックオフによる Redis OSS クライアントのベストプラクティスと、メンテナンス中のダウンタイムを最小限に抑えるためのベストプラクティスを実装することをお勧めします。

エンジンをアップグレードする際、Valkey または Redis OSS (クラスターモードが無効) から Valkey または Redis OSS (クラスターモードが有効) に直接アップグレードすることはできません。以下の手順では、Valkey または Redis OSS (クラスターモードが無効) から Valkey または Redis OSS (クラスターモードが有効) にアップグレードする方法を示しています。

例えば、5.0.6 から 6.0 にメジャーエンジンのバージョンをアップグレードする場合は、新しいエンジンバージョンと互換性のある新しいパラメータグループも選択する必要があります。

単一の Redis OSS クラスターや、マルチ AZ が無効になっているクラスターの場合、「Valkey または Redis OSS スナップショットを作成するのに十分なメモリがあることを確認する」で説明されているように、Redis OSS 用に十分なメモリを確保することをお勧めします。このような場合、プライマリはアップグレードプロセスの実行中、リクエストに対応できません。

マルチ AZ が有効になっている Redis OSS クラスターの場合、書き込みの受信トラフィックが少ない期間中にエンジンのアップグレードを予定することもお勧めします。Redis OSS 5.0.6 以降にアップグレードする場合は、アップグレードプロセス中も、プライマリクラスターは引き続きサービスリクエストを処理できます。

複数のシャードを含むクラスターおよびレプリケーショングループは、次のように処理および修正されます。

現在のクラスターまたはレプリケーショングループで暗号化が有効になっている場合、暗号化をサポートしていないエンジンバージョン (3.2.6 から 3.2.10 など) にアップグレードすることはできません。

エンジンのバージョニングは、パッチの適用方法をできる限り制御できるように設計されています。ただし、ElastiCache には、システムまたはキャッシュソフトウェアに重大なセキュリティ脆弱性が発生する可能性が低い場合に、お客様に代わってクラスターにパッチを適用するための権限あります。

Memcached エンジンでは永続性がサポートされていないため、そのエンジンバージョンのアップグレードは常に、クラスターのすべてのキャッシュデータを消去する破壊的なプロセスです。