Planification de la capacité et augmentation de la charge

Résumé succinct

1. Prévisions de la demande (tendance de base + saisonnalité + ivents).

2. Modèle de charge (open-model pour Internet).

3. Marge de sécurité (headroom) et budget erroné.

4. Mise à l'échelle (horizon/vertical/auto) + limiteurs (rate-limit/backpressure).

5. Finances : $/1000 RPS, $/ms p95, TCO par scénario.

Termes et métriques

Throughput : RPS/QPS/CPS est la bande passante réelle.
Latency p95/p99 : SLO ciblé pour les chemins personnalisés.
Saturation : chargement CPU/mémoire/IO/FD/connexions/files d'attente.
Taux d'erreur : 5xx/timeout/429, budget erroné pour la période.
Headroom : part de la puissance libre dans le trafic de pointe (recommandé ≥ 30 %).
Burst : sursaut à court terme (secondes/minutes), Spike : croissance spectaculaire × N.

Modèles et formules de base

Little's Law (pour les systèmes en file d'attente)

L = λ W

L est le nombre moyen de requêtes dans le système, λ l'intensité moyenne d'entrée (RPS), W le temps moyen dans le système. Utile pour estimer la profondeur des files d'attente.

Taux de chargement (ρ)

ρ = λ / μ

μ est la vitesse de service (RPS à 100 % CPU). Lors de la ρ→1, la latence augmente de manière non linéaire - gardez le point de travail ρ ≤ 0. 6–0. 75.

Facteur de sécurité/stock

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

Où le Degradation_factor tient compte de la défaillance N, de la dégradation du cache, de la perte d'un PoR/région (par example 1. 2).

Prévisions de la demande

1. Historique : profils journaliers/hebdomadaires, saisonnalité, corrélation avec les événements (matchs/strimes/paiements).
2. Events : coefficients de scénario (jour normal × 1, tournoi × 2. 3, finale × 3. 5).
3. Sources de fluctuations : campagnes marketing, sorties, anomalies des bots.
4. Unités de prévision : RPS par itinéraire (login, lobby, catalogue, payments), CPS TLS, QPS DB, disque IOPS, egress Gbit/s.
5. Confiance : garder deux scénarios - conservateur et agressif.

Simulation de charge

Open-model (arrivée Poisson-like) : plausible pour les API/webs publics - à utiliser pour le sizing.
Closed-model (VU + think-time) : convient aux séquences internes ; Combiner.
Mélanges d'itinéraires : fractions de poids par endpoint ; incluez non seulement « chaud », mais aussi « cher » (inscription, dépôt).
N'oubliez pas : retraits, files d'attente, limites partenaires (PSP, API tierces).

Conception de marge de sécurité

Cible Headroom : ≥ 30 % au sommet (pour Internet) ; pour le noyau de paiement et les voies critiques - 40-50 %.
N + 1/N + 2 : nous supportons une défaillance de 1-2 instances/zone sans perturber le SLO.
Multi-région : chaque région tire ≥ 60 % du pic total (pour survivre à la perte d'un voisin).
Mode Degrade : Désactiver les fonctions secondaires, réduire le paiement, activer le cache/les réponses.

Sizing par couches

Réseau/Edge

CPS/RPS sur le front, TLS-handshake p95, resumption≥70 %, egress Gbit/s.
Anycast/Geo-routing, limites CDN/WAF (accord préalable).
Stock : Link/aplink ≥ pic × 1. 3, SYN backlog avec stock, UDP/443 pour H3.

Équilibreurs/Proxy

RPS à l'intérieur, connexions ouvertes, file d'attente, CPU/IRQ.
Keepalive et connection pooling - réduisent les connexions aux backends.
Stock : ρ ≤ 0. 7, limiter по CPS/RPS per route.

Applications

Performance cible par noyau (RPS/core) dans le plateau.
Pools (thread/DB/HTTP) - ne pas respecter les limites.
Stock : Auto Skale jusqu'à CPU 60-70 % et latency-trigger (p95).

Cache

Hit-ratio, volume hotset, evection, réplique.
Réserve : Mémoire ≥ 1. 2 × hotset, tête haute réseau ≥ 30 %.

Bases de données

QPS/TPM, p95 requêtes, verrous, cache tampon, WAL/replication lag.
L'IOPS et le disque latin sont la clé de p95.
Stock : CPU point de fonctionnement 50-65 %, réplique larme <cible ; plan de chardonnages et read-replicas.

Disques/Stockage

IOPS (4k/64k), throughput, fsync cost.
Stock : IOPS ≥ pic × 1. 5, latency p95 dans la fenêtre cible ; pools individuels pour le journal/données.

GPU/ML (s'il y a des informations en ligne)

Samples/s, latency, VRAM headroom, batching.
Stock : paramètres de batch sous « scie » de charge, GPU warm-pool.

Mise à l'échelle automatique

HPA/KEDA : métriques CPU + sur mesure (p95 latitude, RPS, file d'attente).
Warm pools : avant de chauffer les instances devant les ivents.
Step-scaling : étapes avec cooldown pour ne pas « scier ».
Temps de réaction : nous visons en T_scale ≤ 1-2 minutes pour la couche de front ; pour la base de données - à l'avance.

Limiteurs et backpressure

Rate-limit по IP/ASN/device/route; quotas pour les partenaires.
Files d'attente avec TTL, refus « poli » (429/via grey-wal) avant les timouts.
Idempotence : clés de paiement ; Retrai avec budget + jitter.
Request collapsing/SWR : ne pas réveiller l'origin pendant le sursaut.

Exemple de calcul rapide

Données : prévision du pic de 35k RPS par API, p95 ≤ 250 ms, service moyen 8 ms par instance à 60 % de CPU → μ≈125 RPS/core, 8 cœurs par instance → ~ 1000 RPS/instance.
Étape 1 (pas de stock) : 35 instances.
Étape 2 (tête haute 30 %) : 35 × 1. 3 = 46.
Étape 3 (échec d'un AZ, + 20 %) : 46 × 1. 2 ≈ 55.
Étape 4 (arrondi + réserve chaude 10 %) : 61 instances.
Vérification : ρ ≈ 35k/( 61k) ≈ 0. 57 - en zone verte.

Modèle financier (FinOps)

$/1000 RPS par couches (edge, proxy, app, DB).
$/ms p95 (coût de la réduction de la queue).
Scripts TCO : on-demand vs reserved vs spot (avec risque d'interruptions).
Plan de capacité : limites trimestrielles des comptes/grappes, quotas cloud, limites PSP/CDN.

Préparation aux pannes et DR

Multi-AZ/région : chaque épaule ≈ 60 % de la charge.
Plan d'échec : withdraw Anycast, GSLB commutation, TTL ≤ 60-120 s.
Dépendances critiques : limites PSP/banques, fournisseur secondaire.
Exercices périodiques : game day avec désactivation du PoP/BG/cache.

Observation et signaux de saturation précoce

Croissance p95/p99 et files d'attente à entrée stable.
Chute du cache hit-ratio, croissance de l'origin egress.
Augmentation de retransmits/ECN CE, baisse de résumption TLS.
Croissance 429/timeout et retry-rate.
Pour la base de données - augmentation des conflits, checkpoint time, WAL fsync.

Pratiques opérationnelles

Examen de la capacité mensuel : le fait vs plan.
Changez Windows sous events : noyau freeze et limites.
Prewarm (CDN/DNS/TLS/pools) 10-30 min avant le pic.
Versioner les limites : fixez les configurations rate-limit/pools dans Git.

Spécificité pour iGaming/fintech

Tournois/matchs : profils spike + plateau, itinéraires gris pour les bots, limites d'inscription/dépôts séparées.
Paiements/PSP : quotas par fournisseur/méthode, itinéraires fallback, egress-IP pools, SLA Time-to-Wallet.
Fournisseurs de contenu : distribution par studio, caches chaudes, pools de shard.
Antifrod/AML : limite sur les règles/scoring, dégradation en règles light au pic.

Chèque d'implémentation

• Prévisions des pics (base/saison/événements), deux scénarios.
• SLO/budget erroné et tête haute cible ≥ 30 %.
• Sizing par couches (edge/proxy/app/cache/DB/IO/réseau).
• Limiteurs : rate-limit, files d'attente, idempotency, retry-budget.
• HPA/KEDA + warm pools; plan de déroulement avant l'ivent.
• Multi-AZ/région, failover-playbooks, TTL et GSLB.
• Les quotas cloud/PSP/CDN sont harmonisés et documentés.
• Observabilité : dashboards capacity, premiers signaux de saturation.
• Exercice DR et examen capacity régulier.

Erreurs typiques

Plan de RPS moyen sans queues/éclats.
ρ≈0. 9 « sur papier » - la latence explose au moindre bruit.
Ignorer les limites des services externes (PSP/CDN/cluster OBD).
Il n'y a pas de mode degrade et backpressure est un feel en cascade.
Auto-échelle sans échauffement - arrive « après » le pic.
Un seul headroom pour toutes les couches - un goulot d'étranglement migre.

Mini-playbooks

Avant l'événement de pointe (T-30 min)

1. Augmenter minReplicas/target HPA, activer warm pool.
2. Chauffer CDN/DNS/TLS/connexions, chauffer les caches.
3. Augmenter les limites des pools et les quotas PSP par accord.
4. Activer les routes grises/filtres de bot, réduire les endpoints lourds.

Perte partielle de la région

1. GSLB → région voisine, TTL 60-120 s.
2. Activer le mode degrade (cache/émission simplifiée).
3. Redistribuer les limites PSP/egress-IP.
4. Communication de statut, contrôle p95/erreurs.

L'éclatement des rétrogrades

1. Réduire retry-budget, activer backoff + jitter.
2. Activer request-collapsing/SWR sur GET.
3. Resserrer temporairement le taux-limite pour les ASN « bruyants ».

Total

La planification de la puissance est une prévision de la demande + modèle d'ingénierie + marge de sécurité + leviers opérationnels. Formalisez SLO et headroom, tenez compte des limites externes, automatisez la mise à l'échelle et la dégradation, mesurez le « coût milliseconde » et effectuez un examen capacity régulier. Alors l'augmentation de la charge de travail ne deviendra pas un risque, mais une mesure gérée de l'entreprise.