amazon web services - receive - SQS vs RabbitMQ

amazon mq (3)

Necesito crear una cola para procesar. La cola en sí es relativamente de bajo volumen. Puede haber alrededor de 1,000 escrituras por hora. La ejecución de cada tarea puede demorar aproximadamente un minuto cada una, y se procesan casi tan pronto como el elemento se agrega a la cola.

¿Hay alguna razón por la que desee implementar RabbitMQ en lugar de algo comercial como Amazon SQS? ¿Cuáles son algunas razones por las que una aplicación necesitaría su propio sistema de colas en lugar de algo como SQS?

De hecho, utilicé ambos en un entorno comercial razonable.

La respuesta breve es que, a menos que haya casos de esquina específicos, es mejor optar por AWS SQS. (Puede saltar al final para un resumen simple)

Codificación (empate): RabbitMQ y AWS SQS tienen bibliotecas establecidas y muchos ejemplos.

Tiempo de espera de visibilidad (SQS): una cosa que ofrece SQS RabbitMQ es una noción más amplia de tiempo de espera de visibilidad. En RabbitMQ, si un consumidor muere antes de que llegue, los mensajes se vuelven a poner en la cola. Pero SQS tiene una noción más amplia de tiempo de espera de visibilidad que no está vinculada a un llamador específico. Para que pueda comenzar una unidad de trabajo, establecer la visibilidad con un gran tiempo de espera (hasta 12 horas), desconectarse, hacer que otro trabajador termine y acéptelo. En mi diseño, aprovechamos esto ampliamente y eliminamos el servicio / almacenamiento adicional para administrar cargas útiles potencialmente grandes ''en progreso''.

Manejo de letra muerta (RabbitMQ - por una ''liebre'') SQS proporciona la entrega básica de letra muerta en lo que llaman "Política de re-manejo" que descarga mensajes en la Cola de letra muerta (solo otra cola). Es básico y solo tiene una noción de conteo de mensajes. RabbitMQ tiene Intercambios de letras muertas que proporcionan mensajes que se envían int DLE cuando caducan. Pero esto es algo discutible ya que la idea de "Si no está viendo que sus servicios y mensajes caducan, entonces aterrizará en el DLE". Es una pequeña victoria para RabbitMQ, ya que encuentro que el argumento es contrario a la intuición. ¿Por qué monitorearías tu cola y no tus servicios? (En todo caso, es al revés)

Administración (SQS): no hay administración a SQS. Solo paga por las llamadas a la API. Los equipos de AWS manejan todos los dolores de cabeza habituales, como parches de seguridad del sistema operativo / aplicación, escala (agregar más nodos), disco. También cumple con FedRamp (para uso del gobierno). Es realmente un sistema de ''configuración y olvido''. Donde, como RabbitMQ, requiere parches de servicio / sistema operativo habituales, AMI, agrupamiento, refuerzo de seguridad, etc. Si bien es extremadamente raro, los AMI pueden fallar o, a veces, deben moverse, por lo que es necesario agruparlos fuera de la caja. SQS elimina todos esos dolores de cabeza.

COSTO (SQS): una sola llamada API de SQS puede incluir ''lotes de hasta 10 mensajes / tamaño de 256k'' y ''sondeo largo'' puede reducir drásticamente el costo. Además, existen estrategias como la compresión de mensajes para empujar docenas (algunos afirman que cientos o más) de mensajes se pueden enviar en una sola carga útil para reducir aún más los costos. Y esto es antes de considerar el tiempo que las personas pasan monitoreando / parcheando / arreglando problemas. SQS también es ideal para ''proyectos de poc'', ya que si está inactivo, no hay costo.

FIFO (TIE): en 2016, AWS introdujo el soporte FIFO a un costo adicional de ~ $ 0.01 / millón de llamadas API ($ 0.05 vs $ 0.04 por millón de API todo, antes de los descuentos). Puedes elegir usar FIFO o no. Para los que no son FIFO, raramente vemos mensajes duplicados.

Almacenamiento (SQS): AWS no cobra por el almacenamiento, pero tiene un límite de 14 días. En RabbitMQ, tendrá que asignar, expandir y administrar el espacio en disco que requiere una capacidad de almacenamiento máxima más almacenamientos intermedios adicionales. Es solo más dolores de cabeza.

Métricas (SQS): SQS proporciona métricas listas para usar. Y si bien podría agregarlos a AWS, es solo más trabajo.

Desarrollo local (empate): a las tiendas más modernas les gusta tener un ambiente local. Hay varias opciones que permiten los acopladores de RabbitMQ y SQS ahora.

Alto rendimiento / mensaje muy grande (RabbitMQ - más o menos) A medida que presiona SQS> 1000 solicitudes / seg, la latencia de SQS aumentará. Hay varias estrategias para evitarlo. Pero considero que estos casos son extremadamente raros, ya que la mayoría del trabajo puede dividirse en múltiples colas. Pero para este tipo de casos donde se requieren 100k / seg, creo que Kafka es mejor. (También utilizamos Kafka en mi trabajo) Es raro tener una sola unidad de trabajo que requiera más de 1000 solicitudes / segundo con baja latencia. * Vea más abajo para esta explicación

Resumen: Si va a estar en AWS y dispuesto a casarse con AQS, entonces SQS es obvio. Pero debe seguir leyendo ya que hay cosas importantes a considerar.

La estrategia clásica para RabbitMQ (y otras colas) es crear varios tipos de colas optimizadas para ciertos tipos de trabajo. Luego, ajuste cada una de estas colas y agrupe trabajos similares en un pequeño número de estas (a menudo muy grandes) colas. Dado que SQS no tiene sobrecarga administrativa, en realidad es mejor asignar una cola dedicada para cada trabajo. Al hacerlo, permite la escala, pero también elimina la saturación de la cola (ofende el trabajo saturando la cola y ahogando a otros trabajadores), una mejor visión del trabajo (métricas predeterminadas) y demás.

La nueva estrategia ha permitido a mis equipos tener una mejor visión de cómo se distribuye el trabajo. Atrás quedaron los días de ''actualizar la instancia para más carga''. En el pasado, veíamos un gran aumento inexplicable que causaría efectos secundarios a otros servicios o simplemente adivinaba que los números acumulativos parecen correctos ''. Ahora que el tráfico está separado, en realidad descubrimos muchos problemas que pasaron desapercibidos antes y podemos explicar claramente cuánto tráfico va a dónde. Y si bien es muy posible implementar métricas y herramientas, SQS proporciona todo esto de forma inmediata.

Todavía hay grandes casos en los que RabbitMQ debería considerarse seriamente

- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff - Messages that needs to be in the same work stream for > 14 days - Very large messages that has very low latency requirements with it - Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option - Large volume of data for a single pipeline that can''t be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.

Para empezar, Amazon SQS es una pseudo-cola, lo que significa que la entrega de cada mensaje (si llega a la cola) está garantizada, pero no de una manera FIFO, que generalmente ocurre en una cola.

Si el orden de los mensajes es importante para usted y desea que la cola funcione de manera FIFO, la documentación de Amazon SQS indica que debe manejar esto en la lógica de su aplicación, ya que los mensajes de Amazon SQS llegarán fuera de secuencia.

En comparación con esto, que yo sepa, puede implementar colas de trabajo en RabbitMQ. Si eso le impide implementar la secuenciación de mensajes en cola a nivel de aplicación, esta sería una opción más preferible.

Aquí hay algunos factores para ayudarlo a decidir cuál elegir:

Secuencia de mensajes en cola como se mencionó anteriormente.
Puede configurar su propio servidor con RabbitMQ pero no en el caso de Amazon SQS, por lo que el costo se involucra aquí.
La configuración de su propio servidor requerirá un buen conocimiento del tema para que no deje ningún rincón intacto. Este no es el caso con Amazon SQS, ya que es bastante rápido para comenzar.
Su propio servidor RabbitMQ significa costos de mantenimiento en el futuro, lo que no es el caso con Amazon SQS.

Actualizaciones:

Amazon SQS ahora admite colas FIFO.

SQS sería mi preferencia sobre RabbitMQ, aquí está la razón.

SQS es un servicio gestionado. Por lo tanto, no tiene que preocuparse por los aspectos operativos de la ejecución de un sistema de mensajería, incluida la administración, la seguridad, la supervisión, etc. Amazon lo hará por usted y le brindará asistencia si algo sale mal.
SQS es elástico y puede escalar a velocidades / volúmenes muy grandes (ilimitado según AWS;))
La disponibilidad de SQS tiene muchos 9 y está respaldada por Amazon, que es una cosa menos de la que preocuparse en su aplicación.

Sin embargo, RabbitMQ podría proporcionar tiempos de respuesta más rápidos para los put and gets, generalmente en 10s de miles de TPS de mis pruebas. Para que SQS proporcione ese tipo de rendimiento, tendrá que escalar horizontalmente con varias instancias. Entonces, si está buscando menos de 5 ms, RabbitMQ podría ser una opción a considerar porque he visto cerca de 20 ms-30 ms de tiempo de mis pruebas de SQS en 1000s de TPS, que es un poco más alto que RabbitMQ.

Acabamos de trasladar nuestra infraestructura de mensajería de ActiveMQ a SQS y no podemos estar más felices. Hemos encontrado que es más barato que mantener nuestro propio clúster ActiveMQ en la nube.

¡Espero que esto ayude! Háganos saber cómo va.