Categoria: Missatgeria
Apache Kafka gestionat al vostre compte: clúster, retenció i actualitzacions sense ensurts
El vostre clúster de Kafka amb rèpliques que de veritat protegeixen les dades, una retenció que no omple el disc i actualitzacions node a node, al vostre compte i descrit en codi.
- On es munta
- Al vostre compte, a nom vostre
- Còpies
- Amb restauració provada
- Actualitzacions
- Planificades i documentades
- Llicència
- Open source, Apache 2.0 (els components de Confluent tenen altres llicències)
En resum
Apache Kafka és una plataforma de codi obert per a moure i guardar fluxos d'esdeveniments entre aplicacions. Gestionar-lo és respondre que no es perden missatges, que els consumidors no es queden enrere i que el disc no s'omple. Muntem i operem el clúster al vostre compte, en màquines virtuals o en Kubernetes amb Strimzi, amb tot descrit al repositori.
De què ens encarreguem?
Kafka sol funcionar en silenci fins que un broker es queda sense disc, un grup de consumidors acumula hores de retard o una actualització ajornada deixa el clúster fora de suport. La nostra feina és que aquests avisos arriben abans que el problema i que cada canvi estiga al repositori.
Brokers i KRaft
Quòrum de controladors, brokers repartits en zones o màquines diferents i configuració en codi.
Rèpliques
Factor de rèplica 3 i min.insync.replicas 2 en els topics que no poden perdre dades.
Retenció i disc
Retenció per temps i mida d’acord amb el disc, amb marge perquè un broker caigut no desborde la resta.
Lag i mètriques
Retard de cada grup de consumidors, particions amb rèpliques endarrerides i latència de peticions.
Accessos
TLS entre clients i brokers, autenticació SASL o mTLS i ACL per aplicació.
Actualitzacions
Versions de Kafka i de Java al dia, broker a broker i sense perdre disponibilitat.
Quina arquitectura recomanem?
Per a producció, almenys tres brokers en màquines o zones diferents i un quòrum de tres controladors KRaft, que en clústers xicotets poden compartir màquina amb els brokers i en els grans van a part. Els topics importants porten factor de rèplica 3 i min.insync.replicas 2, i els productors escriuen amb acks=all: així un broker pot caure sense que es perda un missatge ja confirmat i sense que es pare l’escriptura.
| Situació | El que muntem | Per què |
|---|---|---|
| Ja feu servir Kubernetes i l’opereu bé | Strimzi amb el clúster, els topics i els usuaris declarats en YAML | Tot en GitOps i actualitzacions guiades per l’operador |
| Sense Kubernetes, càrrega estable | Màquines virtuals amb Kafka en KRaft, desplegades amb Ansible o Terraform | Menys capes i discos locals ràpids |
| El vostre núvol té Kafka gestionat i us n’hi ha prou | Amazon MSK, el servei de Google Cloud, DigitalOcean o OVHcloud | Menys manteniment; nosaltres vigilem topics, lag, retenció i cost |
Les particions les calculem segons quants consumidors necessiteu en paral·lel i quant creixerà el volum. Augmentar-les després és possible, però canvia a quina partició va cada clau, i reduir-les no es pot: per això es pensen abans.
Quins problemes trobem més sovint?
- Factor de rèplica 1 o min.insync.replicas 1: el clúster sembla redundant, però una caiguda perd dades confirmades.
- Disc ple: retenció per temps sense límit de mida, o un topic que creix més del previst.
- Lag que ningú no mira: un consumidor porta hores endarrerit i es nota quan les dades ja caduquen per retenció.
- Particions de més: milers de particions xicotetes que allarguen les arrancades i les eleccions de líder.
- ZooKeeper encara en ús: el clúster no pot passar a Kafka 4 sense migrar abans a KRaft.
- Topics creats a mà: la creació automàtica activada i ningú no sap quina configuració té cadascun.
Com protegim les dades i provem la recuperació?
Kafka no té una còpia de seguretat clàssica: la protecció són les rèpliques dins del clúster i, si les dades ho justifiquen, una còpia en un altre clúster o regió amb MirrorMaker 2, o els topics bolcats a un emmagatzematge d’objectes. El que sí que provem és la recuperació: apaguem un broker i comprovem que els líders es mouen, que ningú no perd missatges i quant tarda a posar-se al dia quan torna. Les definicions de topics, ACL i quotes viuen al repositori, així que un clúster nou es reconstrueix des del codi.
Com fem una actualització de versió?
Llegim les notes de la versió, comprovem la compatibilitat dels clients i de Java, i assagem en un entorn de proves. Després actualitzem broker a broker: esperem que no quede cap partició amb rèpliques endarrerides abans de passar al següent, i pugem la versió de metadades només quan tot el clúster és en la nova i ha funcionat un temps. Amb Strimzi l’operador segueix aquest mateix ordre.
Com migrem des d’un altre clúster o des de Confluent Cloud?
Amb MirrorMaker 2 repliquem els topics, la seua configuració i els offsets dels grups de consumidors al clúster nou del vostre compte. Canviem primer els consumidors, que continuen on ho havien deixat, i després els productors, topic a topic i amb marxa enrere. El que siga propi de Confluent i no de Kafka, com Schema Registry o alguns connectors, ho substituïm per alternatives obertes abans del tall. Si el motiu és el cost, el comparem amb les vostres factures en migracions i costos cloud.
Com és el suport dia a dia?
Les mètriques de Kafka van a Prometheus i Grafana, com expliquem en monitoratge amb Grafana i Prometheus, amb alertes de lag, rèpliques endarrerides, controlador actiu i disc. La vigilància automàtica és contínua; la resposta humana, el següent dia feiner en horari laboral, dins de l’SRE com a servei. Cada mes rebeu un informe amb versions, incidències, creixement del disc i canvis fets.
- Productorsacks=all i idempotència
- Brokers KafkaTres o més, en zones diferents
- Controladors KRaftQuòrum de tres per a les metadades
- ConsumidorsGrups amb el lag vigilat
- 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 | Servidors cloud o dedicats amb Kafka en KRaft muntat per nosaltres, discos locals o volums i xarxa privada entre brokers. | Hetzner no ofereix Kafka gestionat: el clúster, les rèpliques i les actualitzacions les posem nosaltres. |
| AWS | Amazon MSK quan encaixa (aprovisionat o serverless); si no, EC2 o EKS amb Strimzi i brokers repartits en tres zones. | Amb MSK continuem revisant topics, rèpliques, retenció, lag i el cost del trànsit entre zones. |
| Google Cloud | Managed Service for Apache Kafka de Google Cloud, o GKE amb Strimzi. | Triem entre gestionat i Strimzi segons la versió, la mida i quins paràmetres necessiteu tocar. |
| Azure | AKS amb Strimzi o màquines virtuals amb Kafka. Event Hubs accepta el protocol de Kafka, però no és Kafka. | Event Hubs serveix per a molts productors i consumidors senzills; amb Kafka Streams, Connect o transaccions convé provar-ho abans. |
| DigitalOcean | Kafka gestionat de DigitalOcean, o Droplets i DOKS amb Strimzi. | Opció senzilla per a clústers xicotets; abans de triar-la revisem els límits de configuració. |
| OVH | Kafka gestionat de Public Cloud Databases d'OVHcloud, o instàncies de Public Cloud amb Kafka propi. | |
| Servidor propi | Kafka en KRaft en els vostres servidors o màquines virtuals, o en el vostre Kubernetes amb Strimzi. | Tres brokers en una mateixa màquina física no són alta disponibilitat: calen almenys tres màquines. |
Què inclou
- Clúster Kafka en mode KRaft, sense ZooKeeper, amb controladors separats dels brokers quan la mida ho demana.
- Factor de rèplica, min.insync.replicas i acks revisats per topic perquè una caiguda no perda missatges confirmats.
- Particions dimensionades segons el paral·lelisme real dels consumidors, no per costum.
- Retenció per temps i per mida ajustada al disc, amb alertes abans d'arribar al límit.
- Mètriques de brokers i consumidors: lag, particions amb rèpliques endarrerides, peticions i disc, amb alertes i runbooks.
- Topics, ACL i quotes declarats en codi (Strimzi o Terraform), no creats a mà.
- Actualitzacions de versió broker a broker, assajades abans en un entorn de proves.
- Migració des d'un altre clúster o des de Confluent Cloud amb MirrorMaker 2.
Preguntes freqüents
És millor Amazon MSK o Confluent Cloud que un Kafka propi?
Depén del vostre equip i del volum. Un servei gestionat us lleva el manteniment dels brokers, però no el disseny de topics, la retenció, el lag ni el cost del trànsit. Muntem Kafka propi quan el proveïdor no l'ofereix, quan el gestionat limita paràmetres que necessiteu o quan el seu cost creix més que la càrrega.
Kafka en Kubernetes o en màquines virtuals?
Si ja teniu Kubernetes ben operat, Strimzi fa molt còmode declarar el clúster, els topics i els usuaris en codi. Si no teniu Kubernetes, unes màquines virtuals amb Ansible o Terraform són més senzilles d'entendre. En tots dos casos Kafka necessita discos persistents ràpids i brokers repartits en màquines diferents.
Què passa amb el nostre clúster si encara fa servir ZooKeeper?
Des de Kafka 4.0 ZooKeeper ja no té suport. Per a actualitzar cal migrar abans les metadades a KRaft en una versió 3.x que ho permeta, i després pujar de versió. Ho planifiquem amb un assaig previ i la marxa enrere preparada.
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:
- Apache Kafka Documentation: KRaft
- Apache Kafka Documentation: Geo-Replication (Cross-Cluster Data Mirroring)
Revisat el