Shipyard: como a Slack construiu sua plataforma EC2 de próxima geração

• A Slack passou do modelo antigo de corrigir continuamente EC2s de longa duração para deploys por substituição baseados em AMIs imutáveis, aplicando uma abordagem moderna de deploy também a workloads difíceis de migrar para contêineres
• Sobre a imagem base comum slack-zero, são empilhadas imagens específicas de cada serviço; configurações pesadas são tratadas no bake da imagem, enquanto apenas segredos e metadados específicos do ambiente são aplicados na inicialização
• O orquestrador de deploy Gondola gerencia AMIs e artefatos Chef versionados como uma única unidade de deploy, realizando rollout gradual baseado em métricas, interrupção e rollback automático
• Peekaboo fornece um inventário quase em tempo real de todo o EC2, e The Reaper substitui instâncias contaminadas ou expiradas sob limites de velocidade e mecanismos de pausa
• É eficaz para serviços de curta duração, mas instâncias de longa duração que não podem ser substituídas rapidamente, como nós de dados, GitHub Enterprise e Atlassian JIRA, exigem uma abordagem separada de patches e um executor de deploy próprio

---

Limitações do modelo EC2 corrigido continuamente

• A Slack substituiu sua antiga pilha Chef única por uma arquitetura resiliente de múltiplas pilhas e introduziu deploys de cookbooks versionados e um processo seguro de promoção, aumentando a confiabilidade e o controle operacional sobre dezenas de milhares de instâncias EC2
  • O processo relacionado pode ser visto em Advancing Our Chef Infrastructure
• Depois, introduziu ambientes de produção segmentados, execuções do Chef baseadas em sinais e métodos de rollout aprimorados, reduzindo bastante o raio de impacto de falhas sem que as equipes precisassem reescrever cookbooks
  • Na etapa Safety Without Disruption, a plataforma legada foi mantida de forma estável enquanto se ganhava espaço para planejar a arquitetura futura
• Porém, o modelo de continuar atualizando instâncias de longa duração dificultava deploys por serviço, não conseguia evitar drift de infraestrutura e ficava mais complexo à medida que mudanças em várias camadas precisavam ser coordenadas
• Contêineres resolveram problemas de alguns workloads, mas nem todos os sistemas podiam ser migrados facilmente; por isso, era necessária uma plataforma que aplicasse diretamente ao EC2 imutabilidade, deploys graduais e salvaguardas automáticas

O modelo de operação EC2 oferecido pelo Shipyard

• Shipyard é a plataforma EC2 de próxima geração da Slack, que trata a infraestrutura como artefatos implantáveis, e não como instâncias a serem modificadas continuamente
• Ela combina deploys por serviço com sistemas de build e orquestração, aplicando às atualizações de EC2 o mesmo nível de segurança e previsibilidade de uma plataforma de deploy de aplicações

• Suporte a várias arquiteturas e sistemas operacionais

  • Oferece suporte a várias arquiteturas de CPU, incluindo AMD64 e Graviton baseado em ARM, e permite usar Ubuntu, RHEL e Amazon Linux
  • As equipes podem escolher instâncias e sistemas operacionais conforme custo, desempenho e compatibilidade, sem implementar uma plataforma separada
  • É especialmente adequada para componentes de infraestrutura, nós workers do Kubernetes e stacks de rede de egress difíceis de migrar para contêineres

• Deploy seguro baseado em métricas

  • Cada serviço é integrado ao Gondola para executar rollouts graduais com verificações automáticas de segurança baseadas em métricas
  • Dependendo dos sinais de saúde do serviço, o deploy pode ser interrompido automaticamente ou sofrer rollback automático para a versão saudável anterior

• Provisionamento rápido e previsível

  • Usa uma estrutura de imagens em camadas, semelhante a contêineres, para construir imagens específicas de serviço sobre uma imagem base golden comum
  • Ao reduzir o trabalho feito em tempo de execução, as instâncias sobem de forma rápida e consistente em várias regiões

• Gerenciamento de configuração simplificado

  • No passado, tarefas agendadas do Chef verificavam e reaplicavam configurações periodicamente, revertendo alterações manuais ou inesperadas ao estado desejado
  • No Shipyard, a configuração é aplicada apenas em etapas claras do ciclo de vida, como bake da imagem e provisionamento inicial
  • As ferramentas de gerenciamento de configuração são usadas principalmente para implantar serviços, em vez de modificar continuamente o sistema inteiro
  • Com isso, reduzem-se a carga em segundo plano e sobrescritas não intencionais; como as instâncias não continuam mudando ao longo do tempo, fica mais fácil raciocinar sobre seu comportamento

• Instâncias com vida útil limitada

  • Cada instância recebe uma vida útil limitada e é substituída automaticamente de forma periódica
  • Isso reduz o tempo em que vulnerabilidades potenciais podem causar problemas e incentiva as equipes a substituir instâncias em vez de modificá-las em execução

Inventário Peekaboo e visibilidade de toda a frota

• Peekaboo é um sistema de inventário que usa eventos de nuvem e metadados de instância, em vez do Chef Server, para mostrar quase em tempo real o estado da frota EC2
• Ele também rastreia instâncias implantadas fora do Shipyard, permitindo visualizar toda a frota em um só lugar
• Foi construído com AWS EventBridge, OpenSearch e Lambda, e oferece as seguintes interfaces
  • UI para explorar a frota
  • API para integração com sistemas
  • CLI para verificações rápidas pela linha de comando
• Ao centralizar as informações do EC2, unifica os pontos de telemetria e gerenciamento em todo o ambiente

Imagem base golden slack-zero

• slack-zero é uma imagem de máquina comum criada pela Compute Platform Team e gerenciada em conjunto com as equipes de segurança e monitoramento
• É uma base padronizada e confiável herdada por todos os serviços; as equipes de serviço configuram seus próprios ambientes de runtime sobre ela
• A imagem inclui os seguintes elementos
  • Baseline do sistema operacional e configurações de hardening de segurança
  • Configuração de rede e service discovery
  • Agentes de monitoramento e segurança
  • Ferramentas comuns e configuração de sistemas de base
• A imagem base é tratada como um alvo imutável e efêmero
  • Quando são necessários patches de segurança, atualizações de monitoramento ou melhorias de rede, uma nova imagem slack-zero é criada
  • As imagens dos serviços descendentes são reconstruídas sobre a nova base para herdar as correções

• Por que escolher o AWS Image Builder

  • A slack-zero é construída com AWS Image Builder, em vez do Packer usado anteriormente
  • Políticas de ciclo de vida limpam automaticamente AMIs antigas, reduzindo custos de armazenamento
  • Quando uma nova imagem é criada, o parâmetro AWS Systems Manager (SSM) que aponta para a AMI mais recente de cada conta é atualizado, e os pipelines de serviço leem esse parâmetro para usar a base mais recente
  • Quando o bake da imagem é concluído com sucesso, EventBridge e Lambda iniciam automaticamente pipelines descendentes nas contas dos proprietários dos serviços
  • Antes de publicar a AMI, testes de validação são executados em uma instância temporária, reduzindo o risco do rollout em produção

Bake e provisionamento de imagens de serviço

• Cada equipe de serviço cria sua própria AMI com base na slack-zero, herdando componentes comuns da plataforma e mantendo controle sobre seu ambiente de runtime
• O pipeline de imagem do serviço define os seguintes itens
  • Software a ser instalado
  • Forma de configurar o serviço
  • Procedimentos de inicialização de instâncias desse serviço
• A maior parte da configuração é incluída na imagem para aumentar a velocidade e a consistência de execução e minimizar drift de configuração

• Separação de papéis em duas etapas

  • Na etapa de bake, pacotes e configurações comuns entre ambientes são instalados, para que a instância já tenha a maior parte de seu estado saudável preparada antes de ser executada
  • Na etapa de provisionamento, durante o boot, são aplicadas apenas configurações dependentes do ambiente, como segredos, configurações por região e metadados de deploy
  • Em geral, ela apenas posiciona arquivos de configuração, consulta segredos e inicia serviços
  • Ao mover tarefas pesadas, como instalação de pacotes, para o bake, a instância pode ficar operacional em segundos, não em minutos
  • A inicialização rápida é importante para eventos de escala, deploys sequenciais e substituição automática de instâncias; o provisionamento mínimo reduz o drift que poderia surgir durante adaptações em runtime

Atualizações de frota centradas na substituição de AMI

• As mudanças são lançadas criando uma nova AMI e fazendo o rollout pelo pipeline de deploy; a frota é atualizada por substituição controlada, sem aplicar patches às instâncias existentes
• Auto Scaling Groups (ASG) usam AWS Instance Refresh, e frotas de workers Kubernetes usam Karpenter
• Serviços com requisitos especiais de deploy podem adicionar executores próprios, enquanto o Gondola integra padrões diferentes em uma experiência de deploy consistente

• Caminho para correções emergenciais

  • Em emergências, é possível aplicar mudanças limitadas de configuração em instâncias em execução, mas depois essas instâncias devem ser substituídas pelo pipeline normal de deploy
  • A correção emergencial é aplicada executando recipes Chef selecionadas por meio de documentos predefinidos do AWS Systems Manager
  • Quando o sistema se estabiliza, as instâncias são rotacionadas para retornar ao estado imutável pretendido

Deploy gradual do Gondola

• Pipelines de clientes podem ser configurados em várias etapas, conforme o serviço e os requisitos operacionais
• Cada etapa do Gondola representa uma unidade de deploy, como um ASG, um cluster Kubernetes ou um grupo de instâncias EC2
• A Egress Team mantém ASGs separados de canário e produção em cada zona de disponibilidade e organiza as etapas para que as atualizações fluam sequencialmente
• O Gondola monitora métricas-chave enquanto atualiza cada etapa e, se detectar problemas, faz rollback automático para impedir a propagação da falha

• Artefatos de deploy e executores

  • O pacote de deploy criado pelo Gondola é composto por duas partes
    • A AMI a ser implantada na frota
    • Um artefato Chef contendo recipes versionadas vinculadas a um commit Git
  • Os dois elementos são tratados como uma única unidade de deploy, e cada etapa faz rollout por meio do executor definido pelo serviço
  • Em deploys de ASG, o executor atualiza o launch template com a nova AMI e configuração
  • O código Chef é empacotado no Amazon S3
  • O bootstrapper embutido da nova instância busca o artefato correto e executa as recipes relevantes
  • Metadados de configuração são usados para aplicar apenas as configurações adequadas àquela função
  • Em frotas de workers Kubernetes, o executor entrega ao Karpenter a AMI a ser usada e os mesmos metadados de configuração, e os nós são inicializados da mesma maneira
  • Mesmo quando executores para deploys especiais são adicionados, o modelo de AMI, artefatos de configuração versionados e bootstrap baseado em metadados permanece igual

Divisão de responsabilidades entre equipes de plataforma e de serviço

• As equipes de Compute, Security e Monitoring gerenciam os componentes globais de infraestrutura da camada base, patches de segurança e configurações obrigatórias
• As equipes de serviço constroem AMIs que adicionam seu próprio software e configurações específicas do serviço sobre essa base
• Quando a equipe de Compute distribui patches de segurança, agentes de monitoramento e mudanças de rede, as equipes de serviço devem incorporar a imagem base atualizada às suas próprias AMIs
• Esse modelo de responsabilidade compartilhada mantém a autonomia por serviço ao mesmo tempo em que alinha a consistência, segurança e confiabilidade da frota

Exceção de segredos em vez de imutabilidade total

• Pacotes e configurações das instâncias Shipyard ficam majoritariamente fixos no momento do bake, mas segredos são uma exceção
• O serviço Consul Template de cada instância distribui novos segredos do Vault sem substituir a frota
• Como credenciais ou certificados podem ser renovados dinamicamente, o Shipyard é uma infraestrutura semi-imutável, com apenas o sistema central e a camada de serviço fixos
• Isso mantém estabilidade e previsibilidade, permitindo atualizar segredos críticos de runtime quando necessário

Política de substituição do The Reaper

• The Reaper determina alvos de substituição a partir de dois tipos de entrada
  • Sinais de contaminação enviados por sistemas externos, como ferramentas de segurança ou eventos do AWS EC2, indicando que uma instância saiu do estado desejado
  • Verificações periódicas para saber se a instância está em execução há mais tempo que a vida útil máxima permitida
• Se qualquer uma das condições for atendida, a substituição da instância é agendada conforme a política do serviço
• Acesso remoto manual é permitido para emergências, mas conectar-se diretamente a um nó de nível de produção gera um sinal e marca a instância como candidata a substituição futura
• Integrado ao Peekaboo, ele acompanha a idade das instâncias em toda a frota; nós que atingem a vida útil máxima seguem o mesmo processo de desligamento saudável e substituição
• No futuro, a equipe planeja adicionar consciência de contexto para que apenas mudanças significativas, como atualizações de software ou drift de configuração, provoquem substituição, enquanto operações somente leitura ou de baixo risco não gerem rotações desnecessárias

• Velocidade de substituição e controle de emergência

  • Limites de velocidade embutidos definem quantas instâncias podem ser substituídas de uma vez por serviço, região e zona de disponibilidade, evitando impactos súbitos de capacidade
  • Um mecanismo global de pausa, o “big red button”, que posiciona um objeto de controle no S3, pode interromper toda a atividade do Reaper durante incidentes ou períodos de alto risco
  • A CLI permite gerenciar limites de velocidade, verificar configurações e ativar ou desativar a pausa global
  • Em situações break-glass que exigem investigação profunda, podem ser usados métodos de acesso controlado, como certificados SSH de curta duração

Testes em infraestrutura real com Ship Quick

• Ship Quick é um workflow de desenvolvedor no qual equipes de plataforma e donos de serviço executam testes realistas de bake e provisionamento em infraestrutura real antes de mesclar um pull request
• O desenvolvedor executa um comando CLI no repositório de cookbooks e define casos de teste em um arquivo YAML
• O Ship Quick processa na seguinte ordem
  • Empacota o cookbook e faz upload para o S3
  • Envia uma mensagem de workflow para uma fila
  • Uma instância worker gerenciada pelos Longshoremen pega a tarefa
  • O worker é desanexado do Auto Scaling Group e executa o workflow do Chef
  • Os logs são transmitidos para a CLI e, em seguida, a instância é encerrada; o desenvolvedor também pode optar por mantê-la para depuração

• Frotas de workers por camada base

  • Devido à estrutura de bootstrap, são operadas duas frotas de workers separadas
  • A frota Ubuntu básica faz bake e testa a imagem base a partir de uma AMI Ubuntu limpa, porque a slack-zero não pode ser construída sobre si mesma
  • A frota slack-zero testa cookbooks de equipes de serviço que dependem da slack-zero pré-bakeada
  • O provisionamento é validado sobre a mesma base usada em produção
  • As frotas são continuamente atualizadas para as imagens mais recentes, refletindo o ambiente de produção atual
  • Ambas as frotas escalam automaticamente conforme a demanda
  • Equipes que criam imagens em suas próprias contas AWS podem configurar frotas de workers dedicadas e enviar tarefas do Ship Quick para essas frotas, mantendo o isolamento

Expansão para workloads de longa duração

• O Shipyard atualmente funciona bem para serviços de curta duração e continua fazendo onboarding de equipes da plataforma EC2 legada
• O próximo desafio são instâncias de longa duração que não podem ser rotacionadas rapidamente
  • Nós de dados da Slack
  • Serviços singleton como GitHub Enterprise
  • Instâncias de tecnologia empresarial de terceiros, como Atlassian JIRA
• Esses workloads precisam de métodos seguros de patch e atualização e de políticas de ciclo de vida que o The Reaper consiga tratar corretamente
• Em colaboração com as equipes de serviço, está sendo desenvolvido um executor para workloads de longa duração no Gondola; à medida que a adoção crescer, a equipe planeja continuar melhorando ferramentas, workflows de desenvolvedor e a experiência de deploy
• No futuro, serão abordados separadamente os componentes da API do Shipyard, pipelines de imagem, workflows de desenvolvedor e sistema de inventário, além dos problemas encontrados ao escalar a plataforma