DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

RabbitMQコマンドによるメッセージのパージとキュー内容の管理

コマンドラインツールを使用してRabbitMQキューを効果的に管理する方法を学びます。このガイドでは、キュー内容の確認、`rabbitmqctl list_queues`を使用したメッセージ数の監視、`rabbitmqctl purge_queue`を使用したキューからの全メッセージの安全なパージ方法を詳しく説明します。メッセージブローカー環境におけるパフォーマンス、データ整合性、運用効率の維持に不可欠です。

RabbitMQコマンドによるメッセージのパージとキュー内容の管理

RabbitMQキューをパージすることは、大雑把なツールです。キューにテストメッセージ、有害な作業アイテム、または意図的に破棄することにしたバックログが含まれている場合に便利です。推測だけで行うのは危険です。パージではバックログが発生した理由はわかりませんし、遅いコンシューマー、悪いリトライループ、またはメッセージを間違った場所に送信しているデッドレターポリシーを修正することもできません。

このガイドのコマンドを運用チェックリストとして使用してください。キューを検査し、vhostを確認し、コンシューマーに何が起こるかを判断し、パージするメッセージのみをパージし、結果を検証します。

rabbitmqctlを使用したキュー内容の理解

パージする前に、キューの現在の状態を理解することがしばしば必要です。rabbitmqctlツールは、キュー統計を検査するためのいくつかのコマンドを提供します。メッセージ数を理解するための最も関連性の高いコマンドはlist_queuesです。

キューとメッセージ数の一覧表示

rabbitmqctl list_queuesコマンドは、キューメトリクスを表示します。パージの決定において、最も重要な区別は、準備完了メッセージと未確認メッセージの間です。

構文:

rabbitmqctl list_queues [options]

例: キュー名とメッセージ数の表示

すべてのキューとそのメッセージ数を表示するには、次のコマンドを使用できます:

rabbitmqctl list_queues name messages_ready messages_unacknowledged

このコマンドは、次のような出力を表示します:

name            messages_ready    messages_unacknowledged    consumers
my_queue        0                 0                          2
another_queue   150               25                         4

この出力では:

  • name: 選択されたvhost内のキュー名。
  • messages_ready: 配信待ちのメッセージ。
  • messages_unacknowledged: コンシューマーに配信されたが、まだ確認応答されていないメッセージ。
  • consumers: 接続されているコンシューマーの数。

messages_readyが増加している場合、プロデューサーがコンシューマーを上回っているか、コンシューマーが不足しています。messages_unacknowledgedが増加している場合、コンシューマーが作業を受け入れたが完了していません。パージは準備完了メッセージのみをクリアします。これは、コンシューマーの手にある作業を削除するクリーンな方法ではありません。

特定のキューの詳細の検査

スクリプト作成には、JSON出力を使用し、JSON対応ツールでフィルタリングします:

rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers --formatter json

人間によるインシデントチェックには、テーブル出力の方が速いことがよくあります:

rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers state

キューからのメッセージのパージ

キューに不要になったメッセージが蓄積された場合、またはテストデータをクリアする場合、purge_queueコマンドが主要なツールです。このコマンドは、指定されたキューからすべてのメッセージを削除します。これは強力な操作であるため、注意して使用する必要があります。パージされたメッセージは復元できません。

purge_queueコマンド

rabbitmqctl purge_queueコマンドは、キュー名を引数として受け取ります。仮想ホストには-pを使用します。

構文:

rabbitmqctl purge_queue [-p <vhost_name>] <queue_name>

例: デフォルト仮想ホスト内のキューのパージ

デフォルト仮想ホストにprocessing_errorsという名前のキューがあり、そこからすべてのメッセージをクリアしたいとします:

rabbitmqctl purge_queue processing_errors

実行が成功すると、rabbitmqctlはパージされたメッセージ数を報告します:

Purged 150 messages from queue 'processing_errors' in vhost '/'

例: 特定の仮想ホスト内のキューのパージ

キューdead_letter_queueがmy_vhostという名前の仮想ホストにある場合、次を使用します:

rabbitmqctl purge_queue -p my_vhost dead_letter_queue

このコマンドは、指定されたキューとvhostからパージされたメッセージ数を示す同様の確認メッセージを返します。

purge_queueに関する重要な考慮事項

  • 不可逆性: パージされた準備完了メッセージは、他の場所にキャプチャまたは再生可能なソースデータがない限り失われます。
  • 未確認メッセージ: パージは、すでにコンシューマーに配信されたメッセージを確実に消去しません。クリーンなリセットが必要な場合は、最初にコンシューマーを停止します。
  • 権限: rabbitmqctlを実行するユーザーは、vhostとキューへの適切なアクセス権を持っている必要があります。
  • 間違ったvhostのリスク: 共有環境では常に-pを指定します。

以下は、本番環境のようなキューに対するより安全なパージ手順です:

# 1. 正確なvhost内のキューを検査
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

# 2. デプロイメントシステムからコンシューマーを停止またはスケールダウン
# 例のみ。プラットフォームの通常のコントロールプレーンを使用してください。

# 3. 処理中のメッセージを理解するために再度確認
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

# 4. キューをパージ
rabbitmqctl purge_queue -p /prod processing_errors

# 5. 確認
rabbitmqctl list_queues -p /prod name messages_ready messages_unacknowledged consumers

キューがデッドレターキューの場合、パージする前に管理UIまたは制御されたコンシューマーを通じて数件のメッセージをサンプリングすることをお勧めします。デッドレターキューには、シリアル化バグ、不正なルーティングキー、期限切れメッセージ、または拒否されたジョブの唯一の簡単な証拠が含まれていることがよくあります。

キュー管理のベストプラクティス

効果的なキュー管理は、パージ方法を知るだけではありません。考慮すべきベストプラクティスをいくつか示します:

定期的な監視

rabbitmqctl list_queuesまたはRabbitMQ管理UIを使用して、キューを継続的に監視します。messages_readyとmessages_unacknowledgedの数に特に注意してください。予期せぬ高い数値は、以下を示している可能性があります:

  • コンシューマーがダウンしているか、処理を停止している。
  • コンシューマーが遅すぎて生産レートに追いつけない。
  • メッセージ処理ロジックのバグにより、確認応答が失敗している。

アラート

キューメトリクスに基づいてアラートを設定します。たとえば、messages_readyが長期間にわたって特定のしきい値を超えた場合にアラートをトリガーします。このプロアクティブなアプローチにより、アプリケーションのパフォーマンスやデータ整合性に影響を与える前に問題に対処できます。

制御されたパージ

  • 計画メンテナンス: 一時的なキューが意図的に破棄可能な場合、既知のウィンドウ中にクリーンアップを自動化します。
  • トラブルシューティング: バックログを説明するのに十分な証拠を収集した後にパージします。
  • キャパシティプランニング: 繰り返しのパージは問題の兆候です。通常、コンシューマーの容量、リトライ動作、またはルーティングに注意が必要であることを意味します。

デッドレタリング

正常に処理できないメッセージについては、デッドレタリングを設定します。これにより、拒否、期限切れ、または制限を超えたメッセージが別の交換機/キューにルーティングされ、検査されます。デッドレターキューをパージするのは、それらのメッセージを再生、アーカイブ、または破棄する必要があるかどうかを理解した後にのみ行ってください。

冪等性

コンシューマーを冪等になるように設計します。つまり、同じメッセージを複数回処理しても、1回処理した場合と同じ効果が得られます。これは、パージと再配信のリスクを軽減するため重要です。重複処理によってアプリケーションの状態が不正確になることはありません。

パージすべきでない場合

グラフが高いからといってパージしないでください。バックログは有用なプレッシャーになる可能性があります。プロデューサーがコンシューマーより速い、コンシューマーが失敗している、またはダウンストリームサービスが遅いことを示しています。パージはそのシグナルを隠します。ビジネスがそれらのメッセージを処理すべきでないと判断した場合に、パージは正しい行動です。

適切なパージチケットまたはインシデントノートは、4つの質問に答える必要があります:

  1. どのvhostとキューがパージされましたか？
  2. パージ前に、準備完了メッセージと未確認メッセージはいくつありましたか？
  3. コンシューマーは停止されましたか、それともまだ実行中でしたか？
  4. メッセージを破棄することがなぜ許容されたのですか？

そのノートはその瞬間は退屈に感じるかもしれませんが、後で誰かがジョブがどこに行ったのか尋ねたときに、多くの議論を節約できます。