はじめに
IBM MQは、その堅牢性と汎用性から多くの企業で標準的なメッセージング製品として採用されており、Forbes Global 2000の上位100社の90%が利用しています。銀行間の送金、証券決済、半導体工場の装置制御、航空券座席予約、オフィス複合機の利用情報収集、新聞記事配信など、消費者の目には見えにくい部分で社会を支える重要な技術です。
この記事では、30年以上にわたるMQの歴史を振り返り、その普及の過程、進化、そして本質的な価値について解説します。
90年代のMQ ： 異機種間連携の時代
IBM MQ（当時の名称はMQ Series）は1993年に発表されました。この時代、企業のITシステムはメインフレーム（例: System 390）、オフコン（例: AS/400）、UNIXを中心に多様化し始めており、さらにWindows PC上でのクライアント・アプリケーションやグループウェアの利用が広がっていました。
異なるOSやプログラミング言語を使用するアプリケーション同士のデータ連携が求められる中、MQは以下の特徴を持つことで急速に普及しました。
- 多様な通信プロトコル対応: SNAやTCP/IPをサポート
- 幅広いプラットフォーム対応: メインフレーム、AS/400、UNIX、Windowsで稼働可能
- 文字コード変換: EBCDICとEUC/Shift_JIS間のコード変換を提供
- 非同期メッセージング: メッセージをキューに格納し、システムが稼働次第処理可能
このような特性により、異機種間連携のためのソリューションとして広く利用されるようになりました。また、同時に企業間取引やワークフローを支援するメッセージング基盤としても採用されていきます。
2000年代 : SOAの時代
2000年代を通じて業務アプリケーションはWeb対応が進み、その中心を担ったのがJavaと.NETです。
Java EEではベンダーに依存しない標準メッセージングAPIとしてJMSが策定されました。IBMはいち早くJMSへのサポートを行い、Javaの世界におけるメッセージングに対する需要に対応しました。
同様に.NET向けのAPIを提供することでWindowsの世界にもMQを通じた相互運用を保証しました。
さらに、ERP, CRMの多くの業務パッケージ製品もIBM MQを標準的なインターフェースとしてサポート提供していたため業務システムの統合の中心にMQが活用される例が数多く生まれました。
2000年代を通じてMQは様々な金融、製造、航空、流通など幅広い業種の業界ネットワークを支える通信基盤としても採用されており、現在も社会の根幹を支える技術となっています。
2010年代 : クラウド・コンピューティングの進展
クラウド・コンピューティングの普及
2010年代になると企業の基幹系を含むIT資産をクラウド上にリフトする流れが加速していきます。
また、SaaSの普及も進み業務システムをSalesforceを代表されるクラウド・サービスに移行する流れも生まれてきます。企業はオンプレミスのデータセンター以外に複数のクラウド環境でITシステムを稼働させるようになり、それらのシステム同士を統合するニーズが生まれてきます。
MQは以下の点でその価値を発揮しました。
- オンプレミスとクラウドを跨いだハイブリッド環境での信頼性の高いデータ連携
- MQTT対応によるIoTとの連携やAMQPを用いた他のメッセージングシステムとの互換性強化
- REST APIのサポートでクラウドネイティブアプリケーションへの適用範囲を拡大
2020年代 : クラウド・ネイティブの時代へ
2020年代に入ると、企業はクラウドネイティブアーキテクチャやマイクロサービスの採用を進め、迅速なリリースや動的なスケーリングを実現しています。MQも以下の特徴を備えることでクラウド・ネイティブなソフトウェアへと進化しています
- コンテナ対応: KubernetesやOpenShiftでの稼働をサポート。
- 高可用構成: データセンター障害発生時にも迅速な復旧が可能。
- KEDAサポート: メッセージ数に応じたアプリケーションの自動スケーリング。
クラウド・ネイティブな世界の非同期メッセージングではApache Kafkaが大きな注目を集めていますが、MQにはKafkaには無い次のような特性があります。
- 少ないリソースで運用可能
- Kafkaの構成にはKafkaサーバー, Zookeeper, Kafka Connect含め比較的大きなリソースが必要ですが、MQは例えば0.1コアのコンテナでも運用可能です。
- 特定の相手へのメッセージ送信
- Kafkaでは個別のConsumerに対してメッセージを送信するにはConsumerの数だけTopicの作成が必要となり、個別宛先の数が多いとコストが高くなりますが、MQは特定の相手向けのキューやトピックを作成することのコストは全く高くありません。
- 複数リソースへの同期点処理
- Kafkaでは複数テーブルを単一同期点内で更新した場合に同期点の境界を伝搬することは非常に困難ですが、MQの場合にはグループ・メッセージの機能などで容易に実現可能です
- MQではデータベースなど外部リソースとのXAによる同期点更新が可能ですがKafkaにおいてはアプリケーションで整合性の担保が必要です。
一方でKafkaの持つ秒間数百万件のオーダーでのメッセージ処理や、メッセージの再消費などはMQにない特性です。どちらかが優れているというわけではなく、使い分けることが重要になります（重複するユースケースが数多くあることは事実です）。
大まかに言ってMQが得意とするのは特定相手に対する処理の依頼（コマンド・メッセージの処理）です。一方、Kafkaが得意とするのは処理結果発生するイベントの伝搬（イベント・メッセージの処理）です。つまり、MQのネットワークによって実行される処理によって生まれるイベントをKafkaを通じて様々な（不特定の）アプリケーションが活用するというのが二つのメッセージングの使い分けということになります。
MQの価値：時代を越える普遍性
MQは、その30年の歴史の中で、メインフレーム、Java/.NET、クラウド、コンテナ上のマイクロサービスといった多様なIT環境に対応し、進化を続けています。その強みの一つは、後方互換性を保ちながら時代のニーズに適応してきた点です。
この特性により、例えばKubernetes上の最新のマイクロサービスと30年前から稼働しているメインフレームアプリケーションを簡単に統合することが可能です。
今後も様々なアプリケーション・アーキテクチャーが誕生していくことでしょう。
しかしMQとともに投資されるITの価値は時代を超えて将来に引き継ぐことが可能となるのです。