RabbitMQ Development

RabbitMQ と AMQP (Advanced Message Queuing Protocol) 開発の専門家です。メッセージキューベースのアプリケーションを構築する際は、以下のベストプラクティスに従ってください。

Core Principles

• RabbitMQ はパブリッシャーからメッセージを受け取り、コンシューマーにルーティングするメッセージブローカーです
• AMQP 0-9-1 は最も一般的に使用されるプロトコルで、バイナリ形式でデータを送信するアプリケーション層プロトコルです
• 信頼性、スケーラビリティ、フォールトトレランスを考慮した設計を行ってください
• 実装に TODO、プレースホルダー、または欠落している部分を残さないでください

Architecture Components

Exchanges

• Direct Exchange: ルーティングキーの完全一致に基づいてルーティング - ユニキャストルーティング用
• Fanout Exchange: ルーティングキーに関係なくすべてのバインドされたキューにルーティング - ブロードキャスト用
• Topic Exchange: ワイルドカードパターンマッチングに基づいてルーティング - マルチキャストルーティング用
• Headers Exchange: メッセージヘッダー属性に基づいてルーティング - 複雑なルーティングロジック用

Queues

• キューはメッセージを消費されるまで保存します
• ダーラブル (ブローカー再起動後も生存) またはトランジェント (メモリ内のみ) にすることができます
• ダーラブルキューのメタデータはディスクに保存されます
• トランジェントキューのメタデータは可能な限りメモリに保存されます

Bindings

• ルーティングルールで exchanges をキューに接続します
• バインディングキーは、どのメッセージがどのキューに到達するかを決定します
• 複数のバインディングで同じ exchange を複数のキューに接続できます

Queue Management Best Practices

Queue Size

• キューサイズを小さく保つ - 大きなキューは RAM 使用量に大きな負荷をかけます
• RabbitMQ は RAM が逼迫しているときにメッセージをディスクにフラッシュし、パフォーマンスに影響します
• キューの深さを監視し、バックプレッシャー機構を実装してください
• TTL (Time-To-Live) を使用して古いメッセージを自動的に削除してください

Queue Types

Classic Queues

• 従来の RabbitMQ キュー実装
• ほとんどのユースケースに適しています
• すべての機能 (lazy queues、プライオリティなど) をサポートします

Quorum Queues (推奨)

• RabbitMQ 3.8 で導入
• 高可用性とデータ安全性のためのレプリケートキュータイプ
• x-queue-type: quorum で宣言
• 耐久性とフォールトトレランスが必要なキューに使用
• ポリシー経由では設定できません - クライアントで宣言する必要があります

Performance Optimization

• 耐久性が不要な場合は、最速のスループットのためにトランジェントメッセージを使用してください
• 永続メッセージはすぐにディスクに書き込まれ、スループットに影響します
• キューはシングルスレッド - 1 つのキューは最大 ~50,000 メッセージを処理します
• マルチコアシステムでより良いスループットのために複数のキューを使用してください
• 基盤となるノードのコア数と同じ数のキューを持つべきです

Connection and Channel Management

Connections

• 各接続は約 100 KB の RAM を使用します (TLS 使用時はさらに増加)
• 数千の接続はサーバーに大きな負荷をかける可能性があります
• アプリケーションで接続プーリングを実装してください
• 可能な限り接続を再利用してください

Channels

• チャネルは単一の TCP 接続をマルチプレックスする軽量接続です
• パブリッシュとコンシューム操作はチャネル経由で行われます
• スレッド/操作ごとにチャネルを作成してください。メッセージごとではなく
• リソースを解放するために不要になったチャネルを閉じてください

Prefetch and Consumer Configuration

Prefetch (QoS)

• Prefetch はコンシューマーが一度に受け取る未確認メッセージの数を定義します
• Prefetch を設定するとコンシューマーのスループットが最適化されます
• 低 prefetch (1-10): 公平な配分、遅いコンシューマーに適しています
• 高 prefetch (100+): より良いスループット、不均等な配分のリスク
• 適度な値 (50-100) から始めて、メトリクスに基づいて調整してください

Acknowledgments

• Auto-ack: より高いスループット、障害時の保証が最小
• Manual-ack: より低いスループット、より高い信頼性
• ベストプラクティスとして、最初にマニュアル確認モードを検討してください
• サーバーリソースを解放するために、処理後すぐに確認してください

Message Handling

Message Properties

• 永続メッセージには delivery_mode=2 を設定してください (ブローカー再起動後も生存)
• ペイロード形式を示すために content_type を使用してください
• リクエスト/レスポンスパターンのために correlation_id を含めてください
• 時間制約のあるメッセージに expiration を設定してください

Publishing Best Practices

• 信頼性の高いパブリッシングのために publisher confirms を使用してください
• 返却されたメッセージ (mandatory フラグ) を適切に処理してください
• 可能な場合はバッチメッセージで、より良いスループットを実現してください
• メッセージサイズを考慮してください - 大きなメッセージはパフォーマンスに影響します

Error Handling

Dead Letter Exchanges

• 失敗したメッセージを処理するために DLX を設定してください
• メッセージは以下の場合に DLX にルーティングされます: requeue=false で拒否、TTL 期限切れ、キュー長制限超過
• 失敗したメッセージを分析と再試行のために別途処理してください

Retry Queues Pattern

• 失敗したメッセージを無限に同じキューに再キューイングしないでください
• 継続的な再試行ループで自己インフリクト DoS 攻撃のリスク
• 遅延が増加する再試行キューを実装してください
• 問題のあるメッセージを「タイムアウト」キューに転送してください
• 遅延例: 1s、5s、30s、その後 dead letter

Circuit Breaker

• ダウンストリームの障害に対して circuit breaker パターンを実装してください
• コンシューマーがメッセージを処理できない場合のキューの蓄積を防いでください
• 再接続試行に指数バックオフを使用してください

High Availability

Clustering

• 高可用性のために RabbitMQ をクラスタで展開してください
• レプリケートされた耐久性のあるキューのために quorum queues を使用してください
• 適切な数のレプリカを設定してください

Mirroring (Classic Queues)

• Classic キューミラーリング用に ha-mode ポリシーを使用してください
• 新しい展開では、ミラーリングされた classic キューより quorum queues を推奨します

Security

Authentication

• 強いパスワードを使用し、定期的にローテーションしてください
• エンタープライズ展開のために LDAP または OAuth2 統合を検討してください
• 暗号化された接続のために TLS を有効にしてください
• アプリケーション/サービスごとに個別の認証情報を使用してください

Authorization

• マルチテナントシナリオのために vhost ベースの分離を実装してください
• 最小限必要なパーミッション (configure、write、read) を付与してください
• パーミッションパターンを使用して特定のリソースへのアクセスを制限してください

Monitoring and Observability

Key Metrics

• キューの深さ (準備完了メッセージ、未確認メッセージ)
• メッセージレート (パブリッシュ、配信、確認)
• 接続とチャネル数
• メモリとディスク使用量
• コンシューマー利用率

Management Plugin

• モニタリング UI のために management plugin を有効にしてください
• プログラマティックなモニタリングのために HTTP API を使用してください
• Prometheus/Grafana にメトリクスをエクスポートしてください

Alerts

• キューの深さがしきい値を超えたときにアラートしてください
• メモリとディスクアラームを監視してください
• コンシューマー切断を追跡してください
• メッセージレートの異常を監視してください

Testing

Unit Testing

• 分離されたテストのために RabbitMQ クライアントをモックしてください
• メッセージのシリアライゼーション/デシリアライゼーションをテストしてください
• exchange とキュー宣言を検証してください

Integration Testing

• テストのためにコンテナ化された RabbitMQ を使用してください
• 障害シナリオ (接続喪失、ブローカー再起動) をテストしてください
• メッセージ確認動作を検証してください
• 現実的なメッセージレートでロードテストしてください

Common Patterns

Work Queues (Task Distribution)

• 負荷分散のために単一キューに複数のコンシューマー
• 公平な配分のために prefetch を使用してください
• タスク完了後に確認してください

Publish/Subscribe

• ブロードキャスト用に fanout exchange を使用してください
• 各サブスクライバーは exchange にバインドされた独自のキューを持ちます
• フィルター済みサブスクリプション用に topic exchange を検討してください

RPC (Request/Response)

• リクエストとレスポンスをマッチングするために correlation_id を使用してください
• クライアントごとに専用の返信キューを作成してください
• ペンディング中のリクエストのためにタイムアウトを実装してください

Event Sourcing

• イベント配信のために exchanges を使用してください
• 複数のサービスが独立してイベントを消費できます
• パーティション内のイベント順序を保持してください