Categoría: Mensajería
RabbitMQ gestionado en vuestra cuenta: colas fiables, clúster y actualizaciones
Vuestro broker de mensajes en clúster, con colas que sobreviven a la caída de un nodo, alarmas que se ven venir y actualizaciones sin sobresaltos, en vuestra cuenta y en código.
- Dónde se monta
- En vuestra cuenta, a vuestro nombre
- Copias
- Con restauración probada
- Actualizaciones
- Planificadas y documentadas
- Licencia
- Open source, MPL 2.0
En resumen
RabbitMQ es un broker de mensajes de código abierto que reparte trabajo entre aplicaciones mediante colas. Gestionarlo es responder de que ningún mensaje se pierda y de que las colas no se atasquen. Montamos un clúster de tres nodos con colas quorum, vigilamos memoria, disco y colas acumuladas, y planificamos las actualizaciones, en máquinas virtuales o en Kubernetes con su operador.
¿Qué nos encargamos de mantener?
RabbitMQ suele dar guerra en dos momentos: cuando un consumidor deja de funcionar y las colas crecen hasta disparar la alarma de memoria, y cuando toca actualizar una versión que lleva años sin tocarse. Nos encargamos de que lo primero avise con tiempo y de que lo segundo sea un procedimiento ensayado.
Clúster
Número impar de nodos: las colas quorum necesitan mayoría, y con tres el clúster aguanta la caída de uno.
Colas
Límite de entregas y cola de mensajes muertos, para que un mensaje que siempre falla no se reintente sin fin.
Alarmas
La alarma de memoria salta por defecto al 40 % de la RAM y bloquea a todos los productores: la ajustamos al nodo real.
Métricas
Mensajes entregados y sin confirmar por consumidor: lo primero que miramos cuando una cola crece.
Accesos
Nunca el usuario guest: un usuario y un vhost por aplicación, con permisos solo sobre sus colas.
Actualizaciones
Todos los feature flags activados antes de cambiar de versión; si falta alguno, el nodo nuevo no arranca.
¿Qué arquitectura recomendamos?
Para producción, un clúster de tres nodos, porque las colas quorum necesitan mayoría para seguir funcionando: con tres, aguanta la caída de uno. Las aplicaciones se conectan a través de un balanceador o de una lista de nodos, publican con confirmaciones del broker y consumen con acuse manual, para que un mensaje no se dé por entregado hasta que se ha procesado. En Kubernetes usamos el operador oficial de RabbitMQ, que declara el clúster, los usuarios y las colas como recursos del repositorio.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Ya usáis Kubernetes y lo operáis bien | Operador de RabbitMQ con tres réplicas y volúmenes persistentes | El clúster y su topología en GitOps |
| Sin Kubernetes | Tres máquinas virtuales con RabbitMQ, desplegadas con Ansible o Terraform | Pocas piezas y fácil de razonar |
| Estáis en AWS y os basta | Amazon MQ for RabbitMQ en modo clúster | Menos mantenimiento; nosotros vigilamos colas, alertas y versiones |
Para las particiones de red, elegimos con qué política se comporta el clúster y lo probamos cortando la red entre nodos en un entorno de pruebas, para que no sea una sorpresa en producción.
¿Qué problemas encontramos más a menudo?
- Colas clásicas replicadas: configuradas hace años, impiden pasar a RabbitMQ 4.
- Un solo nodo: si cae, se paran todas las aplicaciones que dependen de él.
- Colas que crecen sin fin: consumidores caídos o lentos, sin límite de longitud ni cola de mensajes fallidos.
- Alarma de memoria disparada: los productores se quedan bloqueados y la aplicación parece colgada.
- Mensajes perdidos: publicación sin confirmaciones o consumo con acuse automático.
- Panel de gestión expuesto: con el usuario guest o una contraseña compartida entre aplicaciones.
¿Cómo protegemos los mensajes y la configuración?
En RabbitMQ la protección de los mensajes son las colas quorum replicadas, no una copia nocturna: los mensajes viven poco y una copia de ayer no sirve para recuperarlos. Lo que sí guardamos es la definición del clúster: usuarios, vhosts, colas, intercambios y políticas, en el repositorio y exportadas periódicamente. Para comprobar que funciona, levantamos un clúster de prueba desde esas definiciones y apagamos un nodo con carga para ver que no se pierde nada.
¿Cómo hacemos una actualización de versión?
Leemos las notas de la versión, comprobamos la ruta de actualización admitida y revisamos que todos los feature flags estén activados antes de saltar de serie, porque RabbitMQ lo exige. Ensayamos en pruebas y después actualizamos nodo a nodo, esperando a que las colas quorum recuperen sus réplicas antes de seguir. Cuando el salto es grande o hay que cambiar el tipo de colas, montamos un clúster nuevo en paralelo y movemos las aplicaciones de forma gradual, en lo que RabbitMQ llama despliegue azul-verde.
¿Cómo migramos desde otro RabbitMQ o desde Amazon MQ?
Con el clúster nuevo levantado y las definiciones importadas, usamos Shovel o Federation para mover los mensajes pendientes mientras cambiamos primero los consumidores y luego los productores. Aprovechamos para pasar a colas quorum lo que siga en colas clásicas. Si estáis pensando en cambiar de proveedor por coste, lo comparamos con vuestras facturas en migraciones y costes cloud.
¿Cómo es el soporte día a día?
Las métricas van a Prometheus y Grafana, como contamos en monitorización con Grafana y Prometheus, con alertas de mensajes pendientes, consumidores caídos, alarmas y nodos fuera del clúster. La vigilancia automática es continua; la respuesta humana, el siguiente día hábil en horario laboral, dentro del SRE como servicio. Cada mes recibís un informe con versiones, incidencias y cambios hechos.
- ProductoresCon confirmaciones del broker
- BalanceadorEntrada única al clúster
- RabbitMQTres nodos, colas quorum
- ConsumidoresCon acuse manual
- PrometheusMétricas y alertas
¿Dónde lo montamos?
En vuestra cuenta, en el proveedor que ya uséis o en el que mejor encaje. Si los datos tienen que quedarse en la UE, Hetzner y OVHcloud son las opciones europeas.
Proveedores en los que lo montamos
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propio
| Proveedor | Cómo lo montamos | A tener en cuenta |
|---|---|---|
| Hetzner | Tres servidores cloud en red privada con RabbitMQ en clúster, o en vuestro Kubernetes con el operador de RabbitMQ. | Hetzner no ofrece RabbitMQ gestionado: el clúster y las actualizaciones las ponemos nosotros. |
| AWS | Amazon MQ for RabbitMQ cuando encaja; si no, EC2 o EKS con el operador de RabbitMQ en tres zonas. | Con Amazon MQ revisamos tamaño de instancia, tipo de colas, alertas y ventanas de mantenimiento. |
| Google Cloud | Compute Engine o GKE con RabbitMQ y su operador. | Google Cloud no tiene un RabbitMQ gestionado propio; Pub/Sub es otro servicio con otro modelo. |
| Azure | Máquinas virtuales o AKS con RabbitMQ y su operador. | Azure no tiene un RabbitMQ gestionado propio; Service Bus es una alternativa, no un reemplazo directo. |
| DigitalOcean | Droplets o DOKS con RabbitMQ en clúster. | Sin RabbitMQ gestionado: lo montamos y mantenemos nosotros. |
| OVH | Instancias de Public Cloud o Managed Kubernetes con RabbitMQ. | |
| Servidor propio | RabbitMQ en clúster en vuestros servidores o máquinas virtuales, o en vuestro Kubernetes. | Los tres nodos deben estar en máquinas físicas distintas y con red fiable entre ellas. |
Qué incluye
- Clúster de tres nodos en máquinas o zonas distintas, en código con Terraform, Ansible o el operador de Kubernetes.
- Colas quorum para los datos que no pueden perderse y streams cuando hace falta releer mensajes.
- Migración de las antiguas colas clásicas replicadas, que RabbitMQ 4.0 ya no admite.
- Límites de memoria y de disco ajustados, con alertas antes de que salten las alarmas y bloqueen a los productores.
- Plugin de Prometheus con paneles en Grafana: mensajes pendientes, consumidores, confirmaciones y conexiones.
- Política de particiones de red elegida y probada, para saber qué hace el clúster si se corta la red.
- Usuarios, vhosts y permisos por aplicación, TLS y panel de gestión sin acceso desde internet.
- Actualizaciones con feature flags revisados o por despliegue azul-verde, ensayadas antes.
Preguntas frecuentes
¿Colas quorum o colas clásicas?
Para mensajes que no pueden perderse, colas quorum: se replican en varios nodos con un protocolo de consenso y aguantan la caída de uno. Las clásicas siguen sirviendo para datos temporales donde importa más la velocidad. Las clásicas replicadas desaparecieron en RabbitMQ 4.0, así que si aún las usáis hay que migrarlas antes de actualizar.
¿RabbitMQ o Kafka?
RabbitMQ encaja cuando repartís tareas entre trabajadores y cada mensaje se consume y se borra. Kafka encaja cuando muchos consumidores leen el mismo flujo de eventos o necesitáis guardarlo días. Los streams de RabbitMQ cubren parte de ese hueco; si dudáis, lo vemos con vuestro caso real.
¿Amazon MQ o RabbitMQ propio?
Si estáis en AWS y vuestra carga es normal, Amazon MQ os quita el mantenimiento del broker. Montamos RabbitMQ propio cuando vuestro proveedor no lo ofrece, cuando necesitáis plugins o configuración que el servicio no permite, o cuando queréis el broker dentro de vuestro Kubernetes.
¿Por qué se bloquean los productores?
Por las alarmas de memoria o de disco: cuando un nodo pasa el límite, RabbitMQ deja de aceptar mensajes para protegerse. Suele ser síntoma de consumidores lentos o caídos y colas que crecen sin parar. Lo evitamos con alertas sobre mensajes pendientes antes de llegar a la alarma.
Contadnos vuestro caso
En una llamada gratuita de 20 minutos vemos dónde estáis y por dónde empezar. Sin compromiso.
Documentación oficial consultada
Los datos técnicos de esta página se basan en:
Revisado el