Errores del productor Kafka en Node.js: soluciones y optimización

Desafíos y soluciones al trabajar con el productor de Kafka en Node.js

Trabajar con Apache Kafka mediante la biblioteca cliente KafkaJS en Node.js requiere comprender no solo los conceptos fundamentales, sino también errores específicos que pueden degradar el rendimiento y la confiabilidad del sistema. En esta primera parte centrada en el productor, examinaremos problemas clave al publicar mensajes y métodos para resolverlos.

Errores de selección de partición

Elegir una partición para un mensaje es un paso crítico que afecta la distribución de carga entre los consumidores. Una lógica incorrecta de particionado puede provocar desequilibrios y pérdida de escalabilidad.

Un error común es usar una función de particionado basada en la división entera de la clave del mensaje (key). Si la clave no es un número o no se puede convertir adecuadamente a entero (por ejemplo, un MongoDB ObjectID), todos los mensajes terminarán en una sola partición.

const producer = await kafka.producer(topic, {
  createPartitioner: function () {
    return ({ partitionMetadata, message }: PartitionerArgs) => {
      return partitionMetadata.length
        ? partitionMetadata[Number(message.key) % partitionMetadata.length]?.partitionId || 0
        : 0;
    };
  },
});

En este caso, los consumidores del grupo no podrán distribuir eficientemente la carga, ya que toda la data se concentra en una sola partición.

Solución:

• Validar el tipo y formato de la clave de partición a nivel de productor.
• Configurar métricas para monitorear desequilibrios en el tamaño de las particiones.
• Usar algoritmos de particionado más confiables, como el hashing de claves de texto.

Publicación en particiones inexistentes

La numeración de particiones en un tema comienza desde 0. Si el productor intenta publicar un mensaje en un índice de partición superior al número disponible (por ejemplo, la partición 1 en un tema con solo una partición), KafkaJS no lanzará un error. El método send() devolverá un array vacío, y el mensaje quedará efectivamente sin escribir.

const result = await producer.send({
  topic: 'user_events',
  messages: [
    { key: '2', value: 'user_created', partition: 1 }
  ]
});
console.log(result); // []

Solución:

• Crear temas y particiones mediante archivos de configuración durante la implementación para evitar errores manuales.
• Validar la respuesta del método send() a nivel de aplicación. Si el resultado es vacío o contiene un error (por ejemplo, errorCode distinto de 0), tomar acciones: lanzar una excepción, registrar el evento, publicar en un tema de respaldo o enviar una métrica.
• Verificar periódicamente los metadatos del tema (lista de particiones disponibles) antes de enviar.

Uso ineficiente del productor

Crear una nueva instancia del productor (kafka.producer()) para cada solicitud o operación es un error común que genera un sobrecosto significativo. Cada nuevo productor establece conexiones de red pesadas con los brokers de Kafka.

app.post('/send-message', async (request) => {
  const { topic, message } = request.body;
  const producer = kafka.producer(); // Nueva instancia por solicitud
  // ...
});

Solución:

• Usar el patrón Singleton o un pool de productores. Crear una única instancia del productor y reutilizarla para todas las operaciones de publicación (producer.send()). Esto mejora el rendimiento y reduce la carga sobre los brokers.
• Para arquitecturas multi-hilo o microservicios, considerar el uso de un cliente Kafka compartido con un productor compartido.

Problemas de red y estrategia de reintento

La red entre el productor y el clúster de Kafka puede ser inestable. Para mejorar la fiabilidad de la entrega de mensajes:

• Configurar el manejo del evento request_timeout para rastrear problemas de red.

producer.on('producer.network.request_timeout', (error) => {
  console.error({
    code: 'producer_network_timeout',
    message: error.message,
    data: { stack: error.stack },
  });
})

• Configurar mecanismos de reintento (retry) al crear el productor. Por defecto, los reintentos están configurados en 5.

kafka.producer({
  retry: { retries: 10 }
});

Importante: Aumentar el número de intentos sin una estrategia adecuada (por ejemplo, sin aumentar los intervalos entre intentos) puede generar una carga similar a un ataque DDoS sobre los brokers. Usar configuraciones con intervalos crecientes (retroceso exponencial).

Manejo de mensajes grandes

Kafka no está diseñado para mensajes mayores de 1 MB. Publicar datos grandes (5–10 MB) provoca problemas graves:

• Rotación frecuente de segmentos: Con un tamaño máximo de segmento pequeño (por ejemplo, 512 MB), los mensajes grandes provocan una rotación rápida, aumentando la carga del sistema.
• Alto tráfico de red: Replicar mensajes grandes entre todos los In-Sync Replicas (ISR) incrementa la carga de red.
• Reducción del rendimiento: El buffer de mensajes del productor crece, aumentando el riesgo de pérdida de datos y tiempos de espera más largos para confirmaciones cuando acks=-1.
• Consumo de recursos: Se requiere más RAM para el os page cache en los brokers y para el JVM de Kafka, lo que incrementa la carga del CPU debido a la recolección de basura (GC).

Recomendaciones de tamaño de mensaje:

• Usar la fórmula: message.max.bytes = tamaño promedio del mensaje * 2, pero menos de 1MB.
• Para archivos grandes (video, audio, documentos), usar almacenamiento externo (por ejemplo, S3). Enviar solo una referencia al objeto en el mensaje de Kafka.
• Si se deben enviar grandes JSON/XML sin almacenamiento externo, el mensaje probablemente contenga datos redundantes para distintos consumidores. Considerar dividir el tema en múltiples temas especializados, cada uno con los campos mínimos necesarios.
• Una alternativa, aunque más compleja: dividir los mensajes grandes en fragmentos y reconstruirlos en el lado del consumidor.

Conclusiones principales

• Particionado: Un cálculo incorrecto de partición causa desequilibrio de carga y pérdida de escalabilidad. La validación de claves y el monitoreo de métricas son obligatorios.
• Existencia de partición: Publicar en una partición inexistente no genera un error en KafkaJS, pero el mensaje no se escribe. Validar la respuesta de send() es crucial.
• Eficiencia del productor: Crear un nuevo productor por solicitud es costoso. Usar Singleton o un pool.
• Red y reintentos: Configurar el manejo de tiempo de espera de red y estrategias de reintento mejora la fiabilidad de la entrega.
• Tamaño de mensaje: Enviar datos superiores a 1 MB afecta negativamente el rendimiento del clúster. Usar almacenamiento externo para archivos grandes y optimizar la estructura del mensaje.

— Editorial Team