AMQ Broker in Action: Assessing and Enhancing Messaging Architecture (Part 1)

Assessing an AMQ Broker is critical for ensuring reliable message handling, high performance, and optimized resource usage.

Red Hat AMQ Broker is a reliable messaging broker based on Apache ActiveMQ. This series will cover the main topics of an AMQ Broker assessment.

Red Hat AMQ Broker is a product based on the open-source project ActiveMQ Artemis by Apache. It is a high-performance messaging broker that uses a journal for message persistence and supports different messaging protocols, including CORE (the native protocol), MQTT (Message Queuing Telemetry Transport), and AMQP (Advanced Message Queuing Protocol). For more details about its features, I recommend the Red Hat documentation.

Assessing an AMQ Broker is critical for ensuring reliable message handling, high performance, and optimized resource usage. This article covers the main assessment questions that help to understand the current state of the messaging architecture, how the broker is deployed, which protocols are being used, how much load is being processed, analyzing broker JVM, queues, and message metrics, and more.

Architecture

AMQ Broker can be deployed on any Linux/Windows machine or using a deployment managed by Red Hat’s Operator. Apart from the deployment strategy, AMQ Broker offers flexible deployment options to suit various needs, ranging from single-broker setups to more resilient high-availability clusters.

Main Deployment Strategies

There are two main deployment strategies: on Linux/Windows machines (outside of OpenShift) or inside of OpenShift using Operators.

These two paths can lead to topologies like high-availability deployments (shared-storage, replication, or live-only), clustered deployments without passive nodes, or single-broker deployments.

• Outside OpenShift: The brokers are deployed and managed separately by the Sys Admin who is responsible for configuring the broker.xml by adding the right cluster settings. The following diagram illustrates a typical AMQ Broker deployment outside of OpenShift, managed manually by system administrators.

• Inside OpenShift: Using Operators, the brokers are deployed using the ActiveMQArtemis resource. The cluster size is determined by the number of replicas that will be deployed by the custom resource, and the AMQ Broker Operator automatically generates each broker with the cluster configuration in their broker.xml. Additionally, the operator manages each broker pod, ensuring availability through liveness and health checks.

  The following diagram illustrates a typical AMQ Broker deployment inside OpenShift, managed by Operators and OpenShift Administrators.

Assessment

During an assessment, it is important to understand if the deployed architecture fits the use-case.

Clustered Broker

For instance, to achieve high throughput on OpenShift, the broker should not be clustered because, in a clustered architecture, the broker spends resources synchronizing its state with the rest of the brokers in the cluster. In this case, it is recommended to deploy a single broker or active-passive (high-availability) broker.

Business Domain

Understanding the business domain of the broker is crucial for aligning message processing with business requirements. Segregating brokers by domain can lead to improved resource allocation and risk management, as well as simplify maintenance and scaling. Segregating reduces the risk of bottlenecks in the entire system, and managing a broker with fewer clients, protocols, messages, and queues is much easier for everyone. Smaller brokers can be owned by smaller teams, which splits responsibility and gives ownership across multiple engineers.

High-availability

High-availability (HA) topologies are better options than implementing clusters, which are error-prone due to the complexity of management and message sharing. HA can be deployed on Linux/Windows machines or OpenShift (only supported on 7.12+ versions). It is recommended to use HA deployments because the active and passive brokers share the same journal, and the probability of losing messages due to an outage is very low.

Journal

On OpenShift, the journal cannot be shared in the same way it is on Linux machines because each broker deployment uses its Persistent Volume. Kubernetes does not allow two pods to access the same Persistent Volume.

Therefore, the solution to implement HA on OpenShift is to use a JDBC connection to an external database, with two different broker deployments connecting to the same database. The challenge with this solution is that it introduces a third component (a database) to the system architecture, which also needs to be managed.

In summary, assessing the architecture and deployment strategies of an AMQ Broker is essential for optimal performance and reliability. In the next post, I will explore protocols, queue management, and metrics monitoring to ensure your broker can handle the expected workloads.