Prácticas recomendadas de Amazon MQ para ActiveMQ

Utilice esta sección como referencia para encontrar rápidamente recomendaciones que le permitan maximizar el rendimiento y minimizar los costos al usar agentes de ActiveMQ en Amazon MQ.

No modifique ni elimine nunca la interfaz de red elástica de Amazon MQ

Cuando crea un agente de Amazon MQ por primera vez, Amazon MQ aprovisiona una interfaz de red elástica en la nube privada virtual VPC () de su cuenta y, por lo tanto, requiere una serie de permisos. EC2 La interfaz de red permite al cliente (productor o consumidor) comunicarse con el agente de Amazon MQ. Se considera que la interfaz de red está dentro del ámbito de servicio de Amazon MQ, a pesar de formar parte del de tu cuenta. VPC

aviso

No se debe modificar ni eliminar esta interfaz de red. Modificar o eliminar la interfaz de red puede provocar una pérdida permanente de la conexión entre usted VPC y su agente.

Usar siempre el grupo de conexiones

En un escenario con un único productor y un único consumidor (como el tutorial Primeros pasos: creación de un bróker ActiveMQ y conexión a él), puede usar una sola clase ActiveMQConnectionFactory para cada productor y consumidor. Por ejemplo:

// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);

// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);

// Establish a connection for the consumer.
final Connection consumerConnection = connectionFactory.createConnection();
consumerConnection.start();

Sin embargo, en escenarios más realistas con varios productores y consumidores, puede resultar costoso e ineficiente crear un gran número de conexiones para varios productores. En estos escenarios, debe agrupar varias solicitudes de productor mediante la clase PooledConnectionFactory. Por ejemplo:

nota

Los consumidores de mensajes nunca usan la clase PooledConnectionFactory.

// Create a connection factory.
final ActiveMQConnectionFactory connectionFactory = new ActiveMQConnectionFactory(wireLevelEndpoint);

// Pass the sign-in credentials.
connectionFactory.setUserName(activeMqUsername);
connectionFactory.setPassword(activeMqPassword);

// Create a pooled connection factory.
final PooledConnectionFactory pooledConnectionFactory = new PooledConnectionFactory();
pooledConnectionFactory.setConnectionFactory(connectionFactory);
pooledConnectionFactory.setMaxConnections(10);

// Establish a connection for the producer.
final Connection producerConnection = pooledConnectionFactory.createConnection();
producerConnection.start();

Usar siempre el transporte de conmutación por error para conectarse a puntos de enlace de varios agentes

Si necesita que su aplicación se conecte a puntos de enlace de varios clientes, por ejemplo, cuando usa un modo de implementación activo/de reserva o cuando migra desde un agente de mensajes local a Amazon MQ, utilice el transporte de conmutación por error para permitir que sus consumidores se conecten con uno de ellos de forma aleatoria. Por ejemplo:

failover:(ssl://b-1234a5b6-78cd-901e-2fgh-3i45j6k178l9-1.mq.us-east-2.amazonaws.com:61617,ssl://b-9876l5k4-32ji-109h-8gfe-7d65c4b132a1-2.mq.us-east-2.amazonaws.com:61617)?randomize=true

Evitar usar los selectores de mensajes

Es posible utilizar JMSselectores para añadir filtros a las suscripciones por temas (para redirigir los mensajes a los consumidores en función de su contenido). Sin embargo, el uso de JMS selectores llena el búfer de filtros del bróker de Amazon MQ, lo que impide que filtre los mensajes.

En general, no permita a los consumidores dirigir los mensajes, ya que, para que el desacoplamiento de consumidores y productores sea óptimo, tanto el consumidor como el productor deben ser efímeros.

Preferir los destinos virtuales a las suscripciones duraderas

Una suscripción duradera puede ayudar a garantizar que el consumidor reciba todos los mensajes publicados en un tema, por ejemplo, tras la restauración de una conexión perdida. Sin embargo, el uso de las suscripciones duraderas también impide el uso de la competencia de consumidores y puede tener problemas de desempeño a escala. Considere la posibilidad de utilizar destinos virtuales en su lugar.

Si utilizas el VPC peering de Amazon, evita que el cliente esté dentro del IPs alcance CIDR 10.0.0.0/16

Si está configurando el VPC peering de Amazon entre la infraestructura local y su agente de Amazon MQ, no debe configurar las conexiones de los clientes con IPs un rango. CIDR 10.0.0.0/16

Desactivar el almacenamiento y el envío simultáneos en colas con consumidores lentos

De forma predeterminada, Amazon MQ optimiza las colas para los consumidores rápidos:

• Se considera que los consumidores son rápidos si pueden mantener el ritmo de los mensajes generados por los productores.

• Se considera que los consumidores son lentos si una cola crea un atasco de mensajes sin confirmar, lo que puede provocar una reducción en el rendimiento del productor.

Para indicar a Amazon MQ que optimice las colas para los consumidores lentos, establezca el atributo concurrentStoreAndDispatchQueues en false. Para ver una configuración de ejemplo, consulte concurrentStoreAndDispatchQueues.

Elegir el tipo de instancia de agente correcto para obtener el mejor desempeño

La velocidad de los mensajes de un tipo de instancia de agente depende del caso de uso de su aplicación y de los siguientes factores:

• Uso de ActiveMQ en modo persistente

• Tamaño del mensaje

• El número de productores y consumidores

• El número de destinos

Descripción de la relación entre el tamaño del mensaje, la latencia y el rendimiento

Dependiendo de su caso de uso, es posible que un tipo de instancia de agente más grande no mejore necesariamente el desempeño del sistema. Cuando ActiveMQ escribe mensajes en un almacenamiento duradero, el tamaño de sus mensajes determina el factor limitante de su sistema:

• Si sus mensajes son más pequeños que 100 KB, la latencia de almacenamiento persistente es el factor limitante.

• Si sus mensajes son más grandes que 100 KB, el desempeño de almacenamiento persistente es el factor limitante.

Cuando se utiliza ActiveMQ en modo persistente, la escritura en el almacenamiento se produce normalmente cuando hay pocos consumidores o cuando los consumidores son lentos. En el modo no persistente, la escritura en el almacenamiento también se produce con consumidores lentos si la memoria del montón de la instancia del agente está llena.

Para determinar el mejor tipo de instancia de agente para su aplicación, recomendamos probar diferentes tipos de instancia de agente. Para obtener más información, consulte Broker instance types y mida el rendimiento de Amazon MQ con JMS el índice de referencia.

Casos de uso para tipos de instancias de agentes más grandes

Hay tres casos de uso comunes cuando los tipos de instancia de agente más grandes mejoran el desempeño:

• Non-persistent mode (Modo no persistente): cuando la aplicación sea menos sensible a la pérdida de mensajes durante la conmutación por error de la instancia del agente (por ejemplo, cuando se emiten resultados deportivos), a menudo es posible utilizar el modo no persistente de ActiveMQ. En este modo, ActiveMQ escribe mensajes en el almacenamiento persistente solo si la memoria acumulada de la instancia del agente está llena. Los sistemas que utilizan el modo no persistente pueden beneficiarse de una mayor cantidad de memoria y una red cada vez más veloz CPU disponibles en los tipos de instancias de broker más grandes.

• Fast consumers (Consumidores rápidos): cuando hay consumidores activos disponibles y el indicador concurrentStoreAndDispatchQueues está habilitado, ActiveMQ permite que los mensajes fluyan directamente del productor al consumidor sin enviar mensajes al almacenamiento (incluso en modo persistente). Si su aplicación puede consumir mensajes rápidamente (o si puede diseñar sus consumidores para que lo hagan), puede beneficiarse de un tipo de instancia de agente más grande. Para permitir que la aplicación consuma mensajes más rápidamente, añada subprocesos de consumo a las instancias de aplicación o escálelas vertical u horizontalmente.

• Batched transactions (Transacciones por lote): cuando se utiliza el modo persistente y se envían múltiples mensajes por transacción, se puede obtener un mayor rendimiento general de los mensajes utilizando tipos de instancia de agente más grandes. Para obtener más información, consulte la sección sobre la necesidad de usar transacciones en la documentación de ActiveMQ.

Elegir el tipo de almacenamiento de agente correcto para obtener el mejor rendimiento

Para aprovechar la alta durabilidad y la replicación en varias zonas de disponibilidad, utilice AmazonEFS. Para aprovechar la baja latencia y el alto rendimiento, usa AmazonEBS. Para obtener más información, consulte Storage.

Configurar la red de agentes correctamente

Al crear una red de agentes, configúrela correctamente para su aplicación:

• Enable persistent mode (Habilitar modo persistente): dado que cada instancia de agente (en relación con sus pares) actúa como un productor o un consumidor, las redes de agentes no proporcionan replicación distribuida de mensajes. El primer agente que actúa como consumidor recibe un mensaje y lo mantiene en almacenamiento. Este agente envía una confirmación al productor y reenvía el mensaje al siguiente agente. Cuando el segundo agente confirma la persistencia del mensaje, el primer agente elimina el mensaje.

  Si se deshabilita el modo persistente, el primer agente confirma al productor sin mantener el mensaje en almacenamiento. Para obtener más información, consulte Replicated Message Store y What is the difference between persistent and non-persistent delivery? en la documentación de Apache ActiveMQ.

• Don't disable advisory messages for broker instances (No desactivar mensajes de aviso para instancias del agente): para obtener más información, consulte Mensaje de aviso en la documentación de Apache ActiveMQ.

• Don't use multicast broker discovery (No utilice detección del agentes mediante multidifusión): Amazon MQ no admite la detección de agentes mediante multidifusión. Para obtener más información, consulte What is the difference between discovery, multicast, and zeroconf? en la documentación de Apache ActiveMQ.

Para evitar los reinicios lentos, recupere las transacciones XA preparadas

ActiveMQ admite transacciones distribuidas (XA). Saber cómo procesa ActiveMQ las transacciones XA puede ayudarle a evitar tiempos de recuperación lentos cuando se reinicia el agente y conmutaciones por error en Amazon MQ.

Las transacciones XA preparadas sin resolver se repiten en cada reinicio. Si estas permanecen sin resolver, su número irá creciendo con el tiempo, lo que aumentará considerablemente el tiempo necesario para iniciar el agente. Esto afecta al tiempo de reinicio y de conmutación por error. Debe resolver estas transacciones con una instrucción commit() o rollback() para que el rendimiento no se degrade con el paso del tiempo.

Para supervisar las transacciones de XA preparadas no resueltas, puede utilizar la JournalFilesForFastRecovery métrica de Amazon CloudWatch Logs. Si este número aumenta o es sistemáticamente mayor que 1, debería recuperar sus transacciones sin resolver con código similar al que se incluye en el siguiente ejemplo. Para obtener más información, consulte Quotas in Amazon MQ.

El siguiente código de ejemplo recorre las transacciones XA preparadas y las cierra con un rollback().

import org.apache.activemq.ActiveMQXAConnectionFactory;

import javax.jms.XAConnection;
import javax.jms.XASession;
import javax.transaction.xa.XAResource;
import javax.transaction.xa.Xid;

public class RecoverXaTransactions {
    private static final ActiveMQXAConnectionFactory ACTIVE_MQ_CONNECTION_FACTORY;
    final static String WIRE_LEVEL_ENDPOINT =
            "tcp://localhost:61616";;
    static {
        final String activeMqUsername = "MyUsername123";
        final String activeMqPassword = "MyPassword456";
        ACTIVE_MQ_CONNECTION_FACTORY = new ActiveMQXAConnectionFactory(activeMqUsername, activeMqPassword, WIRE_LEVEL_ENDPOINT);
        ACTIVE_MQ_CONNECTION_FACTORY.setUserName(activeMqUsername);
        ACTIVE_MQ_CONNECTION_FACTORY.setPassword(activeMqPassword);
    }

    public static void main(String[] args) {
        try {
            final XAConnection connection = ACTIVE_MQ_CONNECTION_FACTORY.createXAConnection();
            XASession xaSession = connection.createXASession();
            XAResource xaRes = xaSession.getXAResource();

            for (Xid id : xaRes.recover(XAResource.TMENDRSCAN)) {
                xaRes.rollback(id);
            }
            connection.close();

        } catch (Exception e) {          
        }
    }
}

En un escenario real, puede comparar sus transacciones XA preparadas con las del administrador de transacciones XA. A continuación, puede decidir si tratar cada transacción preparada con una instrucción rollback() o commit().