Categoria: Missatgeria
RabbitMQ gestionat al vostre compte: cues fiables, clúster i actualitzacions
El vostre broker de missatges en clúster, amb cues que sobreviuen a la caiguda d'un node, alarmes que es veuen vindre i actualitzacions sense sobresalts, al vostre compte i en codi.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
- Llicència
- Open source, MPL 2.0
En resum
RabbitMQ és un broker de missatges de codi obert que reparteix feina entre aplicacions mitjançant cues. Gestionar-lo és respondre que cap missatge no es perda i que les cues no s'embussen. Muntem un clúster de tres nodes amb cues quorum, vigilem memòria, disc i cues acumulades, i planifiquem les actualitzacions, en màquines virtuals o en Kubernetes amb el seu operador.
De què ens encarreguem?
RabbitMQ sol donar guerra en dos moments: quan un consumidor deixa de funcionar i les cues creixen fins a disparar l’alarma de memòria, i quan toca actualitzar una versió que fa anys que no es toca. Ens encarreguem que el primer avise amb temps i que el segon siga un procediment assajat.
Clúster
Nombre senar de nodes: les cues quorum necessiten majoria, i amb tres el clúster aguanta la caiguda d’un.
Cues
Límit de lliuraments i cua de missatges morts, perquè un missatge que sempre falla no es reintente sense fi.
Alarmes
L’alarma de memòria salta per defecte al 40 % de la RAM i bloqueja tots els productors: l’ajustem al node real.
Mètriques
Missatges lliurats i sense confirmar per consumidor: el primer que mirem quan una cua creix.
Accessos
Mai l’usuari guest: un usuari i un vhost per aplicació, amb permisos només sobre les seues cues.
Actualitzacions
Tots els feature flags activats abans de canviar de versió; si en falta algun, el node nou no arrenca.
Quina arquitectura recomanem?
Per a producció, un clúster de tres nodes, perquè les cues quorum necessiten majoria per a continuar funcionant: amb tres, aguanta la caiguda d’un. Les aplicacions es connecten a través d’un balancejador o d’una llista de nodes, publiquen amb confirmacions del broker i consumeixen amb confirmació manual, perquè un missatge no es done per lliurat fins que s’ha processat. En Kubernetes fem servir l’operador oficial de RabbitMQ, que declara el clúster, els usuaris i les cues com a recursos del repositori.
| Situació | El que muntem | Per què |
|---|---|---|
| Ja feu servir Kubernetes i l’opereu bé | Operador de RabbitMQ amb tres rèpliques i volums persistents | El clúster i la seua topologia en GitOps |
| Sense Kubernetes | Tres màquines virtuals amb RabbitMQ, desplegades amb Ansible o Terraform | Poques peces i fàcil de raonar |
| Esteu en AWS i us n’hi ha prou | Amazon MQ for RabbitMQ en mode clúster | Menys manteniment; nosaltres vigilem cues, alertes i versions |
Per a les particions de xarxa, triem amb quina política es comporta el clúster i ho provem tallant la xarxa entre nodes en un entorn de proves, perquè no siga una sorpresa en producció.
Quins problemes trobem més sovint?
- Cues clàssiques replicades: configurades fa anys, impedeixen passar a RabbitMQ 4.
- Un sol node: si cau, s’aturen totes les aplicacions que en depenen.
- Cues que creixen sense fi: consumidors caiguts o lents, sense límit de longitud ni cua de missatges fallits.
- Alarma de memòria disparada: els productors es queden bloquejats i l’aplicació sembla penjada.
- Missatges perduts: publicació sense confirmacions o consum amb confirmació automàtica.
- Panell de gestió exposat: amb l’usuari guest o una contrasenya compartida entre aplicacions.
Com protegim els missatges i la configuració?
En RabbitMQ la protecció dels missatges són les cues quorum replicades, no una còpia nocturna: els missatges viuen poc i una còpia d’ahir no serveix per a recuperar-los. El que sí que guardem és la definició del clúster: usuaris, vhosts, cues, intercanvis i polítiques, al repositori i exportades periòdicament. Per a comprovar que funciona, aixequem un clúster de prova a partir d’aquestes definicions i apaguem un node amb càrrega per a veure que no es perd res.
Com fem una actualització de versió?
Llegim les notes de la versió, comprovem la ruta d’actualització admesa i revisem que tots els feature flags estiguen activats abans de saltar de sèrie, perquè RabbitMQ ho exigeix. Ho assagem en proves i després actualitzem node a node, esperant que les cues quorum recuperen les seues rèpliques abans de continuar. Quan el salt és gran o cal canviar el tipus de cues, muntem un clúster nou en paral·lel i passem les aplicacions de manera gradual, en el que RabbitMQ anomena desplegament blau-verd.
Com migrem des d’un altre RabbitMQ o des d’Amazon MQ?
Amb el clúster nou aixecat i les definicions importades, fem servir Shovel o Federation per a moure els missatges pendents mentre canviem primer els consumidors i després els productors. Aprofitem per a passar a cues quorum el que continue en cues clàssiques. Si esteu pensant a canviar de proveïdor per cost, ho comparem amb les vostres factures en migracions i costos cloud.
Com és el suport del dia a dia?
Les mètriques van a Prometheus i Grafana, com expliquem en monitoratge amb Grafana i Prometheus, amb alertes de missatges pendents, consumidors caiguts, alarmes i nodes fora del clúster. La vigilància automàtica és contínua; la resposta humana, el següent dia feiner en horari laboral, dins del SRE com a servei. Cada mes rebeu un informe amb versions, incidències i canvis fets.
- ProductorsAmb confirmacions del broker
- BalancejadorEntrada única al clúster
- RabbitMQTres nodes, cues quorum
- ConsumidorsAmb confirmació manual
- PrometheusMètriques i alertes
On ho muntem?
Al vostre compte, al proveïdor que ja feu servir o al que encaixe millor. Si les dades s'han de quedar a la UE, Hetzner i OVHcloud són les opcions europees.
Proveïdors on ho muntem
- Hetzner
- AWS
- Google Cloud
- Azure
- DigitalOcean
- OVH
- Servidor propi
| Proveïdor | Com ho muntem | A tindre en compte |
|---|---|---|
| Hetzner | Tres servidors cloud en xarxa privada amb RabbitMQ en clúster, o en el vostre Kubernetes amb l'operador de RabbitMQ. | Hetzner no ofereix RabbitMQ gestionat: el clúster i les actualitzacions els posem nosaltres. |
| AWS | Amazon MQ for RabbitMQ quan encaixa; si no, EC2 o EKS amb l'operador de RabbitMQ en tres zones. | Amb Amazon MQ revisem la mida de la instància, el tipus de cues, les alertes i les finestres de manteniment. |
| Google Cloud | Compute Engine o GKE amb RabbitMQ i el seu operador. | Google Cloud no té un RabbitMQ gestionat propi; Pub/Sub és un altre servei amb un altre model. |
| Azure | Màquines virtuals o AKS amb RabbitMQ i el seu operador. | Azure no té un RabbitMQ gestionat propi; Service Bus és una alternativa, no un reemplaçament directe. |
| DigitalOcean | Droplets o DOKS amb RabbitMQ en clúster. | Sense RabbitMQ gestionat: el muntem i el mantenim nosaltres. |
| OVH | Instàncies de Public Cloud o Managed Kubernetes amb RabbitMQ. | |
| Servidor propi | RabbitMQ en clúster en els vostres servidors o màquines virtuals, o en el vostre Kubernetes. | Els tres nodes han d'estar en màquines físiques diferents i amb una xarxa fiable entre elles. |
Què inclou
- Clúster de tres nodes en màquines o zones diferents, en codi amb Terraform, Ansible o l'operador de Kubernetes.
- Cues quorum per a les dades que no es poden perdre i streams quan cal tornar a llegir missatges.
- Migració de les antigues cues clàssiques replicades, que RabbitMQ 4.0 ja no admet.
- Límits de memòria i de disc ajustats, amb alertes abans que salten les alarmes i bloquegen els productors.
- Plugin de Prometheus amb panells en Grafana: missatges pendents, consumidors, confirmacions i connexions.
- Política de particions de xarxa triada i provada, per a saber què fa el clúster si es talla la xarxa.
- Usuaris, vhosts i permisos per aplicació, TLS i panell de gestió sense accés des d'internet.
- Actualitzacions amb feature flags revisats o per desplegament blau-verd, assajades abans.
Preguntes freqüents
Cues quorum o cues clàssiques?
Per a missatges que no es poden perdre, cues quorum: es repliquen en diversos nodes amb un protocol de consens i aguanten la caiguda d'un. Les clàssiques continuen servint per a dades temporals on importa més la velocitat. Les clàssiques replicades van desaparéixer en RabbitMQ 4.0, així que si encara les feu servir cal migrar-les abans d'actualitzar.
RabbitMQ o Kafka?
RabbitMQ encaixa quan repartiu tasques entre treballadors i cada missatge es consumeix i s'esborra. Kafka encaixa quan molts consumidors llegeixen el mateix flux d'esdeveniments o necessiteu guardar-lo dies. Els streams de RabbitMQ cobreixen part d'aquest buit; si dubteu, ho mirem amb el vostre cas real.
Amazon MQ o RabbitMQ propi?
Si esteu en AWS i la vostra càrrega és normal, Amazon MQ us lleva el manteniment del broker. Muntem RabbitMQ propi quan el vostre proveïdor no l'ofereix, quan necessiteu plugins o configuració que el servei no permet, o quan voleu el broker dins del vostre Kubernetes.
Per què es bloquegen els productors?
Per les alarmes de memòria o de disc: quan un node passa el límit, RabbitMQ deixa d'acceptar missatges per a protegir-se. Sol ser símptoma de consumidors lents o caiguts i de cues que creixen sense parar. Ho evitem amb alertes sobre missatges pendents abans d'arribar a l'alarma.
Expliqueu-nos el vostre cas
En una trucada gratuïta de 20 minuts veiem on sou i per on començar. Sense compromís.
Documentació oficial consultada
Les dades tècniques d'aquesta pàgina es basen en:
Revisat el