Reduzindo o tempo de boot do EC2

• É possível reduzir o tempo de boot de instâncias EC2 de 40 segundos para 5 segundos
• Isso é muito importante quando uma nova instância EC2 é necessária para processar uma tarefa específica

Por que o tempo de boot é demorado

• Ao solicitar uma nova instância EC2, a AWS executa várias tarefas:
  • criar o volume EBS raiz a partir da AMI selecionada
  • atribuir um endereço IP privado à instância
  • escolher um host para a instância
  • inicializar a máquina de fato
• Mesmo depois que o hardware é ligado, o bootloader, o kernel e os processos em espaço de usuário ainda precisam ser iniciados.

Como contornar o problema

• Operar um pool de computação em espera para rotear solicitações de build para instâncias EC2 que já estejam em execução.
• Porém, isso não é economicamente viável para todas as cargas de trabalho.
• No caso de runners do GitHub Actions, cada job é roteado para uma instância EC2 dedicada.
• Manter 50 instâncias EC2 online para lidar com 50 jobs paralelos é irrealista.

Tempos de boot mais rápidos

• Para certas tarefas, sempre é mais rápido evitar trabalho desnecessário.
• Cada etapa da criação da instância, do boot e da inicialização da aplicação é otimizada de forma sistemática.
• Usa-se um método em que a instância é iniciada uma vez, desligada e depois iniciada novamente quando necessário.

Streaming do volume raiz EBS

• A preparação do volume raiz EBS tem grande impacto no tempo de boot da instância EC2 e no desempenho da aplicação.
• Ao criar um volume EBS a partir de uma AMI, os blocos de dados precisam ser buscados do S3 quando são acessados pela primeira vez.
• A AWS recomenda pré-carregar todos os blocos de dados.

Inicializar a instância uma vez

• Instâncias com suporte a EBS podem ser paradas e iniciadas novamente.
• Uma instância parada mantém apenas sua configuração, e você paga somente pelo volume EBS raiz.
• Se a instância for iniciada uma vez para executar tarefas de inicialização e depois parada, cria-se um volume raiz EBS "aquecido".

Warm pools do Auto Scaling

• A AWS oferece warm pools para o EC2 Auto Scaling.
• Porém, grupos de Auto Scaling levam tempo para reagir às solicitações.
• Para obter o melhor desempenho, usa-se diretamente as chamadas de API LaunchInstances e StartInstances para iniciar instâncias EC2.

Redimensionamento da instância

• O tempo de boot é otimizado alterando o tipo da instância aquecida.
• Para as tarefas de inicialização, usa-se um tipo de instância barato e, no trabalho real, ele é trocado por um tipo de instância de maior desempenho.

Fluxo completo

• A instância runner do GitHub Actions segue o fluxo abaixo:
  • criada como uma instância t3.large
  • recebe um endereço IP privado na VPC de destino
  • kernel e processos em espaço de usuário são iniciados uma vez
  • instância é parada
  • quando chega uma solicitação de job, o tipo da instância é atualizado para m7a e ela é iniciada
  • se não houver capacidade para instâncias m7a, o tipo é atualizado para um tipo de backup e a instância é iniciada novamente
• Com esse fluxo, o tempo para preparar uma instância para um job cai de 40 segundos para 5 segundos.

[GN⁺]

Comentários no Hacker News

Resumo

• Tempo de boot: é um fator-chave para o sucesso do auto scaling; quanto menor o tempo de boot, menor a janela de previsão e maior a precisão da previsão. Para reduzir custos, pode fazer sentido preparar volumes EBS com antecedência.
• Otimização da Amazon: a Amazon implementou boot ultrarrápido com tecnologias como o Firecracker e pode oferecer recursos semelhantes também no EC2.
• Configuração imutável: com configuração imutável/atômica, é possível compartilhar volumes EBS e otimizar usando uma AMI mínima de boot.
• Medição do tempo de boot: o tempo de boot de instâncias EC2 aparece com distribuição bimodal, ficando em 15–20 segundos ou 80 segundos. É preciso entender a causa.
• GitHub Actions: apesar da otimização de boot dos runners do GitHub Actions, o tempo de entrega das tarefas continua alto e precisa ser otimizado.
• Comparação com a AWS: comparação do tempo de boot entre a AWS e outros provedores de nuvem. A Hetzner cria instâncias em poucos segundos.
• Auto Scaling do EC2: são mencionadas as limitações do auto scaling do EC2 e a necessidade de melhorias. O auto scaling oferecido pela AWS é lento e limitado.
• Motivo para usar EBS: o EBS sacrifica custo e desempenho em favor da durabilidade. Por ser um volume conectado pela rede, é lento. Uma instalação Linux mínima e armazenamento local rápido podem ser mais adequados.
• Falta de suporte a Copy-On-Write no EBS: o EBS não oferece suporte a Copy-On-Write, e os snapshots são armazenados no S3, o que atrasa a alocação de IOPS.
• Migração para hardware on-premises: a Depot pode migrar para hardware on-premises para otimizar o desempenho e reduzir custos. Inicializar os jobs de CI dos clientes diretamente no hypervisor pode ser uma abordagem melhor.