Apache Camel による IBM MQ と Amazon SQS、Amazon SNS との統合

IBM MQは、世界の銀行、航空会社、医療機関、保険会社など、多くの企業組織で使用されているメッセージ指向ミドルウェア (MOM) 製品です。

AWS では、既存のオンプレミスにある MOM システムをクラウドで実行されている新しいアプリケーションと統合できる方法についてお客様からよくお問い合わせいただきます。お客様は、クラウドアプリケーションからこれらのメッセージングシステムにメッセージを送受信できる、費用対効果が高く、スケーラブルで手間のかからないソリューションを探しています。

このブログ記事では、オンプレミスの IBM MQ から Amazon MQ、Amazon Simple Queue Service (Amazon SQS)、Amazon Simple Notification Service (Amazon SNS) への双方向ブリッジをセットアップする方法を示しています。

これにより、フルマネージド型の AWS メッセージングサービスと Apache Camel を使用してプロデューサーアプリケーションとコンシューマーアプリケーションを統合できます。このブログでは前述のソリューションをデプロイする方法と、SNS、SQS、およびデモ用の IBM MQ クラスター環境（AWS Fargate 上の Amazon Elastic Container Service (ECS) で実行）を使用して、実行中の統合をテストする方法を学びます。

このソリューションは、ブログ記事「Migrating from IBM MQ to Amazon MQ using a phased approach」で説明されているアプローチを使用して、段階的な移行の一部として使用することもできます。

ソリューション概要

Apache Camel ブローカークラスターを使用して、IBM MQ システムと、ターゲットシステム（ActiveMQ エンジンの Amazon MQ、SNS トピック、 SQS キューなど）を双方向に統合します。

次の例では、AWS サービス (この場合は AWS Lambda と SQS) が SNS トピック経由で IBM MQ に公開されたメッセージを受信します:

クラウドメッセージコンシューマー (Lambda と SQS) は、ソリューション内のターゲット SNS トピックにサブスクライブします。
Apache Camel ブローカーは、AWS Secrets Manager に保存されている認証情報で IBM MQ に接続し、IBM MQ’s Java Library を使用してキューから新しいメッセージを読み取ります。IBM MQ’s Java Library を利用する場合、IBM MQ メッセージのみがソースとしてサポートされています。
Apache Camel ブローカーは、これらの新しいメッセージをターゲット SNS トピックに公開します。Amazon SNS Extended Client Library for Java を使用して、256 KB を超えるメッセージを Amazon Simple Storage Service (Amazon S3) バケットに保存します。
Apache Camel は、2 回再試行しても SNS に配信できないメッセージを S3 のデッドレターキューバケットに保存します。

次の図は、ソリューション内で SQS キューから IBM MQ にメッセージを送り返す方法を示しています:

Lambda を使ったサンプルメッセージプロデューサーは、SQS キューにメッセージを送信します。Amazon SQS Extended Client Library for Java を使用して 256 KB を超えるメッセージを送信します。
Apache Camel ブローカーは、必要に応じて SQS Extended Client Libraryを使用して SQS に公開されたメッセージを受信します。
Apache Camel ブローカーは、メッセージを IBM MQ ターゲットキューに送信します。
同様に、ブローカーは IBM MQ に配信できないメッセージを S3 デッドレターキューバケットに保存します。

段階的なライブマイグレーションは、次の 2 つのステップで構成されます:

ブローカーサービスをデプロイして、既存の IBM MQ キューへのメッセージの読み取りと書き込みを可能にします。
コンシューマーまたはプロデューサーが移行されたら、対応するサービスを新しく選択したサービス (SNS または SQS) に移行します。

次に、AWS Cloud Development Kit (AWS CDK) を使用してソリューションをセットアップする方法を学習します。

ソリューションのデプロイ

必要条件

AWS CDK
TypeScript
Java
Docker
Git
Yarn

Step 1: リポジトリをクローンする

git を使用してリポジトリをクローンします:

git clone https://github.com/aws-samples/aws-ibm-mq-adapter

Step 2: テスト用 IBM MQ 認証情報のセットアップ

このデモでは、IBM MQ の相互 TLS 認証を使用します。そのためには、 app フォルダで以下のコマンドを実行して X.509 証明書を生成し、AWS Secrets Manager に保存する必要があります:

X.509 証明書を生成します。
```
./deploy.sh generate_secrets
```
Apache Camel ブローカーに必要なシークレットを設定します ( <integration-name >は、たとえば devと置き換えてみてください) :
```
./deploy.sh create_secrets broker <integration-name >
```
模擬用の IBM MQ システムのシークレットを設定します:
```
./deploy.sh create_secrets mock
```
cdk.jsonファイルを、ここまでのコマンドで出力されたシークレット ARN で更新します。（訳註：IBMMQ_TRUSTSTORE_… と IBMMQ_KEYSTORE_… はサンプルコード中の複数箇所で定義されていますが、全て更新が必要です）:
- IBM_MOCK_PUBLIC_CERT_ARN
- IBM_MOCK_PRIVATE_CERT_ARN
- IBM_MOCK_CLIENT_PUBLIC_CERT_ARN
- IBMMQ_TRUSTSTORE_ARN
- IBMMQ_TRUSTSTORE_PASSWORD_ARN
- IBMMQ_KEYSTORE_ARN
- IBMMQ_KEYSTORE_PASSWORD_ARN

独自の IBM MQ システムを使用していて、すでに X.509 証明書が利用可能になっている場合は、スクリプトを実行した後にスクリプトを使用してそれらの証明書を AWS Secrets Manager にアップロードできます。

Step 3: ブローカーの設定

このソリューションでは 2 つの Apache Camel ブローカーがデプロイされます。1 つはテスト用 IBM MQ システムからのメッセージを読み取るため、もう 1 つはメッセージを送り返すためのものです。送信用、受信用で異なるApache Camel ブローカーの使用は２つの目的があります。１つ目は、Auto Scaling 機能をより有効活用するためです。２つ目は、送信と受信のどちらかに問題発生しても、もう片方に影響を与えないためです。

cdk.jsonファイルを次の値で更新します。:

accountId: ソリューションをデプロイする AWS アカウント ID。
region: ソリューションをデプロイする AWS リージョンの名前。
defaultVPCId: ブローカーとモックがデプロイされている AWS アカウント内の既存の VPC ID を指定します。
allowedPrincipals: アカウント ARN (例： arn:aws:iam::123456789012:rootを追加して、この AWS アカウントがブローカーとの間でメッセージを送受信できるようにします。このパラメーターを使用して、SQS と SNS の両方の統合にクロスアカウント関係を設定し、複数のコンシューマーとプロデューサーをサポートできます。（訳註：サンプルコード中の複数箇所で定義されていますが、全て更新が必要です。）

Step 4: ソリューションのブートストラップとデプロイ

開発アカウントに正しい AWS_PROFILEと AWS_REGION環境変数が設定されていることを確認してください。
yarn install を実行して CDK の依存関係をインストールします。
CDK をブートストラップするために yarn cdk bootstrap –-qualifier mq <aws://<account-id >/<region >コマンドを実行します。
最後に、 yarn cdk deploy '*-dev' –-qualifier mq --require-approval never
を実行して、ソリューションを dev環境にデプロイします。

Step 5: 統合のテスト

AWS System Manager Session Managerとポートフォワーディングを利用してテスト用 IBM MQ インスタンスへのトンネルを確立し、ウェブコンソールにアクセスして手動でメッセージを送信します。ポートフォワーディングの詳細については、ブログ「Amazon EC2 instance port forwarding with AWS Systems Manager」を参照してください。（訳註：サンプルコードの README の「How to test locally」の項目も適宜ご参照ください）

コマンドラインターミナルで、開発アカウントに正しい AWS_PROFILEと AWS_REGION環境変数が設定されていることを確認します。
さらに、次の環境変数を設定します:
- IBM_ENDPOINT: IBM MQ のエンドポイント。例: IBM モック用のネットワークロードバランサー mqmoc-mqada-1234567890.elb.eu-west-1.amazonaws.com（訳註：マネジメントコンソールでデプロイされたロードバランサーのDNS名をコピーすることで取得可能です）
- BASTION_ID: 踏み台ホストのインスタンス ID。この出力は、「ステップ 4: ソリューションをブートストラップとデプロイ」において、 mqBastionStackのデプロイ後のリストから取得できます。
以下のコマンドを使用して環境変数を設定します:
```
export IBM_ENDPOINT=mqmoc-mqada-1234567890.elb.eu-west-1.amazonaws.com
export BASTION_ID=i-0a1b2c3d4e5f67890
```
スクリプト test/connect.shを実行します
デフォルトの IBM ユーザー (admin) と AWS Secrets Manager に mqAdapterIBMockAdminPassword として保存されているパスワードを使用して、https://127.0.0.1:9443/adminから IBM ウェブコンソールにログインします。

IBM MQ からのデータの送信と SNS での受信:

IBM MQ コンソールで、ローカルキューマネージャー QM1→ DEV.QUEUE.1にアクセスします
Hello AWSという内容のメッセージを送信してください。このメッセージは AWS Fargate によって処理され、SNS に公開されます。
SQS コンソールにアクセスし、 snsIntegrationStack-dev-2プレフィックスキューを選択します。これは SNS トピックにサブスクライブされたテスト用の SQS キューです。
[メッセージの送受信] を選択します。
[メッセージをポーリング] を選択すると、前に IBM MQ に送信された Hello AWSメッセージが表示されます。

Amazon SQS から IBM MQ へのデータの返送:

SQS コンソールにアクセスし、 sqsPublishIntegrationStack-dev-3-devというプレフィックスの付いたキューを選択します。
[メッセージの送受信] を選択します。
[メッセージ本文]には、 Hello from AWSを追加してください。
[メッセージを送信] を選択します。
IBM MQ コンソールで、ローカルキューマネージャー QM1→ DEV.QUEUE.2にアクセスして、このキューの下にリストされているメッセージを探します。

Step 6: クリーンアップ

cdk destroy '*-dev'を実行して、このウォークスルーの一部としてデプロイされたリソースを削除します。

まとめ

このブログでは、Amazon SQS と Amazon SNS を使用して IBM MQ とクラウドアプリケーション間でメッセージを交換する方法を学びました。

独自の統合を始めることに興味がある場合は、GitHub リポジトリの README ファイルを参照してください。JMS、NMS、AMQP 1.0 などの業界標準の API とプロトコルを使用して既存のアプリケーションを移行する場合は、リポジトリに用意されている手順を使用して Amazon MQ と統合することを検討してください。

Kubernetes で Apache Camel を実行することに興味がある場合は、代わりに Apache Camel K を使用するようにアーキテクチャを変更することもできます。

その他のサーバーレス学習リソースについては、Serverless Land をご覧ください。

この記事は、Principal Security Consultant の Joaquin Rinaudo と DevOps Consultantのゲジム・ムスリアンが執筆したものを Solutions Architect の三厨が翻訳しました。原文はこちら（記事公開日：2023 年 8 月 15 日）。

Amazon Web Services ブログ