Imagina o seguinte cenário: você trabalha em um e-commerce com alto volume de tráfego e logo no início do ano a diretoria comercial junto ao marketing decide realizar uma mega promoção de queima de estoque de produtos que não venderam na Black Friday, com desconto agressivo e prazo curto.

Tudo no ar, campanhas rodando em redes sociais, tráfego subindo, todo mundo animado. Até que percebem que um cálculo errado de preço está sendo aplicado em parte do catálogo, afetando diretamente alguns dos produtos da promoção.

Não tem muito o que discutir, é preciso corrigir. A única saída é um novo deploy para sanar o problema.

Seu time faz a correção, o CI passa, o deploy começa. Minutos depois, o time de atendimento dispara no Slack dizendo que vários clientes não conseguiram finalizar compras nos últimos 5 minutos, exatamente o tempo que levou para o rollout da nova versão. Carrinhos abandonados, pagamentos falhando, reclamações públicas. Climão.

Você começa a investigar e percebe que diversas requisições simplesmente não foram concluídas durante o deploy. Algumas morreram no meio do caminho. Outras nunca receberam resposta.

O que aconteceu? Sua aplicação morreu no meio de transações ativas. Pedidos sendo processados foram abortados. Pagamentos ficaram em estados inconsistentes. Workers processando emails de confirmação morreram deixando eventos órfãos no Kafka.

E agora? Como evitar que isso aconteça de novo?

É aqui que entra o Graceful Shutdown, uma forma de encerrar uma aplicação de maneira controlada, garantindo que requisições em andamento sejam concluídas antes do processo morrer.

O que é Graceful Shutdown de verdade?

Graceful Shutdown é um contrato operacional entre sua aplicação e o ambiente onde ela roda. Para satisfazer esse contrato, você precisa garantir três coisas:

1. Não aceitar novas requests e workloads: Encerrar o recebimento de novas requisições HTTP; Parar de consumir mensagens de filas (Kafka, RabbitMQ, SQS); Sem derrubar conexões já estabelecidas com banco de dados ou cache;

2. Completar todo processamento: Aguardar que todas as requisições ativas sejam concluídas; Processar mensagens que já foram retiradas da fila; Se ultrapassar um tempo aceitável, responder com erro previsível, não timeout genérico.

3. Liberar recursos: Encerrar conexões com bancos de dados; Commitar offsets do Kafka; Liberar locks de arquivos; Finalizar qualquer comunicação ativa com sistemas externos.

Neste artigo, vou mostrar como implementar isso em Go, mas o conceito vale para qualquer linguagem, runtime ou plataforma de orquestração.

Como processos sabem que devem morrer?

Antes de nos aprofundarmos em Graceful Shutdown, é importante entender como processos são “avisados” de que precisam parar. Vamos voltar ao cenário do e-commerce, quando você fez o deploy, o que exatamente aconteceu do ponto de vista do processo rodando no container?

Sinais

Em sistemas Unix-like, processos são notificados através de sinais. Sinais são interrupções enviadas pelo sistema operacional (ou por outro processo) para notificar que algo relevante aconteceu e uma ação precisa ser tomada.

Quando um sinal é entregue, o fluxo normal de execução do processo é interrompido para que ele possa reagir a esse evento.

Porém, nem todo processo reage da mesma forma a um sinal, e nem todo sinal permite reação.

Existem três comportamentos possíveis:

Signal handler

Um signal handler é uma função registrada pela aplicação para lidar com um sinal específico. Quando o sinal é recebido, o processo não morre automaticamente. Em vez disso, o handler é executado, permitindo que a aplicação:

• Pare de aceitar novas requisições;

• Aguarde requisições em andamento;

• Libere recursos;

• Finalize de forma controlada.

Ação padrão (default action)

Se a aplicação não define um handler, o sistema operacional executa a ação padrão associada ao sinal e dependendo do sinal, essa ação pode ser:

• Encerrar o processo imediatamente;

• Ignorar o sinal;

• Parar (suspender) o processo.

Unblockable signals (sinais que não podem ser tratados)

Alguns sinais não podem ser interceptados ou ignorados, independentemente do que a aplicação faça. Os mais conhecidos são SIGKILL e o SIGSTOP. Quando um desses sinais é enviado, o processo morre imediatamente, sem chance de cleanup, sem handler, sem tempo de reagir.

E em ambientes conteinerizados?

No Kubernetes, o processo normalmente recebe um SIGTERM antes de qualquer coisa mais agressiva. Esse é como se fosse um último aviso educado para a aplicação.

Se a aplicação não trata SIGTERM ou demora mais do que o tempo configurado, o orquestrador envia um SIGKILL e a sua aplicação cai.

Voltando ao cenário do deploy com bug de preço

15:29:58 - Deploy iniciado
15:30:00 - Kubernetes envia SIGTERM para Pod antigo
15:30:00 - Sua aplicação IGNORA o sinal (não tem handler)
15:30:00 - Runtime do Go encerra processo imediatamente
15:30:00 - 47 requisições HTTP ativas abortadas
15:30:00 - 12 mensagens Kafka meio processadas
15:30:00 - 3 workers gerando relatórios mortos
15:30:01 - Time de atendimento começa a receber reclamações

O erro comum

Muitos times acham que “Graceful Shutdown é coisa do Kubernetes” ou do load balancer, a real é que não é.

O Graceful Shutdown começa dentro da aplicação, no momento em que ela decide o que fazer ao receber um sinal.

Lidando com sinais em Go

Quando uma aplicação Go inicia, antes mesmo da função main rodar, o runtime registra handlers para vários sinais do sistema operacional. Esses handlers existem para garantir que o processo termine de forma previsível.

Porém, para Graceful Shutdown, quase tudo é ruído. Na prática, três sinais concentram 99% dos cenários reais:

• SIGTERM: Indica que o processo deve encerrar. É o sinal enviado por orquestradores como Kubernetes durante deploys, scale down ou evictions. Ele pode e deve ser tratado pela aplicação;

• SIGINT: Normalmente enviado quando alguém pressiona Ctrl+C no terminal. O comportamento esperado é encerrar de forma limpa, assim como no SIGTERM;

• SIGHUP: Historicamente é um sinal utilizado para indicar fechamento de terminal. Hoje em dia, ele costuma ser usado para recarregar configs.

Por padrão, ao receber qualquer um desses sinais, o runtime do Go encerra o processo imediatamente. Isso significa que:

• Requisições em andamento são abortadas;

• Conexões são fechadas sem aviso;

• O sistema externo que chamou sua aplicação não vai receber a resposta.

Para mudar esse comportamento, é necessário interceptar os sinais usando o pacote os/signal.

Basicamente, signal.NotifyContext (disponível desde o Go 1.16) faz com que o runtime notifique os sinais para um contexto ao invés de executar o comportamento padrão, permitindo que você configure a melhor forma de prevenir que a aplicação termine de forma abrupta.

Timeout não é detalhe

Graceful Shutdown não acontece no seu tempo, acontece no tempo que o ambiente permite.

Quando sua aplicação recebe um sinal de encerramento, existe um relógio invisível rodando. Se ele zerar antes do seu cleanup terminar, o sistema simplesmente mata o processo.

No Kubernetes, por exemplo, o comportamento padrão é o seguinte:

• Ao iniciar um deploy, scale down ou eviction, o Pod recebe um SIGTERM;

• A partir desse momento, começa a contar o valor que é especificado no terminationGracePeriodSeconds, que por padrão são 30 segundos - doc;

• Se o processo ainda estiver vivo ao final desse período, o Kubernetes envia um SIGKILL.

E aqui não tem negociação, o SIGKILL não pode ser interceptado, tratado ou ignorado. O processo morre imediatamente, no estado em que estiver.

Isso significa que toda a sua lógica de shutdown precisa caber dentro dessa janela:

• Concluindo requisições em andamento;

• Respondendo erros controlados se necessário;

• Liberando conexões;

• Finalizar goroutines e workers.

No cenário do e-commerce, se você tem:

• Requisições HTTP de checkout que levam 5-8 segundos (validação de estoque, pagamento, nota fiscal);

• Workers processando emissão de Notas Fiscais que levam 10-15 segundos;

• Consumidor Kafka commitando offsets em batch a cada 30 segundos.

Você tem um baita de um problema. O shutdown padrão de 30s não vai dar conta.

Parando de receber requisições: HTTP Server

Vamos começar pelo básico, fazer o servidor HTTP parar de aceitar novas requisições.

O pacote net/http possui o método http.Server.Shutdown(ctx) que implementa Graceful Shutdown nativamente. Ele para de aceitar novas conexões, aguarda as requisições em andamento completarem (respeitando o contexto passado) e então fecha as conexões idle. Veja um exemplo aqui.

Se você usa Gin, ele não possui método próprio, você usa o http.Server.Shutdown diretamente, já que Gin é apenas um wrapper em cima do net/http. Exemplo aqui.

Já se você usa o Fiber (minha escolha pessoal), ele tem seu próprio método, o app.ShutdownWithContext(ctx) porque usa o fasthttp por baixo e não o net/http. Exemplo.

Comportamento comum aos três

Independte da implemente, framework, o comportamento é o mesmo:

• Param de aceitar novas conexões imediatamente;

• Aguardam requisições ativas finalizarem (com timeout do contexto);

• Fecham conexões idle;

• Porém, não garantem que requisições vão completar se o timeout do contexto expirar.

O problema do Kubernetes

Já no Kubernetes, mesmo após o Pod ser marcado para termination, o kube-proxy pode demorar alguns segundos (~5-10s) para atualizar as regras de iptables e remover o Pod dos endpoints do Service.

Durante essa janela, você ainda pode receber tráfego. O que acontece:

15:30:00 - SIGTERM enviado 
15:30:00 - app.Shutdown() chamado imediatamente 
15:30:00 - Servidor para de aceitar conexões 
15:30:01 - Cliente tenta conectar → Connection refused 
15:30:02 - Cliente tenta conectar → Connection refused 
15:30:05 - kube-proxy finalmente atualiza iptables 
15:30:05 - Agora sim, tráfego para de chegar

O resultado são clientes recebendo erros 5xx.

Uma boa solução é implementar um delay antes de chamar o Shutdown:

E agora o fluxo ficaria algo assim:

15:30:00 - SIGTERM recebido
15:30:00 - Aplicação aguarda 10s (delay intencional)
15:30:05 - kube-proxy atualiza iptables
15:30:10 - app.Shutdown() chamado
15:30:10 - Servidor para de aceitar conexões (mas não chega mais tráfego)
15:30:12 - Requisições ativas completadas
15:30:12 - Servidor encerrado 

O que você esqueceu de desligar

Você implementou http.Server.Shutdown, testou localmente, fez deploy em produção. Tudo funcionando. Até que numa terça-feira às 3 da manhã você recebe um alerta: mensagens duplicadas no Kafka, jobs incompletos no banco, relatórios corrompidos.

O que aconteceu? Seu servidor HTTP morreu corretamente com Graceful Shutdown, mas o resto da aplicação morreu no meio do caminho.

O problema real

Aplicações não são só servidores HTTP. Elas têm:

• Consumidores de fila processando eventos assíncronos;

• Workers em background gerando relatórios, enviando emails, processando uploads;

• Jobs agendados fazendo limpeza, sincronização, cálculos periódicos;

• Conexões persistentes com bancos, caches, message brokers.

Quando você faz Graceful Shutdown apenas do servidor HTTP, esses componentes continuam rodando até o SIGKILL chegar (~30s depois no Kubernetes). O resultado:

15:30:00 - SIGTERM recebido
15:30:00 - HTTP server para de aceitar requests
15:30:02 - HTTP server finaliza últimas requisições
15:30:02 - HTTP server encerrado 
15:30:02 - Kafka consumer ainda processando pedido #8472
           ↳ Validando estoque, reservando produtos...
15:30:15 - Worker ainda gerando nota fiscal do pedido #8480
           ↳ PDF 70% completo, gravando no S3...
15:30:20 - Job de sincronização com ERP ainda rodando
           ↳ Atualizando 4.823 produtos de 10.000...
15:30:30 - SIGKILL → tudo morre abruptamente
           ↳ Pedido #8472: estoque reservado mas não commitado no Kafka
           ↳ Nota fiscal #8480: PDF corrompido no S3
           ↳ Sincronização ERP: estado inconsistente

A sequência de shutdown também é importante. Você precisa respeitar as dependências entre componentes:

Fase 1

Primeiro você impede que novos processamentos ocorram no sistema:

1. HTTP Server para de aceitar requisições;

2. Kafka Consumer para de consumir novos eventos;

3. Jobs agendados devem ser cancelados.

A ideia de fazer nessa ordem é porque o servidor HTTP pode enfileirar eventos no Kafka, e o Kafka pode disparar jobs. Se você parar o Kafka antes do HTTP, requisições vão falhar ao tentar publicar os eventos.

Fase 2

Aqui a ideia é finalizar todo processamento que está em andamento:

1. Requisições HTTP ativas, por exemplo: checkout, pagamento;

2. Kafka Consumers: Finaliza processamento, commita offsets;

3. Workers: Completa geração de Notas Fiscais, envio de e-mails;

4. Jobs: Termina sincronização com ERP.

Fase 3

Por fim, você a aplicação deve liberar conexões com recursos externos:

1. Fecha conexões com o Kafka, tanto de producer quanto consumer;

2. Encerra conexão com o banco de dados;

3. Encerra conexão com o Redis, memcached ou qualquer outro sistema de cache;

4. Libera locks de arquivos.

Essa ordem importa, por que se você fechar a conexão com o banco de dados enquanto os workers ainda estão salvando Notas Fiscais, você verá um connection closed do nada. Se fechar a conexão com o Kafka antes de commitar os offsets, vai ter que reprocessar mensagens.

Exemplo:

Goroutines também precisam saber a hora de morrer

Outro ponto ignorado com frequência: goroutines não morrem sozinhas.

Quando o processo recebe um SIGTERM:

• O runtime não cancela goroutines automaticamente;

• Loops infinitos continuam rodando;

• Workers bloqueados continuam bloqueados.

Se você não tem um mecanismo claro de cancelamento (normalmente via context.Context), você está acreditando que o processo vai morrer rápido o suficiente, ou o orquestrador vai mandar SIGKILL.

Nenhuma das duas opções é uma boa estratégia.

Uma boa aqui é utilizar context-aware goroutine, exemplo. Agora caso você tem várias goroutines, use sync.WaitGroup para aguardar todas finalizarem, exemplo.

Toda goroutine de longa duração deveria responder a cancelamento. Se ela não sabe quando parar, ela é provavelmente é um leak.

Shutdown precisa ser previsível, não best effort

Muita gente implementa shutdown como algo “best effort”, tenta fechar tudo e torce para dar tempo e isso é frágil.

O shutdown precisa ter:

• Ordem clara, o que encerra antes do quê;

• Limites de tempo explícitos;

  • Lembra das fases que citei acima?

• Fallback bem definido. O que acontece se algo não for encerrado conforme esperado?

Esses tempos precisam ser mensurados e testados. Uma dica aqui é adicionar uma gordura. Voltando ao nosso cenário:

Vamos relembrar que o terminationGracePeriodSeconds por padrão no Kubernetes são 30 segundos, mas a soma das nossas fases dá ~35s. Isso é intencional, você quer que todas fases termine antes do SIGKILL.

Você pode muito bem configurar o lifecycle do seu Deployment/Pod através do parâmetro terminationGracePeriodSeconds e utilizar o preStop hook.

Observe o shutdown como um evento crítico

Outro erro recorrente, o shutdown não é observado.

Em produção, você deveria conseguir responder:

• Quanto tempo o shutdown levou?

• Q que demorou mais?

• Quantas requisições foram abortadas?

• Houve timeout?

Sem logs claros e métricas, o shutdown vira um buraco negro. Quando algo dá errado, ninguém sabe o real motivo.

Talvez esse seja o grande ponto de reflexão do meu post, Graceful Shutdown é um evento operacional importante, não um detalhe de implementação.

Dicas para mensurar

• Através métricas para mensurar o tempo de duração do shutdown;;

• Através de logs contendo duração, quantas requests estavam ativas, quantos jobs estavam pendentes;

• Crie uma dashboard para monitorar esses tempos, com duração do shutdown, quantos shutdowns foram bem sucedidos, a duração por fase e quantas requests foram abortadas;

• Alerte apenas em casos críticos. Quando o shutdown está próximo dos 30s ou do valor que você definir do terminationGracePeriodSeconds.

Não teste só quando dá problema

Shutdown precisa ser testado:

• Localmente durante desenvolvimento;

• Em staging antes de subir pra produção;

• Sob carga com tráfego real;

• Com latência que possa simular dependências lentas;

• Com dependências como banco de dados e Kafka falhando.

Quanto antes você falhar, mais barato é corrigir.

Conclusão

Graceful Shutdown não é uma feature opcional nem um detalhe de infraestrutura.
Ele é parte do contrato da aplicação com o ambiente onde ela roda.

Se você ignora:

• Sinais do sistema operacional;

• Limites de tempo impostos pelo orquestrador;

• Requisições em andamento;

• Goroutines e workers;

O sistema vai continuar funcionando, até o dia em que o deploy custar dinheiro, reputação ou ambos.

Próximos passos

Se você ainda não tem Graceful Shutdown:

1. Comece pelo básico interceptando SIGTERM e SIGINT;

2. Implemente shutdown do servidor HTTP;

3. Identifique todos os componentes concorrentes (Kafka, workers, jobs);

4. Implemente shutdown coordenado respeitando dependências;

5. Adicione logs e métricas;

6. Teste localmente com Ctrl+C;

7. Teste em staging sob carga;

8. Faça rollout gradual em produção;

9. Monitore e ajuste timeouts baseado em dados reais.

Se você já tem Graceful Shutdown:

1. Revise a ordem, ela respeita dependências?;

2. Meça os timeouts;

3. Adicione observabilidade;

4. Teste sob condições adversas;

5. Configure alertas;

6. Documente.

Fiquem a vontade para comentar suas soluções, como vocês implementam ou se possuem dúvidas sobre o tema.

Até mais!

Compartilhar

Esse post é baseado em um dos melhores artigos que li esse ano e que tenho tentado seguir. Sim, é um exercício constante e para mudar esse comportamento leva tempo. Afinal, somos humanos e reclamar é inerente.

No texto do Marc Brooker, ele toca em um ponto que a maioria das pessoas prefere ignorar (ou que não se atentaram ainda), que são as pessoas e grupos que você escolhe ouvir, dar atenção e participar moldam de forma silenciosa a sua ambição, a sua energia e a sua capacidade de evolução.

E uma grande verdade é que se você passa tempo demais em ambientes e/ou grupos onde o normal é reclamar, você vira parte do problema, mesmo achando que está só desabafando.

Evitando o ruído negativo

“If I could offer you a single piece of career advice, it’s this: avoid negativity echo chambers.”

Grupos onde a reclamação reina vão drenar sua capacidade de pensar com clareza e será criada uma distorção onde todo desafio parece muito complicado, toda empresa é tóxica e todo líder é incompetente.

Você pode não perceber, mas a sua ambição é enfraquecida por osmose.

E a verdade é simples, pessoas que vivem reclamando não progridem e também não querem que você progrida.

E é aí que o pessimismo em grupo vira identidade.

“Sometimes, it becomes a cultural norm… pessimistic people end up dominating.”

Essa é a real, quando a negatividade vira a linguagem comum, quem tenta construir algo novo se torna o ingênuo que não conhece o ambiente que trabalha.

E na minha opinião, esse tipo de grupo/comunidade é bem confortável para quem desistiu silenciosamente da própria evolução. Se você está cercado disso, você com certeza já sabe. E sabe também que, quanto mais tempo passa, mais difícil se desligar dessas comunidades.

Outra grande verdade é que reclamar com pares também não adianta e essa é uma das frases mais verdadeiras do texto:

“DMing away about how much things suck doesn’t make change.”

Sair mandando mensagem privada para seus pares pode criar a sensação de ação, mas a real é que não. Ainda mais se é um problema cultural e/ou estrutural da empresa. No fim, é autoengano com um custo emocional alto.

Quando você passa um tempo demais alimentando essas conversas de bastidores, está tentando dizer para si mesmo que está tentando melhorar… mas, na prática, só está mantendo o status quo. É um vício que parece inofensivo, mas destrói clareza e motivação.

Vale ressaltar que o oposto também é prejudicial:

“Positive echo chambers can be bad too.”

Sim, entusiasmo e positivismo cego é tão tóxico quanto o pessimismo crônico. O ponto central não é ser positivo e good vibes o tempo todo. É ter clareza da situação.

Todo esse otimismo sem ação gera ilusão e a negatividade sem ação gera corrosão e entre esses dois extremos está o único caminho que importa, a realidade com movimento.

E como sair desse ciclo?

O Marc propõe algo bem direto:

“If more than 20% of the content is negative, I move on.”

Marc também define um limite objetivo para se livrar desses ambientes e você não precisa se explicar, não precisa convencer ninguém, é só sair. Se você está consumindo e interagindo de forma negativa mais de 20% do seu tempo ou mais de 20% das conversas são só reclamações, você já sabe o que isso está fazendo com seu cérebro e com seu ânimo.

Meu conselho aqui é fazer uma reflexão do que você consome em mídias sociais (principalmente LinkedIn) e em grupos/comunidades que você participa hoje e se você achar que é tóxico, saia. Novamente, você não precisa se explicar, nem convencer ninguém.

Outra saída é onde você vai e deve colocar sua energia:

“Spend your energy at work doing great work and improving. Or, do the minimum and disconnect.”

Em uma tradução livre “Gaste sua energia no trabalho fazendo um trabalho bacana e sempre melhorando, ou faça o mínimo e desconecte” e ponto final.

Esse clima morno onde você nem cresce, nem descansa e nem se preserva não leva a nada, só estagnação.

Se quer evoluir, aprenda, construa, se exponha ao que te desafia. Se aproxime de pessoas que constroem, que tentam, que erram, que corrigem e que seguem nesse ritmo. Isso vale para pessoas no seu trabalho ou de comunidades.

O que não dá é tentar justificar essa estagnação com discursos sobre “como o mercado é cruel” ou “como ninguém sabe o que faz”. Infelizmente, esse discurso só te faz continuar na mesma.

Pontos finais

Como disse inicialmente, é difícil quebrar esse ciclo e a maioria das pessoas subestima o impacto das comunidades que fazem parte e o conteúdo que consomem.

Você pode ser super competente, ser ótimo tecnicamente, mas se a sua referência diária são grupos onde as pessoas são frustradas e beiram o cinismo, não existem atalhos, mentoria e nem ajuda profissional que ajude.

Meu conselho é, se quiser evoluir, remova todo o ruído negativo, saia de grupos, faça uma boa limpa em suas redes sociais, não dê bola para aquele colega de trabalho que só sabe ver o lado negativo das coisas e comece a se aproximar de quem está construindo e evoluindo.

Um dos pontos mais importantes ao arquitetar sistemas escaláveis é disponibilidade. Existem serviços que um certo tempo de downtime é entendível e até esperado e alguns não podem ficar fora do ar de forma alguma.

Acredito que existem perguntas essenciais que não só times de engenharia, mas também times de negócio e produto devem se fazer ao determinar o quão importante é a disponibilidade de sistemas para a empresa e para seus clientes. Como por exemplo:

1. Por que comprar seu produto? Por que alguém compraria seu produto ou seu serviço se ele não está operacional ou acessível quando eles precisam?

2. O que os clientes pensariam nesse cenário? O que eles pensariam ou sentiriam sobre a marca/empresa quando eles precisam usar seu serviço e ele está fora do ar?

3. Qual é o nível de satisfação dos seus clientes? Como você pode fazer os clientes felizes, trazer dinheiro para a empresa e atender as promessas do seu negócio se os serviços estão fora?

E a real é que a respostas para essas perguntas levam a um único ponto. Seu sistema precisa estar operacional. Existe uma relação direta entre nível de satisfação de seus clientes com a disponibilidade de seus serviços.

Disponibilidade e Resiliência

Disponibilidade e resiliência são dois conceitos muito similares, porém diferentes e é importante entender essa diferença. Ainda mais se você trabalha com SRE ou arquitetando e desenvolvendo aplicações.

Disponibilidade se refere a habilidade de um sistema em realizar suas operações. Se o sistema está de pé, está operacional e está respondendo então sim, ele está disponível.

Já resiliência se refere a qualidade do sistema, se o sistema consegue de forma consistente realizar suas operações.

Novamente, ambos conceitos são super parecidos. É difícil um sistema ser disponível se ele não é resiliente e o contrário também é uma verdade.

Se um sistema que recebe dois parâmetros e os soma, por exemplo “4” e “2” e retorna “8”, ele tem uma baixa resiliência. Nesse cenário, a resiliência pode ser corrigida ao implementar testes. Já a disponibilidade é mais difícil de se resolver. Vamos a mais um cenário, imagine que o sistema ao receber os mesmos parâmetros retorne “6”, ele é resiliente. Mas devido a um problema de rede, as vezes ele retorna 6, as vezes não retorna nada. A aplicação é resiliente, mas não é sempre disponível.

Causas de Disponibilidade Degradada

• Exaustão de recursos: Quando a quantidade de usuários ou a quantidade de dados trafegados ou armazenados aumenta resultando em requisições lentas;

• Mudanças inesperadas na carga que o sistema suporta: Geralmente requer mudanças de última hora e sem planejamento, tanto na infraestrutura quanto no código e podem aumentar a probabilidade de mais problemas;

• Dependências externas: Quanto mais seu sistema depender de recursos externos, como SaaS, mais o seu sistema estará exposto a problemas de disponibilidade causado por esses recursos;

• Dívida técnica: Quanto mais as aplicações se tornam complexas, geralmente, a dívida técnica cresce junto e dívida técnica é sinônimo de problema em algum momento.

O ponto aqui é que problemas de disponibilidade custam dinheiro para você, para seus clientes e afeta diretamente a confiança dos clientes no negócio e produto. Provavelmente a empresa não vai pra frente se você tem problemas constantes de disponibilidade e contruir aplicações que precisam escalar é construir aplicações que tenham alta disponibilidade.

Medindo Disponibilidade

Medir a disponibilidade é importante para manter seu sistema sempre operacional. Ao mensurá-la você pode entender como sua aplicação está performando agora e compará-la daqui 1 semana, 1 mês ou sempre que uma nova funcionalidade nova for para produção.

O mecanismo mais utilizado para medir a disponibilidade é calcular a porcentagem de quanto aquele sistema está disponível para os clientes, onde pode ser utilizada a seguinte fórmula:

Exemplo, durante o mês de Janeiro, seu sistema ficou fora do ar 3 vezes, a primeira 40 minutos, a segunda 20 minutos e a terceira 5 minutos. Qual seria a disponibilidade desse sistema?

Segundos fora do ar: (40*60)+(20*60)+(5*60) ​= 3.900s
Segundos em um mês: 31 dias x 86.400s/dia​ = 2.678.400s

Agora aplicando a fórmula:

A disponibilidade seria ~99.8%. O que nos leva ao próximo tópico e uma pergunta que ouvimos bastante, “a disponibilidade da sua aplicação está em quantos noves?”

Os Noves

Estamos acostumados a relacionar “os noves” como indicadores de alta disponibilidade. A tabela abaixo dá uma visão geral do que isso significa.

Um sistema que tem 2 noves de disponibilidade, precisa estar disponível 99% do tempo, ou seja, o sistema pode ficar fora 432 minutos por mês. Já uma aplicação que garante 5 noves de disponibilidade pode ter apenas 4 minutos de downtime por mês.

No exemplo que mostrei anteriormente, a aplicação falhou em atender a disponibilidade de 3 noves (99.8% comparado a 99.9%). Mas qual é o valor razoável para seu sistema ser considerado como altamente disponível? E a resposta para isso é, depende. Você vai precisar determinar isso com negócio/produto da sua empresa e nesse momento você precisa saber ouvir e saber vender qual seria o trabalho (e custo) necessário pra chegar no nível desejado. O ideal é chegar ao meio termo. Geralmente para aplicações web 3 noves é considerado como aceitável.

Vale lembrar que manutenções programadas também são consideradas como downtime. Vamos aplicar a mesma fórmula anterior em um cenário onde o time realiza manutenções preventivas toda semana e o sistema fica fora por 3 horas.

Horas em uma semana: 7 x 24 horas = 168 horas
Horas indisponíveis por semana: 3 horas

Nesse cenário, o sistema teria disponibilidade aproximada de 98.21%, ou seja, não atinge nem 99% de disponibilidade. Isso sem contar se houver algum downtime durante o período, então por esse motivo, cuidado com manutenções planejadas.

Melhorando a Disponibilidade

Vamos para mais um cenário. Seu serviço recém lançado está operacional, está online, o time opera normalmente e tudo parece bem. O tráfego aumenta gradativamente, seu serviço é rentável e está tudo bem. Até que o sistema tem um downtime inesperado, mas tudo bem, a disponibilidade continua boa.

Até que acontece novamente e ninguém liga, pois os números continuam bons. E acontece novamente. O time de negócio começa a se preocupar, começam a pipocar tickets e reclamações para o time de atendimento e novamente, outro incidente.

Manter seu sistema disponível é uma tarefa difícil, o que você faria se isso começasse a acontecer e você precisa trabalhar para manter os clientes satisfeitos e o dinheiro entrando novamente?

Identificar cenários como esse são essenciais para evitar um ciclo vicioso de problemas e você pode ter algumas iniciativas para contornar isso:

• Medir e acompanhar a disponibilidade geral;

• Automatizar processos manuais;

• Automatizar processos de deploy;

• Manter todas as configurações dos sistemas de forma centralizada;

• Continuar trabalhando em melhorar seus sistemas. Isso não significa migrar para o Kubernetes, e sim identificar problemas de arquitetura, código ou infraestrutura.

Vamos nos aprofundar em cada uma delas:

Medir e acompanhar a disponibilidade geral

Para entender o que está acontecendo com a disponibilidade do sistema, você precisa medi-la primeiro e saber qual é o valor atual. Expliquei isso mais acima. Utilize a fórmula e alguma ferramenta para acomapanhar se a disponibilidade está melhorando ou piorando.

Monitore de forma contínua essa porcentagem e também quando houve alterações significativas ou não no sistema. Dessa forma você pode correlacionar eventos com incidentes.

Automatizar processos manuais

Elimine variáveis e processos desconhecidos. Realizar operações manuais é um modo comum de inserir resultados variáveis ou desconhecidos no sistema.

A dica de ouro é nunca realize operações manuais em produção.

Quando você realiza uma mudança, essa mudança pode melhorar ou comprometer de vez seu sistema. Ao usar apenas tarefas automatizadas e que podem ser repetidas traz benefícios como:

• Você pode testar um processo ou script antes de executá-lo;

• Realizar ajustes nesse script para executar exatamente o que você precisa;

• O script pode ser revisado por um colega, com isso diminui a probabilidade de algo estar passando despercebido;

• Você pode versionar scripts afim de entender quando o script foi alterado e por quem;

• Possibilidade de rodar o mesmo script em vários servidores ao mesmo tempo;

• Ao automatizar você cria tarefas repetitíveis e toda tarefa repetitível podem ser auditada e analisada. Ou seja, você terá como saber qual foi o impacto. Se positivo ou negativo.

Existem empresas onde ninguém tem acesso ao ambiente de produção. Toda e qualquer mudança só deve ser feita através de processos automatizados.

Deploys automatizados

Essa pode parecer mais do mesmo, mas muitas empresas ainda não tem um processo de deploy automatizado, onde a pipeline (testes, processos de segurança, build) é igual para toda e qualquer nova release.

Os processos de rollbacks também são mais confiáveis quando automatizados.

Gestão de configuração

Assim como o ponto de cima, pode parecer super comum, mas não é.

Utilizar sistemas de gestão de configuração como Ansible ao invés de sair mudando manualmente aquela variável no Kernel de um servidor é um passo bem importante. Se o Ansible é muito para seu cenário, escreva um script que faça as alterações e versione.

Para infraestrutura, utilize soluções de Infra as Code como Terraform ou Pulumi. Falo mais sobre isso aqui.

Melhorando sistemas

Agora que você tem um sistema onde é possível monitorar a disponibilidade, uma maneira de rastrear riscos e uma maneira de aplicar alterações consistentes ao seu sistema de forma fácil e segura, você pode concentrar seus esforços em melhorar a disponibilidade dele. Vou dar alguns exemplos que podem te direcionar.

Construa pensando em falhas

Planeje e desenhe as aplicações pensando que em algum momento elas vão falhar. Ou por um problema de rede, ou por um serviço terceiro fora do ar, ou por DNS :). Isso é fato, em algum momento haverão falhas, ponto. Portanto:

• Quais design patterns você considerou ou utiliza que irá melhorar a disponibilidade da aplicação? Ao usar patterns simples como lógica de retry e circuit breakers você consegue identificar problemas mesmo que eles afetem apenas uma pequena funcionalidade. Isso ajuda a limitar o escopo de um problema e permite que a aplicação continue operacional em partes;

• O que você faz quando um componente que a aplicação depende começa a falhar? Como você faz a retentativa da requisição? Circuit breakers são ótimos para esses casos, pois eles reduzem o impacto de falhas em dependências. Sem um circuit breaker, você diminui a performance da aplicação, principalmente quando timeouts longos são necessários para detectar uma falha;

• O que você faz quando acontece um tráfego inesperado para seu sistema? O sistema cai? Você consegue limitar a quantidade de requisições?

Sempre se pergunte “isso escala?”

Não é porque sua aplicação funciona hoje que ela vai funcionar amanhã, ainda mais aplicações web, onde o tráfego de hoje pode ser totalmente diferente daqui uma semana, as vezes em até menos tempo. Construa pensando sempre no futuro:

• Arquitete pensando em como escalar seus bancos de dados;

• Pense nos limites lógicos ao escalar a camada de dados. O que acontece se seu banco de dados alcançar algumas de suas capacidades e limites?

• Construa sua aplicação de forma que seja fácil adicionar novos servidores em caso. Como você mantém o estado da aplicação? Como o tráfego externo chega nos servidores? Existe um load balancer?

• Utilize CDNs para conteúdos estáticos para minimizar o tráfego para sua rede e servidores;

• Pense em quais conteúdos dinâmicos podem ser gerados de forma estática.

Mitigue riscos

Identifique possíveis riscos que seu sistema pode ter. Geralmente as causas das falhas poderiam ter sido identificadas antes delas terem ocorrido. Alguns exemplos:

• Um servidor vai cair;

• Os dados no banco de dados podem se corromper;

• A resposta de uma requisição pode retornar errada;

• Uma conexão de rede vai falhar;

Manter sistemas disponíveis envolve remover ou reduzir os riscos, mas com o aumento da complexidade isso se torna cada vez mais difícil. Manter um sistema grande disponível é muito mais sobre gerenciar seus riscos, o quanto é aceitável e o que você pode fazer para mitigá-los.

Observabilidade

Você não saberá que há um problema a menos que você o veja. Instrumente seu sistema de ponta a ponta para ter uma visão do todo. Também falei sobre isso aqui. Existem soluções Open Source que podem ser adotadas de forma fácil para essa finalidade.

O segredo é não criar um caminhão de alertas, setar SLIs e monitorar SLOs. Observe tendências na performance e os outliers (valores fora do normal) poderão ser tratados como problemas de disponibilidade, podendo dessa forma gerar alertas em ocorrências.

Resposta a incidentes

Ter um sistema observável é inútil se você não tem uma forma de atuar quando os incidentes acontecem. Estabeleça processos e procedimentos, os famosos Runbooks, que os times possam seguir para identificar problemas e corrigi-los de forma fácil.

Por exemplo, se um serviço é afetado, você deve ter uma série de passos para restaurá-lo a normalidade. Não importa se seja um restart de um daemon, de um conteiner, verificação de espaço em um banco de dados ou consumer lag de um tópico do Kafka. O importante é ter o passo a passo documentado para ajudar as pessoas a identificar o problema.

Quando um alerta é enviado, os donos dos serviços devem ser os primeiros a receber a notificação, porém, outros times que consomem ou tem algum tipo de “conexão” com o serviço afetado também podem ser notificados. Isso vai depender de cada empresa e cultura.

Outro ponto importante é documentar o escopo de atuação de cada time, ou seja, quem são os donos de determinados serviços, vamos considerar squads de um e-commerce:

Nesse caso, a squad de Checkout é “dependente” de serviços da squad de Catálogo onde por exemplo, o carrinho não exibe o valor correto de um produto se o serviço de gestão de produtos que determina o valor está incosistente. Assim como ela também depende do serviço de cálculo de frete, do time de Logística. Criar SLOs para observar o error budget de fluxos importantes é essencial nesse cenário.

Todos esses processos e procedimentos devem ser preparados com antecedência para que, durante um incidente, os times saibam o que fazer nas diversas circunstâncias para restaurar as operações rapidamente.

Finalizando

Esse foi o primeiro post de uma série sobre boas práticas de como manter a disponibilidade com resiliência em aplicações. Nos próximos, a ideia é aprofundar mais em como lidar com falhas de forma inteligente, graceful shutdown e tudo que está em torno disso.

Em quase 20 anos da minha trajetória profissional aprendi bastante depois de participar de vários projetos, tanto aqueles de infra mais raíz, quanto migrações para cloud, Kubernetes e por aí vai. Em algumas vezes tomei decisões erradas, mas o importante disso é o aprendizado. E nada mais justo do que repassar esse conhecimento a diante.

Por isso, eu vejo muitas pessoas (desde os que estão começando agora até os mais experientes) tomando decisões ou querendo surfar a onda do hype, ou como costumávamos dizer na Leroy Merlin, sendo “bleeding-edge”.

Esse post é para quem está trabalhando em projetos greenfield, stealths ou começando do zero.

1 - Escolha tecnologias maduras (boring tech)

Sim, escolha tecnologias maduras ao iniciar novos projetos. Aquele novo orquestrador de conteiner, aquele novo serviço da AWS ou aquele framework novo que promete ser 20% mais rápido que o framework que você utiliza não vale todo o overhead operacional.

Sim, é legal usar e testar novas tecnologias, eu gosto e todo mundo gosta, mas cuidado ao usar em projetos novos. As vezes o tempo gasto dando manutenção em algo que “ninguém usa”, seria muito mais útil se aproveitado trabalhando em melhorias reais de performance.

2 - Infra as Code desde o início

Simples como o título. Provisionar infra não é mais o famoso “next, next, finish” na console da AWS (ou qualquer outra cloud). Sem saber o que e como foi feito só vai gerar mais dívida técnica e impossibilitar de recriar o ambiente em caso de necessidade.

Sem contar as inúmeras vantagens que IaC traz, como rastreabilidade, consistência e redução de erros, já que o código pode ser revisado e testado.

3 - Segurança planejada, não acidental

Adicionar segurança depois que o projeto já está rodando, ou depois de um incidente é muito (mas muito) mais difícil do que construir desde o dia zero. Começar com o menor privilégio possível em roles, keys e etc já é um baita começo. Use IRSA ou Pod Identity na AWS.

Se seu escopo for além da cloud, Dependabot (ou Renovatebot) e Trivy salvam muito.

4 - Automatize tudo

É o mesmo ponto de Infra as Code. Não se trata de velocidade e sim de consistência. Processos manuais criam silos de conhecimento e pontos únicos de falha.

O mínimo aceitável é ter um fluxo de deploy automatizado tanto para infraestrutura quanto para o código.

5 - Documente decisões

Não adianta só documentar seu código, documente suas decisões e os motivos de escolher determinadas arquiteturas.

Um bom início é escrever ADRs (Architectural Decision Records). Não precisa ser nada rebuscado, um markdown em um repositório no GitHub já ajuda. Com certeza, vai ajudar as próximas pessoas do seu time a entender o por que as coisas são do jeito que são.

6 - Se questione o “por que”

Esse vai de encontro com o ponto acima.

A arquitetura das aplicações (ou infraestrutura) devem servir ao negócio, não ao contrário. Tecnologia não é o objetivo, é o meio. Mantenha as coisas simples, com propósitos e alinhado ao negócio.

Provavelmente você não precisa de microserviços para um MVP.

7 - Planeje para falhas

Uma hora seu serviço, sua infra, seu DNS vai falhar. Toda rede tem problemas. Desenhe sua arquitetura esperando que isso vai acontecer em algum momento.

Aprendi com um antigo gestor durante uma migração de servidores Microsoft Exchange 2003 para 2010 (ainda existe isso?), o seguinte pensamento:

Quem tem um, não tem nenhum.
Quem tem dois, tem um.
Quem tem três, tem dois.

E é sobre isso. Tenha no mínimo duas réplicas do que é core para o negócio.

8 - Observabilidade

O papo de observabilidade não é monitoração já tá batido. Identifique seus SLIs e defina SLOs para acompanhá-los. Novamente, tecnologia a favor do negócio e não ao contrário.

Comece instrumentando seu código e pontos chaves da infraestrutura. A stack LGTM é um ótimo ponto de partida.

O eBPF (Extended Berkeley Packet Filter) surgiu como uma tecnologia revolucionária para observabilidade e otimização de desempenho em sistemas modernos, permitindo a execução segura de código diretamente no kernel do Linux, oferecendo uma abordagem “sandboxed” para interagir com aplicações, redes e subsistemas do hardware.

A ideia desse post é abordar alguns princípios e fundamentos mais básicos, já que o eBPF continua em constante evolução e é aplicado em cada vez mais cenários.

O que é eBPF?

O eBPF foi inicialmente desenvolvido para Linux, porém não há motivos para que ele não possa ser utilizado em outros Sistemas Operacionais. Inclusive, a Microsoft tem desenvolvido uma implementação dele para Windows.

A ideia do eBPF nasceu no início dos anos 90 como uma “pseudo máquina” que podia rodar programas como se fossem filtros, onde era determinado se um pacote de rede poderia ser aceito ou rejeitado. Esses programas eram escritos em instruções chamadas BPF (BSD Packet Filter) bem similares ao Assembly. Caso você queira se aprofundar nas raízes do eBPF, sugiro dar uma lida no paper escrito no fim de 1992 por Steven McCanne e Van Jacobson. Abaixo, um exemplo de código retirado direto desse paper:

Esse código basicamente filtra pacotes que não são pacotes IP da seguinte maneira:

1. O código trabalha com pacotes Ethernet como entrada;

2. Utilizando uma instrução ldh, ele carrega um valor de 2 bytes a partir do byte 12 do pacote (este é o campo EtherType nos quadros Ethernet que identifica o protocolo);

3. Uma instrução jeq então compara este valor com o código padrão para pacotes IP;

4. Se houver uma correspondência, a execução salta para um “rótulo” (ou função) chamado L1 e retorna um valor não zero (#TRUE), aceitando o pacote;

5. Se não houver correspondência, o pacote é rejeitado retornando 0.

No paper existem trechos de código bem mais complexos, porém o mais importante disso tudo é ficar claro, que a pessoa podia escrever essas instruções e serem executadas diretamente dentro do Kernel, o que possibilita a utilização do eBPF hoje em dia. A primeira utilização do BPF no Linux foi a partir da versão 2.1, no utilitário tcpdump para capturar pacotes TCP.

O BPF se tornou o que conhecemos hoje por eBPF na versão 3.18 do kernel do Linux trazendo mudanças significativas como:

• Um melhor suporte a arquitetura 64-bit;

• Possibilidade de criar estruturas de dados através de maps;

• A syscall bpf() foi adicionada para que programas rodando a nível de usuário pudessem interagir com programas eBPF rodando no kernel.

eBPF e o Kernel do Linux

Desde 2005 existe uma funcionalidade no kernel do Linux chamada kprobes (kernel probes), que permite que você injete “traps” em quase todas instruções de código do kernel de uma forma que novos módulos (kernel modules) possam “attachar” suas funções a esses kprobes com intuito de medir performance ou debugar aplicações.

Porém, só em 2015 foi adicionada a funcionalidade de “attachar” programas eBPF aos kprobes e foi a partir de então que a forma como todo tracing dentro de um sistema Linux começou a mudar, permitindo uma melhor visualização e entendimento de toda stack de rede daquele sistema. Nos anos seguintes, a adoção do eBPF se tornou proeminente em empresas como Netflix e Facebook possibilitando o nascimento do projeto Cilium.

Em meados de 2018, a comunidade viu o eBPF se tornar um subsistema totalmente separado dentro do kernel do Linux, a introdução do BTF, tornando programas eBPF mais portáteis e o LSM BPF, que tornou programas eBPF a serem utilizados juntos de uma interface do kernel chamada Linux Security Module (LSM), possibilitando que o eBPF fosse a melhor tecnologia para segurança, observabilidade e redes.

Kernel e o User space

Para realmente entender o eBPF, é necessário saber a diferença entre o kernel e o user space no Linux, então vamos lá.

De modo bem simples e direto, o kernel do Linux é um software que atua entre as aplicações e o hardware do sistema onde ele roda. Já as aplicações rodam em uma camada “superior” chamada user space, o que não dá acesso direto ao hardware, para isso, a aplicação que necessita ler e escrever arquivos, trafegar dados pela rede ou acessar a memória RAM, precisa fazer requests utilizando syscalls para que o kernel atue pela aplicação nesses momentos. O kernel também é responsável por coordenar processos concorrentes, permitindo que várias aplicações rodem ao mesmo tempo.

É bem difícil no dia dia utilizarmos uma interface de syscall de forma direta, pois as linguagens de programação já oferecem abstrações e bibliotecas que são muito mais fáceis de se utilizar. Por isso, muitas pessoas não fazem ideia do que o kernel está fazendo enquanto aplicações estão rodando. Para ter uma noção, veja o output de um strace durante a execução de um simples docker run.

Com isso, dá pra perceber o quanto as aplicações “dependem” do kernel e com eBPF é possível adicionar instrumentações nele para entender e ter todos esses insights. Por exemplo, se você interceptar syscalls em operações de arquivos, você saberá exatamente quais arquivos foram manipulados.

Programas eBPF podem ser carregados (e descarregados) de forma dinâmica do kernel e uma vez que eles são “attachados” a um evento, esse programa sempre será acionado por esse evento independente do que o causou. Por exemplo, se você “attachar” um programa a uma syscall ao abrir arquivos, esse programa será acionado sempre que qualquer programa tentar abrir um arquivo.

Isso significa que utilizar ferramentas de segurança e observabilidade que utilizam eBPF são um grande diferencial de ferramentas comuns, pois você terá visibilidade de tudo que está acontecendo no sistema. Sem contar que também é possível filtrar eventos a nível do kernel sem enviá-los ao user space, “economizando” custo de processamento. Em ambientes rodando conteineres, a visibilidade chega até os processos dentro desses conteineres, o que nos leva ao próximo tópico.

eBPF em ambientes Cloud Native

Com a adoção de soluções cloud native como Kubernetes, são utilizadas abordagens que decidem em qual servidor um determinado workload irá rodar. Obviamente, esses servidores rodam um Sistema Operaciona que possui um kernel. E aplicações em conteineres compartilham o mesmo kernel do servidor onde estão rodando, ou seja, em um cluster Kubernetes, todos os conteineres em todos os Pods em um determinado node estão utilizando o mesmo kernel. Quando esse kernel é instrumentado através de programas eBPF, todos workloads estarão visíveis para esses programas.

E ter essa visibilidade trás benefícios como:

• Não é necessário mudar ou implementar bibliotecas para instrumentá-las com eBPF;

• Assim que o kernel carrega um novo programa eBPF, esse programa pode observar processos de aplicações que já estão rodando.

O que comparado com soluções que utilizam sidecars, é um super diferencial, pois:

• Ao usar sidecars, os Pods precisam ser reiniciados para que esse novo conteiner seja adicionado;

• O tempo de inicialização do Pod é afetado;

• Gerenciar vários conteineres em um Pod só trás mais complexidade;

Como ferramentas baseadas em eBPF podem ter uma visibilidade completa, pode ser mais difícil para que invasores não sejam notados. Por exemplo, imagine que um invasor consiga explorar uma vulnerabilidade em um serviço exposto e faça upload de um binário malicioso para realizar uma coleta de dados. Se sua estratégia de observabilidade ou segurança depende de agentes instalados dentro do conteiner ou de sidecars, é bem provável que esse processo passe completamente despercebido. Já com uma abordagem baseada em eBPF, é possível observar syscalls, conexões de rede e acesso a arquivos diretamente do kernel, independentemente de como o processo foi iniciado. Isso significa que esse tipo de atividade pode ser detectada sem depender de modificações no ambiente da aplicação.

Aplicações de eBPF

Como ficou claro até aqui, o eBPF permite customizar o comportamento do kernel e observar eventos em todo o sistema e reportá-los ao user space. A partir de agora vamos entrar de forma mais profunda em como o eBPF pode ser aplicado em soluções de segurança e rede.

eBPF para segurança

Como mencionei um pouco acima, syscalls são interfaces entre aplicações rodando no user space e o kernel. É possível restringir ou limitar quais syscalls uma aplicação pode fazer, e se você utiliza Docker há um bom tempo, você já deve ter esbarrado em uma ferramenta que utiliza BPF para isso, a seccomp.

O seccomp (SECure COMPuting) surgiu com o objetivo de isolar aplicações não confiáveis, limitando quais syscalls estão disponíveis para um determinado processo. Em seu modo strict, apenas syscalls como read(), write(), _exit() e sigreturn() são permitidos, o suficiente para aplicações extremamente limitadas. Para oferecer maior flexibilidade, foi criado o seccomp-bpf, que usa filtros baseados em BPF para permitir ou bloquear syscalls dinamicamente com base em algumas configurações e os filtros são executados toda vez que uma syscall é chamada.

Ferramentas como Falco, ampliam essa abordagem ao usar eBPF para rastrear syscalls de processos já em execução, sem a limitação de aplicar políticas somente na inicialização. O Falco permite definir regras que geram alertas quando comportamentos suspeitos são detectados, usando drivers baseados tanto em módulo de kernel quanto em eBPF.

eBPF em soluções de rede

Quando pensamos em soluções de rede baseadas em eBPF, a primeira que vem a mente é o Cilium, que utiliza eBPF como plataforma para gerenciar toda parte de rede em clusters Kubernetes, provendo funcionalidades como balanceamento de carga, criptografia, observabilidade e muito mais. Outro grande exemplo é a Cloudflare, que utiliza eBPF em soluções conta DDoS.

E ao falarmos em rede, vale dar uma breve explicação sobre XDP (eXpress Data Path). O XDP é uma tecnologia para processamento de pacotes de rede, que executa programas no ponto mais “baixo” possível da stack de rede. Ele é utilizado em aplicações como:

• Firewall de baixa latência, que inspeciona cada pacote assim que ele chega à interface de rede;

• Mitigação de ataques DDoS ao monitorar a taxa de pacotes por IP de origem, por exemplo, se um IP exceder um certo limite em um intervalo de tempo, os pacotes serão descartados;

• Pacotes malformados podem explorar vulnerabilidades (Packet of Death) no kernel, causando instabilidades ou até a paralização do sistema. Um programa XDP pode inspecionar padrões suspeitos (como headers inválidos ou tamanhos inconsistentes) e descartar o pacote antes que ele chegue de fato no kernel.

Além disso, programas XDP não são limitados a “apenas” inspecionar conteúdos de pacotes de rede, eles também podem modificar o conteúdo desses pacotes. Outro fato interessante é que atualmente já existem placas de rede (interfaces) que suportam XDP Offload, onde os programas eBPF são executados no próprio processador da placa, ou seja, um pacote pode ser dropado ou redirecionado antes mesmo de chegar ao kernel do sistema e não gastar ciclos de CPU do servidor de forma desnecessária, o que pode resultar em melhoras significativas em performance.

eBPF e a stack de rede do Kubernetes

Esse não é o ponto central do post, mas acredito que seja bom exemplificar como eBPF pode ajudar a melhorar o tráfego para (e entre) workloads rodando no Kubernetes.

Um Pod no Kubernetes, é um grupo de conteineres que compartilham o mesmo namespace do kernel e cgroups, o que isola Pods um dos outros e do servidor/node onde eles estão rodando.

Geralmente (isso vai variar de ambiente pra ambiente), um Pod tem seu próprio namespace de rede e seu endereço IP, o que significa que o kernel tem uma stack de rede para cada namespace, separando a rede do servidor/node de outros Pods. Como mostro abaixo, o Pod é conectado ao servidor/node por uma conexão Ethernet virtual.

Nota-se que pacotes que vem de fora do node tem que trafegar por toda a stack de rede daquele servidor, até a interface virtual e posteriormente até a rede do Pod e consequentemente toda a stack de rede do namespace do Pod até chegar na aplicação.

Para mais contexto sobre iptables, recomendo dar uma lida nesse belo material sobre o tema.

Essas duas stacks estão no mesmo kernel, certo? Então podemos concluir que o pacote está fazendo o mesmo caminho duas vezes. Com isso, teremos uma latência mais alta. Uma solução para esse cenário seria utilizar o Cilium e substituir toda carga duplicada de roteamento do kernel e do iptables, uma vez que o eBPF é uma solução mais inteligente pra isso.

Mas qual o real motivo de evitar a utilização de iptables? O componente kube-proxy implementa uma load balancer que permite que vários Pods respondam requisições enviadas a um Service e por baixo dos panos o kube-proxy utiliza iptables.

Como muito de vocês sabem, existe a possibilidade de utilizar plug-ins de CNI (Container Network Interface) que implementam novas funcionalidades em toda camada de rede de um cluster, porém, a grande maioria ainda utiliza regras de iptables que trabalham na camada 3 e 4 (Rede e Transporte) e quando essas regras precisam ser atualizadas elas podem demorar e muito - o trecho do vídeo abaixo explica o motivo.

Então devido a utilização de eBPF pelo Cilium, toda a configuração de regras, conntrack e balanceamento de carga são armazenadas em hash table maps, que possibilitam essas operações escalar de forma muito melhor.

Finalizando

Não só eBPF, mas como o Cilium, são tecnologias que vão muito além de um post. O tema é vasto e uma coisa é entender o funcionamento macro e outra coisa é entender criando programas eBPF e implementando o Cilium. Se rolou um interesse mais e gostaria que eu abordasse mais sobre o assunto, deixe um comentário ou me procure no LinkedIn para batermos um papo.

Existe também um Substack muito interessante só sobre eBPF, chamado eBPF Chirp. Vale a pena conferir.

Até a próxima!

Bem-vindos a mais um post da série sobre Systems Performance. Até agora abordei desde os conceitos e métricas, até como realizar capacity planning de forma eficaz. E seguindo a ideia, nesse post abordarei como descrever os objetivos de melhoria de performance, técnicas, desafios de diferentes linguagens de programação e muito mais, então pegue um café e aproveite a leitura. ☕

Criando contexto

Antes de iniciar qualquer tipo de análise, assim como abordei em posts anteriores, é importante criar um entendimento sobre como a aplicação se comporta em alto nível, o que ela faz, como ela opera e como é a performance atual. Para isso é importante se perguntar:

1. Qual é o papel dessa aplicação? É um web server, banco de dados, load balancer?

2. Quais tipos de requisições essa aplicação serve? É possível medir?

3. A aplicação roda em qual modo de CPU? User-level ou kernel-level?

4. Como é realizada a configuração da aplicação? Via arquivo, ENV VARs?

5. Como é a infraestrutura que hospeda a aplicação? Quais são seus recursos e limites?

6. A aplicação publica métricas e logs? Quais logs podem ser habilitados e quais métricas de performance estão disponíveis através de logs?

7. Houve alguma modificação recente visando melhoria de performance?

8. Existem bugs conhecidos em bibliotecas terceiras? Algum tipo de bug conhecido no web server ou banco de dados que possa afetar performance?

Ao responder essas questões, você terá uma ideia de onde o esforço precisa ser aplicado e o que você precisa fazer e criar um objetivo. Você pode iniciar com os tipos de operações ou requisições que a aplicação serve, se possível sempre usando métricas - tais métricas podem vir como requisito de negócio ou de um arquiteto de soluções (ou alguém que faça esse papel na sua empresa), alguns exemplos de objetivos:

• Latência média de 10ms;

• 90% das requisições completadas com latência abaixo de 200ms;

• Não ter requests acima de 2s;

• Cada instância (servidor, Pod, VM) da aplicação processar 5000 requests por segundo;

Ao começar esse trabalho é comum (ou deveria ser) olhar o código da aplicação. Uma forma eficiente de realizar performance é iniciando onde a maior parte do workload é realizado. Por exemplo, se uma API está com alta latência, pode ser mais assertivo analisar os trechos de código responsáveis por acessar o banco de dados ou fazer serializações mais pesadas.

Aprofundando nas técnicas

Existem algumas técnicas para melhorar performance de aplicações, vou abordar algumas aqui começando por Caching.

Caching

Sistemas Operacionais utilizam cache para melhorar a performance de leitura em sistemas de arquivos. Nas aplicações utilizamos cache pelo mesmo motivo, ao invés de sempre executar uma operação pesada de leitura, os resultados de algumas operações podem ser armazenados em um cache para uma utilização futura. Um ótimo exemplo é cache em bancos de dados, onde o resultado das queries pode ser armazenado em um memcached ou Redis. Enquanto o cache vai melhorar o tempo de leitura, o disco será usado como um buffer para melhorar operações de escrita.

Buffering

Geralmente falamos muito mais de cache do que buffering, mas a realidade é que essa é uma das maneiras de melhorar operações de escrita, onde os dados podem ser agrupados em um buffer antes de serem enviados para o próximo passo do processamento, aumentando o tamanho das operações de I/O. Porém, existe um trade-off onde dependendo do tipo de escrita, onde isso pode aumentar a latência, já que primeira escrita precisa esperar por outras.

Escolhendo o tamanho da operação de I/O (ou I/O Size)

Antes de falar sobre isso vale diferencia tamanho de I/O (I/O Size) de Block Size.

I/O Size é o page size que a aplicação utiliza, por exemplo 8KB no Postgres, 16KB no MySQL, ou seja, é o tamanho real dos dados que estão sendo lidos e escrito em uma única operação. Já o Block Size é configurado no lado do Sistema Operacional (ou storage) e se refere ao tamanho da unidade de dados consegue endereçar, por exemplo se o Block Size do disco são 16KB, mesmo que você grave 5KB, o sistema irá utilizar 16KB no disco.

Dito isso, aumentar o tamanho das operações de I/O é uma estratégia para melhorar o throughput. Por exemplo, é muito mais eficiente transferir 128 KB de uma vez só, do que fazer 128 operações separadas de 1 KB cada. E como sempre há trade-offs. Se a aplicação não precisa de tamanhos maiores de I/O, o desempenho pode piorar (e muito). Imagine um banco de dados que faz leituras de 8 KB, se o sistema estiver lendo 128 KB por operação, 120 KB são desperdiçados a cada leitura. Isso gera uma latência desnecessária, que poderia ser reduzida com operações de I/O menores e mais alinhadas com o padrão de acesso da aplicação.

Paralelismo e Concorrência

A diferença entre paralelismo e concorrência é bem importante para entender como otimizar aplicações. Concorrência é a capacidade de lidar com múltiplas tarefas ao mesmo tempo, enquanto paralelismo implica na execução simultânea dessas tarefas.

Fibers e Threads

Threads são as unidades básicas de execução gerenciada pelo sistema operacional. Cada thread possui sua própria stack e estado, compartilhando o mesmo espaço de memória com outras threads do mesmo processo. O sistema operacional aloca tempo de CPU para cada thread e realiza o context switching (processo de armazenar o estado da thread) entre elas, o que pode ser custoso devido ao overhead de salvar e restaurar o estado.

Fibers, por outro lado, são threads leves (lightweight threads) gerenciadas pela própria aplicação e não pelo sistema operacional. A principal diferença é que o escalonamento de fibers é cooperativo, ou seja, a aplicação controla o fluxo de execução, em vez de ser interrompido (preemptivo) pelo sistema operacional. O interessante das fibers é que elas ocupam bem menos memória se comparado a threads, cada fiber pode ocupar de 2KB a 4KB.

Coroutines

Coroutines representam um modelo de concorrência onde as funções podem ser suspensas e retomadas posteriormente, mantendo seu estado entre execuções. As principais características incluem:

• Suspensão e retomada: Uma coroutine pode pausar sua execução e retornar o controle para quem a chamou, mas mantém seu estado para continuar de onde parou;

• Execução assíncrona sem callbacks: Permitem escrever código assíncrono de forma sequencial, evitando o callback hell;

• Eficiência: Consomem menos recursos que threads, permitindo alta concorrência.

Thread Pools

Thread pools são mecanismos para gerenciar um conjunto de threads reutilizáveis, evitando a criação e destruição constante de threads, devido ao context switching que mencionei anteriormente.

Um service thread pool é dedicado a operações de longa duração, especialmente com foco em I/O (acesso a rede, DBs ou filesystems). Já um CPU thread pool é dedicado a operações de processamento intensivo, ideal para cálculos, transformações de dados, compressão, etc…

SEDA (Staged Event-Driven Architecture)

SEDA é uma arquitetura que decompõe uma aplicação em um conjunto de estágios conectados por filas, onde cada estágio possui seu próprio thread pool. Essa abordagem fornece alguns benefícios como:

• Isolamento de recursos: Problemas em um estágio não afetam diretamente outros estágios;

• Permite backpressure: Filas entre estágios podem implementar mecanismos de controle de fluxo;

• Otimização de recursos: Cada estágio pode ter seu thread pool dimensionado de acordo com suas características específicas;

• Monitoramento mais fácil: Métricas podem ser coletadas por estágio, facilitando a identificação de possíveis gargalos.

Linguagens de programação

Linguagens de programação podem ser interpretadas ou compiladas. Vale um grande parêntese aqui: muitas das linguagens se “vendem” por serem conhecidas por ser otimizadas para performance, mas que no final das contas, vai depender mais do software ou do código escrito do que da linguagem em si. Essa é a verdade.

Compilado vs Interpretado

Linguagens compiladas, como C, Go e Rust, passam por um processo de compilação antes da execução, onde o código fonte é traduzido para instruções de máquina e armazenado em arquivos binários. Esses binários podem ser executados a qualquer momento, sem necessidade de ser recompilado.

Uma das grandes vantagens das linguagens compiladas é a performance. Como o código já está traduzido para instruções que o processador entende, não haverá o overhead de interpretação durante o runtime.

Compiladores também aplicam otimizações, reorganizando instruções para extrair ainda mais desempenho.

Já por outro lado, as linguagens interpretadas como PHP, Python ou Ruby executam o código linha por linha durante o runtime. Esse processo de interpretação envolve parsing, tradução e execução dinâmica, o que vai adicionar um overhead a cada execução. Sim, essas linguagens não foram projetadas pensando em alta performance, e sim em produtividade e facilidade de escrita. Porém, há diversos sistemas mega robustos recebendo milhares de requests por segundo construídos com essas linguagens, o que novamente vale ressaltar: vai depender muito mais de como seu código foi escrito do que da linguagem em si.

Garbage Collection

Algumas linguagens utilizam um sistema automático de gerenciamento de memória, onde a memória alocada pela aplicação é “limpa” de forma assíncrona, chamado Garbage Collector. Porém, ao utilizar GC també há trade-offs:

• A memória da aplicação pode crescer de forma gradativa se o GC não liberar objetos corretamente, levando seu sistema a “swapar” ou até cair (aquele famoso OOM no Kubernetes);

• O GC consome CPU ao escanear a memória, o que pode reduzir os recursos disponíveis para a aplicação, especialmente em aplicações com uso intensivo de memória;

• Dependendo do tipo de coleta utilizando no GC, ele pode pausar a execução da aplicação em alguns casos, retornando requests com uma latência acima do esperado.

Vale consultar a documentação da linguagem utilizada e configurar o GC de acordo com o seu cenário.

Virtual Machines

Linguagens como o Java são normalmente executadas em Virtual Machines (VMs), onde elas podem ser executadas independente da plataforma. O código fonte é compilado para um conjunto de instruções da VM, chamado bytecode, que pode ser executado em qualquer sistema que tenha aquela VM instalada.

Ainda utilizando o exemplo do Java, é possível utilizar JIT que converte o bytecode em instruções de máquina, oferecendo uma performance bem próxima ao de um código compilado.

Voltando em metodologias

Além das metodologias que descrevi em um post dedicado ao tema, vale a pena ressaltar algumas técnicas de análise um pouco mais específicas, como CPU Profiling, análise de syscalls e tracing distribuído.

CPU Profiling

Profiling constrói uma “imagem” de alguns momentos durante a execução da sua aplicação para entender um determinado comportamento da CPU, onde é possível identificar gargalos e problemas de performance.

Atualmente, várias (ou quase todas) ferramentas de observabilidade e monitoração possuem suporte a profilers, mas o que muita gente desconhece é que o próprio linux possui ferramentas para tal finalidade, como o perf. O perf roda em modo kernel e pode caputar tanto stacks do kernel (kernel-level) quanto de usuário (user-level), o que vai prover uma visibilidade praticamente completa da utilização da CPU.

Os profilers construidos para linguagens específicas geralmente capturam a utilização da CPU em user-level, o que pode ocultar algumas informações, por isso o ideal é iniciar essa análise utilizando um profiler que tenha acesso tanto ao user-level quanto ao kernel-level, para ter uma visão do todo.

A minha recomendação aqui é utilizar flame graphs. Eles estão disponíveis na maioria das ferramentas de observabilidade hoje em dia.

Outros recursos

Os profilers também mostram evidências de problemas que podem estar acontecendo além da utilização de CPU, I/O de disco é um exemplo disso. Ao analisar resultados de profilers através de flame graph, você pode encontrar funções que referenciam quais operações estão acontecendo naquele momento.

É importante ressaltar que ao analisar essas operações você só irá encontrar as atividades e não seus resultados. Uma das formas de entender melhor essas operações é instrumentando a aplicação com OpenTelemetry por exemplo, dessa forma você irá conseguir correlacionar melhor em qual parte do código está utilizando mais rede ou disco.

Vou listar alguns nomes de funções para dar uma ideia dessas operações ao analisar flame graphs:

• ext4, zfs, xfs: Operações no file system

• tcp: Operações de rede

• alloc: Alocação de memória

Syscalls

System calls também podem ser instrumentadas para encontrar problemas de performance. A ideia aqui é entender onde o time da syscall é gasto, incluindo o tipo e o motivo dela ter sido invocada.

Existe uma documentação muito abrangente sobre syscalls no próprio man. Vou listar algumas syscalls importantes que podem ser analisadas:

• Para execução de novos processos. Você pode utilizar o execsnoop para analisar a syscall execve(2);

• Para syscalls de I/O como read(2), open(2) e send(2) você pode utilizar o bpftrace;

• Já a ferramenta syscount pode mostrar o tempo de CPU em operações do Kernel (Kernel time).

Vale lembrar que dependendo da distribuição Linux, o nome desses comandos podem ser um pouquinho diferente. Por exemplo, no Ubuntu as ferramentas são nomeadas como coloquei acima. Já no PopOS! elas tem o sufixo bpfcc.

USE

Assim como mencionei no post anterior, é possível utilizar a metodologia USE para resolver problemas em aplicação através da análise da utilização, saturação e erros.

Por exemplo, imagine um serviço que processa uploads de arquivos em background. Esse serviço terá utiliza uma fila de tarefas e um conjunto de processos (pool de worker threads) que irão armazenar os arquivos no S3. Tendo esse serviço em mente poder definir três métricas assim:

• Utilização: Percentual médio dos processos de upload que estiveram ativos em um intervalo de tempo. Por exemplo, 80% significa que, em média, 8 de 10 processos estavam ocupados lidando com uploads;

• Saturação: Tamanho médio da fila de uploads pendentes no mesmo intervalo. Esse valor indica quantos uploads estavam esperando por um processo disponível para começar;

• Erros: Quantidade de uploads que falharam, seja por timeout, problemas de rede ou tamanho do arquivo excedido.

A próxima etapa seria identificar como coletar essas métricas. Algumas podem estar expostas pela aplicação via logs e métricas no formato timeseries para ser analisadas via Prometheus ou até utilizar eBPF para uma análise em tempo real. Esse tema ficará para um post futuro.

Tracing distribuído

Por fim, temos tracing distribuído, muito utilizado em ambientes de arquitetura distribuída compostas por serviços rodando em diferentes servidores e/ou sistemas.

Tracing distribuído envolve analisar informações de cada request realizadas nesses serviços e combiná-las para ter uma visão geral. Dessa forma saberemos quais são as dependências de cada serviço, o tempo gasto em cada uma dessas dependências e qual serviço está gerando a latência ou os erros que estão sendo retornados.

Dentro das informações que os traces produzem podem estar:

• RequestID único da transação

• Horário de início e fim da transação

• Status de erros

Um dos desafios do tracing distribuído é o volume de dados que pode ser gerado, onde cada requisição na aplicação pode resultar em múltiplos registros. Uma abordagem comum para lidar com esse problema é utilizar sampling, por exemplo, é possível coletar dados de apenas uma em cada mil (ou mais) requests. Isso costuma ser suficiente para entender o comportamento geral do sistema, mas pode dificultar a análise de erros intermitentes.

Vale também mencionar que existem dois tipos de sampling, head-based e tail-sampled. Onde o head-based a decisão se toda informação será armazenada é feita no início da request e o tail-based é decidido posteriormente. A diferença entre eles é que no tail-based alguns critérios como latência ou presença de erros serão levados em consideração se o trace será mantido ou descartado.

Concluindo

Acredito que seja muito valioso abordar esses temas mais profundos, principalmente para quem trabalha com performance de aplicações, como SREs e engenheiros de software. Entender o que realmente está acontecendo em seu sistema é essencial para não ficar aquele famoso jogo de “empurra-empurra” entre infraestrutura e código.

Ferramentas de observabilidade ajudam bastante a mostrar sintomas e possíveis causas, mas saber como sua aplicação funciona, qual é o seu papel e como iniciar uma análise estruturada é o que faz diferença de verdade. No fim das contas, um bom troubleshooting começa com contexto, não com achismos.

Até a próxima.

Bem vindos a mais um post da série sobre Systems Performance. Agora vou abordar um tema que vejo que é pouco discutido em times de engenharia e SREs, mas super importante. Capacity Planning.

Capacity Planning sempre existiu, não é coisa nova. Nos meus tempos de sysadmin e datacenters físicos, planejar a capacidade dos recursos computacionais era super importante pois nos dava uma visão de que tipo de servidores comprar, se seria necessário investir em novos switches de fibra para interligar aquele novo storage lotado de disco SSD e por aí vai. Era uma época onde escalar horizontalmente não era tão simples (e barato) como hoje, então tudo devia ser muito bem pensado.

Com avanço da cloud, ficou muito mais fácil de escalar, subir e descer recursos sob demanda, mas assim como no passado (não tão distante), economia de custos sempre foi uma vantagem muito competitiva. E Capacity Planning é isso, é ter orçado e planejado a quantidade certa de recursos para desde uma aplicação até toda camada de dados e armazenamento. É saber colocar na balança performance e custo, sem levar a empresa a falência. É o famoso fazer mais com menos.

Capacity Planning também é analisar como uma aplicação vai se comportar quando começar a receber requisições e como ela irá escalar conforme a quantidade de requisições aumenta. Essa análise pode ser feita de várias maneiras, vamos lá.

Limites de Recursos

Encontrar o recurso que vai se tornar o gargalo sob muita carga é a primeira forma de análise. Em ambientes de containers, recursos podem ter seus limites setados por configurações e que podem vir a se tornar um gargalo. E por onde podemos começar?

Comece identificado o papel daquele servidor e o tipo de requisições que ele serve, por exemplo, um servidor web serve requisições HTTP, já um servidor NFS serve requisições através do protocolo NFS e um servidor de banco de dados serve requisições de queries.

O próximo passo é determinar o consumo de recurso por requisição. Para um sistema existente, você pode medir a taxa de requisições atuais junto com a utilização dos recursos, onde você pode estimar através de extrapolação qual recurso irá chegar aos 100% de utilização primeiro e qual será a taxa de requests. Para sistemas que estão sendo desenvolvidos, você pode utilizar ferramentas que de load test para simular a quantidade de requests que aquele sistema deve receber e ao mesmo tempo medindo a utilização dos recursos. Conforme o número de requisições for aumentando, com certeza você irá encontrar o limite de utilização de cada recurso.

Certo, mas quais recursos eu posso monitorar?

Para hardware, utilização de CPU, utilização de memória, IOPS, throughput do disco e rede e espaço em disco. No lado do software, utilização da memória virtual, quantidade de threads/processos e de file descriptors.

Digamos que você está analisando uma aplicação que está recebendo 200 requests por segundo e o recurso mais ocupado no seu servidor são as 8 CPUs que ele possui, que estão com utilização média de 60%, então você chega na conclusão que esse será o seu gargalo assim que a CPU chegar em 100%, mas como você vai precisar saber quantas requests por segundo o sistema precisa receber pra chegar a esse ponto, certo? A fórmula pra chegar no valor é basicamente:

A predição seria de aproximadamente 333 requests por segundo para a CPU chegar a 100% ocupada. Porém, vale lembrar que essa é uma estimativa, pode ser que durante o aumento de requests algum outro fator limitante possa ser encontrado.

Análise de Recursos

Ao escolher uma instância/VM na cloud ou adquirir novo hardware há alguns fatores que podem ser alterados para alcançar a performance desejada. Esse processo inclui escolher o tipo e tamanho de discos e CPUs, a quantidade de memória, configurações do filesystem e por aí vai. A ideia é conseguir a performance desejada com o menor custo possível.

Uma ideia de como testar combinações de configurações a partir de uma configuração “máxima”:

1. Teste a performance usando todos os recursos configuradas ao máximo, por exemplo: uma instância com 16 CPUs, 64GB de RAM, utilizando discos SSD ou NVMe formatados e particionados da melhor forma possível;

2. Mude os fatores um por um e continue testando a performance;

3. Anote a porcentagem de queda de performance para cada recurso alterado e o custo financeiro de cada alteração/configuração;

4. Iniciar com o máximo de performance (e que o bolso pode pagar), escolha os recursos que você abre mão para economizar mais, ao mesmo tempo mantendo a quantidade de requests necessárias;

5. Teste novamente a configuração ideal para confirmar se a performance está dentro do esperado.

Imagine que estamos projetando a capacidade de um banco de dados distribuído para uma aplicação de recomendação de produtos. O requisito é suportar 500k queries por segundo, com um dataset de 2TB, distribuído em 10 nodes. A configuração máxima para cada node seria 2 CPUs com 32 cores, 512GB de RAM, 4 SSDs entregando 100k IOPS cada e um throughput de rede de 40Gbps.

Se reduzirmos os recursos, vamos observar as seguintes quedas na performance:

• Reduzindo para 1 CPU: 45%

• Utilizando metade de RAM (256GB): 60%

• Usando 2 SSDs: 35%

• Reduzindo a rede para 10Gbps: 30%

Com essa configuração, vamos estimar a performance estimada por cada node:

Cada node entregaria ~5000 queries por segundo, ou seja para suportar 500k queries por segundo, precisaríamos de 100 nodes. Analisando profundamente, essa configuração “econômica” pode não ser viável. Por isso, teste muito e avalie o que vale a pena no fim do dia.

Escalando

Quando pensamos em escalar sistemas, geralmente pensamos em duas soluções, a vertical, onde aumentamos a quantidade de recurso de um determinado servidor, ou a horizontal, onde aumentamos a quantidade de réplicas geralmente atrás de um load balancer para que esses servidores pareçam ser um só.

Hoje quando só falamos em cloud, é possível utilizar instâncias/VMs menores e se aproveitar cada vez mais do escalonamento horizontal de forma mais eficiente, sempre adicionando novas instâncias aos poucos, o que nos leva a um Capacity Planning menos “rigoroso” no início de um projeto em fase de desenvolvimento.

Como já bem conhecido e estabelecido é possível automatizar esse escalonamento em qualquer cloud utilizando métricas. Por exemplo, na AWS existe o Auto Scaling Group, onde uma política de escalonamento customizado pode ser utilizada para aumentar ou diminuir a quantidade de instâncias baseada em uma métrica.

Em sistemas como o Kubernetes, também existe suporte a autoscaling, como por exemplo o HPA, que pode escalar Pods de forma horizontal se baseando em métricas de utilização de CPU ou de alguma outra métrica customizada.

Já para bancos de dados, uma forma comum de escalonamento é o sharding, onde o dado é dividido em segmentos lógicos gerenciado por instâncias distintas.

Pretendo fazer um post sobre isso mais para frente.

Pontos finais

Capacity Planning sempre existiu e sempre irá existir como uma boa prática, não só para SREs, mas para arquitetos de soluções, engenheiros trabalhando em early-stage Startups ou Scaleups. É uma estratégia bem importante para definir como crescer e escalar seus sistemas.

Até a próxima!

Esse é mais um post da série sobre Systems Performance. Dessa vez, irei abordar sobre metodologias, ou seja, por onde começar suas análises em ambientes e aplicações que não estão performando bem. Vou abordar sobre as principais utilizadas hoje em dia, como USE e RED, mas também comentar sobre formas mais simples que as vezes, podem dar uma luz só pelo fato de fazer algumas perguntas.

Mas antes disso, vamos dar um passo para trás e falar sobre perspectivas de análises.

Perspectivas

Existem duas perspectivas comuns para a análise de performance, cada uma direcionada a “alvos” diferentes e utilizando métricas e abordagens distintas. Essas perspectivas são: as análises de workloads e as análises de recursos.

A análise de recursos começa examinando os principais componentes do sistema, como CPU, memória, discos, interfaces de rede e etc... O foco aqui está na utilização, com o objetivo de identificar quando os recursos estão próximos de atingir ou se já excederam seus limites. Alguns recursos, como a CPU, possuem métricas de utilização diretamente acessíveis. Para outros, é necessário fazer estimativas baseadas em dados disponíveis, como calcular a utilização de interfaces de rede comparando o tráfego de saída (egress) e entrada (ingress) com a largura de banda máxima.

As métricas mais adequadas para análise de recursos incluem: IOPS, Throughput, Utilização e Saturação. Vou entrar em detalhes sobre isso mais a diante.

Essas métricas revelam não apenas a carga aplicada a cada recurso, mas também o quão próximos eles estão de seus limites operacionais. Métricas adicionais, como latência, fornecem uma visão complementar, ajudando a avaliar como os recursos estão lidando com os workloads em termos de tempo de resposta. Existem ferramentas nativas no Linux como vmstat, mpstat e iostat, que fornecem dados detalhados para uma análise mais certeira.

Já a análise de workload foca no desempenho das aplicações, avaliando a carga aplicada e como a aplicação responde a ela. As principais métricas para análise são taxa de requests e latência.

Essa análise envolve examinar os atributos das requests, como o quantidade de clients, tabelas mais acessadas ou as queries mais realizadas. Isso ajuda a identificar cargas desnecessárias ou desbalanceadas. Mesmo em sistemas com baixa latência, entender os padrões de workload pode revelar algumas oportunidades de otimização.

A latência é o indicador mais importante de desempenho da aplicação, representando o tempo de resposta. Para diferentes sistemas, como bancos de dados ou servidores web, a latência equivale ao tempo para processar queries ou requisições HTTP.

Com isso alinhado, vamos nos aprofundar em algumas metodologias.

Metodologias

Ao trabalhar com aplicações e ambientes não performáticos, geralmente o primeiro desafio é: Por onde devemos começar?

Assim como mencionei no primeiro post dessa série, problemas de performance podem aparecer de qualquer lugar, software, hardware ou qualquer componente que esteja no fluxo dos dados. As metodologias de análise podem ajudar por onde iniciar a análise com processos mais efetivos.

Entendendo o problema

Entender o que de fato está acontecendo é a primeira coisa a ser feita. Não importa o tipo de problema. Com uma série de perguntas básicas, as vezes é possível chegar a uma causa e a solução do problema só respondendo essas perguntas.

1. O que te faz pensar que existe um problema de performance?

2. Essa aplicação já teve boa performance anteriormente? Se sim, há quanto tempo?

3. O que mudou nos últimos dias? Código? Alteração no workload? Hardware?

4. É um problema no tempo de resposta?

5. O problema está afetando outras aplicações?

6. Como está o ambiente? Quais libs são utilizadas? Existem versões mais novas? Qual a configuração da aplicação?

Obviamente que isso se torna cada vez mais “fluído” e natural uma vez que a senioridade da pessoa vai aumentando. Uma dica que eu dou para enriquecer ainda mais a análise é testar a hipótese de um problema com base em dados.

Outra dica que eu dou é, cuidado com o número de ferramentas ao analisar e entender o problema. Sempre que possível, tente correlacionar as métricas em um único lugar.

USE - Utilization, Saturation, Errors

O método USE é uma das abordagens para identificar gargalos e desempenho em sistemas. Ele se concentra na análise de recursos como CPUs, memória e disco, seguindo três métricas-chave:

1. Utilization: Mede o percentual de tempo ou capacidade que um recurso está ocupado processando algum workload. Para memória, a utilização se refere à porcentagem da capacidade total em uso.

2. Saturation: Indica a “pressão” sobre o recurso, geralmente manifestada por filas de espera quando o recurso não consegue atender à toda demanda.

3. Errors: Mede eventos de falha, incluindo operações que precisam ser repetidas ou dispositivos com falhas.

Essa metodologia prioriza a verificação rápida dessas métricas para todos os recursos do sistema, criando uma lista de "known-unknowns" quando os dados estão indisponíveis.

Uma dica aqui é a investigação de erros, que podem degradar o desempenho sem serem identificados de imediato, especialmente em sistemas que possuem algum tipo de mecanismo de recuperação automática.

No fluxograma abaixo, demonstro de forma prática como iniciar uma análise utilizando o método USE.

Erros geralmente são verificados primeiro, já que eles são rápidos e fáceis de interpretar. Saturação é verificado em um segundo passo devido a facilidade de interpretar se comparado com a Utilização, já que qualquer nível de saturação pode ser um problema.

Um ponto importante de destacar é que picos curtos de alta utilização podem causar saturação e consequentemente, problemas de desempenho, mesmo que a utilização média em intervalos maiores pareça baixa. Ferramentas de monitoramento que usam médias de 5 minutos por exemplo, podem mascarar esses picos, como no caso de CPUs que atingem 100% brevemente, gerando gargalos não detectáveis em médias mais extensas.

Assim que você tiver em mãos os recursos a serem analisados, pense nas métricas para cada um deles se baseando em utilização, saturação e erros, por exemplo:

Algumas dessas métricas podem não estar disponíveis em ferramentas padrões que já acompanham o sistema operacional e podem necessitar de uma monitoria adicional.

Gosto de pensar nessas métricas da seguinte forma:

• Utilização: Geralmente utilização em 100% é um sinal de gargalo. Acima de 60% já pode ser um problema em alguns casos. Dependendo do intervalo de monitoração, ele pode esconder os picos de alta utilização;

• Saturação: Qualquer nível de saturação pode ser um problema. Medir o tamanho da fila de espera ou o tempo aguardando na fila é uma boa também;

• Erros: Igual a Saturação, qualquer evento de erro é válido investigar, ainda mais se a performance está degradada e os erros continuam aumentando.

E recursos de sistemas?

Alguns recursos de software ou sistemas também podem ser analisados dessa forma. Isso geralmente se aplica a componentes menores e não aplicações inteiras, vamos aos exemplos:

• Thread pools: A Utilização pode ser definida pelo tempo que as threads estavam ocupadas (busy) processando algum workload, já a Saturação pode ser definida pela quantidade de requests aguardando serem processadas;

• Capacidade de thread ou processo: O sistema pode ter uma quantidade limitada de processos ou threads, o qual o uso naquele momento pode ser definida para Utilização. Já o tempo de espera de alocação de novas threads pode indicar Saturação e por fim Erros é quando a alocação falhou, no caso gerando um cannot fork;

• Capacidade do file descriptor: Similar a capacidade de threads e processos, porém para file descriptors.

Em casos de microsserviços rodando no Kubernetes por exemplo, podemos pensar da seguinte forma:

• Utilização: A média de utilização de CPU se comparado ao total de CPU disponível no cluster;

• Saturação: A diferença entre o p99 e a média da latência;

• Erros: Erros de requests.

Porém, há uma metodologia que foi criada especificamente para serviços, a RED.

RED - Request Rate, Errors, Duration

O objetivo da RED é acompanhar métricas de serviços, já que podemos verificar a saúde do sistema com a perspectiva do usuário.

As métricas são:

• Request rate: O número de requisições por segundo;

• Errors: A quantidade de requisições que falharam;

• Duration: O tempo que levou para completar uma requisição.

As vantagens de utilizar a metodologia RED são similares ao USE. É fácil e rápido de identificar problemas. Vale ressaltar que ambas metodologias se complementam, você pode utilizar a USE para saúde de recursos do servidor e RED para aplicação.

Medir a taxa de requisições (request rate), dá uma boa ideia de onde começar a investigar o problema, se é um problema de performance ou é pela quantidade (de requisições) ou um problema arquitetural (meu post anterior fala um pouco disso). Se a taxa de requisições está estável, mas a duração delas está aumentando possivelmente é um problema de arquitetura. Se ambos aumentam, então o problema pode ser o workload.

Investigando o workload

Workloads podem ser caracterizados respondendo algumas perguntas:

• Quem causou a carga? Foi um processo, usuário (aplicação) ou um IP remoto?

• Por que essa carga excessiva? Existe um stack trace para análise?

• Quais são as características dessa carga? Aumento de IOPS, throughput?

• Como a carga muda conforme o tempo? Existe um padrão? É um padrão diário?

Imagine este cenário: você está investigando um problema de desempenho em microsserviços em um cluster Kubernetes. O tráfego esperado deveria vir de serviços internos, mas você decide verificar as métricas de rede. Para sua surpresa, descobre que um único nó está recebendo uma quantidade anormal de conexões de outro serviço, enquanto os demais estão praticamente ociosos. Após uma investigação mais profunda, percebe que um erro na configuração do service discovery está direcionando todas as requisições para apenas um pod, causando um hotspot e degradando o desempenho da aplicação.

Five whys

Um método adicional que você pode utilizar é o Five Whys, onde você se pergunta “Por que?” por cinco vezes (ou mais) até encontrar a causa raíz.

1. Uma instância de banco de dados começou a degradar performance conforme a quantidade de queries aumentou. Por que?

2. É um problema de IO devido a paginação de memória. Por que?

3. A utilização de memória aumentou. Por que?

4. O alocador está consumindo mais memória do que o previsto. Por que?

5. A versão do banco de dados tem um bug no alocador de memória.

Esse é um caso real que pode ser resolvido atualizando a versão do banco de dados. O problema foi encontrado se questionando e indo a fundo para entender a causa raíz.

Anti-patterns

Para fechar o post, vale mencionar dois anti-patterns muito comuns de acontecer. Principalmente se quando existem silos muito bem definidos na estrutura de engenharia da empresa.

O primeiro deles é quando a pessoa responsável por solucionar um problema, vai tentando adivinhar onde está a causa raíz e sai mudando várias configurações, alocação de recursos, atualização de libs até o problema desaparecer. Além de ser um processo custoso, a pessoa pode ter alterado algo que não faz o menor sentido.

Outro exemplo que é clássico é jogar o problema no colo do colega. Imagine o seguinte cenário, a pessoa começou a analisar um problema, sem nenhuma análise muito profunda, ela acha que o problema pode ser a rede. Por ter um time especializado naquele tema, ela joga o problema para o time. Caso o problema não seja aquele, a pessoa volta para a análise desde o início e continua jogando o problema para os outros.

A dica nesse caso para não se tornar dono de um problema que não é seu, peça a pessoa que está analisando o problema, evidências que comprovem o que ela está dizendo.

Conclusões

Acredito que abordei nesse post a maioria dos temas sobre metodologias que conheço e utilizo. Minhas dicas para SREs e SWEs que gostam do tema é, tenham em mente as metodologias como USE e RED. Elas fornecem um caminho estruturado para identificar e solucionar gargalos. Além disso, a abordagem investigativa baseada em perguntas e técnicas como Five Whys ajudam a enxergar além dos sintomas, chegando à verdadeira causa dos problemas.

No final das contas, resolver problemas de performance é tanto uma questão técnica quanto um exercício de análise crítica. Não tenha medo de perguntar e questionar. Ferramentas e métricas são essenciais, mas uma abordagem baseada em evidências é o que vai diferenciar um troubleshooting eficaz de um processo meia boca.

Até a próxima!

An english version is coming soon. Stay tuned. 😃

Uma breve introdução

Sempre fui contra utilizar os Helm Charts da Bitnami - as imagens dos conteineres são super modificadas e no caso do Keycloak especificamente, é uma confusão enorme com as ENV VARs para configurá-lo (KC_*), as ENV VARs para configurar o conteiner da Bitnami (KEYCLOAK_*) e a documentação não é das melhores. Mas não posso negar que em alguns momentos esses Charts ajudam a subir algo rápido, e foi por esse motivo que o time que trabalho decidiu subir dessa forma, ao invés de utilizar o Keycloak Operator.

No fim do ano passado, puxei a iniciativa de atualizar as intâncias de Keycloak que utilizamos na Pier com outros Staff Engineers para suportar algumas funcionalidades que seriam interessantes implementar em algumas aplicações. Foi um trabalho de formiguinha, mas deu certo. Nesse post, irei explicar o processo e dar algumas dicas.

Vale ressaltar que nem todos ambientes são iguais, no nosso caso, utilizamos ALB Ingress Controller no AWS EKS, rodando Kubernetes 1.31.

Após uma pergunta no grupo Cloud & Infra da comunidade Platform Engineering no Whatsapp, resolvi escrever esse post para ajudar outras pessoas. Espero que possa te ajudar também!

Dicas de ouro

A ideia era atualizar para a última versão do Keycloak (26.0.7) e meu primeiro erro foi tentar subir da versão 22 direto para 26 e subindo a versão do Helm Chart da 16 para 24. E as coisas não funcionam assim.

Por isso, faça upgrades sequenciais, tanto do Keycloak quanto do Helm Chart. Entre as major versions do Keycloak, o banco é atualizado diversas vezes e não senti segurança na execução das migrations entre a 22 e a 26, principalmente pela alta customização da imagem feita pela Bitnami. Os Helm Charts também devem ser atualizados de forma sequencial, porém, nem sempre atualizações entre major versions funcionam bem.

Segunda dica, antes de cada upgrade leia o Upgrading Guide na documentação oficial do Keycloak. A doc não é das melhores, mas explica mudanças significativas como alteração do hostname_v1 para hostname_v2 e na API.

A terceira dica é, testar, testar e testar. Verifique se o login na console de administração está funcionando e o principal, se sua aplicação continua funcionando conforme o esperado.

Atualizando

Os values utilizados a partir da versão 16.0.3 do Chart (Keycloak 22.0.1) estão nesse Gist. Eu usarei o mesmo YAML como referência até a versão 24.2.3 e mencionando apenas as mudanças, caso você não queira ir até a última versão do Chart.

Upgrades sem mudanças nos values

• Helm Chart: 16.0.3 → 17.3.6 / Keycloak: 22.0.5

• Helm Chart: 17.3.6 → 18.7.1 / Keycloak: 23.0.7

• Helm Chart: 18.7.1 → 19.4.1 / Keycloak: 23.0.7

  • Você pode pular esse upgrade e ir direto para a 19.4.1, caso queira ir para a versão 24.0.2 do Keycloak.

• Helm Chart: 19.4.1 → 21.0.0 / Keycloak: 24.0.2

• Helm Chart: 21.0.0 → 21.1.3 / Keycloak: 24.0.4

• Helm Chart: 21.1.3 → 21.2.2 / Keycloak: 24.0.4

  • Você pode pular esse upgrade e ir direto para a 21.3.4, caso queira ir para a versão 24.0.5 do Keycloak.

• Helm Chart: 21.2.2 → 21.3.4 / Keycloak: 24.0.5

• Helm Chart: 21.3.4 → 21.4.6 / Keycloak: 24.0.5

• Helm Chart: 21.4.64 → 21.5.0 / Keycloak: 24.0.5

• Helm Chart: 21.5.0 → 21.6.0 / Keycloak: 24.0.5

Upgrades com mudanças nos values

A partir da versão 21.6.0, uma série de releases foram lançadas tentando corrigir vários bugs, regressões e etc… um caos completo.

Você também irá notar que eu voltei para a 21.5.0. Isso se deve ao fato de puro troubleshooting, tentando quebrar minha cabeça para entender a bagunça feita pelos mantenedores e comunidade.

• Helm Chart: 21.5.0 → 22.1.0 / Keycloak: 25.0.2

  • Mudanças:

    • proxy: none - Isso se deve ao fato da remoção de como o Keycloak trata requests atrás de um proxy reverso.

    • proxyHeaders: forwarded - Devido a mudança acima, existe uma nova forma de tratar e configurar os proxy headers atrás de um ingress ou proxy reverso. Vale a pena ler a documentação oficial sobre o tema.

    • ingress.controller: gce - Alguns usuários utilizando o ingress-gce, setam /* no ingress.path, assim como eu, utilizando o ALB Ingress Controller. Setar gce nesse parâmetro vai fazer com que ao utilizar /*, o ingress rule não quebre.

    • hostnameStrict: false - Ajustando o configuração de hostname v2 do Keycloak.

• Helm Chart: 22.1.0 → 24.0.0 / Keycloak: 26.0.0

  • Sem mudanças

• Helm Chart: 24.0.0 → 24.2.3 / Keycloak: 26.0.7

  • As mudanças realizadas aqui foram feitas para resolver problemas que tivemos no nosso cenário:

    • global.security.allowInsecureImages: true - Utilizamos uma imagem customizada do Keycloak onde inserimos temas e mais alguns componentes desenvolvidos internamente. Mais infos aqui.

    • proxyHeaders: xforwarded - Após iniciarmos os testes, alguns fluxos de autenticação retornavam erros relacionados aos cookies. Setar xforwarded resolveu o problema.

O resultado final dessa saga, você pode conferir nesse Gist.

Notas finais

Eu levei um dia e meio para ler e entender todas as mudanças feitas no Helm Chart entre as versões 16.0.3 e a 24.2.3. Recomendo não só para o Keycloak, mas para qualquer Chart da Bitnami fazer o mesmo. Anotar e documentar o processo é importante para não perder o fio da meada.

Se atentar as mudanças na API do Keycloak no Upgrading Guide é super importante também. No nosso caso tivemos que fazer alguns ajustes nas aplicações, então tenha tudo mapeado.

Espero que esse post possa ajudar a comunidade de alguma forma.

Até mais!

Com anos de experiência na área, presenciei a evolução da infraestrutura de TI: da transição de servidores físicos para virtuais à administração de storages em redes de fibra óptica, da implantação de servidores blade à migração para a nuvem em meados de 2017. Uma constante em todas essas mudanças? A importância do desempenho e performance dos sistemas.

Cada desafio de performance exigia um mergulho profundo nos "bits and bytes" da tecnologia em questão, o que me permitiu acumular uma vasta gama de conceitos e metodologias ao longo do tempo.

Este (longo) post visa compartilhar esse conhecimento, abordando métricas de desempenho, trade-offs ao otimizar e quando parar de analisar e realizar otimizações. Com base nisso tudo, iremos nos aprofundar posteriormente em aplicar metodologias em cima disso tudo.

Antes de começarmos

Antes de prosseguirmos, é importante esclarecer alguns termos-chave que serão utilizados ao longo deste post.

• Cache: Uma área de armazenamento rápido que evita comunicação direta com uma camada de armazenamento mais lenta. Geralmente esse armazenamento é feito em memória RAM, o que melhora o desempenho das operações.

• Gargalo: É um recurso que limita a performance do sistema. Identificar e eliminar gargalos é uma atividade super importante na melhoria de desempenho de um sistema.

• IOPS: Operações de entrada e saída (I/O) por segundo é uma medida da taxa de operações de transferência de dados. Para operações de I/O em disco, IOPS se refere ao número de leituras e gravações por segundo.

• Latência: Expliquei no post anterior, mas é a medida do tempo que uma operação passa aguardando para ser processada.

• Saturação: O grau em que um recurso tem trabalho acumulado em fila que não consegue processar de imediato.

• Tempo de resposta: O tempo necessário para uma operação ser concluída, incluindo o tempo de espera e o tempo gasto para processar a operação, assim como o tempo de transferência do resultado de toda operação.

• Throughput: A quantidade de trabalho realizado em um determinado período. Em comunicações, o termo é frequentemente usado para se referir à taxa de dados (bytes por segundo ou bits por segundo). Em outros contextos, como em bancos de dados, throughput pode se referir à taxa de operações (operações por segundo ou transações por segundo).

• Workload: Refere-se à entrada ou carga aplicada ao sistema. Em um banco de dados, a carga de trabalho consiste nas consultas e comandos enviados pelos clientes.

Conceitos

Latência

Em alguns ambientes, a latência é o principal ponto de desempenho, enquanto em outros ela está entre as métricas mais importantes, junto com throughtput. A latência se refere ao tempo de espera antes que uma operação seja realizada, como o estabelecimento de uma conexão de rede antes de transferir dados em uma requisição HTTP. Esse tempo de resposta inclui tanto a latência quanto o tempo necessário para completar toda a operação.

A latência pode ser medida a partir de diferentes pontos, sendo frequentemente especificada pelo alvo da medição. Por exemplo, o tempo de carregamento de um site pode incluir a latência do DNS, da conexão TCP e o tempo de transferência dos dados. Em níveis mais amplos, todos esses componentes podem ser considerados parte da latência geral percebida pelo usuário, como o tempo desde o clique em um link até a página estar totalmente carregada.

Como a latência é uma métrica baseada no tempo, ela permite diversos cálculos e comparações diretas, facilitando a identificação e priorização de problemas de desempenho. Por exemplo, é mais simples comparar 200 ms de I/O de rede com 100 ms de I/O de disco do que comparar métricas diferentes como IOPS. Converter outras métricas para tempo ou latência sempre que possível torna a análise muito mais objetiva, permitindo assim prever aumentos de velocidade ao reduzir ou eliminar a latência.

Para referência, as abreviações de unidade de tempo estão listadas abaixo:

Trade-offs

Ao otimizar o desempenho, é crucial considerar os trade-offs mais comuns. O ditado popular "bom, bonito e barato" ilustra bem esse conceito. No nosso caso, iremos usar “bom, rápido e barato” e geralmente você só pode escolher dois desses atributos ao considerar os trade-offs ao otimizar um sistema.

Muitos projetos e times priorizam prazos e custos mais baixos, deixando o desempenho para depois. Essa abordagem pode se tornar problemática quando decisões iniciais comprometem futuras melhorias de desempenho. Exemplos incluem a escolha de uma arquitetura de armazenamento, o uso de uma linguagem de programação ou sistema operacional ineficientes, ou a escolha de componentes sem ferramentas robustas de análise de desempenho.

Na otimização de desempenho, um trade-off comum ocorre entre CPU e memória. Tradicionalmente, a memória é usada para cache, reduzindo o uso da CPU. Porém, com a abundância de CPU disponível hoje em dia, essa relação pode se inverter, o tempo livre de CPU pode ser dedicado à compressão de dados por exemplo, diminuindo assim o uso de memória.

Otimizações

A otimização de desempenho é mais eficaz quando realizada o mais próximo possível do local onde o workload da aplicação é executado. A tabela abaixo ilustra uma aplicação com diversas possibilidades de ajustes.

Ao otimizar no nível da aplicação, é possível eliminar ou reduzir consultas ao banco de dados, resultando em melhorias de desempenho significativas. Se ao invés de olharmos para as queries e otimizarmos o acesso ao disco, obviamente iremos melhorar as operações de I/O, porém, um custo já foi incorrido na execução de todo código, o que pode resultar em ganhos marginais.

Embora otimizar no nível da aplicação seja o mais eficaz nesse caso, ele nem sempre é o mais adequado em termos de observabilidade. Consultas lentas podem ser melhor entendidas ao analisar o tempo gasto na CPU ou as operações de I/O no sistema de arquivos e disco. Essas métricas são facilmente observáveis por meio de ferramentas do sistema operacional.

Grandes melhorias de desempenho, incluindo correções de regressões, são frequentemente identificadas à medida que o código da aplicação evolui. Nesses contextos, a otimização e a observabilidade a partir do sistema operacional podem ser negligenciadas. No entanto, é importante lembrar que a análise de desempenho do sistema operacional pode também identificar problemas no nível da aplicação, frequentemente de maneira mais eficiente do que a observação apenas a partir da aplicação.

Diferenciando carga de trabalho e problemas arquiteturais

Uma aplicação pode apresentar um desempenho ruim devido a má configuração do software (Framework, Sistema Operacional) quanto no hardware, assim como na sua arquitetura e implementação. No entanto, uma aplicação também pode ter um desempenho ruim simplesmente por estar submetida a uma carga de trabalho excessiva, resultando em filas de espera e altas latências.

Se a análise da arquitetura mostrar muito enfileiramento, mas não identificar problemas na execução dessas tarefas enfileiradas, o problema pode ser a carga excessiva aplicada, este é o momento de adicionar mais instâncias/servidores/VMs para lidar com o aumento dessa carga.

Já um problema de arquitetura pode ser uma aplicação single-thread e está constantemente utilizando a CPU, com requisições enfileirando enquanto outras CPUs estão ociosas. Nesse caso, o desempenho é limitado pela arquitetura single-thread da aplicação. Outro exemplo de problema de arquitetura pode ser uma aplicação multi-thread que disputa um único bloqueio, de forma que apenas uma thread consegue avançar enquanto as outras aguardam.

Por outro lado, um problema de carga de trabalho pode ser uma aplicação multi-thread que está utilizando todas as CPUs disponíveis. Nesse caso, o desempenho é limitado pela capacidade de CPU disponível, ou seja, há mais carga de trabalho do que as CPUs conseguem processar.

Escalabilidade

A imagem acima apresenta um perfil típico de throughput conforme a carga de trabalho do sistema cresce. Inicialmente, se observa uma escalabilidade linear, onde o throughput aumenta proporcionalmente à carga. No entanto, chega um ponto (marcado pela uma linha pontilhada), onde a contenção por um recurso começa a degradar o throughput. Esse ponto é chamado de knee point, representando a transição entre duas funções. Além desse ponto, o throughput deixa de escalar linearmente devido ao aumento da contenção pelo recurso, e eventualmente, os custos adicionais de contenção e coerência fazem com que menos requisições sejam atendidas, resultando assim em uma diminuição do throughput. Esse ponto de saturação pode ocorrer quando um componente atinge 100% de utilização ou quando a utilização se aproxima de 100%, e as filas de espera começam a se tornar frequentes e significativas.

A degradação do desempenho em uma escalabilidade não linear, em termos de tempo de resposta médio ou latência, é representada na imagem abaixo.

Obviamente, tempos de resposta mais altos são indesejáveis. O perfil de degradação "rápida" pode ocorrer com ao utilizar muita memória, quando o sistema começa a mover páginas de memória para o disco para liberar a memória principal, ou seja, o sistema começa a “swapar”. Já o perfil de degradação "lenta" pode ocorrer ao utilizar mais CPU. Outro exemplo de degradação "rápida" é utilização de I/O do disco. À medida que a carga (e a consequente utilização do disco) aumenta, operações de I/O começarão a ser enfileiradas. A escalabilidade linear do tempo de resposta pode ocorrer se a aplicação começar a retornar erros quando os recursos não estiverem disponíveis ao invés de enfileirar mais operações.

Métricas

Métricas de desempenho (ou performance), são estatísticas geradas pelo sistema, aplicações ou ferramentas adicionais que medem suas atividades. Elas são observadas para análise e monitoramento de desempenho, através da linha de comando (CLI) ou de modo gráfico (GUI).

Alguns tipos de métricas de desempenho de sistemas:

• Throughput (Taxa de Transferência): Pode ser medido em operações ou volume de dados por segundo;

• IOPS (Operações de I/O por Segundo): Mede apenas operações de input/ouput (leituras e escritas);

• Utilização: Indica o quão ocupado está um recurso, geralmente expresso em porcentagem;

• Latência: Tempo de operação, apresentado como média ou percentil.

O throughput depende do contexto, por exemplo, o throughput de um banco de dados geralmente mede a quantidade de queries ou requisições por segundo, enquanto o throughput de rede mede o volume de bits ou bytes por segundo.

As métricas de desempenho não são “gratuitas”, em algum momento, ciclos de CPU devem ser gastos para coletá-las. Isso gera sobrecarga, que pode afetar o desempenho do que está sendo medido ou monitorado.

Utilização

O termo utilização é frequentemente utilizado em sistemas operacionais para descrever o uso de dispositivos, como CPU e discos. A utilização pode ser baseada no tempo ou na capacidade.

Utilização Baseada no Tempo

A utilização baseada no tempo é definida na teoria das filas, onde a média do tempo que o servidor ou recurso esteve ocupado, junto com a razão U = B/T.

Onde U é a utilização e B é o tempo total que o sistema esteve ocupado durante T, o período de observação.

Esta é também a definição de utilização mais comum disponível nas ferramentas de monitoração disponíveis em sistemas operacionais, como por exemplo, o iostat que denomina essa métrica como %b (percent busy).

Esta métrica de utilização indica quão ocupado está um componente. Quando um componente se aproxima de 100% de utilização, o desempenho pode degradar seriamente devido à contenção pelo recurso. Nessa caso, outras métricas podem ser verificadas para confirmar se o componente se tornou um gargalo no sistema.

Alguns componentes podem atender múltiplas operações em paralelo. Para esses, o desempenho pode não degradar mesmo com 100% de utilização, pois eles podem aceitar mais carga de trabalho. Um exemplo para ilustrar melhor seria um ônibus que está em constante operação, seguindo sua rota sem interrupções. O ônibus está sendo utilizado a 100% em termos de movimento, pois está sempre em serviço. No entanto, mesmo estando continuamente em operação, ele pode aceitar mais passageiros a cada parada. Isso significa que, apesar de estar a 100% de utilização em termos de atividade, ainda há capacidade adicional para transportar mais pessoas.

Um disco que está 100% ocupado também pode aceitar e processar mais cargas de trabalho, por exemplo, armazenando gravações no cache do disco para serem concluídas posteriormente. Um outro exemplo, arrays de disco frequentemente operam a 100% de utilização porque provavelmente algum disco está ocupado o tempo todo, mas o array possui discos ociosos suficientes para aceitar mais trabalho.

Utilização Baseada na Capacidade

Essa definição de utilização é usada no contexto de planejamento de capacidade, onde um sistema ou componente é capaz de entregar uma certa quantidade de taxa de transferência. Em qualquer nível de desempenho, o sistema ou componente está operando em alguma proporção de sua capacidade. Essa proporção é chamada de utilização.

Esta definição de utilização é em termos de capacidade, ao invés de se basear no tempo, isso implica que um disco com 100% de utilização não pode aceitar mais trabalho. Com a definição baseada no tempo, 100% de utilização apenas significa que ele está ocupado 100% do tempo, mas não necessariamente que está operando em sua capacidade máxima.

Para o exemplo anterior do ônibus, 100% de capacidade pode significar que o ônibus está cheio e não pode aceitar mais passageiros.

Saturação

A saturação se refere ao grau em que mais carga de trabalho é solicitado a um recurso do que ele pode processar. A saturação começa a ocorrer quando a utilização atinge 100% (baseada na capacidade), pois a carga de trabalho extra não pode ser processada imediatamente e começa enfileirar.

A figura acima mostra que a saturação aumenta de forma linear além da marca de 100% de utilização baseada na capacidade à medida que a carga continua a crescer. Qualquer grau de saturação representa um problema de performance, já que o tempo é gasto aguardando, ou seja, aumentando a latência.

Para a utilização baseada no tempo (percentual de ocupação), a formação de filas e, consequentemente, a saturação podem não iniciar exatamente na marca de 100% de utilização. Isso vai depender do quanto o recurso pode processar tarefas em paralelo.

Imagine um servidor de banco de dados configurado para processar até 200 queries por segundo (100% de capacidade). Se a demanda aumentar para 250 queries por segundo, as 50 queries adicionais não poderão ser processadas imediatamente e começarão a se acumular em uma fila, resultando em saturação. Isso causa aumento na latência, pois as consultas adicionais precisam esperar para serem processadas.

Por outro lado, considere um servidor que pode processar múltiplas requests em paralelo devido a múltiplos núcleos de CPU. Mesmo quando a utilização baseada no tempo atinge 100%, ele pode continuar a aceitar novas requests sem um aumento significativo na latência, desde que consiga gerenciar eficientemente o processamento de forma paralela.

Profiling

O profiling é o processo de coleta e análise de dados sobre o comportamento de um sistema ou aplicação para construir um modelo detalhado de desempenho. permitindo identificar gargalos com intuito de otimizar a performance. Ele é normalmente realizado por meio de amostragem periódica do estado do sistema em intervalos de tempo definidos. Isso envolve a captura de informações como registros de utilização de CPU, memória ou atividades de I/O, que, quando agregadas, fornecem insights sobre o funcionamento do sistema ao longo do tempo.

Diferentemente de métricas como IOPS e throughput, que fornecem medidas quantitativas específicas, o uso de amostragem no profiling oferece uma visão mais abrangente das atividades e interações dentro do sistema. A granularidade e o detalhamento das informações obtidas dependem diretamente da taxa de amostragem: taxas mais altas permitem uma resolução temporal mais fina e detalhes mais precisos, enquanto taxas mais baixas reduzem a sobrecarga no sistema, mas podem perder eventos transitórios importantes.

Por exemplo, para compreender detalhadamente o uso da CPU, pode-se realizar uma amostra do ponteiro de instrução (instruction pointer) ou capturar stack traces em intervalos de tempo frequentes. Ao registrar onde a CPU está executando essas instruções, é possível entender quais funções ou trechos de código consomem mais recursos computacionais.

Caching

Cache é frequentemente utilizado para melhorar o desempenho. Um cache armazena resultados de uma camada de armazenamento mais lenta em uma camada mais rápida, para ser utilizado posteriormente. Um bom exemplo disso é o armazenamento em cache de blocos de disco na memória RAM.

Uma métrica para entender o desempenho do cache é a taxa de acertos (hit rate) de cada cache. O número de vezes que os dados necessários foram encontrados no cache (hits) versus o total de acessos (hits + misses):

Taxa de Hits = hits / (hits + misses)

Quanto maior, melhor, pois uma taxa mais alta reflete mais dados acessados com sucesso a partir de mídias mais rápidas. A imagem abaixo ilustra a melhoria de desempenho esperada para o aumento da taxa de hits do cache.

Alguns exemplos de cache:

1. Cache de CPU: As CPUs utilizam múltiplos níveis de cache (L1, L2, L3) para acelerar o acesso à memória principal. O cache L1 é extremamente rápido, mas pequeno, enquanto o L3 é maior e mais lento. Isso permite que a CPU acesse dados rapidamente sem precisar acessar a memória principal constantemente.

2. Cache de disco na RAM: Um sistema operacional pode armazenar blocos de disco frequentemente acessados na memória RAM. Isso reduz o tempo de acesso aos dados, já que a RAM é bem mais rápida que os discos.

3. Cache de Aplicação: Aplicações web normalmente utilizam caches em memória, como o Redis ou Memcached, para armazenar resultados de queries do banco de dados. Isso diminui a necessidade de acesso ao banco de dados, melhorando a velocidade de resposta da aplicação.

Quero entrar mais a fundo sobre caches em um próximo artigo, onde vou abordar alguns algoritmos como MRU, LRU, LFU e também sobre caches Hot, Warm e Cold.

A dificuldade de identificar os riscos

A noção de “conhecidos-conhecidos”, “conhecidos-desconhecidos” e “desconhecidos-desconhecidos”, é bem importante para o campo de desempenho. De início pode parecer confuso, mas vamos aos exemplos:

Conhecidos-Conhecidos

São coisas que você sabe. Você sabe que deve verificar uma métrica de desempenho e também conhece seu valor atual, por exemplo, você sabe que deve monitorar a utilização da CPU e também sabe que o valor está, em média, em 10%.

Conhecidos-Desconhecidos

São coisas que você sabe que não sabe. Você sabe que pode verificar uma métrica ou a existência de um subsistema, mas ainda não o observou, por exemplo, Você sabe que pode usar profiling para verificar o que está consumindo a CPU, mas ainda não realizou essa verificação.

Desconhecidos-Desconhecidos

São coisas que você não sabe que não sabe. Você não tem conhecimento de certos aspectos que podem impactar o desempenho, então não os está verificando. Exemplo, você pode não saber que interrupções de dispositivos (como uma placa de rede de alta velocidade) podem se tornar grandes consumidoras de CPU, portanto, não está monitorando esse ponto.

Existe uma afirmação que é "quanto mais você sabe, mais você descobre que não sabe.", e isso é verdade! À medida que você aprende mais sobre os sistemas, você se torna ciente de mais desconhecidos-desconhecidos, que então se tornam conhecidos-desconhecidos que você pode começar a verificar.

Quando parar de analisar

Analisar o desempenho de um sistema pode ser desafiador, especialmente quando não se sabe quando parar. Com tantas ferramentas e aspectos a serem examinados, é comum se perguntar qual é a abordagem correta.

Existem três cenários onde pode ser apropriado encerrar a análise de desempenho:

• Primeiro, quando a maior parte do problema já foi explicado. Por exemplo, se uma aplicação estava utilizando três vezes mais CPU do que o esperado e, ao investigar, descobre-se que chamadas de API mal otimizadas estão consumindo 60% do tempo de execução, você já possui uma parte significativa do problema. Nesse caso, é possível interromper a análise, corrigir o que foi descoberto e reavaliar o sistema após as mudanças;

• Segundo, quando o retorno sobre o investimento (ROI) potencial é menor que o custo da análise. Problemas que podem economizar milhões anuais justificam meses de análise, enquanto questões menores que geram retornos de centenas de dólares podem não valer o tempo investido.

• Terceiro, quando há oportunidades de ROI maiores em outras áreas, priorizando assim onde focar os esforços;

Concluindo

Acredito que isso é tudo que tenho para compartilhar a respeito de conceitos. A ideia inicial era trazer mais alguns pontos como perspectivas de análises, mas o artigo ficaria bem maior do que já está. Então resolvi fazer um resumão para preparar vocês para que nos próximos artigos possamos nos aprofundar mais em metodologias.

Até mais!

Essa é a primeira parte de uma série de posts sobre performance de sistemas, um tópico que sempre chamou minha atenção e algo que tenho estudado bastante nos últimos tempos.

A ideia desse primeiro artigo é trazer uma introdução ao tema, falar um pouco sobre onde SRE se encaixa nisso, os desafios e observabilidade.

Performance de Sistemas

Quando falamos sobre performance de sistemas, precisamos ter em mente que a disciplina contempla todos os componentes de um computador, ou seja, hardware e software, até mesmo tudo que está no fluxo de dados como dispositivos de armazenamento até a aplicação. Em sistemas distribuídos, essa abrangência inclui vários servidores e serviços replicados.

Como uma boa prática é interessante ter um diagrama do seu ambiente mostrando tudo isso, se você não tem ainda, pode ser uma ótima hora para começar agora, desta forma será mais fácil compreender as conexões ou relacionamentos entre os componentes e garantir que você tenha a visão do todo.

Ao final do dia, será possível entender a performance de sistemas e garantir uma melhor experiência para o usuário final. Seja reduzindo latência, custo de processamento, otimização de queries, e redução de saltos na rede.

A figura abaixo mostra uma stack super simples de um aplicação rodando em um único servidor.

Atividades e papéis

A análise de performance de sistemas envolve uma série de atividades que podem (e devem) ser feitas por diversos profissionais de forma holística, independente de suas funções e especialidades, pois a composição de sistemas complexos necessita de integração contínua e colaborativa de diversas disciplinas. Equipes compostas por pessoas SysAdmin, SREs, SWEs, analistas de rede, DBAs são um bom exemplo de equipes multidisciplinares. O ideal é que a análise de performance seja apenas uma parte do dia a dia de trabalho das equipes, podendo atuarem também, de forma mais eficaz na maioria dos casos. Entretanto, existem empresas que contratam pessoas focadas em performance com intuito de criar ferramentas e auxiliar outros times com análises.

No mundo perfeito, sabemos que pensar em performance deveria ser algo inicial, antes mesmo da primeira linha de código, porém, grande parte desse processo é realizado posteriormente, quando o produto já está em produção ou quando um problema surge. No entanto, realizar testes e análises de performance em produção não é errado e pra isso que servem as Feature Flags, Canary Releases e Blue-Green deployments, o que nos permite controlar melhor como uma nova feature é enviada para produção e se necessário, realizar rollback para uma versão mais estável.

É possível também realizar capacity planning (planejamento de capacidade), que não se limita apenas ao hardware e software de forma isolada, as iniciativas mais eficientes desse tipo de ação são as que levam em conta a revisão de uma arquitetura de solução por completo para atender as expectativas de uso, sejam eles focados em otimização de uso intensivo ou para expectativas de negócio.

A análise de performance em produção pode envolver SREs, geralmente seguido incident reviews ou durante a escrita de postmortems, com intuito de analisar o que aconteceu, compartilhar métodos para “debugar” o problema e encontrar maneiras de prevenir incidentes no futuro. Uma boa dica aqui, é utilizar a técnica dos 5 Whys (5 porquês), onde através da aplicação de questionamentos é possível que o time encontre a causa raíz do incidente. Claro que cada empresa tem suas peculiaridades no papel do SRE, mas o correto é que alguém que esteja na frente de resiliência participe dessas análises, seja ele um SRE ou SWE.

Desafios

A análise (ou engenharia) de desempenho de sistemas é desafiadora em alguns momentos por ser subjetiva, complexa e muitas vezes envolver múltiplos problemas sem uma causa raiz clara.

Diferente de outras disciplinas, questões de desempenho podem ser difíceis de identificar e resolver, principalmente classficá-los como "bom" ou "ruim" sem metas claras. Além disso, a complexidade dos sistemas e das interações entre seus componentes torna difícil identificar e solucionar problemas de desempenho, que podem não se manifestar de maneira reproduzível em ambientes que não sejam produtivos.

Problemas de desempenho podem também podem ter múltiplas causas, onde eventos normais ocorrem simultaneamente e juntos podem criar um problema. Além disso, em sistemas mais complexos, não é raro haver vários problemas de performance simultâneas. O desafio não é tanto encontrar um problema, mas identificar quais problemas são os mais importantes. Sim, é complexo.

Para isso, a pessoa responsável pela análise deve tentar quantificar a gravidade dos problemas e estimar o potencial de melhoria, ajudando a justificar a alocação de recursos para sua resolução. E um ótimo indicador para essa quantificação, é a latência.

Latência

Latência é a medida do tempo que um sistema leva para responder a uma solicitação e é uma métrica super essencial. Por exemplo, o tempo de um clique em um site até o carregamento total da página.

Sabe aquela ideia que é melhor retornar um erro 500 do que deixar o usuário esperando? Pois é, a latência alta pode causar até perda de clientes. Além disso, a latência permite estimar o potencial de melhoria do desempenho, quantificando o impacto de fatores como leituras de disco em uma operação e indicando onde aprimoramentos podem ser realizados para aumentar a velocidade. Vamos para um exemplo:

Na imagem acima, temos uma query que leva 200ms para ser executada (isso é a latência), no qual 180ms foi só de espera para leitura de disco. Eliminando a leitura de disco, por meio de estratégias como cache, é possível reduzir o tempo de execução de 200ms para 20ms, ou seja, tornar a operação 10 vezes mais rápida

Ao contrário de outras métricas, como operações de I/O por segundo (IOPS), a latência permite estimar com clareza o impacto de mudanças no desempenho. Contudo, a latência pode ser ambígua sem qualificadores e quantitativos. Por exemplo, em redes, ela pode se referir ao tempo necessário para estabelecer uma conexão entre uma origem e um destino, ou à duração total de uma conexão considerando todo tempo de processamento até uma resposta conclusiva da operação. Tendo isso em mente, a latência nem sempre está disponível em todos os pontos do sistema. É onde entra o eBPF, permitindo medir a latência de forma mais “customizada” e ao mesmo tempo fornecendo dados detalhados sobre sua distribuição.

Observabilidade

Observabilidade é uma prática de entendimento do comportamento de um sistema por meio de observação, utilizando ferramentas como contadores, profiling e tracing. Vale ressaltar que ferramentas de load test ou stress test, que alteram o estado do sistema não são consideradas ferramentas de observabilidade. O motivo é simples, elas criam um tipo de workload com finalidade de experimentação. Em ambientes produtivos, é recomendável utilizar ferramentas de observabilidade ao invés de ferramentas de experimentação e em ambientes de teste inativos, essas ferramentas podem ser utilizadas para avaliar o desempenho do hardware.

Aplicações e o kernel geralmente fornecem dados sobre seu estado e suas atividades, como contagem de operações, bytes, medições de latência, utilização de recursos e taxas de erro. Esses dados são geralmente implementados como variáveis do tipo inteiro chamados counters (contadores), que são inseridas nas aplicações e algumas delas acumulam valores de forma contínua, o que permite lê-los em vários momentos para análise de performance e desempenho.

No exemplo abaixo, vemos o utilitário vmstat, que mostra um resumo de estatísticas da memória virtual baseadas nos contadores do kernel presentes no /proc. Abordarei o vmstat com mais detalhes nos próximos posts.

Em observabilidade, o termo profiling geralmente se refere ao uso de ferramentas que realizam amostragem, coletando um subconjunto de medições para criar uma visão geral do sistema. Por exemplo, CPU é um recurso comum para profiling, onde a análise é feita de forma frequente através de amostragens em intervalos de tempo durante a execução da aplicação. Uma visualização eficaz dessas amostragens são os flame graphs, que ajudam a identificar problemas de desempenho não apenas relacionados à CPU, mas também a outros aspectos como problemas de memória ao analisar o tempo de CPU em funções de alocação de memória.

Já o termo tracing se refere a um registro baseado em eventos, onde esses dados são capturados e armazenados para análise posterior ou processados em tempo. Existem ferramentas específicas para captura de traces de syscalls como o strace e o tcpdump. Essas ferramentas utilizam várias fontes para capturar os eventos, incluindo instrumentação dinâmica e estática, além da utilização do eBPF.

A instrumentação estática refere-se a pontos de instrumentação adicionados diretamente ao código-fonte da aplicação. No kernel do Linux, existem vários desses pontos que monitoram operações como I/O do disco, eventos do scheduler, syscalls e entre outros. Para software em espaço de usuário, existe uma tecnologia semelhante chamada USDT (User Statically Defined Tracing). O USDT é utilizado por bibliotecas (como a libc) para instrumentar chamadas de biblioteca e por muitas aplicações para instrumentar requisições de serviço. Já a instrumentação dinâmica, cria pontos de instrumentação enquanto o aplicação está em execução, modificando instruções na memória para inserir rotinas de instrumentação. Isso permite gerar estatísticas de desempenho em qualquer aplicação.

Finalizando

Essa foi a primeira parte de uma série de posts sobre performance de sistemas. O intuito foi dar uma introdução ao tema, abordar os principais termos e ferramentas para que possamos nos aprofundar sobre metodologias, capacity planning e benchmarking nos próximos posts.

Se você curtiu essa primeira parte, compartilhe esse post com seus colegas de trabalho e em redes sociais. Feedbacks são sempre muito bem vindos também!

Até mais. :)

Imagine você, como Engenheiro/a DevOps ou Engenheiro/a de Software, como você mediria seu desempenho, do seu time ou da engenharia como um todo? Existe algum framework ou método para isso? A resposta é “sim”, como o SPACE e o DevEx, mas o framework que vou abordar hoje é o DORA Metrics.

Medir a eficácia das práticas de DevOps vai além de apenas implementar CI/CD e afirmar que se está praticando DevOps. As DORA Metrics, desenvolvidas pela DevOps Research and Assessment, são fundamentais para obter uma visão precisa e baseada em dados sobre o desempenho de entrega de software. Elas se concentram em quatro métricas principais que revelam o desempenho real das equipes de engenharia, destacando de forma clara as áreas que precisam de melhorias. Com essas métricas, você consegue ir direto ao ponto, identificando gargalos e oportunidades para otimizar processos e entregar mais valor.

Além disso, as DORA Metrics podem ser alinhadas com os objetivos estratégicos da empresa, garantindo que as práticas de DevOps estejam em sintonia com as metas de negócio. Por exemplo, ao melhorar a Frequência de Deploys e reduzir o tempo médio de recuperação de um incidente, a empresa pode acelerar o tempo de lançamento de novos produtos no mercado e consequentemente aumentando sua competitividade e satisfação do cliente.

As quatro métricas

Entendido o que são as DORA Metrics, vamos passar por cada uma delas e dar mais contexto:

Deployment Frequency

Deployment Frequency mede quantas vezes novas versões de código sobem para produção em um determinado período. É um indicador que mede a agilidade da equipe de desenvolvimento e da capacidade de entregar valor continuamente aos usuários e ao negócio. Ou seja, uma alta frequência de deploy corresponde a equipes que respondem rapidamente a feedbacks (feedback loops) e mudanças nas regras de negócios.

Para medir, basta calcular o número de deploys realizados em um período específico, como por dia ou semana. Um processo importante, que minimiza dependências e “burocracias” no processo de deploy e que já é bem difundido é o CI/CD. Vale ressaltar que CI/CD não é ter um Jenkins ou GitHub Actions rodando, CI/CD é de fato o processo contínuo e sem intervenções manuais para rodar uma suíte de testes, processo de build e deploy.

Lead Time for Changes

Mede o tempo que leva desde o commit inicial até o deploy para produção. Essa métrica reflete a eficiência das pipelines, fluxos de desenvolvimento e a capacidade e velocidade de entregar valor.

Diferente do deployment frequency, a ideia é ter essa métrica com indicadores baixos, ou seja, subir pequenas alterações para produção e com mais frequência. A utilização de metodologias ágeis, também ajuda muito no processo.

Mean Time to Recovery ou MTTR

O MTTR mede o tempo médio que um time leva para recuperar um sistema após uma falha em produção. É um indicador da resiliência e estabilidade do sistema. Adotar práticas SRE, como a criação de playbooks para incidentes, observabilidade, e chaos engineering, pode melhorar significativamente o MTTR.

Ter um bom processo de gerenciamento de incidentes, com revisão de post-mortems e ferramentas que alertem a qualquer comportamento anômalo e que possam indicar uma possível falha, ajudam na identificação de melhorias e recuperação/correção mais rápida.

Change Failure Rate

Mede a porcentagem de deploys que resultam em falhas em produção. É um indicador importante para avaliar a qualidade do processo de desenvolvimento e a estabilidade do sistema.

Implementar suíte de testes automatizados, realizar revisões de código de forma mais regular e utilizar pipelines de CI/CD para validação contínua são métodos eficazes para reduzir a taxa de falhas.

Como implementar

A maior parte das ferramentas de CI/CD e observabilidade atualmente conseguem demonstrar os indicadores das quatro métricas. Por exemplo, a Datadog possui em beta uma funcionalidade para extração e análise, a Harness tem algo um pouco mais sólido, porém mais simples. Já o GitLab oferece uma análise bem mais completa, porém apenas no plano Ultimate.

Porém, ambas soluções são pagas e isso vai muito da ferramenta que você utiliza, por isso, recomendo uma ferramenta que tenho estudado há algumas semanas, o Apache DevLake. Nela, é possível plugar várias soluções de mercado e centralizar a extração e visualização de métricas em um só lugar. Outro ponto bem positivo, é que caso na sua empresa seja utilizado alguma ferramenta desenvolvida internamente, o DevLake aceita Webhooks.

Além das quatro métricas, o DevLake consolida várias outras adicionais, como tamanho das Pull Requests, duração dos builds, linhas adicionadas ou deletadas em um commit e por aí vai.

Obviamente, que conseguir integrar a medição das métricas no dia a dia, requer práticas e processos bem definidos. Uma dica é incorporar revisar essas métricas durante as dailies ou em retrospectivas. Criar uma dashboard para que todo time possa acompanhar as métricas pode aumentar a transparência e incentivar a responsabilidade compartilhada.

Estabilidade e Velocidade

Todo mundo quer uma baixa taxa de erros e que sistemas sejam restaurados rapidamente em caso de falha, é uma verdade que todo mundo também quer colocar features de forma mais rápida em produção. E inicialmente, parece que há uma divergência entre elas, certo? Se o time colocar mais features em produção sem bons testes ou controle de qualidade, a taxa de erros pode aumentar.

Algo muito importante, é que observabilidade vai muito de encontro com o tema. Quando há um incidente em produção, é possível entender de forma mais rápida, o problema olhando para qual foi a mudança. Com um lead time mais curto, a compreensão da mudança é mais fácil e consequentemente, sabemos qual é o problema. Ou seja, entender a causa raíz reduz o MTTR, que também reduz a taxa de falhas em mudanças (Change Failure Rate).

O contexto e os recursos são importantes nesses momentos. Porém, essas quatro métricas se influenciam mutuamente e muitas vezes ajudam dar insights que seriam mais difíceis de compreender de outra forma. Analisar essa “dualidade” entre velocidade e estabilidade é uma abordagem eficaz para avaliar o desempenho das práticas DevOps.

Vou deixar alguns livros que recomendo demais para quem quer se aventurar mais na melhoria de fluxo de entrega de software e DevOps.

• Accelerate: The Science of Lean Software and DevOps (Versão Kindle)

• The DevOps Handbook (Versão Kindle)

• Measuring Continuous Delivery

• Observability Engineering (Versão Kindle)

Boa leitura e até a próxima.