Apache Kafka es una plataforma abierta para mover datos en el momento en que ocurren. Las aplicaciones que generan información —una venta, un clic, la lectura de un sensor— la publican como un evento, y las aplicaciones que la necesitan la leen a su propio ritmo. En lugar de que cada sistema converse directamente con cada otro sistema, todos conversan con Kafka.
¿Qué problema resuelve Kafka?
La mayoría de las empresas todavía mueve información por lotes. El sistema de ventas cierra el día, genera un archivo, y de madrugada un proceso lo carga en el almacén de datos. A la mañana siguiente el tablero muestra lo que pasó ayer. Ese diseño funcionó durante décadas y sigue siendo razonable para muchos reportes.
Deja de serlo cuando la decisión no puede esperar hasta mañana. Una transacción fraudulenta hay que frenarla antes de aprobarla, no en el reporte del día siguiente. Un producto agotado hay que sacarlo del canal digital ahora, no en la próxima carga. Una máquina que empieza a fallar avisa con datos que pierden valor por minuto.
El otro problema es de arquitectura. Cuando cada sistema se conecta directamente con cada otro sistema, la cantidad de integraciones crece mucho más rápido que la cantidad de sistemas: diez aplicaciones que se hablan entre sí pueden significar decenas de conexiones que mantener, cada una con su formato y su horario. Agregar la aplicación número once obliga a tocar varias de las anteriores.
Kafka ataca las dos cosas a la vez. Pone un lugar común por el que pasan los eventos: quien produce publica una sola vez, quien consume se suscribe a lo que necesita, y ninguno de los dos tiene que conocer al otro. Sumar un consumidor nuevo deja de ser un proyecto de integración.
¿Cómo funciona Kafka?
El modelo es más simple de lo que sugiere la reputación de la herramienta. Hay cuatro piezas.
Un evento es un hecho que ya ocurrió, con su momento y sus datos: “el cliente 4821 pagó S/ 129 a las 10:42”. Un tópico es la categoría donde se publican los eventos de un mismo tipo, algo así como un canal: pagos, clics, lecturas de sensor. Un productor es la aplicación que publica en un tópico. Un consumidor es la aplicación que lee de él.
Lo distintivo está en cómo se guarda todo eso. Kafka no es un buzón que entrega el mensaje y lo borra: es un registro ordenado y duradero. Los eventos se agregan al final, se conservan durante el tiempo que se configure y cada consumidor lleva su propia marca de hasta dónde leyó. De ahí salen tres propiedades que explican por qué Kafka se volvió el estándar:
- Varios consumidores, sin interferencia. El equipo de fraude, el tablero de operaciones y el almacén analítico leen los mismos eventos de pago sin pisarse ni duplicar la ingesta.
- Recuperación sin pérdida. Si un consumidor se cae, al volver retoma desde su última marca. Los eventos siguieron ahí mientras estuvo fuera.
- Reproceso. Un modelo nuevo o una corrección de lógica puede releer el histórico disponible y recalcular, sin pedirle nada al sistema que originó el dato.
Cada tópico se divide en particiones, y ahí está la palanca de escala: más particiones permiten más consumidores trabajando en paralelo. El precio a pagar es que el orden solo está garantizado dentro de una partición. Por eso la llave que decide en qué partición cae cada evento —el número de cuenta, el identificador de equipo— es una decisión de diseño con consecuencias, no un parámetro que se completa al final.
Casos de uso que aparecen una y otra vez
En los proyectos que nos llegan, el streaming casi siempre entra por una de estas puertas:
- Riesgo y fraude en el momento. Evaluar la transacción mientras ocurre, no después de aprobarla.
- Inventario y precios en vivo. Canales digitales que reflejan el estado real en segundos y no en la carga de la madrugada.
- Telemetría de equipos y vehículos. Mantenimiento que se anticipa a la falla en lugar de reaccionar a ella.
- Sincronización entre sistemas. Reemplazar el intercambio de archivos entre el sistema central y las aplicaciones satélite por eventos.
- Alimentación continua de analítica. Tableros y modelos que dejan de mirar el día anterior.
El patrón común es que el valor del dato cae rápido con el tiempo. Si el dato vale lo mismo mañana, un buen proceso ETL por lotes suele ser la respuesta correcta y más barata de operar.
Kafka administrado sobre AWS: Amazon MSK
Operar Kafka por cuenta propia es donde se va el presupuesto: brókeres que dimensionar, almacenamiento que vigilar, versiones que actualizar, reequilibrios que coordinar. Amazon Managed Streaming for Apache Kafka (Amazon MSK) es el servicio administrado de AWS que se hace cargo de esa capa. AWS ejecuta las operaciones del plano de control —crear, actualizar y eliminar clústeres— y corre versiones de código abierto de Apache Kafka, de modo que las aplicaciones, herramientas y complementos existentes de socios y de la comunidad de Apache Kafka funcionan sin cambios en el código de la aplicación. Esto último es lo que hace que la conversación deje de ser “migrar a otro producto” y pase a ser “dejar de administrar servidores”.
Sobre la disponibilidad: MSK crea los nodos brókeres en las zonas de disponibilidad que se indiquen, con un mínimo de un bróker por zona y cada zona en su propia subred aislada. Cuando detecta un bróker con problemas, lo mitiga o lo reemplaza por uno nuevo y, cuando es posible, reutiliza el almacenamiento del anterior para reducir los datos que Kafka necesita replicar. Tras la recuperación, las aplicaciones productoras y consumidoras siguen comunicándose con las mismas direcciones que usaban antes de la falla.
También cambió la gestión de metadatos. La comunidad de Apache Kafka desarrolló KRaft para reemplazar a Apache ZooKeeper: los metadatos del clúster se propagan dentro de un grupo de controladores que forman parte del propio clúster. En MSK, esos controladores KRaft no tienen costo adicional y no requieren configuración ni administración extra.
Hay dos modalidades de consumo del servicio —y una de ellas ofrece dos tipos de nodo—. La elección es de modelo operativo:
| Modalidad | Quién dimensiona la capacidad | Cuándo encaja |
|---|---|---|
| MSK Serverless | AWS, de forma automática | Demanda que sube y baja sin previsibilidad; equipos que no quieren razonar sobre capacidad |
| MSK Provisioned — brókeres estándar | El equipo | Control fino del dimensionamiento y del almacenamiento |
| MSK Provisioned — brókeres Express | El equipo, con menos trabajo | Alto rendimiento y escalado rápido, sin administrar almacenamiento |
MSK Serverless aprovisiona y escala la capacidad de forma automática y administra las particiones de los tópicos, con un modelo de precios basado en rendimiento. Es totalmente compatible con Apache Kafka, así que cualquier cliente compatible sirve para producir y consumir, y se integra con AWS PrivateLink para conectividad privada, con AWS Identity and Access Management (IAM) para autenticación y autorización, con AWS Glue Schema Registry para la gestión de esquemas, con Amazon Managed Service for Apache Flink para procesamiento de flujos y con AWS Lambda para procesamiento de eventos. Un detalle que conviene saber antes y no después: MSK Serverless exige control de acceso con IAM en todos los clústeres y no admite las listas de control de acceso propias de Apache Kafka.
Los brókeres Express de MSK Provisioned son la novedad que más cambia el cálculo cuando el volumen es alto. Incluyen almacenamiento que escala automáticamente y no requiere dimensionar, aprovisionar ni monitorear de forma proactiva. Según el tamaño de instancia elegido, cada nodo puede entregar hasta 3 veces más rendimiento por bróker, escalar hasta 20 veces más rápido y recuperarse un 90 % más rápido que un bróker estándar de Apache Kafka. Vienen preconfigurados con los valores recomendados por Amazon MSK y no tienen ventanas de mantenimiento: AWS actualiza el hardware del clúster de forma continua. A cambio hay límites que conviene revisar al diseñar: solo están disponibles en configuración de tres zonas de disponibilidad, solo en ciertos tamaños de instancia, sobre las versiones 3.6, 3.8, 3.9 y 4.2 de Apache Kafka, y todavía no soportan por completo la API de KStreams.
Alrededor del clúster hay dos piezas que resuelven necesidades muy frecuentes. MSK Connect mueve datos hacia y desde el clúster de Apache Kafka, que es lo que se necesita cuando el origen es una base de datos existente y no una aplicación nueva. MSK Replicator replica datos de forma confiable entre clústeres de MSK Provisioned, en la misma región de AWS o en regiones distintas, que es la pieza que aparece cuando el requisito es continuidad ante la caída de una región completa.
Un punto de planificación: no todos los tipos de clúster están disponibles en todas las regiones de AWS. Antes de fijar la arquitectura conviene confirmar la disponibilidad de la modalidad elegida en la región de destino, sobre todo cuando hay requisitos de residencia de datos de por medio.
Kafka frente a Kinesis: cómo se elige
Es la pregunta que aparece en cuanto la conversación pasa de “necesitamos tiempo real” a “sobre qué lo montamos”. Amazon Kinesis Data Streams es el servicio de AWS para recolectar y procesar grandes flujos de registros de datos en tiempo real. La demora entre que un registro entra al flujo y puede recuperarse es típicamente menor a un segundo, y varias aplicaciones pueden consumir del mismo flujo de forma concurrente e independiente. En capacidad, las dos opciones resuelven el mismo problema. La diferencia está en otro lado.
| Eje | Apache Kafka (sobre Amazon MSK) | Amazon Kinesis Data Streams |
|---|---|---|
| Naturaleza | Plataforma abierta, ejecutada como servicio administrado | Servicio propio de AWS |
| Ecosistema | Amplio: conectores, herramientas y complementos de la comunidad | Integrado de forma nativa con el resto de AWS |
| Portabilidad | Alta: la misma plataforma corre en otros entornos | Ligada a AWS |
| Curva de aprendizaje | Requiere entender el modelo de Kafka | Menor, si el equipo ya trabaja en AWS |
| Encaje habitual | Ya hay inversión en Kafka, o se busca portabilidad | Se busca el camino más corto dentro de AWS |
La lectura práctica: si el equipo ya tiene aplicaciones, conectores o experiencia en Kafka, MSK evita reescribir y elimina la administración de servidores. Si se parte de cero, el equipo vive dentro de AWS y nadie extraña el ecosistema de Kafka, Kinesis llega antes al primer resultado. Es una decisión de ecosistema y de equipo, y por eso conviene tomarla temprano: cambiar de plataforma de streaming a mitad de camino cuesta bastante más que elegir bien al inicio.
Lo que suele salir mal
Tres patrones se repiten lo suficiente como para mencionarlos.
Tratar a Kafka como base de datos. Kafka es la vía por la que los datos viajan, no el lugar donde se consultan. Las preguntas de negocio se responden en la base operativa, en el almacén de datos o en el lago que Kafka alimenta.
Decidir las particiones al final. El número de particiones y la llave que las determina definen la escala máxima y las garantías de orden. Corregirlo con el sistema en producción es incómodo y a veces implica reprocesar.
Adoptar streaming sin un caso que lo justifique. Si ninguna decisión del negocio cambia por recibir el dato en segundos en lugar de mañana, la arquitectura por eventos agrega complejidad sin devolver valor. Vale la pena empezar por el caso de uso y no por la herramienta.
Kafka dentro de una arquitectura de datos
Adoptar Kafka rara vez es un proyecto aislado. Casi siempre llega junto con un rediseño de cómo se mueven y se consumen los datos: qué eventos importan, quién los produce, qué se conserva y por cuánto tiempo, y cómo se conecta todo eso con microservicios, con la analítica y con los patrones de mensajería que ya existen —el mapa de cuándo usar cola, notificación o bus de eventos está en nuestra comparativa de SQS, SNS y EventBridge.
En Caleidos diseñamos e implementamos estas arquitecturas dentro de nuestras prácticas de Data Engineering en AWS y aplicaciones cloud-native, y las sostenemos con Caleidos Lens©, nuestra mesa de servicio 24×7. Puedes ver cómo lo aplicamos en nuestros casos de éxito.
Preguntas frecuentes
¿Qué es Kafka en términos simples? Una plataforma abierta donde las aplicaciones publican los hechos del negocio en el momento en que ocurren y otras aplicaciones los leen a su propio ritmo, sin que unas y otras tengan que conocerse.
¿Kafka reemplaza a una base de datos? No. Es la vía por la que los datos viajan; las consultas siguen viviendo en la base operativa, el almacén analítico o el lago de datos que Kafka alimenta.
¿Hace falta administrar servidores para usar Kafka? No sobre AWS. Amazon MSK se hace cargo del plano de control y ejecuta versiones de código abierto de Apache Kafka, y MSK Serverless además aprovisiona y escala la capacidad de forma automática.
¿Cuándo conviene Kafka y cuándo Kinesis? Kafka cuando ya hay inversión en su ecosistema o se busca portabilidad; Kinesis cuando el equipo vive dentro de AWS y busca el camino más corto.
¿Evalúas streaming en tiempo real para tu operación?
Conversemos sobre tu caso y te damos una lectura concreta de si tu necesidad se resuelve mejor con Kafka administrado sobre AWS, con Kinesis, o con un buen proceso por lotes que ya tienes casi armado.
