Resumo Executivo

Julio Cesar Ferreira Leão; João Choma Neto

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

A transição de arquiteturas monolíticas para modelos baseados em microsserviços representa um marco na engenharia de software contemporânea, impulsionada pela necessidade de maior agilidade, escalabilidade e resiliência no desenvolvimento de sistemas complexos. Conforme apontam Fowler e Lewis (2014), a abordagem de microsserviços decompõe uma aplicação em um conjunto de serviços pequenos e independentes, cada um executando um processo próprio e comunicando-se por meio de mecanismos leves, geralmente APIs HTTP. Essa modularização permite que as organizações reduzam o acoplamento entre componentes, aumentem a capacidade de inovação paralela e facilitem a evolução incremental de partes específicas do sistema sem comprometer a integridade do todo (Newman, 2021). No entanto, a adoção dessa arquitetura introduz desafios operacionais significativos, exigindo um rigor elevado sobre a orquestração de contêineres e a observabilidade do ambiente distribuído. Richards (2020) destaca que, em contrapartida aos benefícios de autonomia das equipes, cresce a complexidade na gestão de falhas e na manutenção da performance sob carga variável. Nesse cenário, a escalabilidade horizontal torna-se um requisito central, permitindo que o sistema responda a picos de demanda por meio da replicação de instâncias e da distribuição eficiente de carga.

A resiliência em sistemas distribuídos é outro pilar fundamental, visto que falhas de rede, hardware e software são inevitáveis em ambientes de larga escala. Para mitigar a indisponibilidade percebida pelos usuários, práticas de engenharia de confiabilidade tornam-se indispensáveis. Newman (2021) enfatiza que a utilização de mecanismos automáticos de verificação de saúde, conhecidos como probes, e políticas de reinicialização automática de instâncias com falhas são essenciais para sustentar a disponibilidade. A literatura sobre o tema frequentemente recorre à simulação de falhas para avaliar a robustez da arquitetura, um conceito popularizado por ferramentas de engenharia do caos que encerram instâncias aleatoriamente para verificar a capacidade de autorrecuperação da aplicação (Netflix, 2011). Complementarmente, a observabilidade surge como uma evolução do monitoramento tradicional, abrangendo a coleta e a análise integrada de métricas, logs e traços distribuídos. Segundo Turnbull (2018), a observabilidade permite que as equipes não apenas detectem incidentes rapidamente, mas identifiquem as causas raízes em ambientes complexos, reduzindo o tempo médio de detecção e de recuperação.

O Kubernetes consolidou-se como o padrão de fato para a orquestração de contêineres, oferecendo recursos nativos para implantação, replicação e balanceamento de carga. Seus mecanismos de controle, como os ReplicaSets e o Horizontal Pod Autoscaler, possibilitam que os serviços escalem horizontalmente de forma automatizada com base no consumo de recursos como CPU e memória (Kubernetes Documentation). Além disso, a integração com plataformas de observabilidade como o Datadog permite consolidar a telemetria em painéis unificados, correlacionando métricas de infraestrutura com eventos de aplicação. Diante desses avanços, torna-se imperativo investigar como as decisões de orquestração e as estratégias de monitoramento impactam o comportamento de microsserviços em cenários práticos. O objetivo da implementação realizada foi demonstrar, de forma aplicada, como a escolha de ferramentas e a configuração de parâmetros de infraestrutura influenciam métricas de desempenho, como latência e throughput, e indicadores de resiliência sob diferentes perfis de carga e falhas controladas.

A metodologia adotada para a execução dos experimentos baseou-se na construção de um ambiente de microsserviços utilizando o framework FastAPI, em linguagem Python, escolhido por sua alta performance e suporte nativo a operações assíncronas. A arquitetura foi desenhada para ser executada em um cluster local de Kubernetes, utilizando a ferramenta kind para a criação dos nós. Cada microsserviço foi desenvolvido com endpoints específicos para simular diferentes tipos de carga de trabalho: uma rota de verificação de saúde simples, um endpoint para simulação de processamento intensivo de CPU e uma rota para operações de entrada e saída com espera controlada. A containerização foi realizada via Docker, garantindo que as dependências e o ambiente de execução fossem isolados e portáveis. O arquivo de definição da imagem utilizou uma base leve de Python 3.11-slim, otimizando o tempo de build e o tamanho final da imagem para facilitar o deploy no cluster.

Para a orquestração, foram elaborados manifestos YAML detalhados que definiram os objetos de Deployment, Service e Ingress. No manifesto de Deployment, estabeleceram-se limites rigorosos de recursos para cada pod, fixando o consumo de CPU em 500 mcores e a memória em 256 MiB como valores de requisição inicial, com limites máximos de 1000 mcores e 512 MiB. A configuração de probes de saúde foi um passo crítico na metodologia: o livenessProbe foi configurado para verificar se o processo da aplicação permanecia ativo, reiniciando o contêiner em caso de falha, enquanto o readinessProbe foi ajustado para garantir que o tráfego só fosse direcionado ao pod após a conclusão do seu processo de inicialização e aquecimento. O balanceamento de carga interno foi gerenciado pelo objeto Service do Kubernetes, e a exposição externa do serviço foi realizada através de um controlador Ingress Nginx, permitindo o acesso aos endpoints a partir da máquina local.

A estratégia de observabilidade foi centralizada no Datadog, exigindo a implantação de um agente específico dentro do cluster Kubernetes. Este agente foi configurado via DaemonSet para coletar métricas de performance dos nós, logs estruturados dos contêineres e traços de execução distribuídos através da biblioteca ddtrace. A instrumentação da aplicação FastAPI incluiu a integração de middlewares para capturar o tempo de resposta de cada requisição e exportar métricas no formato Prometheus, que foram posteriormente consumidas pelo Datadog. Painéis de controle customizados foram criados para visualizar, em tempo real, a latência média, os percentis de cauda (p95 e p99), a taxa de erro por minuto, o consumo de CPU por pod e o número de réplicas ativas. Essa infraestrutura de monitoramento permitiu a correlação direta entre os eventos de carga gerados e o comportamento da infraestrutura.

A geração de carga foi executada com a ferramenta k6, utilizando scripts em JavaScript para definir cinco cenários experimentais distintos. O primeiro cenário, de carga baixa, consistiu no envio de 20 requisições por segundo durante cinco minutos, estabelecendo uma linha de base para o desempenho do sistema. O segundo cenário elevou a carga para 60 requisições por segundo por 10 minutos, simulando um regime de utilização média. O terceiro cenário, focado em estresse, aumentou a demanda para uma faixa entre 200 e 500 requisições por segundo, visando identificar o ponto de saturação do serviço. O quarto cenário envolveu a simulação de falhas através da deleção manual de pods durante a execução de uma carga média, para avaliar a capacidade de autorrecuperação do Kubernetes e o impacto na latência durante a transição. Por fim, o quinto cenário testou a escalabilidade horizontal, adicionando réplicas extras ao deployment após o sistema atingir a saturação, observando a recuperação dos níveis de serviço.

Os dados coletados durante os testes foram exportados pelo k6 em formatos JSON e CSV, contendo o registro temporal de cada requisição. O procedimento de análise envolveu o alinhamento das janelas temporais dos relatórios do k6 com os gráficos de telemetria do Datadog. Para cada cenário, foram consolidadas tabelas comparativas e analisados os logs para identificar possíveis gargalos ou erros de execução. A reprodutibilidade do estudo foi garantida pela disponibilização de todos os scripts de teste, manifestos de infraestrutura e arquivos de configuração em um repositório público, permitindo que outros pesquisadores repliquem o ambiente e validem os resultados encontrados. A pesquisa seguiu preceitos éticos, utilizando apenas dados gerados sinteticamente em ambiente controlado, sem envolver informações de usuários reais ou dados sensíveis.

Os resultados obtidos no primeiro cenário, caracterizado por uma carga baixa de 19,99 requisições por segundo, revelaram um sistema operando em regime de estabilidade absoluta. A latência média registrada foi de 76,65 ms, com um p95 de 156,94 ms. A análise da telemetria no Datadog indicou que o consumo de CPU por pod variou entre 70 e 80 mcores, atingindo picos ocasionais de 132 mcores, o que representa apenas uma fração do limite estabelecido. O uso de memória manteve-se estável em aproximadamente 52 MiB. Esses dados confirmam que, sob baixa demanda, a aplicação possui uma sobra considerável de recursos, operando de forma confortável e sem pressão sobre o coletor de lixo ou sobre o loop de eventos do FastAPI. A ausência de erros HTTP e a estabilidade do working set de memória indicam uma configuração saudável do ambiente de execução.

No segundo cenário, ao elevar a carga para uma média de 59,97 requisições por segundo, observou-se uma manutenção eficiente da performance. Curiosamente, a latência média reduziu para 47,07 ms, enquanto o p95 permaneceu estável em 157,28 ms. Essa redução na latência média pode ser atribuída ao melhor aproveitamento dos workers do servidor Uvicorn e ao aquecimento dos caches internos da aplicação. O consumo de CPU subiu para uma faixa entre 0,3 e 0,4 cores por pod, demonstrando uma correlação linear entre o aumento do throughput e a utilização de processamento. A memória apresentou um crescimento suave, estabilizando-se novamente em torno de 52 MiB. Este comportamento sugere que o pool de conexões e o número de processos trabalhadores estavam adequadamente dimensionados para o padrão de requisições predominantemente voltado para operações de entrada e saída.

O cenário de estresse, com uma carga de aproximadamente 128,61 requisições por segundo direcionadas a um único pod, revelou o ponto crítico de saturação da arquitetura. A latência média sofreu um aumento drástico, atingindo 3239,47 ms, enquanto o p95 explodiu para 8125,02 ms. A análise detalhada no Datadog mostrou que o consumo de CPU atingiu o teto de 1,0 core em diversos momentos, com picos de até 1,02 cores. Conforme discutido por Nguyen et al. (2019), esse fenômeno de degradação abrupta é característico da contenção de recursos, onde a fila do loop de eventos cresce exponencialmente à medida que o processador não consegue dar vazão às requisições. Embora não tenham sido registrados erros HTTP explícitos de timeout no lado do servidor, a experiência do usuário foi severamente comprometida pela lentidão, evidenciando que o limite operacional de uma única instância foi superado.

A avaliação da resiliência no quarto cenário, que envolveu a queda forçada de pods durante uma carga de 60 requisições por segundo, demonstrou a eficácia dos mecanismos de orquestração do Kubernetes. Durante o evento de deleção, a latência média manteve-se em 51,55 ms e o p95 em 155,15 ms, valores muito próximos aos observados no regime de carga média estável. A combinação das probes de prontidão e saúde impediu que o tráfego fosse direcionado para instâncias que ainda estavam em processo de inicialização. O Kubernetes reprovisionou as instâncias automaticamente, mantendo a disponibilidade do serviço. Observou-se um leve aumento temporário no uso de memória para cerca de 73 MiB durante a transição, o que é esperado devido ao reuso de caches e carregamento de bibliotecas após um cold start, mas o sistema retornou rapidamente ao estado de equilíbrio.

No quinto e último cenário, a implementação da escalabilidade horizontal foi testada ao adicionar réplicas extras para processar uma carga de 119,95 requisições por segundo. Com a distribuição do tráfego entre múltiplos pods, a latência média retornou para o patamar de 50,53 ms e o p95 caiu drasticamente para 179,44 ms, comparado aos valores de segundos observados no teste de estresse com apenas uma instância. O throughput efetivo dobrou, validando que a arquitetura escala de forma eficiente quando recursos adicionais são disponibilizados. A análise dos gráficos de agregação no Datadog confirmou que, embora cada réplica individual estivesse operando abaixo do seu limite de saturação, a capacidade agregada do cluster foi capaz de sustentar o nível de serviço exigido, cumprindo os objetivos de desempenho estabelecidos.

A discussão dos resultados permite inferir que a explosão da cauda de latência observada no cenário de estresse não é um ruído estatístico, mas um efeito direto da contenção de CPU e das limitações do modelo de thread única do loop de eventos do Python sob carga extrema. Para mitigar esse comportamento em ambientes produtivos, Richards (2020) sugere que, além da escalabilidade horizontal, é fundamental implementar limites de taxa de requisição e mover tarefas intensivas de processamento para filas de trabalho em segundo plano. A utilização de ferramentas de observabilidade mostrou-se indispensável para identificar que o gargalo estava no processamento e não em vazamentos de memória, visto que o working set permaneceu estável durante todos os experimentos. A correlação entre as janelas de teste do k6 e as métricas de infraestrutura permitiu um diagnóstico preciso da causa raiz da degradação de performance.

A eficácia das probes de saúde configuradas no Kubernetes foi comprovada pela manutenção da disponibilidade durante a simulação de falhas. Sem a configuração adequada do readinessProbe, o balanceador de carga poderia ter enviado requisições para pods que ainda não haviam carregado suas dependências internas, resultando em erros de conexão para o cliente final. A prática de definir limites e requisições de recursos no manifesto de deployment, conforme recomendado pela documentação do Kubernetes, garantiu que o escalonador do cluster pudesse alocar os pods de forma previsível, evitando que uma única instância consumisse todos os recursos do nó e afetasse outros serviços. Esses achados reforçam a importância de uma configuração minuciosa da orquestração para garantir a resiliência operacional.

Apesar dos resultados positivos, é necessário reconhecer as limitações do estudo realizado. Os experimentos ocorreram em um ambiente controlado de cluster local, o que elimina variáveis comuns em produção, como a latência de rede variável, falhas de resolução de nomes e instabilidades de provedores de nuvem. Além disso, a carga gerada pelo k6 foi sintética e seguiu padrões previsíveis, diferindo da volatilidade do tráfego real de usuários. Pesquisas futuras poderiam expandir esta análise para ambientes de nuvem pública, incorporando pipelines de integração e entrega contínua para avaliar o impacto de novos deploys na estabilidade do sistema. A exploração de métricas customizadas para o escalonamento automático, baseadas em latência ou tamanho da fila de requisições em vez de apenas CPU, também representa um campo fértil para investigações adicionais.

A integração entre FastAPI, Kubernetes e Datadog demonstrou ser uma combinação robusta para a construção de sistemas modernos. A facilidade de instrumentação do FastAPI permitiu a exposição de métricas detalhadas com baixo esforço de desenvolvimento, enquanto a capacidade de agregação do Datadog transformou dados brutos em informações acionáveis para a tomada de decisão técnica. O estudo consolidou um guia prático que vai além da teoria, documentando como as escolhas arquiteturais se refletem diretamente nos indicadores de desempenho percebidos pelo usuário final. A observabilidade, quando bem implementada, deixa de ser um custo adicional e passa a ser um investimento na confiabilidade e na capacidade de evolução do software.

Conclui-se que o objetivo foi atingido, uma vez que a implementação demonstrou a viabilidade técnica de manter microsserviços estáveis e resilientes através da orquestração adequada e do monitoramento rigoroso. Os testes de carga e estresse evidenciaram os limites operacionais da arquitetura, enquanto a simulação de falhas e a escalabilidade horizontal validaram a capacidade de autorrecuperação e adaptação do sistema frente a demandas variáveis. A correlação entre métricas de infraestrutura e performance da aplicação permitiu identificar gargalos de CPU e confirmar a estabilidade do uso de memória, fornecendo um embasamento sólido para decisões de planejamento de capacidade. O estudo reforça que a resiliência em ambientes distribuídos não é um atributo estático, mas o resultado de uma configuração precisa de mecanismos de controle e de uma visibilidade profunda sobre o estado interno dos serviços.

Referências Bibliográficas:

FOWLER, M.; LEWIS, J. Microservices: a definition of this new architectural term. 2014. Disponível em: https://martinfowler.com/articles/microservices.html. Acesso em: 20 set. 2025.

KUBERNETES. Kubernetes Documentation. Disponível em: https://kubernetes.io/docs/. Acesso em: 20 set. 2025.

NETFLIX. Chaos Monkey. 2011. Disponível em: https://netflix.github.io/chaosmonkey/. Acesso em: 20 set. 2025.

NEWMAN, S. Building Microservices: Designing Fine-Grained Systems. 2. ed. Sebastopol: O’Reilly Media, 2021.

NGUYEN, T.; et al. Stress testing microservices: approaches and challenges. Proceedings of the 2019 IEEE International Conference on Software Architecture, 2019.

RICHARDS, M. Microservices vs. Monoliths. Sebastopol: O’Reilly Media, 2020.

TURNBULL, J. The Art of Monitoring. Turnbull Press, 2018.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy