Explorando los límites de ancho de banda de Kafka en Dropbox

El uso generalizado de tecnologías Apache-stack es una tendencia obvia. Y Kafka está a la vanguardia de la popularidad: hoy, las personas que conocen a un agente de mensajes de este tipo, tal vez superan el número de aquellos que están acostumbrados a ver la palabra Franz junto a la palabra Kafka.

Nosotros mismos estamos utilizando activamente esta tecnología en nuestros proyectos. Pero siempre es interesante, pero ¿cómo funciona para los demás? Y es doblemente interesante si este no es solo un ejemplo de la práctica de alguien, sino una prueba enfocada de la tecnología. Por lo tanto, hemos traducido un artículo reciente que habla sobre cómo Dropbox buscó empíricamente límites de oportunidad y límites de resistencia en Kafka. Y encontró lo que buscaba.

Explorando los límites de ancho de banda de Kafka en Dropbox
Apache Kafka es una solución popular para la transmisión distribuida y el procesamiento secuencial de grandes cantidades de datos. Es ampliamente utilizado en la industria de alta tecnología, y Dropbox no es una excepción. Kafka desempeña un papel importante en la estructura de datos de muchos de nuestros sistemas críticos distribuidos: análisis de datos, aprendizaje automático, monitoreo, recuperación y procesamiento de flujo (Cape) (y estos son solo algunos).

En Dropbox, los grupos de Kafka son administrados por el equipo de Jetstream, cuya responsabilidad principal es proporcionar servicios de alta calidad relacionados con Kafka. Comprender el límite de ancho de banda de Kafka dentro de la infraestructura de Dropbox es fundamental para tomar las decisiones correctas sobre cómo asignar recursos en diferentes casos de uso, y este era uno de los objetivos prioritarios del equipo. Recientemente creamos una plataforma de prueba automatizada para lograr esto. Y en esta publicación nos gustaría compartir nuestro método y los resultados.

Plataforma de prueba

La figura anterior muestra los parámetros de nuestra plataforma de prueba para este estudio. Utilizamos Spark para alojar clientes de Kafka, lo que nos permite producir y consumir tráfico en un volumen arbitrario. Creamos tres grupos de Kafka de diferentes tamaños, de modo que ajustar el tamaño del grupo se redujo literalmente a redirigir el tráfico a otro punto. Kafka creó un tema para la producción y el consumo de tráfico de prueba. Para simplificar, hemos distribuido el tráfico en todos los corredores de manera uniforme. Para hacer esto, creamos un tema de prueba con el número de secciones diez veces el número de corredores. Cada corredor lleva exactamente 10 secciones. Dado que escribir en una sección es secuencial, muy pocas particiones asignadas a un corredor pueden conducir a una escritura competitiva, lo que limita el ancho de banda. Nuestros experimentos mostraron que 10 es un buen número para eliminar las dificultades de cuello de botella asociadas con la grabación competitiva.

Debido a la naturaleza distribuida de nuestra infraestructura, nuestros clientes están ubicados en varias regiones de los Estados Unidos. Teniendo en cuenta que nuestro tráfico de prueba está significativamente por debajo del límite de los canales troncales de Dropbox, podemos asumir con confianza que este límite de tráfico interregional también es aplicable al tráfico local.

¿Qué afecta a la carga?

Hay muchos factores que pueden afectar la carga del clúster de Kafka: la cantidad de productores, la cantidad de grupos de consumidores, la compensación inicial de los consumidores, la cantidad de mensajes por segundo, el tamaño de cada mensaje, la cantidad de temas y secciones involucradas. Y estos son solo algunos de ellos. El grado de libertad en el establecimiento de parámetros es alto. Por lo tanto, necesitamos encontrar los factores dominantes para reducir la complejidad de las pruebas a un nivel aceptable.

Examinamos varias combinaciones de parámetros que encontramos adecuados. Llegamos a una conclusión sorprendente de que los factores dominantes que deben tenerse en cuenta son los componentes principales de la carga: la cantidad de mensajes producidos por segundo (s / s) y la cantidad de bytes por mensaje (b / s).

Modelo de tráfico

Tomamos un enfoque formal para comprender las limitaciones de Kafka. Hay un espacio de tráfico relacionado para un clúster Kafka particular. Cada punto en este espacio multidimensional corresponde a un estado único de tráfico aplicable a Kafka y se presenta como un vector de parámetros: <s / s, b / s, # productores, # grupos de consumidores, # temas, ...>. Todos los estados de tráfico que no provocan congestión de KafKa forman un subespacio cerrado cuya superficie limitará el clúster de Kafka.

Para nuestra primera prueba, elegimos s / sy b / s como los parámetros principales y redujimos el espacio de tráfico a un plano bidimensional. Los límites del tráfico permitido forman áreas claras de seguimiento. La detección del límite de Kafka en nuestro caso es equivalente a determinar los valores límite de esta área.

Prueba de automatización

Para establecer los límites con suficiente precisión, fue necesario realizar cientos de pruebas con varios parámetros, lo que sería extremadamente irracional hacer manualmente. Por lo tanto, hemos desarrollado un algoritmo que le permite realizar todos los experimentos sin intervención humana.

Tasa de congestión

Es muy importante encontrar un conjunto de indicadores que le permita evaluar mediante programación el estado de Kafka. Examinamos una amplia gama de posibles indicadores y nos decidimos por la siguiente muestra pequeña:

• un flujo de E / S simple es inferior al 20%: esto significa que el conjunto de flujos de trabajo utilizados por Kafka para procesar las solicitudes de los clientes está demasiado ocupado y no puede hacer frente a las tareas entrantes.
• cambio en el conjunto de réplicas sincronizadas (ISR) en más del 50%: esto significa que cuando se usa el tráfico durante el 50% del tiempo observado, al menos un intermediario no tiene tiempo para duplicar los datos recibidos de su líder.

Los mismos indicadores se utilizan en Jetstream para monitorear el estado de Kafka y servir como las primeras señales de alarma de sobrecarga del clúster.

Encuentra fronteras

Para determinar un valor límite, arreglamos b / sy luego cambiamos s / s para que Kafka se sobrecargue. Es posible determinar el valor s / s de límite cuando conocemos el valor s / s seguro y está cerca de él, pero ya está causando sobrecarga. De estos dos, el valor s / s seguro se toma como el valor límite. Como se muestra a continuación, la línea de valores límite se forma de acuerdo con los resultados de pruebas similares con diferentes indicadores b / s:



Vale la pena señalar que en lugar de regular directamente s / s, experimentamos con un número diferente de fabricantes que tienen la misma velocidad de producción, denotada por np. La cuestión es que el procesamiento por lotes de mensajes complica el control sobre la velocidad de producción de un solo fabricante. Un cambio en el número de fabricantes, por el contrario, le permite cambiar linealmente el tráfico. Según nuestras primeras investigaciones, un simple aumento en el número de fabricantes no creará una diferencia notable en la carga en Kafka.

Para empezar, encontramos un valor límite separado usando una búsqueda binaria. La búsqueda comienza con un rango muy grande np [0, max], donde max es el valor que necesariamente conducirá a una sobrecarga. En cada iteración, se selecciona un valor promedio para crear tráfico. Si Kafka está sobrecargado con este valor, este valor promedio se convierte en el nuevo límite superior; de lo contrario, se convierte en un nuevo límite inferior. El proceso de búsqueda se detiene cuando el rango se reduce lo suficiente. Luego consideramos los indicadores s / s, que están relacionados con el límite inferior establecido de los valores límite.

Resultado



Como puede ver en el diagrama anterior, establecemos los valores límite para Kafka de diferentes tamaños. Con base en los resultados, llegamos a la conclusión de que el rendimiento máximo posible de la infraestructura de Dropbox es de 60 Mb / s por corredor.

Cabe destacar que este es un límite conservador, ya que el contenido de nuestros mensajes de prueba fue lo más aleatorio posible para reducir el efecto de la compresión interna de mensajes en Kafka. Cuando el tráfico alcanza su límite, tanto el disco como la red se utilizan por completo. En los scripts de trabajo, los mensajes de Kafka generalmente corresponden a un cierto patrón, ya que a menudo están formados por algoritmos similares. Esto proporciona oportunidades significativas para optimizar la compresión de mensajes. Probamos un escenario extremo, cuando los mensajes consisten en un solo carácter y registramos un rendimiento mucho mayor, ya que el disco y la red ya no son un cuello de botella.

Además, estos indicadores de rendimiento son correctos si hay al menos 5 grupos de consumidores que se suscriben al tema probado. En otras palabras, el ancho de banda de grabación indicado se logra cuando el ancho de banda de lectura es 5 veces mayor. Cuando el número de grupos de consumidores supera los 5, el ancho de banda de grabación comienza a disminuir a medida que la red se convierte en un cuello de botella. Dado que la proporción de tráfico de lectura y escritura es mucho menor que 5 en los casos en que se usan clústeres de producción de Dropbox, el ancho de banda obtenido se extiende a todos los clústeres de producción.

Este resultado lo ayudará a planificar mejor los recursos para el futuro Kafka. Por ejemplo, si queremos permitir que hasta el 20% de todos los intermediarios trabajen sin conexión, el ancho de banda máximo seguro de un intermediario debe ser 60 MB / s * 0.8 ~ = 50 Mb / s. Este número puede usarse en adelante para determinar el tamaño del clúster, dependiendo del rendimiento planeado de casos de uso futuros.

Herramientas para el trabajo futuro.

La plataforma y el probador automatizado serán herramientas valiosas para el equipo de Jetstream en su trabajo futuro. Cuando pasamos a un nuevo hardware, cambiamos la configuración de la red o actualizamos la versión de Kafka, simplemente podemos volver a ejecutar estas pruebas y obtener nuevos datos sobre los límites permitidos de la nueva configuración. Podemos aplicar la misma metodología para estudiar otros factores que pueden afectar el rendimiento de Kafka de varias maneras. Finalmente, la plataforma puede actuar como un banco de pruebas Jetstream para simular nuevas opciones de tráfico o reproducir problemas en un entorno aislado.

Para resumir

En este artículo, presentamos nuestro enfoque sistemático para comprender las limitaciones de Kafka. Es importante tener en cuenta que hemos logrado estos resultados basados ​​en la infraestructura de Dropbox, por lo que nuestros números pueden no ser aplicables a otras instalaciones de Kafka debido a la diferencia en las condiciones de hardware, software y red. Esperamos que la metodología presentada aquí pueda ayudar a los lectores a comprender sus propios sistemas.