Noticias

El servicio Apache Kafka está diseñado para una latencia baja y sin pérdida de datos

Diseñar un entorno de servicio de producción con baja latencia y cero pérdida de datos a escala en torno a Apache Kafka no es una tarea fácil. De hecho, es el santo grial de los sistemas de mensajería. En esta publicación de blog, describiré algunas consideraciones básicas de diseño de servicios que debe tener en cuenta para que su arquitectura de servicios cumpla con las normas.

Empecemos con lo básico.

Servicio básico de la solución Apache Kafka

Los servicios básicos incluyen servicios de protocolo de tiempo de red (NTP), servicio de nombres de dominio (DNS) y enrutamiento de red, cortafuegos y partición. Debe hacer esto bien antes incluso de pensar en pasar a la implementación de la aplicación en sí. Ahora, sé de lo que está hablando: «Estoy implementando Kafka en la nube, esto ya está solucionado, no hay nada que ver aquí». Bueno no exactamente.

Incluso en la nube, debe asegurarse de que su entorno de VPC tenga el enrutamiento de red configurado correctamente, que las reglas de entrada y salida del firewall sean adecuadas y efectivas, y que la partición de su red esté diseñada para soportar el flujo de tráfico esperado por las aplicaciones basadas en Kafka. , cliente Productor y consumidor Por lo general, se requiere poder llegar a todos los agentes de Kafka en el clúster. Si está utilizando un servicio de este tipo, es posible que también desee asegurarse de que el servicio DNS de su nube esté configurado correctamente.

Para las implementaciones locales, definitivamente también deberá lidiar con los servicios NTP. Desactivar la sincronización horaria es muy importante para las aplicaciones de clúster distribuidas como Apache Kafka. Cuando se utilizan soluciones de nube privada y virtualización como Charmed OpenStack, es imperativo asegurarse de que la hora de la máquina virtual invitada esté sincronizada con una fuente de tiempo confiable y estable (idealmente fuera del clúster del hipervisor); de lo contrario, el tiempo entre máquinas variará drásticamente, en algunos casos. , el tiempo de la máquina virtual invitada podría incluso saltar de un lado a otro, confundiendo por completo la implementación de Apache Kafka.

LEER  El ecosistema de código abierto para drones

Una vez que tenga un plan de servicio básico para su implementación, el siguiente paso es planificar la arquitectura de implementación de la aplicación para su solución Kafka.

Arquitectura de implementación de aplicaciones Kafka

Kafka se puede implementar en modo de clúster extendido en escenarios altamente elásticos, donde los nodos del mismo clúster se distribuyen en varios centros de datos. Por supuesto, el mismo centro de datos también puede albergar varios clústeres; por ejemplo, un clúster de Kafka primario y en espera se puede implementar uno al lado del otro y replicarse entre los clústeres para minimizar el tiempo de inactividad durante las intervenciones de servicio. Como siempre, hay compensaciones aquí. En caso de que falle un nodo de Kafka Broker, la replicación entre centros de datos dentro del mismo clúster consumirá una capacidad de red significativa para reconstruir particiones alojadas en otro lugar del clúster. También necesita una interconexión de red de alto rendimiento entre sitios; de lo contrario, su aplicación de productor de Kafka sufrirá demoras durante las escrituras.

Como alternativa, puede considerar una arquitectura con varios clústeres de Kafka específicos del sitio, utilizando la duplicación asincrónica entre sitios. Nuevamente, debe hacer concesiones entre disponibilidad, integridad y costo.

El siguiente diagrama ilustra un clúster ampliado implementado en tres sitios. El sitio «A» y el sitio «B» alojan a Kafka Broker y Apache ZooKeeper, mientras que el sitio «C» solo aloja a ZooKeeper y actúa como árbitro para evitar que ocurra la «división del cerebro». Se produce una situación de «cerebro dividido» cuando un evento de partición de red separa el sitio A del sitio B, lo que hace que cada sitio asuma que el otro está perdido y continúe sirviendo de una manera que podría generar inconsistencias en los datos (posiblemente datos obsoletos) y procesamiento de datos. entrará en conflicto una vez que se restablezca la conexión de red.

Una consideración importante para este tipo de implementación es la capacidad de la red entre los sitios. El tipo de enlace de sitio a sitio que se está ejecutando, la capacidad total del enlace y la capacidad comprometida del servicio de Kafka disponible para el tráfico de replicación en el clúster deben evaluarse cuidadosamente.

Diseño de host del servidor Ubuntu

El rendimiento general de una solución de Kafka se puede entender en gran medida por el diseño de los servidores host. La elección del sistema operativo, la capacidad de la memoria, la clase de almacenamiento, el volumen y el sistema de archivos afectan el rendimiento de la solución en diversos grados.

Por ejemplo, el rendimiento de una aplicación de consumidor que procesa datos en un agente de Kafka con Transport Layer Security (TLS) habilitado puede beneficiarse enormemente de la implementación en una plataforma basada en Linux como Ubuntu Server 22.04 LTS, que se mantiene con una implementación estable de OpenSSL. esta distribuido.

Elegir un sistema de archivos de alto rendimiento, como el sistema de archivos XFS para volúmenes que alojan datos de registro de Kafka, puede aportar la estabilidad y los importantes beneficios de rendimiento de este sistema de archivos maduro a su implementación de Kafka.

Para garantizar la estabilidad y el rendimiento de cada nodo de intermediario de Kafka en el clúster, debe configurar el sistema con suficiente memoria para alojar dos procesos de intermediario de Kafka (normalmente, se asignan alrededor de 6 GB de memoria para el almacenamiento dinámico de Java JVM). También debe asegurarse de que el sistema operativo tenga suficiente memoria para que pueda crear un caché de página eficiente que contenga los datos de registro de Kafka.

Otros aspectos que debe tener en cuenta al diseñar un host de Ubuntu Server para Kafka, aunque no es estrictamente una preocupación de implementación de baja latencia, pueden incluir el fortalecimiento del sistema; un ejemplo es garantizar que se revoquen todos los privilegios innecesarios. También deberá ajustar correctamente su instalación de OpenJDK JRE (Java Runtime Environment), con el recolector de basura adecuado y su configuración asociada.

La guía detallada sobre cómo dimensionar su clúster para garantizar que se implementen suficientes nodos de intermediario de Kafka para cumplir con los objetivos de carga, latencia y disponibilidad está más allá del alcance de esta publicación de blog, pero aquí hay un ejercicio que debe completar para asegurarse de que su servicio de Kafka sea correcto: El tamaño adecuado para su caso de uso. Incluso en un escenario de nube elástica, donde el escalado se puede automatizar en gran medida y solo toma unos minutos, aún debe tener una idea clara del costo total de la solución en ejecución, por lo que este paso realmente no se puede omitir.

Implementar observabilidad

A veces es necesario solucionar problemas, ya sea durante la fase inicial de prueba de concepto o durante la ejecución de un servicio de producción. Para ello, necesita una adecuada monitorización e integración diagnóstica. Por lo general, esto significa habilitar la exportación de métricas en Java JVM para que puedan recopilarse y procesarse con herramientas como Telegram y Prometheus, implementar una solución de agregación de registros como syslog-ng y posiblemente incluso usar tcpdump para la inspección del tráfico de red.

Use una solución de observabilidad como Pila de observabilidad canónica (COS Lite) se convierte en un trabajo sencillo en el que el único paso necesario es asociar Kafka con un recopilador de telemetría implementado, como el proxy COS para la implementación de máquinas o el proxy Grafana para Kubernetes.

Resumen del diseño del servicio Kafka de producción

Diseñar un servicio Kafka de producción para casos de uso de baja latencia, alto volumen y cero pérdida de datos no es poca cosa, pero al adoptar un enfoque holístico de sistemas para el diseño del servicio, usted fueron capaces Cree un servicio sólido que ofrezca un tiempo de inactividad mínimo al mismo tiempo que ofrece baja latencia a escala.

Canonical tiene una amplia experiencia en la implementación de Apache Kafka y ofrece servicios totalmente administrados para Apache Kafka, tanto en las instalaciones como en la nube, diseñados y personalizados según sus necesidades únicas.

Contáctenos y háganos saber sus requerimientos.

Obtenga más información sobre la solución de Canonical para Apache Kafka.

LEER  Ubuntu Touch OTA-18 llega el 14 de julio con mejoras de rendimiento y varios cambios

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba