Amazon ElastiCache for RedisからAmazon ElastiCache Serverless for Valkeyへ移行した話

導入

こんにちは。2024年8月に名刺アプリ「Eight」のSREエンジニアとして、Sansan株式会社へ入社した技術本部 Eight Engineering Unit Platformグループの藤原です。日々プロダクトの信頼性に向き合っています。

本記事では、Web版Eightのセッション管理で活用しているAmazon ElastiCache for Redis OSS（以後ElastiCache for Redis とする）を、Amazon ElastiCache Serverless for Valkey（以後ElastiCache Serverless for Valkeyとする）に移行した背景やプロセス、移行後の効果をご紹介します。

セキュリティーアップデート時の運用負荷軽減だけでなく、ユーザーへの影響も最小化し、コスト削減も実現できたため、ElastiCache Serverless for Valkeyへの移行を検討している方の参考になれば幸いです。

背景

みなさん、Eight にはアプリ版だけでなく、Web版があるのをご存知でしょうか？ 2024年10月には大幅なリニューアルを実施しました。
jp.corp-sansan.com
そんなWeb版Eightでは、ユーザーのセッション管理にElastiCache for Redisを活用しています。

ElastiCache for Redisは独自設計型クラスターとしてマルチAZで構築しており、定期的にAWSよりサービスの更新がリリースされます。SREチームはサービスの更新通知を受け取ると、更新を適用するかの判断を実施し、適用する場合はPdMやサポートと連携をとりながら日程調整をした上で適用を進めます。

AWSコンソールやCLIからサービスの更新を提供するのが一般的ですが、その場合は更新中のノードでは数秒のダウンタイムが発生するとされており、それはユーザーがその間Web版Eightを使えないことを意味します。そのためEightでは、新規クラスターを作成しエンドポイントの切り替えを実施することで、ダウンタイムをゼロにする工夫を施しています。しかし、この方法では切り替え前のキャッシュのデータは引き継がれないため、サービスの更新の際にユーザーが強制的にログアウトされてしまう問題が発生します。さらに、ユーザーの再ログインに伴い、二要素認証に使用されているSMS Outboundのコストが約$100発生していました。

上記の対応により、ユーザーへの影響を最小限に抑えられるものの、サービスの更新通知を受け取ってからセキュリティーアップデート作業を完了させるまでに合計で約12時間の工数が発生していました。そこで、運用負荷の軽減と、ユーザーへの影響を最小化させることを目的として、サービスの更新が自動的かつ透過的に適用されるサーバーレスクラスターへの移行を決定しました。

また、エンジンにRedisではなくValkeyを選択した理由として、Redisのライセンスに変更があったこと、Redis と比較してコストが安くなることが挙げられます。

移行方法

ElastiCache Serverless for Valkeyを採用するにあたり、いくつか検証が必要なポイントがありました。

メジャーバージョンアップグレードを伴うこと
RBACの仕組みに移行すること
エンジンの変更を伴うこと

です。

1. に関して、ElastiCache Serverless for Valkeyはバージョン7.2以降のみをサポートしているため、メジャーバージョンを6から7にアップグレードする必要がありました。セッション管理の仕組みだったため、SETやGETなどのシンプルなコマンド処理のみを行っており、検証の結果、互換性を保ちながら移行が可能であることを確認しました。

2. に関して、ElastiCache for Redisではアプリケーションの認証の仕組みとしてRedis AUTHを使用していました。こちらは古い仕組みであり、サーバーレスクラスターでは RBACのみがサポートされています。Redis AUTHは、認証が成功すればRedisクラスターの全コマンドを実行することが可能です。RBACではユーザーグループごとに、より細かな設定ができますが、今回は既存の仕組みと互換性を保つように設定しました。

3. は、1. と同様に、シンプルなコマンド処理のみを行っていたため、検証の結果、クライアントの変更を伴わずに切り替えが可能であることを確認しました。

上記の検証結果を踏まえ、シームレスな移行が可能と判断し、サービス停止を伴うメンテナンス時に切り替える方法で進めました。これにより、移行時に静止点を設けられ、キャッシュデータを失うことなく移行を完了できると考えたのです。つまり、ユーザーの視点からは通常通りの体験が維持されます。なお、検証環境でElastiCache for RedisのスナップショットからElastiCache Serverless for Valkeyを立ち上げた後にエンドポイントを切り替え、意図したキャッシュデータが存在するかなど、データロストの有無の検証も行っています。

以下が簡単な移行の流れとアーキテクチャ図です。非常にシンプルですよね。

RBAC用のユーザーとユーザーグループを作成しておく
メンテナンス中にアクセスが届いていないことをメトリクスから確認し、既存のRedisのスナップショットを取得する
スナップショットからElastiCache Serverless for Valkeyを立ち上げる
アプリケーションコードのエンドポイントを切り替え、リリースする

なお、サーバーレスキャッシュはパラメータグループを指定、変更ができないため、既存のパラメータと差異がないかは確認しておくほうがベターです。入念に事前検証していたこともあり、大きなトラブルなく移行することができました。

移行後の成果

ElastiCache Serverless for Valkeyに移行したことで、以下のコストが削減されました。

AWSコスト
サービス更新にかかる人的コスト
問い合わせ対応の人的コスト

1. に関して、1週間の運用後にコスト試算をしてみました。今後キャッシュデータ量が増えてくるとその分従量課金されるため、あくまで現時点での比較となります。既存の ElastiCache for RedisはReserved Instancesを購入していましたが、それでも ElastiCache Serverless for Valkeyに移行したことで年間コストと比較して約32％削減される見込みです。仮にエンジンはRedisのままサーバーレス化していた場合、概算コストは移行前とほぼ同等でした。そのため、Valkeyへの移行がコスト削減に大きく寄与していることが分かります。

今回のユースケースでは、ElastiCache Serverless for Valkeyの全体コストのうち、98% がCachedDataにかかるコストとなっています。約1,200万／日のアクセスが ElastiCacheに届きますが、ElastiCache Processing Unit (ECPU)の占める割合はわずか2%でした。なお、1回の通信のデータ量によっても変化するため、あくまで参考値となる点はご了承ください。また、サービスの更新作業自体がなくなるので、再ログインに伴う二要素認証のコストも約$100削減されることが期待できます。

2. に関して、セキュリティーアップデート時の工数は約12時間／回分削減されます。仮に半年に1回の頻度でアップデートを実施すると、月換算では約2時間の工数削減となります。

そして最後に3. に関して、ユーザーの再ログイン時に「二要素認証の設定を忘れたためログインできない」といった問い合わせが発生することがあり、その対応に一定のサポート工数がかかっていました。こちらも透過的に行われるサービス更新により、発生頻度の低下が期待されます。

なお、本移行の主目的とは異なるので参考として記載しますが、移行前後でパフォーマンスに大きな変化は見られませんでした。ただし、ElastiCache Serverless version 8.0 for Valkeyに移行することで、スケーリングの高速化やメモリ効率の向上といったパフォーマンス向上が期待できます。