Unidad 5.6: Transmisión de eventos (Managed Kafka)

Introducción

La decisión fundamental en la transmisión de eventos no es la provisión del Cluster, sino la forma del tema. La cuenta de particiones fija tanto la garantía de ordenación como el límite en la paralelización del consumidor para la vida de ese tema, y el factor de replicación y la retención juntos deciden cuánto se paga para mantener los datos seguros y durante cuánto tiempo. Obtener la forma del tema correcta y el Cluster es casi incidental. Obtenerlo mal y se descubre el límite en producción, donde las particiones no se pueden reducir y una reconfiguración significa un nuevo tema y una migración.

Esta unidad trata al Event Streams for Apache Kafka como la columna vertebral de transmisión para FinCorp, la empresa de servicios financieros alemana que lleva las obligaciones GDPR y BSI a través de su migración y su nueva capacidad de inteligencia artificial. Comenzamos en la decisión de diseño del tema, explicamos cómo interactúan las particiones, los grupos de consumidores, la replicación y la retención, mostramos dónde se encuentra el flujo en la arquitectura más amplia, y luego creamos un Cluster y un tema correctamente configurado en el Data Center Designer.

1. El tema es la arquitectura: particiones, ordenación y paralelismo

Una partición es la unidad de ordenación y paralelismo, y esas dos propiedades tiran en la misma dirección, lo que hace que el recuento de particiones sea la decisión que más importa. Kafka mantiene el orden de los mensajes dentro de una partición; no hace ninguna promesa de ordenación entre particiones. Así que si FinCorp debe procesar todos los eventos para una cuenta determinada en el orden en que ocurrieron, cada evento para esa cuenta debe llegar a la misma partición. La forma estándar de garantizar eso es establecer una clave de partición (el identificador de la cuenta) para que el productor haga un hash en una partición fija. La ordenación es, por lo tanto, una propiedad por clave, no por tema: obtienes un orden estricto dentro de cada clave y concurrencia entre claves, lo que es exactamente lo que un flujo de transacciones de alta Volume quiere.

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 recuento de particiones es el límite duro de cuántos consumidores pueden trabajar en ese tema en paralelo. Tres particiones significan como máximo tres consumidores activos; un cuarto se mantiene inactivo. Más particiones permiten un mejor equilibrio de carga entre consumidores y mejoran el rendimiento, pero también multiplican los controladores de archivos abiertos, el tráfico de replicación y el tiempo de reequilibrio, por lo que el recuento se ajusta al rendimiento que realmente se espera, no se infla de manera especulativa. La asimetría que se debe internalizar es que generalmente se pueden agregar particiones más adelante, pero agregarlas rehasha el mapeo de clave a partición y rompe la garantía de ordenación por clave para claves en vuelo, por lo que para un flujo ordenado se dimensionan las particiones de antemano y se dejan en paz.

IONOS proporciona una regla de dimensionamiento concreta que relaciona el recuento de particiones con la topología del broker de Cluster. Cada Event Streams for Apache Kafka Cluster ejecuta tres brokers independientemente del tamaño del modelo. La guía 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 recuento de brokers (3, 6, 9, 12, etc.) para evitar una distribución desigual de particiones entre brokers. Una distribución desigual deja un broker más caliente que los demás y desperdicia la capacidad que se pagó. Si el alto rendimiento es una prioridad, la documentación sugiere 2x o 3x el recuento 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, siempre manteniéndose en un múltiplo de tres.

Los grupos de consumidores y los desplazamientos son cómo este diseño sobrevive a los reinicios y se escala. Un grupo de consumidores es un conjunto de consumidores que cooperativamente dividen las particiones de un tema entre sí; Kafka realiza un seguimiento, por grupo y por partición, del desplazamiento del último mensaje procesado. Debido a que el desplazamiento se confirma de regreso al Cluster, un consumidor que se bloquea y se reinicia se reanuda desde donde el grupo se detuvo en lugar de desde el principio, y agregar un consumidor al grupo desencadena un reequilibrio que redistribuye las particiones. Esta es la razón por la que FinCorp puede ejecutar un grupo de consumidores para puntuación de fraude en tiempo real y un segundo grupo, independiente, para el almacén de análisis contra el mismo tema: cada grupo mantiene sus propios desplazamientos y lee la secuencia completa a su propio ritmo, y ninguno bloquea al otro.

2. Replicación y retención como palancas de coste y confiabilidad

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

El factor de replicación es el número de copias de cada mensaje que se mantienen en brokers distintos. IONOS recomienda un factor de replicación de 3, que en un Cluster de tres brokers significa una copia completa de la partición en cada broker, por lo que el tema sobrevive a la pérdida de brokers sin pérdida de datos y el failover y la replicación automáticos de Cluster mantienen el flujo de la tubería. El coste es multiplicativo: con un factor de replicación de 3, el almacenamiento que consume un tema es tres veces su mensaje Volume bruto. La nota de tamaño de IONOS hace esto explícito, advirtiendo que el consumo de almacenamiento final puede ser varias veces el Volume de datos de entrada dependiendo del factor de replicación configurado. Un factor más bajo ahorra almacenamiento, pero sacrifica la tolerancia a fallos; para los datos de transacciones regulados de FinCorp, 3 es el piso correcto.

La retención decide cuánto tiempo se mantienen los mensajes antes de que se purguen, 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 que no hay límite de tiempo. Existe un tamaño de segmento de retención companion en bytes (el tamaño en el que se enrolla un segmento de registro, valor predeterminado 1073741824, que es 1 GB, con un piso documentado de 14 bytes) y un límite de tamaño de retención que purga los mensajes más antiguos una vez que se alcanza el límite de tamaño total del tema. Por lo tanto, el tamaño del Cluster es un problema de aritmética de retención. La documentación proporciona un ejemplo trabajado: tres temas, cada uno que retiene siete días a 500 KB por segundo, necesitan un mínimo de aproximadamente 866 GB de almacenamiento total antes de que se cuente la replicación. Las plantillas de Cluster fijan el almacenamiento que obtiene:

Lea esta tabla como un presupuesto, no como un menú de grados de velocidad: selecciona el tamaño según el rendimiento y la retención que demandan sus temas, luego verifique que el almacenamiento total de Cluster supere cómodamente el Volume bruto multiplicado por el factor de replicación durante la ventana de retención. La alimentación de transacciones de siete días y factor de replicación de 3 de FinCorp lo lleva más allá de la plantilla S incluso a tasas de ingesta modestas, por lo que M es el punto de partida realista con margen para un segundo tema.

Una sutileza de retención que vale la pena nombrar porque la plataforma lo admite: la compacción de registros de Kafka conserva solo el valor más reciente para una clave determinada en lugar de purgar por edad, lo que se adapta a un tema que representa el estado actual (el saldo más reciente por cuenta, por ejemplo) en lugar de una historia de eventos. Es un modo de retención diferente al de purga por tiempo o tamaño; úselo solo cuando el tema modela genuinamente un estado con clave, y no suponga que está activado por defecto.

3. El flujo como sustituto y columna vertebral

Este es el lugar donde la transmisión de eventos gana su lugar en el modelo de sustitución nativa de la plataforma. Las bases de datos gestionadas por IONOS no exponen un flujo de captura de datos de cambio al que puedas suscribirte, por lo que no puedes seguir el registro de transacciones de la base de datos para impulsar a los consumidores downstream. El patrón nativo es invertir la dependencia: en lugar de buscar cambios en la base de datos después del hecho, la aplicación publica un evento de dominio en un tema de Kafka en el momento en que realiza el cambio, y cada sistema downstream (el almacén de análisis, el modelo de fraude, un índice de búsqueda, un archivo de auditoría) consume 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 el abanico que un flujo de CDC le habría dado sin una función que la plataforma no vende. 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 operación lógica única en la aplicación, ya que la plataforma no ofrece un puente automático entre ellos.

El mismo flujo es la columna vertebral de ingesta en el nivel de IA. Los modelos de FinCorp no llaman directamente a la base de datos transaccional; consumen los temas de eventos, lo que da a las cargas de trabajo de IA una alimentación desconectada y reproducible que pueden volver a leer desde un desplazamiento comprometido cada vez que se vuelve a entrenar un modelo. Dos puntos finales cierran el bucle y ambos se apoyan en Object Storage. Primero, archivo: la exportación de datos en bloque está disponible pero no es de autoservicio, es un proceso de ticket de soporte (número de contrato, PIN de soporte y una clave PGP, después de lo cual IONOS entrega un archivo cifrado a su cubo Object Storage), por lo que la cola larga de eventos que ha envejecido más allá de la ventana de retención en caliente se exporta a Object Storage solo después de esa solicitud, y la retención corta Cluster es un diseño viable solo si el ritmo de archivo tiene en cuenta ese tiempo de espera manual. Segundo, la cola de cartas muertas: los mensajes que un consumidor no puede procesar se enrutan a un tema de cartas muertas separado y, para una retención forense duradera, se drenan a Object Storage donde el bloqueo de objeto los hace evidentes de manipulación. Los corredores permanecen delgados para el tráfico en vivo; el almacenamiento lento, barato e inmutable absorbe el archivo y los fallos.

La seguridad en el plano de datos es mutua TLS, y el modelo es estricto. La comunicación con Cluster es TLS segura con ambas partes autenticadas: el cliente verifica el certificado de Cluster y Cluster verifica el certificado del cliente. Debido a que Cluster no utiliza certificados firmados públicamente, los clientes validan el servidor contra la autoridad de certificación propia de Cluster, y Cluster mantiene una CA de cliente 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 las credenciales de usuario API 30 días antes de su vencimiento, lo que es la ventana que su libro de ejecución de rotación tiene como objetivo. La gestión API, por otro lado, se autentica con un token Bearer y es accesible públicamente en un punto final por región (Kafka.<región>.ionos.com); solo el protocolo de plano de datos Kafka en los corredores es privado-LAN solo sin punto final público, por lo que el perímetro de seguridad para el plano de datos es la red privada más el apretón de manos mTLS, mientras que el perímetro de la gestión API es control de token Bearer (privilegio IAM con alcance, control y rotación de tokens).

DCD Implementación paso a paso

Usted provisionará un Event Streams for Apache Kafka de tres brokers Cluster en el centro de datos privado de FinCorp LAN y creará un tema correctamente configurado para la alimentación de eventos de cuenta. El objetivo arquitectónico es la columna vertebral de ingesta de la Sección 3: un flujo privado, seguro con mTLS, dimensionado para una ventana de retención de siete días, con un factor de réplica de 3, y con un recuento de particiones que honra tanto el orden como la topología del broker. El Cluster no tiene un punto de conexión público, por lo que el trabajo se realiza entirely dentro del centro de datos virtual que usted construyó anteriormente en el curso.

Objetivo de construcción: Crear un Cluster y un tema bien configurado.

Requisitos previos: Un centro de datos virtual provisionado que contenga al menos un VM en un LAN privado; ese VM accede al Cluster a través del LAN privado y cuenta contra su cuota de contrato. Decida las direcciones del broker IP con anticipación: deben pertenecer a la misma subred que el LAN que seleccione.

Pasos (en el Data Center Designer):

1. Abra la sección Event Streams for Apache Kafka y haga clic en Crear Cluster.
2. Establezca Nombre de Cluster en un nombre único e identificable, y seleccione Versión de Kafka (la versión 4.0.0 es la versión compatible; 3.9.0 y 3.9.1 están obsoletas, y los clústeres existentes en esas versiones siguen funcionando).
3. Elija el Tamaño de Cluster (XS a XL) según sus requisitos de throughput y retención. Para la alimentación de siete días, con factor de réplica de 3, de FinCorp, elija el tamaño de la tabla de almacenamiento en la Sección 2 en lugar de adivinar; M es el piso realista.
4. Seleccione la Ubicación (región) para el Cluster. La región fija la ubicación geográfica, la latencia y la residencia normativa, así que elija el centro de datos alemán para los datos regulados de FinCorp.
5. Elija el Centro de datos y la Red de centro de datos LAN. Seleccione la red de datos privada LAN; el Cluster será accesible solo en esta red.
6. Configure las direcciones del broker 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 routificación dentro del Cluster funcione. Utilice la pista de subred de la pantalla DCD para confirmar el rango.
7. Revise los costos estimados que se muestran para la entrada (una estimación que excluye variables como el tráfico), luego haga clic en Guardar para implementar. Monitoree el progreso hasta que el Cluster alcance el estado Disponible.
8. Con el Cluster disponible, ábralo, seleccione la pestaña Temas y haga clic en Crear tema.
9. En el diálogo Crear tema, establezca: Nombre; Factor de réplica (utilice 3); Número de particiones (un múltiplo de los tres brokers: 3 para empezar, 6 o 9 si el throughput lo requiere); Tiempo de retención (ms) (604800000 para siete días, o -1 para no tener límite de tiempo); y Tamaño del segmento de retención (B) (predeterminado 1073741824, con un mínimo de 14 bytes). Haga clic en Crear.

Para utilizar el Cluster después, recupere el certificado de cliente por usuario de los credenciales API y valide el broker contra el Cluster CA; el API devuelve el certificado como 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 sola llamada ilustra el límite arquitectónico, no un laboratorio de configuración: el plano de datos es mTLS, por lo que un cliente sin un certificado firmado por una autoridad de certificación no puede conectarse en absoluto, y el ciclo de vida del certificado (validez de 365 días, renovación disponible 30 días antes) es una tarea operativa que el equipo posee.

Errores comunes:

• Establecer un recuento de particiones que no es múltiplo del recuento 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 a un broker y desperdicia la capacidad pagada.
• Tratar el recuento de particiones como ajustable más adelante. Agregar particiones reorganiza las claves y rompe el orden por clave para las claves en vuelo, así que dimensione las particiones de una fuente ordenada de antemano.
• Subestimar el Cluster contra 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 un factor de replicación de 3, puede ser varias veces la ingesta bruta Volume, y una vez que se alcanza el límite de almacenamiento, se purgan los mensajes más antiguos.
• Seleccionar las direcciones del broker IP fuera de la subred seleccionada LAN. Deben estar en la misma subred o los brokers no pueden enrutar a los clientes.
• Olvidar el requisito previo de la subred privada LAN: un centro de datos virtual con un VM en una subred privada LAN debe existir primero, y no hay un punto de conexión público, por lo que la conectividad y el camino del certificado mTLS son la única forma de acceder.
• Dejar que los certificados de cliente caducen. Cada uno es válido durante 365 días con una renovación disponible 30 días antes de la caducidad; incluya la recuperación y rotación en el cuaderno de ejecución.

Resumen

La forma del tema es la arquitectura: el recuento de particiones fija el orden por clave y limita el paralelismo del grupo de consumidores, y en IONOS debería ser un múltiplo de los tres brokers; el factor de replicación (recomendado 3) y la retención (predeterminada 7 días, -1 para ilimitado) son las palancas de coste y confiabilidad que dimensionan el Cluster. El flujo también es la respuesta nativa de la plataforma a dos brechas, sustituyendo un flujo de captura de datos de cambio de base de datos a través de la publicación de eventos a nivel de aplicación y sirviendo como la columna vertebral de ingesta reproducible en el nivel de inteligencia artificial, con Object Storage que lleva el archivo envejecido y la cola de cartas muertas. La construcción es un Cluster privado, seguro con mTLS, en el LAN de nivel de datos más un tema bien formado, dimensionado desde la tabla de almacenamiento en lugar de por conjeturas.

Puntos clave:

• Una partición es la unidad de orden (por clave) y paralelismo del consumidor (un consumidor por partición por grupo); dimensionar particiones como múltiplo de los tres brokers y de antemano para feeds ordenados.
• El factor de replicación 3 es el piso de durabilidad recomendado y multiplica el almacenamiento aproximadamente tres veces; el tiempo de retención (predeterminado 604800000 ms / 7 días, -1 para sin límite) y el tamaño del segmento impulsan el REST de la factura de almacenamiento.
• Los grupos de consumidores rastrean los desplazamientos comprometidos por partición, por lo que los grupos independientes leen el mismo tema a su propio ritmo y sobreviven a los reinicios sin reprocesar.
• La publicación de eventos a nivel de aplicación es el sustituto nativo de la ausente secuencia de captura de datos de cambio de base de datos, y los mismos temas son la alimentación reproducible en el nivel de inteligencia artificial.
• Object Storage es el archivo (a través de la exportación de datos en bloque) y la cola de cartas muertas duradera; los brokers se mantienen delgados para el tráfico en vivo.
• El plano de datos es mutuo TLS contra el Cluster propio CA con certificados de 365 días (renovación 30 días antes); el API de administración utiliza un token Bearer; el Cluster es solo LAN privado.

Terminología importante:

• Partición: La unidad de orden y paralelismo dentro de un tema. El orden está garantizado dentro de una partición solo; 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 comprometidos, lo que permite el consumo paralelo, reanudable e independiente.
• Factor de replicación: El número de copias residentes en el broker de cada mensaje; recomendado 3, y un multiplicador directo en el consumo de almacenamiento.
• Retención: La política (tiempo, tamaño o compacción de registro) que gobierna cuánto tiempo persisten los mensajes antes de ser purgados o compactados.
• mTLS: Autenticación mutua TLS donde el cliente y el Cluster se autenticitan entre sí contra la autoridad de certificación del Cluster; el único camino hacia el plano de datos privado.

Lectura adicional

• Unidad 5.2: Object Storage (el archivo, la carta muerta y el objetivo del corpus de entrenamiento)
• Unidad 5.3: Bases de datos relacionales (el lado de escritura que publica eventos de dominio)
• Unidad 6.5: Inferencia de IA - Centro de modelos gestionados (el consumidor al final de la columna vertebral de ingesta)
• Centro de arquitectura de IONOS Cloud