アスクル株式会社における、Amazon ElastiCache for Valkey へのマイグレーションで実現するコスト最適化

本ブログは、アスクル株式会社と Amazon Web Services Japan が共同で執筆しました。

はじめに

アスクル株式会社（以下、アスクル）は、「お客様のために進化する」という DNA のもと、事業所向け通信販売サービス「ASKUL」や個人向け通信販売サービス「LOHACO」を運営しています。取り扱い商品はオフィス用品、生活用品、家具、製造業・建設業向けの専門用品、衛生・介護・薬局用品等の一般医療用商品・医薬品・医療機器等の医療材料まで多岐にわたります。 1,500 万アイテム以上の商品をワンストップで購入できるサービスを提供しています。

アスクルは 2019 年頃から主要システムのクラウドネイティブ環境への移行を段階的に実施し、SAP ERP をはじめとする多数の基幹システムのマイグレーションに成功しました。こうしたモダナイゼーションの取り組みの延長として、運用やコストの最適化にも継続的に取り組んでおり、Amazon ElastiCache を Redis から Valkey にマイグレーションすることで約 20% のコスト削減を実現しました。 本記事では、アスクルが ElastiCache を Redis から Valkey にマイグレーションした際の移行戦略、当日の作業手順、およびコスト最適化の成果について紹介します。

システム構成

アスクルは 2019 年から基盤システムのモダナイゼーションの一環としてマイクロサービスアーキテクチャを積極的に採用しています。社内で「Trylion（トライオン）」と呼ばれるプロジェクトの一部として、膨大な商品情報を管理する商品プラットフォームもマイクロサービス化されており、特に商品 API や外部サービス（広告出稿など）への商品情報連携バッチなど、高速な処理が求められる機能に Amazon ElastiCache を採用しています。

アスクルの商品プラットフォームでは、Amazon ElastiCache を以下の 2 つの用途で活用しています。

• 商品 API（Amazon ECS）: お客様が askul.co.jp にアクセスした際、商品 API が Amazon Aurora（PostgreSQL）から取得した結果（商品名、価格など）を Amazon ElastiCache にキャッシュします。これにより、同一商品への繰り返しアクセスに対してデータベースへの問い合わせを削減し、高速なレスポンスを実現しています。
• 商品更新バッチ（Amazon EC2）: 商品情報の更新処理において、冪等性の担保や並列処理時の処理重複を避けるために処理済み ID を Amazon ElastiCache にキャッシュしています。これにより、大量の商品データを効率的に更新できる仕組みを構築しています。

Valkey へのマイグレーションを検討した背景

モダナイゼーションの中ではコスト最適化も重要な課題です。ElastiCache のコストをさらに最適化するため、アスクルは Valkey への移行を検討しました。 Valkey は 40 社以上の支持を受けて Linux Foundation が運営するオープンソースプロジェクトです。Amazon ElastiCache では 2024 年 10 月 8 日に Valkey のサポートを開始しました。ElastiCache for Valkey はノードベースクラスターのコストが従来の ElastiCache for Redis OSS と比較して約 20% 低く、アスクルのコスト最適化の目標に合致していました。 加えて、Redis OSS の API およびデータフォーマットとの互換性があり、ダウンタイムゼロで移行できるオプションが提供されていることも魅力的で、前向きに検討してみる要因の一つになりました。これらの要素を総合的に評価し、アスクルは Valkey の採用を決定しました。特に、Redis OSS との API 互換性によりアプリケーションコードの改修が不要と見込まれた点は、移行の意思決定を後押しする大きな要因でした。

移行前の懸念事項と事前準備

Amazon ElastiCache では、既存の Redis クラスターをダウンタイムなしで Valkey へ移行するオプションが提供されており、その手軽さは魅力的でした。しかし、移行後に予期しない問題が発生した場合の切り戻しを考慮すると、インプレース移行だけでは不十分と判断しました。 そこでアスクルは、既存の Redis クラスターは維持したまま新規に Valkey クラスターを構築することで、問題が発生した場合でも Redis に即時切り戻せる体制を確保しました。ただし、新規 Valkey クラスターへの切り替えは API の参照先変更（= API リリース）を伴います。リリース直後はキャッシュが空の状態となるため、大量のキャッシュミスが発生するリスクがありました。これを軽減するため、商品 API の Amazon ECS サービスに対する AWS CodeDeploy のデプロイ設定を変更しました。 具体的には、ECSAllAtOnce（トラフィックを一度にすべて切り替える設定）から ECSLinear10PercentEvery3Minutes（3 分ごとにトラフィックの 10% ずつを新クラスターへ切り替える設定）に変更し、トラフィックを段階的に新クラスターへ誘導する方式を採用しました。これにより、ウォームアップ時間を確保しつつキャッシュミスの影響を最小限に抑えることができました。 また、本番移行前に開発環境で一連の流れを検証し懸念事項の解消を確認しました。 切り戻しの準備は、移行当日までに本番用の新規 Valkey クラスターを事前構築しておく程度だったため、手間なく当日の作業を最小化することができました。

移行当日の作業手順

移行当日は、インフラチームと開発チームが連携し、以下の手順で作業を進めました。

ステップ 1（インフラチーム）: CodeDeploy デプロイ設定を ECSAllAtOnce から ECSLinear10PercentEvery3Minutes に変更しました。

ステップ 2（開発チーム）: API をリリースし、参照先を Redis から Valkey へ変更しました。Valkey は Redis OSS と API 互換性があるため、アプリケーションコードの変更は接続先の設定変更のみで済みました。

ステップ 2-1（開発チーム）: Blue/Green デプロイの Green タスクセット（移行先環境）を使用して動作確認を実施しました。本番（Redis）と移行先環境（Valkey）のレスポンス結果を突合するスクリプトを実行し、レスポンス結果に差分がないことを確認しました。

ステップ 3（インフラチーム）: 動作確認完了後、CodeDeploy 設定を元の ECSAllAtOnce に戻しました。

移行作業は約 40 分で完了し、移行前後を通じてシステム側での問題は発生しませんでした。

移行結果と今後の展開

移行検討から本番移行の完了まで約 3〜4 か月のスケジュールで、無事に移行を完了しました。移行後の商品 API のレスポンスタイムは Redis 利用時と同等で、性能劣化は確認されませんでした。 Redis と Valkey を並行稼働させていたため一時的にコストが増加しましたが、Redis クラスター削除後は想定どおり約 20% のコスト削減を達成しました。さらに、リザーブドノードの購入を組み合わせることで、最終的に約 30% のコスト削減を実現しました。この成果を受けて、他プラットフォームでも同様の手順で Valkey への移行を進めています。また、今後新規に Amazon ElastiCache クラスターを構築する場合は Valkey を標準採用とする方針に変更しました。

まとめ

アスクルは十分な事前準備により、約 40 分という短時間で安全に ElastiCache for Redis OSS から Valkey へのマイグレーションを完了し、最終的には約 30% のコスト削減を実現しました。ElastiCache for Valkey への移行を検討されている方は、開始方法もあわせてご参照ください。

著者について

	荒木 泰詞 2023年にアスクル株式会社へ入社。Trylionのインフラをメインに、他のプロダクト も含めた設計・構築・運用保守を横断的に担当。JAWS-UGに参加し、AWSの学びを楽し みながらキャッチアップや情報発信活動を行っている
	中野 暁人 2018年にアスクル株式会社へ入社。商品プラットフォームの立ち上げ初期より参画 し、設計・実装・運用まで一貫して担当。OSSの公開およびコントリビュートに積極的 に取り組んでいる。
	藤田 将大 Database Specialist Solutions Architect として、担当テリトリーのお客様に対し、データベース全般の活用を技術支援してい ます。
	朴 総明 Technical Account Manager。AWS データベース技術コミュニティメンバーとしてデータベースの課題解決＆技術支援を しています。