Redisは「キャッシュ」だけではもったいない
多くのチームがRedisをMemcachedの代替、つまり単純なKVキャッシュとして使っている。しかし2025年のRedis 8はマルチモデルデータベースへと進化しており、キャッシュはその機能の一部にすぎない。KGAでは5つのプロジェクトでRedisをキャッシュ以外の用途で活用している。その実践を共有する。
Redis 8の主な変更点
Redis 8（2025年リリース）の最大の変更はライセンスの変遷を経てのRSAL v2 + SSPLv1からの移行だが、技術的には以下の機能統合が重要だ。Redis Stack（旧モジュール群）の機能がコアに統合され、Search、JSON、Time Series、Probabilistic Data Structuresが標準搭載になった。追加モジュールのインストールが不要になり、運用が大幅に簡素化された。
パフォーマンス面では、I/Oスレッディングの改善により、マルチコア環境での読み取り性能が最大2倍に向上した。io-threadsパラメータで利用するスレッド数を指定でき、KGAでは8コアの環境でio-threads 4に設定して最良の結果を得ている。
ベクトル検索: LLMアプリケーションの基盤
Redis 8のベクトル検索（旧RediSearch VSS）は、LLMアプリケーションのembeddingストアとして有力な選択肢だ。FLAT（ブルートフォース）とHNSW（近似最近傍）の2つのインデックスタイプをサポートする。
KGAのRAGパイプラインでは、ドキュメントチャンクのembedding（1536次元、text-embedding-3-small）をRedisに格納している。10万エントリに対するHNSWベクトル検索のレイテンシは2-5msで、Pineconeの10-30msやPgvectorの15-50msと比較して高速。既にRedisを使っているインフラなら、ベクトルDBを別途導入する必要がない。
ハイブリッド検索（ベクトル類似度 + テキストフィルタ）も強力だ。FT.SEARCHコマンドで、ベクトル類似度のKNN検索にテキストフィルタ（カテゴリ、日付範囲等）を組み合わせられる。KGAのFAQ検索システムでは、ベクトル類似度で候補を取得しつつ、カテゴリと言語でフィルタリングし、検索精度（Recall@10）を82%から94%に改善した。
Pub/Sub: リアルタイムイベント配信
Redis Pub/Subは軽量なメッセージブローカーとして、Kafkaを導入するほどではない規模のリアルタイムイベント配信に最適だ。KGAのWebSocketベースのリアルタイム通知システムでは、バックエンドサーバー群（8台）がRedis Pub/Subを介してイベントを共有している。
SUBSCRIBE/PUBLISHの基本的なパターンに加え、パターンマッチング（PSUBSCRIBE）でチャネル名のワイルドカード購読が可能。notifications:user:123:*のように、特定ユーザーの全通知チャネルを一括購読できる。
ただしPub/Subには永続化がない。サブスクライバーがオフラインの間のメッセージは失われる。この制約を理解した上で使うことが重要だ。メッセージの確実な配信が必要なら、Redis Streamsを使うべきだ。
Streams: 永続的なメッセージキュー
Redis StreamsはKafkaライクな永続メッセージキューだ。メッセージの永続化、コンシューマーグループ、メッセージの確認応答（ACK）をサポートする。KGAではマイクロサービス間のイベント駆動通信にStreamsを活用している。
Kafkaと比較した場合のメリットは、運用の簡素化だ。ZooKeeper/KRaftの管理が不要で、既存のRedisインフラにStreamの機能を追加するだけ。月間1,000万メッセージ程度の規模なら、KafkaよりRedis Streamsの方が運用コストが大幅に低い。
一方、秒間10万メッセージを超えるような高スループット環境や、メッセージの長期保存（月単位）が必要な場合はKafkaが適切。Redis Streamsのメッセージはメモリ上に保持されるため（RDBやAOFで永続化はされる）、大量のメッセージを長期間保持するとメモリ消費が問題になる。KGAではXTRIMでStream長を10万メッセージに制限し、古いメッセージはS3にアーカイブする運用を採用している。
JSONネイティブサポート
Redis 8のJSON機能（旧RedisJSON）により、JSONドキュメントをネイティブに格納・操作できる。文字列として格納してGET/SETする代わりに、JSON.GETでJSONPath指定の部分取得、JSON.SETで部分更新が可能。
KGAのセッション管理では、ユーザーセッション情報をJSONドキュメントとして格納している。JSON.SETでカートの更新、JSON.GETで特定フィールドの取得を行い、セッション全体をGET/SETする従来方式と比較してネットワーク転送量が60%削減された。
実運用でのアーキテクチャ
KGAの典型的なRedisアーキテクチャを共有する。Redis Cluster（6ノード、3マスター+3レプリカ）をAWS ElastiCacheで運用。キャッシュ、ベクトル検索、Pub/Sub、Streamsを同一クラスターで処理。メモリ割り当ては100GB（r7g.2xlarge x3）で月額約$2,100。
この構成で、キャッシュ（月間2億回のGET/SET）、ベクトル検索（月間500万回のFT.SEARCH）、Pub/Sub（日間100万メッセージ）、Streams（月間1,000万メッセージ）を同時に処理し、平均レイテンシ0.8ms、P99レイテンシ3.2msを維持している。
注意点として、ベクトル検索とStreamsはメモリを多く消費するため、キャッシュのmaxmemory-policyとの兼ね合いに注意が必要だ。KGAではキャッシュ用のキースペースにTTLを必ず設定し、ベクトルデータとStreamデータが追い出されないようにしている。Redisの万能性に頼りすぎず、各機能の特性と制約を理解した上で使い分けることが重要だ。