Mejores prácticas para ejecutar Apache Kafka en AWS

Por Prasad Alle, Consultor Senior de Big Data de AWS.

NOTA: Esta publicación en el blog fue escrita antes del lanzamiento de Amazon MSK, un servicio totalmente administrado, de alta disponibilidad y seguro para Apache Kafka. Te recomendamos usar Amazon MSK en lugar de ejecutar tu propio clúster Apache Kafka en Amazon EC2. Si necesitas ejecutar Apache Kafka en Amazon EC2 entonces encontrarás que este blog sigue siendo útil.

Este post fue escrito en asociación con Intuit para compartir aprendizajes, mejores prácticas y recomendaciones para ejecutar un clúster de Apache Kafka en AWS. Gracias a Vaishak Suresh y a sus compañeros de Intuit por sus aportaciones y apoyo.

Intuit, en sus propias palabras: Intuit, un cliente empresarial líder para AWS, es creador de soluciones de gestión empresarial y financiera. Para obtener más información sobre cómo Intuit se asocia con AWS, consulta nuestra publicación anterior en el blog, Procesamiento de Stream en tiempo real usando Apache Spark Streaming y Apache Kafka en AWS. Apache Kafka es una plataforma de transmisión distribuida, es código abierto y te permite construir aplicaciones de streaming en tiempo real.

Las mejores prácticas descritas en esta publicación se basan en nuestra experiencia durante más de dos años, en la ejecución y operación de clusters Kafka a gran escala en AWS. Nuestra intención para esta publicación es ayudar a los clientes de AWS que actualmente ejecutan Kafka en AWS, y también a los clientes que están considerando migrar implementaciones locales de Kafka a AWS.

AWS ofrece Amazon Kinesis Data Streams, una alternativa a Kafka totalmente administrada.

Ejecutar Kafka en Amazon EC2 proporciona una solución escalable y de alto rendimiento para ingestar datos de streaming. AWS ofrece muchos tipos de instancias diferentes y combinaciones de opciones de almacenamiento para implementaciones de Kafka. No obstante, dada la cantidad de posibles topologías de despliegue, no siempre es trivial seleccionar la estrategia más adecuada para su caso de uso.

En esta publicación, cubrimos los siguientes aspectos de la ejecución de clusters Kafka en AWS:

Patrones de implementación y consideraciones
Opciones de almacenamiento
Tipos de instancias
Redes
Actualizaciones y mejoras
Ajuste de rendimiento
Monitoreo
Seguridad
Restauración y Copias de seguridad

Nota: Al implementar clusters Kafka en un entorno productivo, asegúrate también de considerar factores como; número de mensajes, tamaño de mensajes, monitoreo, manejo de fallas y cualquier problema operativo.

Patrones de implementación y consideraciones

En esta sección, discutimos varias opciones de implementación disponibles para Kafka en AWS, así como los pros y contras de cada opción. Una implementación exitosa comienza con una consideración reflexiva de estas opciones. Considerar disponibilidad, consistencia y sobrecarga operativa de la implementación nos ayuda a elegir la opción correcta.

Región única de AWS, tres zonas de disponibilidad, All Active

Un patrón de implementación típico (todo activo) consiste en una sola región de AWS con tres zonas de disponibilidad (AZs). Se despliega un cluster de Kafka en cada AZ junto con las instancias de productores y consumidores de Apache ZooKeeper y Kafka como se muestra en la siguiente imagen:

En este patrón, la implementación del cluster de Kafka sería la siguiente:

Los productores de Kafka y el cluster de Kafka se despliegan en cada AZ.
Los datos se distribuyen uniformemente en tres clusters de Kafka usando un Elastic Load Balancer.
Los consumidores de Kafka agregan los datos recibidos de los tres clusters de Kafka.

La recuperación ante fallas del cluster de Kafka ocurre de la siguiente manera:

Identificar todos los productores de Kafka
Detener los consumidores
Depurar y volver a lanzar a Kafka
Reiniciar los consumidores
Reiniciar a los productores de Kafka

A continuación, se describen los pros y los contras de este patrón.

Pros	Contras
Alta disponibilidad Puede soportar las fallas de dos AZs No hay pérdida de mensajes durante la recuperación de fallas Despliegue sencillo	Gastos operativos muy altos: Todos los cambios deben desplegarse 3 veces, uno por cada cluster de Kafka Mantenimiento y monitoreo de 3 clusters Mantenimiento y monitoreo de 3 clusters de consumidores

Es necesario reiniciar para aplicar parches y actualizar a los brokers en un cluster de Kafka. En este enfoque, se realiza una actualización gradual por separado para cada cluster.

Región única de AWS, tres zonas de disponibilidad, Active-Standby

Otro patrón típico de implementación (active-standby) consiste en una sola región de AWS con un único cluster de: Kafka, Kafka Broker y Zookeepers distribuidos en tres zonas AZs. Otro cluster Kafka similar actúa como un standby como se muestra en la siguiente imagen. Puede usar Kafka con MirrorMaker para replicar mensajes entre dos clusters.

En este patrón, la implementación del cluster de Kafka sería la siguiente:

Los productores de Kafka se despliegan en tres AZs.
Sólo se despliega un cluster de Kafka en tres AZs (activo).
Las instancias de ZooKeeper se despliegan en cada AZ.
Los Brokers se distribuyen uniformemente en las tres AZs.
Los consumidores de Kafka se pueden desplegar en cualquiera de las AZs.
La implementación está formada por los productores de Kafka en Standby y un cluster de Kafka Multi-AZ.

La recuperación ante fallas del cluster de Kafka ocurre de la siguiente manera:

Mueve el tráfico al cluster de productores de Kafka en Standby y al cluster de Kafka.
Reinicie a los consumidores para obtener datos del cluster de Kafka en Standby.

A continuación, se describen los pros y contras de este patrón.

Pros

Contras

Reducción en la carga operativa en comparación con la primera opción
Un único clúster Kafka que administrar y de donde consumir datos
Puede manejar fallas individuales por AZ sin activar un cluster Kafka en Standby

Incremento en latencia causado por la transferencia de datos entre AZs de los Brokers de Kafka
Para las versiones de Kafka anteriores a la 0.10, deberás asignar réplicas por particiones de tópico para ser distribuidas a los Broker en diferentes AZs (rack-awareness)
El clúster puede dejar de estar disponible en caso de un defecto de red, donde ZooKeeper no encontrará los Brokers de Kafka
Posibilidad de pérdida de mensajes en tránsito durante el proceso de recuperación de fallas

Intuit recomienda utilizar un solo clúster de Kafka en una región de AWS, con Brokers distribuidos en tres AZs (una sola región, tres AZs). Este enfoque ofrece una tolerancia a fallas más robusta, porque una falla en una AZ no causará tiempo de inactividad de Kafka.

Opciones de Almacenamiento

Existen dos opciones para el almacenamiento de archivos en Amazon EC2:

El almacenamiento efímero es local de la instancia de Amazon EC2. Puede proporcionar altos IOPS en función del tipo de instancia. Por otro lado, los volúmenes de Amazon EBS ofrecen mayor resiliencia y puede configurar IOPS en función de sus necesidades de almacenamiento. Los volúmenes de EBS también ofrecen algunas ventajas en cuanto al tiempo de recuperación. Su elección de almacenamiento estará directamente relacionada con el tipo de carga de trabajo que soportará el cluster de Kafka.

Kafka tiene incorporada tolerancia a fallas replicando particiones de datos a través de un número configurable de instancias. Si un broker falla, puede recuperarse a partir de los datos de todos los otros brokers en el cluster que almacenan réplicas. Dependiendo del tamaño de la transferencia de datos y el tráfico en la red, el proceso de recuperación podría verse afectado y esto a su vez eventualmente afectar el desempeño del cluster

En la siguiente tabla se muestran las recomendaciones sobre los diferentes tipos de almacenamiento:

Instance store

EBS

Se recomienda el Instance Storage para clusters Kafka grandes y medianos. Para un cluster grande, el tráfico de lectura/escritura se distribuye a través de un alto número de brokers, por lo que la pérdida de un broker tiene menos impacto. No obstante, para clústeres más pequeños, es importante una recuperación rápida en caso de nodos con fallas, pero un broker tarda más tiempo y requiere más tráfico de red para un cluster Kafka más pequeño.
Las instancias optimizadas para almacenamiento como h1, i3 y d2 son una opción ideal para aplicaciones distribuidas como Kafka.

La principal ventaja de usar EBS en una implementación de Kafka es que reduce significativamente el tráfico de transferencia de datos cuando un broker falla o debe ser reemplazado. El broker reemplazado se une al clúster mucho más rápido.
Los datos almacenados en EBS en caso de fallo o terminación de una instancia persisten. Los datos del broker almacenados en un volumen de EBS permanecen intactos, y se puede montar el volumen de EBS en una nueva instancia de EC2. La mayoría de los datos replicados para el broker de reemplazo ya están disponibles en el volumen de EBS y no es necesario copiarlos a través de la red desde otro broker. Sólo los cambios realizados después de la falla del broker original necesitan ser transferidos a través de la red. Eso hace que este proceso sea mucho más rápido.

Intuit elige a EBS por sus frecuentes cambios en los requerimientos de las instancias, entre otros beneficios proporcionados por EBS.

Generalmente, las implementaciones de Kafka usan un factor de replicación de tres. EBS ofrece replicación dentro del servicio, por lo que Intuit eligió un factor de replicación de dos en lugar de tres.

Tipos de Instancia

Elegir un tipo de instancia generalmente está impulsado por el tipo de almacenamiento requerido por sus aplicaciones de streaming en un cluster de Kafka. Si su aplicación requiere almacenamiento efímero, las instancias h1, i3 y d2 son la mejor opción.

Intuit utilizó instancias r3.xlarge para sus brokers y r3.large para ZooKeeper, con ST1 (HDD optimizado con capacidad de salida) EBS para su clúster Kafka.

Aquí te presentamos los muestreos de referencia de las pruebas de Intuit:

Configuración	Bytes del Broker (MB/s)
r3.xlarge ST1 EBS 12 brokers 12 partiticiones	Agregación Incremental 346.9

Si necesita almacenamiento de EBS, entonces AWS tiene una instancia r4 de nueva generación. La instancia r4 es superior a r3 de muchas maneras:

Tiene un procesador más rápido (Broadwell).
Optimización de EBS por defecto.
Cuenta con redes basadas en Elastic Network Adapter (ENA), con hasta 10 Gbps en los tamaños de instancia más pequeños.
Cuesta 20% menos que las r3.

Nota: Siempre es una mejor práctica revisar los últimos cambios en los tipos de instancias.

Redes y Conectividad

La red juega un papel muy importante en un sistema distribuido como Kafka. Una red rápida y confiable asegura que los nodos puedan comunicarse entre sí fácilmente. El rendimiento de red disponible controla la cantidad máxima de tráfico que Kafka puede manejar. El resultado de la red, combinado con el almacenamiento en disco, suele ser el factor rector para el dimensionamiento de clústeres.

Si espera que su clúster reciba un alto tráfico de lectura/escritura, seleccione un tipo de instancia que ofrezca un rendimiento de 10 Gb/s.

Además, elija una opción que mantenga el tráfico de red interbroker en la subred privada, ya que este enfoque permite a los clientes conectarse a los brokers. La comunicación entre brokers y clientes utiliza la misma interfaz de red y puerto. Para obtener más detalles, consulte la documentación sobre direccionamiento IP para instancias EC2.

Si está desplegando en más de una región de AWS, puede conectar las dos VPC en las dos regiones de AWS mediante la interconexión de VPC entre regiones. No obstante, tenga en cuenta los costos de red asociados a las implementaciones entre regiones y AZs.

Actualizaciones

Kafka no suele es cada vez mejor. Durante una actualización de Kafka, debes mantener a tus ser compatible con versiones anteriores, pero el soporte de compatibilidad con versiones anteriores clientes productores y consumidores en una versión igual o inferior a la versión desde la que estás actualizando. Una vez finalizada la actualización, puede comenzar a usar una nueva versión de protocolo y cualquier nueva característica que permita. Existen tres enfoques de despliegues disponibles:

Rolling o in-place

En un escenario de rolling o in place, se despliega y actualiza un broker de Kafka a la vez. Tome en consideración las recomendaciones para hacer reinicios uno a uno para evitar tiempos de inactividad para los usuarios finales.

Reducción de tiempo de inactividad

Si puede permitirse el tiempo de inactividad, puede bajar todo su clúster, actualizar cada broker de Kafka y luego reiniciar el clúster.

Blue/green

Intuit siguió el modelo de actualizaciones blue/green para sus cargas de trabajo, como se describe a continuación.

Si puedes permitirte crear un clúster Kafka separado y actualizarlo, te recomendamos ampliamente el escenario de actualización blue/green. En este escenario, te recomendamos que mantengas tus clusters actualizados con la última versión de Kafka. Para obtener más detalles adicionales sobre las actualizaciones de la versión de Kafka, consulte la documentación de despliegues de Kafka.

En la siguiente imagen se muestra un despliegue blue/green:

En este escenario, el plan de actualización funciona así:

Crear un nuevo cluster de Kafka en AWS.
Crear una nueva pila de productores de Kafka que apunten al nuevo cluster de Kafka.
Crear tópicos sobre el nuevo cluster de Kafka.
Probar el despliegue verde de extremo a extremo (sanity check)
Usando Amazon Route 53, cambie la nueva pila de productores de Kafka para apuntar al nuevo entorno verde de Kafka que has creado en AWS. El plan de roll-back funciona así:

El plan de roll-back funciona así:

Cambie en Amazon Route 53 a la antigua pila de productores de Kafka en AWS para señalar el antiguo entorno de Kafka.

Para obtener más detalles sobre la arquitectura de implementación azul/verde usando Kafka, consulte la presentación de re:Invent Aprovecha la nube con una arquitectura de implementación blue/green.

Optimizaciones de Rendimiento

Se puede optimizar el rendimiento de Kafka en múltiples dimensiones. A continuación, se presentan algunas mejores prácticas para la afinación del rendimiento.

Estas son algunas técnicas generales para mejorar el rendimiento:

Si el rendimiento es menor que la capacidad de red, prueba lo siguiente:
- Agregar más hilos
- Aumentar el tamaño de los lotes
- Agregar más productores
- Agregar más particiones
Para mejorar la latencia cuando acks =-1, aumenta tu valor replica.fetches.
Para transferencia de datos a otra AZ, ajustar la configuración del búfer para los sockets y para OS TCP.
Asegúrese de que io.threads sea mayor que el número de discos dedicados a Kafka.
Ajuste network.threads en función del número de productores más el número de consumidores más el factor de replicación.
El tamaño del mensaje afecta el ancho de banda de la red. Para obtener mayor rendimiento de un clúster Kafka, seleccione un tipo de instancia que ofrezca un rendimiento de 10 Gb/s.

Para optimizaciones de Java y JVM, intente lo siguiente:

Minimice las pausas GC con el JDK de Oracle, que utiliza el nuevo G1 garbage-first collector.
Intente mantener el tamaño del heap de Kafka por debajo de 4 GB.

Monitoreo

Saber si un clúster Kafka está funcionando correctamente en un entorno de producción es crítico. En ocasiones, sólo saber que el clúster está arriba es suficiente, pero las aplicaciones Kafka tienen muchas partes qué monitorear. De hecho, fácilmente puede llegar a ser confuso entender lo que es importante ver y lo que puedes dejar de lado. Las métricas para monitorear van desde algunas simples sobre la tasa general de tráfico, hasta productores, consumidores, corredores, controladores, ZooKeeper, tópicos, particiones, mensajes, etcétera.

Para el monitoreo, Intuit utilizó varias herramientas, entre ellas New Relic, Wavefront, Amazon CloudWatch y AWS CloudTrail. A continuación, se sigue nuestro enfoque de monitoreo recomendado.

Para las métricas del sistema, te recomendamos que supervises:

Carga de CPU
Métricas de Red y Conectividad
Uso de Manejo de Archivos
Espacio en Disco
Rendimiento en disco de E/S
Métricas del Recolector de Basura
Métricas de ZooKeeper

Para los productores, te recomendamos que monitorees:

Batch-size-avg
Compression-rate-avg
Waiting-threads
Buffer-available-bytes
Record-queue-time-max
Record-send-rate
Records-per-request-avg

Para los consumidores, te recomendamos que monitorees:

Batch-size-avg
Compression-rate-avg
Waiting-threads
Buffer-available-bytes
Record-queue-time-max
Record-send-rate
Records-per-request-avg

Seguridad

Al igual que la mayoría de los sistemas distribuidos, Kafka proporciona los mecanismos para transferir datos con una seguridad relativamente alta a través de los componentes involucrados. Dependiendo de su configuración, la seguridad podría implicar diferentes servicios como encriptación, Kerberos, certificados de Seguridad de la capa de transporte (TLS) y configuración de listas de controles de acceso avanzado (ACL) en brokers y ZooKeeper. A continuación, revisaremos el enfoque de Intuit. Para obtener más detalles sobre la seguridad de Kafka no cubiertos en esta sección, consulte la documentación de Kafka.

Cifrado en reposo

Para las instancias EC2 respaldadas por EBS, puede habilitar el cifrado en reposo utilizando volúmenes de Amazon EBS con cifrado habilitado. Amazon EBS utiliza AWS Key Management Service (AWS KMS) para el cifrado. Para obtener más detalles, consulte Amazon EBS Encryption en la documentación de EBS. Por instancias EC2 respaldadas por almacén de instancias, puede habilitar el cifrado en reposo mediante el cifrado de Amazon EC2 instance store .

Cifrado en transito

Kafka utiliza TLS para las comunicaciones con clientes e internodos.

Autenticación

La autenticación de conexiones a brokers desde los clientes (productores y consumidores) a otros brokers y herramientas utiliza ya sea Secure Sockets Layer (SSL) o Simple Authentication and Security Layer (SASL).

Kafka soporta la autenticación de Kerberos. Si ya tienes un servidor Kerberos, puedes agregar Kafka a tu configuración actual.

Autorización

En Kafka, la autorización es integrable y soporta de los servicios de autorización externa.

Respaldo y Copias de Seguridad

El tipo de almacenamiento utilizado en su implementación definirá su estrategia de copia de seguridad y restauración.

La mejor manera de hacer copias de seguridad de un clúster Kafka basado en instance store es configurar un segundo clúster y replicar mensajes usando MirrorMaker. La función de espejo de Kafka permite mantener una réplica de un cluster Kafka existente. Dependiendo de su configuración y requisitos, el clúster de copia de seguridad podría estar en la misma región de AWS que su clúster principal o en uno diferente.

Para implementaciones basadas en EBS, puede habilitar Snapshots automáticos de volúmenes de EBS para realizar copias de respaldo de sus volúmenes y crear fácilmente nuevos volúmenes de EBS a partir de estos Snapshots para restaurar. Te recomendamos almacenar archivos de copia de seguridad en Amazon S3.

Para obtener más información sobre cómo hacer copias de respaldo en Kafka, consulte la documentación de Kafka.

Conclusión

En esta publicación, discutimos varios patrones para ejecutar Kafka en la nube de AWS. AWS también proporciona una solución administrada alternativa con Amazon Kinesis Data Strems, o sin servidores que administrar o escalamiento de que preocuparse, puede cambiar el tamaño de su canalización de streaming en segundos sin tiempo de inactividad, la replicación de datos en todas las zonas de disponibilidad es automática, se beneficia de la seguridad hacia fuera de la caja, Amazon Kinesis Data Streams está estrechamente integrado con una amplia variedad de servicios de AWS como AWS Lambda, Amazon Redshift, Amazon OpenSearch (sucesor de Amazon Elasticsearch Service) y admite marcos de código abierto como Storm, Spark, Flink, y más. Puede referirse al conector kafka-kinesis.

Si tiene preguntas o sugerencias, por favor comente es la sección de abajo.

También leer

Si esta publicación te parece interesante, asegúrate de revisar estas otras también. Implement Serverless Log Analytics Using Amazon Kinesis Analytics y Real-time Clickstream Anomaly Detection with Amazon Kinesis Analytics.

Este artículo fue traducido del Blog de AWS en Inglés.

Sobre el autor

Prasad Alle es Consultor Senior de Big Data en Servicios Profesionales de AWS. Lidera y construye soluciones de Big data escalables y confiables, es especialista en Machine learning, Inteligencia Artificial e IoT para clientes empresariales y estratégicos de AWS. Se interesa por diversas tecnologías como Advanced Edge Computing, Machine learning at Edge. En su tiempo libre, disfruta pasar tiempo con su familia.

Sobre el traductor

Rene Roldan es Arquitecto de Soluciones de AWS.

Sobre los revisores

Rodrigo Cabrera es Arquitecto de Soluciones de AWS.

Servio Reyes es Arquitecto de Soluciones de AWS.

Conozca más contenidos sobre base de datos en la página de sesiones bajo demanda.

Acceda >

Blog de Amazon Web Services (AWS)