先に要点
Redis ってよく聞くけど、結局何に使うの？ MySQL や PostgreSQL と何が違うの？
この疑問はかなり多いです。
特に Laravel や Web アプリの構成図を見ると、DB とは別に Redis が置かれていて、この箱は何の仕事をしているのか が分かりにくいことがあります。
この記事では、2026年4月14日時点の Redis 公式ドキュメントを確認しながら、Redis の基本と、初心者が実務で最初に出会いやすい キャッシュ セッション キュー の3つの使いどころを整理します。
Redisとは何か
Redis は、高速な読み書きを得意とするインメモリ中心のデータストアです。
初心者向けにかなりざっくり言うと、メモリ上に素早く出し入れできる保管場所 のようなイメージです。
一般的なリレーショナルデータベースと大きく違うのは、正規化した表をきっちり管理する より、一時的に持ちたい値を速く扱う ことが得意な点です。
そのため、実務では次のような用途で名前が出やすいです。
MySQLやPostgreSQLと何が違うのか
MySQL や PostgreSQL は、会員情報、商品情報、受注、記事本文のような 消えると困る本体データ を持つのが主な役割です。
一方 Redis は、速く扱いたい補助データ や 一時的な処理の置き場 として使われることが多いです。
| 観点 | Redis | MySQL / PostgreSQL |
|---|---|---|
| 得意なこと | 高速な読み書き、一時データ、非同期処理の補助 | 本体データの保存、厳密な整合性、複雑な検索 |
| 保存先のイメージ | メモリ中心 | ディスク中心 |
| 向いているデータ | キャッシュ、セッション、キュー、カウンター | 会員情報、注文、記事、マスタデータ |
| 実務での立ち位置 | 補助役として使われやすい | 中心のDBとして使われやすい |
つまり、Redis は DB の代わり というより、DB やアプリの処理を軽くするための相棒 と考えると分かりやすいです。
一番よく使われる用途1：キャッシュ
Redis が最初に使われやすいのは、やはり キャッシュ です。
キャッシュで何をしているのか
たとえば、
- 重い集計結果
- よく読まれる記事一覧
- 外部 API の取得結果
- 毎回同じ条件で作る検索結果
のようなものを、毎回ゼロから作ると遅くなります。
そこで、一度作った結果を Redis にしばらく置いておき、次回はそれを返すようにします。
リクエスト
→ Redis に結果があるか確認
→ あればそのまま返す
→ なければ DB や API から作る
→ Redis に保存して返す
この流れで、アプリや DB の負荷を下げやすくなります。
実務でありがちな場面
- トップページの人気記事一覧
- 商品一覧の並び替え結果
- ダッシュボードの集計値
- 短時間で何度も呼ばれる API
初心者が混乱しやすい点
キャッシュは速くなりますが、古い情報が残ることがあります。
そのため、何分持たせるか 更新時に消すか を決めずに入れると、速いけど古い 状態になりやすいです。
よく使われる用途2：セッション
セッションは、ログイン中の状態や一時的なユーザー情報を持つために使われます。
セッションで何をしているのか
たとえばログイン後、毎回ユーザー情報を全部送り直すのではなく、サーバー側で この人はログイン済み という状態を持っておきます。
その保存先として Redis を使うことがあります。
Redis が向いている理由は、次の通りです。
- 読み書きが速い
- 有効期限を持たせやすい
- 複数サーバー構成でも共有しやすい
特に Web サーバーが複数台あると、各サーバーのメモリだけにセッションを置くより、Redis にまとめた方が扱いやすくなります。
実務でありがちな場面
- ログイン中ユーザーの状態管理
- 多段フォームの一時保存
- 認証途中の一時的な情報保持
注意点
セッションは 消えてもその場で再ログインすれば戻れるか を考える必要があります。
絶対に失いたくない本体データを Redis セッションにだけ持たせるのは危険です。
よく使われる用途3：キュー
初心者が Redis ってこんな使い方もするのか と驚きやすいのがキューです。
キューで何をしているのか
キューは、今すぐ画面の返答に必要ではない重い処理 を後ろへ回すための仕組みです。
たとえば、
- メール送信
- 通知送信
- 画像変換
- CSV 出力
- 外部サービスへの連携
のような処理を、ユーザーのクリックと同時に全部やると画面が遅くなります。
そこで、やるべき仕事 だけを Redis に積んでおき、ワーカーが後から順に処理します。
ユーザーが登録ボタンを押す
→ 本体データだけ保存
→ メール送信ジョブをキューへ積む
→ 画面はすぐ完了
→ ワーカーが後からメール送信
これで体感速度がかなり変わります。
Laravelで出会いやすい場面
Laravel では、キューの保存先として Redis を使う構成がよく出てきます。
同期でやると遅い処理を、ジョブとして後ろに回す という考え方を覚えると、構成図の意味がかなり見えやすくなります。
初心者が混乱しやすい点
キューに積んだだけでは処理は終わりません。
ワーカーが動いていないと、ジョブはたまるだけです。
そのため、実務では 積む側 と 処理する側 の両方を見ないといけません。
Pub/SubやStreamsは何が違うのか
Redis を調べると、Pub/Sub や Streams も出てきます。
ただ、初心者の最初の理解としては、ここを深追いしすぎなくて大丈夫です。
- Pub/Sub: イベントを購読者へ配る仕組み
- Streams: 履歴を持ちながらメッセージを流せる仕組み
まず実務で多いのは、キャッシュ、セッション、キューです。
Pub/Sub や Streams は、リアルタイム処理やイベント連携の要件が強くなったときに見れば十分です。
Redisは何でも入れてよいのか
ここはかなり大事です。
Redis は便利ですが、速いから全部 Redis に置こう は危険です。
判断の目安はこうです。
| データの性質 | Redis向きか |
|---|---|
| 消えても作り直せるキャッシュ | 向いている |
| 有効期限つきのログイン状態 | 向いている |
| 後ろで処理したいジョブ | 向いている |
| 会員情報や注文などの本体データ | 基本は向かない |
| 長期保存が前提の厳密な記録 | 基本はDB向き |
大事なのは、Redis に入れるデータは「消えたら何が困るか」を考えること です。
実務で見るときのポイント
Redis を実務で使うときは、次の点を見ると事故が減ります。
- 保存期間を決めているか
- キャッシュ削除のタイミングが決まっているか
- ワーカー監視ができているか
- Redis が落ちたときにどこまで影響するか分かっているか
本体DBと補助データの役割分担が崩れていないか
速いことだけに目が行くと、あとで 古いデータが出る ジョブが詰まる セッションが飛ぶ という形で困りやすいです。
筆者ならどう使い分けるか：redis-cliで見る3つの役割
ここまでは考え方の話でしたが、筆者(SE歴9年、Web・バックエンド・DB実務)が役割を判断するときは、最終的に「このデータは消えても作り直せるか」「有効期限を何秒にするか」の2点で決めています。実際に redis-cli で触ると、3つの用途の違いが一気に腹落ちするので、最小のコマンドで並べます。
キャッシュは「消えても DB から作り直せる」前提なので、保存と同時に有効期限を付けます。EX で秒数を渡し、TTL で残り秒数を確認できます。
# 60秒だけ集計結果を持つ(消えたら作り直す前提)
redis-cli SET ranking:top '[{"id":1},{"id":2}]' EX 60
redis-cli TTL ranking:top
# (integer) 58 残り秒数。-2 なら既に消えている
redis-cli GET ranking:top
セッションは1つのキーに複数の属性を持たせたいので、筆者はハッシュ(HSET)を使い、キーごとに EXPIRE で寿命を切ります。文字列を何本も作るより、ユーザー1人=1キーにまとまって見通しが良くなります。
# session:ユーザーIDに属性をまとめ、30分(1800秒)で失効
redis-cli HSET session:1001 user_id 1001 role editor logged_in 1
redis-cli EXPIRE session:1001 1800
redis-cli HGETALL session:1001
キューは「積む側」と「処理する側」を分けるのが肝でした。最小構成なら LPUSH で積み、ワーカー側は BRPOP で待ち受けます。BRPOP はジョブが来るまでブロックして待つので、無駄なポーリングが要りません(末尾の 5 は最大5秒待つ意味です)。
# 積む側:メール送信ジョブを1件積む
redis-cli LPUSH jobs:mail '{"to":"a@example.com","tpl":"welcome"}'
# 処理する側:ジョブが来るまで最大5秒待って取り出す
redis-cli BRPOP jobs:mail 5
# 履歴も残したい場合は Streams(XADD/XREAD)を使う選択肢もある
注意したいのは、これらはすべて「メモリ上の揮発データ」が前提だという点です。Redis は RDB(スナップショット)や AOF(追記ログ)で永続化もできますが、AOF を有効にすると書き込みごとにログが増えてディスク I/O とのトレードオフになります。筆者は「消えても困らない補助データ」なら永続化を軽め、本体相当を一時的に預かるなら AOF を検討、と切り分けています。
さらにメモリ上限の設計も外せません。maxmemory に上限(例:512MB)を、maxmemory-policy に追い出し方針を入れておかないと、上限到達時に既定の noeviction だと書き込みが丸ごとエラーになります。キャッシュ主体なら古いキーから消す allkeys-lru、有効期限付きのキーだけ消したいなら volatile-lru を選ぶ、という判断になります。
# 現在の上限と方針を確認(空文字なら無制限=本番では危険)
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policy
結局のところ、役割を選ぶ基準はシンプルで、「消えたら作り直せる→キャッシュ」「消えたら再ログインで戻せる→セッション」「すぐ返さず後ろで回したい→キュー」です。この一言で迷いがかなり減ります。
よくある誤解
Redisはただのキャッシュ専用ツール？
キャッシュ用途が有名ですが、セッションやキューでもかなり使われます。
速い一時データの置き場 と考えると理解しやすいです。
RedisがあればDBはいらない？
基本は違います。
本体データは MySQL や PostgreSQL のような DB に持たせ、Redis は補助役として使うのが一般的です。
Redisに積んだらキュー処理は終わったことになる？
なりません。 ジョブを積んだだけで、実際に処理するワーカーが動いていなければ完了しません。
Redisに関するよくある質問
Q. Redis のデータはサーバー再起動で消えますか？
A. デフォルトでは消えませんが、設定次第です。RDB スナップショットと AOF(追記ログ)で永続化できますが、基本は揮発 の前提で、消えても困らないデータに使うのが安全です。
Q. Redis と Memcached はどちらを使うべきですか？
A. 単純なキャッシュだけなら Memcached、データ構造(リスト、ハッシュ、ソート済みセット)、Pub/Sub、Stream など多機能を求めるなら Redis です。最近はほとんどの新規構築で Redis が選ばれます。
Q. Redis はマネージドサービスで使えますか？
A. はい、AWS ElastiCache、Azure Cache for Redis、GCP Memorystore、Upstash、Redis Cloud などが定番です。自前で Redis サーバーを運用するより、運用負担が大幅に軽くなります。
Q. Redis のメモリ不足になったらどうなりますか？
A. maxmemory と maxmemory-policy の設定で挙動を制御できます。LRU や LFU で古いデータを削除する、書き込みを拒否する、などが選べます。noeviction のままだと書き込みエラーで詰まります。
Q. Redis Sentinel と Redis Cluster はどう違いますか？
A. Sentinel は 1ノードに障害が起きた時の自動フェイルオーバー、Cluster は データを複数ノードに分散して水平スケール する仕組みです。可用性のみなら Sentinel、データ量も増やすなら Cluster を使います。
Q. セッション保存に Redis を使うメリットは？
A. 複数の Web サーバー間で同じセッションを共有できる、有効期限を秒単位で管理できる、高速に読み書きできる、の3点です。シングルサーバーなら DB セッションでも十分ですが、複数台構成では Redis が定番です。
Q. キュー処理(BullMQ、Sidekiq、Resque)に Redis が向いている理由は？
A. リスト型操作(LPUSH/RPOP)、信頼性のある排他制御、Pub/Sub、データ構造の豊富さ、低遅延、が揃っているためです。専用キューミドルウェア(RabbitMQ、SQS)と比べて、軽量で開発が早いという特性があります。
まとめ
Redis は、高速な読み書きを得意とするインメモリ中心のデータストアで、一時的に持ちたい情報 とかなり相性がよいです。
初心者が最初に押さえたい用途は、キャッシュ、セッション、キューの3つです。
キャッシュは 毎回重い処理をしないため、セッションは ログイン状態などを持つため、キューは 重い処理を後ろで回すため に使われます。
大事なのは、Redis は速い補助役 であって、何でも入れる本体DBではないと分けて考えることです。
あわせて、キャッシュそのものの考え方を整理したいなら CDNとは？何が速くなるのか、どこまで必要なのかを解説 や glossary の キャッシュ もつながります。
データベースとの役割分担まで見たいなら PostgreSQLとMySQLの違いは？実務でどう選ぶかを初心者向けに比較 も続けてどうぞ。
参考リンク
- Redis Docs: What is Redis?
- Redis Docs: Data Types
- Redis Docs: Expiration
- Redis Docs: Pub/Sub
- Redis Docs: Streams
- Laravel Docs: Queues