AMQP？えーえむきゅーぴー？

はじめに

Quarkusの学習をする際初めて出会ったRabittMQという存在。（RabbitMQを使用したQuarkusメッセージング入門）

勤めている会社ではRabittMQを使用していますが、
そもそもRabittMQって何なのか、AMQPとは？。

えーえむきゅーぴー？

AMQP（Advanced Message Queuing Protocol）
よみ：えーえむきゅーぴー
AMQPはビジネスメッセージングのためのインターネットプロトコルです。
アプリケーション間または組織間でビジネスプロセスに必要な情報（メッセージ）を提供し、目標を達成するための指示を確実に転送します。

RabbitMQ はAMQPを使用した、オープンソースのメッセージ指向ミドルウェアです。

使用例

RabbitMQ公式サイトが分かりやすかったです。

例えば、
エンドユーザーに通知を送信するバックエンドサービスがあるとします。
通知チャネルには、電子メールとモバイルアプリケーションのプッシュ通知の2つがあります。

バックエンドは、各チャネルに1つずつ、合計2つのキューに通知を公開します。
電子メールとプッシュ通知を管理するプログラムは、
関心のあるキューをサブスクライブし、通知が到着するとすぐに処理します。

使用することによるメリット

RabbitMQは負荷の急増を吸収します。
サービス全体を中断することなく、通知マネージャーのメンテナンスを行うことができます。

使用しなかったらどうなるのか

•直接接続の問題:
バックエンドが通知サービス（メールやプッシュ通知）に直接リクエストを送る場合、通知サービスがリクエストをすぐ処理できないと、バックエンドに待ち時間やエラーが発生します。

例: 通知サービスが一時的にダウンしている場合、バックエンドは通知を失敗したまま再送する仕組みを自前で実装しなければなりません。
また、通知が順番通りに処理されるようにする仕組みを、バックエンドと通知サービスの両方で考える必要があります。

•負荷の急増の影響:
突然大量の通知が発生した場合（例: キャンペーン開始時など）、バックエンドと通知サービスの両方が過負荷になります。バックエンドはそのリクエストを処理しきれず、通知の遅延や失敗につながります。

MQの良さを改めて

AMQPを使用すると、メッセージキューが以下の役割を果たします：
•非同期処理の実現:
バックエンドは通知をキューに送信し、通知サービスが利用可能なときにそれを処理するため、通知サービスが過負荷でもバックエンドに影響がありません。

•負荷の平準化:
急増した通知はすべてキューに蓄積され、通知サービスは可能な速度で一つずつ処理します。
キューが緩衝材のように機能します。

•耐障害性:
通知サービスが一時的に停止しても、メッセージはキューに保持されます。通知サービスが復旧すれば、未処理のメッセージを再開できます。

まとめ

AMQP（RabbitMQ）のような仕組みを使うと、負荷の急増を吸収し、非同期で柔軟に通知を処理できます。
一方、これを使わない場合は、負荷の増加が直接バックエンドと通知サービスを圧迫し、システム全体に影響を及ぼします・・・。
また、キューの役割を果たす機能を自前で実装する必要があり、開発の複雑さも増すとのことで、
RabbitMQってすごい便利じゃん、と気づきがありました。
以上！