RabbitMQの永続キューと一時キュー：どちらを選ぶべきか

RabbitMQの永続キューはブローカーの再起動後も存続します。一時キューは存続しません。シンプルに聞こえますが、多くの障害はチームがキューを永続化しても、メッセージに独自の永続性設定が必要なことを忘れるために発生します。

この区別は、タスクキュー、通知ファンアウト、イベントパイプラインを設計する際に使用します。適切な選択は、メンテナンス中やクラッシュ時にキュー定義や処理中のメッセージの損失が許容できるかどうかに依存します。

キューの永続性の定義

RabbitMQにおいて、永続性とは、キュー構造とメタデータがブローカーの再起動後も存続する能力を指します。キューが永続的として宣言されると、RabbitMQはキュー定義（名前、引数、バインディング）がディスクに書き込まれることを保証します。

RabbitMQサーバーがシャットダウンした場合、永続キューは起動時に自動的に再作成され、バインディングを保持します。ただし、キュー永続性だけではメッセージの永続性を保証しないことを覚えておくことが重要です。それには個々のメッセージに適用される別の設定が必要です。

永続キュー：永続性と信頼性

永続キューは、データ損失が許容されないアプリケーションの標準的な選択肢です。信頼性を生の速度よりも優先します。

永続キューの特性

再起動後の存続： キュー定義はブローカーの再起動後も存続します。
ディスク永続性： キューメタデータはディスクに永続的に保存されます。
パフォーマンスのトレードオフ： 宣言と復旧のプロセスは、必要なディスクI/Oのために若干遅くなります。
リソース使用量： 特に永続メッセージと組み合わせた場合、ブローカーが永続ストレージを管理するため、一般的にリソース要件が高くなります。

永続キューを使用する場合

キュー構造がブローカーインスタンスのライフサイクルを超えて存続する必要があり、通常は重要なデータと組み合わせる場合に永続キューを使用します。

重要なワークフロー： 金融取引、注文処理、タスクを忘れてはならない重要なビジネスロジックの処理。
長時間実行タスク： メンテナンスウィンドウよりも長くかかる可能性がある、またはブローカーのダウンタイムが発生する可能性のあるタスク。
配信保証システム： 高いレベルのメッセージ配信保証を達成するための基盤として必要（永続メッセージと組み合わせた場合）。

永続キューの宣言

ほとんどのクライアントライブラリでは、永続性は宣言時にブールフラグで設定します。

# Pika（Pythonクライアントライブラリ）を使用した例
channel.queue_declare(queue='order_processing', durable=True)

⚠️ 警告：キューの再宣言

既存のキューを異なる永続性設定で再宣言しようとすると、RabbitMQはチャネル例外（PRECONDITION_FAILED）を発生させます。キューが永続的（または一時的）として定義されると、最初にキューを削除しない限り、そのタイプを変更できません。

一時（非永続）キュー：速度と柔軟性

一時キューは、非永続キューとも呼ばれ、短命で一時的なワークフローを対象としています。RabbitMQ 4.xは一時的な非排他的クラシックキューを非推奨としているため、新しいシステムを設計する前にブローカーのバージョンを確認してください。

一時キューの特性

再起動時の損失： キュー構造はブローカーのシャットダウンまたは再起動時に即座に失われます。
本質的に一時的： 通常、一時的なコンシューマー、応答キュー、再作成可能なデータに役立ちます。
再起動安全性が低い： ブローカーの再起動時にキューとその内容が消失することを想定する必要があります。
バージョン依存性： 新しいRabbitMQバージョンでは、一部の一時的なクラシックキューパターンが推奨されません。

一時キューを使用する場合

一時キューは、運ぶデータが再生成しやすい場合、または現在のキュー内容の損失が許容でき、速度と低レイテンシーを優先する場合に最適です。

リアルタイム通知： ライブアップデート、チャットメッセージ、株価ティッカーデータの配信。わずかに古いデータはすぐに上書きまたは再生成されます。
一時的な作業キュー： 一時的なコンシューマーまたはワーカープールで使用され、コンシューマーが接続を再確立し、キューを再宣言する責任を負います（必要な場合）。
ファンアウト/ブロードキャスト： メッセージが多くの一時的なコンシューマーにブロードキャストされる場合、キューバインディングの損失がシステムクリティカルではありません。

一時キューの宣言

一時キューは、durableフラグをFalseに設定するか（または省略する。Falseがデフォルトであることが多い）ことで宣言します。

# Pika（Pythonクライアントライブラリ）を使用した例
# durable=Falseを明示的に設定
channel.queue_declare(queue='live_notifications', durable=False)

# または、デフォルト（通常はFalse）に依存
channel.queue_declare(queue='temp_session_logs')

重要な区別：キューの永続性とメッセージの永続性

キューの永続性とメッセージの永続性は、信頼性の高いシステムを実現するために正しく設定する必要がある2つの独立した設定であることを理解することが重要です。

機能	設定	影響	デフォルト設定
キューの永続性	`queue_declare`の`durable=True/False`	キュー構造が再起動後も存続するかどうかを決定します。	通常`False`（一時的）
メッセージの永続性	`basic_publish`の`delivery_mode=2`（永続的）または`1`（一時的）	メッセージペイロードがディスクに書き込まれるかどうかを決定します。	通常`1`（一時的）

メッセージ永続性の要件

メッセージペイロードがブローカーの再起動後も存続するためには、2つの条件が満たされなければなりません。

メッセージを受信するキューは永続的である必要があります。
メッセージ自体は永続的として公開される必要があります。

永続メッセージを一時キューに送信した場合、メッセージはキュー自体が削除されるまで（ブローカー再起動時に即座に発生）のみ存続します。同様に、永続キューが一時メッセージを受信した場合、再起動後も存続しますが、すべてのメッセージは失われます。

# 完全な永続性の実現（キュー存続 + メッセージ存続）
# 1. キューは永続的である必要があります
channel.queue_declare(queue='fully_persistent_queue', durable=True)

# 2. メッセージは永続的である必要があります（delivery_mode=2）
channel.basic_publish(
    exchange='',
    routing_key='fully_persistent_queue',
    body='Critical Data Payload',
    properties=pika.BasicProperties(delivery_mode=2) # 2は永続的を意味します
)

意思決定フレームワーク：適切なタイプの選択

永続キューと一時キューのどちらを選択するかは、パフォーマンス要件と利用可能なリソースに対してデータの重要度を評価する必要があります。

決定基準	永続キューを選択	一時キューを選択
データの重要度	高い（金融データ、注文、必須タスク）。	低い（ログ、一時的な状態、リアルタイム更新）。
ブローカーダウンタイム	ブローカーの再起動/アップグレード後も存続する必要がある。	キュー構造とメモリ内容の損失が許容できる。
永続性の必要性	永続メッセージと組み合わせるために必要。	不要。メッセージは多くの場合一時的または短命。
パフォーマンス目標	信頼性が最大速度よりも重要。	最大スループットと可能な限り低いレイテンシーが必要。
リソース使用量	メモリとディスク使用量が高い（許容可能なオーバーヘッド）。	メモリ使用量が低い。永続的なディスクアクティビティを回避。

ベストプラクティスのまとめ

永続性を優先する： 信頼性の必要性について疑問がある場合は、デフォルトで永続キューと永続メッセージを組み合わせて使用します。パフォーマンスがボトルネックになった場合、後でいつでも一時キューに最適化できます。
組み合わせて使用する： コア処理パイプラインには永続キューを、同じシステム内の二次的な監視や通知サービスには一時キューを使用します。
損失を前提に設計する： 一時キューを使用する場合は、コンシューマーまたは上流システムが失われたデータを再処理したり、再起動後に欠落したメッセージを適切に処理したりするメカニズムを確保します。

まとめ

重要なワークロードには、永続キューを宣言し、パブリッシャー確認を有効にして永続メッセージを公開します。一時的または使い捨てのフローには、アプリケーションがキューを再作成し、メッセージの損失を許容できる場合にのみ一時パターンを使用します。

主なルールはシンプルです。キューの永続性はキュー定義を保持し、メッセージの永続性はメッセージペイロードを保持します。メッセージがブローカーの再起動後も存続するには、両方が必要です。