Amazon ElastiCache for Redisのメジャーアップグレード方法をまとめてみた

2022.08.15

Amazon ElastiCache for RedisはAWSが提供するRedisのマネージドサービスです。

2023年にElastiCache Redisの2系及び3系がEOLを迎えることから、メジャーアップグレード方法を検討する機会がありましたので、共有します。

ElastiCache for Redis 2/3 の EOL

ElastiCache for Redis は 2.6.13から6.2まで幅広いバージョンに対応しています。

この内、2系と3系は2023年に EOL を迎えることが発表されています。

エンジンバージョン コンソールから作成不可 CLI・API・CloudFormationから作成不可 自動アップグレード
2.x.x 2022/10/13 以降 2023/01/13 以降 2023/01/13 以降
3.x.x 2023/05/01 以降 2023/07/31 以降 2023/07/31 以降

EOL を迎えるエンジンは、まずはAWSコンソールから作成できなくなり、その後、CLI/API/CloudFormationなどから作成できなくなり、以降はメンテナンスウィンドウ中に 6.2 へ自動アップグレードされます。

アップグレードが必要なクラスターが存在する場合、AWSアカウント宛に以下のような案内が通知されているはずです。

Hello,

You are receiving this message because you have one or more Amazon ElastiCache for Redis clusters running version 3.x.x in the AP-NORTHEAST-1 Region.

ElastiCache for Redis version 3, originally released in October 2017, will reach its End Of Life (EOL) on July 31, 2023. We are providing you this notice to give you sufficient time to upgrade your Redis cluster(s). We recommend that you upgrade your cache cluster(s) to the latest available ElastiCache for Redis version before July 31, 2023. At this time, the latest version is 6.2, and it contains features including: JSON support, Redis Streams, performance improvements (including Enhanced IO), and data tiering as well as a various security and reliability updates.

[snip]

アップグレード方法

  1. インプレース
  2. Blue/Green

の2種類のアップグレード方法があります。

方法 インプレース Blue/Green
詳細 既存の Redis クラスターを直接アップグレード 既存クラスターとは別に、新規クラスターを作成し、切り替え
メリット 操作がシンプル。エンドポイントが変わらない。 ダウンタイムが短い。Data Tiering化などクラスターの作り直しを伴う構成変更にも対応
デメリット 構成によってはダウンタイムが長くなる可能性。 エンドポイントが変わる。手順が複雑。新クラスターのウォーム
ロールバック スナップショットからクラスターを作成 アプリのエンドポイントを旧クラスターに向ける

まずは、計画メンテナンスが可能か、インプレースのオンライン変更に伴うダウンタイムを許容できるかによって、インプレース・Blue/Green を検討しましょう。

1. インプレース方式

クラスターの変更操作の一環としてバージョンを変えるだけのため、非常にシンプルです。 余裕を持ったメンテナンス時間を確保できる場合や一時的なサービス断を許容できる場合、おすすめです。

Elasticache Redis はインプレースアップグレード中もAurora/RDS のような長時間のダウンタイムは伴わず、主にフェイルオーバーのタイミングで接続障害が発生します。

以下の様なクラスター構成の場合、ダウンタイムが長くなる可能性があります。

  • エンジンバージョンが 5.0.5 未満
  • レプリカがないスタンドアローン構成

具体的には、以下の通りです(参考)。

  • Starting with Redis engine version 5.0.5, you can upgrade your cluster version with minimal downtime. The cluster is available for reads during the entire upgrade and is available for writes for most of the upgrade duration, except during the failover operation which lasts a few seconds.
  • You can also upgrade your ElastiCache clusters with versions earlier than 5.0.5. The process involved is the same but may incur longer failover time during DNS propagation (30s-1m).

検証環境でアップグレードを試し、ダウンタイムが許容範囲か検証しましょう。

また、バージョンアップと同時に以下のような構成変更を行いたい場合、クラスターの作り直しが必要なため、インプレース方式を採用できません。

  • 大容量のキャッシュを扱えるData Tieringを利用したい
  • クラスター化(シャーディング)したい
  • at-rest暗号化したい

代わりに、スナップショットから、新規クラスターを作成してください。

2. Blue/Green方式

ダウンタイム無しにバージョンアップしたい場合に向いています。

既存クラスターとは別に新規クラスターを作成し、切り替えのタイミングでアプリの向き先を新クラスターに向けます。

既存・新規クラスター間でのデータ同期には注意が必要です。

オンライン・マイグレーション機能を利用すると、ElastiCache RedisをEC2/オンプレなどでセルフホストされたRedisのレプリカにできますが、他のElastiCache Redisクラスターをソースとしたマイグレーションは対象外です(Online migration is designed for data migration from hosted Redis on Amazon EC2 or on-premise self-hosted Redis to ElastiCache for Redis and not between ElastiCache for Redis clusters.)

さらに、ElastiCache Redisはreplicaof/slaveof コマンドが禁止されているため、レプリケーションのターゲットになれません。

最新キャッシュが溜まっている状態でクラスターを切り替えたい場合、以下の流れでダブルライトしましょう。

  1. (スナップショットから)移行先バージョンの新クラスターを作成
  2. アプリを改修し、新旧クラスターに同じデータを書き込む(ダブルライト)。読み取りは旧クラスターから行う
  3. 新旧クラスターのキャッシュが同等になったタイミングで、読み書きを新クラスターだけにする
  4. 旧クラスターを削除

仮にRedisの全データに対してTTLを7日に設定している場合、7日以上ダブルライトすれば、新旧クラスター間のデータ差分を気にする必要はありません。

ダブルライトの事例としては、タップルは、サービス影響なし・ダウンタイムなしにメジャーアップグレードしています。

タップルにおける約4年越しのキャッシュストア大幅アップデート | CyberAgent Developers Blog

アップグレード先バージョンは?

Redis は基本的に後方互換性が維持されており、RDBでありがちなSQLの性能劣化のようなリスクも低いです。 そのためか、ElastiCache Redis は、任意のより上位のバージョンにアップグレードできます。

例えば、一番古い 2.6.13 から 最新の 6.2 へのアップグレードすら可能です。 実際、EOL のドキュメントでは、2.x/3.xの移行先(Recommended Upgrade Target)として 6.2 が推奨されています。

バージョンごとの差異がまったく存在しないわけではないため、次のドキュメントからバージョンの差分を確認し、特別な事情がなければ最新の6.2へのアップグレードを検討しましょう。

リスク軽減のために少しでもバージョンを抑えたい場合、5.0.6 がおすすめです。

クラスター変更時のダウンタイムが軽減され(5.0.5から)、最新のノードタイプ(5.0.6から)を選択できるためです。

一方で、ダウングレードには対応していません。

ノードタイプどうする?

メジャーアップグレードはノードタイプを見直すよい機会です。

新しいノードタイプほどより安く、より高性能な傾向があるため、メジャーアップデートやリザーブドインスタンスの更新を期に、新しいノードタイプへ変更しましょう。

エンジンバージョンごとに利用可能なノードタイプに制限があり、最新の最新ノードタイプ(M6g/R6g/T4g)はバージョン 5.0.6 以上で対応しています。

注意点として、5.0.6未満のクラスターをバージョンアップと同時に最新ノードタイプへは変更できません。 一度、5.0.6以上へバージョンアップした上で、ノードタイプを変更してください。

対応しているクラスター変更パス

  • 2.8/R4 → 6.2/R4
    • バージョンだけを変更
  • 2.8/R4 → 6.2/R5
    • バージョンとノードタイプ(非最新)を変更
  • 2.8/R4 → 6.2/R4 → 6.2/R6g
    • バージョンを5.0.6以上に変更後、最新のノードタイプへ変更
  • 5.0.6/R4 → 6.2/R6g
    • 5.0.6以上のバージョンから、バージョンアップと同時に最新ノードタイプへ変更
  • 2.8/R4 → スナップショット → 6.2/R6g
    • スナップショットを経由してクラスターを新規作成する場合、バージョンアップと同時に最新ノードタイプへの変更が可能

対応していないクラスター変更パス

  • 2.8/R4 → 2.8/R6g
    • 5.0.6未満のバージョンは最新ノードタイプに対応していない
  • 2.8/R4 → 6.2/R6g
    • 5.0.6未満のバージョンから、5.0.6以上へのバージョンアップと最新ノードタイプへの変更は同時にできない

参考 : Amazon ElastiCache for Redisの各バージョンが対応しているノードタイプを調べてみた | DevelopersIO

データロス

ElastiCache はノード変更時にデータロストができるだけ起きないように設計されています。

The Amazon ElastiCache for Redis engine upgrade process is designed to make a best effort to retain your existing data and requires successful Redis replication.

Upgrading engine versions - Amazon ElastiCache for Redis

Redisはキャッシュサービスのため、データの永続性についてはRDBほどシビアでないはずです。

データロスがクリティカルな場合、Redis の使い方を間違えているかもしれません。 これを機に、アプリケーションがRedisで管理すべきデータを見直しましょう。

最後に

Amazon ElastiCache for Redisのメジャーアップグレード方法を紹介しました。

Redis はバージョンアップに伴う互換性や性能劣化のリスクが RDB ほど高くありません。 また、インプレース・バージョンアップグレードに伴うダウンタイムも、Aurora/RDSに比べて遥かに短いです。

まずはシンプルなインプレース方式を検討し、計画メンテナンスやインプレース・アップグレードのダウンタイムが許容できない場合は、Blue/Green方式を検討してください。

それでは。

参考