Memorystore for Valkeyは、オープンソースのインメモリデータストアValkeyをGoogle Cloudがフルマネージドで提供するサービスです。2026年9月24日にValkey 9.1が一般提供（GA）となり、新規インスタンスの既定バージョンも9.1に切り替わりました。この記事では、クラスタモードとノードタイプの選び方、9.1で増えた機能、gcloudでの作成から接続までのコマンド、ノード時間課金の月額試算、自前のRedisやMemcachedから移行する手順を公式ドキュメントに沿って整理します。最後に、Memorystore for Valkeyを採用する条件と見送る場面を言い切ります。
まとめ：Memorystore for Valkeyの仕組み・9.1の新機能・採用判断
Memorystore for Valkeyは、シャードとレプリカの構成をノード単位で選び、Private Service Connect（PSC）経由のプライベートIPで接続するマネージドサービスです。クラスタモードは作成時にしか選べず、後から切り替えられません。ここが設計で最初に固める論点になります。
Valkey 9.1では、データベース単位のACL、CLUSTERSCANなどの新コマンド、スループット最大17%向上（GETは最大30%）が入りました。料金はノード数×ノードタイプ×稼働時間の1秒課金で、us-central1の表示価格では最小のshared-core-nano 1ノードが月約23ドル、highmem-mediumを3シャード×レプリカ1で組むと月約842ドルです。Google Cloud上で自前のRedisを運用している、またはMemorystore for Memcachedを使っているチームは、公式の移行機能があるため移行の第一候補になります。一方、AWSが主基盤のシステムにキャッシュだけ置くのは見送るべきです。
Memorystore for Valkeyの構成：クラスタモードとノードタイプの選び方
ValkeyそのもののRedisとの違いやデータ型の使い方は、ValkeyとRedisの違い・Streamsの使い方を解説した記事で扱っています。ここではGoogle Cloudのマネージド版に固有の設計要素だけを見ます。
クラスタモード有効と無効の接続先の違いと作成後に変更できない制約
インスタンスで選べるのは、Cluster Mode EnabledとCluster Mode Disabledの2種類です。有効にすると複数シャードへキーを分散でき、クライアントはディスカバリーエンドポイントに接続します。無効の場合は1シャード固定で、書き込み用のプライマリエンドポイントと、読み取りをレプリカへ振り分けるリーダーエンドポイントを使います。
公式のインスタンス作成手順では、--modeの既定はclusterで、作成後は変更できないと明記されています。無効で作ったインスタンスをクラスタ構成へ移すには、新しいインスタンスを作り直すしかありません。将来シャードを増やす可能性が少しでもあれば、最初から有効で作るのが安全です。
容量はノードタイプとシャード数で決まります。インスタンスとノードの仕様から主なタイプを抜き出すと次のとおりです（2026年10月時点）。
| ノードタイプ | vCPU | 書き込み可能容量 | ノード総容量 | SLA |
|---|---|---|---|---|
| shared-core-nano | 0.5 | 1.12 GB | 1.4 GB | なし |
| standard-small | 2 | 5.2 GB | 6.5 GB | あり |
| highmem-medium | 2 | 10.4 GB | 13 GB | あり |
| highcpu-medium | 8 | 10.4 GB | 13 GB | あり |
| highmem-xlarge | 8 | 46.4 GB | 58 GB | あり |
| highmem-2xlarge | 16 | 88 GB | 110 GB | あり |
shared-core-nanoはSLAの対象外なので、開発・検証環境に限ります。custom-picoなどのカスタムノードタイプはクラスタモード無効のインスタンスでしか選べません。クラスタモード有効でレプリカ0なら、highmem-2xlargeで書き込み可能容量は最大27,500 GBまで伸ばせます。
シャードあたりのレプリカ数0〜5と本番環境でのゾーン配置の判断基準
各シャードは1つのプライマリと0〜5個のレプリカで構成され、レプリカはゾーンに均等に分散されます。本番でレプリカ0は選ばないでください。プライマリのゾーン障害でそのシャードが書き込み不能になります。
レプリカを増やすとプライマリ数の上限が下がる点に注意が要ります。仕様ページでは、レプリカ0ならプライマリ250、レプリカ1なら125、レプリカ2なら83が上限です。読み取りを分散したいだけならレプリカ1〜2、ゾーン障害を2つ同時に想定するなら2以上、というのが実務の目安です。
Valkey 9.1 GAで増えた機能：DB単位ACL・CLUSTERSCAN・性能向上
Valkey 9.1は2026年7月27日にプレビューで追加され、9月24日にリリースノートで一般提供が告知されました。サポート対象は7.2・8.0・9.0・9.1の4系統です。
9.1で追加されたDB単位ACLとHGETDEL・MSETNX・CLUSTERSCAN
サポートバージョンのページに載っている9.1の変更点は次の4つです。
- I/Oスレッドと文字列処理の改善でスループット最大17%向上（GET操作は最大30%）
- ACLによるデータベース単位のアクセス制御
- 新コマンド
HGETDEL・MSETNX・CLUSTERSCAN HSETEXがNX・XXオプションに対応
実務で効くのはDB単位ACLです。クラスタモード無効のインスタンスで論理データベースを用途ごとに分け、アプリAにはDB0だけ、バッチにはDB1だけを許可する、という権限分離がインスタンスを分けずに書けます。CLUSTERSCANはクラスタ全体のキーを1本のカーソルで走査できるコマンドで、シャードごとにSCANを回していた保守スクリプトを短くできます。
9.0から入ったハッシュフィールド有効期限とCOMMANDLOG
7.2や8.0から上げる場合、9.0の変更も同時に入ります。ハッシュのフィールド単位で有効期限を付けられるようになり、セッション情報の一部だけを先に失効させる設計が、キーを分割せずに記述できる仕組みです。COMMANDLOGは低速なコマンドに加えて大きなリクエストや応答も記録するため、SLOWLOGでは見えなかった遅延の原因調査に使えます。パイプライン向けメモリプリフェッチでスループット最大40%向上という数値も公表されています。
バージョンアップは戻せないため検証用インスタンスで先に確かめる
公式ドキュメントには、インスタンスのバージョンを上げた後に以前のバージョンへ戻すことはできないと書かれています。7.2から9.1への飛び級アップグレードは可能です。
本番に当てる前に、同じエンジンバージョンの検証用インスタンスを作り、アプリケーションのクライアントライブラリと周辺ツールが新コマンドの応答や変わった挙動で壊れないかを確かめてください。shared-core-nanoのクラスタモード無効インスタンスなら月数十ドルで検証環境を用意できます。
gcloudでMemorystore for Valkeyを作成して接続するまでの手順
作成手順は、API有効化、サービス接続ポリシー作成、インスタンス作成、接続の4段です。gcloud CLIは489.0.0以降が必要とされています。以下のコマンドはプレースホルダ（大文字部分）を自分の環境の値に置き換えて使います。
APIの有効化とgcp-memorystoreのサービス接続ポリシー作成
Memorystore for Valkey API、Network Connectivity API、Service Consumer Management APIの3つを有効にします。続いて、接続するVPCネットワークにサービスクラスgcp-memorystoreのサービス接続ポリシーを作ります。ポリシー作成のフラグは、サービス接続ポリシーの設定手順に沿った指定です。
gcloud services enable memorystore.googleapis.com \
networkconnectivity.googleapis.com \
serviceconsumermanagement.googleapis.com
gcloud network-connectivity service-connection-policies create valkey-policy \
--network=NETWORK \
--project=PROJECT_ID \
--region=asia-northeast1 \
--service-class=gcp-memorystore \
--subnets=https://www.googleapis.com/compute/v1/projects/PROJECT_ID/regions/asia-northeast1/subnetworks/SUBNETポリシーはネットワークとリージョンの組ごとに1つ作れば、同じ組の後続インスタンスでも使い回せます。
gcloud memorystore instances createで3シャード作成
東京リージョンに、highmem-mediumを3シャード×レプリカ1で、エンジンバージョン9.1のクラスタモード有効インスタンスを作る例です。--engine-versionを省略しても9.1になりますが、意図を残すため明示しています。
gcloud memorystore instances create my-valkey \
--location=asia-northeast1 \
--endpoints='[{"connections": [{"pscAutoConnection": {"network": "projects/PROJECT_ID/global/networks/NETWORK", "projectId": "PROJECT_ID"}}]}]' \
--shard-count=3 \
--replica-count=1 \
--node-type=highmem-medium \
--engine-version=VALKEY_9_1 \
--mode=clusterインスタンスIDは1〜63文字の英小文字・数字・ハイフンで、英小文字始まりという規則があります。この構成はプライマリ3＋レプリカ3の計6ノードとして課金されます。
ディスカバリーエンドポイントを調べてvalkey-cliで接続する
作成後、describeの出力にあるendpointsから、connectionTypeがCONNECTION_TYPE_DISCOVERYのエントリのipAddressとportを控えます。CONNECTION_TYPE_DATAはMemorystoreの内部用なので接続先にしません。
gcloud memorystore instances describe my-valkey --location=asia-northeast1
# 同じVPC内のCompute Engine VMから接続（-c はクラスタ対応モード）
valkey-cli -h DISCOVERY_ENDPOINT_ADDRESS -p PORT_NUMBER -c
# 接続後のプロンプトで実行
SET greeting "hello"
GET greeting
INFO server公式の接続手順によれば、-cを付けないと別シャードのキーに触れた時点でMOVEDエラーになります。アプリケーション側も同じで、クラスタ対応のクライアントを使う必要があります。ファイアウォールではPSCエンドポイント向けにTCP 6379とTCP 11000〜13047を許可してください。
料金の計算：ノード時間課金と構成別の月額試算（us-central1）
Memorystore for Valkeyには、Serverless型のような処理量課金はありません。プロビジョニングしたノードに対して、使っていなくても秒単位で課金されます。
ノードタイプ別の時間単価と1年・3年の確約利用割引による料金の比較
公式の料金ページで既定表示されるus-central1（アイオワ）の1ノードあたり時間単価は次のとおりです（2026年10月12日時点・米ドル）。確約利用割引（CUD）は1年で20%、3年で40%の割引になります。
| ノードタイプ | 容量 | 通常 | 1年CUD | 3年CUD |
|---|---|---|---|---|
| shared-core-nano | 1.4 GB | $0.0318 | $0.02544 | $0.01908 |
| standard-small | 6.5 GB | $0.1425 | $0.114 | $0.0855 |
| highmem-medium | 13 GB | $0.1923 | $0.15384 | $0.11538 |
| highmem-xlarge | 58 GB | $0.8581 | $0.68648 | $0.51486 |
東京（asia-northeast1）の単価は料金ページのリージョン選択で切り替えて確認してください。上の値はアイオワの表示であり、東京の単価とは一致しません。バックアップの保管とAOF永続化はGB時間で別途課金されます。
開発用1ノードから本番3シャード構成までのノード数に応じた月額試算
1か月を730時間として、us-central1の通常単価で試算すると次のようになります。
- 開発用：shared-core-nano×1ノード（クラスタモード無効）＝$0.0318×730時間で約23ドル
- 小規模本番：standard-small×2ノード（プライマリ1＋レプリカ1）＝約208ドル
- 中規模本番：highmem-medium×6ノード（3シャード×レプリカ1）＝約842ドル、1年CUDで約674ドル、3年CUDで約505ドル
費用の大半はノード数で決まります。レプリカ数を1から2に増やすとノード数が1.5倍になり、月額も1.5倍です。コストを下げる最初の打ち手はノードタイプの格下げではなく、実際のメモリ使用量に対してシャード数とレプリカ数が過剰でないかを見直すことです。
自前RedisとMemcachedからValkeyへ移行する手順と制約
2026年8月13日、Google Cloud上の自前Redis・Valkeyから移行する機能が一般提供になりました。Memorystore for Memcachedの非推奨化も進んでおり、移行の判断材料がそろっています。
Redis 3.2〜7.2を対象にしたレプリケーション型移行の流れ
公式の移行ガイドによると、移行元はRedis 3.2.x〜7.2.xとValkey 7.x〜9.xです。移行先インスタンスが移行元のレプリカとして動き、データを継続的に複製します。移行先はあらかじめ同じプロジェクト・リージョンに作成しておき、移行元と同じクラスタモードにします。
gcloud memorystore instances start-migration my-valkey \
--project=PROJECT_ID \
--location=asia-northeast1 \
--source-ip=SOURCE_IP_ADDRESS \
--source-port=6379 \
--network-attachment=projects/PROJECT_ID/locations/asia-northeast1/networkAttachments/NETWORK_ATTACHMENT_ID
# state が MIGRATING になり、Migration status メトリクスが HEALTHY になったら切り替え
gcloud memorystore instances finish-migration my-valkey \
--project=PROJECT_ID \
--location=asia-northeast1データの完全な一致が必要なら、finish-migrationの前に移行元への書き込みを止めます。完了後にアプリケーションの接続先を移行先へ向け替えます。
移行元でAUTHとTLSを無効化する前提とつまずきやすい設定
この移行機能で最も引っかかりやすいのは、移行元のAUTHとTLSを無効化する必要がある点です。認証を外せない運用ルールがある環境では、そのまま使えません。ほかにも、protected-modeの無効化、bind設定とファイアウォールの更新、複製に使うPSYNCなどのコマンド名を変更していないことが条件になります。
クラスタモード有効なら移行先のシャード数を移行元と同数に、無効なら論理データベース数を移行元以上にそろえます。ネットワークアタッチメントのサブネットは10.0.0.0/23と重ならないように取り、移行先ノード数＋1個以上のIPアドレスを確保してください。
Memorystore for Memcachedの非推奨化と移行期限
Memcachedの非推奨化のお知らせでは、2026年1月20日に推奨サービスから外れ、2027年2月1日以降は既存インスタンスの無いプロジェクトで新規作成ができなくなり、2029年1月31日にサポートが終了すると示されています。推奨移行先の筆頭はMemorystore for Valkeyです。
MemcachedとValkeyはプロトコルが異なるため、レプリケーション型の移行機能は使えません。キャッシュ用途ならデータの移送は不要で、クライアントライブラリを差し替えて空のValkeyへ向け、キャッシュを温め直す切り替えが現実的です。
Memorystore for Valkeyを採用する条件と見送る場面の判断
採用と見送りの境界を条件で示します。
AWSのElastiCache for Valkeyと比べたときの違い
同じValkeyのマネージドサービスでも、AWSのElastiCacheにはノードを意識しないServerless型があり、処理量（ECPU）とデータ量で課金されます。Memorystore for Valkeyはノード課金だけなので、負荷の波が大きいサービスではElastiCache Serverlessのほうが費用を抑えやすい場合があるという違いです。AWS側の料金計算はElastiCache Serverless for Valkeyの料金と上限値をまとめた記事、エンジンとデプロイ方式の全体像はAmazon ElastiCacheの対応エンジンと採用判断の記事で比べられます。
実際の選択はキャッシュ単体の機能差では決まりません。アプリケーションとデータベースが乗っているクラウドで決まります。キャッシュだけ別クラウドに置くと、往復の遅延とクラウド間の転送料金がキャッシュの効果を打ち消すからです。
採用する条件：Google Cloud上の自前Redisやセッション基盤
次のどれかに当てはまるなら、Memorystore for Valkeyを第一候補にしてよいと考えます。
- Compute EngineやGKE上で自前のRedisを運用していて、パッチ適用やフェイルオーバーの手間を減らしたい
- Memorystore for Memcachedを使っており、2027年2月の新規作成停止までに移行先を決める必要がある
- Cloud RunやGKEのアプリのセッション管理・レート制限・ランキングに、レプリカ付きのインメモリ基盤が要る
- 1つのインスタンスを複数アプリで共有し、9.1のDB単位ACLで権限を分けたい
Google Cloud上のキャッシュ基盤の構成やRedisからの移行計画の立て方に迷う場合は、AWS・Google Cloud・Azureのインフラ構築支援で設計段階から相談できます。
採用を見送る場面：AWS主体のシステムやAUTHが必須となる移行元
アプリケーションとDBがAWSにあるなら採用しません。ElastiCacheを選ぶべきで、その選び分けはAWSでRedisを使う方法の記事で整理しています。
次に、移行元のAUTHやTLSを移行期間中も外せないRedisは、公式の移行機能の対象外です。この場合はRIOTなどのツールによるデータコピーか、キャッシュを捨てて温め直す切り替えを計画に組み込みます。キャッシュではなく正のデータを置く永続ストアとして使う設計も見送りです。RDB・AOFの永続化はありますが、台帳や決済のような失えないデータはCloud SQLなどのデータベースに置き、Memorystoreはその前段に置く構成を守ります。キーバリュー型ストアとRDBの役割分担はKVSとRDBの使い分けを解説した記事が前提知識になります。
よくある質問：Memorystore for Valkeyの料金・移行・バージョン
Memorystore for Valkeyを検討する際によく出る疑問に、公式ドキュメントの記載をもとに答えます。
Memorystore for ValkeyとMemorystore for Redisは何が違いますか？
両サービスの違いは、内部で動いているエンジンの種類です。Memorystore for RedisはRedis OSS、Memorystore for ValkeyはLinux Foundation傘下のOSSであるValkeyを使います。ValkeyはRedis OSS 7.2のAPIと互換性があるため、多くのアプリケーションはクライアントを変えずに接続できます。Valkey版は9.1のDB単位ACLやCLUSTERSCANなど新しいバージョンの機能を受け取れる点と、Memcachedからの推奨移行先の筆頭に挙がっている点が判断材料です。新規構築ならValkey版から検討するのが自然です。
既存のRedisクライアントライブラリはそのまま使えますか？
クラスタモード無効のインスタンスなら、Redis互換のクライアントでプライマリエンドポイントへ接続するだけで使えます。クラスタモード有効の場合は、クラスタ対応のクライアント（valkey-cliなら-c付き）が必要です。非対応のクライアントでは別シャードのキーに触れた時点でMOVEDエラーになります。また、Memorystore for ValkeyはValkeyのコマンドすべてではなく一部のサブセットをサポートしているため、運用スクリプトで管理系コマンドを使っている場合は事前に確認してください。
最小構成の料金はいくらですか？無料で試せますか？
us-central1の表示価格では、shared-core-nano（1.4 GB）の1ノードが1時間$0.0318で、730時間換算で月約23ドルです。これが最も安い構成ですが、SLAの対象外なので開発・検証用に限ります。料金ページにはこのサービス専用の無料枠の記載は無く、作成した時点から秒単位で課金されます。検証が終わったらインスタンスを削除してください。バックアップは自動削除されない点にも注意が要ります。
バージョンを9.1に上げた後で元に戻せますか？
戻せません。公式ドキュメントは、アップグレード後に以前のバージョンへダウングレードできないと明記しています。7.2から9.1へ一度に上げることはできるため、本番と同じ構成の検証用インスタンスを9.1で作り、アプリケーションの動作確認を済ませてから本番を上げる順序にしてください。新規作成時は--engine-versionを省略すると9.1になります。
東京リージョンでMemorystore for Valkeyを使えますか？
使えます。料金ページのリージョン一覧にTokyo（asia-northeast1）とOsaka（asia-northeast2）が並んでいます。単価はリージョンごとに異なるため、見積もりでは料金ページで東京を選び直してから計算してください。なお移行機能は移行元と同じリージョンに移行先を置くことが条件です。
関連記事
- Valkeyとは？Redisとの違い・Streamsの使い方と導入手順【Valkey 9.1】：エンジンであるValkey自体の機能とRedisとの違い
- ElastiCache Serverless for Valkeyとは？料金の計算・上限値と作成手順【Valkey 9対応】：AWSでValkeyをサーバーレスで使う場合の比較対象
- Amazon ElastiCacheとは？対応エンジン・Serverlessとノードベースの違いと料金・採用判断を実装者目線で解説：AWS側のマネージドキャッシュの全体像
- AWSでRedisを使う方法：ElastiCache・MemoryDB・EC2の選び分けと接続手順：AWS主体のシステムでの選び分け
- KVS（キーバリューストア）とは：Redisで動かして分かる仕組みとRDBとの使い分け【2026年版】：キャッシュとデータベースの役割分担の前提
