re:Invent 2024: AWS・ASFが語るApache ActiveMQ 6の新機能と今後の展望
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Harnessing Apache ActiveMQ: ActiveMQ 6.x features and roadmap (OPN311)
この動画では、オープンソースのメッセージブローカーであるApache ActiveMQの最新動向について、AWSのJules GraybillとApache Software FoundationのJB Onofréが解説しています。ActiveMQの歴史から始まり、2023年にリリースされたActiveMQ 6の新機能、特にJMS 2.0とJakarta Messaging 3.1への対応について詳しく説明されています。また、Amazon MQ for ActiveMQの新機能であるクロスリージョンデータレプリケーションについても紹介され、Split Brain問題への対処方法など技術的な詳細が語られています。さらに、2025年末までのロードマップとして、Replicated KahaDBの実装やSpring依存関係の削除を含むActiveMQ 7のリリース計画についても言及されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Apache ActiveMQの概要と登壇者紹介
おはようございます。re:inventの3日目へようこそ。皆様、体調管理はできていますでしょうか。十分な休息と、カフェインを補給して、オープンソースソフトウェアについての話題に備えていただければと思います。本日は特に、Apache ActiveMQの興味深い新展開についてお話しさせていただきます。ActiveMQは現在、最も広く使用されているオープンソースのメッセージブローカーの一つであり、私たちAmazonもその開発に深く関わっています。私はJules Graybillと申します。AWSのメッセージングサービスを統括しており、これにはActiveMQとRabbitMQを含むオープンソースメッセージブローカーのマネージドサービスであるAmazon MQも含まれています。
本日は、私のオープンソースにおける役模範の一人である、Apache Software FoundationのJB Onofréにも登壇していただいています。 皆様、おはようございます。JBです。Apache Software Foundationのボードメンバーを務めており、ActiveMQを含む約20から25のApacheプロジェクトでPMCメンバーとして活動しています。 ActiveMQ 6と7について詳しく説明する前に、 まずはActiveMQとは何かを振り返っておくことが重要です。Julesが述べたように、これはメッセージブローカーです。
メッセージブローカーとActiveMQの特徴
では、メッセージブローカーとは実際には何なのでしょうか？メッセージブローカーには様々な特徴がありますが、私にとって最も重要なのは、プロデューサーとコンシューマーの分離です。この分離によって、多くの異なるユースケースが可能になります。メッセージのプロデューサーは、コンシューマーがどこにいるのか、誰なのかを知る必要がありません。ブローカー内の一つの宛先だけを知っていればいいのです。一方、コンシューマーはメッセージがどこから来たのかを知る必要がありません。これは、メッセージブローカーによる一種のman-in-the-middleパターンと言えます。
なぜこれはクライアント・サーバーではなく、ブローカーと呼ばれるのでしょうか？それは、ブローカー内でメッセージに対して高度な機能を適用できるからです。メッセージルーティングを適用できます。あるキューやトピックで受け取ったメッセージを、別の宛先、別のキュー、別のトピックにルーティングできます。例えば、Composite Destinationでは、一つのキューから受け取ったメッセージを複数のキューに転送できます。これがActiveMQがただのメッセージサーバーではなく、ブローカーである理由です。このような論理を適用できるからです。
また、バッファリングも可能です。これは基本的に非同期配信と呼ばれるものです。ブローカー内にメッセージを蓄積し、コンシューマーがメッセージを消費できるようにします。キューを使用するかトピックを使用するかによって、one-to-manyやmany-to-manyなど、異なる消費方法が可能です。使用する宛先によって異なります。ルーティングと同様に、フィルタリングも可能です。このメッセージは誰にも配信したくない場合は実質的に破棄されますし、このメッセージはある条件を満たす場合にのみ配信されるといった設定も可能です。これは、メッセージを消費する際のSelectorと呼ばれる機能です。
最後に、私の意見では、ActiveMQの主要なユースケース、そして最も重要なユースケースの1つはトランザクションに関するものです。プロデューサー側とコンシューマー側の全ての確認応答のおかげで、ブローカーをトランザクションリソースとして扱うことができます。メッセージをプロデュースする際、そのメッセージが正しくプロデュースされ、ブローカーに配信され、ブローカーがそれを処理できる状態になったことを確認できます。何らかの理由で配信されなかった場合、クライアントはそれを認識し、再試行するか別のメッセージを送信することができます。これらがメッセージブローカーの一般的な特徴です。
では、メッセージブローカーとしてのActiveMQについて詳しく見ていきましょう。ActiveMQとは何なのでしょうか？まず第一に、これは標準規格に基づいています。JMSのようなJava標準や、AMQPやMQTTのような事実上の標準規格などです。ActiveMQのすべての機能は標準規格に基づいており、私たちはその仕様を実装しています。基本的に、これはメッセージランタイムです。ActiveMQには2つの主要な部分があります：ブローカー部分とクライアント部分です。
ブローカー部分は、マシン上で直接実行できます - ActiveMQを起動するだけで、すぐに使用できるブローカーが用意されます。また、クライアント部分も提供しており、JMSとJMS APIを使用する場合は単純なActiveMQ Connection Factoryかもしれませんし、PythonやRustなどの他の言語でSTOMPプロトコルを使用したい場合は、より高度なクライアントになるかもしれません。
マルチトランスポートに対応しており、これはクライアントとブローカー間、あるいはネットワーク接続を実装する際のブローカー間での通信方法が様々なプロトコルをサポートしているということです。例えば、VMを使用できます。これは、ActiveMQをアプリケーションに組み込んで、ネットワークを使用せずにJVMを直接使用してメッセージを配信できることを意味します。これにより、クライアントとブローカー間の便利な切断可能な接続が提供されます。TCPとSSLは、クライアントとブローカー間の通信で主に使用されるものです。また、HTTPやWebSocketもサポートしており、STOMPはWebSocketをベースにしています。
マルチプラットフォームに対応しており、これはブローカーがJVMだけを必要とすることを意味します。ActiveMQブローカーにはネイティブコードが含まれていないため、JVMがあるマシンで直接実行できます。また、言語サポートの面でもマルチクライアントです。Java、C、C#、C++などどの言語を使用していても、ActiveMQで使用できるクライアントが用意されています。これらのクライアントは、NMS（ActiveMQのCクライアント）のようにActiveMQが直接提供する場合もあれば、Connection Factoryを使用してJMSでJavaで提供される場合もあります。
ActiveMQの歴史と最新バージョンの特徴
ActiveMQの歴史を振り返ってみますと、2004年にLogicBlazeという小さな会社からスタートしました。 当時、私たちはJMSブローカーを実装したいと考えていました。IBM MQは当時も今も非常に人気がありましたが、私たちはオープンソースで何かを作りたいと考えていました。LogicBlazeでは、当時バージョン1.0だったJMS APIの実装からスタートしました。2005年には、 ActiveMQ 3を作り上げました。バージョン1と2は主にプロトタイプで、本番環境での使用には適していませんでしたが、ActiveMQ 3は初めての本番環境対応のブローカーでした。このActiveMQ 3は Apache Software Foundationに寄贈され、2005年にApacheインキュベーターでActiveMQプロジェクトが始まりました。このバージョンではブローカーに2つの大きな変更が加えられました：KahaDBの前身となるメッセージの永続化機能で、ファイルシステムにメッセージを保存する方法と、パフォーマンス、トランザクション、関連機能を備えたブローカーのセキュリティ機能です。
2006年には、 ActiveMQ 3を改良してメッセージグループやバーチャルトピックなどの新機能を追加したActiveMQ 4を作りました。ActiveMQ 4は、金融企業や産業界での採用が進み、ユーザーから大きな支持を得て、本番環境で最も使用された主要バージョンだったと思います。私の意見では、ActiveMQ 5はプロジェクトの重要なマイルストーンでした。これは機能面で完全なブローカーとなり、KahaDBを導入しました。KahaDBは、それまでに作成してきたすべてのメッセージストアの経験から生まれ、より高性能なメッセージストアを目指したものでした。さらに、ActiveMQ 5は、Apacheのインキュベーターからactivemq.apache.orgという形でトップレベルプロジェクトに昇格した時期でもあり、プロジェクトにとって重要な意味を持っていました。これは2007年のことで、かなり昔のことですが、私たちは今でもApache ActiveMQへの貢献を続けています。
過去には、ActiveMQトップレベルプロジェクトに新しいブローカーであるArtemisが加わりました。Artemisが Apache Software Foundationに寄贈される前、私たちは独立したトップレベルプロジェクトとして設立するか、ActiveMQエコシステムの一部として運営するかなど、さまざまな選択肢を検討しました。結果として、ArtemisをActiveMQエコシステムに加えることを決定しました。現在、ActiveMQには2つのブローカーがあります：ArtemisとActiveMQ Classicです。これは競合関係ではなく、基本的に同じ機能を持つ異なるブローカーなので、どちらかを選んで使用することができます。2つのコミュニティとブローカーは一緒に維持されており、2023年も引き続き開発を続けています。
昨年、私たちはActiveMQ 6をリリースしました。これが今日のトークの目的です。私の意見では、ActiveMQ 6はActiveMQ 5と比べて大きな進歩を遂げています。ActiveMQ 6はJMS 2.0とJakarta Messaging 3.1 に準拠しています。これがActiveMQ 6の主な焦点でした。ActiveMQ 5はJMS 1.1のみの対応でしたが（5.18は1.1と2.0の両方をサポート）、JMS 2.0 APIを完全にサポートすることを目指しました。また、ActiveMQ 6では新機能も追加され、新しいJVMバージョンのサポートも含まれています。JDK 17以上からJava 23まで実行可能です。
ActiveMQ 6では、ブローカー内の依存関係を更新しました。内部的にはSpringとJettyを引き続き使用しており、SpringとJettyの最新バージョンにアップグレードしました。また、ActiveMQ内で直接Enterprise Integration Patternsを実装する方法であるApache Camel 4にもアップグレードしました。ActiveMQ 6では、クラウドデプロイメントに重点を置き、Dockerイメージが利用可能になりました。セキュリティと可観測性の改善に関してActivMQの内部に大きな更新を加え、新しいMBeans、Prometeus exporter、OpenTelemetry機能をブローカー内に追加して、内部で何が起きているかをより詳細に把握できるようにしました。ActiveMQの目的はUIやダッシュボードを提供することではなく、インフラストラクチャに必要なメトリクスとデータを提供し、必要なダッシュボードを作成できるようにすることです。Role-based access controlをサポートする新しいプラグインを提供してセキュリティを向上させ、KahaDBとトランザクションに焦点を当てたパフォーマンスの改善も行いました。
最も重要な点はJMS 2.0についてです。 JMS 2.0の第一の目的は、APIを大幅にシンプル化することでした。JMS 1.1では、単純なメッセージをブローカーに送信するだけでも、たくさんのボイラープレートコードを書く必要がありました。例えば、Connection Factoryを使用する場合、Connectionを作成し、Sessionを作成し、Acknowledge modeを定義し、Producerを作成し、Text Messageを作成して、最後にメッセージを送信する必要がありました。これは非常に長く複雑で、多くのボイラープレートコードが必要でした。JMS 2.0では、わずか2行で済みます：JMSContextを作成し、Producerをインラインで作成してペイロードを直接送信するだけです。 この簡素化は、例外処理を含む他のJMSの側面にも及んでいます。
JMS 2.0では例外処理がはるかに簡単になりました。JMSRuntimeExceptionがunchecked exceptionとなったため、至る所でtry-catchブロックを書く必要がなくなりました。これにより、try-catchブロックを everywhere に実装する必要なく例外をすばやく簡単にキャッチできるようになり、アプリケーションロジックの開発が大幅に改善されました。 この簡素化はAPIにも及んでいます。メッセージ送信時に、TextMessage、MapMessage、ByteMessageなどでラップする必要なく、ペイロードを直接送信できるようになりました。例えば、Producerを作成し、同じメソッドの一部としてペイロードを直接送信できます。
アプリケーションでメッセージを消費する方法には、主に2つの方法があります。クライアントにメッセージがディスパッチされるのを待つブロッキング方式のreceive messageメソッドを使用するか、Message Listenerを使用する方法です。JMS 1.1では、onMessageメソッドの実装が必要なMessageListenerインターフェースを使用していました。ロジック自体は複雑ではありませんでしたが、このインターフェースを作成してonMessageメソッドを実装する必要があったため、かなりのボイラープレートコードが生成されていました。JMS 2.0では、Lambda式を直接使用できるためより簡単になりました。Consumerを作成し、Message Listenerを設定して、そこでLambdaを実装するだけです。ブローカーのActiveMQがクライアントにメッセージをディスパッチし、メッセージがディスパッチされるとアプリケーションが反応します。
Jakarta Messaging 3.1では、APIは基本的に同じままですが、名前空間がjavax.jmsからjakarta.jmsに移行するという大きな変更が1つありました。これは、アプリケーション全体でこれらの参照を更新する必要があることを意味します。ActiveMQ 5.18では、javax.jmsクライアントとjakarta.jmsクライアントの両方からのメッセージをサポートすることを決定しました。これはユーザーがJMS 1.1からJMS 2.0に移行する時間を確保するために5.18で実装しました。しかし、ActiveMQ 6では、新しい標準APIとしてJakarta JMSのみをサポートしています。
Jakarta Messagingではいくつかのクリーンアップと新機能も導入されました。例えば、Producerでdelivery delayを実装できるようになり、2秒後や20ミリ秒後など、将来の時間にメッセージ配信をスケジュールできるようになりました。また、ActiveMQで実装したもう一つの改善点は非同期プロダクションです。通常、Producerのsendメソッドはブロッキングであり、アプリケーションはブローカーからの確認応答を待つ必要がありました。今では、sendAsyncを使用することで、確認応答の処理を後で別のスレッドに委譲できるようになり、スループットが大幅に向上しました。これらが、新しいJDKバージョンのサポートとともに、ActiveMQ 6で実装した主な変更点です。ありがとうございます、JB。ここで数分間、Amazon MQ for ActiveMQサービスと、クラウドやAWS上でActiveMQを実行する際にできることについて説明させていただきます。
Amazon MQ for ActiveMQサービスとクロスリージョンデータレプリケーション
Amazon MQ for ActiveMQサービスは、オープンソース製品のマネージドサービスです。AWSが提供する多くのマネージドサービスと同様に、お客様にとってのメリットは、ActiveMQの運用とセキュリティ、パッチ適用、信頼性、堅牢性に関するベストプラクティスを日々考え続けているチームがいることです。私たちがこれらの作業の重労働を担当することで、お客様は開発者として、そしてアプリケーション開発に集中することができます。
このサービスは2017年にActiveMQをサポートしてローンチしました。 2020年には、もう一つの人気のあるオープンソースメッセージブローカーであるRabbitMQのサポートを追加しました。どちらのブローカーも利用可能で、ブローカーのプロビジョニング、管理、スケーリングに関して、基本的に同じような体験を提供しています。本日のこの場では、最近ローンチした特に興味深い機能について詳しくお話ししたいと思います。 それは、ActiveMQのクロスリージョンデータレプリケーションです。
クロスリージョンデータレプリケーションとは何でしょうか？基本的に、その名の通りの機能です。ブローカーがあり、通常はすべてのプロデューサーやコンシューマーアプリケーション、データベースなどが、この例ではus-east-1という私たちが「プライマリリージョン」と呼ぶ場所で動作していて、それらすべてをus-west-2という「レプリケーションリージョン」または「レプリカリージョン」にクローンしたいというケースです。設定やデータ、状態のすべてを、そのレプリケーションリージョンに継続的にクローンしてレプリケートすることで、必要に応じて、データや状態を失うことなく、ワークロード全体を国を横断して新しいリージョンに移行できるようになります。
私たちはこの機能をActiveMQでサポートしており、今すぐにご利用いただけます。セットアップは非常にシンプルです。ブローカーを実行している状態で、レプリカの作成をリクエストするだけです。現在、北米のリージョンをサポートしています。レプリカは、ブローカーの設定をそっくりそのままコピーします。複数のノードを持つ高可用性ブローカーの場合、すべてのノードのレプリカを作成し、データの移行を開始します。これはウォームスタンバイレプリケーションなので、レプリカリージョン（us-west-2）では、図の線上にある小さなXマークが示すように、プロデューサーやコンシューマーアプリケーションを直接接続することはできません。2つのリージョン間でデータをレプリケートしている間は、常にプライマリリージョン内で、つまり1つのリージョン内で作業を行います。
このレプリケーションは、この機能を構築する際に得た最初の洞察の一つです。メッセージブローカーのデータをどのようにレプリケートするか考えた時、データベースやストリーミングサービスの場合、トランザクションログを取得して別のリージョンにストリームすることでデータを再作成するという、単純なレプリケーションの考え方があります。しかし、メッセージブローカーの場合、プロデューサーがメッセージをキューに入れようと競争し、コンシューマーアプリケーションがキューからメッセージを取り出して確認応答を行い、確認応答されたメッセージは削除されます。そのため、バランスの取れたメッセージブローカーでは、キューが空になっている可能性があります。
私たちが気づいたのは、Brokerにメッセージが届いた後、1秒ほど待機すると、新しいリージョンへの複製が完了する前にそのメッセージが消費され、削除されてしまうことが多いということでした。メッセージが削除されるまでの時間的な余裕を設けるスライディングウィンドウを作成することで、適切に調整すれば、わずかな遅延を導入することによって、実際にはBroker上のメッセージを別のリージョンにより効率的に複製できることを実証しました。これは、この機能をサポートする複製エンジンに実装した機能です。これで、レプリカリージョンのセットアップが完了し、メッセージの複製も行われ、すべてが順調に動作するようになりました。
Amazon MQは、スイッチオーバー時の消費者の優先順位に基づいて、2つの異なるスイッチオーバーモードをサポートしています。1つ目は「Switchover」と呼ばれる計画的なスイッチオーバーイベントで、一貫性を重視するお客様向けに設計されています。Switchoverイベントでは、レプリカリージョンに対して、自身をPrimary Brokerに昇格させるコマンドを発行します。その後、一連のステップが実行されます：us-east-1の現在のPrimary Brokerは接続の受け入れを停止し、既存のProducerとConsumerへの接続を切断します。その後、自身とReplica Broker間のすべてのデータの複製を完了させます。すべてのデータが同期されると、すべてのデータが新しいリージョンに移動されたことが確認できます。Replica Brokerは自身をPrimaryに昇格させ、接続を開放して、接続の受け入れを開始します。
この場合、Replica BrokerがPrimaryに昇格する前に、すべてのデータが確実に移行されていることがわかります。これでus-west-2で運用が開始され、理論的にはデータの一貫性を保ちながら、双方向のスイッチが可能になります。多くのお客様が、この操作を常に実行できることを確認するため、定期的に双方向のスイッチを練習しています。複雑な課題の1つは、PrimaryとReplica Brokerの両方が自身をPrimaryと認識して接続を受け入れる「Split Brain」シナリオを防ぐことです。これが発生すると、2つのBroker間でメッセージキューに解決不可能な差異が生じる可能性があります。メッセージBrokerの使用目的を考えてみてください - 同じコンサートチケットを2人に販売してしまい、そのコンサートで良い思いをさせることができなくなる可能性があります。
Split Brainを防ぐために、2つのBrokerは、ネットワークの輻輳や問題に関係なく、常にどちらがPrimaryであるかを把握している必要があります。これは本質的に「二人の将軍問題」であり、ご存知の方もいるかもしれませんが、論理的に解決不可能な問題です。2つのBroker自体がすべての状況でSplit Brainを効果的に管理できないことがわかっているため、私たちは緩和策を実装しています。クラウドで運用することで、いくつかの利点があります。どのBrokerがPrimaryで、どのBrokerがReplicaであるかの状態を管理する専用のプロセスを用意しています。このプロセスは、Amazon MQ自体が稼働しているよりもはるかに多くのリージョンで実行され、全体的なネットワーク状況に関係なく、1ビットの情報を超高い一貫性で処理します。Brokerは「フェイルクローズ」で動作します - 自身がPrimaryであることを認識できない場合は、Replicaであると判断します。
このシステムにより、Split Brainシナリオは、より大きな問題が発生していることを示唆するほどまでに緩和されています。この1つの状態を慎重に管理することは非常に重要であるため、かなりの技術的工夫とバックグラウンドでの作業が行われています。これは特に2つ目のスイッチオーバーモードである「Failover」にとって重要です。Failoverは、一貫性よりも可用性を重視するお客様向けに設計された計画外のイベントです。Failover時は、リージョン間で完全なネットワーク分断が発生している場合でも、Replica Brokerを昇格させることができます。Replica Brokerは直ちにPrimaryに昇格し、広く分散されたSplit Brain防止システムを使用して、以前のPrimary Brokerを即座に降格させます。このシナリオでは、新しいリージョンに移行されていないメッセージが存在し、それらのメッセージは以前のPrimaryリージョンに保持され、Switchoverで元に戻すことで取り出すことができます。
新しいプライマリブローカーでは、実際にはブローカーが受信していないメッセージを、コンシューマーが確認しようとする可能性があります。維持すべき状態が多く、解決すべき複雑な問題が存在します。これらすべてのエッジケースを頭で考えて対処しようとするのは適切な解決策ではありません。私たちは複数のラウンドの正式な検証方法を使用して、フェイルオーバーを実行し、同期できない状態で状態を移行する際にも、メッセージの損失がなく、データの損失がなく、状態の損失がないことを保証しています - すべてが復元可能なのです。
オープンソース製品のActiveMQを使用して、これを自分で実装することもできますが、お勧めはしません。これは、グローバルスケールでのデプロイが可能で、かつこれらの問題に取り組むことができるクラウドプロバイダーと協力することで、このような要件を持つメッセージブローカーの大規模デプロイメントに大きな価値を付加できるケースの一つです。 サービスで体験できることについて簡単にお話しします。現在、ActiveMQの2つのバージョンをサポートしています：JMS 1.1に焦点を当てた5.17と、JBが言及した移行を支援するハイブリッドバージョンの5.18です。来年半ばまでには、サービス上でActiveMQ 6をサポートする予定です。そのため、現在JMS 2.0のワークロードをお持ちの場合、その時点でワークロードの移行をサポートできるようになります。
オープンソースプロジェクトへの参加と貢献は、チームの主要な優先事項です。私たちは、様々なワークロードを持つActiveMQを大規模に運用することについて多くのことを学んでおり、それらの学びを可能な限りアップストリームに貢献することを優先しています。例えば、このクロスリージョンデータレプリケーションでは、同期前に削除されていたメッセージの送信を回避できるスライディングウィンドウを使用したメッセージ圧縮を開発しました。これはActiveMQのデータプレーンで実装可能で、この機能の一部を、うまく機能することが分かっている方法で実装できるよう、ブローカーへの実装を進めています。
私たちの貢献は、学んだことがある分野と、お客様が機能を要求する分野の両方に焦点を当てています。JMS 2.0とJakarta 3.1は明らかに大きな優先事項です。認証と認可は、おそらく2番目によく要求される機能です。ユーザーはLDAPやその他のエンタープライズスケールの認証およびアイデンティティメカニズムを使用したいと考えています。IAMはAWSを全面的に利用しているユーザーにとってはうまく機能しており、ユーザーとアクセス認証をよりシームレスに管理できるようにサポートを改善できることも分かっています。JBは、ネイティブクラスタリングとネイティブ分散Apache ActiveMQに関するいくつかのアイデアについて話をしますが、私たちはその開発に関わることをとても楽しみにしています。ここでJBに戻して、プロジェクトで何が起きているかについて話してもらいましょう。
ActiveMQの将来計画とコミュニティ参加の呼びかけ
ありがとう、Jules。Amazon MQによってActiveMQがパワーアップしているのを見るのは素晴らしいことです。また、ActiveMQプロジェクトとコミュニティへの多大な貢献に感謝します。 これはActiveMQ 6以降について計画している内容のハイレベルなロードマップです。コミュニティ内でまだ完全な合意は得られていませんが、これらは私たちが議論している事項です。実現する可能性は高く、タイムラインは異なるかもしれませんが、まさにこれがActiveMQで起こることです。 現在、私たちはActiveMQ 6.3を使用しています。来年のQ1かQ2に、完全なJMSとJakarta Messagingのサポートを備えたバージョン6.5をリリースする予定です。現在、Jakarta Messagingのいくつかの機能をまだサポートしていないためです。具体的には、遅延配信や共有コンシューマーについて考えています。
ActiveMQ 6.5では、JMS 2.0のサポートに関する作業が必要で、その後6.6がリリースされる予定です。 Julesが言及したように、バージョン6.6では主に認証と認可に焦点を当てていきます。現在、追加の認証・認可モデルをサポートする唯一の方法は、独自のプラグインを提供することです。ActiveMQでは、設定するだけで必要な認証が得られるプラグインを提供すべきです。OAuth 2.0やOIDC、その他の類似のバックエンドソリューションを検討しています。Amazon MQチームと協力して、新しい認証と認可モデルをブローカーに導入していく予定です。
特に私が楽しみにしている機能の1つが、バージョン6.7でプレビューとベータ版として提供される予定のReplicated KahaDBです。Replicated KahaDBについて説明させていただきます。現在、複数のブローカーを一緒に使用する場合、1つのブローカーがロードバランサーとして機能し、負荷に応じて異なるブローカーにメッセージを転送することができます。クライアントは任意のブローカーに接続してメッセージの送受信が可能です。ただし、1つのブローカーが故障すると、そのブローカー内の保留中のメッセージは、再起動するまで失われてしまいます。つまり、クライアントはActiveMQクライアントのフェイルオーバー機能を使用して別のブローカーに再接続できますが、保留中のメッセージはすべて失われてしまうのです。
Replicated KahaDBでは、1つのブローカーがメインメッセンジャーとして機能し、各メッセージをフォロワーブローカーに複製することを目指しています。障害が発生した場合でも、他のブローカーに複製されたメッセージは利用可能なままで、クライアントはトランザクションや確認応答を失うことなく、メッセージの消費と生成を継続できます。これはクラウドのコンテキストで特に有益です。Amazon MQを使用すれば、メッセージレプリケーションを使用して自動的に同期する複数のブローカーをスピンアップできるからです。これがActiveMQ 6.7の計画で、パフォーマンスとトランザクションの面での課題を認識しているため、まずはReplicated KahaDBをベータ版として提供する予定です。
ActiveMQ 7に向けて、2つの重要な変更が計画されています。1つ目は、ブローカーからSpringの依存関係を削除することです。現在、ActiveMQはSpringによって動作しています - ActiveMQ XMLを見ると、基本的にSpring Beans XMLです。これは依存性の注入とスキーマ管理には便利ですが、Springとそのメリット・デメリットに依存しているため課題があります。Springで問題が発生した場合、迅速にアップデートをリリースする必要があります。Apache Camelで使用しているようなシンプルなサービスプロバイダーインターフェースローダーや、Quarkusなどの他のフレームワークの活用など、さまざまな代替案を検討しています。
2つ目の大きな変更は、ActiveMQ 7でReplicated KahaDBが本番環境で使用可能になることです。スケジュールについては、ActiveMQ 7は2025年末より前にはリリースされないと予想しています。 Apache ActiveMQとコミュニティに参加したい方は、activemq.apache.orgをご覧ください。SlackまたはEメールで私に連絡していただければ、喜んでサポートやメンタリングをさせていただきます。サービスに関する情報はAWSで確認でき、Amazon MQ for ActiveMQで検索できます。
ご質問がございましたら、お気軽に私たち両名にお声がけください。何らかの形で参加したい、貢献したいとお考えの方がいらっしゃいましたら、喜んでご相談させていただきます。講演後も会場に残っておりますので、インフォーマルなQ&Aでお話しできればと思います。ご参加いただき、誠にありがとうございます。お願いがございます。セッションのアンケートにぜひご回答ください。私たちは皆様からのフィードバックを真摯に受け止めており、皆様にとって最も重要なコンテンツを提供できるよう努めております。 皆様、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion