【ITニュース解説】Migrating a LavinMQ Node.js app from `amqplib` to `amqp-client.js`

この解説では、Node.jsアプリケーションでメッセージングシステムのクライアントライブラリを切り替える際の経験と、その結果得られた重要な知見について説明する。具体的には、AMQPというメッセージングプロトコルを扱うNode.jsのライブラリとして広く使われているamqplibから、CloudAMQPが開発したamqp-client.jsへの移行事例を取り上げる。

まず、メッセージングシステムとは、複数のアプリケーション間でデータをやり取りするための仕組みだ。AMQP（Advanced Message Queuing Protocol）はそのための標準的なルールを定めたもので、LavinMQはそのルールに基づいてメッセージを中継する「メッセージブローカー」の一種である。アプリケーションは、AMQPクライアントライブラリを使ってこのブローカーと通信し、メッセージを送受信する。

この移行作業では、既存のamqplibを使用しているNode.jsアプリケーションが、amqp-client.jsに切り替えることで、どれほどの変更が必要になるのかを検証した。検証のために、銀行のトランザクションを扱う小さなアプリケーションを構築した。このアプリケーションは、トランザクション情報をメッセージとしてLavinMQに送り、別のプログラム（ワーカー）がそのメッセージを受け取って処理する仕組みだ。処理中に一時的な問題が発生した場合は後で再試行（リトライ）し、永続的な失敗の場合は「デッドレターキュー」と呼ばれる特別な場所にメッセージを送り、さらに同じトランザクションが複数回届いても二重に処理されないよう、「冪等性（べきとうせい）」という仕組みで保護している。

このアプリケーションを設計する上で重要な工夫は、「broker.js」という中間レイヤーを導入したことだ。これは、銀行のビジネスロジック（例えば、口座残高を更新するなどの処理）と、AMQPクライアント固有のメッセージング操作（LavinMQに接続したり、メッセージを送ったり受け取ったりする処理）を明確に分離するための層である。概念的には、アプリケーションのビジネスロジックがbroker.jsに指示を出し、broker.jsが実際のAMQPクライアントを通じてLavinMQと通信するという構造になっている。

この分離のおかげで、AMQPクライアントライブラリをamqplibからamqp-client.jsに移行する際も、アプリケーションの大部分を変更せずに済んだ。具体的に変更されなかったのは、以下のような部分である。

• 銀行のビジネスロジック: トランザクション処理の具体的な手順など、業務に直接関わるコードは一切変更がなかった。
• キューとエクスチェンジのトポロジー: LavinMQ内でメッセージをどこに送るか、どこに保管するかといった「キュー」や「エクスチェンジ」の構成は変わらなかった。
• リトライ戦略: エラーが発生した際の再試行のルールは同じだった。
• デッドレター処理: 永続的な失敗メッセージをどのように扱うかのロジックも変更なしだった。
• 冪等性ロジック: 重複メッセージからアプリケーションを保護する仕組みもそのままだ。

ワーカープログラムがメッセージを受け取って行う判断、例えば「このトランザクションを処理する」「一時的なエラーなのでリトライする」「永続的なエラーなのでデッドレターに送る」「既に処理済みなので承認する」といったアプリケーションレベルの決定も、移行後も一切変わらなかった。これは、AMQPクライアントがメッセージングプロトコルの実装を担当するだけで、アプリケーションのビジネスルールや信頼性設計そのものには影響しないことを示している。

実際に変更が必要だったのは、ほとんどがbroker.jsレイヤーの内部実装だった。この層は、異なるAMQPクライアントがそれぞれどのようにメッセージング操作を実行するか、その具体的な方法を吸収する役割を担った。例えば、broker.jsを介して行われる「接続確立」「メッセージ発行」「メッセージ消費」「メッセージ承認」といった基本的な操作のコードは、クライアントライブラリの違いに合わせて書き換える必要があった。

ワーカープログラムはbroker.connect()で接続し、broker.subscribe(handleMessage)でメッセージの受け取りを開始するなど、broker.jsが提供するシンプルで一貫したインターフェースを通じてメッセージング操作を行っていたため、ワーカー側のコードはクライアント変更の影響を受けずに済んだ。broker.retry()やbroker.sendToDeadQueue()、broker.acknowledge()といった操作も、ワーカーはメッセージの処理結果をbroker.jsに伝えるだけでよく、その結果をどのAMQPクライアントを使ってLavinMQに伝えるかはbroker.jsが担当していた。

この移行で特に大きな違いが見られたのは「接続リカバリ」の処理である。メッセージングシステムでは、ネットワークの問題などで一時的にブローカーとの接続が切れることがあり、その際にアプリケーションが自動的に再接続し、中断した処理を再開できることが重要だ。

amqplibを使っていた当初の実装では、接続リカバリのロジックはbroker.jsレイヤー、つまりアプリケーション側で実装していた。接続が失われた場合、アプリケーションがそれを検知し、一定時間待ってから再接続を試み、新しい「チャネル」（通信経路のようなもの）を作成し、さらにメッセージを受け取るための「コンシューマー」（メッセージの受信役）を復元する必要があった。この一連のステップはすべてアプリケーションが責任を持って行うため、複雑なコードが必要になる場合もあった。

一方、amqp-client.jsには「AMQPSession」という高レベルなAPIが用意されており、このAPIを使うと接続リカバリの多くの部分をクライアントライブラリ自体が処理してくれる。接続が失われた場合、AMQPSessionがそれを自動的に検知し、再接続を試み、さらにメッセージを受け取るための「サブスクリプション」（キューからのメッセージ購読）を復元する。これにより、アプリケーションが直接書くリカバリコードの量を大幅に減らすことができた。

重要な点は、どちらのクライアントライブラリを使っても、接続障害から回復できる堅牢なアプリケーションを構築できるということだ。違いは、そのリカバリの責任がどこにあるか、つまりアプリケーションコード側で細かく制御するか、それともクライアントライブラリが自動的に多くの部分を処理してくれるか、という点にあった。amqplibではアプリケーションがリカバリを実装し、amqp-client.jsではクライアントがそれを担当する傾向がある。

この移行作業を通じて、リトライ、デッドレター、メッセージ承認、キューの耐久性設定、冪等性といった、アプリケーションの信頼性に関する主要なパターンは、AMQPクライアントライブラリを切り替えても変わらないことがわかった。これらはAMQPプロトコル自体やメッセージングシステム設計の基本的な要素であり、特定のクライアントライブラリが魔法のように解決してくれるものではない。観察された主な違いは、アプリケーションが接続のライフサイクル管理（接続、切断、再接続など）をどれだけ自分で処理する必要があるか、という点に集約された。

結論として、AMQPクライアントを切り替えることは、必ずしもアプリケーションの信頼性設計全体を根本的に変えることを意味しない。broker.jsのような中間レイヤーを使って、クライアント固有のメッセージングコードをビジネスロジックから分離することで、銀行アプリケーションのビジネスロジックやメッセージングアーキテクチャを変更することなく、基盤となるクライアントライブラリをスムーズに移行することが可能だった。変更されたのは、このbroker.jsの内部実装のみで、ビジネスの振る舞いは一貫して保たれた。