はじめに
こんにちは！ 昨年、株式会社レアゾン・ホールディングスに入社した2年目の鈴木 健介です。レアゾン・ホールディングスはmenuをはじめとする複数の事業を運営するグループ会社で、私はその中のmenu株式会社に配属されました。配属後は、マイクロサービスチームでGoogle Cloudを用いたクラウドインフラおよびマイクロサービスの開発・保守・運用をしています。最近はマイクロサービスチームと兼任で、技術的な負債解消や横断的な課題解決に取り組むdev-coreチームにも所属しています。
背景と移行の目的
menuでは、多くの機能にRedisを活用しています。これらは長年Google Compute Engine (GCE)上に構築したRedisクラスタで動いており、安定的に運用されていました。
一方でサービスが成長するにつれ、コストと運用効率をより最適化できる構成を検討するタイミングが来ました。そこで今回、フルマネージドサービスであるMemorystore for Redisへの移行に取り組みました。
移行によって期待できるメリットは主に以下の2点です。
料金の最適化：GCEのVMインスタンスは汎用的な構成のため、Redisのように特定リソースに特化した用途では費用対効果を上げる余地があります。Memorystoreはメモリ容量単位の課金でRedisの用途にフィットしたコスト構造です。
運用負荷の軽減：自前運用ではOSのパッチ当てやRedisプロセスの管理、インフラの監視対応など、機能開発に直接関係しないコストが発生し続けます。Memorystore for Redisに移行することでこれらをマネージドにすることができ、エンジニアのリソースをプロダクト開発に向けられます。
こうした背景から、自分からこのプロジェクトをやりたいと手を挙げ着手しました。
移行前のSandbox検証
本番に手をつける前に、まずSandbox環境で「GCE Redis」と「Memorystore for Redis」を並行稼働させ、同一のリクエストを流して挙動を比較しました。
確認したのは以下のような点で、ここに挙げるのはその一部です。
コマンド互換性：Memorystoreでは一部のコマンドが制限されています（参考: Supported and blocked commands）。現在利用しているコマンドが制限対象に含まれていないかを確認しました。
既存設定との差異確認：接続先が変わることで既存のキャッシュクラスがそのまま動作するかを実機ベースで確認しました。Memorystoreに接続してPINGが返ることを確認した後、実際にキャッシュクラスを経由した読み書きが正常に行われるかを検証しました。
ネットワークレイテンシ：同一VPC内のVPCネイティブ接続のためレイテンシの大幅増加はありませんでしたが、念のため計測しました。また、Memorystoreは読み取りレプリカが別エンドポイントで提供されるため、プライマリと読み取りレプリカの両方に接続できることを確認しました。
この段階で移行に問題がないことを確認しました。
段階的移行の進め方
一気に全切り替えをするとリスクが高いため、影響範囲と切り戻しやすさを基準に複数のフェーズへ分けてリリースを進めました。
Phase 1：確認しやすく・切り戻しやすいキャッシュから始める
最初のフェーズは「本番でMemorystoreが正常に動くことを確認する」ことが目的です。そのため、最初に選ぶキャッシュの基準は「スムーズに移行できなかった場合にすぐ気づけて、すぐ元に戻せる」ことを重視しました。
まずは、フォールバックが前提の設計になっている、DBのクエリの結果を一時的に保持しているキャッシュを選択しました。これにより、スムーズに移行できなかった際も即座にロールバックできる状態を確保しながら本番での動作確認を進めることができました。
Phase 2：書き込み頻度が高いキャッシュへ対象を広げる
Phase 1で動作確認が取れたら、より書き込み頻度が高いキャッシュへと対象を広げていきます。リリースのたびにMemorystoreへの書き込みが正常に行われているかを確認しながら進めました。
Phase 3：最もクリティカルなキャッシュを移行する
決済フローや認証に直結するキャッシュなど、問題が起きたときの影響が最も大きいものを最後に移行します。このフェーズはステージング環境での検証を最も厚くしてから本番に臨みました。
なお、一部のキャッシュでは接続先の切り替えだけでなく事前にデータの移行作業が必要なものもありました。そういったキャッシュは別フェーズとして切り出すことで、他の移行に影響を与えずに進めることができました。
Memorystoreを運用する上での注意点
移行後に運用して気づいた点として、公式ドキュメントに記載されている以下の制約は事前に把握しておくことをおすすめします。
CPU使用率の上限：プライマリノードでは80%、レプリカノードでは50%を超えないようにする必要があります（参考）。
メンテナンス時のメモリ制約：公式ドキュメントによると「メンテナンス更新時のシステムメモリ使用率は50%以下でなければならない」と記載されています。インスタンスをギリギリのメモリ量で設計すると、メンテナンス時に問題が発生する可能性があります。余裕を持ったキャパシティ設計を心がけましょう。
まとめ
今回はGCE上のRedisをMemorystore for Redisへ移行した取り組みを紹介しました。
移行自体はシンプルに見えても、事前のSandbox検証やフェーズの切り方、キャッシュごとの性質の把握など、丁寧に進めるべき工程が多くありました。特にフェーズ分けの基準として「切り戻しやすさ」を起点に考えたことが、安心して本番リリースを進める上で効いたと感じています。
マネージドサービスへの移行でインフラ管理の負担が減り、料金も約60%削減できました。その分のリソースを今後は別の改善に使えるようになったのが一番の成果だと感じています。同じような移行を検討している方の参考になれば幸いです。
▼新卒エンジニア研修のご紹介
レアゾン・ホールディングスでは、2025年新卒エンジニア研修にて「個のスキル」と「チーム開発力」の両立を重視した育成に取り組みました。 実際の研修の様子や、若手エンジニアの成長ストーリーは以下の記事で詳しくご紹介していますので、ぜひご覧ください！
▼採用情報
レアゾン・ホールディングスは、「世界一の企業へ」というビジョンを掲げ、「新しい"当たり前"を作り続ける」というミッションを推進しています。
現在、エンジニア採用を積極的に行っておりますので、ご興味をお持ちいただけましたら、ぜひ下記リンクからご応募ください。