GCP Cloud Memorystore for Redisを徹底解説！特徴、料金、導入手順

By /

GCP Cloud Memorystore for Redisを徹底解説！特徴、料金、導入手順

はじめに

現代のクラウドネイティブアプリケーション開発において、データへの高速なアクセスは不可欠です。特に、Webアプリケーションのセッション管理、データベースのキャッシュ、リアルタイム分析、ゲームのリーダーボードといった用途では、ミリ秒以下のレイテンシが求められます。リレーショナルデータベースや一般的なファイルシステムでは、このような要求を満たすことは困難です。そこで登場するのが、インメモリデータストアです。

インメモリデータストアは、データをディスクではなくRAM上に保持することで、非常に高速な読み書きを実現します。その中でも、Redis（Remote Dictionary Server）は、オープンソースのインメモリデータ構造ストアとして、世界中で最も広く利用されています。キー・バリューペアだけでなく、リスト、セット、ソート済みセット、ハッシュ、ビットマップ、ハイパーログログ、ジオ空間インデックスなど、多様なデータ構造をサポートし、Pub/Sub機能やLuaスクリプティング機能も備えています。その柔軟性と高速性から、様々なアプリケーションの基盤として活用されています。

しかし、オンプレミスや自己管理型の環境でRedisクラスターを構築・運用するには、多くの手間と専門知識が必要です。サーバーのプロビジョニング、ソフトウェアのインストールと設定、クラスターの構築、レプリケーション設定、監視、パッチ適用、バックアップ、障害発生時の復旧など、運用タスクは多岐にわたります。これらの運用負荷は、特にリソースが限られているチームにとっては大きな課題となります。

そこで、Google Cloud Platform (GCP) が提供するのが、Cloud Memorystore for Redisです。Cloud Memorystoreは、スケーラブルで可用性の高いRedisサービスを、完全にマネージドな形で提供します。これにより、ユーザーはインフラストラクチャの管理に煩わされることなく、アプリケーション開発とビジネスロジックに集中できます。本記事では、このCloud Memorystore for Redisについて、その特徴、料金体系、そして具体的な導入手順までを、約5000語のボリュームで徹底的に解説します。

Cloud Memorystore for Redisとは何か

Cloud Memorystore for Redisは、GCPが提供するフルマネージドなRedisサービスです。これは、オープンソースのRedisと完全に互換性があり、既存のRedisクライアントライブラリやツールをそのまま利用できます。ユーザーはRedisインスタンスのプロビジョニング、パッチ適用、監視、レプリケーション、フェイルオーバーといった煩雑な運用作業から解放されます。GCPはこれらのタスクをバックグラウンドで自動的に実行し、インスタンスの可用性とパフォーマンスを維持します。

Cloud Memorystoreは、インメモリデータストアが求められる様々なワークロードに対応するために、以下の2つのエディション（ティア）を提供しています。

  1. Basic Tier: 開発、テスト、あるいはデータ消失のリスクを許容できる非ミッションクリティカルなアプリケーション向けのシングルノードインスタンスです。コスト効率を重視する場合に適しています。
  2. Standard Tier: 高可用性と耐久性を重視するミッションクリティカルな本番アプリケーション向けのインスタンスです。自動フェイルオーバーを備え、高い可用性SLAを提供します。

どちらのティアも、オープンソースRedisの豊富なデータ構造とコマンドセットをサポートしており、非常に高速なデータアクセスを実現します。

Cloud Memorystore for Redisの主な特徴

Cloud Memorystore for Redisが多くの企業や開発者に選ばれる理由は、その豊富な特徴にあります。ここでは、主要な特徴を詳しく見ていきましょう。

1. フルマネージドサービス

Cloud Memorystoreの最も重要な特徴は、そのフルマネージドであるという点です。これは、Redisインスタンスのライフサイクル全体にわたるインフラストラクチャの管理責任をGCPが負うことを意味します。

  • プロビジョニングと設定: 数クリックまたは簡単なコマンドでRedisインスタンスを作成できます。容量、リージョン、ティア、バージョンなどを指定するだけで、GCPがサーバーリソースを準備し、Redisをインストール・設定します。
  • パッチ適用とアップグレード: 基盤となるオペレーティングシステムやRedisソフトウェアのセキュリティパッチ適用、バージョンアップグレードはGCPが自動またはスケジュールに従って行います。これにより、常に最新かつ安全な環境を維持できます。
  • 監視とアラート: CPU使用率、メモリ使用率、ネットワークトラフィック、接続数、キャッシュヒット/ミス率など、インスタンスの健全性やパフォーマンスに関する多様なメトリクスを自動的に収集し、Cloud Monitoringで確認できます。これらのメトリクスに基づいてアラートを設定することも可能です。
  • 障害検出と自動修復: ハードウェア障害やソフトウェアエラーが検出された場合、GCPは自動的に問題を診断し、必要に応じてインスタンスの再起動や、Standard Tierの場合はフェイルオーバーを実行してサービスの中断を最小限に抑えます。
  • バックアップとリストア: インスタンスのスナップショットを取得し、必要に応じてそのスナップショットからデータを復旧できます。

これらの運用タスクから解放されることで、開発チームはインフラの保守よりも、アプリケーションの機能開発や改善に集中できるようになります。これは、特にマイクロサービスアーキテクチャを採用している場合や、運用リソースが限られているスタートアップにとっては大きなメリットとなります。

2. 高いパフォーマンスとスケーラビリティ

Cloud Memorystoreは、インメモリデータストアとしてのRedisの強みを最大限に引き出す設計になっています。

  • 低遅延: データがメモリ上に存在するため、ディスクI/Oが発生せず、非常に低いレイテンシ（通常ミリ秒以下）で読み書きが可能です。これにより、リアルタイム性が求められるアプリケーションに適しています。
  • 高スループット: ネットワーク経由でのアクセスは高速であり、多数の同時接続と高いリクエストレートを処理できます。
  • 容量スケーリング: インスタンスの容量を、アプリケーションの成長に合わせて簡単にスケールアップまたはスケールダウンできます。Basic Tier、Standard Tierともに、最小1GBから最大5TBまで容量を増減させることが可能です（バージョンやリージョンによって上限は異なる場合があります）。Standard Tierでは、スケールアップ時にダウンタイムを最小限に抑える工夫がされています。

3. オープンソースRedisとの完全な互換性

Cloud Memorystore for Redisは、オープンソースのRedisと完全に互換性があります。これは非常に重要な特徴です。

  • 既存のクライアントライブラリ: Java, Python, Node.js, Ruby, PHP, C#, Goなど、Redisに対応した様々な言語のクライアントライブラリをそのまま利用できます。特別なクライアントライブラリは必要ありません。
  • 既存のコマンドセット: オープンソースRedisで利用できるほぼ全てのコマンド（SET, GET, LPUSH, LPOP, HSET, HMGET, ZADD, ZRANGE, PUBLISH, SUBSCRIBEなど）をそのまま利用できます。これにより、オンプレミスやVM上の自己管理RedisからCloud Memorystoreへの移行が容易になります。
  • 移行の容易性: 既存のRedisワークロードをCloud Memorystoreに移行する際、アプリケーションコードの変更を最小限に抑えることができます。

ただし、一部の管理コマンドやファイルシステムにアクセスするコマンドなど、フルマネージドサービスとして提供する上で適切ではないコマンド（例: DEBUG, CONFIG, BGSAVE, SHUTDOWNなど）は制限されています。利用可能なコマンドのリストは公式ドキュメントで確認できます。

4. 高可用性 (Standard Tier)

Standard Tierは、ミッションクリティカルな本番アプリケーションのために設計されており、高い可用性を提供します。

  • レプリケーション: インスタンス作成時に指定したリージョン内の複数のゾーンに、プライマリノードとレプリカノードが自動的にプロビジョニングされます。データはプライマリからレプリカに非同期でレプリケーションされます。
  • 自動フェイルオーバー: プライマリノードに障害が発生した場合、Cloud Memorystoreは自動的にレプリカノードの1つを新しいプライマリノードに昇格させます。このフェイルオーバープロセスは通常数十秒から数分で完了し、アプリケーションからの接続は新しいプライマリノードに自動的にリダイレクトされます。これにより、サービスのダウンタイムを最小限に抑えられます。
  • SLA: Standard Tierは、高い可用性に関するサービスレベル契約（SLA）によって裏付けられています。

Basic Tierはシングルノード構成のため、ノードに障害が発生した場合、サービスが停止し、データが失われる可能性があります。したがって、本番環境やデータ耐久性が重要なワークロードにはStandard Tierを選択する必要があります。

5. 強固なセキュリティ

Cloud Memorystoreは、GCPの強固なセキュリティインフラストラクチャと統合されています。

  • VPCネットワーク統合: RedisインスタンスはVPC (Virtual Private Cloud) ネットワーク内にデプロイされます。デフォルトでは、同じVPCネットワーク内のリソース（Compute Engine VM、GKE Podなど）からのみプライベートIPアドレス経由でアクセス可能です。これにより、インターネットからの直接アクセスを防ぎ、安全なネットワーク環境を構築できます。
  • ファイアウォールルール: VPCファイアウォールルールを使用して、特定のIPアドレス範囲やVMインスタンスからのアクセスのみを許可するなど、アクセスを細かく制御できます。
  • IAM (Identity and Access Management): GCP IAMを使用して、誰がどのMemorystoreインスタンスに対してどのような操作（作成、削除、変更など）を行えるかを細かく制御できます。最小限の権限付与の原則に基づいたアクセス管理が可能です。
  • Redis AUTH: Redisの組み込み認証機能であるAUTHコマンドを使用して、パスワードによるアクセス認証を有効化できます。これにより、ネットワークレベルのアクセス制御に加えて、アプリケーションレベルでの認証を強制できます。パスワードはGCPによって安全に管理されます。
  • 暗号化: データは、転送中（ネットワーク経由）および保管時（ストレージ）の両方で暗号化されます。GCPが管理するキーによる暗号化がデフォルトで有効になっています。

6. モニタリングとロギング

Cloud Memorystoreは、GCPの包括的なオペレーションスイート（以前のStackdriver）と緊密に統合されています。

  • Cloud Monitoring: RedisインスタンスのCPU使用率、メモリ使用率、ネットワークスループット、接続数、キャッシュヒット率、エラー率、コマンド実行数など、多数のメトリクスがCloud Monitoringに自動的にエクスポートされます。これらのメトリクスを使用して、カスタムダッシュボードを作成したり、パフォーマンスのボトルネックを特定したり、キャパシティプランニングを行ったりできます。閾値に基づいたアラートポリシーを設定することで、問題発生時に通知を受け取ることができます。
  • Cloud Logging: インスタンスの作成、変更、削除などの管理操作や、認証失敗などのイベントはCloud Loggingに記録されます。これにより、監査証跡を追跡したり、問題の原因究明を行ったりできます。

7. バックアップとリストア

データの耐久性を確保し、誤操作や障害から復旧するために、Cloud Memorystoreはバックアップ（スナップショット）機能を提供します。

  • スナップショット: Redisインスタンスの特定の時点のデータをスナップショットとして保存できます。この機能は、RDBファイル形式でデータをエクスポートするオープンソースRedisのBGSAVEコマンドに相当しますが、マネージドサービスとして提供されます。
  • ポイントインタイムリカバリ (PITR): 特定の時点（数秒単位の精度）にインスタンスの状態を復旧できる機能です。誤ってデータを削除してしまった場合などに有効です。
  • リストア: 保存されたスナップショットから新しいRedisインスタンスを作成したり、既存のインスタンスにデータを復旧したりできます。

この機能により、データ損失のリスクを低減し、ビジネス継続性を確保できます。

Cloud Memorystore for Redisが適しているユースケース

Cloud Memorystore for Redisは、その高速性、スケーラビリティ、柔軟性から、様々なアプリケーションやワークロードに利用できます。代表的なユースケースをいくつか紹介します。

  • セッションストア: Webアプリケーションやモバイルアプリケーションのユーザーセッションデータを保存するために利用されます。Redisは低遅延でキー・バリューペアを扱えるため、セッションデータの読み書きが高速に行え、ユーザーエクスペリエンスを向上させます。
  • キャッシュ: データベースクエリ結果、APIレスポンス、レンダリング済みHTMLフラグメントなど、頻繁にアクセスされるが変更が少ないデータをキャッシュするために利用されます。これにより、バックエンドデータベースへの負荷を軽減し、アプリケーションの応答時間を短縮できます。キャッシュヒット率を高めることで、全体のパフォーマンスを大幅に改善できます。
  • リアルタイム分析とストリーム処理: 高速に発生するイベントデータを取り込み、集計や分析をリアルタイムで行うためのバッファや中間データストアとして利用されます。Redisのデータ構造（例: ソート済みセット）やPub/Sub機能が活用できます。
  • Pub/Subメッセージング: 軽量なメッセージブローカーとして、マイクロサービス間の通信やイベント通知に利用されます。RedisのPUBLISH/SUBSCRIBEコマンドを使用します。
  • レート制限: APIエンドポイントへのアクセスレートを制限するために利用されます。RedisのINCRコマンドやLuaスクリプティングを用いて、アクセス回数をカウントし、制限を超えたリクエストを拒否するロジックを実装できます。
  • ゲームのリーダーボード: ユーザーのスコアをソート済みセット（Sorted Set）として保存し、リアルタイムにリーダーボードを表示するために利用されます。スコアの更新やランキングの取得が非常に高速です。
  • 地理空間データストア: Redisの地理空間インデックス機能（GEOコマンド）を利用して、緯度・経度データを持つオブジェクトを保存し、指定した地点から一定範囲内のオブジェクトを検索するなどの処理を行います。位置情報サービスやマッチングサービスに活用できます。
  • キュー: リスト（List）データ構造をキューとして利用し、非同期処理やタスクの引き渡しに利用されます。LPUSH/RPUSHで要素を追加し、LPOP/RPOPで要素を取り出すといった操作を行います。
  • カウンタと統計: アクセス数、いいね数などのカウンターや、特定のイベント発生回数などを高速に集計・管理するために利用されます。INCRBYコマンドなどが役立ちます。

これらのユースケースにおいて、Cloud Memorystoreはインフラ管理の負担なく、スケーラブルで信頼性の高いRedis環境を提供します。

Cloud Memorystore for Redisのエディション

Cloud Memorystore for Redisには、前述の通り Basic Tier と Standard Tier の2つのエディションがあります。どちらを選択するかは、アプリケーションの要件（パフォーマンス、可用性、コスト）によって異なります。

Basic Tier

  • 構成: シングルノードインスタンスです。
  • 可用性: 高可用性機能はありません。ノードに障害が発生した場合、インスタンスは利用できなくなり、データは失われる可能性があります。GCPによる自動再起動が行われる場合もありますが、復旧時間は保証されず、データ永続性も保証されません。
  • パフォーマンス: Standard Tierと同等の低遅延・高スループットを提供しますが、レプリケーションのオーバーヘッドがないため、理論上は書き込み性能が若干高くなる可能性があります。
  • スケーリング: 容量のスケールアップ/ダウンは可能ですが、シングルノード構成のため、大規模なトラフィックやデータセットには限界があります。
  • コスト: Standard Tierに比べて低コストです。
  • 適した用途: 開発環境、テスト環境、ステージング環境、あるいはキャッシュとして利用しており、データ損失が発生しても大きな問題とならない非ミッションクリティカルなアプリケーション。

Standard Tier

  • 構成: プライマリノードと1つ以上のレプリカノードで構成される高可用性インスタンスです。ノードは指定したリージョン内の複数のゾーンに分散配置されます。
  • 可用性: 自動フェイルオーバー機能により、プライマリノードに障害が発生しても、レプリカが新しいプライマリに昇格することでサービスが継続されます。高い可用性SLAが提供されます。データはレプリカに複製されるため、プライマリノードの障害によるデータ損失リスクが大幅に低減されます。
  • パフォーマンス: レプリケーションのオーバーヘッドがあるため、書き込みスループットはBasic Tierより若干低くなる可能性がありますが、読み込みスループットはレプリカノードを利用することでスケールアウト可能です。Standard Tierのレプリカは読み込みレプリカとして利用でき、読み込み負荷を分散できます。
  • スケーリング: 容量のスケールアップ/ダウンに加えて、読み込み負荷に応じてレプリカ数を増やすことで読み込みスループットをスケールアウトできます。
  • コスト: Basic Tierに比べて高コストです。ノード数（プライマリ＋レプリカ）と容量に基づいて課金されます。
  • 適した用途: 本番環境、ミッションクリティカルなアプリケーション、データ永続性や高い可用性が必須となるワークロード（セッションストア、重要なキャッシュ、リーダーボードなど）。

どちらのティアを選択するかは、RPO (Recovery Point Objective) と RTO (Recovery Time Objective)、そしてコストのバランスを考慮して決定する必要があります。本番環境で利用する場合は、特別な理由がない限りStandard Tierを選択することを強く推奨します。

料金体系

Cloud Memorystore for Redisの料金は、主に以下の要素に基づいて計算されます。

  1. インスタンスのティア: Basic TierかStandard Tierか。Standard Tierの方が高くなります。
  2. インスタンスの容量: プロビジョニングしたインスタンスのメモリ容量（GB単位）に基づいて課金されます。容量が大きいほど高くなります。
  3. インスタンスのリージョン: リージョンによって料金が異なります。一般的に、アジアやヨーロッパのリージョンは北米のリージョンよりも料金が高くなる傾向があります。
  4. ネットワーク下り（外向き）料金: Redisインスタンスからインターネットや他のリージョンのGCPサービスへのデータ転送に対して課金される場合があります。同じリージョン内のGCPサービス（Compute Engine, GKEなど）へのデータ転送は、通常無料または低コストです。

料金の具体例 (注意: 料金は変更される可能性があります。必ず公式の料金ページで最新情報を確認してください):

例として、us-central1 リージョンにおける料金のイメージを示します。

  • Basic Tier:
    • 1GB の場合: ~$0.02 / 時間
    • 5GB の場合: ~$0.07 / 時間
    • 10GB の場合: ~$0.13 / 時間
    • 50GB の場合: ~$0.65 / 時間
  • Standard Tier:
    • 1GB の場合: ~$0.04 / 時間
    • 5GB の場合: ~$0.14 / 時間
    • 10GB の場合: ~$0.26 / 時間
    • 50GB の場合: ~$1.30 / 時間

(注: これらの価格は単なる例であり、公式価格とは異なります。正確な料金はGCPのCloud Memorystore for Redis料金ページをご確認ください。)

Standard Tierは、プライマリノードとレプリカノードの両方に対して容量ベースで課金されます。例えば、5GBのStandard Tierインスタンスは、プライマリ5GBとレプリカ5GBを持つ構成となり、合計10GB相当の容量に対して料金が発生すると考えることができます（内部的なレプリケーションやオーバーヘッドにより計算はもう少し複雑ですが、イメージとして）。

コスト最適化のヒント:

  • 適切なティアの選択: 開発/テスト環境や非ミッションクリティカルな用途ではBasic Tierを選択し、コストを抑えます。
  • 適切な容量の選択: 必要以上に大きな容量をプロビジョニングしないようにします。アプリケーションのデータサイズやトラフィックをモニタリングし、必要に応じて容量を調整します。メモリ使用率が継続的に高い場合は、容量をスケールアップすることを検討します。
  • エビクションポリシーの利用: キャッシュとして利用する場合、メモリが一杯になったときに古いキーやあまりアクセスされないキーを自動的に削除するエビクションポリシー（例: allkeys-lru, volatile-lruなど）を設定することで、メモリ使用量を効率的に管理し、無駄な容量増加を防ぐことができます。
  • 無料枠の確認: GCPには無料枠があり、一定量のCloud Memorystore利用が無料になる場合があります。ただし、無料枠は制限が厳しいため、本番環境での利用には適していません。学習や少量のテスト目的で確認すると良いでしょう。
  • GCP料金計算ツールの利用: GCPウェブサイトにある料金計算ツールを使って、想定される構成（ティア、容量、リージョンなど）に基づいた月額料金を試算できます。

料金は変動する可能性があるため、常にGCPの公式ドキュメントや料金計算ツールで最新の情報を確認することが重要です。

Cloud Memorystore for Redisの導入手順

ここでは、GCP Consoleとgcloud CLIの両方を使用してCloud Memorystore for Redisインスタンスを導入する手順を詳細に解説します。

前提条件

  • GCPアカウントとアクティブなプロジェクト。
  • プロジェクトに対して、Cloud Memorystore APIが有効になっていること。
  • インスタンスを配置するVPC (Virtual Private Cloud) ネットワークが準備されていること。デフォルトネットワークでも可能ですが、本番環境ではカスタムVPCネットワークの利用が推奨されます。
  • Cloud Memorystoreインスタンスを作成および管理するための適切なIAM権限を持つユーザーアカウントまたはサービスアカウント。（例: roles/redis.editor またはより制限されたカスタムロール）
  • Redisインスタンスに接続するためのGCPリソース（Compute Engine VM、GKEノード、Cloud Functionsなど）が、Redisインスタンスと同じVPCネットワーク内、またはVPC Peering等で接続されたネットワーク内に存在すること。

手順 1: GCP Consoleからのインスタンス作成

  1. GCP Consoleにログイン: ウェブブラウザでhttps://console.cloud.google.com/にアクセスし、対象のGCPプロジェクトを選択します。
  2. Cloud Memorystoreへのナビゲーション: 左側のナビゲーションメニューを開き、「データベース」セクションの下にある「Memorystore」を選択します。初めて利用する場合は、APIを有効にする必要があるかもしれません。「Redis」を選択します。
  3. インスタンス作成の開始: 「インスタンスを作成」ボタンをクリックします。
  4. インスタンスの設定: 設定画面が表示されます。以下の項目を入力・選択します。
    • インスタンスID: インスタンスを一意に識別するための名前を入力します。例: my-redis-instance
    • ティア: 「Standard Tier」または「Basic Tier」を選択します。本番環境であれば通常「Standard Tier」を選択します。
    • Redis バージョン: 利用したいRedisのバージョンを選択します。特別な理由がなければ、最新の安定版を選択します。
    • 容量: メモリ容量をGB単位で指定します。アプリケーションのデータサイズやアクセスパターンに基づいて決定します。後からスケールアップも可能です。
    • リージョン: インスタンスをデプロイするGCPリージョンを選択します。アプリケーションがデプロイされているリージョンと同じリージョンを選択することで、ネットワーク遅延を最小限に抑えられます。
    • ゾーン (Standard Tierのみ): Standard Tierの場合、プライマリノードとレプリカノードを配置するゾーンを指定します。自動的にゾーンを選択させることも可能です（推奨）。
    • ネットワーク: Redisインスタンスを接続するVPCネットワークを選択します。インスタンスに接続するGCPリソースが配置されているネットワークと同じネットワークを選択する必要があります。
    • 予約済みIPアドレス範囲 (任意): Redisインスタンスに割り当てるプライベートIPアドレスの範囲を指定できます。指定しない場合は、GCPが自動的に割り当てます。
    • AuthConfig (任意): Redis AUTH認証を有効にするかどうかを選択できます。有効にする場合は、パスワードを設定します。本番環境では有効にすることを強く推奨します。
    • 高度な設定:
      • メモリ割り当てポリシー (Eviction Policy): メモリが満杯になった場合の挙動を指定します。キャッシュとして利用する場合は、allkeys-lru（最も使われていないキーを削除）などが一般的です。
      • 最大メモリ比率 (Maxmemory ratio): メモリ割り当てポリシーが発動するしきい値を設定します。
      • Redis 구성 플래그 (Redis構成フラグ): 一部のRedis設定をカスタマイズできますが、通常はデフォルトで十分です。
      • メンテナンスウィンドウ: システムメンテナンスが行われる時間帯を指定できます。
      • レプリカ読み取り (Standard Tierのみ): レプリカノードを読み込みリクエストの処理に利用するかどうかを設定できます。読み込み負荷が高い場合は有効にするとスループットが向上します。
      • ポイントインタイムリカバリ (PITR): PITRを有効にするかどうかを設定できます。有効にすると、特定の時点への復旧が可能になります。
  5. インスタンス作成: 設定内容を確認し、「作成」ボタンをクリックします。
  6. 作成完了待ち: インスタンスの作成には数分から数十分かかる場合があります。インスタンスリストに表示され、「ステータス」が「アクティブ」になれば作成完了です。
  7. 接続情報の確認: 作成されたインスタンスの詳細画面で、インスタンスのプライベートIPアドレスを確認します。このIPアドレスを使ってアプリケーションから接続します。

手順 2: gcloud CLIからのインスタンス作成

gcloud CLIを使用すると、コマンドラインやスクリプトからインスタンスを作成・管理できます。

  1. gcloud CLIのインストールと設定: ローカルマシンまたはCloud Shellにgcloud CLIをインストールし、対象のGCPプロジェクトを設定します。

  2. インスタンス作成コマンドの実行: 以下のコマンドを実行します。<PROJECT_ID>, <INSTANCE_ID>, <REGION>, <TIER>, <SIZE_GB>, <REDIS_VERSION>, <NETWORK_NAME> は適切な値に置き換えてください。

    bash
    gcloud memorystore redis instances create <INSTANCE_ID> \
    --project=<PROJECT_ID> \
    --region=<REGION> \
    --tier=<TIER> \
    --size=<SIZE_GB> \
    --redis-version=<REDIS_VERSION> \
    --network=<NETWORK_NAME> \
    --reserved-ip-range=<IP_RANGE_NAME_OR_CIDR> \
    --display-name="My Application Redis Cache" \
    --labels="env=production,app=my-app" \
    # Standard Tier の場合、ゾーン指定 (任意)
    # --zone=us-central1-a \
    # Redis AUTH を有効にする場合
    # --enable-auth \
    # メモリ割り当てポリシーを指定する場合
    # --memory-size-gb=<SIZE_GB> --maxmemory-policy=<POLICY> \
    # PITR を有効にする場合
    # --enable-persistence \
    # --rdb-snapshot-period=1h --rdb-snapshot-start-time=00:00

    • --project: 対象のGCPプロジェクトID。
    • --region: インスタンスを作成するリージョン。
    • --instance-id: インスタンスID。
    • --tier: BASIC または STANDARD を指定。
    • --size: メモリ容量をGB単位で指定。
    • --redis-version: 利用するRedisのバージョン（例: REDIS_6_0).
    • --network: インスタンスを接続するVPCネットワークの名前。
    • --reserved-ip-range (任意): 使用するIPアドレス範囲。CIDR表記 (例: 10.0.0.0/29) または事前に予約したIPアドレス範囲の名前。
    • --enable-auth (任意): Redis AUTH認証を有効にするフラグ。有効にすると、インスタンス作成後にパスワードを確認する必要があります。
    • --maxmemory-policy (任意): メモリ割り当てポリシーを指定。例: allkeys-lru
    • --enable-persistence (任意): PITRなどの永続化機能を有効にするフラグ。
    • その他のオプションは gcloud memorystore redis instances create --help で確認できます。

  3. 作成完了待ち: コマンド実行後、インスタンスの作成が開始されます。ステータスが READY になるまで待ちます。ステータスは gcloud memorystore redis instances list --region=<REGION> コマンドで確認できます。

  4. 接続情報の確認: 作成されたインスタンスのプライベートIPアドレスは、gcloud memorystore redis instances describe <INSTANCE_ID> --region=<REGION> コマンドの出力で確認できます。host フィールドに表示されます。Redis AUTHを有効にした場合は、gcloud memorystore redis instances get-auth-string <INSTANCE_ID> --region=<REGION> コマンドで認証文字列（パスワード）を取得できます。

手順 3: クライアントからの接続

Redisインスタンスが作成されたら、同じVPCネットワーク内のGCPリソースから接続します。

  1. 接続元の準備: Cloud Memorystoreインスタンスと同じVPCネットワークに接続されているCompute Engine VM、GKE Pod、または他のGCPサービス（例: App Engine Flexible, Cloud Functions – VPC Connector経由）を準備します。
  2. Redisクライアントのインストール: 接続元となるGCPリソース（例: VM）に、利用する言語のRedisクライアントライブラリをインストールします。また、テスト用にredis-cliをインストールしておくと便利です。
    • Linux (Debian/Ubuntu): sudo apt update && sudo apt install redis-tools
    • Linux (RHEL/CentOS): sudo yum install redis (redis-cliが含まれる)

  3. 接続テスト (redis-cliを使用): 接続元VMから、以下のコマンドでRedisインスタンスに接続できるか確認します。<REDIS_IP_ADDRESS> はCloud MemorystoreインスタンスのプライベートIPアドレスに置き換えます。

    bash
    redis-cli -h <REDIS_IP_ADDRESS> -p 6379

    • Redis AUTHを有効にしている場合は、パスワードが必要です。
      bash
      redis-cli -h <REDIS_IP_ADDRESS> -p 6379 -a <REDIS_AUTH_PASSWORD>
      または、redis-cli に接続後、AUTH <REDIS_AUTH_PASSWORD> コマンドを実行します。

    • 接続に成功すると、プロンプトが REDIS_IP_ADDRESS:6379> のようになります。

    • 以下のコマンドをいくつか実行して、動作を確認します。
      redis
      PING
      SET mykey "hello world"
      GET mykey
      INFO
      QUIT

  4. アプリケーションからの接続: アプリケーションコードで、利用する言語のRedisクライアントライブラリを使用し、Cloud MemorystoreインスタンスのプライベートIPアドレス（および有効にしている場合はAUTHパスワード）を指定して接続します。

    例: Python (redis-py ライブラリを使用)
    “`python
    import redis

    Redis AUTH を有効にしている場合

    r = redis.Redis(host=’‘, port=6379, password=’‘)

    Redis AUTH を有効にしていない場合

    r = redis.Redis(host=’‘, port=6379)

    try:
    r.ping()
    print(“Connected to Redis!”)
    r.set(‘mykey’, ‘hello from python’)
    value = r.get(‘mykey’)
    print(f”Value: {value}”)
    except redis.exceptions.ConnectionError as e:
    print(f”Could not connect to Redis: {e}”)
    “`

    アプリケーションのデプロイ先（GKE, Cloud Functionsなど）に応じて、接続文字列や認証情報の管理方法（Secret Managerなど）を適切に検討してください。

これでCloud Memorystore for Redisインスタンスの導入は完了です。アプリケーションの要件に合わせて、適切なティア、容量、セキュリティ設定を選択し、運用管理を進めていきます。

運用と管理

Cloud Memorystoreはフルマネージドサービスですが、利用者が行うべき運用・管理タスクもいくつか存在します。

モニタリング

インスタンスのパフォーマンスと健全性を把握するために、Cloud Monitoringを活用します。

  • ダッシュボード: GCP ConsoleのCloud Memorystore詳細画面には、主要なモニタリングメトリクスが表示されます。より詳細なモニタリングには、Cloud Monitoringのカスタムダッシュボードを作成し、以下の主要メトリクスを追加することを推奨します。
    • redis.googleapis.com/stats/cpu/usage_ratio: CPU使用率。継続的に高い場合は、インスタンス容量不足や高負荷を示す可能性があります。
    • redis.googleapis.com/stats/memory/usage_ratio: メモリ使用率。メモリが限界に近づいている場合は、エビクションポリシーの発動や容量不足を示します。
    • redis.googleapis.com/stats/network/received_bytes_count / sent_bytes_count: ネットワークトラフィック。スループットのボトルネックを特定できます。
    • redis.googleapis.com/stats/clients/connected: 接続クライアント数。接続上限に近づいていないか確認します。
    • redis.googleapis.com/stats/keys/count: 保存されているキーの数。データ量の変化を追跡できます。
    • redis.googleapis.com/stats/commands/processed_count: 処理されたコマンド数。スループットの指標となります。
    • redis.googleapis.com/stats/commands/error_count: エラーとなったコマンド数。エラー率が高い場合はアプリケーションやRedisの利用方法に問題がある可能性があります。
    • redis.googleapis.com/stats/cache/hit_ratio: キャッシュヒット率（GETコマンドなど）。キャッシュとして利用している場合に重要です。ヒット率が低い場合は、キャッシュ容量が不足しているか、キャッシュ戦略を見直す必要があります。
    • redis.googleapis.com/stats/replication/offset_bytes (Standard Tier): プライマリとレプリカ間のレプリケーション遅延。大きな遅延がある場合は、レプリケーションのボトルネックを示します。
  • アラート: 主要なメトリクス（CPU使用率、メモリ使用率、エラー率、接続数など）に対してアラートポリシーを設定し、閾値を超えた場合に通知が来るように設定します。これにより、問題発生時に早期に対応できます。

スケーリング

アプリケーションのトラフィックやデータ量の変化に応じて、インスタンスの容量をスケールアップ/ダウンできます。

  • 容量の変更: GCP Consoleまたはgcloud CLIから、インスタンスの容量を変更できます。
    bash
    # 例: 容量を 20GB に変更
    gcloud memorystore redis instances update <INSTANCE_ID> \
    --region=<REGION> \
    --size=20
    容量のスケールアップは、通常ダウンタイムなしで実行されます（Standard Tier）。スケールダウンは、データ量が新しい容量以下である必要があります。容量変更には時間がかかる場合があります。
  • レプリカ数の変更 (Standard Tier): Standard Tierでは、読み込み負荷に応じてレプリカ数を増やすことで読み込みスループットをスケールアウトできます。
    bash
    # 例: レプリカ数を 2 に変更
    gcloud memorystore redis instances update <INSTANCE_ID> \
    --region=<REGION> \
    --replica-count=2

バックアップとリストア

データ損失のリスクを最小限に抑えるために、スナップショット機能を利用します。

  • スナップショットの有効化と設定: インスタンス作成時または作成後に、PITRやRDBスナップショットを有効にし、取得頻度や時間を設定します。
    “`bash
    # PITR 有効化 (保存期間 7 日)
    gcloud memorystore redis instances update \
    –region= \
    –enable-persistence \
    –persistence-mode=aof-rdb \
    –aof-storage-bytes=1000000000000 \ # 必要に応じて調整
    –aof-rewrite-ratio=100 \ # 必要に応じて調整
    –aof-rewrite-min-size=67108864 # 必要に応じて調整

    RDB スナップショット設定例 (毎日午前2時、間隔 1時間)

    gcloud memorystore redis instances update \
    –region= \
    –enable-persistence \
    –persistence-mode=rdb \
    –rdb-snapshot-period=1h \
    –rdb-snapshot-start-time=02:00 # HH:MM 形式
    * `--persistence-mode`: `rdb` (RDBのみ), `aof-rdb` (AOFとRDBの組み合わせ).
    * `--rdb-snapshot-period`: RDBスナップショットの間隔。`1h`, `6h`, `12h`, `24h` など。
    * `--rdb-snapshot-start-time`: RDBスナップショットを開始する時間 (UTC)。
    * **スナップショットからのリストア:** GCP Consoleまたはgcloud CLIから、既存のスナップショットを選択して新しいRedisインスタンスを作成したり、既存のインスタンスにデータをロードしたりできます。リストアは、基本的に新しいインスタンスとして作成するのが一般的な方法です。    bash

    特定のスナップショットから新しいインスタンスを作成

    gcloud memorystore redis instances create \
    –region= \
    –source-instance= \
    –source-backup= \
    # その他の設定（ティア、容量、ネットワークなど）
    PITRの場合は、特定の時点を指定してリストアします。bash

    特定の時点に新しいインスタンスを作成 (PITR有効な場合)

    gcloud memorystore redis instances create \
    –region= \
    –source-instance= \
    –point-in-time= \ # RFC3339 形式のタイムスタンプ
    # その他の設定
    “`
    リストアプロセスには時間がかかる場合があります。

パッチ適用とメンテナンス

Cloud Memorystoreはマネージドサービスのため、OSやRedisソフトウェアのパッチ適用はGCPが自動で行います。これにより、常に最新のセキュリティ対策が適用された状態を維持できます。

  • メンテナンスウィンドウ: 本番環境では、メンテナンス作業（パッチ適用やバージョンアップグレードなど）が行われる時間帯を、ビジネスへの影響が少ない時間帯に指定できます。インスタンス作成時または後から設定変更が可能です。指定した時間帯の中で、GCPが最適なタイミングでメンテナンスを実行します。

セキュリティ管理

  • IAM: GCP IAMを使用して、Redisインスタンスに対するアクセス権限を適切に管理します。プロジェクトレベル、フォルダレベル、インスタンスレベルで権限を付与できます。最小権限の原則に従い、必要最低限の権限のみを付与するようにします。
  • Redis AUTH: インスタンス作成時または後からRedis AUTHを有効にし、パスワード認証を必須に設定します。これにより、不正なアクセスを防ぎます。パスワードは定期的にローテーションすることを検討します。
  • VPC Service Controls: より高度なセキュリティ要件がある場合、VPC Service Controlsを利用して、サービス境界を定義し、承認されていないネットワークからのデータアクセスを制限できます。

トラブルシューティング

Cloud Memorystoreを利用する上で遭遇しうる一般的な問題と、その原因・対策について解説します。

1. クライアントから接続できない

  • 原因:
    • ネットワーク設定の誤り: クライアント（VM, GKE Podなど）が、Redisインスタンスと同じVPCネットワークに接続されていない。
    • ファイアウォールルールの不備: クライアントからRedisインスタンスのIPアドレスおよびポート（デフォルト 6379）へのTCPトラフィックを許可するファイアウォールルールが設定されていない。
    • IPアドレスの誤り: 接続しようとしているIPアドレスが、RedisインスタンスのプライベートIPアドレスと異なっている。
    • Redis AUTH の有効化とパスワードの誤り: Redis AUTHが有効になっているにも関わらず、認証情報なしで接続しようとしている、または誤ったパスワードを使用している。
    • インスタンスのステータス: インスタンスが「アクティブ」状態ではない（まだ作成中、エラー状態など）。
  • 対策:
    • クライアントとRedisインスタンスが同じVPCネットワーク（またはVPC Peering等で接続されたネットワーク）に存在することを確認します。
    • クライアントのサブネットからRedisインスタンスのIPアドレスへのTCP 6379ポートを許可するVPCファイアウォールルールを追加します。
    • GCP Consoleまたはgcloud CLIでインスタンスの詳細を確認し、正しいプライベートIPアドレスを使用しているか確認します。
    • Redis AUTHが有効になっている場合は、redis-cli -a <PASSWORD> やアプリケーションコードで正しいパスワードを指定して接続します。パスワードはgcloud memorystore redis instances get-auth-stringコマンドで確認できます。
    • GCP Consoleでインスタンスのステータスを確認し、アクティブになるまで待ちます。

2. パフォーマンスが遅い/レイテンシが高い/スループットが低い

  • 原因:
    • CPU使用率が高い: インスタンスが処理能力の限界に達している可能性があります。
    • メモリ使用率が高い: メモリが一杯で、エビクション（キー削除）が頻繁に発生している可能性があります。
    • ネットワーク帯域の限界: ネットワークI/Oがボトルネックになっている可能性があります。
    • 大規模なキー/データ構造: 大きなハッシュ、リスト、セットなどを操作している場合、処理に時間がかかることがあります。
    • 効率の悪いRedisコマンドの使用: KEYS, FLUSHALL, FLUSHDB, GETALL, LRANGE (巨大な範囲) など、全体スキャンや大量データ転送を伴うコマンドを頻繁に使用している。
    • レプリケーション遅延 (Standard Tier): プライマリノードとレプリカノード間のデータ同期に遅延が発生している。
    • クライアント側の問題: クライアントアプリケーションの実装（コネクションプール、直列処理など）に問題がある。
  • 対策:
    • Cloud MonitoringでCPU使用率、メモリ使用率、ネットワークトラフィックを確認します。これらのメトリクスが継続的に高い場合は、インスタンスの容量をスケールアップすることを検討します。
    • メモリ使用率が高い場合は、より大きな容量にスケールアップするか、エビクションポリシーを適切に設定し、不要なデータを削除するようにします。
    • アプリケーションがRedisをどのように利用しているかプロファイリングし、効率の悪いコマンドの使用を避けるか、より効率的なデータ構造やパターン（例: Pipeline, Luaスクリプト）に置き換えることを検討します。
    • Standard Tierで読み込み負荷が高い場合は、レプリカ読み込みを有効にするか、レプリカ数を増やすことを検討します。
    • クライアント側の実装を見直し、コネクションプールを利用する、非同期処理を導入するなど、効率的なRedisクライアント利用を検討します。
    • 長時間のRedisコマンド（Slowlogで確認可能）を特定し、その使用頻度や効率を改善します。

3. メモリ不足エラー (OOM – Out Of Memory)

  • 原因:
    • 保存されているデータ量がインスタンスのプロビジョニングされた容量を超えている。
    • エビクションポリシーが適切に設定されていないか、有効になっていない。
    • 過剰なコネクション数によるオーバーヘッド。
  • 対策:
    • Cloud Monitoringでメモリ使用率を確認し、現在のデータ量とプロビジョニング容量を比較します。
    • インスタンス容量をスケールアップします。
    • キャッシュとして利用している場合は、メモリが満杯になった際に自動的にキーを削除するエビクションポリシー（例: allkeys-lru, volatile-lru）を有効にします。
    • 不要なキーを削除するか、キーの有効期限（TTL）を適切に設定します。
    • 接続クライアント数が過剰でないか確認し、必要に応じてクライアント側のコネクションプールの設定を見直します。

4. インスタンスが応答しない/エラー状態になる

  • 原因:
    • GCP側のインフラ障害（まれ）。
    • インスタンス自体に深刻な問題が発生している。
    • （Basic Tier）シングルノード障害。
  • 対策:
    • GCP Status Dashboardで、利用しているリージョンのCloud Memorystoreサービスに障害が発生していないか確認します。
    • GCP Consoleでインスタンスのステータスとエラーメッセージを確認します。詳細な情報が提供されている場合があります。
    • Cloud Loggingでインスタンスに関連するログを確認し、エラーや警告がないか調査します。
    • （Basic Tierの場合）シングルノード障害はデータ損失を伴う可能性があります。インスタンスを再起動または再作成する必要があるかもしれません。
    • （Standard Tierの場合）自動フェイルオーバーが発生しているか確認します。フェイルオーバーが完了するまで待ちます。
    • 問題が解決しない場合は、GCPサポートに連絡し、診断と支援を依頼します。

これらのトラブルシューティングのステップは、Cloud Memorystoreを安定して運用するために不可欠です。モニタリングを継続的に行い、問題の兆候を早期に発見することが重要です。

Advanced Topics

Cloud Memorystore for Redisをさらに深く活用するための高度なトピックをいくつか紹介します。

Redis Pub/Sub の利用

Cloud MemorystoreはオープンソースRedisのPub/Sub機能をサポートしています。これは、発行/購読型のメッセージングパターンを実装するために利用できます。

  • アプリケーションの一方が特定の「チャンネル」にメッセージを発行 (PUBLISH) し、別のアアプリケーションがそのチャンネルを購読 (SUBSCRIBE) することで、非同期なメッセージ通信を実現できます。
  • マイクロサービス間でのイベント通知や、リアルタイムデータ配信などに活用できます。
  • Cloud Memorystoreはチャンネル数やメッセージサイズに制限がありますが、軽量なPub/Subとして非常に高速に機能します。

Redis Modules のサポート状況

オープンソースRedisには様々な機能拡張を行うためのRedis Modulesがありますが、Cloud Memorystoreでは全てのRedis Modulesをサポートしているわけではありません。GCPが提供するCloud Memorystoreは、互換性と安定性を維持するために、特定のバージョンのオープンソースRedisを基盤としており、Modulesのサポートは限定的です。利用したい特定のModuleがある場合は、公式ドキュメントでサポート状況を確認する必要があります。

GKE や Cloud Functions からの接続

  • GKE: Google Kubernetes Engine (GKE) のPodからCloud Memorystoreに接続する場合、GKEクラスターがCloud Memorystoreインスタンスと同じVPCネットワーク、またはVPCネイティブ（エイリアスIP）構成で接続されたネットワークに配置されている必要があります。PodはPod IPからRedisインスタンスのプライベートIPにアクセスします。ファイアウォールルールでPodのIPレンジからのアクセスを許可する必要がある場合があります。
  • Cloud Functions: Cloud FunctionsからCloud MemorystoreのようなVPC内のプライベートIPリソースにアクセスするには、VPCコネクタ (VPC Connector) を使用する必要があります。Cloud FunctionsをVPCコネクタに接続し、そのVPCコネクタがRedisインスタンスと同じVPCネットワークに接続されている構成をとります。これにより、Cloud FunctionsはVPCネットワーク内のIPアドレスからRedisにアクセスできるようになります。

VPC Peering や Shared VPC 環境での利用

  • VPC Peering: 異なるVPCネットワーク間でRedisインスタンスを共有したい場合、VPC Peeringを利用してネットワーク間を接続できます。ただし、Peering接続されたネットワークからのアクセスには、ファイアウォールルールの設定が必要です。
  • Shared VPC: Shared VPC (XPN) 環境では、ホストプロジェクトでCloud Memorystoreインスタンスを作成し、サービスプロジェクトのVMやGKEクラスターからアクセスすることが可能です。この構成は、大規模な組織でネットワークを一元管理する場合に有効です。サービスプロジェクトのリソースは、ホストプロジェクトのVPCネットワーク経由でRedisに接続します。

コスト最適化の詳細

  • 適切なティアと容量の選択: 前述の通り、ワークロードに最適なティアと容量を選択することが最も重要なコスト最適化です。
  • エビクションポリシー: キャッシュ目的の場合は、allkeys-lruなどのエビクションポリシーを必ず設定し、メモリ使用率を管理します。これにより、不必要に容量を増やすことを避けられます。
  • モニタリングに基づいた調整: CPU、メモリ、ネットワーク使用率を継続的にモニタリングし、リソースが過剰にプロビジョニングされていないか確認します。利用率が低い場合は、容量をスケールダウンすることを検討します。
  • 不要なインスタンスの削除: 開発/テスト目的で作成したインスタンスなど、利用していないインスタンスは忘れずに削除します。
  • PITR/RDB設定の調整: PITRの保存期間やRDBスナップショットの取得頻度は、データの重要度とコストのバランスを考慮して設定します。取得頻度が高いほど、ストレージコストは増加します。

まとめ

本記事では、GCP Cloud Memorystore for Redisについて、その基本的な概念から、特徴、料金、導入手順、運用管理、そして高度なトピックまで、約5000語の詳細な解説を行いました。

Cloud Memorystore for Redisは、インメモリデータストアとして広く普及しているオープンソースRedisを、GCPのフルマネージドサービスとして提供する強力なサービスです。その最大の利点は、プロビジョニング、パッチ適用、監視、スケーリング、高可用性の維持といった煩雑な運用タスクをGCPが肩代わりしてくれる点にあります。これにより、開発チームはアプリケーション開発とビジネスロジックに集中でき、開発・運用効率を大幅に向上させることができます。

Basic Tierは開発/テスト環境や非ミッションクリティカルな用途向けにコスト効率の良い選択肢を提供し、Standard Tierは自動フェイルオーバーとレプリケーションによる高可用性でミッションクリティカルな本番アプリケーションを支えます。用途に合わせて適切なティアと容量を選択することで、パフォーマンス、可用性、コストの最適なバランスを実現できます。

料金体系は容量とティア、リージョンに基づいてシンプルに設定されており、GCP料金計算ツールで簡単に試算できます。適切な容量選択やエビクションポリシーの活用により、コストを最適化することも可能です。

導入手順はGCP Consoleとgcloud CLIの両方から行うことができ、既存のVPCネットワークとの連携や、必要に応じたセキュリティ設定（Redis AUTH）を行うことで、安全かつ確実にサービスを立ち上げられます。接続元のCompute EngineやGKEなどからは、プライベートIPアドレス経由で高速にアクセスできます。

運用フェーズでは、Cloud Monitoringによる詳細なメトリクス監視とアラート設定、必要に応じた容量スケール、スナップショットによるデータ保護が重要となります。フルマネージドであるため多くの作業は自動化されますが、これらのモニタリングやバックアップ設定はユーザー側で行うべき重要なタスクです。

Redisの豊富なデータ構造とコマンドセットをそのまま利用できる互換性は、既存のRedisワークロードをクラウドに移行する際の障壁を低くします。セッションストア、キャッシュ、リーダーボード、リアルタイム分析など、幅広いユースケースでその高速性と柔軟性を発揮します。

Cloud Memorystore for Redisは、GCP上で高速でスケーラブルなインメモリデータストアを構築・運用するための、非常に強力で信頼性の高い選択肢です。インフラ管理の負担を軽減しつつ、高いパフォーマンスと可用性を必要とするアプリケーションを構築する際に、ぜひ活用を検討してみてください。

付録: 主要なRedisコマンド（抜粋）

Cloud Memorystore for Redisでよく利用される基本的なRedisコマンドの一部を以下に示します。全てのコマンドはRedis公式ドキュメントを参照してください。

  • キー操作:

    • SET key value [EX seconds | PX milliseconds | KEEPTTL] [NX | XX]: キーに値を設定。有効期限や条件付き設定も可能。
    • GET key: キーの値を取得。
    • DEL key [key ...]: キーを削除。
    • EXPIRE key seconds: キーに有効期限（秒）を設定。
    • TTL key: キーの有効期限（秒）を取得。
    • KEYS pattern: パターンに一致するキーを検索（注意: 本番環境での頻繁な使用は避けること。パフォーマンスに影響）。代わりに SCAN コマンドを使用することを推奨。
    • EXISTS key [key ...]: キーが存在するか確認。
    • RENAME key newkey: キー名を変更。
    • TYPE key: キーに保存されているデータ型を取得。

  • 文字列 (Strings):

    • INCR key: キーの値をインクリメント（数値の場合）。
    • DECR key: キーの値をデクリメント（数値の場合）。
    • APPEND key value: キーの値の末尾に文字列を追加。

  • ハッシュ (Hashes):

    • HSET key field value [field value ...]: ハッシュのフィールドに値を設定。
    • HGET key field: ハッシュのフィールドの値を取得。
    • HGETALL key: ハッシュの全てのフィールドと値を取得。
    • HDEL key field [field ...]: ハッシュのフィールドを削除。
    • HMGET key field [field ...]: ハッシュの複数のフィールドの値を取得。

  • リスト (Lists):

    • LPUSH key element [element ...]: リストの先頭に要素を追加。
    • RPUSH key element [element ...]: リストの末尾に要素を追加。
    • LPOP key [count]: リストの先頭から要素を取り出し、削除。
    • RPOP key [count]: リストの末尾から要素を取り出し、削除。
    • LRANGE key start stop: リストの指定範囲の要素を取得。

  • セット (Sets):

    • SADD key member [member ...]: セットにメンバーを追加。
    • SMEMBERS key: セットの全てのメンバーを取得。
    • SREM key member [member ...]: セットからメンバーを削除。
    • SISMEMBER key member: メンバーがセットに含まれているか確認。

  • ソート済みセット (Sorted Sets):

    • ZADD key [NX|XX|CH|INCR] score member [score member ...]: ソート済みセットにメンバーとスコアを追加/更新。
    • ZRANGE key start stop [WITHSCORES]: スコア順で指定範囲のメンバーを取得。
    • ZREM key member [member ...]: ソート済みセットからメンバーを削除。
    • ZSCORE key member: ソート済みセットのメンバーのスコアを取得。

  • Pub/Sub:

    • PUBLISH channel message: 指定したチャンネルにメッセージを発行。
    • SUBSCRIBE channel [channel ...]: 指定したチャンネルを購読。

これらのコマンドは、Cloud Memorystore for Redisでもそのまま利用できます（一部管理コマンドなどを除く）。アプリケーションの要件に応じて、適切なデータ構造とコマンドを選択してRedisを活用してください。

本記事が、GCP Cloud Memorystore for Redisの理解を深め、導入・運用の一助となれば幸いです。常にGCPの公式ドキュメントで最新の情報や変更点を確認することをお勧めします。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール