Los conectores de Lilt permiten que nuestros clientes conserven el contenido en sus sistemas preferidos, como publicaciones de blog de WordPress o wikis de soporte de Zendesk, y que usen Lilt en segundo plano para la traducción. El contenido se importa a Lilt y se exporta nuevamente al sistema de contenido original cuando se termina la traducción. La importación y la exportación se hacen sin problemas, y esta eficiencia juega un papel importante a la hora de ayudar a Lilt a lograr que la información del mundo sea más accesible.

Lilt actualmente ofrece conectores para más de 15 sistemas diferentes. Nuestros clientes dependen en gran medida de los conectores de Lilt para su flujo de trabajo de localización. ¡En 2021, casi el 90 % de todo el contenido traducido en la plataforma de Lilt se hizo a través de un conector!

Nuestra arquitectura de conectores no siempre estuvo diseñada para admitir el increíble volumen que maneja en la actualidad. En este artículo, se describe de qué manera Lilt usa Argo Workflows para escalar nuestro marco de conectores, lo que posibilita que se convierta en nuestra oferta empresarial más grande hoy.

Nuestros inicios

En los primeros días de Lilt, cada conector se implementaba en su propio repositorio de Github, era desarrollado por diferentes ingenieros e interactuaba con Lilt de maneras matizadas con bases de datos y esquemas separados. Cualquier cambio en nuestra API traía aparejada la necesidad de actualizar el codebase en varios lugares. Además de eso, cada conector venía con un conjunto único de errores, que eran difíciles de rastrear y corregir. Imagina lo que significaba ser un ingeniero que tenía que mantener múltiples conectores. ¡Uf!

 💡 Dato curioso: Zendesk fue nuestro primer conector, y se lanzó a principios de 2019.

Unificación de conectores

Era evidente que este modelo no escalaría a medida que creciera la oferta de conectores de Lilt. Por lo tanto, unificamos nuestro marco de conectores mediante la centralización del código y la configuración de los conectores para que se ejecuten de la misma manera, independientemente de a qué sistema se conectaran. Una vez que el código estuvo en un solo repositorio, comenzamos a usar tareas nativas de Kubernetes para gestionar y ejecutar todas las tareas de los conectores.

Esta fue una gran mejora con respecto a nuestra implementación anterior y fue inmensamente más eficiente. Luego, surgió un nuevo tipo de problema de escalamiento. Aunque Kubernetes en sí era confiable, eventualmente nos encontramos con limitaciones de recursos que causaron problemas de confiabilidad.

Programación

- Los documentos se importan a y se exportan desde Lilt siguiendo un cronograma dado. Establecimos una configuración para que el servidor de administración ejecutara el cronograma, pero Kubernetes frecuentemente programaba demasiadas tareas a la vez (por ej., 50 en el mismo milisegundo), lo que agotaba la memoria del clúster y causaba que el descarte y la pérdida de los trabajos.

- Las tareas nuevas quedaban atascadas y no se podían enviar por falta de memoria.

Registro

- Ejecutamos Kubernetes en Google Kubernetes Engine (GKE) y lo configuramos para producir registros de aplicaciones de procesamiento en Stackdriver, pero los registros estaban desorganizados y eran confusos.

- El filtrado manual de los registros en Stackdriver requería mucho tiempo y era engorroso pero necesario para determinar la causa de las tareas fallidas.

Limpieza de tareas

- Kubernetes no estaba optimizado para recopilar basura. Nosotros teníamos que encargarnos de eliminar los pods y las tareas terminadas, e implementar un código separado para la limpieza.

Ante estos problemas, nos encontramos con el mismo dilema que en nuestros primeros días: necesitábamos una solución mejor, o no escalaríamos.

Ingreso de Argo

Al evaluar soluciones para renovar nuestra arquitectura de conectores, consideramos Airflow y Prefect, pero ninguno de ellos ofrecía compatibilidad nativa con Kubernetes. En última instancia, queríamos usar algo además de Kubernetes, y Argo Workflows realiza una gestión de orquestación de tareas basada en contenedores para Kubernetes. Además, resolvió nuestras dificultades por medio de estas características:

Visibilidad y accesibilidad de los registros

- Argo recopila más información en cada ejecución que Stackdriver, lo que nos permite depurar las tareas fallidas más rápido.

- De forma predeterminada, Argo admite el guardado de registros. Todo lo que teníamos que hacer era especificar dónde guardarlos.

- Argo guarda un registro de nuestros flujos de trabajo históricos, lo que nos brinda aún más registros y visibilidad.

Gestión de tareas confiable

- Argo nos permite definir el paralelismo. Si tenemos 100 tareas, Argo realizará 5 a la vez y solo ejecutará una tarea cuando la anterior esté terminada, lo que mejora enormemente la confiabilidad y elimina los problemas de programación causados por el uso de tareas de Kubernetes de forma autónoma.

- Argo usa flujos de trabajo de cron en conjunto con Kubernetes para programar y ejecutar tareas sobre la base de los recursos requeridos. Nuestro programador se ejecuta directamente a través de Argo.

- Escalar no requiere esfuerzo. Cuando aumenta el volumen, simplemente tenemos que intensificar los recursos de Kubernetes en Google Cloud Platform (GCP) para que Argo los utilice.

- Argo tiene opciones de recopilación de basura para administrar tareas terminadas.

Integración sin fisuras

- Argo es el "motor de flujo de trabajo para Kubernetes", lo que significa que no tendríamos que cambiar las herramientas de orquestación de contenedores.

- La integración en nuestra arquitectura no requirió ningún cambio de código, lo que nos permite seguir ejecutando el código de nuestro repositorio centralizado.

- Los requisitos de instalación fueron mínimos: solo tuvimos que especificar la configuración de flujo de trabajo de Argo en un archivo YAML.

Ergo, Argo

Después de adoptar Argo, nuestros servicios de conectores ahora consisten en tres componentes principales:

1. Servidor de administración
2. Servidor de ejecución
3. Ejecución de tareas

Servidor de administración

El panel connectors-admin es la interfaz de usuario al servidor de administración y proporciona una interfaz para que los usuarios realicen tareas. El servidor de administración se conecta a nuestra base de datos y admite operaciones de CRUD para configuraciones y tareas, como crear/actualizar configuraciones de conectores, monitorear el progreso y registrar el producto de las tareas en ejecución: los usuarios pueden acceder a todo esto a través del panel connector-admin.

Servidor de ejecución

Argo es el servidor de ejecución que está conectado a un clúster de Kubernetes local. Con nuestra arquitectura actualizada, las tareas se envían del servidor de administración directamente a Argo en lugar de Kubernetes. Todas las interacciones con Argo desde el servidor de administración se realizan a través de la API REST de Argo.

Cómo funciona

1. El servidor de administración envía tareas a Argo.
2. Argo gestiona la programación del flujo de trabajo y garantiza que la tarea se termine. Nuestro programador se ejecuta cada 5 a 15 minutos y verifica si hay nuevas tareas para importar o exportar.
3. Cuando se termina un flujo de trabajo, Argo elimina pods y recursos.
4. Argo almacena la información de flujo de trabajo en su propia base de datos y guarda los registros de pods en Google Cloud Storage. Los usuarios pueden recuperar y ver los registros de pods a pedido a través del panel connectors-admin.

Ejecución de tareas

Si bien cada conector es diferente, todos se ejecutan de la misma manera. Para los clientes con requisitos únicos en su flujo de trabajo de localización, podemos usar nuestro panel connector-admin para controlar cómo se procesa su contenido cuando se ejecutan tareas y se transfiere contenido a o desde la plataforma de Lilt.

Exeunt Argo

Implementamos Argo Workflows a principios de 2021, y la adopción ha escalado nuestro software para admitir un incremento asombroso en el volumen que manejamos hoy. Después de Argo, la cantidad de documentos importados Lilt a través de un conector ha aumentado en más de un 870 %. Esperamos que esa cifra suba a medida que seguimos integrando Argo en nuestro marco de conectores.