こんにちは、技術推進本部のシムです。 今回は最近実施したセッションストアのValkey Serverless移行について、なぜ移行を決めたのか、実際の移行プロセスや成果、運用で得られた知見を紹介します。
ここでのセッションストアとは
STORES ネットショップの本体は Rails で動いており、該当アプリケーションのセッションストアを指します。 元々は MemoryDB (with Redis OSS) をストレージとして利用しており、該当クラスタにはセッションに関係するデータも一部追加で保存されておりました。
なぜ Valkey Serverlessに移行したのか？
ここには Serverless の採用と Valkey の採用という二つの話があるので分けて話していきます。
Serverless の採用
ElastiCache Serverless は従来の ElastiCacheとは異なり、キャパシティを自動で管理するサーバレス版のサービスです。使っただけの従量課金、自動更新、Parameter Group が廃止されたことによる運用負荷軽減などのメリットがあります。
長所として以下が挙げられます：
- キャパシティ管理が不要
- 従量課金による柔軟な料金体系
- メンテナンス作業なしでの自動更新
- Parameter Group 概念の廃止による考慮事項の削減
短所ないしは導入において考えるべきものは以下でした。
- Parameter Group が亡くなったため、細かいパラメータ調整をこちらからできなくなる
- 従量課金になるのでコストを見積りづらい。ユースケースによっては ECPU の計算がむずかしく、移行する前に精度高く見積もりを出すことができない
- サーバレスは自動でキャパシティを管理するが、アクセス集中によるスパイクを問題なく処理できるのかわかってなかった
- Serverless 固有の制約がある
パラメータ調整ができない、という点に関してはセッションストレージとして使っているクラスタでは eviction の設定くらいしか修正してなかったし、今後も積極的に変更する可能性が低いと考えてよしと判断しました。
課金に関しては結構真面目に計算しておりまして、具体的には一月分の各種コマンドの呼び出し数、ネットワーク通信量から予想額を出した上で、少なくとも今よりコストが増えることがないだろう、という判断のもとで問題ないと判断しました。
キャパシティに関してはスパイクしたところで 10倍くらいしかないことを考えるとそこまでシビアな調整はしてないだろうと予想しており実はそこまで心配してなかったのですが、一応頭の隅っこに入れておきました。
最後に ElastiCache Serverless のシステム上の制約があります。わかりやすいのは使えないコマンド一覧です。たまに便利に使う KEYS と CLIENT LIST などが使えないのは地味に不便ですが、そこまで致命的なものでもありません。
Ref: https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/SupportedCommands.html
以上から採用を決定しました。
Valkey の採用
Valkey とは Redis 7.2 からのフォークでして、2024年3月の Redis のライセンス変更が発端で Linux Foundation のプロジェクトとして誕生しました。今後はどう成長していくかはまだわからないですが、 AWS で提供している 8.0 は一般的な用途において Redis 互換となっています。
元々が Redis でしたのでそのままにするか Valkey に移行するか、という状況で後者を選んだのは我々が AWS というクラウドを利用しているという面が大きいです 。
- Valkey の方が Redis OSS より 30% 安い、攻めの値段になっている
- ElastiCache Serverless & Valkey を採用する場合、ストレージの最低料金が 100MB 基準になりミニマムコストが安い(Redis OSS の場合は 1GB)
- 今後 AWS 上で Redis OSS の新しいバージョンが降ってこない可能性を考慮した
Valkey が Redis より速い(Redis 8 が出る前)という話もありますが、この判断をしていた時は正直一部のケースが高速になった、というだけで実用上ではそこまで速くならないと判断してあまり信じてませんでした、のでメリットとにはあげておりません。つまりコストと今後のサポートを考慮し Valkey を採用することにしました。
移行する
いろいろ事前準備や確認を終わらせて 2025年3月中に移行をしました。 移行の戦略としては
- 新しいクラスタを確認してセッションがあればそれを使う
- なければ古い方をみにいく
- 書き込みは新しい方に
といったものになりました。もっと丁寧な方法として完全にダブルライトしている状態を経由する方針もありえますが、並行運用期間が長くなること、 変更内容からそこまで丁寧に進める必要はないという判断からこのような形になりました。 なお、同じクラスタに保存していたセッションに関係する一部のデータは上記の方法では完全に移行することができなかったので、愚直にコピーしました。
ElastiCache Serverless への移行時の注意点としては、やはり固有の制約でしょう。まずはすでに言及していたコマンドですが、今回のセッションストアであれば使うコマンドが単純で ElastiCache Serverless 固有のコマンド制約から外れることもありませんでしたが、たとえば Sidekiq のキューのバックエンドとして Valkey を使いたいとなればもう少し慎重に調べた方が良いでしょう。
コマンドだけではなく別の制約もあります。一覧は公式を参考にしていただきたいのですが、ほとんどは見ることのない数字が上限として設定されておりまして、主に気にすべきはリクエストごとの引数の数、およびキーの長さと考えます。データコピーをしていた時になぜか一部だけ失敗するという現象で大変頭を悩ませていたのですが、実は渡せる引数の数の制約が原因でした。みなさんは気をつけてください。
https://docs.aws.amazon.com/AmazonElastiCache/latest/dg/RedisConfiguration.html
監視に関して
サーバレスになってしまうことで、監視も見直す必要があります。渡されるメトリックス名が変わったのでそれの追従することももちろんですが、例えば CPU Utilization の監視は不要になったり、リクエストのスロットリングの監視を増やしたりしました。
パフォーマンス・コストの変化
パフォーマンス
上述した通り、早くなることは期待してなかったのですが、意外とインパクトはありました。
こちら、移行期間中のアプリケーションからみた各リクエストのレイテンシーの比較です。レイテンシー平均が 3ms から 2 ms に下がっており、単純比較でいうと 30%くらいは高速になりました。 並行期間中、書き込み、読み込みのパターンが微妙に違うという指摘がありえるかなと思いますが、この期間前後で各クラスタのレイテンシー平均は大きく変わっておりません。
Webアプリケーションにおいて1msのレイテンシー改善は、そこまで大きくありませんがこういう改善が集まってユーザー体験の向上していくのだと考えると歓迎すべき改善です。 グラフの右側をみると Valkey のレイテンシーが 1.5ms に減ったようにみえますが、これは数日後 2ms に戻っておりますので、おそらく確保してるキャパシティにより変動してると予想しています。その後の数ヶ月の様子だと 1.7-2ms で安定するようになりました。
最後に懸念点として挙げていたスパイク時のレイテンシーの変化ですが、少なくとも現状の規模ではわかりやすくレイテンシーが悪くなることは観測できず、問題なく稼働しています。
コスト
結論から言いますと約60% のコストを削減した形になりました。
こちらは切り替えが始ってから切り替えが完全に終わるまでのコスト比較になります。 MemoryDB から ElastiCache への移行で、 ElastiCache Serverless は従量課金ですので徐々に利用が増えてどの辺で移行が完了しているかみえるグラフになっております。
実は見積もりで出していた金額と大きく違っていたので詳細を確認しましたが、
- 元々のクラスタのストレージ使用量をレプリカ数で割ることで得た予想ストレージ利用量より、移行後実測したストレージ使用量の方が少なかった
- ECPU の計算が大きく外れていた。ECPUは主にデータ転送量に基づく課金単位なため、クラスタからのネットワークアウトバイトのメトリックスを参考に試算したのですが、実際の使用量は予想より大幅に少なかったです
ということがありました。単純にこちらの計算ミスかもしれませんが、もしそれっぽい原因に思い当たる節がある方はこっそり教えてください。見積もりの数字を外してしまっていましたが、課金が増える方向での間違いじゃなくてよかったです。サーバレスの課金の見積もりが難しい。
まとめ
Valkey Serverlessへの移行は結果としてパフォーマンス向上、コスト削減、運用負荷軽減の三拍子が揃った成果となりました。今後は別のクラスタでも Valkey の活用をポジティブに検討していこうと考えています。
