- "Up: Portable Microservices Ready for the Cloud"
- A Uber tem 4.500 engenheiros e inúmeros sistemas automatizados implantando mais de 4.000 vezes por semana cerca de 4.500 microsserviços stateless
- Esses serviços são desenvolvidos, implantados e operados por centenas de equipes independentes espalhadas pelo mundo
- Os serviços variam em tamanho, forma e função: alguns são pequenos e usados para tarefas internas, enquanto outros são grandes e usados para cálculos em tempo real em larga escala
Histórico dos serviços stateless da Uber
- Em 2014, a Uber tinha um monólito escrito em Python que armazenava dados em um único banco de dados PostgreSQL
- À medida que cresceu, contratou mais engenheiros e migrou para uma arquitetura de microsserviços
- Com o aumento do número de serviços, a Uber criou uma ferramenta chamada µDeploy para implantar código de forma centralizada e em larga escala
- Conteinerizou todos os serviços stateless e abstraiu o gerenciamento e a alocação em hosts
- Isso permitiu que o grupo de infraestrutura gerenciasse a frota de hosts independentemente dos microsserviços das unidades de negócio
- Mas o gerenciamento e a alocação dos serviços ainda eram manuais
- A infraestrutura da Uber segue um modelo em que grupos de zonas formam uma região
- A latência entre zonas dentro de uma região é curta o suficiente para que a comunicação síncrona entre serviços na mesma região seja eficiente
- Cada zona pode ser um cluster de máquinas pertencentes à Uber ou a um provedor de nuvem pública, mas uma zona específica sempre pertence a um único provedor
- Em geral, todos os microsserviços devem conseguir chamar outros serviços sem problemas de latência, desde que estejam na mesma região
- O µDeploy não centralizava no sistema a alocação geográfica das cargas de trabalho porque os engenheiros ainda precisavam gerenciar a alocação física no nível de zona de disponibilidade (Availability Zone)
- Em outras palavras, os engenheiros de serviço ainda precisavam decidir não apenas se executariam o serviço em uma zona on-premises, mas também em qual zona específica ele seria executado
- Ao operar datacenters on-premises, a Uber enfrentou longos prazos de entrega devido à escassez de chips e a problemas na cadeia de suprimentos
- Em 13 de fevereiro de 2023, a Uber firmou parcerias com Oracle e Google para reduzir a exposição a problemas da cadeia de suprimentos e diversificar
- Com milhares de engenheiros da Uber desenvolvendo centenas de serviços diferentes para dar suporte ao negócio, essa estratégia seria impossível sem um "sistema capaz de abstrair a infraestrutura subjacente"
Preparando a migração da Uber para a nuvem
- Migrar 4.500 serviços stateless para a nuvem sem interromper o negócio exigia uma enorme coordenação e muito esforço
- Desde o início ficou claro que esse trabalho seria propenso a erros e quase impossível de administrar com esforço manual coordenado
- Para manter e gerenciar microsserviços stateless em larga escala, era necessário transformá-los para que pudessem ser gerenciados automaticamente por um sistema centralizado de implantação, sem intervenção humana
- Indo além de Stateless, rumo à Portability
- Com base no modelo de regiões e zonas, surgiu o conceito de "portabilidade"
- Portabilidade significa um serviço que pode ser executado em qualquer zona de uma região e ser movido automaticamente para novas zonas pela plataforma de infraestrutura, sem intervenção humana
- Isso inclui mover serviços entre provedores de nuvem pública, bem como para dentro e para fora de zonas on-premises
- Alguns serviços normalmente não tinham portabilidade porque dependiam da configuração da zona e de preferências por recursos específicos da zona
- Para realizar uma migração automática para a nuvem, era necessário garantir portabilidade para todos os serviços
Tornando a Uber portátil
- Ao longo de 2021 e 2022, a empresa conduziu um programa de engenharia para garantir que todos os serviços fossem portáveis
- Em muitos casos, era possível detectar violações de portabilidade apenas inspecionando o código em busca de constantes de string e uso de nomes de arquivos
- Nos casos simples, foram criadas regras de lint para destacar código aparentemente hardcoded para ser executado em um local físico específico
- Para testar se um serviço era realmente portável, era preciso de fato movê-lo entre zonas sem intervenção humana
- Foi criado um conjunto de ferramentas de teste para que os donos dos serviços pudessem iniciar a primeira movimentação do serviço
- Como isso foi baseado nas ferramentas existentes de rollout seguro e gradual de código, os responsáveis pelo serviço podiam reverter a implantação para a zona original a qualquer momento e corrigir problemas caso fossem encontrados
- Se a movimentação fosse concluída com sucesso, o serviço era então marcado para migrações automáticas futuras
- Nos anos seguintes, a Uber repetiu esse processo para todos os seus serviços e acabou concluindo totalmente a tarefa
- Após a conclusão, tornou-se possível mudar a topologia das zonas sem intervenção dos engenheiros de serviço
- Para garantir que os serviços mantivessem a portabilidade ao longo do tempo, todos eles continuam sendo migrados regularmente entre zonas a cada poucas semanas, testando continuamente essa capacidade de movimentação
- Isso permite detectar regressões com facilidade e, com o tempo, os engenheiros se acostumaram a não assumir uma alocação em zonas específicas para seus serviços
Up: plano de controle federado multicloud e multitenant
- Foram definidos os seguintes objetivos iniciais do sistema
- Oferecer um ponto único de entrada (Single Point of Entry) para que engenheiros interajam com o sistema de infraestrutura
- Gerenciar e aplicar boas práticas aos serviços implantados diretamente no sistema, oferecendo alto nível de segurança durante rollouts de código
- Automatizar a alocação de serviços entre zonas de disponibilidade; quando novas zonas estiverem disponíveis, mover implantações para elas, incluindo a coordenação centralizada dessas alocações para sustentar a alta disponibilidade da Uber
- Automatizar migrações de infraestrutura complexas para que engenheiros de serviço não precisem se envolver nelas
- Arquitetura de alto nível
- Camada de experiência (Experience Layer):
- Implementa as diferentes formas de interação dos engenheiros com o sistema
- Inclui UI, Continuous Delivery, robôs que mantêm o sistema em bom estado etc.
- Inclui o Balancer, que move continuamente workloads para clusters e zonas com menor utilização
- Inclui o Auto Scaler, que otimiza continuamente a alocação de capacidade para cada workload
- Camada de plataforma (Platform Layer):
- Implementa as abstrações usadas pela camada de experiência para interagir com os serviços
- Inclui as abstrações de serviço e ambiente de serviço que formam o modelo conceitual da operação dos serviços, além da própria API em nível de serviço
- Na camada de plataforma, as restrições de serviço são expressas como um estado desejado de alto nível que descreve as propriedades esperadas da implantação real do serviço
- Isso pode incluir restrições sobre o desempenho das máquinas a serem executadas e sobre a capacidade total de computação para serviços em cada região
- Camada de federação (Federation Layer):
- Implementa a integração com clusters de computação
- Organiza todos os clusters por capacidade e alocação física para implementar as abstrações de região e zona usadas pelas camadas superiores
- Recebe da plataforma o estado desejado de alto nível do serviço e o converte em alocações por zona e cluster; essa conversão é baseada nas restrições do estado desejado e no estado real dos clusters, incluindo capacidade disponível no momento e clusters capazes de atender às restrições auxiliares
- O resultado dessa conversão pode mudar com o tempo, e depois outras alocações em zonas e clusters podem se tornar mais desejáveis
- Toda chamada do Balancer e outras ações iniciadas na camada de experiência também podem recalcular e alterar essa alocação
- Para manter o sistema seguro e os serviços saudáveis, um componente de gerenciamento de mudanças implementa um fluxo de rollout que altera gradualmente o estado global por meio de integrações com todos os sistemas que monitoram a saúde dos serviços
- O processo de rollout inclui canarying em todo o sistema e monitoramento de sinais de saúde; se houver problemas, o sistema faz rollback rapidamente do serviço para a configuração e a alocação anteriores ao início da mudança
- Regiões
- As regiões incluem instâncias reais de cluster
- Incluem clusters Peloton e Kubernetes®
- Eles estão fora do próprio Up, mas são os destinos da alocação de capacidade real e gerenciam a implantação de contêineres em hosts físicos
Efeitos
- O trabalho no Up começou em 2018, um protótipo funcional foi entregue no início de 2019 e a plataforma foi lançada oficialmente em meados de 2020
- Desde então, mais de 4.000 serviços de todas as linhas de negócio da Uber foram migrados da plataforma de implantação anterior para o Up
- Como a maior parte dessa migração foi automatizada, a equipe pôde se concentrar nos casos de uso mais avançados e também apoiar a migração de outras equipes
- Durante esse período, a estabilidade da plataforma foi tratada como prioridade máxima, permitindo operar o negócio de forma estável enquanto milhões de usuários utilizavam os sistemas da Uber diariamente
- A migração completa de cerca de 2.000.000 de núcleos de computação para a nova plataforma levou aproximadamente dois anos e foi concluída com sucesso em 2022
- Essa migração devolveu ao negócio dezenas de milhões de dólares em capacidade adicional por meio de auto scaling e esforços de eficiência
- Também gerou grande economia financeira ao poupar dezenas de milhares de horas de engenharia antes gastas com atualizações manuais de serviços, criação e preenchimento de novas zonas e aprendizado para navegar no complexo ambiente de infraestrutura da Uber
Próximos passos
- Após concluir a migração do µDeploy para o Up, a equipe agora pode se concentrar em construir soluções aplicáveis a toda a frota de serviços de maneira centralizada e automatizada, além de uma experiência de usuário em torno dessas capacidades
- Migração para a nuvem
- A Uber está migrando uma parte significativa de sua frota para a nuvem
- Com automação em larga escala e a camada de abstração fornecida pelo Up, as equipes de serviço podem se afastar em grande parte dos detalhes de infraestrutura exigidos por essa transição
- Continuous Delivery automatizado
- O objetivo é automatizar totalmente a entrega de código até produção usando pipelines automatizados que executam várias verificações e testes antes da implantação
- Um foco específico planejado para 2023 é manter os serviços "atualizados", garantindo que todo o código em produção esteja em dia com as últimas atualizações de segurança e bibliotecas
- Segurança de implantação (Safety)
- Dados existentes mostram que uma parcela significativa dos incidentes observados está relacionada a mudanças de código e configuração
- O objetivo é automatizar aspectos manuais do ciclo de vida dos serviços, como execução de testes pré-produção ou configuração de políticas de rollout gradual, reduzindo significativamente a taxa de defeitos que realmente chegam à produção
- Plataforma
- Organizar toda a frota de serviços stateless da Uber sob uma única plataforma guarda-chuva permite modelar com mais clareza as dependências e interações entre produtos da plataforma de infraestrutura
- Isso não só permite fornecer um modelo unificado no código, como também uma experiência de usuário totalmente integrada para o restante da organização de engenharia
- O próximo grande objetivo da equipe é conseguir observar e operar toda a infraestrutura em um só lugar
Conclusão
- O esforço para construir a plataforma Up representa agora uma mudança cultural significativa, já que todos os serviços stateless passam a ser implantados gradualmente usando as mesmas boas práticas e automações
- Mudar políticas de rollout ou criar automações para um rollout de biblioteca em larga escala, tarefas que antes exigiam meses de trabalho, agora se tornaram possíveis de maneira centralizada
- A equipe espera continuar colaborando com stakeholders do Up e donos de serviços para alcançar a visão de permitir que engenheiros da Uber foquem apenas no código, sem se preocupar com infraestrutura
Ainda não há comentários.