- Kafka tuvo éxito como log distribuido en la era de los centros de datos, pero en la nube pública crecen los costos de red entre AZ y la carga operativa de manejar discos locales
- WarpStream es una plataforma de streaming sin discos compatible con el protocolo Apache Kafka, que funciona sobre almacenamiento de objetos como S3 sin discos locales ni rebalanceo de brokers
- Un clúster de Kafka en 3 zonas de disponibilidad incurre, incluso en el mejor caso, en unos $0.053 de costo de transferencia entre AZ por cada 1 GiB transmitido, más que el costo de almacenar 1 GiB en S3 durante un mes, que es de $0.021
- WarpStream separa almacenamiento y cómputo, así como datos y metadatos, mediante un Agent sin estado escrito en Go y un almacén de metadatos aparte; los datos permanecen en el almacenamiento de objetos de la cuenta cloud del usuario
- En la mayoría de las cargas de trabajo de Kafka, el costo puede reducirse entre 5 y 10 veces, pero la implementación actual exige aceptar una latencia de aproximadamente 400 ms en P99 para solicitudes Produce y cerca de 1 segundo P99 de extremo a extremo entre productor y consumidor
La estructura básica de Kafka, que se volvió cara en la nube
- Apache Kafka se publicó como open source en 2011 y desde entonces se convirtió en infraestructura base de las arquitecturas de streaming
- El problema no es tanto Kafka en sí, sino que su diseño, ajustado al centro de datos de LinkedIn en 2011, no encaja bien con las cargas de trabajo modernas en la nube
- Esto se nota especialmente en costos y carga operativa
- Economía cloud: el esquema de replicación de Kafka puede disparar los costos de ancho de banda entre AZ
- Carga operativa: operar un clúster de Kafka propio requiere un equipo dedicado y herramientas personalizadas
- Otros sistemas similares que almacenan datos en discos locales también pueden sufrir los mismos problemas de costo y operación
Kafka-nomics: costo de transferencia entre AZ
- En un clúster típico de Kafka con 3 zonas de disponibilidad, los datos producidos se escriben fuera de la zona con una probabilidad de 2/3 debido a la ubicación del líder de la partición, y luego ese líder replica los datos a los followers de las otras dos zonas
- El costo cuando 1 GiB cruza entre zonas se calcula en $0.022
- egress desde la zona de origen: $0.01
- ingress en la zona de destino: $0.01
- Incluso en el mejor caso, el costo de transmitir 1 GiB es de aproximadamente
0.02 * 2/3 + 0.02 * 2 = $0.053
- Almacenar 1 GiB en S3 durante un mes cuesta $0.021; con lo que cuesta copiar datos desde el productor hasta el consumidor en Kafka, se podría guardar ese mismo dato en S3 durante más de dos meses
- En clústeres de Kafka de alto throughput, el cargo por ancho de banda entre AZ domina el costo total por encima del hardware y puede representar entre 70% y 90% del costo de la carga
- Incluso con bajo throughput, si el período de retención es largo, la capacidad de almacenamiento crece, y almacenar con SSD local en triple réplica puede costar entre 10 y 20 veces más por GiB que un almacenamiento de objetos como S3, aun asumiendo 100% de uso del disco
La operación del clúster que termina recayendo en los desarrolladores
- Los desarrolladores adoptan Kafka para resolver problemas del negocio, pero primero tienen que aprender Kafka y ZooKeeper o KRaft, elección de líder, particiones, grupos de consumidores, rebalanceo, tuning de brokers y tuning de clientes
- Tanto los brokers, que forman el plano de datos de Kafka, como el plano de control basado en consenso —controladores, ZooKeeper y demás— se operan directamente sobre SSD local
- En un clúster de Kafka autohospedado, incluso tareas básicas como reemplazar nodos o escalar el clúster con seguridad requieren un equipo especializado y herramientas custom
- La herramienta integrada de reasignación de particiones de Apache Kafka no puede generar automáticamente un plan de reasignación cuando se retira un broker; el administrador debe redactar manualmente el plan de movimiento de réplicas de partición
- Servicios administrados como AWS MSK tampoco eliminan por completo la carga operativa
- La documentación de rebalanceo de clústeres de MSK enlaza a la documentación de Apache Kafka
- Ese procedimiento incluye editar manualmente JSON para decidir qué particiones mover a qué brokers
- Cruise Control puede reducir esa carga, pero añade aprendizaje de conceptos aparte, despliegue y monitoreo de otro servicio, y más puntos delicados en la operación
- Cruise Control en sí también es una aplicación JVM que depende de Apache Kafka y ZooKeeper
El enfoque de montar streaming sobre almacenamiento de objetos
- Husky, creado en Datadog, era una base de datos columnar para datos de observabilidad que corría directamente sobre S3, y funcionaba en gran parte como un data lake sin estado con autoescalado
- Después de construir Husky, los clústeres de Kafka empezaron a verse como una estructura antigua en comparación
- El ancho de banda de Kafka en Datadog llegaba a decenas de GiB/s, y el almacenamiento de brokers se medía en NVMe a escala de PiB
- Las cargas de trabajo de almacenamiento a gran escala difícilmente pueden competir, en la nube, con la economía, confiabilidad, escalabilidad y elasticidad del almacenamiento de objetos
- Tecnologías de big data como Snowflake y Databricks también diseñan sus sistemas alrededor de almacenamiento de objetos genérico
- Si se construye directamente sobre S3 un sistema parecido a Kafka, se pueden reducir al mismo tiempo dos cargas
- reducción de costos
- reducción de los problemas operativos tradicionales de Kafka
- La dificultad central es construir infraestructura de streaming de baja latencia sobre un medio de almacenamiento de alta latencia como S3, manteniendo la semántica del protocolo Kafka sin discos locales
Arquitectura de WarpStream
- WarpStream es una plataforma de streaming compatible con el protocolo Apache Kafka que corre directamente sobre almacenes de objetos genéricos como AWS S3, GCP GCS y Azure Blob Storage
- No tiene costo de ancho de banda entre AZ, no hay discos locales que administrar, y puede ejecutarse dentro de la VPC del usuario
- En lugar de brokers de Kafka, usa un Agent
- El Agent es un binario sin estado escrito en Go
- No usa JVM
- Habla el protocolo Kafka
- Cualquier Agent puede actuar como líder de topic, commit de offsets de consumer groups o coordinador del clúster
- WarpStream reemplaza la estructura con estado de Kafka mediante dos separaciones
- separa almacenamiento y cómputo, descargando los datos a S3
- separa datos y metadatos, descargando los metadatos a un almacén de metadatos personalizado
- Al llevar todo el almacenamiento al object storage, no hace falta rebalancear datos cuando se aumenta o reduce la cantidad de Agents según cambie la carga
- Incluso ante fallas, las solicitudes pueden reintentarse de inmediato en otro Agent, lo que acelera la recuperación
- También se reducen en gran medida los hot spots donde algunos brokers de Kafka cargan más debido al desbalance de datos por partición
- Los metadatos del Virtual Cluster de WarpStream se almacenan en una base de datos de metadatos personalizada
- La replicación, durabilidad y disponibilidad de los datos quedan a cargo del bucket de almacenamiento de objetos, y los datos del usuario permanecen dentro de su cuenta cloud
- Lo único que sale de la cuenta cloud son los metadatos de la carga necesarios para consensos como el orden de lotes dentro de una partición
- La estructura detallada está resumida en la documentación de arquitectura de WarpStream
Ejemplos de costos y trade-off de latencia
- La carga de trabajo de streaming continuo en el entorno de prueba produce de forma sostenida 140 MiB/s de datos, y tres consumidores dedicados los consumen, generando una transferencia continua total de 560 MiB/s
- El costo de red entre AZ de toda la cuenta cloud se midió en menos de $15 por día en promedio
- Si la misma carga se ejecutara en un clúster de Kafka, solo el costo de red entre AZ se calcularía en $641 por día
- La fórmula es
0.14GiB * $0.053/GiB * 60 * 60 * 24
- El costo de operaciones de API de S3 para la misma carga es de menos de $40 por día
- El hardware de Agent solo requiere VM equivalentes a 27 vCPU
- El costo total de propiedad en la mayoría de las cargas de trabajo de Kafka puede ser entre 5 y 10 veces menor con WarpStream
- La mayor desventaja es la latencia
- El P99 de las solicitudes Produce es actualmente de alrededor de 400 ms
- Porque no se responde con confirmación hasta que los datos quedan almacenados de forma durable en S3 y comprometidos en el plano de control cloud
- La latencia P99 de extremo a extremo desde productor hasta consumidor es de alrededor de 1 segundo
- Si la carga de trabajo tolera una latencia P99 de alrededor de 1 segundo entre productor y consumidor, se puede reducir entre 5 y 10 veces el costo de streaming por GiB y prácticamente eliminar la carga operativa
- La interfaz no es un protocolo propietario sino Kafka, y puede ejecutarse en entornos que usan AWS S3, GCP GCS y Azure Blob Storage
Experiencia de desarrollador y forma de uso
- WarpStream aborda primero dos de los principales problemas de Kafka: la economía cloud y la carga operativa
- Kafka también tiene problemas de experiencia de desarrollador, y se considera que las particiones son una abstracción de demasiado bajo nivel para escribir aplicaciones complejas de procesamiento de streams
- Más adelante planean tratar formas de acercar el desarrollo de aplicaciones de procesamiento de streams a la experiencia de escribir aplicaciones tradicionales
- El demo puede ejecutarse en menos de 30 segundos
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
- WarpStream es una presentación de producto de una empresa que vende una alternativa basada en almacenamiento de objetos sobre Apache Kafka, y las cifras y comparaciones del texto deben leerse en ese contexto
1 comentarios
Opiniones de Hacker News
Creo que la frase “casi todas las empresas tecnológicas usan Kafka” es incorrecta.
No es que hayamos presentado pruebas de ambos lados, pero de las 6 empresas en las que trabajé recientemente, Kafka se usaba en 0; y en la empresa anterior impulsé su adopción, pero después lo descartamos.
LinkedIn creó Kafka para resolver problemas de escala gigantesca que el 99% no tiene, y aunque los tecnólogos tienen cierta reputación de usar tecnologías que no necesitan, creo que la mayoría está logrando evitar usar Kafka.
Si eso es todo lo que necesitas, es fácil usarlo como un broker de mensajes simple sin período de retención; y si necesitas hacer algo particular aprovechando la persistencia, puedes ir por ese lado.
Si alguien tiene sentimientos negativos hacia una herramienta open source sólida y ampliamente usada incluso en su forma básica, por lo general creo que se debe a alguna funcionalidad o caso de uso especial.
Más bien, esa expresión hace quedar mal a este vendor. Se puede criticar o competir con Kafka por sus pros y contras técnicos, pero distorsionar su posición en el mercado no me parece bien.
No dudo que existan buenos casos de uso, pero hasta ahora solo vi usuarios entusiastas que intentaban meterlo a la fuerza en cualquier situación, lo que me dejó un mal sabor de boca; por eso estoy del lado de quienes “lo odian”.
Estoy de acuerdo con la parte de “Accidental SRE”, pero Kafka es una tecnología sólida, y por eso abundan herramientas tipo “un Kafka mejor que Kafka”, como Redpanda.
Al final parece desviarse del punto. Aunque no se use de forma masiva, eso es independiente de si es una tecnología polarizante. Para quienes resuelven esos problemas de escalabilidad del 1% que se mencionan, aún puede ser algo que amen u odien.
Es parecido a decir que “Lamborghini genera amores y odios” es falso porque la mayoría de la gente no tiene un Lamborghini. El autor también limitó explícitamente el alcance al decir “en el campo de los datos”.
Tengo algunas preguntas.
Por eso, el costo de PUT en S3 es proporcional a la cantidad de Agents en ejecución y al intervalo de flush, no a la cantidad de topic-partitions. No confirma las solicitudes Produce hasta que los datos estén almacenados de forma duradera en S3 y en el plano de control en la nube.
Creemos que no debería haber que elegir entre confiabilidad y costo. WarpStream ofrece el nivel de confiabilidad y disponibilidad de ejecutarlo en 3 zonas de disponibilidad, al costo de una sola zona de disponibilidad.
El orden lo maneja una base de datos de metadatos personalizada que se ejecuta en el plano de control en la nube.
No hay nada malo en sí mismo con tener un clúster de Kafka en cada zona de disponibilidad y replicar solo hasta el momento de unirlos después. Pero cuando hay sistemas distribuidos y zonas de disponibilidad de por medio, los ingenieros, y también los requisitos del negocio, por lo general terminan eligiendo una configuración multi-AZ. Lo mismo aplica a las regiones.
Por eso la mayoría de los clústeres de Kafka son multi-AZ, aunque en muchos casos en realidad no hace falta, y esa factura de costos termina atribuyéndose a Kafka.
El protocolo de Kafka en realidad no preserva el orden de las operaciones dentro de una partición de Kafka. Preserva el orden de las operaciones dentro de un par productor-partición, y aun eso solo es posible cuando está configurado de cierta manera.
La implementación estándar preserva el orden en que el broker recibe los mensajes del productor, pero desde la perspectiva de un sistema externo, cuando está configurado correctamente, significa más bien que los mensajes de una clave específica y de un productor específico se preservan en el orden de recepción.
¿El Cloud Metadata Store funciona, en la práctica, como el componente que reparte los offsets?
Soy Ryan Worl, cofundador y CTO de WarpStream. Nos emociona mucho anunciar la vista previa para desarrolladores de un sistema de streaming compatible con el protocolo Kafka, construido directamente sobre S3.
No hay discos/nodos con estado que ejecutar, no hay rebalanceo de datos, no hay ZooKeeper y no hay costos de ancho de banda entre zonas de disponibilidad, por lo que es entre 5 y 10 veces más barato.
Si tienen preguntas sobre WarpStream, las responderé junto con mi cofundador richieartoul.
Una de las razones por las que no lo hice fue que, si la escala no importa, sentía la paradoja de que quizá los usuarios no quieren una versión reducida de Kafka, sino que deberían usar SQLite directamente.
Pero puede haber gente a la que le gusten las semánticas del protocolo Kafka, o que ya usaba Kafka y se dio cuenta de que no tenía la escala que imaginaba y no necesitaba cargar con esa complejidad. Mucha suerte.
Si soportan Cloudflare R2, creo que también sería bueno para multicloud.
¿También ofrece garantías de orden como las que Kafka da a nivel de partición?
Si eso de “5 a 10 veces más barato” se debe sobre todo a reducir costos entre zonas de disponibilidad, ¿AWS MSK no ofrece también eso?
Una cosa es segura: ejecutar Kafka “como se debe” en VM individuales sobre un proveedor cloud es ridículamente caro.
Recuerdo haber tenido una conversación muy simple con varios clientes sobre Kafka y Hadoop: si el disco ya se ofrece como un sistema completamente redundante, ¿por qué replicar los datos otra vez a nivel de VM/disco?
En ese caso era Azure Storage, que ofrecía almacenamiento con redundancia local, redundancia por zona de disponibilidad y redundancia global, y buena parte de eso podía usarse para ejecutar discos administrados.
Por eso, un servicio administrado en la nube de Hadoop/Kafka bien diseñado usa adaptadores de almacenamiento para aprovechar la redundancia integrada del proveedor. Esa es también la razón por la que algunos proveedores cloud tienen brokers de eventos compatibles con Kafka.
El resto de WarpStream parece más bien la cereza del pastel, pero me da curiosidad cómo es la arquitectura interna y cómo evitan los costos entre zonas de disponibilidad.
Como referencia: trabajo en Microsoft, pero antes de entrar, hace casi 10 años, construía clústeres de Hadoop/Spark/Kafka.
Algunas implementaciones de Raft permiten nodos que tienen voto pero no pueden convertirse en líderes de quórum. Por ejemplo, una sucursal donde todo el tráfico pasa por un túnel VPN asimétrico no debería ser elegida líder, pero sí sabe qué candidatos puede ver.
Así que el costo base de operar un clúster estaba más cerca de 2,2 veces que de 3 veces el hardware, y en soluciones pequeñas o sandboxes de desarrolladores eso marcaba una gran diferencia. También importa cuando 3 shards quedan apenas cortos de carga pero 5 son demasiados, o incluso en la diferencia entre 6 y 7.
El problema es que, en replicación geográfica, eso no resuelve los dos problemas que son el punto central de este texto. Desde el punto de vista de la economía cloud, la estrategia de replicación de Kafka genera por diseño costos enormes de ancho de banda entre zonas de disponibilidad; y desde el punto de vista de la carga operativa, operar tu propio clúster Kafka prácticamente requiere un equipo dedicado y herramientas personalizadas sofisticadas.
Aun así, hace falta recuperar esta capacidad en la nube. Sobre todo cuando, como siempre ha pasado, las cosas empiezan a moverse otra vez hacia el self-hosting.
Las soluciones tipo EBS vienen con un costo. En especial cuando necesitas muchos IOPS, son muy caras. Puedes ahorrar costos de tráfico entre zonas de disponibilidad, pero terminas pagando una barbaridad por el almacenamiento.
Si haces la replicación tú mismo, puedes usar almacenamiento conectado mucho más barato.
Para richieartoul: el post del blog está un poco condimentado de más.
Kafka no exige inherentemente un equipo dedicado de expertos ni millones de dólares hasta que operas clústeres muy grandes.
Eso sí, estoy totalmente de acuerdo en que un clúster distribuido en 3 zonas de disponibilidad se devora el dinero en costos de transferencia entre zonas. Así es como AWS vende MSK. Dicen que la transferencia entre zonas de disponibilidad es “gratis”, pero en realidad ya está incluida en el precio.
Se ve interesante, pero después de leer “Accidental SRE” me surgieron dos preguntas.
El bare metal existe desde hace mucho, pero no parece que administrar tu propio bare metal se haya vuelto mucho más fácil. Si realmente fuera fácil, los usuarios finales administrarían más de estas cosas por su cuenta.
Entonces, ¿cómo administran este servicio? ¿Es sobre un proveedor cloud o sobre bare metal?
Ambos tienen mucha experiencia con FoundationDB, que normalmente se administra directamente. Entonces, ¿también eligieron FoundationDB otra vez para el almacén de metadatos? Si lo eligieron, o si no, me gustaría saber por qué.
Así, todos los datos del cliente permanecen dentro de su cuenta cloud y en sus buckets de S3, y nosotros no podemos verlos ni tocarlos. El cliente sí tiene que ejecutar el WarpStream Agent por su cuenta, pero es solo un contenedor sin estado y fácil de administrar.
Evaluamos FoundationDB como almacén de metadatos, pero al final no lo usamos. Para que el nivel gratuito fuera rentable, necesitábamos que el almacén de metadatos fuera lo más eficiente posible para este caso de uso específico, y para eso hacía falta algo más personalizado.
Aun así, FoundationDB es una tecnología excelente. Es la mejor entre varias bases de datos distribuidas que he usado.
La frase “¿Cuántas particiones debería usar? No está claro, pero una vez que lo decides, nunca puedes cambiarlo, así que hay que elegir bien” simplemente está equivocada. La cantidad de particiones sí se puede cambiar
Y tampoco entiendo bien la afirmación repetida de que “para operar Kafka hace falta todo un equipo de ingenieros”. Según mi experiencia, no es cierto. Es verdad que el costo operativo es alto, pero en nuestro equipo no requiere mucho tiempo de ingeniería
Muy interesante. Yo también diseñé algo parecido y quería implementarlo en Zig https://github.com/fremantle-industries/transit
Gran parte del poder de Kafka viene de su API, y llegué a una conclusión similar: al final, la complejidad de administrar clústeres se abstraerá a través de varias implementaciones
Si se puede implementar la persistencia de Kafka sobre el espacio de claves de S3, pensaba empezar con un enfoque que persista directamente en S3, como WarpStream, y luego agregar mecanismos de capas con discos calientes más rápidos y memoria para reducir la latencia de extremo a extremo
Me gusta la dirección. Si quieres hablarlo más a fondo, puedes contactarme por Twitter https://twitter.com/rupurt
En un trabajo anterior construí algo probablemente muy parecido a este producto. Teníamos tráfico de machine learning de decenas de TB por día y no necesitábamos latencia en tiempo real, así que lo movimos todo a S3 y logramos una reducción de costos de alrededor del 90%
Lo hicimos sobre la JVM y todavía usábamos un clúster Kafka de 6 brokers para mantener los metadatos. Cuando todo estaba originalmente en Kafka, probablemente habrían sido unos 300 brokers
El modelo de cómputo/almacenamiento de Kafka no escala bien en casos de uso extremos donde se puede tolerar latencia, y el modelo de Apache Pulsar encajaba mejor. Sin embargo, en ese momento Pulsar no era lo suficientemente estable para usarlo en producción
Una de las claves de la eficiencia de costos era que el tamaño de los datos era lo suficientemente grande como para no tener que esperar mucho hasta alcanzar tamaños de archivo económicos. Me cuesta imaginar que un pipeline de menos de 10 MB por segundo funcione eficientemente con este enfoque
¿Eso era memq de Pinterest, o era otra cosa?
El título del artículo debería haber sido “Kafka is dead. Long live WarpStream.” La parte de “long live” apunta al sucesor
https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!