¿Cómo debería migrar Kafka Streams al protocolo de rebalanceo impulsado por el broker?

Planteamiento y alcance

Eres responsable de una aplicación con estado de Kafka Streams que utiliza el protocolo de grupo clásico. Tras actualizar a Kafka 4.2, el equipo desea utilizar el Streams Rebalance Protocol impulsado por el broker para reducir las pausas de coordinación global cuando las instancias se unen, salen o fallan. El entrevistador solicita un plan de migración, los límites de compatibilidad y el rollback.

Asume Kafka Streams 4.2.x, topics de changelog y repartition existentes, y ninguna reconstrucción completa de estado no planificada. La guía oficial indica que el nuevo protocolo calcula continuamente las asignaciones de tareas en los brokers y utiliza un streams group dedicado. Los nuevos clústeres de Kafka 4.2 habilitan la funcionalidad por defecto, pero los clientes aún configuran group.protocol=streams.

Qué evalúa el entrevistador

• Si explicas cómo la coordinación impulsada por el broker elimina una barrera global del lado del cliente en lugar de simplemente recitar una configuración.
• Si distingues entre un nuevo streams group, una actualización en línea del grupo clásico y la migración fuera de línea soportada.
• Si verificas las versiones del broker y del cliente y el riesgo de KAFKA-20254 en 4.2.0.
• Si sabes que los offsets confirmados (committed) se preservan mientras que otros metadatos del grupo se reconstruyen.
• Si conviertes la falta de static membership, de actualizaciones de topología y de soporte para regex en criterios de bloqueo (release gates).

Una respuesta débil dice "cambia la configuración y haz un despliegue progresivo (rolling)". Una respuesta sólida hace un inventario de brechas de versiones y funcionalidades, elige entre un nuevo grupo o una migración con ventana de mantenimiento, y registra offsets, changelog, topics de repartition y objetivos de recuperación.

Aclaraciones antes de responder

1. ¿Están tanto Kafka como el cliente de Streams al menos en 4.2? De lo contrario, no se puede habilitar el protocolo completo de forma segura.
2. ¿Depende la aplicación de static membership, actualizaciones de topología en línea, suscripciones por regex o asignación standby/rack-aware? Cualquier dependencia puede bloquear la migración.
3. ¿Pueden detenerse todas las instancias mientras el grupo queda vacío? La ruta oficial de 4.2 solo soporta migración fuera de línea (offline).
4. ¿Es la versión 4.2.0 o 4.2.1 y posterior? 4.2.0 tiene un bug conocido en el broker durante la migración fuera de línea, corregido en 4.2.1.
5. ¿Se puede utilizar un nuevo application.id? Un nuevo grupo aísla el riesgo pero reconstruye el estado y cambia la gestión de offsets.

Estas respuestas cambian el plan: si el tiempo de inactividad es imposible, no afirmes que habrá una migración en línea; si se requiere una funcionalidad no soportada, permanece en el protocolo clásico o refactoriza primero.

Estructura de respuesta de 30 segundos

"Primero verifico que los brokers y clientes estén en 4.2.x e inventario las funcionalidades que el nuevo protocolo no soporta. El Streams Rebalance Protocol traslada la coordinación de tareas a los brokers y elimina una barrera global del lado del cliente, pero la migración no es un despliegue progresivo normal. La ruta documentada deja el grupo vacío, configura group.protocol=streams e inicia las instancias. Solo los offsets confirmados se preservan; los topics de changelog y repartition permanecen, mientras que otros metadatos del grupo se reconstruyen. Evitaría 4.2.0 y usaría 4.2.1 o posterior, registraría offsets y checkpoints de estado, verificaría la recuperación, la latencia y las métricas de rebalanceo, y haría rollback al clásico o reconstruiría con un nuevo ID de aplicación si las comprobaciones fallan".

Solución paso a paso

1. Explicar qué cambia

Los grupos clásicos de Streams calculan las asignaciones de tareas de los miembros en los clientes, lo que puede crear un punto de coordinación global durante los cambios de membresía. El nuevo protocolo almacena los metadatos del streams group y la asignación de tareas en los brokers; las aplicaciones se coordinan a través de un heartbeat dedicado y un streams group. La guía oficial describe esto como impulsado por el broker y proporciona estados de streams-group y APIs de Admin independientes.

2. Inventariar brechas de capacidad

Kafka 4.2 documenta límites claros: static membership no está disponible; las actualizaciones significativas de topología requieren un nuevo streams group; solo se soporta el sticky task assignor, por lo que las tareas de warmup y la asignación rack-aware no están disponibles; las suscripciones por patrones (pattern) no son compatibles; y la migración en línea entre grupos clásicos y streams groups no está disponible. Incluye estos puntos en la lista de verificación de lanzamiento antes de cambiar un protocolo.

3. Elegir la ruta de migración

La ruta fuera de línea documentada es: detener todas las instancias, esperar a session.timeout.ms o salir explícitamente para que el grupo quede vacío, configurar group.protocol=streams e iniciar las instancias. Solo los offsets confirmados se retienen en el broker. Los topics de changelog y repartition siguen siendo topics internos ordinarios; otros metadatos del grupo se reconstruyen.

Stop all instances
      ↓
Confirm an empty streams group and record committed offsets
      ↓
Upgrade brokers and clients to a compatible version
      ↓
Set group.protocol=streams
      ↓
Start instances and observe recovery and rebalance metrics

Si una ventana de mantenimiento es inaceptable, mantén el protocolo clásico o utiliza un nuevo application.id para una validación en paralelo (shadow). No traslades las suposiciones de actualización progresiva de los consumidores clásicos al Streams Rebalance Protocol.

4. Manejar el riesgo de versión

La guía de actualización de Kafka advierte que la migración fuera de línea de clásico a streams en 4.2.0 está afectada por el bug del lado del broker KAFKA-20254 y no la recomienda. La corrección se encuentra en 4.2.1. En una entrevista, define 4.2.1 como la versión mínima de migración en lugar de solo decir que "Kafka 4.2 lo soporta".

5. Diseñar comprobaciones de estado y offsets

Antes de la migración, registra los offsets confirmados para cada topic de entrada, el estado del changelog y la latencia de procesamiento. Tras la migración, verifica que el nuevo grupo se reanude desde los offsets esperados, que los almacenes de estado (state stores) se restauren desde los changelogs, que los topics de repartition aún existan con el mismo número de particiones y que los registros duplicados o faltantes coincidan con la semántica de procesamiento acordada. Compara contra una línea base previa a la migración en lugar de solo verificar el inicio del proceso.

6. Monitorear y hacer rollback

Utiliza el estado del streams-group, el conteo/tasa de rebalanceos, la duración de la recuperación, la latencia de procesamiento y la tasa de errores como superficie de observación. Si la recuperación excede el tiempo límite o las comprobaciones de resultados fallan, detén el nuevo grupo, preserva los offsets y logs, y revierte la configuración a clásico. Si el grupo clásico ya se había vaciado, la recuperación requiere una copia de respaldo o un nuevo ID de aplicación; los metadatos del grupo no volverán por arte de magia.

Ejemplo de respuesta de alta calidad

"No trataría esto como un lanzamiento progresivo normal. Primero verifico brokers y clientes en 4.2.x y reviso si hay static membership, actualizaciones de topología en línea, suscripciones por regex, warmup o asignación rack-aware. Dado que la ruta oficial es fuera de línea, elijo 4.2.1 o posterior, detengo todas las instancias en una ventana de mantenimiento, confirmo un grupo vacío, registro los offsets confirmados y los checkpoints del state store, y luego configuro group.protocol=streams.

"Tras el cambio, verifico que los offsets continúen, que los changelogs restauren los state stores, que los topics de repartition permanezcan y que el estado del streams-group, las métricas de rebalanceo, el tiempo de recuperación y la latencia de negocio sean saludables. Solo los offsets confirmados se preservan; otros metadatos del grupo se reconstruyen. 4.2.0 conlleva el riesgo de KAFKA-20254, por lo que no la llamaría una versión de migración segura. Si la validación falla, detengo el nuevo grupo, regreso a clásico o reconstruyo con un nuevo ID de aplicación y conservo la evidencia para su revisión".

Errores comunes

• Error: tratar group.protocol=streams como un cambio progresivo (rolling switch) → Por qué falla: la migración en línea no está soportada → Solución: programar una ventana de mantenimiento con grupo vacío.
• Error: migrar en 4.2.0 → Por qué falla: la guía de actualización oficial registra KAFKA-20254 → Solución: usar 4.2.1 o posterior con la corrección.
• Error: prometer que todo el estado del grupo se preserva → Por qué falla: solo los offsets confirmados permanecen y otros metadatos se reconstruyen → Solución: registrar comprobaciones separadas de offsets, state-store y topics.
• Error: ignorar static membership o actualizaciones de topología → Por qué falla: el nuevo protocolo aún no las soporta → Solución: inventariar funcionalidades y permanecer en clásico cuando sea necesario.

Preguntas de seguimiento y respuestas

El negocio no puede detenerse. ¿Pueden dos lotes de instancias cambiar gradualmente?

No describas eso como la migración documentada de Streams. Si el tiempo de inactividad es imposible, mantén clásico o crea un nuevo ID de aplicación para validación en paralelo (shadow), y luego permite que la capa de negocio absorba el costo de reconstrucción de estado de una transición (cutover).

¿Por qué validar el state store si los offsets confirmados sobreviven?

Un offset indica dónde leer a continuación, no que el estado local esté completo. La reproducción del changelog, las incompatibilidades o los fallos de procesamiento pueden hacer que el state store sea inconsistente con el offset, por lo que se debe validar el estado y los resultados de negocio.

4.2.0 es GA. ¿Por qué evitarla?

GA significa que la funcionalidad fue lanzada, no que cada ruta de migración esté libre de defectos conocidos. La guía oficial identifica KAFKA-20254 en la migración fuera de línea y establece que está corregido en 4.2.1; elige la versión con la corrección, no la etiqueta de GA.

La aplicación utiliza suscripciones por regex. ¿Qué hacer ahora?

El nuevo protocolo de streams no soporta suscripciones a topics basadas en patrones. Permanece en clásico o cambia el descubrimiento a una lista explícita de topics antes de reconsiderar la migración; cambiar únicamente el protocolo de grupo no es suficiente.

¿Cómo decides si utilizar un nuevo ID de aplicación?

Utiliza uno cuando se requiera validación en paralelo, el grupo antiguo no se pueda vaciar de forma segura o deba aislarse el riesgo de recuperación de estado. El costo radica en el reprocesamiento, la reconstrucción del state store y los recursos adicionales, por lo que primero debes estimar el tiempo de recuperación y el almacenamiento.

Referencias

• Guía para desarrolladores de Apache Kafka Streams Rebalance Protocol.
• Guía de actualización de Apache Kafka 4.2 Streams.
• Anuncio de lanzamiento de Apache Kafka 4.2.0.