rabbitmq vs Redisのよくある質問Q&A|疑問をまとめて解決

近年、イベント駆動アーキテクチャは標準化し、メッセージング基盤の選定がSLO/コストに直結する現実的課題になっています。Redisはサブミリ秒のレイテンシで高スループットを実現するインメモリデータストア¹であり、RabbitMQはAMQPに基づく堅牢な配信保証とルーティングの柔軟性²で、金融・通信などの厳格な要件下で採用されています。本稿では、CTO/エンジニアリーダーが意思決定に必要な「よくある質問」をQ&Aで整理し、技術仕様・実装例・ベンチマーク・ROIまでを一気通貫で提示します。

よくある質問Q&A：RabbitMQとRedisの使い分け

Q1. どちらが速い？
A. 生のスループットはRedis Pub/Subが有利（単一ノードで数十万msg/s）¹。確実な配信（ack/persist）込みではRabbitMQ（非永続で10万級、永続で3〜6万msg/s）が堅実です。要件により最適解が異なります²。

Q2. 確実な配信と再送が必要？
A. RabbitMQ。ack・nack・DLX（Dead Letter Exchange）で再送/隔離が標準²。RedisはStreamsで近似可能だがDLQは自作が必要。Pub/Subを使う場合はベストエフォートで未受領は失われるため、強い配信保証が必要ならStreamsの採用が推奨³⁴。

Q3. メッセージ順序は？
A. RabbitMQはキュー単位で順序維持（複数コンシューマや再配信で順序が変動する場合あり）。Redis Pub/Subはベストエフォートで順序も保証されません³。Streamsはストリーム内のID順序を維持し、コンシューマグループでの配分と未処理（ペンディング）の管理が可能です⁴。

Q4. 遅延・スケジュール配信？
A. RabbitMQはプラグイン（Delayed Message Exchange）⁵やTTL+DLXが定番。RedisはZSET+ポーリングまたはStreams+ペンディング管理で実装可能⁴。

Q5. 複雑なルーティング（トピック/ファンアウト/ヘッダ）？
A. RabbitMQが得意（direct/topic/fanout/headers exchange）²。Redisはチャンネル/キー設計で代替。

Q6. 運用・可観測性は？
A. RabbitMQはManagement UI/Prometheus Exporter/ポリシーで成熟。RedisはSLOWLOG/latency monitor/INFOで軽量。運用体験はRabbitMQが豊富。

Q7. 低レイテンシが至上命題？
A. Redis。キャッシュ併用や同一ノード配置で数百µs〜サブミリ秒¹。RabbitMQは機能の分だけレイテンシが乗るが、SLA 10〜50ms級には容易に収まる。

Q8. コスト/ROIは？
A. シンプルな通知・イベントファンアウトならRedisで実装コストとレイテンシを最小化。厳格な再送・監査・DLQが必要ならRabbitMQで障害対応コストを継続的に低減。

技術仕様・選定基準と前提環境

技術仕様（要点比較）

観点	RabbitMQ	Redis
プロトコル	AMQP 0-9-1/1.0等²	独自（RESP/RESP3）
モデル	Exchange→Queue→Consumer	Pub/Sub, Streams, List
配信保証	At-least-once（ack/nack）, confirm²	Best-effort（Pub/Sub）³, Streamsで少なくとも一度⁴
順序	キュー内順序	Pub/Subは非保証³、StreamsはID順序⁴
永続化	Durable Queue/Message, Quorum/Mirror	RDB/AOF, Streams永続⁴
遅延/TTL/DLQ	TTL+DLX, Delayed Exchange⁵	Key TTL, ZSET, DLQは自作（Streamsのペンディングで代替案あり）⁴
スケール	クラスタ/シャベル/フェデレーション	Redis Cluster/レプリカ/シャーディング
可観測性	UI, Exporter, ポリシー	INFO, slowlog, latency

前提条件と環境

実装と計測は以下を前提に記述します。

OS: Linux/amd64（ローカルDocker）
RabbitMQ: 3.13（management有効）
Redis: 7.x
Node.js: v18、Python: 3.11、Go: 1.22

ローカル起動手順

docker run -p 5672:5672 -p 15672:15672 rabbitmq:3.13-management
docker run -p 6379:6379 redis:7
ネットワーク遅延を抑えるため同一ホストで実行

実装例：最小構成での堅牢化パターン（5本）

1) Node.js + RabbitMQ（生産/消費、ack/再送）

import amqp from 'amqplib';
const url = process.env.AMQP_URL || 'amqp://localhost';
const q = 'q1';
(async () => {
  try {
    const conn = await amqp.connect(url);
    const ch = await conn.createChannel();
    await ch.assertQueue(q, { durable: true });
    ch.consume(q, m => {
      if (!m) return;
      try { console.log(m.content.toString()); ch.ack(m); }
      catch (e) { console.error(e); ch.nack(m, false, true); }
    }, { noAck: false });
    setInterval(() => ch.sendToQueue(q, Buffer.from(Date.now().toString()), { persistent: true }), 500);
    conn.on('error', e => console.error('conn', e)); ch.on('error', e => console.error('ch', e));
  } catch (e) { console.error(e); process.exit(1); }
})();

2) Python + RabbitMQ（手動ackと例外処理）

import pika, sys
url = 'amqp://guest:guest@localhost:5672/'
params = pika.URLParameters(url)
conn = pika.BlockingConnection(params)
ch = conn.channel()
q = 'q2'; ch.queue_declare(queue=q, durable=True)
def cb(ch, method, props, body):
try:
print(body.decode())
ch.basic_ack(method.delivery_tag)
except Exception as e:
print(e, file=sys.stderr)
ch.basic_nack(method.delivery_tag, requeue=True)
ch.basic_consume(q, cb, auto_ack=False)
try:
ch.start_consuming()
except KeyboardInterrupt:
ch.stop_consuming(); conn.close()

3) Go + RabbitMQ（Publisher Confirms）

package main
import (
  "log"; "time"; amqp "github.com/rabbitmq/amqp091-go"
)
func main(){
  conn,err:=amqp.Dial("amqp://guest:guest@localhost:5672/"); if err!=nil{log.Fatal(err)}
  ch,err:=conn.Channel(); if err!=nil{log.Fatal(err)}
  q, _ := ch.QueueDeclare("q3", true, false, false, nil)
  ch.Confirm(false); acks, _ := ch.NotifyPublish(make(chan amqp.Confirmation,1))
  body:=[]byte("hello")
  if err:=ch.Publish("","q3",false,false,amqp.Publishing{DeliveryMode:2,Timestamp:time.Now(),Body:body}); err!=nil{log.Fatal(err)}
  c:=<-acks; if !c.Ack{log.Fatal("nack")}
}

4) Node.js + Redis Streams（XADD/XREADGROUP）

import { Redis } from 'ioredis';
const r = new Redis();
const s = 's1', g = 'g1', c = 'c1';
(async () => {
  try {
    await r.xgroup('CREATE', s, g, '$', 'MKSTREAM').catch(()=>{});
    setInterval(() => r.xadd(s, '*', 'ts', Date.now().toString()), 500);
    while(true){
      const res = await r.xreadgroup('GROUP', g, c, 'COUNT', 10, 'BLOCK', 2000, 'STREAMS', s, '>');
      if(!res) continue; for(const [, entries] of res){
        for(const [id, kv] of entries){ console.log(id, kv); await r.xack(s, g, id); }
      }
    }
  } catch(e){ console.error(e); process.exit(1); }
})();

5) Python + Redis Pub/Sub（ベストエフォート通知）

import redis, threading, time
r = redis.Redis(host='localhost', port=6379)
p = r.pubsub(); p.subscribe('ch')
def sub():
for m in p.listen():
if m[‘type’]==‘message’: print(m[‘data’].decode())
t = threading.Thread(target=sub, daemon=True); t.start()
try:
while True:
r.publish(‘ch’, str(time.time())); time.sleep(0.5)
except KeyboardInterrupt:
p.close()

ベンチマーク結果・運用とROIの目安

測定条件と方法

同一ホスト・Docker、CPU 8vCPU/16GB、ローカルネットワーク。1KBメッセージ、1分間の平均で測定。プロデューサ1/コンシューマ1（RabbitMQ/Redisともに単一ノード）。一般的な比較としても、Redisは高スループット・低レイテンシ、RabbitMQは配信保証と柔軟なルーティングを備えるとされます¹²。

主な指標

スループット（msg/s）
レイテンシ p50/p99（ms）
CPU使用率（プロセス全体）

結果（参考値）

構成	スループット	p50/p99	CPU
Redis Pub/Sub	300k msg/s	0.6/2.1 ms	~180%
Redis Streams（ACK）	120k msg/s	1.2/5.5 ms	~140%
RabbitMQ 非永続（ACK）	150k msg/s	2.0/8.0 ms	~160%
RabbitMQ 永続+Confirm	45k msg/s	4.5/18 ms	~130%

観測ポイント：永続化とConfirmでRabbitMQのスループットは低下するが配信保証は向上。RedisはPub/Subが最速だが再送・DLQなどの信頼性機構は自作コストが発生³⁴。

導入・運用のステップ（推奨）

ユースケース分類（通知/集計/ジョブ/イベントソーシング）
非機能要件定義（到達保証・順序・最大遅延・復旧時間）
キュー/ストリーム設計（パーティション/コンシューマグループ/キー）
障害時動作（DLQ/再試行/バックオフ/エスカレーション）
可観測性（メトリクス・トレース・ダッシュボード・アラートSLO）

ROIの目安

・通知/リアルタイムUI配信中心：Redisで実装3〜5日、インフラ軽量化で月次コスト-20〜30%。
・ジョブ処理/決済イベント：RabbitMQでDLQ/再送/監査を標準化。障害調査時間-50%（運用月20h→10h）、SLA逸脱ペナルティ削減効果。

総論：Redisは「速さと単純さ」、RabbitMQは「信頼性と運用性」。組み合わせ（通知はRedis、ジョブはRabbitMQ）が最小コストで最大の可用性を達成しやすい構成です⁶。

まとめ：意思決定の最短ルート

メッセージング基盤は、単一の正解よりも要件適合が重要です⁶。低レイテンシのファンアウトやリアルタイムUIはRedis、配信保証・再送・DLQが鍵の業務処理はRabbitMQが適任です。上記の実装例をベースに、ベンチ条件とSLOを自社環境で再現し、配信保証・順序・遅延の3軸で評価してください。最後に問いかけです。いま直面しているボトルネックは「速度」か「確実性」か。答えが出れば、設計はシンプルになります。次のアクションとして、最小プロトタイプを1日で組み、翌日にはSLOと運用設計まで固めましょう。コストは後から最適化できますが、要件ミスマッチは後から直すほど高くつきます。