メッセージキューの仕組み — 受付と作業を分ける「仕事の箱」

ひよこ

レポート作成を押したら「受付済み」だけ出たよ？

ペンギン先生

作成する仕事をキューへ渡して、別の作業係が進める設計かもしれないね。受付の完了とレポート完成は別。重い処理を全部終えるまで画面を待たせずに済むんだ。

ひよこ

キューは、仕事の順番待ちの箱？

ペンギン先生

そうだよ。Producerが仕事の情報を送り、Consumerが受け取って処理する。送る側と実行する側を分けることで、負荷の変化や片方が待つ場面に対応しやすくなるんだ。

ひよこ

箱へ入れれば、必ず順番どおりに完成する？

ペンギン先生

取り出す順と完了する順は別だよ。複数の作業係、再配信、優先度などで見える順番も変わり得る。順番が重要なら、使うサービスの保証と処理単位を合わせて設計するんだ。

ひよこ

作業係が受け取った瞬間に、仕事は完了？

ペンギン先生

手動ACKの設計では、必要な処理ができたことを受信側が確認して知らせるよ。RabbitMQのConsumerのACKと、送信側がブローカーの受付を確認するPublisher Confirmも別の意味なんだ。

ひよこ

途中で止まった仕事は、どうなるの？

ペンギン先生

手動ACKの未確認配送は接続等が失われると再配信され得るよ。設定やサービスによるけれど、だから同じ仕事が複数回来る可能性も考える。再試行の上限や失敗を調べる場所も用意したいね。

ひよこ

同じ仕事が来たら、2回作ってしまう？

ペンギン先生

仕事IDを使い、同じIDなら保存済みの結果を返すなど、重複しても結果が増えない設計を考える。記録と処理を別々に行うだけでは途中の失敗が残るので、DBの制約やトランザクションも検討するよ。

ひよこ

Kafkaも、受け取ったら消える箱なの？

ペンギン先生

Kafkaは記録を保持し、位置を管理して読むログの性質を持つよ。保持期間等の設定があり、いつまでも残るわけではない。RabbitMQの通常のキューと同じ消え方で覚えないようにしよう。

ひよこ

Exactly-onceなら、何でも1回だけできる？

ペンギン先生

どこまでの保証かを確かめよう。Kafka内のトランザクション等と、外のDB保存やメール送信は別の問題になる。まずは下の小さな箱で、送る・受け取る・終えるを分けてみよう。

まずは、3件の仕事を箱へ入れる

レポート作成のような待ち時間のある処理では、受付と実際の作業を分けると流れを理解しやすくなります。Python 3が使えるなら、次をqueue-demo.pyとして保存し、python queue-demo.pyで試してみましょう。

from queue import Queue

jobs = Queue()
for number in (1, 2, 3):
    jobs.put(f"report-{number}")

print("受付件数:", jobs.qsize())
for _ in range(3):
    job = jobs.get()
    print("処理する:", job)
    jobs.task_done()

jobs.join()
print("すべて完了")

受付件数: 3
処理する: report-1
処理する: report-2
処理する: report-3
すべて完了

この例は1つのプログラム内の待ち行列です。別のサーバーへの配送、永続保存、障害時の復旧を行うRabbitMQ等の実装ではありません。task_doneもネットワーク越しのACKではなく、このQueue内で仕事の完了を数える操作です。

「受け付けた」と「できた」を分ける

図では、画面から「レポートAを作る」という情報を渡し、作業係が実際に作ります。画面に受付済みと表示しても、成果物がもう存在するとは限りません。作業IDで進捗や結果を確認する入口が必要です。

ブローカーを使う場合も、送信側が受け付けてもらった確認と、受信側が処理した確認は別です。RabbitMQではPublisher ConfirmとConsumer Acknowledgementを区別します。必要な処理前に完了扱いにすると、障害時に仕事を失うおそれがあります。

順番・重複・再試行を確認する

RabbitMQの通常のキューは順序を保とうとしますが、優先度や再配信、複数のConsumerなどで観測する順番が変わります。デッドレター用の設定も自動的に何でも付くわけではありません。

もう少し詳しく：Kafkaと保証の境界

Kafkaは記録をパーティションに並べ、Consumerが読み取り位置を管理します。保持期間やコンパクション等の設定があり、消費したら必ず即削除する方式でも、永久保存の保証でもありません。

Kafka内のトランザクションやKafka Streamsでのexactly-onceの意味と、外部サービスへ副作用を起こす意味を分けます。たとえばメール配送や別DBへの保存には、その外部との協調が必要です。冪等性のキー、制約、結果と処理位置の記録などを目的に合わせて設計します。

🐧 ペンギン先生のまとめ：「メッセージキュー」って出てきたら「受け付けた仕事を、別の作業係へ渡す箱」と思えばだいたいOK！

作業係はスレッドプールの仕組み、通知を受け取る入口はWebhookの仕組みで続けて見てみましょう。

参考資料

• Python：queue — Queueのput/get・task_done/joinの意味
• RabbitMQ：Queues — キューの順序と再配信・複数Consumer等の条件
• RabbitMQ：Consumer Acknowledgements and Publisher Confirms — ConsumerのACKと送信側の確認・再配信
• Apache Kafka 4.0：Design — 保存とConsumer位置・トランザクション・外部のexactly-onceの条件