Infrastruktúra-kapacitás és költségek

Capacity & Infrastructure Costs

Right-size infrastructure from measured workload characteristics rather than guesswork, and guard every auto-scaling or pay-per-use resource with hard upper ceilings so a traffic spike, retry loop, or runaway job cannot cause an outage or a billing shock.

Bottleneck Diagnosis (The USE Method)

Before scaling up hardware or adding replicas, check Utilization, Saturation, and Errors for every resource along the request path:

1. Database & Connection Pools (Most Common Real Bottleneck):
   • Adding 20 application containers that each open a 20-connection pool (400 connections) will overwhelm a database configured for max_connections = 100.
   • Size per-instance pool limits so $\text{max_instances} \times \text{pool_size} + \text{admin_reserve} < \text{DB max_connections}$, or place a connection pooler (PgBouncer / RDS Proxy / Supavisor) in front of the database.
2. Memory Working Set vs. Limits (OOMKills):
   • Monitor container memory working set (container_memory_working_set_bytes) and language runtime heap limits (e.g., Node --max-old-space-size set to ~75–80% of container memory limit so GC runs before the Linux kernel OOM-killer terminates the process with exit code 137).
3. CPU Throttling vs. Average CPU:
   • Check container CFS throttling (container_cpu_cfs_throttled_periods_total) and event-loop lag alongside average CPU utilization; bursty workloads can experience severe tail-latency spikes even at 40% average CPU if limits are overly tight.

Safe Autoscaling & Cost Guardrails

When proposing an infrastructure or scaling change, state the expected capacity headroom, failure mode at ceiling, and estimated monthly cost delta explicitly.