OCI Cache実践Vol1｜ElastiCache対比とValkey移行の勘所

1. この記事について — なぜOCI Cacheか

OCIには、インメモリキャッシュを提供するマネージドサービスとして「OCI Cache」があります。AWSでいえばAmazon ElastiCacheに相当するサービスですが、名前も課金モデルもElastiCacheとは大きく異なります。さらにこのサービスは、2023年10月のGA当初「Cache with Redis」という名前で提供されており、2024年6月10日に「OCI Cache」へ改称された経緯を持ちます。この改称は、Redis Inc.が2024年3月にRedisのライセンスをBSD系オープンソースライセンスから、より制限の強いソースアベイラブルライセンスへ変更したことを受けて、オープンソースコミュニティが分岐版として立ち上げた「Valkey」を、OCIがマネージドサービスのエンジンとして採用していった業界の流れと軌を一にしています。

本記事は、「OCI Cache実践」シリーズの第1弾として、ElastiCacheでの実務経験を持つ読者を主な対象に、OCI Cacheの料金体系・エンジン選定・クラスター作成・接続確認までを一気通貫で扱います。

OCI Cacheという名前だけを見ると、単なる「OCI版ElastiCache」のように映るかもしれません。しかし実際に料金体系を確認すると、ElastiCacheのようにインスタンスタイプ(ノードタイプ)を選ぶ課金モデルではなく、確保したメモリ量に対して時間課金するという、まったく異なる発想で設計されていることが分かります。この違いを理解せずに「ElastiCacheと同じようなものだろう」という感覚で試算すると、思わぬ見積もり誤差につながりかねません。本記事は、この料金モデルの違いを出発点に、エンジン選定・クラスター作成・接続確認までを、ElastiCache実務者の目線で整理します。

1-1. 本記事のゴール

本記事は、OCI Cacheを単体の機能紹介として説明するのではなく、ElastiCache実務者が「自分の知っている課金モデル・運用感覚とどう違うのか」を軸に整理することをゴールにしています。読み終えた時点で、次の状態になっていることを目指します。

• OCI Cacheの課金がメモリGB時間の単一次元課金であり、ノード単位でLow Memory/High Memoryの2段階単価が適用される仕組みを理解し、ElastiCacheのノードタイプ課金との違いを説明できる
• Valkey 8.1・Valkey 7.2・Redis 7.0という3つのエンジン選択肢について、公式が推奨する基準とRedis互換性が及ばない領域を把握できる
• 非シャード構成の最小構成(1ノード・2GB)でクラスターを作成し、Compute VM経由でTLS接続してデータ操作を確認できる
• Always Free対象外であることを理解したうえで、検証にかかる料金を事前に見積もり、検証後に削除して課金を止められる

本記事がElastiCacheとの対比にこだわるのは、単に「知っているサービスに寄せて説明した方が分かりやすいから」という理由だけではありません。OCI Cacheのメモリ課金は、ノードタイプという固定された箱にワークロードを合わせる発想ではなく、必要なメモリ量を直接指定する発想に立っています。この設計思想の違いを理解しておくことは、実際に採用を検討する際、コスト試算の精度に直結します。

1-2. 読者像

本記事は、AWSでAmazon ElastiCache(Redis OSS/Valkey)を使った実務経験があり、OCIでの対応サービスを正確に把握したいエンジニアを主な読者として想定しています。マルチクラウド戦略の一環でOCI上にもキャッシュ基盤を持ちたいエンジニア、あるいはOCI案件でセッションストアやアプリケーションキャッシュの設計を任されたインフラ/クラウドエンジニアなどです。

特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCIでElastiCache相当のサービスを使いたいが、料金体系がノードタイプ課金ではないと聞いた。実際どういう課金なのか
• 「Cache with Redis」という古い名前をドキュメントや請求画面で見かけたが、現行の「OCI Cache」と同じサービスなのか
• ValkeyとRedisはどちらを選ぶべきで、公式はどちらを推奨しているのか
• OCI CacheはAlways Free対象なのか、検証だけならいくらかかるのか
• ElastiCacheのCluster Mode Enabled/Disabledに相当する概念は、OCI Cacheにも存在するのか

こうした読者は、多くの場合「AWSで運用しているセッションストアやキャッシュ層を、そのままOCIに置き換えられるか試したい」という動機で本記事にたどり着きます。本記事は、起動手順だけでなく、ElastiCacheとの料金・仕様対比にも重点を置いて解説します。

具体的な典型ユースケースとしては、次のようなケースを想定しています。

• ECサイトやWebアプリのセッションストアを、OCI上でもマネージドサービスとして持ちたい
• アプリケーションキャッシュ(DBクエリ結果のキャッシュ等)を導入し、バックエンドDBの負荷を下げたい
• マルチクラウド構成で、AWS側のElastiCacheとOCI側のキャッシュ層を同じ設計思想で運用したい
• RedisからValkeyへの移行をAWS側ですでに経験しており、OCI側でも同様の移行判断が必要か整理したい
• 将来的にAI/RAG系のセマンティック検索基盤(ベクトル類似検索)をOCI上に構築する前段として、Valkey 8.1の位置づけを把握しておきたい

これらのユースケースに共通するのは、「OCIにもキャッシュサービスがあるはずだが、料金体系や構成範囲がElastiCacheとどう違うのか、公式ドキュメントを読むだけでは整理しづらい」という悩みです。本記事の§2・§3では、この悩みに正面から答えます。

また、AWS側でElastiCache for RedisからElastiCache for Valkeyへの移行をすでに経験している読者にとっては、OCI側でも同じ文脈(Redisライセンス変更→Valkey採用)が進行している点に、既視感を持って読み進められるはずです。エンジンそのものの移行動機は共通していても、課金モデルや構成範囲の細部はサービスごとに異なるため、本記事ではOCI Cache固有の仕様に絞って正確に整理します。

一方で、OCIでのキャッシュ基盤構築が初めてという読者にも配慮し、ノード・シャード・プライベートエンドポイントといった用語は、専門用語として前置きなく使うのではなく、必要な箇所でElastiCacheの対応概念と紐付けながら説明します。OCIのVCN・コンパートメントの基本操作にまだ不慣れな読者は、まず「OCI入門」シリーズから着手することをお勧めします。すでにOCI Cacheの基本操作に慣れており、料金対比とエンジン選定だけを知りたい読者は、§2・§3から読み始めても支障がない構成にしています。

1-3. なぜ今これを書くか

本記事を今書く理由は、大きく2つあります。

1つ目は、Redisのライセンス変更を発端とするValkeyへの移行トレンドです。AWS側ではElastiCache for Valkeyへの移行を扱う記事がすでに多数公開されており、Valkeyという名前自体の検索需要は実在します。一方でOCI側は、2023年10月のGA当初「Cache with Redis」という名前で始まり、2024年6月10日に「OCI Cache」へ改称、そして2025年2月26日にはエンジンとしてValkey 7.2への対応を追加するという経緯を辿っています。この改称・エンジン追加の経緯を正確に整理した日本語記事は、現時点でほぼ見当たりません。

この変遷が示す通り、「OCI Cache」という現行名称は、あくまでValkey採用後に定着した名前であり、サービスそのものは2023年のRedis専用時代から継続して提供されています。次節以降で扱う請求画面のSKU名が、この改称前の「Cache with Redis」のまま表示され続けている点も、あわせて押さえておくべき豆知識です(詳細は§2-1・§6)。

2つ目は、2026年4月9日にGAしたばかりのValkey 8.1という新しい選択肢です。Valkey 8.1では、JSONデータを直接扱えるJSON moduleと、ベクトル類似検索を提供するvalkey-search moduleが追加され、AI/RAG系のセマンティック検索用途にも対応範囲が広がっています。この記事執筆時点でGAから1年に満たない機能であるため、本記事ではdocs本体で確認できた事実の範囲にとどめ、断定を避けながら整理します。

3つ目は、日本語情報の空白です。本記事執筆時点で、OCI Cacheを扱った日本語記事は基礎的な機能紹介にとどまるものが中心で、ElastiCache実務者向けの料金対比・エンジン選定基準・実機ハンズオンまでを体系的にまとめた記事は見当たりません。一方でAWS側では、ElastiCache for Valkeyへの移行を扱う記事がすでに多数公開されており、Valkeyという名前自体への検索需要はすでに存在しています。本記事は、このAWS側の移行トレンドに相乗りする形で、OCI Cache固有の体系的な情報を補うことを狙っています。

本記事は、次の構成で進みます。§2ではOCI Cacheの料金体系とGA履歴を整理します。§3ではエンジン3択の選定基準とRedis互換性の境界を整理します。続く§4では非シャード最小構成でのクラスター作成を扱います。§5では接続とデータ操作、そして削除による課金停止を扱います。§6では、落とし穴チェックリストとしてまとめます。

1-4. 本記事の対象外

本記事は、あくまで「Vol1」として、エンジン選定の基本的な考え方と、非シャード最小構成でのクラスター作成・接続確認までをスコープとしています。次のようなテーマは本記事のスコープ外とし、続編での取り扱いを検討します。

• Valkey 8.1のJSON module・valkey-search moduleを使った実装(JSONスキーマ設計・ベクトルインデックスの構築等)
• シャード構成(3〜99シャード)でのスケールアウト設計と、シャーディングキーの設計方針
• ACL(2025年6月追加)を使った詳細なアクセス制御設計と、カスタム構成パラメータ(16種)のチューニング
• Backup/Restore機能(2026年4月29日追加)を使った運用設計

これらのテーマは、いずれも本記事で扱う最小構成での基本操作が前提となるため、まず本記事でOCI Cacheの料金感覚とエンジン選定の基礎を固めたうえで取り組むことをお勧めします。本記事があえてValkey 8.1の新機能を深掘りしないのは、これらを扱う前に、まずOCI Cacheという基盤そのものの料金感覚と、ElastiCacheとの発想の違いを確実に押さえておくべきだと考えているためです。

なお、本記事はOCI Cacheという単体サービスの実践に焦点を絞っていますが、実際のアプリケーション設計では、Computeのメモリ設計(Flexシェイプでのメモリ割り当て)や、VCNのネットワーク設計と合わせて検討する場面が多くあります。これらの周辺トピックは、既刊の「OCI入門」シリーズや、後述する各記事ですでに扱い済みのため、本記事では該当箇所からのリンクで接続する形にとどめ、重複した説明は避けます。

それでは、次の§2でOCI Cacheの料金体系を正確に押さえたうえで、§3でエンジン選定に進みます。

2. サービス仕様と料金

本章では、OCI Cacheの料金体系とサービス仕様を、公式一次情報に基づいて整理します。OCI CacheはAlways Free対象外のサービスであるため、課金構造を正確に理解しておくことが、検証を安心して進めるための前提になります。

ElastiCache実務者にとって、OCI Cacheの料金体系は「ノードタイプを選ぶ」という発想そのものが存在しない点で、最初はやや戸惑うかもしれません。しかし仕組み自体は単純で、確保するメモリ量と稼働時間の2つの変数だけで料金が決まります。本章を読み終えた時点で、この2変数から自分のワークロードの料金を自力で試算できるようになることを目指します。

2-1. Always Free対象外とメモリGB時間課金

OCI Cacheは、Always Free(永年無料)のリソース一覧には含まれていません。課金は、確保したメモリ容量に対する時間課金という、単一の次元で発生します。ノード数やOCPU数に応じた課金軸は存在せず、確保したメモリの合計GB数と稼働時間だけで料金が決まります。

単価は、1ノードあたりのメモリ量に応じて2段階に分かれています。

この2段階単価はSKU名(B98217 = Low Memory、B99591 = High Memory)としても公式Price List上に登録されています(2026-08-10 cetools取得)。このSKU名にも「Cache with Redis」という2024年6月の改称前の旧称がそのまま残っており、請求明細を確認する際にサービス名の不一致に戸惑わないよう、あらかじめ知っておくとよいポイントです。この点は§6の落とし穴チェックリストでも改めて触れます。

2-2. メモリGB課金の適用単位 — ノードごとに10GB境界を判定

この記事のPhase1確認事項の1つとして、Low Memory/High Memoryの10GB境界が「ノードあたり」なのか「クラスター全体の合計メモリ」なのかを公式ドキュメントで確認しました。結論は、ノードごとに10GB境界を判定する、という仕様です。

たとえば、1ノードあたり15GBのメモリを確保した場合、そのノード単体で見て最初の10GBがLow Memory単価、残り5GBがHigh Memory単価で課金されます。複数ノード構成であっても、この判定はノードごとに独立して行われ、クラスター全体の合計メモリを基準に境界を判定するわけではありません。

2-3. 構成範囲 — 非シャードとシャード

OCI Cacheのクラスターは、非シャード構成とシャード構成の2種類があります。

なお、OCI CacheのクラスターはIPv6のみのサブネットには作成できません。IPv4を含むサブネット(IPv4単独、またはデュアルスタック)を用意する必要があります。

非シャード構成の推奨値が「プライマリ1+レプリカ2」となっているのは、可用性ドメインをまたいだ冗長構成を確保しつつ、読み取り負荷をレプリカに分散できる最小限の構成という位置づけによるものです。本記事のハンズオン(§4)では、検証目的のためレプリカを持たない1ノード構成を採用しますが、実運用ではレプリカを含めた構成を検討することをお勧めします。シャード構成のシャード数が奇数(3〜99)に限定されているのは、シャード間でのデータ分散アルゴリズムの設計上の制約によるものです。

2-4. ElastiCacheとの課金対比

ElastiCacheは、インスタンスタイプ(ノードタイプ)ごとに固定されたvCPU/メモリの組み合わせに対して時間課金する方式です。任意のメモリ量を細かく指定できず、用意されているノードタイプの中から選択する必要があります。これに対しOCI Cacheは、2GB刻みでメモリ量を直接指定でき、指定したメモリ量にそのまま比例して課金されます。

2026年8月10日時点でAWS公式Price List API(ap-northeast-1)から取得したElastiCache for Redisのオンデマンド単価を例に、この違いを確認します。

この対比から分かる通り、ElastiCacheで2GB前後のメモリを確保しようとすると、cache.t4g.small(1.37GiB・$0.049/hr)では不足気味、cache.t4g.medium(3.09GiB・$0.098/hr)では余剰気味という、ノードタイプの粒度に構成を合わせる調整が必要になります。OCI Cacheはメモリ量を直接2GBと指定できるため、必要量に対してより細かくコストを合わせられる設計です。一方で、ElastiCacheのノードタイプにはvCPU数やネットワーク性能といった付帯スペックが紐づいていますが、OCI Cacheのメモリ課金にはそうした付帯スペックの選択軸がない、という違いも押さえておく必要があります。

表の最後に挙げたcache.r7g.large(13.07GiB・$0.263/hr)は、OCI Cacheの構成範囲でいえばHigh Memory階層に踏み込む規模です。仮にOCI Cacheで13GB程度のメモリを1ノードに割り当てた場合、最初の10GBがLow Memory単価($0.0194/GB/hr)、残り3GB程度がHigh Memory単価($0.0136/GB/hr)で計算されるため、単純な単一単価での概算よりもやや低いコストに収まります。この2段階単価の考え方は、次節でもう少し具体的に確認します。

ElastiCache自体の料金にも、Valkeyトレンドを裏付ける事実があります。2026年8月10日時点のAWS公式Price List API(ap-northeast-1)を確認すると、同じノードタイプであっても、エンジンをRedisからValkeyに切り替えるだけで単価が下がると分かります。

いずれのノードタイプでも、Valkeyエンジンの単価はRedisエンジンの約80%に設定されています。ElastiCache側でもValkey採用が価格面で明確に優遇されていることが、AWS側でValkeyへの移行記事が多く公開されている一因と考えられます。OCI Cache側でも、公式がValkey 8.1を新規推奨としている点(§3で扱います)と合わせて、Valkeyという選択肢がAWS・OCI双方でエンジンの主流になりつつある流れが見て取れます。

2-5. High Memory階層の料金イメージ

Low Memory/High Memoryの2段階単価が、実際の請求額にどう影響するかを、もう少し大きなメモリ量の例で確認します。1ノードあたり20GBを確保した場合の時間あたり料金は、次のように計算します。

Low Memory分:  10GB × $0.0194/GB/時間 = $0.194/時間
High Memory分: 10GB × $0.0136/GB/時間 = $0.136/時間
合計: $0.330/時間

もし2段階単価であることを見落とし、20GB全量にLow Memory単価をそのまま乗じてしまうと、$0.388/時間という誤った概算になります。実際の請求額は、10GBを超えた部分にHigh Memory単価が適用される分、これよりも低くなります。複数ノード構成の場合は、この計算をノードごとに独立して行い、合計することで全体の時間あたり料金を求められます。

2-6. 料金試算 — 最小構成でいくらかかるか

§4で行うハンズオンを想定した料金試算です。非シャード構成・1ノード・2GB(Low Memory単価のみ)という最小構成の場合、時間あたりの料金は次の通りです。

2GB × $0.0194/GB/時間 = 約$0.039/時間

2時間ほど検証した場合の概算費用は、次の計算になります。

$0.039/時間 × 2時間 = 約$0.08

この試算は最小構成(2GB・Low Memory単価のみ)を前提としており、10GBを超えるHigh Memory階層は含みません。OCIの新規登録者向けトライアルクレジットの範囲内でも、余裕を持って本記事のハンズオンを完了できる規模です。

参考までに、本記事のスコープ外であるシャード構成を、本番運用に近い規模で試算してみます。3シャード×各シャード2ノード(プライマリ1+レプリカ1)・1ノードあたり8GB(Low Memory階層内)という構成の場合、時間あたりのサービス料は次の計算になります。

ノード数: 3シャード × 2ノード = 6ノード
1ノードあたり: 8GB × $0.0194/GB/時間 = $0.1552/時間
合計: $0.1552/時間 × 6ノード  = 約$0.931/時間

これを1ヶ月(730時間)常時稼働させた場合の概算費用は、約$680です。検証用の最小構成(1ノード・2GB・数時間で数十円規模)と、本番運用を想定したシャード構成(月額数百ドル規模)とでは、コストの桁が大きく異なる点を、構成を決める段階で認識しておくことが重要です。

2-7. GA履歴

OCI Cacheは2023年10月17日に「Cache with Redis」としてGAしました。本記事執筆時点で、公式リリースノートには合計13件の更新が公開されており、そのうち内容が確認できた主要な11件の時系列は次の通りです。

GAから3年に満たない期間でこれだけの機能追加が続いてきたことからも、OCI Cacheは現時点でも活発に開発が続いているサービスだと分かります。特に2025年後半から2026年前半にかけては、Discovery Endpoint・ZPR対応・コンソール刷新・Valkey 8.1・Backup/Restoreと、半年に満たない間隔でアップデートが続いており、開発優先度の高さがうかがえます。

このアップデート頻度は、ElastiCache実務者が「OCI Cacheはまだ機能が少ないのでは」と身構えている場合には、意外に感じられるかもしれません。実際には、シャーディング・ACL・カスタム構成・Backup/Restoreといった、ElastiCacheでも馴染みのある機能が、2023年のGAから3年足らずで一通り揃ってきています。

2-8. 料金情報の一次情報源

本章で示した料金・仕様は、いずれも次の一次情報源を確認したうえで記載しています。

料金・対応バージョンは、クラウドサービスの中でも改定頻度が高い情報です。特にOCI Cacheは、2024年の改称やエンジンの追加が続いた経緯を持つため、本記事に記載した数値は執筆時点で確認した値であり、実際に利用する際はOCIコンソールの費用見積もり画面、または公式ドキュメントの最新情報を確認することをお勧めします。第三者のブログ記事やまとめサイトに記載された料金情報は、取得時期や前提条件の古さゆえに、そのまま引用すると読者に誤った印象を与えるおそれがあります。本記事では、公式ドキュメントおよび公式Price List APIから直接確認できた数値のみを記載する方針を取っています。

続く§3では、Valkey 8.1・Valkey 7.2・Redis 7.0というエンジン3択の選定基準を整理します。

3. エンジン選定とRedis互換性の境界

本章では、OCI Cacheで選択できる3つのエンジン(Valkey 8.1・Valkey 7.2・Redis 7.0)について、公式が推奨する基準とRedis互換性が及ばない領域を整理します。

3-1. エンジン3択比較表

公式ドキュメントは、Valkey 7.2について「メモリ効率・性能・堅牢性が改善されており、最新のセキュリティ修正が適用されている」ことを理由に、Redis 7.0からの移行を推奨しています。ValkeyはRedis OSSとのAPI互換性を維持しているため、既存のRedisアプリケーションをコード変更なしにValkeyへ移行できる、とされています。

3-2. Valkey 8.1の新機能 — JSON moduleとvalkey-search module

2026年4月9日にGAしたValkey 8.1では、2つのモジュールが追加されています。

• JSON module: JSON.SET・JSON.GET・JSON.ARRINSERTなどのコマンドにより、JSONPathを使ってJSONデータを直接格納・操作できます
• valkey-search module: ベクトル類似検索を提供し、RAG(検索拡張生成)やセマンティック検索といったAI駆動アプリケーションでの利用を想定した機能です

両モジュールとも、GAから1年に満たない新しい機能です。個々のコマンド仕様やインデックス設計といった深掘りは、実務での利用が本格化してから改めて扱う方が安全と考え、本記事では機能の存在と用途の紹介にとどめます。

3-3. ACLとカスタム構成

Valkeyエンジンには、2025年6月18日にACL(アクセス制御リスト)機能が追加されています。ユーザーごとにコマンド実行権限やキー空間へのアクセス範囲を制御でき、Redis OSSのACL機能に相当する仕組みです。

また、2025年8月18日には、カスタム構成(パラメータグループ)機能が追加されました。デフォルトの動作から変更できるパラメータが16種類用意されており、ワークロードの特性に応じたチューニングが可能です。

3-4. ElastiCache for Valkey移行者向け対応表

ElastiCache for Valkeyの運用経験がある読者向けに、概念の対応関係を整理します。

コマンド体系はValkey/Redis互換のため大部分がそのまま使えますが、OCI Cache固有の制約として一部のコマンドは利用できません。移行を検討する際は、実際に使用しているコマンドセットが対応範囲に含まれるか、公式ドキュメントの制限事項一覧で個別に確認することをお勧めします。

3-5. Redis 7.0の位置づけ — 非推奨(EOL)ではないが移行推奨

Phase1確認事項として、Redis 7.0の位置づけを公式ドキュメントで確認しました。結論としては、正式な非推奨化(deprecation)やサービス終了(EOL)のアナウンスは確認できていませんが、公式は明確にValkeyベースエンジンへのアップグレードを推奨しています。

クラスターのエンジンがREDIS 7.0の場合、クラスター詳細ページにアップグレードを推奨する警告が表示されます。またアップグレード後は、以前のバージョンへのロールバックができない点にも注意が必要です。本番環境をアップグレードする前には、新バージョンでの動作をあらかじめテストしておくことが推奨されています。

続く§4では、非シャード最小構成でクラスターを実際に作成します。

4. クラスター作成ハンズオン

本章では、§2-6で試算した最小構成(非シャード・1ノード・2GB)を使い、実際にクラスターを作成します。

4-1. 前提 — VCNとプライベートエンドポイント

OCI Cacheのクラスターは、VCN内のプライベートエンドポイント経由でのみアクセスできます。VCN・サブネットの作成がまだの場合は、「OCI入門 Vol3」でVCN・サブネット・セキュリティリストの基礎を扱っていますので、そちらを先に参照してください。

→ OCI入門 Vol3: VCN・サブネット・ゲートウェイ・セキュリティの基礎を読む

§2-3で整理した通り、非シャード構成ではノード数+2のIPアドレスがプライベートエンドポイント用に必要です。本記事の最小構成(1ノード)であれば、3つの空きIPアドレスを持つサブネットを用意しておきます。また、§2-3で触れた通り、OCI CacheはIPv6のみのサブネットには作成できないため、IPv4を含むサブネットを選択してください。

4-2. 作成ダイアログ

OCIコンソールの「データベース」→「OCI Cache」から、新規クラスターを作成します。作成時に指定する主な項目は次の通りです。

作成後、クラスターが利用可能な状態になるまでには一定の待機時間が発生します。ステータスが利用可能になったら、次に接続情報を確認します。

4-3. エンドポイント確認

クラスター詳細ページの「クラスター情報」セクションから、接続に使うプライベートエンドポイントのホスト名とポート番号を確認します。非シャード構成では、プライマリノードへの書き込み用エンドポイントと、レプリカ経由の読み取りエンドポイントが個別に発行されます。この2つのエンドポイントの使い分けは、§5-4で改めて扱います。

続く§5では、Compute VM経由でクラスターに接続し、データを操作します。

5. 接続とデータ操作

本章では、Compute VM(またはBastion経由)からクラスターに接続し、valkey-cli/redis-cliでの基本操作、そして削除による課金停止までを扱います。

5-1. 接続元の準備 — Compute VMまたはBastion経由

OCI Cacheのプライベートエンドポイントは、VCN内、あるいはVCNにルーティングされた経路からのみアクセスできます。踏み台となるCompute VMをクラスターと同じVCN内のパブリック(またはプライベート)サブネットに用意するか、パブリックIPを持たないインスタンスに対してはOCI Bastionサービス経由でセッションを確立します。Bastionサービスのセットアップ手順は、「OCIセキュリティ実践 Vol1」で扱っていますので、そちらを参照してください。

→ OCIセキュリティ実践 Vol1: OCI Bastionを使った踏み台接続を読む

5-2. TLS接続の要件

Phase1確認事項として、TLS(転送中暗号化)の要件を公式ドキュメントで確認しました。結論は、OCI CacheはデフォルトでTLS接続のみをサポートしており、実質的にTLSが必須という仕様です。TLSなしでの接続が必要な特殊なケースでは、サポートへの問い合わせが必要になります。

接続に使うポートは6379で、TLS専用です。redis-cli・valkey-cliともに、--tlsオプションを付けずに接続するとError: connection reset by peerのようなエラーになります。CLIのバージョン要件はエンジンごとに異なり、REDIS 7.0エンジンではredis-cliバージョン6以上(推奨7以上)、VALKEY 7.2エンジンではvalkey-cliバージョン7.2、VALKEY 8.1エンジンではvalkey-cliバージョン8.1が必要です。本記事のハンズオンで作成したクラスターはValkey 8.1エンジンのため、valkey-cliバージョン8.1を使用します。

valkey-cli --tls -h <プライマリエンドポイントのホスト名> -p 6379

5-3. 基本操作

接続後は、Redis/Valkey互換の標準コマンドでデータを操作します。

SET session:1001 "hello from oci cache vol1"
GET session:1001
EXPIRE session:1001 3600
TTL session:1001

SETでキーを登録し、GETで取得、EXPIREで有効期限(TTL)を設定できます。この基本操作はRedis/Valkey互換のため、ElastiCache経験者であれば違和感なく扱えます。

5-4. レプリカと読み取りエンドポイント

§4-3で確認した通り、非シャード構成では書き込み用のプライマリエンドポイントと、読み取り専用のレプリカエンドポイントが個別に発行されます。読み取り負荷を分散したい場合は、参照系のコマンドをレプリカエンドポイント経由で実行します。

valkey-cli --tls -h <レプリカ(読み取り)エンドポイントのホスト名> -p 6379
GET session:1001

ElastiCacheのReader Endpointと同様、書き込みはプライマリ、読み取りはレプリカという役割分担で構成するのが基本です。

5-5. 削除による課金停止

検証が完了したら、クラスターを削除します。OCI Cacheは、Compute VMのような「停止すれば課金が止まる」仕様ではなく、クラスターが存在する限りメモリGB時間分の課金が継続します。検証後に放置すると意図せず課金が積み上がる原因になるため、動作確認が終わったら速やかに削除することを強く推奨します。

OCIコンソールのクラスター詳細ページから「削除」を選択するか、OCI CLIで削除します。

oci redis redis-cluster delete --redis-cluster-id <クラスターOCID>

なお、OCI CLIのコマンドグループ名はoci redisのままです。§6で触れるSKU名の旧称(「Cache with Redis」)と同様、2024年6月の改称後もCLIグループ名は旧称(redis)を引き継いでいる点に注意してください。

6. まとめ・落とし穴チェックリスト

本記事では、OCI Cacheについて、Cache with Redisからの改称経緯・料金体系・エンジン選定・非シャード最小構成でのクラスター作成・接続確認という順に整理してきました。最後に、実際に採用・運用する際に必ず確認しておきたい5つのポイントをチェックリストとしてまとめます。

OCI Cacheは、ElastiCacheのノードタイプ課金に慣れた読者にとって、メモリGB時間という単一次元の課金モデルが新鮮に映るサービスです。§2の料金対比表を出発点に、必要なメモリ量に対してどちらのサービスがコスト効率よく合わせられるか、案件の要件に応じて検討してください。

本記事で扱いきれなかったValkey 8.1のJSON module・valkey-search moduleの実践的な使い方(ベクトル類似検索を使ったセマンティック検索の実装等)は、続編での取り扱いを検討しています。

OCI上でのメッセージング基盤・データ基盤を横断して整備したい場合は、Queue + Streaming with Apache Kafka実践、Database with PostgreSQL実践もあわせてご覧ください。

→ OCI Queue + Streaming with Apache Kafka実践Vol1(SQS/MSK対比の三択メッセージング選定)を読む

→ OCI Database with PostgreSQL実践Vol1(RDS/Aurora対比・Warm Standby DR)を読む

→ OCI入門 Vol4(Compute VM・Always Free枠のFlexシェイプ設計)を読む