Planificarea capacității și creșterea încărcăturii

Scurt rezumat

1. Prognoza cererii (tendință de referință + sezonalitate + evenimente).

2. Model de încărcare (model deschis pentru Internet).

3. Headroom și buget eronat.

4. Scalare (orizont/vertical/auto) + limitatoare (rate-limit/backpressure).

5. Finanțe: $/1000 RPS, $/ms p95, TCO după scenariu.

Termeni și valori

Debit: RPS/QPS/CPS - debit real.
Latență p95/p99: SLO-uri țintă pentru căile utilizatorului.
Saturație: procesor/memorie/IO/FD/conexiuni/cozi de încărcare.
Rata de eroare: 5xx/timeout/429, buget eronat pentru perioada.
Headroom: ponderea puterii libere la traficul de vârf (recomandat ≥ 30%).
Explozie: vârf pe termen scurt (secunde/minute), Spike: creștere ascuțită × N.

Modele și formule de bază

Legea lui Little (pentru sistemele de coadă)

L = λ W

L este numărul mediu de cereri în sistem, λ este rata medie de intrare (SPR), W este timpul mediu în sistem. Util pentru estimarea adâncimii cozii.

Factor de încărcare (ρ)

ρ = λ / μ

μ - viteza de service (RPS la 100% CPU). Când ρ→1, latența crește non-liniar - păstrați punctul de lucru ρ ≤ 0. 6–0. 75.

Factor de siguranță/marjă

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

În cazul în care Degradation_factor reprezintă eșecul N, degradarea memoriei cache, pierderea unui PoP/regiune (de exemplu, 1. 2).

Prognoza cererii

1. Istoric: profiluri zi/săptămână, sezonalitate, corelație cu evenimente (meciuri/fluxuri/plăți).
2. Evenimente: coeficienți de scenariu (zi obișnuită × 1, turneu × 2. 3, final × 3. 5).
3. Surse de fluctuații: campanii de marketing, lansări, anomalii bot.
4. Unități de prognoză: RPS pe rute (login, lobby, catalog, plăți), CPS TLS, QPS DB, IOPS disk, egress Gbps.
5. Încredere: Păstrați două scenarii - conservatoare și agresive.

Simularea sarcinii

Open-model (Poisson-like arrival): plauzibil pentru API-uri publice/web - utilizare pentru dimensionare.
Model închis (timp de gândire VU +): potrivit pentru secvențe interne; combina.
Amestecuri de traseu: fracții de greutate per criteriu final; include nu numai „fierbinte”, ci și „scump” (înregistrare, depozit).
Nu uitați: retras, cozi, limite de parteneri (PSP, API-uri terțe părți).

Design marjă de siguranță

Țintă: ≥ 30% la vârf (pentru Internet); pentru miezul de plată și căile critice - 40-50%.
N + 1/N + 2: rezistă la eșecul a 1-2 instanțe/zone fără a încălca SLO.
Multi-regiune: fiecare regiune trage ≥ 60% din vârful total (pentru a supraviețui pierderii unui vecin).
Mod Degrade: dezactivați funcțiile secundare, reduceți sarcina utilă, activați răspunsurile cache/stab.

Dimensionarea după strat

Rețea/Edge

CPS/RPS în față, TLS-strângere de mână p95, resumption≥70%, Gbps de ieșire.
Anycast/Geo-rutare, limite CDN/WAF (de acord în avans).
Marja: link/aplink ≥ × de vârf 1. 3, restanțe SYN cu UDP/443 de marjă pentru H3.

Balancers/Proxies

RPS la instanță, conexiuni deschise, cozi, CPU/IRQ.
Keepalive și conexiune pooling - reduce conexiunile la backends.
Stoc: ρ ≤ 0. 7, limitator по CPS/SPR pe traseu.

Aplicații

Performanța țintă per nucleu (SPR/core) în platou.
Piscine (thread/DB/HTTP) - nu se execută în limite.
Stoc: autoscale până la CPU 60-70% și latență-trigger (p95).

Cache

Hit-raport, hotset volum, evacuare, replica.
Rezervare: memorie ≥ 1. 2 × hotset, sala de rețea ≥ 30%.

Baze de date

QPS/TPM, cereri p95, încuietori, memorie cache tampon, decalaj WAL/replicare.
IOPS și unitățile de latență sunt cheia pentru p95.
Marjă: punct de operare CPU 50-65%, lag replica <țintă; charding plan și read-replici.

Discuri/Stocare

IOPS (4k/64k), debit, cost fsync.
Stoc: IOPS ≥ vârf × 1. 5, latență p95 în fereastra țintă; piscine separate pentru jurnal/date.

GPU/ML (dacă există inferență online)

Mostre/s, latență, VRAM, lotare.
Marjă: parametrii lotului sub sarcina „ferăstrău”, GPU warm-pool.

Auto-scalare

HPA/KEDA: măsurători CPU + personalizate (latență p95, RPS, coadă).
Piscine calde: instanțe preîncălzite înainte de evenimente.
Pas-scalare: pași cu cooldown, astfel încât să nu „văzut”.
Timp de reacție: țintiți la T_scale ≤ 1-2 minute pentru stratul frontal; pentru DB - în avans.

Limitatoare și backpressure

Limita de tarif по IP/ASN/dispozitiv/traseu; cote partenere.
Cozi cu TTL, refuzul „politicos” (429/prin gri-vol) înainte de timeout.
Idempotence: chei pentru plăți; retroys cu buget + jitter.
Solicitare prăbușire/SWR: Nu treziți originea în timpul unei stropiri.

Exemplu de calcul rapid

Dat: 35k RPS API de vârf prognoză, p95 250 ms, durata medie de serviciu 8 ms pe instanță la 60% CPU RPS/core, 8 nuclee pe instanță 1000 RPS/instanță.
Pasul 1 (fără stoc): 35 de cazuri.
Pasul 2 (înălțime 30%): 35 × 1. 3 = 46.
Pasul 3 (eșecul unui AZ, + 20%): 46 × 1. 2 ≈ 55.
Etapa 4 (rotunjire + rezervă fierbinte 10%): 61 instanțe.
Verificați: ρ ≈ 35k/( 61k) ≈ 0. 57 - în zona verde.

Model financiar (FinOps)

$/1000 RPS pe straturi (margine, proxy, aplicație, DB).
$/ms p95 (costul de reducere a cozii).
Scenarii TCO: la cerere vs rezervate vs spot (cu riscul de întreruperi).
Plan de capacitate: limite trimestriale de cont/cluster, cote cloud, limite PSP/CDN.

Gata pentru eșecuri și DR

Multi-AZ/regiune: fiecare braț ≈ 60% din sarcină.
Plan de eșec: retrageți Anycast, comutare GSLB, TTL ≤ 60-120 s.
Dependențe critice: limite PSP/bancare, furnizor secundar.
Exerciții periodice: zi de joc cu PoP/BG/cache off.

Semnale de observabilitate și saturație timpurie

Creștere de p95/p99 și cozi cu intrare stabilă.
Căderea cache-ului cu raport de succes, creșterea ieșirii originii.
Retransmiteri/ECN creștere CE, TLS reluare scădere.
Creștere 429/timeout și reîncercare.
Pentru baze de date - creșterea conflictelor, timpul de control, WAL fsync.

Practici operaționale

Revizuirea capacității lunar: fapt vs plan.
Schimbați ferestrele pentru evenimente: înghețați sâmburii și limitele.
Prewarm (CDN/DNS/TLS/piscine) 10-30 min înainte de vârf.
Limit versioning: fixați configurațiile rate-limit/pools în Git.

iGaming/fintech specific

Turnee/meciuri: profile spike + platou, rute gri pentru roboți, limite separate de înregistrare/depunere.
Plăți/PSP: cote furnizor/metodă, rute de rezervă, piscine IP de ieșire, SLA Time-to-Wallet.
Furnizori de conținut: distribuție după studio, cache-uri fierbinți, piscine cu cioburi.
Antifraudă/AML: limitarea regulilor/punctajului, degradarea regulilor de lumină la vârf.

Lista de verificare a implementării

• Prognoza de vârf (bază/sezon/evenimente), două scenarii.
• Buget SLO/greșit și țintă ≥ înălțime 30%.
• Dimensionarea după strat (edge/proxy/app/cache/DB/IO/rețea).
• Rate-limită, coadă, idempotency, încercați din nou-buget.
• Piscine calde HPA/KEDA +; planul de promovare înainte de eveniment.
• Multi-AZ/regiune, failover playbooks, TTL și GSLB.
• Cotele Cloud/PSP/CDN sunt consecvente și documentate.
• Observabilitate: tablouri de bord de capacitate, semnale de saturație timpurie.
• Exerciții DR și revizuire regulată a capacității.

Erori comune

Plan pentru SPR medie fără cozi/vârfuri.
ρ≈0. 9 „pe hârtie” - latența explodează la cel mai mic zgomot.
Ignorarea limitelor de servicii externe (cluster PSP/CDN/DB).
Nu există moduri degrade și backpressure sunt eșecuri în cascadă.
Auto-scară fără preîncălzire - gestionează „după” vârf.
Camera single pentru toate straturile - strangulare migrează.

Mini playbook-uri

Înainte de eveniment de vârf (T-30 min)

1. Creșterea minReplicas/țintă HPA, permite piscina caldă.
2. Încălziți conexiunile CDN/DNS/TLS, încălziți cache-urile.
3. Ridicați limitele PSP și cotele convenite.
4. Activați rutele gri/filtrele bot, punctele finale înguste.

Pierderea parțială a regiunii

1. GSLB → regiunea vecină, TTL 60-120 s.
2. Activați modul degrade (memorie cache/checkout simplificat).
3. Redistribuiţi limitele PSP/IP de ieşire.
4. Stare de comunicare, p95/eroare de control.

Supratensiune în retrageri

1. Reduceți bugetul, activați backoff + jitter.
2. Activați cererea-colapsing/SWR pe GET.
3. Strângeți temporar limita de rată pentru ASN-urile „zgomotoase”.

Rezultat

Planificarea capacității este previziunea cererii + modelul ingineriei + marja de siguranță + pârghiile operaționale. Formalizați SLO și headroom, luați în considerare limitele externe, automatizați scalarea și degradarea, măsurați „costul pe milisecundă” și efectuați revizuiri regulate ale capacității. Apoi, creșterea încărcăturii se va transforma nu într-un risc, ci într-o metrică de afaceri ușor de gestionat.