Enfoque API-First para la creación de temas Kafka

Los equipos de ingeniería de DoorDash renovaron la creación de temas de Kafka sustituyendo un enfoque basado en Terraform/Atlantis por una API propia, Infra Service. Esto ha reducido el tiempo de incorporación de canalizaciones en tiempo real en un 95 % y ha ahorrado incontables horas a los desarrolladores.

El equipo de la plataforma de streaming en tiempo real de DoorDash, o RTSP, depende de la organización de la plataforma de datos y gestiona más de 2.500 temas de Kafka en cinco clústeres. Kafka es la capa pub-sub de la tubería Iguazu, que proporciona la entrega de eventos en tiempo real en DoorDash. Cada día se procesan casi seis mil millones de mensajes a un ritmo medio de cuatro millones de mensajes por minuto, que a veces llega al doble. 

El equipo de RTSP busca constantemente formas de acelerar la incorporación de Iguazu. El paso más lento de ese proceso era el aprovisionamiento de Kafka Topics, que requería la aprobación de un ingeniero de guardia y era propenso a fallos, lo que aumentaba aún más la carga de guardia. Para mejorar esto, RTSP se asoció con los equipos de almacenamiento y nube de DoorDash para automatizar la creación de recursos Kafka mediante la integración con un servicio interno de creación de recursos de infraestructura.

Terminología clave

A continuación encontrará definiciones y enlaces a documentación adicional sobre las herramientas que hemos utilizado. En el artículo principal abordamos cómo se utilizan estas herramientas y sus pros y contras. 

• Terraform: Plataforma de infraestructura como código (IaC). Utiliza el lenguaje único HashiCorp Configuration Language (HCL) para configurar los recursos de infraestructura. Para aprovisionar infraestructura, cree un plan de ejecución, denominado plan Terraform, y ejecute el plan a través de Terraform Apply.
• Atlantis: Herramienta de automatización de Terraform. Ejecuta Terraform Plan y Apply. Fusiona Terraform pull requests en ejecuciones exitosas.
• Pulumi: Similar a Terraform, también es una plataforma IaC, pero sin HCL. Pulumi aprovecha los lenguajes de programación existentes para gestionar la infraestructura.
• Prometeo: Una base de datos de monitorización y series temporales. Diseñada para monitorizar métricas de aplicaciones e infraestructuras. Expone el lenguaje de consulta PromQL para escribir alertas sobre métricas.
• Chronosphere: Plataforma de observabilidad nativa en la nube. Construida sobre Prometheus. 
• Flujo de trabajo Cadence: Motor de flujo de trabajo tolerante a fallos y con estado capaz de ejecutar grafos acíclicos dirigidos (DAG).

Comprender la arquitectura heredada

Como se muestra en la Figura 1, el enfoque heredado de DoorDash para la creación de temas implicaba varios pasos dentro de un flujo de trabajo de Cadence.

1. El servicio Orchestrator activa una llamada API contra el repositorio de GitHub para temas de Kafka, creando una solicitud de extracción, o PR, para un nuevo tema y la correspondiente entrada de lista de control de acceso (ACL).
2. El servicio Orchestrator activa Atlantis para ejecutar Terraform Plan contra el tema. 
3. El personal de guardia recibe una notificación automática por correo electrónico sobre el RP. 
4. El servicio Orchestrator sondea el estado del RP para comprobar la aprobación de guardia. 
5. Una vez aprobado y en estado mergeable, Atlantis Apply se activa contra el PR. 
6. Los servicios de Orchestrator supervisan si la fusión del RP se ha realizado correctamente. En caso de fallo, el PR se elimina y el proceso comienza de nuevo desde el paso 1.

Por desgracia, el flujo de trabajo de creación de temas suele fallar por varias razones:

• Conflictos de fusión en GitHub al crear un PR cuando se cortan varios PR del mismo commit
• Deriva del estado de Terraform contra el estado de Kafka
• Atlantis a veces se agotaba en clusters con cientos de temas y se completaba en un tiempo no determinable. 
• Deriva del estado de Atlantis contra el estado de Terraform. Terraform se aplica pero Atlantis no fusionó el PR
• Dado que la revisión y aprobación de los RP lleva mucho tiempo, a veces el personal de guardia no recibía la notificación por correo electrónico, lo que provocaba tiempos de espera. Nota: durante el lanzamiento de un producto, el volumen de relaciones públicas creadas por tema podía superar las 20 por hora.

Además, es difícil auditar mediante programación los clústeres de Kafka y realizar operaciones de escalado como añadir particiones o migrar a clústeres dedicados sin intervención manual. 

Desarrollar una nueva arquitectura

En un principio, estudiamos varios enfoques posibles, entre ellos:

• Creación de un estado duradero en memoria para realizar un seguimiento detallado del progreso y sincronizar los flujos de trabajo. El estado se recuperaría del disco al reiniciar Orchestrator.
• Utilizar la base de datos de procesamiento de transacciones en línea (OLTP) para persistir el estado mencionado anteriormente.
• Escribir un proveedor Terraform personalizado
• Aumentar los reintentos del flujo de trabajo. 

Las cuatro soluciones habrían sido soluciones de cinta adhesiva incapaces de abordar completamente los problemas subyacentes: Sincronización de estados a través de Terraform alojado en Git, Atlantis, Cadence workflow y Kafka. Aunque las dos primeras podrían haber resuelto algunos de los problemas mencionados, habrían corrido el riesgo de complicar aún más la gestión de estados al introducir nuevos estados que mantener sincronizados. Como fuente autorizada de la verdad, Kafka debe ser coherente con cualquier solución que elijamos. 

Una pequeña victoria: Un caso de uso para los superusuarios de Kafka

Mientras explorábamos estas soluciones, identificamos que los conflictos de fusión sólo se producían en los archivos ACL de los usuarios de Iguazu. Cada consumidor y editor en el canal de Iguazu tiene una cuenta de usuario Kafka independiente. Cada vez que se creaba un tema, el archivo ACL de un usuario de Iguazu se actualizaba con una entrada ACL para ese tema. Con el tiempo, los archivos ACL crecieron hasta tener cientos de permisos, ralentizando significativamente las aplicaciones de Atlantis.

Nuestro momento "eureka" fue cuando nos dimos cuenta de que este era un caso de uso perfecto para las cuentas de superusuario. Los problemas relacionados con los permisos hacían que normalmente evitáramos crear superusuarios. Pero si cada usuario de Iguazu - proxy REST o trabajos Flink ascendentes y descendentes - necesitara acceso a cada tema de un clúster, sería ideal dar a estos usuarios acceso completo de lectura o lectura-escritura según fuera necesario, eliminando el archivo ACL y sus problemas relacionados. Además, el flujo de trabajo existente podría mejorarse aún más, como describiremos en breve.

A por la gran victoria: Creación racionalizada de recursos Kafka 

Infra Service es una plataforma interna que proporciona una API para realizar operaciones CRUD en componentes de infraestructura. Está construida y mantenida por la organización de Infraestructura de DoorDash. Sustituye al enfoque tradicional de utilizar la infraestructura como código y GitOps para aprovisionar la infraestructura. Infra Service reproduce las funciones importantes que ofrecen Git y GitHub, como el control de versiones y la revisión de cambios. También se basa en plugins, lo que permite a los equipos añadir soporte para los recursos que deseen gestionar mediante programación. La mayor parte del trabajo necesario para implementar un plugin de Infra Service implica escribir un programa Pulumi subyacente.

Infra Service utiliza Pulumi para manejar el aprovisionamiento de infraestructura bajo el capó. Pulumi es una herramienta de infraestructura como código similar a Terraform, pero a diferencia de Terraform Pulumi permite el uso de lenguajes de programación generales para definir la infraestructura. Cuenta con un sólido soporte para pruebas y un amplio catálogo de proveedores. Infra Service se encarga de invocar Pulumi mediante programación cuando se solicita un cambio y de propagar los resultados de la ejecución de Pulumi al usuario final.

Para crear recursos de Kafka y bases de datos, hemos desarrollado un componente dentro de Infra Service llamado Storage Self-Serve Platform. Esto se muestra a continuación en la Figura 2.

En la Figura 2, todavía envuelta en un flujo de trabajo Cadence, el aprovisionamiento de temas se reduce a un proceso de dos pasos:

1. El servicio Orchestrator Minions lanza una solicitud gRPC a la pasarela Infra Service para aprovisionar el tema Kafka. Los subordinados reciben una respuesta sincrónica sobre si la solicitud de creación del tema es persistente. En este punto, la creación del tema puede no haberse completado. Desde la perspectiva de Minions, todo lo que hay detrás de la pasarela Infra Service es una caja negra que gestiona la deduplicación, la validación y los reintentos.
2. Dado que un tema se considera creado cuando aparece con un uso de disco distinto de cero, Minions sondea continuamente la plataforma de métricas Chronosphere de Prometheus para conocer ese estado. Todos los temas, incluso los que no tienen mensajes, incluyen metadatos de los que se hace una copia de seguridad en disco. Utilizamos Chronosphere por dos razones: En primer lugar, corrobora de forma independiente el estado de la caja negra de Infra Service y, en segundo lugar, DoorDash ejecuta Chronosphere con una disponibilidad de cuatro nueves (99,99%). Esto significa que las interrupciones de Chronosphere esencialmente no existen. Si Kafka no informa de las métricas del tema durante unos minutos, es improbable que esto continúe durante más tiempo, a menos que haya problemas mayores con Kafka. Cuando las métricas aparezcan finalmente en Chronosphere, serán extraídas por Minions. 

Saborear la victoria

Esta nueva arquitectura permite el aprovisionamiento de unos 100 temas nuevos cada semana sin intervención manual. Con este flujo de trabajo de temas basado en API, hemos reducido el tiempo de incorporación de Iguazu en un 95%. Antes, los clientes tenían garantizada la incorporación en dos días laborables, es decir, unas 48 horas. Ahora, la incorporación se completa en menos de una hora desde el envío de la solicitud y, a menudo, en menos de 15 minutos. Y hay un extra: la intervención manual de guardia se ha reducido unas cuatro horas a la semana.

Cada tema creado con la nueva arquitectura incluye metadatos detallados sobre la propiedad, las expectativas de rendimiento y el tamaño de los mensajes, lo que facilitará la aplicación de límites de fiabilidad en el futuro.

En última instancia, mediante la integración con la plataforma de autoservicio de almacenamiento estándar dentro de Infra Service, tenemos acceso a controles de administración que incluyen la anulación de configuraciones de temas, la recuperación de contraseñas de usuario y el acceso fácil para desarrolladores al estado del clúster Kafka. 

Explorando un futuro de autoservicio de almacenamiento

Basándonos en el éxito de Infra Service y la plataforma de autoservicio de almacenamiento, tenemos previsto añadir las siguientes funciones para mejorar nuestros guardarraíles y la experiencia del cliente. La figura 3 ilustra la arquitectura de alto nivel del futuro diseño. 

• Lógica de validación centralizada, que será mantenida por el equipo de almacenamiento. Esta lógica de validación puede ajustarse continuamente a las necesidades de la empresa.
• Valores por defecto inteligentes. El recuento de particiones y el factor de replicación pueden calcularse a petición del cliente. Esto simplifica la entrada del usuario para aprovisionar un tema.
• Detecte las solicitudes duplicadas en una fase más temprana del proceso de aprovisionamiento mediante una lógica de deduplicación específica de Kafka. Devolver los errores de la API a los usuarios.

Agradecimientos

Esta victoria de ingeniería ha sido un esfuerzo de equipo de varios equipos: Plataforma de streaming en tiempo real, Almacenamiento y Nube. Un agradecimiento especial a todos los ingenieros que han ayudado a conseguirlo: Roger Zeng, Luke Christopherson, Venkata Sivanaga Saisuvarna Krishna Manikeswaram Chaitanya, Basar Hamdi Onat, Chen Yang, Seed Zeng, Donovan Bai, Kane Du, Lin Du, Thai Pham, Allen Wang, Zachary Shaw y Varun Narayanan Chakravarthy.