ある大手グローバル製造業企業は、ERP・MES（製造実行システム）・WMS（倉庫管理システム）など基幹システム間の連携に IBM MQ 9.2 を活用しており、オンプレミスデータセンターには 250 以上のキュー定義と 80 のトピックサブスクリプションが構成されています。500 を超えるアプリケーションが JMS（Java Message Service）API を通じてメッセージングを行っており、製造指図・在庫更新などのトランザクションメッセージ（確実な配信と順序保証が必要）と、製造ラインのセンサーデータのストリーミング（高スループット・低レイテンシ、Kafka 互換の消費が必要）が混在しています。 AWS への移行における要件は以下のとおりです。 ・IBM MQ のライセンスコストを削減し、AWS マネージドサービスへの移行を 18 ヶ月以内に完了する ・移行期間中、既存の JMS ベースのオンプレミスアプリケーションはコード変更なしに稼働し続けること ・センサーデータストリーミングには Kafka 互換のコンシューマー API が必要 ・全メッセージは保存時・転送時ともに AWS KMS で暗号化すること ・移行期間中はオンプレミス IBM MQ と AWS 側メッセージングの間でブリッジ構成を維持すること この要件を最もよく満たすアーキテクチャアプローチはどれですか？
Amazon MQ for ActiveMQ は JMS 1.1 および JMS 2.0 を完全にサポートしており、IBM MQ ユーザーが使用していた JMS API と同じインターフェースをネイティブに提供する。既存アプリケーションは JNDI 接続先設定のみを変更して Amazon MQ に切り替えられるため、コード変更なしの要件を満たす。 ActiveMQ の Foreign JMS Provider（JMS Bridge）設定を利用することで、IBM MQ を外部 JMS プロバイダーとして登録し、オンプレミス IBM MQ と Amazon MQ の間で双方向のメッセージ転送を実現できる。これにより移行期間中のブリッジ構成要件を満たしながら段階的な切り替えが可能となる。センサーデータストリーミングには Amazon MSK を採用することで Kafka 互換 API 要件を満たし、トランザクショナルメッセージング（Amazon MQ）とイベントストリーミング（MSK）の 2 層構成が最適なアーキテクチャとなる。両サービスともに AWS KMS による保存時・転送時暗号化をサポートしている。 選択肢BのAmazon MSKは、Kafka ネイティブプロトコルを使用しており JMS API を直接サポートしない。Kafka 互換 JMS ライブラリを追加しても XA トランザクションや commit/rollback のセッション管理など JMS のトランザクションセマンティクスを完全には再現できず、500 以上のアプリへのアダプター導入は「コード変更なし」要件にも違反する。 選択肢CのAmazon SQS/SNSは、JMS プロトコルをネイティブにサポートしておらず、Lambda ベースのアダプターでは JMS トランザクション（セッション commit/rollback）や Browsing API などの JMS 固有セマンティクスを完全に再現できない。大量メッセージ処理時の Lambda 同時実行コストと追加レイテンシも本番ワークロードでは課題となる。 選択肢DのEC2 上のセルフマネージド IBM MQは、IBM の MQ ソフトウェアライセンス費用が継続発生するためライセンスコスト削減要件を満たせない。Amazon MQ for RabbitMQ の JMS サポートは AMQP 0.9.1 ベースの JMS プラグインが別途必要であり、IBM MQ の JMS セマンティクスとの互換性は Amazon MQ for ActiveMQ より低い。