先週2021/06/22にElastiCacheの更新(elasticache-20210615-002)が公開されました。
重大度:criticalな更新は無視することができない必須のアップデートです。
放置していると勝手にAWSからアップデートスケジュールが組まれてしまいますし、メンテナンスウインドウの設定を変更して期日を先延ばしにしても9月20日(月)までには必ずアップデートが実行されてしまうため避ける方法はありません。
アップデートの内容・影響
今回のアップデートの対象はRedisもMemcachedも対象です。
Redis | Memcached | |
対象バージョン | 2.6.13以降 | 1.4.5以降 |
更新時間 | 1ノードあたり30分程度 | 1ノードあたり30分程度 |
更新の影響 | キャッシュは残る | キャッシュは削除される |
ダウンタイム | ノードごとにアップデートされるため基本的にはなし。 ただし更新時間中は接続が不安定になりエラーレートが上昇する可能性が高い |
更新時間中に明確なダウンタイムが発生する |
Redisの場合はダウンタイムはないのでアクセスの少ないタイミングで更新を実行するのが良いかと思います。
なお、Redisは1ノードあたり30分と言いつつ6ノードあるから3時間とはならず、実際にはそれよりも早く完了しました。
Memcachedについては確実にダウンタイムが発生するので、きちんとサービス側でメンテナンスを告知して実施するか、新規のMemcachedクラスターを構築して差し替える対応を行うのが良さそうですね。
AWSで勝手にスケジュールされた更新の確認方法
ElastiCacheのコンソールからはスケジュールされた更新を確認することはできません。
AWSで勝手にスケジュールされた更新は、登録されているメールアドレス宛の連絡かヘルスダッシュボードから確認が可能です。
Personal Health Dashboard > イベントログ > サービス:ElastiCacheでフィルタ
からスケジュールを確認することが可能です。
どうしても先延ばししたい場合
ElastiCacheクラスターの変更からメンテナンスウィンドウを調整することで理論上は1週間ずつ先延ばしにできます。
ちなみにメンテナンスウィンドウを更新した後に再スケジュールされるまで1日以上かかる場合があります。
そのため、実際には一気に1週間延ばすということすら難しく、安全に対応するのであれば3~4日ずつ伸ばす形になりそうです。
ただし今回の場合は2021年9月20日には強制的にアップデートが実行されてしまうので、先延ばしにしたところでいずれは対応が必要になりますね。
新規のElastiCacheに差し替えおすすめ
Memcachedはどうしてもダウンタイムが発生してしまう上にキャッシュも保持されないので、いっそのこと新規のElastiCacheを作成してアプリケーションサーバでの参照先を変更する方法もおすすめします。
この方法であればダウンタイムは発生せずに済みますね。
一番良いのはサービス側でメンテナンスを告知して実施することですが、どうしてもメンテナンスが入れられない場合にはこの方法もお試しください。
おわりに
久しぶりに重要度criticalの更新が来ました。
基本的にキャッシュは消失しても問題ないように運用されているはずなのでセキュリティパッチの更新を当てても良いと思うのですが、安全に実行するのであればきちんとインフラの担当者が事前に対応をできると良いですね。
コメントを残す