Engenharia de Confiabilidade do Website online na Starship | por Martin Pihlak | Tecnologias de naves estelares

A execução de robôs autônomos nas ruas da cidade é um grande desafio de engenharia de instrument. Alguns desses softwares são executados no próprio robô, mas muitos deles são executados no back-end. Coisas como controle remoto, localização de caminhos, correspondência de robôs com clientes, gerenciamento da saúde da frota, mas também interações com clientes e comerciantes. Tudo isso precisa ser executado 24 horas por dia, 7 dias por semana, sem interrupções e dimensionado dinamicamente para corresponder à carga de trabalho.

O SRE da Starship é responsável por fornecer a infraestrutura de nuvem e os serviços de plataforma para executar esses serviços de back-end. Nós padronizamos em Kubernetes para nossos microsserviços e estamos executando-o em cima de AWS. MongoDbGenericName é o banco de dados important para a maioria dos serviços de back-end, mas também gostamos PostgreSQL, especialmente onde são necessárias garantias de digitação e transações fortes. Para mensagens assíncronas Kafka é a plataforma de mensagens preferida e estamos usando-a para praticamente tudo, além de enviar fluxos de vídeo de robôs. Para observabilidade, contamos com Prometeu e Grafana, Loki, Linkerd e Jaeger. O CICD é tratado por Jenkins.

Uma boa parte do pace do SRE é gasto na manutenção e melhoria da infraestrutura do Kubernetes. O Kubernetes é nossa important plataforma de implantação e sempre há algo a melhorar, seja ajustar as configurações de escalonamento automático, adicionar políticas de interrupção de pods ou otimizar o uso de instâncias spot. Às vezes é como colocar tijolos – simplesmente instalar um gráfico Helm para fornecer uma funcionalidade específica. Mas muitas vezes os “tijolos” devem ser cuidadosamente escolhidos e avaliados (o Loki é bom para gerenciamento de logs, é o Carrier Mesh uma coisa e depois qual) e, ocasionalmente, a funcionalidade não existe no mundo e precisa ser escrita do 0. Quando isso acontece, geralmente nos voltamos para Python e Golang, mas também Rust e C quando necessário.

Outra grande parte da infraestrutura pela qual o SRE é responsável são os dados e bancos de dados. A Starship começou com um único MongoDb monolítico – uma estratégia que funcionou bem até agora. No entanto, à medida que o negócio cresce, precisamos revisitar essa arquitetura e começar a pensar em suportar robôs aos milhares. O Apache Kafka faz parte da história de dimensionamento, mas também precisamos descobrir sharding, clustering regional e arquitetura de banco de dados de microsserviço. Além disso, estamos constantemente desenvolvendo ferramentas e automação para gerenciar a infraestrutura de banco de dados atual. Exemplos: adicione observabilidade MongoDb com um proxy sidecar personalizado para analisar o tráfego de banco de dados, habilite o suporte PITR para bancos de dados, automatize testes regulares de failover e recuperação, colete métricas para reestilhaçamento Kafka, habilite a retenção de dados.

Finalmente, um dos objetivos mais importantes da Engenharia de Confiabilidade do Website online é minimizar o pace de inatividade da produção da Starship. Embora o SRE seja ocasionalmente chamado para lidar com interrupções de infraestrutura, o trabalho mais impactante é feito para evitar as interrupções e garantir que possamos nos recuperar rapidamente. Esse pode ser um tópico muito amplo, desde ter uma infraestrutura sólida de K8s até práticas de engenharia e processos de negócios. Há grandes oportunidades para causar impacto!

Chegando ao trabalho, algum pace entre 9 e 10 (às vezes trabalhando remotamente). Pegue uma xícara de café, verifique as mensagens e e-mails do Slack. Revise os alertas disparados durante a noite, veja se há algo interessante lá.

Descobrir que as latências de conexão do MongoDb aumentaram durante a noite. Analisando as métricas do Prometheus com o Grafana, descubra que isso está acontecendo durante o pace em que os backups estão em execução. Por que isso de repente é um problema, executamos esses backups há muito pace? Acontece que estamos comprimindo muito agressivamente os backups para economizar nos custos de rede e armazenamento e isso está consumindo toda a CPU disponível. Parece que a carga no banco de dados aumentou um pouco para tornar isso perceptível. Isso está acontecendo em um nó em espera, não afetando a produção, mas ainda é um problema, caso o primário falhe. Adicione um merchandise do Jira para corrigir isso.

De passagem, altere o código de sondagem do MongoDb (Golang) para adicionar mais buckets de histograma para obter uma melhor compreensão da distribuição de latência. Execute um pipeline do Jenkins para colocar o novo probe em produção.

Às 10h, há uma reunião Standup, compartilhe suas atualizações com a equipe e saiba o que os outros estão fazendo – configurar o monitoramento para um servidor VPN, instrumentar um aplicativo Python com Prometheus, configurar ServiceMonitors para serviços externos, depurar problemas de conectividade MongoDb, pilotando implantações canary com Flagger.

Após a reunião, retome o trabalho planejado para o dia. Uma das coisas planejadas que planejei fazer hoje foi configurar um cluster Kafka adicional em um ambiente de teste. Estamos executando o Kafka no Kubernetes, portanto, deve ser simples pegar os arquivos YAML do cluster existentes e ajustá-los para o novo cluster. Ou, pensando bem, devemos usar o Helm em vez disso, ou talvez haja um bom operador Kafka disponível agora? Não, não vou lá – muita mágica, quero um controle mais explícito sobre meus conjuntos de estado. É YAML bruto. Uma hora e meia depois, um novo cluster está em execução. A configuração foi bastante simples; apenas os contêineres de inicialização que registram os agentes Kafka no DNS precisavam de uma alteração de configuração. A geração das credenciais para os aplicativos exigia um pequeno script bash para configurar as contas no Zookeeper. Um bit que ficou pendente foi configurar o Kafka Attach para capturar eventos de log de alterações do banco de dados – acontece que os bancos de dados de teste não estão sendo executados no modo ReplicaSet e o Debezium não pode obter o oplog dele. Backlog isso e seguir em frente.

Agora é hora de preparar um cenário para o exercício da Roda do Infortúnio. Na Starship, estamos executando isso para melhorar nossa compreensão dos sistemas e compartilhar técnicas de solução de problemas. Ele funciona quebrando alguma parte do sistema (geralmente em teste) e fazendo com que alguma pessoa desafortunada tente solucionar e mitigar o problema. Neste caso, vou configurar um teste de carga com Ei para sobrecarregar o microsserviço para cálculos de rota. Implante isso como um trabalho do Kubernetes chamado “haymaker” e esconda-o bem o suficiente para que ele não apareça imediatamente na malha de serviço do Linkerd (sim, mal 😈). Mais tarde, execute o exercício “Roda” e anote todas as lacunas que temos em manuais, métricas, alertas and many others.

Nas últimas horas do dia, bloqueie todas as interrupções e tente fazer alguma codificação. Ecu reimplementei o analisador Mongoproxy BSON como streaming assíncrono (Rust+Tokio) e quero descobrir como isso funciona com dados reais. Acontece que há um malicious program em algum lugar nas entranhas do analisador e preciso adicionar um registro profundo para descobrir isso. Encontre uma maravilhosa biblioteca de rastreamento para Tokio e deixe-se levar por ela…

Isenção de responsabilidade: os eventos descritos aqui são baseados em uma história actual. Nem tudo aconteceu no mesmo dia. Algumas reuniões e interações com colegas de trabalho foram editadas. Estamos contratando.