Categoría: Mensajería
Apache Kafka gestionado en vuestra cuenta: clúster, retención y actualizaciones sin sustos
Vuestro clúster de Kafka con réplicas que de verdad protegen los datos, retención que no llena el disco y actualizaciones nodo a nodo, en vuestra cuenta y descrito 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, Apache 2.0 (los componentes de Confluent tienen otras licencias)
En resumen
Apache Kafka es una plataforma de código abierto para mover y guardar flujos de eventos entre aplicaciones. Gestionarlo es responder de que no se pierdan mensajes, de que los consumidores no se queden atrás y de que el disco no se llene. Montamos y operamos el clúster en vuestra cuenta, en máquinas virtuales o en Kubernetes con Strimzi, con todo descrito en el repositorio.
¿Qué nos encargamos de mantener?
Kafka suele funcionar en silencio hasta que un broker se queda sin disco, un grupo de consumidores acumula horas de retraso o una actualización aplazada deja el clúster fuera de soporte. Nuestro trabajo es que esos avisos lleguen antes que el problema y que cada cambio esté en el repositorio.
Brokers y KRaft
Quórum de controladores, brokers repartidos en zonas o máquinas distintas y configuración en código.
Réplicas
Factor de réplica 3 y min.insync.replicas 2 en los topics que no pueden perder datos.
Retención y disco
Retención por tiempo y tamaño acorde al disco, con margen para que un broker caído no desborde al resto.
Lag y métricas
Retraso de cada grupo de consumidores, particiones con réplicas atrasadas y latencia de peticiones.
Accesos
TLS entre clientes y brokers, autenticación SASL o mTLS y ACL por aplicación.
Actualizaciones
Versiones de Kafka y de Java al día, broker a broker y sin perder disponibilidad.
¿Qué arquitectura recomendamos?
Para producción, al menos tres brokers en máquinas o zonas distintas y un quórum de tres controladores KRaft, que en clústeres pequeños pueden compartir máquina con los brokers y en los grandes van aparte. Los topics importantes llevan factor de réplica 3 y min.insync.replicas 2, y los productores escriben con acks=all: así un broker puede caer sin que se pierda un mensaje ya confirmado y sin que se pare la escritura.
| Situación | Lo que montamos | Por qué |
|---|---|---|
| Ya usáis Kubernetes y lo operáis bien | Strimzi con el clúster, los topics y los usuarios declarados en YAML | Todo en GitOps y actualizaciones guiadas por el operador |
| Sin Kubernetes, carga estable | Máquinas virtuales con Kafka en KRaft, desplegadas con Ansible o Terraform | Menos capas y discos locales rápidos |
| Vuestra nube tiene Kafka gestionado y os basta | Amazon MSK, el servicio de Google Cloud, DigitalOcean u OVHcloud | Menos mantenimiento; nosotros vigilamos topics, lag, retención y coste |
Las particiones las calculamos según cuántos consumidores necesitáis en paralelo y cuánto crecerá el volumen. Aumentarlas después es posible, pero cambia a qué partición va cada clave, y reducirlas no se puede: por eso se piensan antes.
¿Qué problemas encontramos más a menudo?
- Factor de réplica 1 o min.insync.replicas 1: el clúster parece redundante, pero una caída pierde datos confirmados.
- Disco lleno: retención por tiempo sin límite de tamaño, o un topic que crece más de lo previsto.
- Lag que nadie mira: un consumidor lleva horas atrasado y se nota cuando los datos ya caducan por retención.
- Particiones de más: miles de particiones pequeñas que alargan los arranques y las elecciones de líder.
- ZooKeeper todavía en uso: el clúster no puede pasar a Kafka 4 sin migrar antes a KRaft.
- Topics creados a mano: la creación automática activada y nadie sabe qué configuración tiene cada uno.
¿Cómo protegemos los datos y probamos la recuperación?
Kafka no tiene una copia de seguridad clásica: la protección son las réplicas dentro del clúster y, si los datos lo justifican, una copia en otro clúster o región con MirrorMaker 2, o los topics volcados a un almacenamiento de objetos. Lo que sí probamos es la recuperación: apagamos un broker y comprobamos que los líderes se mueven, que nadie pierde mensajes y cuánto tarda en ponerse al día al volver. Las definiciones de topics, ACL y cuotas viven en el repositorio, así que un clúster nuevo se reconstruye desde código.
¿Cómo hacemos una actualización de versión?
Leemos las notas de la versión, comprobamos la compatibilidad de los clientes y de Java, y ensayamos en un entorno de pruebas. Después actualizamos broker a broker: esperamos a que no quede ninguna partición con réplicas atrasadas antes de pasar al siguiente, y subimos la versión de metadatos solo cuando todo el clúster está en la nueva y ha funcionado un tiempo. Con Strimzi el operador sigue ese mismo orden.
¿Cómo migramos desde otro clúster o desde Confluent Cloud?
Con MirrorMaker 2 replicamos los topics, su configuración y los offsets de los grupos de consumidores al clúster nuevo en vuestra cuenta. Cambiamos primero los consumidores, que siguen donde lo dejaron, y luego los productores, topic a topic y con vuelta atrás. Lo que sea propio de Confluent y no de Kafka, como Schema Registry o algunos conectores, lo sustituimos por alternativas abiertas antes del corte. Si el motivo es el coste, lo comparamos con vuestras facturas en migraciones y costes cloud.
¿Cómo es el soporte día a día?
Las métricas de Kafka van a Prometheus y Grafana, como contamos en monitorización con Grafana y Prometheus, con alertas de lag, réplicas atrasadas, controlador activo y disco. 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, crecimiento del disco y cambios hechos.
- Productoresacks=all e idempotencia
- Brokers KafkaTres o más, en zonas distintas
- Controladores KRaftQuórum de tres para los metadatos
- ConsumidoresGrupos con lag vigilado
- 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 | Servidores cloud o dedicados con Kafka en KRaft montado por nosotros, discos locales o volúmenes y red privada entre brokers. | Hetzner no ofrece Kafka gestionado: el clúster, las réplicas y las actualizaciones las ponemos nosotros. |
| AWS | Amazon MSK cuando encaja (provisionado o serverless); si no, EC2 o EKS con Strimzi y brokers repartidos en tres zonas. | Con MSK seguimos revisando topics, réplicas, retención, lag y el coste del tráfico entre zonas. |
| Google Cloud | Managed Service for Apache Kafka de Google Cloud, o GKE con Strimzi. | Elegimos entre gestionado y Strimzi según versión, tamaño y qué parámetros necesitáis tocar. |
| Azure | AKS con Strimzi o máquinas virtuales con Kafka. Event Hubs acepta el protocolo de Kafka, pero no es Kafka. | Event Hubs sirve para muchos productores y consumidores sencillos; con Kafka Streams, Connect o transacciones conviene probar antes. |
| DigitalOcean | Kafka gestionado de DigitalOcean, o Droplets y DOKS con Strimzi. | Opción sencilla para clústeres pequeños; revisamos los límites de configuración antes de elegirla. |
| OVH | Kafka gestionado de Public Cloud Databases de OVHcloud, o instancias de Public Cloud con Kafka propio. | |
| Servidor propio | Kafka en KRaft en vuestros servidores o máquinas virtuales, o en vuestro Kubernetes con Strimzi. | Tres brokers en una misma máquina física no son alta disponibilidad: hacen falta al menos tres máquinas. |
Qué incluye
- Clúster Kafka en modo KRaft, sin ZooKeeper, con controladores separados de los brokers cuando el tamaño lo pide.
- Factor de réplica, min.insync.replicas y acks revisados por topic para que una caída no pierda mensajes confirmados.
- Particiones dimensionadas según el paralelismo real de los consumidores, no por costumbre.
- Retención por tiempo y por tamaño ajustada al disco, con alertas antes de llegar al límite.
- Métricas de brokers y consumidores: lag, particiones con réplicas atrasadas, peticiones y disco, con alertas y runbooks.
- Topics, ACL y cuotas declarados en código (Strimzi o Terraform), no creados a mano.
- Actualizaciones de versión broker a broker, ensayadas antes en un entorno de pruebas.
- Migración desde otro clúster o desde Confluent Cloud con MirrorMaker 2.
Preguntas frecuentes
¿Es mejor Amazon MSK o Confluent Cloud que un Kafka propio?
Depende de vuestro equipo y del volumen. Un servicio gestionado os quita el mantenimiento de los brokers, pero no el diseño de topics, la retención, el lag ni el coste del tráfico. Montamos Kafka propio cuando el proveedor no lo ofrece, cuando el gestionado limita parámetros que necesitáis o cuando su coste crece más que la carga.
¿Kafka en Kubernetes o en máquinas virtuales?
Si ya tenéis Kubernetes bien operado, Strimzi hace muy cómodo declarar el clúster, los topics y los usuarios en código. Si no tenéis Kubernetes, unas máquinas virtuales con Ansible o Terraform son más sencillas de razonar. En los dos casos Kafka necesita discos persistentes rápidos y brokers repartidos en máquinas distintas.
¿Qué pasa con nuestro clúster si todavía usa ZooKeeper?
Desde Kafka 4.0 ZooKeeper ya no está soportado. Para actualizar hay que migrar antes los metadatos a KRaft en una versión 3.x que lo permita, y después subir de versión. Lo planificamos con un ensayo previo y vuelta atrás preparada.
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:
- Apache Kafka Documentation: KRaft
- Apache Kafka Documentation: Geo-Replication (Cross-Cluster Data Mirroring)
Revisado el