Unidad 5.6: Streaming de eventos (Kafka administrado)

Introducción

La decisión estructural fundamental en la transmisión de eventos no es la aprovisionamiento del clúster, sino la forma del tema. La cantidad de particiones fija tanto la garantía de orden como el límite superior de la paralelización de los consumidores durante toda la vida de ese tema, y el factor de replicación y la retención, en conjunto, determinan cuánto se paga para mantener los datos seguros y durante cuánto tiempo. Si se define correctamente la forma del tema, el clúster es casi un asunto secundario. Si se comete un error, se descubre el límite en producción, donde las particiones no pueden reducirse y una reconfiguración implica un tema nuevo y una migración.

Esta unidad trata Event Streams for Apache Kafka como la columna vertebral de la transmisión de eventos para FinCorp, la empresa alemana de servicios financieros que asume las obligaciones del RGPD y de BSI a lo largo de su migración y su nueva capacidad de IA. Se comienza con la decisión de diseño del tema, se explica cómo interactúan las particiones, los grupos de consumidores, la replicación y la retención, se muestra dónde se ubica el flujo en la arquitectura general y, a continuación, se construye un clúster y un tema con la forma correcta en Data Center Designer.

1. El tema es la arquitectura: particiones, orden y paralelismo

Una partición es la unidad tanto del orden como del paralelismo, y esas dos propiedades tiran en la misma dirección, lo que convierte al número de particiones en la decisión más importante. Kafka mantiene el orden de los mensajes dentro de una partición; no hace ninguna promesa de orden entre particiones. Por lo tanto, si FinCorp debe procesar todos los eventos de una cuenta dada en el orden en que ocurrieron, cada evento de esa cuenta debe llegar a la misma partición. La forma estándar de garantizarlo es establecer una clave de partición (el identificador de la cuenta) para que el productor la convierta en una partición fija mediante una función de hash. El orden es, por lo tanto, una propiedad por clave, no por tema: se obtiene un orden estricto dentro de cada clave y concurrencia entre claves, que es exactamente lo que desea un flujo de transacciones de alto volumen.

El paralelismo es el otro lado de la misma moneda. Dentro de un grupo de consumidores, una partición es consumida por como máximo un miembro a la vez, por lo que el número de particiones es el límite estricto sobre cuántos consumidores pueden trabajar ese tema en paralelo. Tres particiones significan como máximo tres consumidores activos; un cuarto permanece inactivo. Más particiones permiten un mejor equilibrio de carga entre consumidores y mejoran el rendimiento, pero también multiplican los manejadores de archivos abiertos, el tráfico de replicación y el tiempo de reequilibrio, por lo que el número se dimensiona según el rendimiento que realmente se espera, no se infla especulativamente. La asimetría que debe internalizarse es que normalmente se pueden agregar particiones más tarde, pero al agregarlas se recalcula el mapeo de clave a partición y se rompe la garantía de orden por clave para las claves en curso, por lo que para un flujo ordenado se dimensionan las particiones desde el inicio y no se modifican.

IONOS CLOUD proporciona una regla de dimensionamiento concreta que vincula el número de particiones con la topología de brokers del clúster. Cada clúster de Event Streams for Apache Kafka ejecuta tres brokers independientemente de la plantilla de tamaño. La orientación es que el número de particiones debe ser igual o mayor que el número de brokers, y que se deben utilizar solo múltiplos del número de brokers (3, 6, 9, 12, y así sucesivamente) para evitar una distribución desigual de particiones entre brokers. Una distribución desigual deja un broker más activo que los demás y desperdicia la capacidad por la que se pagó. Si el alto rendimiento es una prioridad, la documentación sugiere 2x o 3x el número de brokers o más. Para el tema de eventos de cuenta de FinCorp, eso significa comenzar con 3 particiones y pasar a 6 o 9 solo cuando el rendimiento medido lo justifique, manteniéndose siempre en un múltiplo de tres.

Los grupos de consumidores y las offsets son la forma en que este diseño sobrevive a reinicios y escala hacia afuera. Un grupo de consumidores es un conjunto de consumidores que dividen cooperativamente las particiones de un tema entre ellos; Kafka rastrea, por grupo y por partición, la offset del último mensaje procesado. Dado que la offset se confirma de vuelta al clúster, un consumidor que se bloquea y se reinicia retoma desde donde el grupo lo dejó y no desde el principio, y agregar un consumidor al grupo desencadena un reequilibrio que redistribuye las particiones. Por esta razón, FinCorp puede ejecutar un grupo de consumidores para la puntuación de fraude en tiempo real y un segundo grupo, independiente, para el almacén de analíticas contra el mismo tema: cada grupo mantiene sus propias offsets y lee el flujo completo a su propio ritmo, y ninguno bloquea al otro.

2. La replicación y la retención como palancas de costo y fiabilidad

Dos configuraciones a nivel de tema se traducen directamente en su factura de almacenamiento y en su postura de durabilidad, y ambas son decisiones, no valores predeterminados que se deban aceptar a ciegas.

El factor de replicación es el número de copias de cada mensaje que se conservan en brokers distintos. IONOS CLOUD recomienda un factor de replicación de 3, lo que en un clúster de tres brokers significa una copia completa de la partición en cada broker, de modo que el tema sobrevive a la pérdida de brokers sin pérdida de datos y la conmutación por error automática y la replicación del clúster mantienen el flujo de la canalización. El costo es multiplicativo: con un factor de replicación de 3, el almacenamiento que consume un tema es tres veces su volumen bruto de mensajes. La nota de dimensionamiento de IONOS CLOUD lo deja explícito, advirtiendo que el consumo final de almacenamiento puede ser varias veces el volumen de datos entrantes, dependiendo del factor de replicación configurado. Un factor más bajo ahorra almacenamiento, pero sacrifica la tolerancia a fallos; para los datos transaccionales regulados de FinCorp, 3 es el límite inferior adecuado.

La retención determina cuánto tiempo permanecen los mensajes antes de ser eliminados, y es la otra gran palanca de almacenamiento. El tiempo de retención se establece en milisegundos, tiene un valor predeterminado de 604800000 (7 días), y un valor de -1 significa sin límite de tiempo. Existe un tamaño de segmento de retención complementario en bytes (el tamaño al que se realiza el cambio de segmento de registro, con un valor predeterminado de 1073741824, que es 1 GB, y un límite inferior documentado de 14 bytes), y un límite de tamaño de retención que elimina los mensajes más antiguos una vez que se alcanza el límite total de tamaño del tema. Dimensionar el clúster es, por lo tanto, un problema de aritmética de retención. La documentación proporciona un ejemplo resuelto: tres temas, cada uno con retención de siete días a 500 KB por segundo, requieren un mínimo de aproximadamente 866 GB de almacenamiento total antes de contar siquiera la replicación. Las plantillas de clúster fijan el almacenamiento que obtiene:

Lea esta tabla como un presupuesto, no como un menú de niveles de velocidad: usted selecciona el tamaño según el ancho de banda y la retención que sus temas exigen, y luego verifica que el almacenamiento total del clúster supere con holgura el volumen bruto multiplicado por el factor de replicación durante la ventana de retención. El flujo transaccional de siete días con factor de replicación 3 de FinCorp lo lleva más allá de la plantilla S incluso con tasas de ingesta moderadas, por lo que M es el punto de partida realista con margen para un segundo tema.

Un matiz de retención que vale la pena mencionar porque la plataforma lo soporta: la compactación de registros de Kafka conserva solo el valor más reciente para una clave dada, en lugar de eliminar por antigüedad, lo cual es adecuado para un tema que representa el estado actual (el saldo más reciente por cuenta, por ejemplo) en lugar de un historial de eventos. Es un modo de retención diferente de la eliminación basada en tiempo o tamaño; utilícelo solo cuando el tema modele genuinamente un estado con clave, y no asuma que está activado de forma predeterminada.

3. El flujo como sustituto y columna vertebral

Aquí es donde la transmisión de eventos (event streaming) justifica su lugar en el modelo de sustitución nativa de la plataforma. Las bases de datos administradas de IONOS CLOUD no exponen un flujo de captura de datos cambiados (change-data-capture) al que se pueda suscribir, por lo que no es posible seguir el registro de transacciones de la base de datos para impulsar a los consumidores aguas abajo. El patrón nativo consiste en invertir la dependencia: en lugar de extraer los cambios de la base de datos a posteriori, la aplicación publica un evento de dominio en un tema de Kafka en el momento en que realiza el cambio, y todos los sistemas aguas abajo (el almacén de analítica, el modelo de fraude, un índice de búsqueda, un archivo de auditoría) consumen ese tema. El flujo se convierte en la fuente de verdad para la propagación de cambios, la base de datos se convierte en una proyección más del lado del consumidor, y FinCorp obtiene la distribución en abanico (fan-out) que un flujo CDC le habría proporcionado, sin contar con una funcionalidad que la plataforma no ofrece. La disciplina que esto exige es que la escritura en la base de datos y la publicación en el tema se traten como una única operación lógica en la aplicación, ya que la plataforma no ofrece un puente automático entre ambas.

El mismo flujo es la columna vertebral de ingesta hacia la capa de IA. Los modelos de FinCorp no llaman directamente a la base de datos transaccional; consumen los temas de eventos, lo que proporciona a las cargas de trabajo de IA un flujo desacoplado y reproducible que pueden volver a leer desde un desplazamiento confirmado siempre que un modelo se entrene de nuevo. Dos puntos finales cierran el ciclo y ambos dependen de Object Storage. Primero, el archivo: la exportación de datos en lote está disponible, pero no es de autoservicio; es un proceso mediante ticket de soporte (número de contrato, PIN de soporte y una clave PGP, tras lo cual IONOS CLOUD entrega un archivo cifrado a su bucket de Object Storage), por lo que la cola larga de eventos que ha superado la ventana de retención caliente se exporta a Object Storage solo después de esa solicitud, y una retención corta del clúster es un diseño viable solo si la cadencia del archivo tiene en cuenta ese tiempo de anticipación manual. Segundo, la cola de mensajes no procesados (dead-letter): los mensajes que un consumidor no puede procesar se enrutan a un tema de mensajes no procesados separado y, para una retención forense duradera, se vacían en Object Storage, donde el bloqueo de objetos (object lock) los hace evidentes ante cualquier manipulación. Los brokers se mantienen ligeros para el tráfico en vivo; el almacenamiento lento, económico e inmutable absorbe el archivo y las fallas.

La seguridad en el plano de datos es TLS mutuo, y el modelo es estricto. La comunicación con el clúster está protegida con TLS y ambas partes se autentican: el cliente verifica el certificado del clúster y el clúster verifica el certificado del cliente. Dado que el clúster no utiliza certificados firmados públicamente, los clientes validan el servidor contra la propia autoridad de certificación del clúster, y el clúster mantiene una CA de clientes que firma el certificado de cada usuario autenticado. Cada certificado es válido durante 365 días, y un certificado renovado está disponible para su recuperación desde la API de credenciales de usuario 30 días antes de su vencimiento, que es la ventana a la que apunta su libro de procedimientos de rotación. La API de administración, por el contrario, se autentica con un token Bearer y es accesible públicamente en un punto final por región (kafka.<region>.ionos.com); solo el protocolo del plano de datos de Kafka en los brokers es exclusivo de LAN privada, sin punto final público, por lo que el perímetro de seguridad del plano de datos es la red privada más el apretón de manos mTLS, mientras que el perímetro de la API de administración es el control mediante token Bearer (privilegio de IAM acotado, manejo y rotación de tokens).

Guía de implementación de DCD

Provisionará un clúster de Event Streams for Apache Kafka con tres brokers en la LAN privada de la capa de datos de FinCorp y creará un tema con la estructura adecuada para el flujo de eventos de cuenta. El objetivo de la arquitectura es la columna vertebral de ingesta de la Sección 3: un flujo privado, protegido con mTLS y dimensionado para una ventana de retención de siete días con un factor de réplica de 3, con un número de particiones que respete tanto el orden como la topología de los brokers. El clúster no tiene un punto de acceso público, por lo que el trabajo se realiza por completo dentro del VDC que construyó anteriormente en el curso.

Objetivo de construcción: Crear un clúster y un tema con una estructura adecuada.

Requisitos previos: Un Virtual Data Center aprovisionado que contenga al menos una VM en una LAN privada; esa VM accede al clúster a través de la LAN privada y cuenta contra su cuota contractual. Decida de antemano las direcciones IP de los brokers: estas deben pertenecer a la misma subred que la LAN que seleccione.

Pasos (en Data Center Designer):

1. Abra la sección Event Streams for Apache Kafka y haga clic en Create cluster.
2. Establezca Cluster Name con un nombre único e identificable, y seleccione Kafka Version (la versión 4.0.0 es la versión admitida; las versiones 3.9.0 y 3.9.1 están deprecadas, y los clústeres existentes en esas versiones continúan funcionando).
3. Elija el Cluster Size (de XS a XL) según sus requisitos de capacidad de transferencia y retención. Para el flujo de FinCorp con retención de siete días y factor de réplica de 3, dimensione a partir de la tabla de almacenamiento de la Sección 2 en lugar de suponer; M es el límite inferior realista.
4. Seleccione la Location (región) para el clúster. La región fija la ubicación geográfica, la latencia y la residencia regulatoria, por lo que elija el centro de datos alemán para los datos regulados de FinCorp.
5. Elija el Datacenter y la Datacenter LAN. Seleccione la LAN privada de la capa de datos; el clúster solo será accesible en esta red.
6. Configure las direcciones de los brokers que los clientes utilizarán para conectarse. Las direcciones IP deben pertenecer a la misma subred que la LAN seleccionada en el paso anterior, para que la enrutación dentro del clúster funcione. Utilice la pista de subred de la pantalla de DCD para confirmar el rango.
7. Revise los costos estimados mostrados para la entrada (una estimación que excluye variables como el tráfico) y, a continuación, haga clic en Save para desplegar. Monitoree el progreso hasta que el clúster alcance el estado Available.
8. Con el clúster en estado Available, ábralo, seleccione la pestaña Topics y haga clic en Create topic.
9. En el diálogo Create Topic, establezca: Name; Replication Factor (use 3); Number of Partitions (un múltiplo de los tres brokers: 3 para comenzar, 6 o 9 si la capacidad de transferencia lo exige); Retention Time (ms) (604800000 para siete días, o -1 para sin límite de tiempo); y Retention Segment Size (B) (valor predeterminado 1073741824, con un mínimo de 14 bytes). Haga clic en Create.

Para utilizar el clúster posteriormente, recupere el certificado de cliente por usuario desde la API de credenciales y valide el broker contra la CA del clúster; la API devuelve el certificado en formato PEM, por ejemplo:

curl --location https://kafka.<region>.ionos.com/clusters/${clusterId}/users/${userId}/access \
  --header "Authorization: Bearer ${personalToken}" | yq -r '.metadata.certificate' > client-cert.pem

Esta única llamada ilustra el límite arquitectónico, no un laboratorio de configuración: el plano de datos utiliza mTLS, por lo que un cliente sin un certificado firmado por una CA no puede conectarse en absoluto, y el ciclo de vida del certificado (validez de 365 días, renovación disponible con 30 días de antelación) es una tarea operativa que el equipo debe gestionar.

Errores comunes:

• Establecer un número de particiones que no sea un múltiplo del número de brokers. Utilice múltiplos de tres (3, 6, 9, 12) para que las particiones se distribuyan de manera uniforme; una distribución desigual sobrecarga un broker y desperdicia capacidad pagada.
• Considerar el número de particiones como ajustable posteriormente. Agregar particiones recalcula las claves y rompe el orden por clave para las claves en curso, por lo que debe dimensionar las particiones de un flujo ordenado desde el inicio.
• Subdimensionar el clúster en relación con la retención. Multiplique la ingesta bruta por la ventana de retención y luego por el factor de replicación; el caso de 7 días con factor de replicación 3 puede ser varias veces el volumen bruto, y una vez alcanzado el límite de almacenamiento, los mensajes más antiguos se eliminan.
• Elegir las direcciones IP de los brokers fuera de la subred de la LAN seleccionada. Deben estar en la misma subred, o los brokers no podrán enrutar hacia los clientes.
• Olvidar el requisito previo de LAN privada: debe existir primero un VDC con una VM en una LAN privada, y no hay un punto de acceso público, por lo que la conectividad y la ruta del certificado mTLS son la única forma de acceso.
• Permitir que los certificados del cliente caduquen. Cada uno tiene una validez de 365 días, con renovación disponible 30 días antes de la expiración; integre la recuperación y la rotación en el manual de operaciones.

Resumen

La forma del tema es la arquitectura: la cantidad de particiones fija el orden por clave y limita la paralelización de los grupos de consumidores, y en IONOS CLOUD debe ser un múltiplo de los tres brokers; el factor de replicación (se recomienda 3) y la retención (7 días por defecto, -1 para ilimitado) son las palancas de costo y fiabilidad que dimensionan el clúster. El flujo también es la respuesta nativa de la plataforma a dos vacíos, sustituyendo al flujo de captura de cambios de datos de una base de datos mediante la publicación de eventos a nivel de aplicación y sirviendo como columna vertebral de ingesta reproducible hacia la capa de IA, con Object Storage a cargo del archivo envejecido y la cola de mensajes con error. La construcción consiste en un clúster privado, protegido con mTLS, en la LAN de la capa de datos, más un único tema bien dimensionado, calculado a partir de la tabla de almacenamiento y no por conjetura.

Puntos clave:

• Una partición es la unidad tanto del orden (por clave) como de la paralelización de consumidores (un consumidor por partición por grupo); dimensione las particiones como un múltiplo de los tres brokers y de antemano para flujos ordenados.
• El factor de replicación 3 es el nivel mínimo de durabilidad recomendado y multiplica el almacenamiento aproximadamente por tres; el tiempo de retención (604800000 ms / 7 días por defecto, -1 para sin límite) y el tamaño de segmento determinan el resto de la factura de almacenamiento.
• Los grupos de consumidores rastrean los desplazamientos confirmados por partición, por lo que los grupos independientes leen el mismo tema a su propio ritmo y sobreviven a reinicios sin reprocesar.
• La publicación de eventos a nivel de aplicación es el sustituto nativo del flujo de captura de cambios de datos de base de datos ausente, y los mismos temas son el flujo reproducible hacia la capa de IA.
• Object Storage es el archivo (mediante exportación masiva de datos) y la cola duradera de mensajes con error; los brokers se mantienen ligeros para el tráfico en vivo.
• El plano de datos utiliza TLS mutuo frente a la CA propia del clúster con certificados de 365 días (renovación 30 días antes); la API de gestión utiliza un token Bearer; el clúster es solo de LAN privada.

Terminología importante:

• Partición: La unidad de orden y paralelización dentro de un tema. El orden solo está garantizado dentro de una partición; un grupo de consumidores asigna cada partición a como máximo un miembro.
• Grupo de consumidores: Un conjunto de consumidores cooperativos que dividen las particiones de un tema y comparten desplazamientos confirmados, permitiendo un consumo paralelo, reanudable e independiente.
• Factor de replicación: El número de copias residentes en brokers de cada mensaje; se recomienda 3, y es un multiplicador directo del consumo de almacenamiento.
• Retención: La política (tiempo, tamaño o compactación de registro) que gobierna cuánto tiempo persisten los mensajes antes de ser purgados o compactados.
• mTLS: TLS mutuo en el que el cliente y el clúster se autentican mutuamente frente a la autoridad de certificación del clúster; la única vía hacia el plano de datos privado.

Lectura adicional

• Unidad 5.2: Object Storage (el destino para el archivo, las cartas muertas y el corpus de entrenamiento)
• Unidad 5.3: Bases de datos relacionales (el lado de escritura que publica eventos de dominio)
• Unidad 6.5: AI Inference - Managed Model Hub (el consumidor al final de la columna vertebral de ingesta)
• IONOS CLOUD Architecture Center