Planification des capacités

1) Qu'est-ce que la planification de capacité et pourquoi il est nécessaire

La planification des capacités (capacity planning) est un processus systématique d'évaluation et de mise à disposition des ressources nécessaires pour atteindre les SLO cibles à un coût minimal. Il ne s'agit pas seulement de CPU/mémoire, mais aussi de la bande passante des réseaux, du stockage, des bases de données/caches, des files d'attente/bus d'événements, des fournisseurs externes (paiements/CUS/antifrod), ainsi que des ressources humaines (on-call, support).

• Exécutez SLO/SLAs même dans les pics et les dégradations.
• Minimiser le TCO et le capital simple (overprovisioning).
• Réduire le risque d'incidents dus à l'épuisement des ressources (saturation → p99/erreurs).
• Assurer la prévisibilité des sorties et des campagnes (marketing, tournois, top match).

2) Entrées et sources de vérité

Observation : RPS/concarrence, p50/p95/p99, taux d'erreur, saturation (CPU, mem, disk IOPS, réseau pps/mbps), longueur des files d'attente, limites de taux.
Événements d'affaires : calendriers de campagne, saisonnalité (soirées/week-ends/méga-événements), régions/juridictions.
Techndolg/fiches : versions roadmap, modifications architecturales (par exemple, cryptage, nouveau logging).
Fournisseurs : quotas et throughput services de paiement/CUS/courrier/antifrood.
Incidents passés : où est le goulot d'étranglement (OBD, cache, équilibreur L7, bus, CDN, disque).

3) Concepts et formules de base

Headroom est la marge de capacité : 'headroom = (max _ résistant _ RPS − réel _ RPS )/max _ résistant _ RPS'.
La valeur cible est de 20 à 40 % (pour les flux critiques).
La saturation est le rapport entre la ressource occupée et la ressource disponible (CPU %, mémoire/GC, connexions, fichiers descripteurs, IOPS, profondeur de file d'attente).
Throughput est la vitesse à laquelle p99 et error-rate exécutent SLO pendant longtemps (pas une seule surtension).
L'unité de capacité (UC) est une unité de puissance normalisée pour le service (par exemple, X RPS par pod vCPU = 1, RAM = 2 GiB).
La limite système est max sans dégradation : 'N _ pods × CU'. Il est important de prendre en compte les dépendances partagées (OBD/cache/bus).

4) Modèle de demande : Prévision

Séries statistiques : saisonnalité hebdomadaire/journalière, fêtes, finales sportives, pics régionaux.
Cohortes : par pays, fournisseurs de paiement, appareils, segments VIP.
Delta de l'événement : impact des campagnes/poils/releases/SEO.
« Et si » (scenario planning) : + 50% au trafic à 19h00-22h00 ; la chute du fournisseur A → la redistribution en B (+ 30 % à latence).
Ajustements en temps réel : nowcasting selon les métriques de lead (revitalisation des sessions, file d'attente par match, paniers).

5) Modèle d'offre : où la chaîne « casse »

Le convoyeur de la demande : Edge/CDN → le L7-équilibreur → l'application → la cache → le BD → extérieur API → le tour/pneu → les gestionnaires/ETL.

• Capacité (CU/instance), évolutivité (horizon). , limites (connexions, pps, IOPS), retards.
• Les politiques d'échec (rate limit, circuit breaker, dégradation).
• SLO local et leur contribution à la e2e-SLO.

6) Inventaire et budget des erreurs

Nous lions le headroom à l'error budget : moins de budget → plus de stock.
Pour les flux critiques (paiement/vérification) - headroom ci-dessus, pour les flux secondaires - ci-dessous.
Réserves froides/chaudes : activables au pic/accident.

7) Mise à l'échelle : Tactique

HPA (par mesure de charge) : RPS, latency, longueur de file d'attente, SLIs personnalisés (better than CPU %).
APV : ajustement des ressources aux sous-programmes (plus soigneux avec stateful et p99 GC).
KEDA/adaptateurs : mise à l'échelle par des sources externes (Kafka lag, Redis list length, CloudQueue depth).
Pools Warm/échauffement : Instances levées à l'avance pour éviter un démarrage à froid.
L'approche « Load-as-Code » : les politiques Auto-Skale/Limited/Timeuts/Retraeys sont versionnées et revues.

8) Files d'attente, backpressure et gestion de la queue

L'objectif est d'éviter une croissance en avalanche p99.
Nous limitons le parallélisme et la taille de la file d'attente, entrons les fenêtres temporelles et l'idempotence.
Hedging/Retry-budget : limitez le budget total du temps de l'utilisateur et du système.
Graceful degradation : désactivation des fiches secondaires en cas de surcharge.

9) OBD, caches et stockage

DB : limite de connexions, journal/FSync, index, plan de requête, replica lag, hot-keys/tables, max TPS pour les transactions.
Keshi : hit-ratio par segments, « tempête de défauts » à la libération/invalidité, distribution de clés.
Scorage : IOPS/throughput, retards, compression, TTL, nettoyage des anciens lots/snapshots.
Schéma des migrations : expand→migrate→contract sans verrous d'arrêt.

10) Flux d'événements et ETL

Kafka/pneu : débit des lots, lag, ISR, compaction, limites des producteurs/consumers.
ETL/batchi : fenêtres de démarrage, budgets d'exécution, impact sur l'arrêt (throttle I/O).
Idempotence et exactly-once-like pour les flots critiques (paiements/bilans).

11) Réseau et périmètre

L4/L7 les équilibreurs : connection limits, syn backlog, TLS offload, session reuse.
CDN/Edge : Passe, stratégie de cache pour réduire la charge d'origin.
Limites intra-réseau : pps/mbps dans le VPC/sous-réseau, egress-cost (FinOps).

12) Multiregion, DR et juridictions

Stratégies : active-active (GSLB/Anycast), active-passive (DR chaud/chaud/froid).
N + 1 par région : supporter la perte d'AZ/région tout en conservant les flux de base SLO.
Localisation légale : répartition du trafic/données par pays, limites différentes et SLO en fournisseurs.
Tests DR : jours de jeu réguliers avec transfert de charge réel.

13) Fournisseurs externes : quotas et itinéraires

Paiements/KYC/antifrod/courrier/SMS : quotas TPS, burst, limites journalières.
Multi-fournisseur : routage par latence/succès, fournisseur SLO per, auto-faucher.
Contrats SLA : conformité des e2e-SLO, canaux d'escalade, status webhooks.

14) FinOps : coût et efficacité

TCO : compute + storage + network egress + licences/fournisseurs + service.
Économie unitaire : coût de 1k demandes/1 opération de dépôt/1 KYC.
Optimisation : right-sizing, rabais spot/préfixe, astuce cache, dedup logs/trace, niveaux de stockage à froid.
Transfert de charge dans le temps : batchi non critique dans les fenêtres « nocturnes » et les régions bon marché.

15) Dashboards et rapports (recrutement minimum)

• La charge actuelle vs est stable throughput par maillons.
• Headroom par service et région ; prévisions pour 24/72 heures.
• KPI FinOps : $/1k demandes, $/dépôt.

• Top goulets d'étranglement (p99, saturation, lag), stock selon DR.

• Succès/latence et limites des fournisseurs ; part du trafic sur les itinéraires.

• Plan de mise à niveau/index/optimisation, économies prévues/augmentation de la capacité.

16) Processus et rôles

RACI : Plateforme (infra/clusters/équilibreurs), bases de données/données (index, réplication), commandes de service (profilage/cache), SRE (SLO, alertes), Sec/Compliance (crypto/journaux), Finances (budget).
Rythme : capacity review hebdomadaire (feuille de route, prévisions, risques), résumés Finops mensuels, tests de RD trimestriels.
Gestion du changement : les grandes campagnes/sorties passent par capacity-gate (chèque ci-dessous).

17) Chèque d'émission et de campagne (capacity-gate)

• Prévision de la charge de pointe et « + x % de la queue de secours ».
• Headroom disponible pour les flux core (paiements/CUS/login).
• Les quotas sont confirmés aux fournisseurs ; les itinéraires alternatifs sont actifs.
• Les seuils HPA/KEDA et warm-pool sont configurés.
• Files d'attente/limites et dégradations testées (Pleybooks prêts).
• Parts canaries et auto-reculs inclus.
• Dashboards/alerts (burn-rate, saturation, p99) testés.
• Le plan du DR et les contacts d'escalade sont pertinents.

18) Anti-modèles

« CPU <70 % - tout va bien » : ignorer les limites des dépendances (connexions OBD, IOPS, files d'attente).
Une boîte noire centralisée sans métriques per-link - impossible de comprendre où est la limite.
L'absence de stratégie de cache - les erreurs de sortie tuent origin.
Le hardcode des limites des retraits sans budgets est une tempête de demandes.
« Un fournisseur de paiement » est le point de refus au sommet.
Ignorer les réserves chaudes est un début froid comme cause d'incidents.
Il n'y a pas de tests DR périodiques - le plan ne fonctionne pas quand vous en avez besoin.

19) Mini-calculs (exemple)

Service X : RPS résistant 350 par pod (vCPU = 1, RAM = 2 GiB). L'objectif est de 5 000 RPS, 25 %.
Puissance souhaitée = '5000/0. 75 = 6667 RPS`.
Podov = 'ceil (6667/350) = 20'. Plus warm-pool 15 % → 3 pod supplémentaires.
OBD : limite de 12k TPS, crédit courant de 9k TPS, prévision de pic de 10. 5k TPS → stock 1. 5k (14%). Requis : Index/Charding/Répliques ou mise en cache pour réduire à 8. 5k.
Fournisseur A (KYC) : quota de 120 rps, pic de 95 rps, campagne + 40 % → 133 rps> quotas → routage 70 % A/30 % B.

20) Modèle de mise en œuvre de capacity planning

1. Décrire le chemin e2e et les goulets d'étranglement.
2. Entrez le CU et mesurez le throughput stable de chaque couche.
3. Configurer les métriques de saturation et p99 sur toutes les liaisons.
4. Générer un calendrier des événements/campagnes/versions.
5. Construire une prévision par cohortes et un scénario « si ».
6. Ancre le flux per et la région per (ancre au budget error).
7. Configurer HPA/VPA/KEDA + warm-pools, limites/retrai/files d'attente.
8. Vérifiez les quotas du fournisseur, activez les itinéraires multiples.
9. Assembler les dashboards et le rythme hebdomadaire de capacity review.
10. Trimestriel - Exercice de DR et révision du modèle.

21) Résultat

La planification de la capacité est un ensemble gérable de prévisions, de contraintes architecturales et de coûts, plutôt que d'ajouter des CPU. Lorsque chaque couche de la voie e2e a une capacité mesurée et que le headroom et les stratégies de dégradation sont liés à SLO et error budget, les charges de pointe, les campagnes et les accidents ne sont plus une surprise. Cette approche réduit les risques d'incidents, stabilise les mesures commerciales et optimise les coûts.