OCI Cache (Redis)

解決する課題

• 同じ問い合わせがデータベースに繰り返し届き、DB が過負荷になる
• ページ表示や API 応答のレイテンシを下げたいが、DB 直アクセスでは遅い
• セッション情報やトークンなど揮発的で高頻度のデータを高速に出し入れしたい
• Redis を使いたいが、ノードの構築・パッチ・フェイルオーバー運用を自分でやりたくない

主要概念と用語

• インメモリキャッシュ: データをメモリ上に保持し、サブミリ秒で読み書きする仕組み。ディスク中心の DB より桁違いに速い
• Redis 互換: 広く使われる Redis のコマンド・データ構造（文字列、ハッシュ、リスト、セット、ソート済みセットなど）に対応し、既存クライアントから利用できる
• クラスタ（Cache Cluster）: OCI Cache が管理する単位。1 つ以上のノードで構成される
• プライマリ / レプリカ: 書き込みを受けるプライマリノードと、その内容を複製する読み取り用レプリカ。プライマリ障害時はレプリカへ自動フェイルオーバーする
• シャーディング（シャード）: データを複数ノードに分割して水平スケールする方式。容量とスループットを伸ばせる
• TTL（有効期限）: キーごとに失効時間を設定し、古いデータを自動的に消す仕組み
• エビクション（Eviction）ポリシー: メモリが上限に達したときにどのキーを退避させるかの方針（最近使われていないものを優先するなど）
• エンドポイント: アプリが接続する接続先。プライマリ用と読み取り用が提供される
• コンパートメント: リソースを論理分離する OCI の枠組み（IAM の単位）

仕様・制限・クォータ

• データはメモリに保持され、サブミリ秒級の応答を狙えるため、キャッシュやセッションストアに向く
• クラスタはプライマリ＋レプリカ構成にでき、可用性ドメインをまたいで配置することで単一障害点を避けられる
• 大容量・高スループットが必要な場合はシャーディングでデータを分割し水平にスケールする
• 接続は TLS で暗号化でき、VCN 内のプライベートな接続で利用するのが基本
• ノードあたりのメモリ量や1テナンシあたりのクラスタ数などに**サービス上限（クォータ）**があり、必要に応じて引き上げ申請ができる
• メモリは有限のため、上限到達時はエビクションまたは書き込み拒否となる。容量設計と TTL 設計が前提となる

内部の仕組み

OCI Cache はプライマリノードが書き込みを受け付け、その内容をレプリカへ複製します。プライマリに障害が起きると、サービスがレプリカを新しいプライマリへ**自動昇格（フェイルオーバー）**し、接続先のエンドポイントを切り替えます。アプリ側はエンドポイント経由で接続するため、ノードの入れ替えを基本的に意識せずに済みます。

• 読み取りは読み取り用エンドポイント経由でレプリカに振り分けられ、プライマリの負荷を分散できる
• シャーディング構成では、キーがハッシュで各シャードに割り当てられ、ノードを増やすほど容量とスループットが伸びる
• メモリ上限に達すると、設定したエビクションポリシーに従ってキーが退避される。アクセス頻度の低いキーや TTL の近いキーから消えるのが一般的
• パッチ適用やノード復旧はサービス側が透過的に処理する

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

• Cache-Aside（Lazy Loading）: 参照時にキャッシュ→無ければ DB→キャッシュへ書き戻し。最も汎用的
• Write-Through: 書き込み時にキャッシュと DB を同時更新。読み取り時のミスを減らせるが書き込みが増える
• すべてのキーに TTL を付け、古いデータの滞留とメモリ枯渇を防ぐ
• キー命名規則を統一（例: user:123:profile）し、衝突や名前の取り違えを避ける
• セッションやトークンなど揮発的で高頻度のデータをキャッシュに寄せ、DB の読み取りを削る
• 単一キーへのアクセス集中（ホットキー）を避け、必要なら値を分割・複製して分散する
• 重要なワークロードはレプリカ付き構成にし、可用性ドメインをまたいで耐障害性を確保する

運用・監視

• OCI Monitoring のメトリクスで状態を把握する。代表的には、メモリ使用率、CPU 使用率、接続数、ヒット率・ミス率、エビクション数など
• ヒット率の低下はキャッシュ設計の見直しサイン（TTL が短すぎる、キャッシュ対象が適切でない、容量不足など）
• エビクション多発・メモリ高止まりは容量不足のサイン。ノードのスケールアップ／シャード追加を検討する
• クラスタ作成・スケール・更新などの操作は **Work Request（非同期ジョブ）**として実行され、進捗を追跡できる
• フェイルオーバー時に接続が切れうるため、クライアントは再接続とリトライを実装しておく

コスト

課金は基本的に確保したキャッシュ容量（ノードのメモリ／構成）に対する従量です。レプリカやシャードを増やすほどコストは増えます。具体的な単価は変動するため、ここでは考え方を整理します。

セキュリティ

• 通信は TLS で暗号化でき、VCN 内のプライベート接続で利用するのが基本。インターネットに直接公開しない
• **セキュリティリスト / ネットワークセキュリティグループ（NSG）**で、接続元を必要なサブネット・ポートに限定する
• OCI IAM ポリシーで、クラスタの作成・管理権限をコンパートメント単位に最小化する
• 認証情報をアプリにハードコードせず、コンピュートではインスタンスプリンシパル、Functions ではリソースプリンシパルを使って管理操作を行う

Well-Architected の観点

• パフォーマンス効率: 高頻度の読み取りをサブミリ秒のメモリアクセスに肩代わりさせ、DB のレイテンシとスループットの壁を回避する。読み取りレプリカで負荷を分散する
• コスト最適化: ヒット率を高めて小さな容量で効果を出し、DB 側のスケールアップを抑える。TTL とエビクションで無駄なメモリ確保を避ける
• 信頼性（補足）: レプリカと自動フェイルオーバーで可用性を高める一方、キャッシュ消失に耐える設計（正本は DB）を併用する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Redis クラスタを作成（プライマリ + レプリカで可用性を確保するイメージ）
# nodeCount でノード数、サブネット指定でプライベート接続にする
oci redis redis-cluster create \
  --display-name "session-cache" \
  --compartment-id "$COMPARTMENT_OCID" \
  --node-count 2 \
  --node-memory-in-gbs 4 \
  --software-version "REDIS_7_0" \
  --subnet-id "$SUBNET_OCID" \
  --wait-for-state ACTIVE

# 作成したクラスタの一覧と接続エンドポイントを確認
oci redis redis-cluster list \
  --compartment-id "$COMPARTMENT_OCID"

# クラスタ詳細（プライマリ / 読み取り用エンドポイントなどを取得）
oci redis redis-cluster get \
  --redis-cluster-id "$REDIS_CLUSTER_OCID"