Acervo original preservado
Este conteúdo histórico pode conter propostas ou instruções anteriores ao checkout atual. Consulte Arquitetura para o comportamento documentado e Tutoriais para as ressalvas operacionais.
Ambiente e limites da evidência histórica
Configurações e medições locais não comprovam ambientes corporativos. Propostas e menções históricas a produção não foram verificadas em DEV, STAGING ou PROD. Consulte Ambientes corporativos para o que está confirmado.
Estimativa Inicial de Capacidade e Custo de Processamento --- TOTVS Gateway¶
1. Objetivo¶
Estabelecer uma linha de base inicial de capacidade e custo de processamento do Gateway, utilizando os testes de carga executados até o momento.
Os valores deste documento são preliminares e serão refinados com novos testes, principalmente com políticas do Gateway habilitadas e com a validação individual da capacidade dos microserviços.
2. Ambiente considerado¶
Atualmente, no ambiente de produção, os quatro microserviços do fluxo possuem a seguinte configuração:
Microserviço CPU Memória
security-checker 800m 2048 MB broker 800m 2048 MB builder 800m 2048 MB router 800m 2048 MB
Custo mensal informado do ambiente: R\$ 4.170,26
3. Premissas do benchmark¶
Os testes utilizados nesta análise foram executados nas seguintes condições:
- duração de aproximadamente 5 minutos por execução;
- API target mockada;
- tempo de resposta da API target fixado em aproximadamente 250 ms;
- sem autenticação aplicada;
- sem IP Policy;
- sem Rate Limit;
- sem transformação de request ou response body;
- objetivo de identificar capacidade estável e comportamento dos componentes sob aumento de carga.
Por isso, o resultado atual deve ser interpretado como baseline do fluxo simplificado do Gateway, e não como capacidade definitiva do produto com todas as funcionalidades habilitadas.
Manter a API target mockada em 250 ms nos próximos testes permitirá comparar os cenários sem introduzir variações provenientes da aplicação destino.
4. Resultado de capacidade estável¶
Durante os testes com uma única réplica por serviço, foi identificada uma capacidade estável de aproximadamente:
37 requisições por segundo (RPS)
No teste de 37 RPS:
- aproximadamente 11.101 requisições foram processadas em 5 minutos;
- 0 requisições descartadas;
- 0% de falhas;
- p95 de aproximadamente 271 ms;
- p99 de aproximadamente 317 ms;
- mediana de aproximadamente 258 ms.
O primeiro limitante observado nesse cenário foi o builder, principalmente pelo consumo de memória, motivo pelo qual 37 RPS foi adotado como capacidade estável inicial para uma configuração sem escalabilidade adicional.
5. Teste de escalabilidade¶
Após identificar o builder como primeiro limitante, foram realizados testes permitindo sua escalabilidade para avaliar a capacidade dos demais componentes.
Em um dos testes posteriores, foi executada uma carga de:
100 RPS durante 5 minutos
Resultado do k6:
- 30.001 requisições processadas;
- throughput efetivo de aproximadamente 99,84 RPS;
- 0 requisições descartadas;
- 0% de falhas;
- p95 de aproximadamente 342 ms;
- p99 de aproximadamente 438 ms;
- média de aproximadamente 275 ms.
O teste demonstra que, permitindo o escalonamento do componente limitante, o fluxo consegue sustentar cargas significativamente superiores ao baseline de 37 RPS.
Entretanto, esse teste ainda não determina a capacidade máxima dos demais microserviços. A continuidade do aumento de carga foi interrompida por um problema no Ingress do cluster, que deverá ser corrigido antes da próxima etapa.
6. Estimativa inicial de custo¶
O ambiente utilizado como referência possui custo mensal informado de:
R\$ 4.170,26/mês
Considerando inicialmente a capacidade estável conservadora de 37 RPS, uma instância operando continuamente nessa taxa representaria aproximadamente:
95,9 milhões de requisições/mês
Cálculo:
37 RPS × 60 × 60 × 24 × 30 ≈ 95.904.000 requisições/mês
Utilizando o custo integral do ambiente como referência:
R$ 4.170,26 ÷ 95,904 milhões ≈ R$ 43,48 por milhão de requisições
Referência preliminar¶
Indicador Valor
Capacidade estável inicial 37 RPS Requisições equivalentes/mês \~95,9 milhões Custo mensal de referência R\$ 4.170,26 Custo estimado por 1 milhão de requests \~R\$ 43,48
Este valor não deve ser tratado ainda como preço definitivo por milhão de requisições.
Ele é uma referência inicial e conservadora baseada no custo informado do ambiente e na primeira capacidade estável identificada.
Além disso, o custo mensal atual representa infraestrutura provisionada. Em produção, o custo efetivo dependerá de fatores como quantidade mínima de réplicas, autoscaling, utilização média, requests/limits e capacidade individual de cada componente.
7. Limitações da estimativa atual¶
A principal limitação é que o benchmark representa o caminho simplificado do Gateway.
Ainda não estão refletidos no custo:
- autenticação;
- IP Policy;
- Rate Limit;
- transformação de payload;
- combinações dessas funcionalidades;
- diferentes tamanhos de payload;
- diferentes tempos de resposta da API target;
- comportamento de autoscaling em execução prolongada;
- capacidade máxima individual de broker, security-checker e router.
Portanto, funcionalidades adicionais poderão aumentar CPU, memória e latência e, consequentemente, alterar a quantidade de réplicas necessária e o custo por milhão de requisições.
8. Próximos passos¶
Para aproximar a estimativa do custo real de produção, os próximos testes deverão seguir a mesma metodologia e evoluir progressivamente.
-
Corrigir o problema do Ingress e concluir o teste de capacidade dos demais serviços.\ Manter o builder escalável e aumentar progressivamente o RPS para identificar o próximo gargalo entre broker, security-checker e router.
-
Determinar a capacidade individual por réplica.\ Registrar para cada microserviço o RPS sustentável, CPU, memória, p95/p99 e ponto de saturação.
-
Executar cenários com políticas habilitadas.\ Repetir o benchmark mantendo a target em 250 ms para permitir comparação direta:
- baseline;
- autenticação;
- autenticação + IP Policy;
- Rate Limit;
- transformação de request/response;
- cenário completo com as principais políticas simultaneamente.
-
Testar diferentes payloads.\ A transformação de body tende a ser especialmente sensível ao tamanho do payload. Devem ser definidos payloads pequenos, médios e grandes para comparação.
-
Validar autoscaling.\ Medir quantidade de réplicas necessária para diferentes patamares de tráfego e o comportamento durante subida e redução da carga.
-
Converter capacidade em custo.\ Com a capacidade por réplica conhecida, calcular quantas réplicas são necessárias para cada faixa de consumo mensal e transformar essa necessidade em custo de infraestrutura.
9. Modelo esperado para a próxima versão¶
Com os próximos benchmarks, o objetivo é evoluir de uma única referência para uma matriz semelhante a:
Cenário RPS p95 p99 Réplicas Custo por estável/réplica necessárias milhão
Baseline A medir/refinar --- --- --- ---
Autenticação A medir --- --- --- ---
Auth + IP A medir --- --- --- --- Policy
Rate Limit A medir --- --- --- ---
Transformação A medir --- --- --- ---
Full Gateway A medir --- --- --- ---
Isso permitirá chegar a um custo de processamento baseado no perfil real de utilização do Gateway, em vez de utilizar apenas o custo fixo total do ambiente.
10. Resumo executivo¶
Os testes realizados até o momento estabeleceram 37 RPS como baseline conservador de capacidade estável, considerando uma configuração sem escalabilidade adicional do componente inicialmente limitante.
Com base no custo mensal informado de R\$ 4.170,26, esse baseline equivale preliminarmente a aproximadamente R\$ 43,48 por milhão de requisições, caso a capacidade fosse utilizada continuamente.
Testes posteriores demonstraram que, com escalabilidade do builder, o Gateway conseguiu sustentar 100 RPS durante 5 minutos, sem falhas e sem requisições descartadas, indicando que existe capacidade adicional significativa.
O valor atual deve ser tratado como referência preliminar, pois os testes foram realizados contra uma API mockada com resposta fixa de 250 ms e sem autenticação, IP Policy, Rate Limit ou transformação.
A próxima etapa é identificar a capacidade por réplica dos componentes, repetir os testes com políticas progressivamente habilitadas e relacionar a quantidade necessária de réplicas ao custo de infraestrutura. Isso permitirá obter uma estimativa de custo por milhão de requisições mais próxima do comportamento esperado em produção.