Rincón de los ingenieros: el cambio de Xactly a Chrome sin cabeza

Esta es una publicación de blog invitada del ingeniero de software de Xactly, Anvesh Checka. ¡Estén atentos a futuros blogs del equipo de ingeniería de Xactly!

Un documento de plan es un documento legal entre una empresa y sus representantes de ventas, que se utiliza para realizar un seguimiento del progreso. Planifique documentos dentro de Xactly eDocs & Approvals tanto para simplificar los procesos como para aumentar la flexibilidad a medida que los documentos transitan sin problemas a través de varios canales en su organización.

Cada vez que un representante de ventas solicita un documento de plan, el PDF Generator Service formatea el documento utilizando el marcado HTML que recibe del Headless Browser Service.

Xactly cambió recientemente de PhantomJS a Headless Chrome para generar contenido para documentos de planes en los flujos de trabajo de Xactly DocuSign. El cambio nos ayudó a continuar construyendo un sistema confiable con ganancias significativas de rendimiento y estabilidad.

Este artículo cubrirá:

• ¿Qué inspiró esta transición?
• Desafíos enfrentados durante el proceso.
• Cómo el equipo de ingeniería de Xactly logró este objetivo

Un poco de fondo

En Xactly, ejecutamos automatizaciones en máquinas remotas con cargas de trabajo de datos de producción. En el proceso, hemos realizado conscientemente una serie de modificaciones que han dado lugar a desafíos de mantenimiento, como un mayor consumo de memoria, una menor velocidad de procesamiento, fallas intermitentes e invalidaciones de caché.

Con más poder de cómputo disponible, hubo una explosión de capacidades técnicas con lo que pueden hacer las computadoras de hoy.

PhantomJS se había convertido en un elemento básico en nuestro flujo de trabajo, sin embargo, PhantomJS y otros navegadores sin interfaz no se han desarrollado al mismo ritmo que los ecosistemas front-end a lo largo de los años. Con ES6/7/8, los trabajadores web y de servicios, las API nativas y específicas del navegador, el shadow DOM y otras funciones han agregado su propio conjunto de desafíos. La estabilidad también es una preocupación importante.

Cuando se anunció el final de la vida útil de PhantomJS coincidiendo con la llegada de Headless Chrome, fue una bendición disfrazada para el equipo de ingeniería de Xactly. Comenzamos a ejecutar múltiples PoC (pruebas de concepto) para evaluar sus funciones, monitorear su estabilidad y rendimiento, y verificar su compatibilidad con el conjunto de funciones de nuestro producto.

Observamos que Headless Chrome es tremendamente rápido (con suficiente hardware), estable y, lo que es igualmente importante, fácil de usar para los desarrolladores. Esas razones fueron suficientes para que activáramos el interruptor.

¿Cómo logramos esto?

Como parte de nuestra iniciativa de ingeniería de confiabilidad, implementamos la nueva implementación en aproximadamente dos meses (incluidas las pruebas exhaustivas).

En el proceso, desarrollamos una lista de verificación de las cosas más importantes a considerar relacionadas con la infraestructura. Estas consideraciones incluyen:

• Hardware
• Compatibilidad del software con el sistema operativo
• Configuración de la máquina
• Cree e implemente flujos de trabajo y scripts
• crones
• Descubrimiento de servicios
• controles de salud
• Monitoreo de seguridad
• Monitoreo del servidor
• Sandboxing (cuando sea necesario)

Nuestro monolito PhantomJS se convirtió en un servicio independiente que ejecuta Headless Chrome, con varias instancias del servicio escaladas horizontalmente en varias máquinas multinúcleo con HAProxy.

En cada máquina, una aplicación de NodeJS se escala verticalmente mediante la agrupación de instancias de nodos y el equilibrio de carga mediante PM2. También usamos Puppeteer como nuestro cliente API de facto para hablar con Chromium. Actualmente, recopilamos todos los registros en un archivo local en la máquina, pero planeamos migrar a ELK (Elastic, Logstash, Kibana) en el futuro.

Con cada solicitud, el servicio de nodo llega a un punto final interno y genera el código HTML necesario para los parámetros solicitados. Posteriormente, esto se pasa a un servicio generador de PDF que genera documentos PDF personalizados.

Caché frío y sesiones prístinas

Es importante nunca sacrificar la seguridad por el rendimiento. Cada solicitud se ejecuta sin caché compartida y en una nueva instancia de Chromium. Estas instancias no se reutilizan para crear pestañas. Esto elimina la posibilidad de compartir datos entre dos instancias de Chromium al procesar el HTML, evitando así el acceso involuntario a datos entre empresas.

La sobrecarga de crear y destruir procesos de Chromium para cada solicitud entrante impone una penalización de rendimiento, pero aceptamos esta compensación en nombre de la seguridad. Esto se soluciona fácilmente utilizando un hardware más capaz.

Hechos rápidos

Hemos podido recopilar algunas estadísticas básicas y otra información sobre nuestra implementación, que incluyen lo siguiente:

• El tiempo para generar contenido para un solo documento oscila entre 4 y 10 segundos, dependiendo del tamaño del documento.
• A pesar de activar una nueva instancia de navegador para cada solicitud, una máquina de 8 núcleos generalmente puede generar más de 8000 documentos en menos de una hora. Esto nunca fue posible usando PhantomJS.
• Durante nuestras pruebas de carga, observamos lo siguiente:
  • Lo ideal es ejecutar aproximadamente 35 instancias activas del navegador. Cualquier valor significativamente superior a este número degrada el rendimiento debido a la sobrecarga del proceso. Para mantener las cosas más bajo control, implementamos mecanismos de cola.
• Sin hacer cola, nos encontramos con problemas relacionados con la memoria y el número máximo de subprocesos. En estos casos, notamos un aumento en la cantidad de procesos fantasma de Chrome, que debían eliminarse mediante un cronjob a intervalos regulares.
• En caso de que la solicitud entrante tarde demasiado en completarse o falle debido a algún error interno, intentamos varios reintentos según una configuración preconfigurada.
• Movimos configuraciones como tiempos de espera de API, reintentos, umbral y más a archivos de configuración externos.
• Todos los datos de análisis de métricas se envían a un sistema interno interno. En caso de que no tenga una implementación interna, puede usar la aplicación Keymetrics.

Que sigue

Nuestro sistema continúa evolucionando con mejoras planificadas y otras mejoras, incluidas las siguientes:

• Análisis de registros estructurados a través de ELK
• Supervisión mejorada
• Fiabilidad y rendimiento mejorados

Sobre el Autor

Mi nombre es Anvesh Checka y trabajo como ingeniero de software en el equipo de productos de Xactly. Me encanta crear interfaces de usuario y aplicaciones web con varios sistemas. Si tiene alguna pregunta o comentario, no dude en twittear o enviarme un mensaje.