Amazon MQによるエンタープライズシステムのクラウドマイグレーション #reinvent

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Amazon MQリリース!

新しいサービスがリリースされました。Amazon MQです。中身は、そのまんまActiveMQのようです。AWSは、運用が面倒なMQ(メッセージキュー)をマネージドで提供することで、エンタープライズな環境に導入済みのMQのクラウドマイグレーションを促進します。ActiveMQは、OSSとして多くの実績があり、クライアントライブラリが豊富で、様々なプロトコルに対応しているため、既存のエコシステムに乗りやすいのが特徴です。新規でシステムを開発する際にはAmazon SQSやAmazon SNSを用い、既存システムのマイグレーションにはAmazon MQを使ってみてはいかがでしょうか。

ActiveMQの対応

ActiveMQは非常に多くのライブラリやインタフェースやプロトコルに対応しています。

対応インタフェース

  • Sockets
  • Library(CやGoなど)
  • JMS(Java Message Service)
  • WebSocket

対応プロトコル

  • OpenWire
  • AMQP
  • STOMP
  • MQTT
  • WSS

IBM MQの置き換え?

IBM MQ(旧WebSphere MQ)は、既に多くのエンタープライズシステムへ導入されています。クラウドが無かったころのエンタープライズシステムは、以下に疎結合に、確実にデータを届けるか、重要な要素でした。そして、IBM MQの果たした役割は非常に大きかったと思います。Amazon MQは、これを容易にクラウド向けに置き換えるソリューションになる可能性が高いと思います。重要なことは、既存のシステムのプログラムを一切変更せずに、設定ファイルの切り替えのみで動作をすることです。(あくまでも理想論ですが)

JNDI切り替えによるMQマイグレーション

実際にどうやってマイグレーションするか気になります。MQを活用したシステムの場合、アプリケーション・サーバーからMQにメッセージを送ります。この際、MQへの接続情報について、JNDI(Java Naming and Directory Interface)という、URL名前解決のサービスに記載していることがほとんどです。

以下のようなイメージです。

MQは、配信購読型のモデルで、宛先をJNDIに記載しています。Amazon MQに置き換える手順を見てみます。まず、Amazon MQのインスタンスを立ち上げます。

そして、JNDIでJMSの宛先指定である、コンテキストファクトリーのURL等を書き換えます。これにより、JMSメッセージの宛先がAmazon MQに変わります。同様にメッセージを受け取る側も受け取りのURLをAmazon MQにしてください。

次に、疎結合になったアプリケーションサーバー側をクラウドに移行してしまいましょう。

さらに、メッセージ受け取る側のシステムもクラウドに移行して、VPCでピアリングしてみましょう。

はい、これでエンタープライズシステムをクラウドにマイグレーションできました。

まとめ

Amazon MQのリリースを見て思ったのは、AWSって抜かり無いなと感じました。世の中のエンタープライズなシステムは、IBM MQのシェアが大きいはずで、これをSQSにマイグレーションするよりも全く同じプロトコルでマネージドサービスとしてActiveMQを提供したほうが早いですよね。つまり、AWSは本気でエンプラのマイグレーションしようとしている企業に対して、できるだけ早く簡単に移行できるようにツールやサービスをマネージドで提供していくという意思表明だと思いました。SQSやSNSなど、他にもあるのにどうして新しいサービス?と思うかもしれませんが、AWSとしては、利用者に選択肢を与えることで、より顧客の成功に貢献できると思っているのではと。

参考資料

Amazon MQ – Managed Message Broker Service for ActiveMQ

Apache ActiveMQ

Cross Language Clients and Protocols

Amazon SQSとJMS実装のActiveMQをJDNIで切り替えてみる