Saltar al contenido
Cosas Tecnológicas

Ingeniería de confiabilidad del sitio en Starship

Ingeniería de confiabilidad del sitio en Starship
Foto de Ben Davis, Instagram slovaceck_

Ejecutar robots autónomos en las calles de la ciudad es un desafío de ingeniería de software. Parte de este software se ejecuta en el propio robot, pero gran parte se ejecuta en el backend. Cosas como control remoto, búsqueda de rutas, hacer coincidir los robots con los clientes, gestión del estado de la flota, pero también interacciones con clientes y comerciantes. Todo esto debe ejecutarse las 24 horas del día, los 7 días de la semana, sin interrupciones y escalar dinámicamente para adaptarse a la carga de trabajo.

SRE en Starship es responsable de proporcionar la infraestructura en la nube y los servicios de plataforma para ejecutar estos servicios de backend. Nos hemos estandarizado en Gobernadores para nuestros microservicios y lo están ejecutando sobre AWS. MongoDb es la base de datos principal para la mayoría de los servicios de backend, pero también nos gusta PostgreSQL, especialmente donde se requieren fuertes garantías de mecanografía y transacciones. Para mensajería asincrónica Kafka es la plataforma de mensajería preferida y la estamos usando para casi todo, aparte del envío de transmisiones de video desde robots. Para la observabilidad confiamos en Prometeo y Grafana, Loki, Izquierda y Jaeger. CICD es manejado por Jenkins.

Una buena parte del tiempo de SRE se dedica a mantener y mejorar la infraestructura de Kubernetes. Kubernetes es nuestra principal plataforma de implementación y siempre hay algo que mejorar, ya sea ajustar la configuración de ajuste de escala automático, agregar políticas de interrupción de pod u optimizar el uso de la instancia de Spot. A veces es como colocar ladrillos, simplemente instalar un gráfico de Helm para proporcionar una funcionalidad particular. Pero a menudo los “ladrillos” deben ser cuidadosamente seleccionados y evaluados (es Loki bueno para la gestión de registros, es Service Mesh una cosa y luego cuál) y ocasionalmente la funcionalidad no existe en el mundo y tiene que escribirse desde cero. Cuando esto sucede, generalmente recurrimos a Python y Golang, pero también a Rust y C cuando es necesario.

Otra gran parte de la infraestructura de la que SRE es responsable son los datos y las bases de datos. Starship comenzó con un único MongoDb monolítico, una estrategia que ha funcionado bien hasta ahora. Sin embargo, a medida que el negocio crece, debemos revisar esta arquitectura y empezar a pensar en dar soporte a los robots por miles. Apache Kafka es parte de la historia del escalado, pero también necesitamos descubrir la arquitectura de la base de datos de microservicio, la agrupación regional y la fragmentación. Además de eso, estamos constantemente desarrollando herramientas y automatización para administrar la infraestructura de base de datos actual. Ejemplos de: agregue la observabilidad de MongoDb con un proxy lateral personalizado para analizar el tráfico de la base de datos, habilite la compatibilidad con PITR para las bases de datos, automatice las pruebas periódicas de recuperación y conmutación por error, recopile métricas para la fragmentación de Kafka, habilite la retención de datos.

Finalmente, uno de los objetivos más importantes de Site Reliability Engineering es minimizar el tiempo de inactividad de la producción de Starship. Si bien ocasionalmente se llama a SRE para hacer frente a las interrupciones de la infraestructura, el trabajo más impactante se realiza para prevenir las interrupciones y garantizar que podamos recuperarnos rápidamente. Este puede ser un tema muy amplio, que va desde tener una infraestructura K8 sólida como una roca hasta prácticas de ingeniería y procesos comerciales. ¡Hay grandes oportunidades para causar un impacto!

Un día en la vida de una SRE

Llegando al trabajo, en algún momento entre las 9 y las 10 (a veces trabajando de forma remota). Toma una taza de café, revisa los mensajes y correos electrónicos de Slack. Revise las alertas que se dispararon durante la noche, vea si hay algo interesante allí.

Descubra que las latencias de conexión de MongoDb se han disparado durante la noche. Al profundizar en las métricas de Prometheus con Grafana, descubra que esto sucede durante el tiempo que se ejecutan las copias de seguridad. ¿Por qué esto de repente es un problema, hemos ejecutado esas copias de seguridad durante años? Resulta que estamos comprimiendo de manera muy agresiva las copias de seguridad para ahorrar en costos de red y almacenamiento y esto está consumiendo toda la CPU disponible. Parece que la carga en la base de datos ha aumentado un poco para que esto se note. Esto está sucediendo en un nodo en espera, sin afectar la producción, sin embargo, sigue siendo un problema si falla el primario. Agrega un elemento de Jira para solucionar este problema.

De paso, cambie el código de prueba de MongoDb (Golang) para agregar más depósitos de histograma para obtener una mejor comprensión de la distribución de latencia. Ejecute una tubería de Jenkins para poner en producción la nueva sonda.

A las 10 am hay una reunión de Standup, comparte tus actualizaciones con el equipo y descubre lo que otros han estado haciendo: configurar el monitoreo para un servidor VPN, instrumentar una aplicación Python con Prometheus, configurar ServiceMonitors para servicios externos, depurar problemas de conectividad de MongoDb, pilotando despliegues canarios con Flagger.

Después de la reunión, reanude el trabajo planificado para el día. Una de las cosas que planeé hacer hoy era configurar un clúster Kafka adicional en un entorno de prueba. Estamos ejecutando Kafka en Kubernetes, por lo que debería ser sencillo tomar los archivos YAML del clúster existente y modificarlos para el nuevo clúster. O, pensándolo bien, ¿deberíamos usar Helm en su lugar, o tal vez hay un buen operador de Kafka disponible ahora? No, no iré allí, demasiada magia, quiero un control más explícito sobre mis conjuntos de estado. YAML crudo lo es. Una hora y media después, se está ejecutando un nuevo clúster. La configuración fue bastante sencilla; solo los contenedores de inicio que registran a los corredores de Kafka en DNS necesitaban un cambio de configuración. La generación de las credenciales para las aplicaciones requirió un pequeño script bash para configurar las cuentas en Zookeeper. Un bit que quedó pendiente fue configurar Kafka Connect para capturar los eventos de registro de cambios de la base de datos; resulta que las bases de datos de prueba no se están ejecutando en el modo ReplicaSet y Debezium no puede obtener oplog de ellas. Retrasa esto y sigue adelante.

Ahora es el momento de preparar un escenario para el ejercicio Wheel of Misfortune. En Starship los estamos ejecutando para mejorar nuestra comprensión de los sistemas y compartir técnicas de resolución de problemas. Funciona rompiendo alguna parte del sistema (generalmente en prueba) y haciendo que alguna persona desafortunada intente solucionar y mitigar el problema. En este caso, configuraré una prueba de carga con Oye para sobrecargar el microservicio para los cálculos de ruta. Implemente esto como un trabajo de Kubernetes llamado “haymaker” y ocúltelo lo suficientemente bien para que no aparezca inmediatamente en la malla de servicios de Linkerd (sí, malvado 😈). Luego ejecute el ejercicio “Rueda” y tome nota de cualquier brecha que tengamos en los libros de jugadas, métricas, alertas, etc.

En las últimas horas del día, bloquee todas las interrupciones e intente realizar la codificación. He vuelto a implementar el analizador Mongoproxy BSON como transmisión asíncrona (Rust + Tokio) y quiero averiguar qué tan bien funciona esto con datos reales. Resulta que hay un error en algún lugar de las entrañas del analizador y necesito agregar un registro profundo para resolver esto. Encuentra una maravillosa biblioteca de rastreo para Tokio y déjate llevar por ella …

Descargo de responsabilidad: los eventos descritos aquí se basan en una historia real. No todo sucedió el mismo día. Algunas reuniones e interacciones con compañeros de trabajo se han eliminado. Estamos contratando.


Site Reliability Engineering en Starship se publicó originalmente en Starship Technologies on Medium, donde las personas continúan la conversación destacando y respondiendo a esta historia.