Cómo reducir el tiempo de arranque de EC2

• Es posible reducir el tiempo de arranque de una instancia EC2 de 40 segundos a 5 segundos
• Esto es muy importante cuando se necesita una nueva instancia EC2 para procesar una tarea específica

Por qué el tiempo de arranque tarda tanto

• Cuando se solicita una nueva instancia EC2, AWS realiza varias tareas:
  • Crear el volumen raíz EBS a partir de la AMI seleccionada
  • Asignar una dirección IP privada a la instancia
  • Elegir un host para la instancia
  • Arrancar realmente la máquina
• Incluso después de que el hardware se enciende, todavía deben iniciarse el bootloader, el kernel y los procesos del espacio de usuario.

Cómo evitar el problema

• Operar un pool de cómputo en espera para enrutar las solicitudes de build a instancias EC2 que ya están en ejecución.
• Sin embargo, no es económicamente viable para todas las tareas.
• En el caso de los runners de GitHub Actions, cada trabajo se enruta a una instancia EC2 dedicada.
• Mantener 50 instancias EC2 en línea para procesar 50 trabajos en paralelo no es realista.

Tiempos de arranque más rápidos

• Para ciertas tareas, siempre es más rápido no hacer trabajo innecesario.
• Se optimiza de forma sistemática cada etapa de la creación de la instancia, el arranque y el inicio de la aplicación.
• Se usa un método de arrancar la instancia una vez, detenerla y volver a arrancarla cuando sea necesario.

Streaming del volumen raíz EBS

• La preparación del volumen raíz EBS tiene un gran impacto en el tiempo de arranque de la instancia EC2 y en el rendimiento de la aplicación.
• Cuando se crea un volumen EBS desde una AMI, los bloques de datos deben recuperarse desde S3 la primera vez que se accede a ellos.
• AWS recomienda precargar todos los bloques de datos.

Arrancar la instancia una sola vez

• Una instancia respaldada por EBS puede detenerse y luego volver a iniciarse.
• Una instancia detenida conserva solo la configuración y se paga únicamente el costo del volumen raíz EBS.
• Si la instancia se arranca una vez para realizar las tareas de inicialización y luego se detiene, se crea un volumen raíz EBS "calentado".

Warm pools de Auto Scaling

• AWS ofrece warm pools para EC2 Auto Scaling.
• Sin embargo, los grupos de Auto Scaling tardan en reaccionar a las solicitudes.
• Para obtener el mejor rendimiento, se inician directamente las instancias EC2 usando las llamadas a la API LaunchInstances y StartInstances.

Redimensionamiento de instancias

• Se optimiza el tiempo de arranque cambiando el tipo de las instancias calentadas.
• Para las tareas de inicialización se usa un tipo de instancia económico, y para el trabajo real se cambia a un tipo de instancia de mayor rendimiento.

Flujo completo

• Las instancias runner de GitHub Actions siguen un flujo como este:
  • Se crean como instancias t3.large
  • Se les asigna una dirección IP privada en la VPC de destino
  • El kernel y los procesos del espacio de usuario se inician una vez
  • La instancia se detiene
  • Cuando llega una solicitud de trabajo, se actualiza el tipo de instancia a m7a y se inicia
  • Si no hay capacidad disponible para instancias m7a, se actualiza a un tipo de respaldo y se vuelve a iniciar
• Con este flujo, el tiempo de preparación de la instancia para un trabajo se reduce de 40 segundos a 5 segundos.

[GN⁺]

Comentarios de Hacker News

Resumen

• Tiempo de arranque: es un factor clave para el éxito del autoescalado; cuanto más corto sea, más pequeña será la ventana de predicción y mayor será la precisión. Para reducir costos, puede ser razonable preparar con anticipación los volúmenes EBS.
• Optimización de Amazon: Amazon ha logrado arranques ultrarrápidos con tecnologías como Firecracker, y es posible que ofrezca capacidades similares en EC2.
• Configuración inmutable: mediante una configuración inmutable/atómica, se pueden compartir volúmenes EBS y optimizar usando una AMI mínima de arranque.
• Medición del tiempo de arranque: el tiempo de arranque de las instancias EC2 muestra una distribución bimodal, de 15-20 segundos o de 80 segundos. Hace falta identificar la causa.
• Acciones de GitHub: a pesar de la optimización del arranque de los runners de GitHub Actions, el tiempo de entrega de trabajos sigue siendo largo, por lo que se necesita optimización.
• Comparación con AWS: comparación del tiempo de arranque entre AWS y otros proveedores de nube. Hetzner crea instancias en cuestión de segundos.
• Autoescalador de EC2: se mencionan las limitaciones del autoescalador de EC2 y la necesidad de mejorarlo. El autoescalador provisto por AWS es lento y limitado.
• Razón para usar EBS: EBS sacrifica costo y rendimiento a cambio de durabilidad. Al ser un volumen conectado por red, es lento. Una instalación mínima de Linux y almacenamiento local rápido serían más adecuados.
• Falta de soporte de Copy-On-Write en EBS: EBS no soporta Copy-On-Write, y como los snapshots se almacenan en S3, la asignación de IOPS se retrasa.
• Migración a hardware on-premise: Depot podría optimizar el rendimiento y reducir costos migrando a hardware on-premise. Arrancar directamente las tareas de CI de los clientes en el hipervisor podría ser un mejor enfoque.