ローカルキューマネージャーなしでIBMMQを使用することは可能であり、賢明ですか？

Question

私のチームは、AWS EC2にデプロイされ、IBM MQ（以前はWebSphere MQ、以前はMQSeriesと呼ばれていました）を介してオンプレミスのレガシーシステムと通信するアプリケーションを構築中です。

敷地内にはすでにIBMMQキュー・マネージャーがあります。 EC2にもデプロイする必要がありますか？アプリケーションを実行するEC2ボックスにデプロイする必要がありますか？

私はIBMMQを初めて使用しますが、RabbitMQの使用経験はあります。社内にはIBMMQの経験が豊富な人がいますが、クラウドアプリケーションはありません。アプリケーションのボックスでキューマネージャーを実行する必要があると何度か言われました。キューマネージャーは他のキューマネージャーに転送できますが、エフェメラルディスクを備えたクラウドマシンでは意味がありません。私にとって-それは信頼性を追加しません。

EBSボリュームを備えたEC2マシンにキューマネージャーをデプロイすることができます。これはもう少し意味があり、アプリケーションにそれと通信させることができます。しかし、それは私たちの敷地内にある既存のキューマネージャーと直接話すよりも本当に良いのでしょうか？

おまけの楽しみを追加するために、アプリケーションをEC2に直接デプロイするのではなく、EC2にデプロイされたCloud Foundryにデプロイするため、アプリインスタンスはあまり影響を与えないコンテナー内で実行されます。

Roger · Answer

キュー・マネージャーがデプロイされるボリュームのタイプについて心配することは、あなたが心配すべきことではありません。 IBM MQには、サポートされているボリュームとサポートされていないボリュームに関する特定のガイドラインがあります。詳細については、 MQナレッジセンターをご覧ください。

MQアプリケーションは、ローカルまたはリモート（キュー・マネージャーに対して）で実行できます。

（1）ローカル（バインディングモード）でキューマネージャーに接続するMQアプリケーションは、メッセージの取得や送信にネットワークが関与しないため、アプリケーションの開発とサポートを大幅に容易にすることができます。

（2）リモート（クライアントモード）でキューマネージャーに接続するMQアプリケーションは、はるかに複雑です。最近、他の誰かがMQ ListServerに同様の質問を投稿しました。これは、T.RobWyattの優れた回答です。

スタンドアロンのQMgrから共有ハブに統合する場合、多くの問題が発生します。あなたが質問しているのは、最も機械的で面白くない束の1つです。 FJが指摘しているように、セキュリティへの影響と、あなた自身が遭遇した接続の問題がいくつかあります。他のいくつかのハイレベルなまとめをお見せしましょう。これらのほとんどをどの程度経験するかは、環境が現在スタンドアロンである量と、現在共有している量によって異なります。例外は、クライアントに切り替えるときのデータの整合性です。そのため、最初にそれについて説明します。

メッセージの紛失や重複はなく、順序はほぼ保証されています：

これにはXAトランザクション性が必要です。 XAは独自の設計上の制約を課します。その中には、問題のアプリが別のQMgrにフェイルオーバーできないというものがあります。 MQは通常、通常の状況ではメッセージが重複したり、失われたり、乱れたりしないという点で、誰もが期待しているように動作します。

メッセージの重複、混乱の可能性：

これには、少なくとも単相コミットが必要です。同期点の下のキューからメッセージを取得し、クライアントアプリが次のAPI呼び出しで2059を取得した場合、メッセージはロールバックされ、失われないことが保証されます。しかし、アプリwillもう一度見ると、最初に正しく処理された場合は、重複しているように見えます。また、メッセージをPUTした後にアプリがCOMMITで2059を取得した場合、COMMITが失敗したと見なして、PUTを再度発行する以外に選択肢はありません。 GETの「機能の重複」とは異なり、これは複数の同一のメッセージを生成します。

1つ以上のGETでトランザクションを保持しているチャネルエージェントは、MQまたはTCPがタイムアウトになり、孤立した接続を切断するまでメッセージを解放しません。ロールバックは必ずしもアプリの前に行われるとは限らないためです。再接続すると、その同期点の下にない後続のメッセージを取得する可能性があります。孤立したチャネルが強制終了され、メッセージがキューに再表示されると、メッセージは配信されますが、注文は中断されます。

重複、メッセージの欠落、無秩序化の可能性：XAおよび単相COMMITを使用しないクライアント接続は、記載されている理由により、メッセージを失ったり複製したり、無秩序化したりする可能性があります上記。