Shipyard: cómo Slack construyó su plataforma EC2 de próxima generación

 (slack.engineering)
2 puntos por GN⁺ 1 시간 전 | Aún no hay comentarios. | Compartir por WhatsApp
  • Slack pasó de su enfoque anterior de modificar continuamente EC2 de larga duración a un despliegue de reemplazo basado en AMI inmutables, aplicando una forma moderna de despliegue incluso a cargas de trabajo difíciles de migrar a contenedores
  • Sobre la imagen base común slack-zero se apilan imágenes por servicio, y la configuración pesada se resuelve durante el horneado de imágenes, mientras que solo los secretos y metadatos por entorno se aplican al arrancar
  • El orquestador de despliegue Gondola gestiona una AMI y artefactos versionados de Chef como una sola unidad de despliegue, y realiza despliegues graduales basados en métricas, detenciones y rollback automático
  • Peekaboo ofrece casi en tiempo real el inventario completo de EC2, y The Reaper reemplaza instancias contaminadas o vencidas bajo límites de velocidad y mecanismos de pausa
  • Aunque es eficaz para servicios de corta duración, las instancias de larga duración que no pueden reemplazarse rápido, como nodos de datos, GitHub Enterprise y Atlassian JIRA, requieren un método de parcheo y ejecutores de despliegue aparte

Límites del modelo de EC2 modificado de forma continua

  • Slack transformó su antigua pila única de Chef en una estructura resiliente de múltiples pilas, e introdujo despliegues versionados de cookbook y procedimientos seguros de promoción, aumentando la confiabilidad y el control operativo sobre decenas de miles de instancias EC2
  • Después introdujo entornos de producción segmentados, ejecuciones de Chef basadas en señales y mejores métodos de rollout, reduciendo mucho el alcance del impacto de fallas sin que los equipos tuvieran que reescribir sus cookbook
    • En la etapa de Safety Without Disruption, obtuvo margen para mantener estable la plataforma legacy mientras planificaba la arquitectura futura
  • Sin embargo, el modelo de seguir actualizando instancias de larga duración dificultaba los despliegues por servicio, hacía imposible evitar el drift de infraestructura y se volvía más complejo cuanto más había que coordinar cambios entre varias capas
  • Los contenedores resolvieron parte del problema para algunas cargas de trabajo, pero no todos los sistemas podían migrarse fácilmente, así que hacía falta una plataforma que aplicara directamente a EC2 inmutabilidad, despliegues graduales y mecanismos automáticos de seguridad

El modelo operativo de EC2 que ofrece Shipyard

  • Shipyard es la plataforma EC2 de próxima generación de Slack, que trata la infraestructura no como instancias para modificar continuamente, sino como artefactos desplegables
  • Al combinar despliegues por servicio con sistemas de build y orquestación, aplica a las actualizaciones de EC2 el mismo nivel de seguridad y previsibilidad que una plataforma de despliegue de aplicaciones

  • Soporte para múltiples arquitecturas y sistemas operativos

    • Soporta varias arquitecturas de CPU, incluyendo AMD64 y Graviton basado en ARM, y puede usar Ubuntu, RHEL y Amazon Linux
    • Los equipos pueden elegir instancias y sistemas operativos según costo, rendimiento y compatibilidad sin tener que implementar una plataforma aparte
    • Es especialmente adecuado para componentes de infraestructura difíciles de migrar a contenedores, nodos worker de Kubernetes y la pila de red de egress

  • Despliegues seguros basados en métricas

  • Provisionamiento rápido y predecible

    • Usa una estructura de imágenes en capas similar a la de los contenedores para construir imágenes por servicio sobre una imagen base dorada compartida
    • Al reducir el trabajo que debe hacerse en tiempo de ejecución, las instancias arrancan de forma rápida y consistente en varias regiones

  • Gestión de configuración simplificada

    • Antes, tareas programadas de Chef revisaban y reaplicaban periódicamente la configuración para devolver al estado deseado cambios manuales o inesperados
    • En Shipyard, la configuración solo se aplica en etapas claras del ciclo de vida, como el horneado de imágenes y el provisionamiento inicial
    • Las herramientas de gestión de configuración se usan principalmente para desplegar servicios, en lugar de modificar continuamente todo el sistema
    • Con eso se reducen la carga en segundo plano y las sobrescrituras no deseadas, y como las instancias no siguen cambiando con el tiempo, es más fácil razonar sobre su comportamiento

  • Instancias con vida útil limitada

    • A cada instancia se le asigna una vida útil limitada y se reemplaza automáticamente de forma periódica
    • Eso reduce el tiempo en que posibles vulnerabilidades pueden causar problemas e impulsa a los equipos a reemplazar instancias en vez de modificarlas en ejecución

Inventario de Peekaboo y visibilidad de toda la flota

  • Peekaboo es un sistema de inventario que, en lugar de depender de Chef Server, usa eventos de la nube y metadatos de instancias para mostrar casi en tiempo real el estado de la flota EC2
  • También rastrea instancias desplegadas fuera de Shipyard, permitiendo ver toda la flota en un solo lugar
  • Está construido con AWS EventBridge, OpenSearch y Lambda, y ofrece las siguientes interfaces
    • UI para explorar la flota
    • API para integración de sistemas
    • CLI para verificaciones rápidas desde la línea de comandos
  • Al centralizar la información de EC2, unifica la telemetría y los puntos de administración en todo el entorno

slack-zero, la imagen base dorada

  • slack-zero es una imagen de máquina común creada por el Compute Platform Team y administrada en conjunto con los equipos de seguridad y monitoreo
  • Es una base estandarizada y confiable que todos los servicios heredan, y sobre la que los equipos de servicio construyen su propio entorno de runtime
  • La imagen incluye lo siguiente
    • Línea base del sistema operativo y configuraciones de hardening de seguridad
    • Configuración de red y de service discovery
    • Agentes de monitoreo y seguridad
    • Herramientas comunes y configuración base del sistema
  • La imagen base se trata como un objetivo inmutable y efímero
    • Cuando se necesitan parches de seguridad, actualizaciones de monitoreo o mejoras de red, se crea una nueva imagen slack-zero
    • Las imágenes de servicio derivadas se vuelven a construir sobre la nueva base para heredar las correcciones

  • Por qué eligieron AWS Image Builder

    • slack-zero se construye con AWS Image Builder en lugar del Packer anterior
    • Las políticas de ciclo de vida limpian automáticamente las AMI antiguas y reducen costos de almacenamiento
    • Cuando se genera una nueva imagen, se actualiza un parámetro de AWS Systems Manager (SSM) que apunta a la AMI más reciente por cuenta, y los pipelines de servicio lo leen para usar la base más reciente
    • Cuando el horneado de imagen termina con éxito, EventBridge y Lambda inician automáticamente pipelines descendientes en las cuentas propietarias de los servicios
    • Antes de publicar la AMI, se ejecutan pruebas de validación en instancias temporales para reducir el riesgo del rollout a producción

Horneado y provisionamiento de imágenes de servicio

  • Cada equipo de servicio crea su propia AMI basada en slack-zero, heredando componentes comunes de la plataforma mientras mantiene control sobre su entorno de runtime
  • El pipeline de imágenes de servicio define lo siguiente
    • Software que se instalará
    • Cómo se configurará el servicio
    • El procedimiento de inicialización de instancias para ese servicio
  • La mayor parte de la configuración se incluye en la imagen para mejorar la velocidad de ejecución, la consistencia y minimizar el drift de configuración

  • Separación de funciones en dos etapas

    • En la etapa de horneado, se instalan paquetes y configuraciones comunes entre entornos para que la instancia llegue al arranque ya mayormente en un estado listo
    • En la etapa de provisionamiento, al arrancar solo se aplican ajustes dependientes del entorno, como secretos, configuración por región y metadatos de despliegue
    • Por lo general, solo se realizan tareas como colocar archivos de configuración, recuperar secretos e iniciar servicios
    • Al mover tareas pesadas como la instalación de paquetes al horneado, las instancias pueden arrancar en segundos en lugar de minutos
    • El inicio rápido es importante para eventos de escalado, despliegues secuenciales y reemplazo automático de instancias, y el provisionamiento mínimo reduce el drift que podría surgir durante la adaptación en runtime

Actualización de la flota centrada en reemplazo de AMI

  • Los cambios se aplican creando una nueva AMI y haciéndola avanzar por el pipeline de despliegue, renovando la flota mediante reemplazo controlado en lugar de parchear instancias existentes
  • Los Auto Scaling Group (ASG) usan AWS Instance Refresh, y las flotas de workers de Kubernetes usan Karpenter
  • Los servicios con requisitos especiales de despliegue pueden agregar ejecutores separados, y Gondola unifica distintos patrones bajo una experiencia consistente de despliegue

  • Ruta de corrección de emergencia

    • En emergencias, se pueden aplicar cambios limitados de configuración a instancias en ejecución, pero luego esas instancias deben reemplazarse mediante el pipeline de despliegue normal
    • Las correcciones de emergencia se aplican ejecutando recipes de Chef seleccionadas mediante documentos predefinidos de AWS Systems Manager
    • Una vez estabilizado el sistema, las instancias se rotan para volver al estado inmutable deseado

Despliegues graduales con Gondola

  • Los pipelines de clientes pueden componerse de varias etapas ajustadas a los requisitos operativos y del servicio
  • Cada etapa de Gondola representa una unidad de despliegue, como un ASG, un clúster de Kubernetes o un grupo de instancias EC2
  • El Egress Team mantiene ASG separados de canary y producción en cada zona de disponibilidad, y ordena las etapas para que las actualizaciones fluyan secuencialmente
  • Gondola monitorea métricas clave mientras actualiza cada etapa y, si detecta problemas, hace rollback automático para evitar la propagación de incidentes

  • Artefactos y ejecutores de despliegue

    • El paquete de despliegue que crea Gondola se compone de dos partes
      • La AMI que se desplegará en la flota
      • El artefacto de Chef con recipes versionadas vinculadas a un commit de Git
    • Ambos elementos se tratan como una sola unidad de despliegue, y cada etapa hace rollout mediante el ejecutor definido por el servicio
    • En despliegues sobre ASG, el ejecutor actualiza el launch template con la nueva AMI y configuración
    • El código de Chef se empaqueta en Amazon S3
    • El bootstrapper integrado en las nuevas instancias obtiene el artefacto correcto y ejecuta las recipes correspondientes
    • Usa metadatos de configuración para aplicar solo los ajustes adecuados a ese rol
    • En flotas de workers de Kubernetes, el ejecutor entrega a Karpenter la AMI y los mismos metadatos de configuración, y los nodos también se inicializan del mismo modo
    • Incluso al agregar ejecutores para despliegues especiales, se mantiene el enfoque de AMI, artefactos de configuración versionados y bootstrap basado en metadatos

Reparto de responsabilidades entre el equipo de plataforma y los equipos de servicio

  • Los equipos de Compute, Security y Monitoring gestionan los componentes globales de infraestructura de la capa base, los parches de seguridad y la configuración obligatoria
  • Los equipos de servicio construyen sobre esa base AMI con su propio software y configuraciones específicas del servicio
  • Cuando el equipo de Compute despliega parches de seguridad, agentes de monitoreo o cambios de red, los equipos de servicio deben incorporar la imagen base actualizada en sus propias AMI
  • Este modelo de responsabilidad compartida equilibra consistencia, seguridad y confiabilidad de la flota mientras mantiene la autonomía de cada servicio

Excepción de secretos en una inmutabilidad no total

  • Aunque los paquetes y la configuración de las instancias de Shipyard quedan mayormente fijados durante el horneado, los secretos son la excepción
  • El servicio Consul Template de cada instancia despliega nuevos secretos desde Vault sin reemplazar toda la flota
  • Como credenciales y certificados pueden renovarse dinámicamente, Shipyard es una infraestructura semiinmutable donde solo quedan fijas las capas centrales del sistema y del servicio
  • Así mantiene estabilidad y previsibilidad mientras permite actualizar secretos críticos de runtime cuando es necesario

La política de reemplazo de The Reaper

  • The Reaper decide qué reemplazar a partir de dos tipos de entrada
    • Señales de contaminación enviadas por sistemas externos, como herramientas de seguridad o eventos de AWS EC2, cuando una instancia se desvía del estado deseado
    • Revisiones periódicas para verificar si la instancia ha estado ejecutándose más tiempo que su vida útil máxima permitida
  • Si se cumple cualquiera de las condiciones, programa el reemplazo de la instancia según la política del servicio
  • El acceso remoto manual se permite para emergencias, pero si alguien entra directamente a un nodo de nivel producción se emite una señal y la instancia queda marcada para reemplazo futuro
  • Integrado con Peekaboo, rastrea la edad de las instancias en toda la flota, y los nodos que alcanzan su vida útil máxima siguen el mismo procedimiento normal de apagado y reemplazo
  • A futuro, planean agregar conciencia de contexto para que solo los cambios significativos, como actualizaciones de software o drift de configuración, disparen reemplazos, evitando rotaciones innecesarias por operaciones de solo lectura o de bajo riesgo

  • Velocidad de reemplazo y control de emergencia

    • Con límites de velocidad integrados, se define por servicio, región y zona de disponibilidad cuántas instancias pueden reemplazarse al mismo tiempo, evitando impactos repentinos de capacidad
    • Con un mecanismo global de pausa llamado “big red button”, que coloca un objeto de control en S3, puede detenerse toda actividad de Reaper durante incidentes o periodos de alto riesgo
    • Desde la CLI se gestionan límites de velocidad, verificación de configuración y activación o desactivación de la pausa global
    • En situaciones break-glass que requieren investigación profunda, pueden usarse mecanismos de acceso controlado como certificados SSH de corta duración

Pruebas de infraestructura real con Ship Quick

  • Ship Quick es un flujo de trabajo para desarrolladores que permite a equipos de plataforma y responsables de servicio ejecutar pruebas realistas de horneado y provisionamiento en infraestructura real antes de hacer merge de un pull request
  • Los desarrolladores ejecutan comandos de CLI desde el repositorio de cookbook y definen los casos de prueba en archivos YAML
  • Ship Quick procesa en este orden
    • Empaqueta el cookbook y lo sube a S3
    • Envía un mensaje de workflow a una cola
    • Una instancia worker administrada por Longshoremen toma la tarea
    • El worker se desacopla de un Auto Scaling Group y ejecuta el workflow de Chef
    • Hace streaming de logs a la CLI y luego termina, aunque el desarrollador puede elegir mantenerlo para depuración

  • Flotas de workers por capa base

    • Debido a la estructura de bootstrap, operan dos flotas separadas de workers
    • La flota base de Ubuntu hornea y prueba la imagen base sobre una AMI limpia de Ubuntu, porque slack-zero no puede construirse sobre sí misma
    • La flota slack-zero prueba cookbook de equipos de servicio que dependen de una slack-zero prehorneada
    • Valida el provisionamiento sobre la misma base que producción
    • Se actualiza continuamente con las imágenes más recientes para reflejar el entorno actual de producción
    • Ambas flotas hacen auto scaling según la demanda
    • Los equipos que crean imágenes en su propia cuenta de AWS pueden configurar una flota dedicada de workers y enviar ahí los trabajos de Ship Quick para mantener el aislamiento

Expansión hacia cargas de trabajo de larga duración

  • Shipyard actualmente funciona de manera efectiva en servicios de corta duración y sigue incorporando equipos desde la plataforma EC2 legacy
  • El siguiente desafío son las instancias de larga duración que no pueden rotarse rápidamente
    • Nodos de datos de Slack
    • Servicios singleton como GitHub Enterprise
    • Instancias de tecnología de negocio de terceros como Atlassian JIRA
  • Estas cargas de trabajo requieren métodos seguros de parcheo y actualización, además de políticas de ciclo de vida que The Reaper pueda manejar correctamente
  • En colaboración con los equipos de servicio, están desarrollando un ejecutor de cargas de trabajo de larga duración para Gondola, y planean seguir mejorando herramientas, flujos de trabajo para desarrolladores y experiencia de despliegue a medida que crezca la adopción
  • Más adelante abordarán por separado la API de Shipyard, los pipelines de imágenes, los flujos de trabajo para desarrolladores, los componentes del sistema de inventario y los problemas surgidos al escalar la plataforma

Lecturas relacionadas

Aún no hay comentarios.

Aún no hay comentarios.