Memorystore

解決する課題

データベースへの読み取り集中やミリ秒未満の応答が必要な処理を、自前のキャッシュサーバーを運用せずに解決します。

• バックエンドDBに同じ読み取りが集中して遅い、負荷が高い → 結果をインメモリキャッシュして肩代わりさせたい
• ステートレスなアプリでセッション情報を共有したい → 高速な共有メモリストアに置きたい
• ランキングやカウンタ、レートリミット、ジョブキューなどインメモリ構造が欲しい → Redis のデータ構造を使いたい
• キャッシュサーバーのプロビジョニング・パッチ・フェイルオーバーが重い → 自動化したい

主要概念と用語

• エンジン: Redis（リッチなデータ構造・永続化・レプリケーション対応）と Memcached（シンプルなキーバリュー・水平スケール向き）の2系統を提供
• インスタンス: 稼働しているメモリストア本体。メモリ容量やノード構成を指定して作成する
• ティア（Redis）: Basic（単一ノード・フェイルオーバーなし）と Standard（レプリカを持ちゾーン間で自動フェイルオーバー）の区分。可用性要件で選ぶ
• 読み取りレプリカ: Standard 構成で読み取りをスケールするためのレプリカ
• クラスタ構成: 大規模・高スループット向けに、データをシャーディングして水平スケールする構成
• プライベートサービスアクセス: インスタンスへ VPC 内のプライベートIP で接続する仕組み（インターネット非公開）
• TTL / エビクション: キーごとの有効期限と、メモリ上限到達時にどのキーを退避するかの方針

仕様・制限・クォータ

• 提供エンジンは Redis と Memcached の2種類。用途やデータ構造の必要性で選ぶ
• 接続は基本的に 同一リージョンの VPC 内からプライベートIP 経由。インターネットへ直接公開する使い方は想定されていない
• Redis の Basic ティアはフェイルオーバー非対応で、ノード障害やメンテナンス時に一時的な接続断やデータ消失が起こりうる。可用性が要るなら Standard ティアを選ぶ
• メモリ容量には下限・上限があり、容量変更（スケール）は可能だが瞬時ではない（再構成を伴う場合がある）
• Memcached はノードを増やして水平スケールできるが、永続化やレプリケーションは持たない（揮発性キャッシュ専用）
• インメモリゆえ容量はメモリサイズに制約される。大容量の永続データの正本には向かない

内部の仕組み

• Redis Standard ティア: プライマリノードの書き込みをレプリカへ複製し、別ゾーンにレプリカを配置することでゾーン障害時に自動フェイルオーバーする。フェイルオーバー後も接続エンドポイントは維持される設計
• Redis Basic ティア: 単一ノードで動作し、レプリカを持たない。再起動・メンテナンス・障害でデータが揮発しうるため、失われても再生成できるキャッシュとしてのみ使う
• Memcached: 複数ノードにキーを分散させる。クライアントがハッシュでノードを選ぶ前提で、ノード間の複製は行わない
• 永続化（Redis）: スナップショットなどによりデータを保持するオプションを設定できるが、メモリストアの基本性格は揮発性キャッシュである点は変わらない

設計パターン / ベストプラクティス

• キャッシュアサイド（Lazy Loading）: アプリがまずキャッシュを引き、ミスならDBから読んでキャッシュに書き戻す。最も一般的なキャッシュパターン
• TTL を必ず設定: キーに有効期限を付け、古いデータの滞留とメモリ枯渇を防ぐ。更新時はキャッシュを無効化する
• 可用性要件に応じてティア選択: 落ちると困る用途は Redis Standard、純粋な使い捨てキャッシュなら Basic でコストを抑える
• 大規模・高スループットは クラスタ構成でシャーディングし、単一ノードの上限を超えてスケールする
• エンジン選択: ランキング・キュー・レートリミットなどデータ構造が要るなら Redis、単純なキーバリューを大量に並列キャッシュするだけなら Memcached

運用・監視

• Cloud Monitoring でメモリ使用率・エビクション数・キャッシュヒット率・接続数・CPU・レプリケーション遅延を可視化する
• メモリ使用率とエビクション数は重要指標。エビクションが多発していれば容量不足かTTL設計の見直しが必要
• キャッシュヒット率が低いと効果が出ていない。キー設計やTTL、対象データを再検討する
• メンテナンスはメンテナンスウィンドウで時間帯を制御。Basic ティアではメンテナンス時に接続断が起こりうる点を運用に織り込む

コスト

課金は主に 確保したメモリ容量（GB単位）とノード構成、リージョン に応じた積み上げです。CPUを個別課金するというより、容量とティアで決まります。

キャッシュは過剰に大きくしがちです。ヒット率とエビクション数を見ながら、効いている範囲で最小の容量に保つのがコスト最適化の基本です。

セキュリティ

• ネットワークは プライベートサービスアクセスで VPC 内のプライベートIP に閉じるのが基本。インターネットへは公開しない
• 接続の TLS による暗号化、および Redis の AUTH（認証） を有効化し、無認証アクセスを防ぐ
• 保存時暗号化はデフォルトで有効。要件に応じて CMEK（Cloud KMS の顧客管理鍵） を利用できる
• IAM でインスタンスの作成・管理権限を最小化し、アプリには接続に必要な範囲のみ付与する

Well-Architected の観点

• パフォーマンス効率: DBの前段にインメモリキャッシュを置くことで、読み取りレイテンシを大幅に下げ、バックエンドの負荷を逃がせる。ヒット率を高く保つキー設計が肝
• コスト最適化: TTLとエビクションで容量を適正化し、可用性が不要な用途は Basic ティアで安く運用する。キャッシュで上流DBのスケールアップを回避できればトータルコストも下げられる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Standard ティア（自動フェイルオーバー）の Redis インスタンスを作成
gcloud redis instances create app-cache \
  --size=5 \
  --region=asia-northeast1 \
  --tier=standard \
  --redis-version=redis_7_0 \
  --network=projects/PROJECT_ID/global/networks/default \
  --connect-mode=private-service-access

# 接続先（ホストIPとポート）を確認
gcloud redis instances describe app-cache \
  --region=asia-northeast1 \
  --format="value(host,port)"

# メモリ容量をスケール（例: 5GB から 10GB へ）
gcloud redis instances update app-cache \
  --region=asia-northeast1 \
  --size=10