Está de prevenção a um serviço web: um balanceador de carga à frente de uma frota de instâncias, uma cache à frente de uma base de dados e um objetivo de disponibilidade de 99,9 %. A cada minuto o modelo calcula atraso de fila, timeouts, acertos de cache e carga da base de dados a partir de fórmulas de manual — e quanto custam as suas decisões.
Piso da frota. Aumentá-lo lança instâncias de imediato — mas ainda precisam do atraso de arranque antes de servir.
Seguimento de um alvo de utilização; sem novo escalonamento para cima enquanto as instâncias ainda estão a arrancar. Desligado = exatamente o mínimo.
Mais baixo = mais folga e mais custo. A utilização medida não pode exceder 100 %, por isso uma frota saturada só cresce passo a passo.
TTL mais longo = mais acertos, mas as respostas podem ser mais antigas (idade média ≈ TTL/2).
Carrega chaves quentes durante 6 minutos (+12 % da cache por minuto) ao preço de 600 consultas extra à base de dados por segundo.
Parte dos 30 % de baixa prioridade (prefetch, lotes, crawlers) rejeitada no balanceador de carga com «tente mais tarde».
A funcionalidade pesada acrescenta 20 ms de CPU e uma consulta à base de dados por pedido. Desligada = degradação graciosa.
Volta a implementar a última versão boa numa frota nova (5 min, faturada em dobro) e depois muda o tráfego. Carregar de novo reinicia a preparação; sem uma versão má em produção, só custa dinheiro.
| Taxa de consumo (1 h) | 0,0 × |
|---|---|
| Pedidos | 1125 req/s |
| Instâncias a servir | 10 |
| Instâncias a arrancar | 0 |
| Taxa de acertos da cache | 77 % |
| Utilização da base de dados | 19 % |
| Tráfego rejeitado | 0 % |
| Custo da frota | 4,00 $/h |
| Custo até agora | 0,00 $ |
| Idade média das respostas em cache | 30 s |
| Tráfego na versão má | 0 % |
| Recomendações disponíveis | 100 % |
Uma nova versão sai às 09:10. O mês já foi duro: só restam 20 % do orçamento de erros. Minutos depois do deploy dispara o alerta de taxa de consumo. Proteja o orçamento.
Uma ligação para o serviço está a espalhar-se depressa e é esperado um pico de tráfego a qualquer momento desta manhã — ninguém sabe quando, nem de que dimensão. As novas instâncias demoram hoje 8 minutos a arrancar. Quando chegar, mantenha baixos os erros e a latência sem gastar dinheiro em capacidade parada.
No pico do meio-dia, um script de manutenção limpa toda a cache. Cada pedido vai agora à base de dados, dimensionada para a taxa habitual de 85 % de acertos. Recupere o serviço sem sobrecarregar a base de dados.
Todas as relações que o simulador usa, com a respetiva fonte. As constantes marcadas como pressupostos são calibrações ilustrativas.
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]Pressuposto: números de workers, tempos de serviço, capacidade da base de dados, tamanho da cache, velocidade de reposição, preços e a taxa de erros da versão má são valores ilustrativos para um serviço web de média dimensão.N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]Aproximação: somar os quantis de serviço e de espera não dá o p99 exato da sua soma (pode ficar um pouco alto ou baixo); a fila é tratada como estável dentro de cada minuto porque os pedidos demoram milissegundos.busy workers L = λ·S ⇒ utilization = λ·S / N[4]hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]Pressuposto: números de workers, tempos de serviço, capacidade da base de dados, tamanho da cache, velocidade de reposição, preços e a taxa de erros da versão má são valores ilustrativos para um serviço web de média dimensão.budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]Pressuposto: números de workers, tempos de serviço, capacidade da base de dados, tamanho da cache, velocidade de reposição, preços e a taxa de erros da versão má são valores ilustrativos para um serviço web de média dimensão.16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instancesPressuposto: números de workers, tempos de serviço, capacidade da base de dados, tamanho da cache, velocidade de reposição, preços e a taxa de erros da versão má são valores ilustrativos para um serviço web de média dimensão.Aleatoriedade: um gerador mulberry32 com semente; distribuições usadas — uniforme, exponencial (inversa da CDF), normal (Box–Muller), Poisson (Knuth). A semente é apresentada e partilhável.
Modelo educativo — não para decisões operacionais. Os locais reais calibram cada constante para o seu próprio equipamento e dados.