こんにちは。Supershipの@sirobouです。KDDI messagecastの開発を行っています。
この記事は Supershipグループ Advent Calendar 2025 の 5日目の記事です。
TL;DR
- redisは豊富な型・コマンドによって、データ保存以外の様々な用途に用いられている
- ただし、用途別に他ソフトウェアを利用したほうが良いケースももちろんある。
はじめに
業務内でRedisを利用した分散システムに触れており、インメモリのKVSの便利さを知り複数の用途に利用しています。
いずれ分散システムを構築する機会に立った際、用途別に適切なデータストアやブローカーを選定することが重要だと感じたため、Redisが一般的に使われている用途の分解を行い、類似物との比較を行い選択肢を増やすことを目的としています。
この記事でわかること
- Redisの各用途に（キャッシュ、ブローカー、排他制御）おける強み
- Memcached, RabbitMQ, ZooKeeperといった類似技術との比較と選定基準
Redisとは？
Redisはデータをメモリ上で管理するデータベース（インメモリdb）です。
- シングルスレッドで動作
- 永続化の方法がある（ディスクに保存）
- 複数のデータ型をサポート
- 不可分に読み出し、書き込みを行うコマンドがある
- TTLを簡単に設定できる
上記のような特徴があり、後述する様々な用途が実現可能なのはこれらのおかげと言えます。
利用事例と類似技術との比較
私が認識しているRedisの使用事例・用途を示します。
1. キャッシュ
分散システムの高速化を目的としたときに、インメモリで動作するRedisは共有するキャッシュとして利用することが可能です。
比較対象として Memcached を挙げます。同様にインメモリで動作するdbとなります。
https://memcached.org/
比較表
| 特徴 | Redis | Memcached |
|---|---|---|
| スレッドモデル | シングルスレッド | マルチスレッド |
| データ構造 | 複数対応 (List, Hash等) | String (バイナリ) のみ |
| 部分更新 | 可 (Hash型等) | 不可 |
| 永続化 | 可 (RDB/AOF) | 不可 |
上記の表から、
単純なKey-Valueの高速処理と、サーバー性能（コア数）に応じたスケールアップを最優先するなら Memcached。
複雑なデータ構造（ランキングやセッション等）の操作や永続化が必要なら Redis が適していると考えられます。
2. メッセージブローカー
非同期処理やサービス間通信において、Redisは手軽なメッセージブローカーとして機能します。
比較対象として、 RabbitMQ を挙げます。
https://www.rabbitmq.com/
比較表
| 特徴 | Redis (Pub/Sub, List) | RabbitMQ |
|---|---|---|
| 到達保証 | なし | あり |
| 機能性 | シンプル・高速 | 高機能 (再送制御・複雑なルーティング) |
| プロトコル | RESP（redis特有） | AMQP |
選定のポイント:
リアルタイム性重視でインフラを増やしたくない場合は Redis。
決済処理など「絶対にロストしてはいけない」タスクや、優先度の設定、複雑なルーティングが必要な場合は RabbitMQ が適していると考えられます。
3. 排他制御（分散ロック）
分散システムで同一リソースへの書き込みを制御する際、Redisは高速なロック機構として利用できます。
redisはシングルスレッドであること、SETNXを例とした疑似CAS操作コマンドを提供することで、排他制御を実現しています。
比較対象として、 ZooKeeper を挙げます。
https://zookeeper.apache.org/
比較表
| 特徴 | Redis (SETNX / Redlock) | ZooKeeper |
|---|---|---|
| 整合性モデル | AP寄り (速度重視) | CP (厳密な整合性重視) |
| ロック解放 | TTL (時間経過) で解放 | セッション断で自動解放 |
| 実装難易度 | ライブラリを使えば容易 | 構築・運用コストが高い |
選定のポイント:
高頻度なロック取得が必要でパフォーマンスを重視する場合は Redis。
リーダー選出など、システム全体で厳密な整合性が最優先される場合は ZooKeeper が適切だと考えられます。
ただし、CAP定理 https://ja.wikipedia.org/wiki/CAP%E5%AE%9A%E7%90%86
で示されるように、ネットワークを利用した分散システムでは完璧な排他制御を実現することは難しい（ほぼ不可能らしい）ため、要件に応じてパフォーマンスを求めるのか、一貫性を求めるのかで選定を行う必要がありそうです。
まとめ
Redisの便利さに甘えず、アーキテクチャ構築における複数の選択肢を持つために調査を行いました。
加えて、様々なデータの保存以外の用途でRedisが用いられる理由（型、コマンドの豊富さ）を再確認することができました。
思い残しは
- valkeyについて調べてみたかった
- zookeeperとmemcachedは令和の比較対象としては古すぎたかも
になります
参考
最後に宣伝です。
Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。
ご興味がある方は以下リンクよりご確認ください。
Supership 採用サイト
是非ともよろしくお願いします。