Opérations et gestion → Mise à l'échelle de l'infrastructure d'exploitation

Mise à l'échelle de l'infrastructure d'exploitation

1) Pourquoi et quoi considérer comme « mise à l'échelle »

L'évolutivité est la capacité système de la plate-forme à augmenter la bande passante (RPS/TPS, connexions, IOPS, throughput) et la quantité de données sans perte de SLO et avec un coût contrôlé. Pour iGaming/fintech, c'est directement sur l'argent : conversion des dépôts/paris, jeux en direct et calculs.

• Maintenez le SLO à X fois la charge et les pics saisonniers.
• Fournir un temps de mise à l'échelle prévisible (minutes, pas heures).
• Sauver l'économie : cost/RPS, cost/transaction, cost/1k événements.

2) Principes de la plate-forme évolutive

1. Horizontal-first : division en petits, steless-services ; l'état est dans les clusters de données.
2. Back-pressure et files d'attente : lissage des éclats, protection contre les « tempêtes ».
3. Mise en cache sur tous les calques : client/edge/service/OBD.
4. Idempotence et répétabilité : Retraits sécurisés, outbox, dedup.
5. Dépendances avec restrictions : timeouts, breakers, isolation bulkhead, rate-limits.
6. Observabilité par signaux de capacité : headroom, p95/p99, lag, connexions, quotas.
7. Auto-scaling avec rails de garde : HPA/VPA/Cluster Autoscaler + conditions stop.
8. Multi-région par design : zones blast indépendantes, données locales, feilovers durables.

3) Capacity planning : comment « compter combien il faut »

Entrées du modèle : TPS de pointe cibles, profil de trafic (horaire), « chemins critiques », taux de cache-hit, moyenne payload's, SLO et limites des fournisseurs.

• RPS → CPU/pods : 'pods = RPS p99_time/efficace _ CPU _ in _ pode' (avec une marge de 30 à 50 %).
• Files d'attente : 'minimum _ vitesse _ consumers ≥ pic _ vitesse _ producteurs 1. 2`.
• Connexions DB : 'max _ conns = active _ pools _ services moyen _ pool _ size 1. 3`.
• Cache : taille = « hot working-set en N minutes » + 20-30 % de stock.
• Egress/CDN : pic egress = pic de requête taille moyenne de réponse (prendre en compte la compression).

Headroom : objectif de 20 à 40 % au sommet (par couches). Moins de 15 % → le déclencheur "capacity uplift'.

4) Calques et modèles d'échelle

4. 1 Edge / CDN / WAF

Mise en cache sur le bord (TTL + SWR), géo-équilibre, compression, HTTP/2/3.
Taux-limites sur le périmètre IP/JWT/clé, protection contre les surtensions.
Fan-out d'événements (jackpots, alertes en direct) via les courtiers/canaux pub/sub.

4. 2 passerelles API/Backend-for-Frontend

Mise à l'échelle horizontale sur les pods statles, les pools dedicated sur le downstream.
HPA par métrique d'entreprise : RPS, p99, file d'attente dans le pool de works - et pas seulement CPU.

4. 3 Files d'attente asynchrones/streaming (Kafka/Rabbit/Pulsar)

Échelle par lot et consumers ; éviter le skew (clés et distribution).
Lag-alerts + auto-mise à l'échelle des consumers ; DLQ et retry-topics.
Retraite sous la SLA de reconsilation et de repli.

4. 4 Caches (Redis/Memcached)

Modes de cluster, répliques, stratégies d'évaluation (LFU), multiget, pipeline.
Séparez les tâches hot-key'e et en arrière-plan, les limites des clients et la politique max-memory.

4. 5 Bases de données

Répliques de lecture et d'itinérance, connection pooling.
Chardonnages par région/tenant/gamme de clés.
CQRS : Les enregistrements sont sur le maître/leader, les lectures sur les répliques.
L'indexation et l'écriture batch (outbox → stream → sink).
Archivage et données à chaud/froid (tiering).

4. 6 Stockage de fichiers/objets

Multithreads, téléchargements multipart, CDN-front, transformations asynchrones.
Quotas du fournisseur, nettoyage des « queues » et budget egress.

4. 7 Fournisseurs (PSP/KYC/studios)

Multi-fournisseur et routage par quotas/SLO/coût.
Circuit breaker + rate-limit par fournisseur, file de retraits, « mode grace ».

5) Auto-scaling et garde-rayes

• HPA: метрики `rps_per_pod`, `queue_depth`, `p99_latency`; `targetAverageValue`.
• APV : recommandations sur les ressources ; mettre à jour en dehors du pic.
• Cluster Autoscaler : profils de groupes nod (spot + on-demand) avec priorités.
• PodDissolutionBudget/TopologySpreadConstraints : uniformité par zone.
• LimitRange/ResourceQuota : protection contre les débris « bourrés ».

apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler spec:
scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: api-gw}
minReplicas: 8 maxReplicas: 200 metrics:
- type: Pods pods:
metric:
name: rps_per_pod target:
type: AverageValue averageValue: "120"
- type: Pods pods:
metric:
name: p99_latency_ms target:
type: AverageValue averageValue: "280"
behavior:
scaleUp:
stabilizationWindowSeconds: 90 scaleDown:
stabilizationWindowSeconds: 300

• « Pause & Rollback » si le canarium p99> 1. 3 × baseline 10 minutes.
• « Freeze scale-down » en prime time, seulement scale-up.
• « Stop retries » à 'open _ circuit = 1' aux goulots d'étranglement.

6) Multi-région : actif/actif et actif/passe

Régions isolées Blast : clusters indépendants, secrets locaux/quotas.
Itinérance globale : latincy-/geo-based, health-probes, override manuelle.

• Chaud - réplication locale + eventual (strim).
• Les transactions critiques sont négociées par domaine (ledger/bilan).
• Failover-playbooks : changement de source étape par étape, TTL, chauffage des caches.
• Règlement d'exercice (DR) : entraînement trimestriel avec objectifs RTO/RPO.

7) Modèles de réseau et de service

Service Mesh : mTLS, retry/breaker, outlier detection, per-downstream limites.
eBPF/Observability par L4/L7, limites de connexion, protection de la tête de ligne.
Passerelles API internes pour les S2S, rate-limit général et audit.
VPC/sous-réseaux par zone blast, contrôle NAT/Egress, peering avec les fournisseurs.

8) Performance : Tests et preuves

Load & stress dans le profil prime-time + worst-case.
Soak (longue durée) - fuites de mémoire/descripteurs, croissance de latitude.
Chaos/game-days : chute du courtier/fournisseur/zone, « fournisseur lent ».
Régression de perf en IC : ensemble de scénarios de référence et de gates automatiques.

9) Données et référentiels : Stratégies de croissance

Hauteur verticale jusqu'au « plafond » → horizontal/sharding.
Lectures → répliques/cache ; Entrées → batchi/asynchrone/journal.
Migrations de schémas : expand → migrate → contract, sans verrous globaux.
Archivage : lots froids dans un stockage bon marché + ré-hydrogénation à la demande.
Recherche : Index individuel (OpenSearch/Solr) avec pipline de mises à jour incrémentielles.

10) Gestion des fournisseurs et des quotas

Carte des quotas (TPS, fenêtres, valeur) ; alert'utilisation _ ratio> 0. 9`.
Itinérance par coût/qualité (routage intelligent).
Les accords OLA ↔ SLO et le processus d'augmentation des quotas.
Pool d'alternatives et commutation « chaud ».

11) Observabilité et signaux d'échelle

• Capacity headroom по слоям; `queue_lag/backlog growth`; `kafka ISR`; `db connections`/`repl lag`; `redis evictions`; `open_circuit`/`retry_rate`; `quota_usage`.
• Mesures d'entreprise : taux de réussite/conversion de dépôt, heure de lancement du jeu.
• Coût : cost/RPS, cost/1k calls.

• Aperçu de la capacité (headroom, risques supérieurs, SLO de taux de croissance).
• Stream & Queue Panel (lag/backlog, consumer saturation).
• DB & Cache (p99, connexions, hit/evictions).
• Providers & Quotas (TPS, timeouts, coût, commutation).
• Change Safety (avant/après la sortie, canari, auto-gates).

ALERT HeadroomLowAPI
IF capacity_headroom{layer="api"} < 0. 15 FOR 10m

ALERT KafkaBacklogAtRisk
IF (consumer_lag > 5e6 AND rate(consumer_lag[5m]) > 5e4) AND (hpa_desired == hpa_max) FOR 10m

ALERT DBConnectionsNearMax
IF active_conns / max_conns > 0. 85 FOR 5m

ALERT ProviderQuota90
IF usage_quota_ratio > 0. 9 FOR 5m

12) FinOps : mise à l'échelle bénéfique

Facteurs d'efficacité : cost/RPS, cost/dépôt, cost/1k événements.
Right-sizing : VPA/recommandations, rapports « over-provisioned ».
Spot/Préemptible pour non critique ; Reserved/Committed pour la charge de base.
Budget egress et mise en cache, CDN/edge-offload.
Collecte et archivage des logs par niveau de valeur (hot vs cold).
Quotas d'avertissement (soft-cap) et auto-tickets d'extension.

13) Processus et personnes

Gestion du changement : canaris, ficheflags, arrêts en cas de régression.
Incident de préparation : runbook 'et « où ajouter de la capacité », « comment changer de région ».
Planification des pics : calendrier des matchs/tournois/campagnes et fenêtres des fournisseurs.
Jeux réguliers et exercices DR.
Matrice de propriété : qui peut « serrer le bouton » sur le faucher/augmentation des quotas.

14) Chèques-feuilles de mise en œuvre

• Carte des chemins et limites critiques (par couches), objectif headroom ≥ 30 %.
• HPA for Business Metrics + Cluster Autoscaler ; PDB/SpreadConstraints.
• Files d'attente sur les chemins chauds, idempotency-keys, outbox.
• Caches : objectifs hit ≥ 90 %, politique des événements, indices clés.
• DB : répliques de lecture, pool de connexions, plan de partage.
• Fournisseurs : multi-fournisseurs, quotas, breakers/retrai.
• Dashboards « Capacity/Stream/DB/Providers », alertes du § 11.
• Canaris et auto-gates « avant/après la sortie ».
• DR-pleybuk et une formation de faussaire partielle.

• Échauffement des caches, avant-scène HPA/ASG, répliques warm-standby.
• Augmentation des quotas des fournisseurs, inclusion du routage intelligent.
• Activation du mode de suppression de nuit pour les alertes non critiques.
• Ficheflag « mode sûr » est prêt pour l'allumage instantané.

15) Anti-modèles

Mise à niveau verticale « jusqu'à butée » au lieu de l'horizontale.
Un pool commun de flux/connexions sur tous les downstream (head-of-line).
Rétrospective sur les timaouts des goulets d'étranglement, absence de jitter → tempête.
Il n'y a pas d'hystérésis dans les alertes et les politiques scales → « sciage ».
Une base de données mondiale unique sans partage et localisation des données.
Croyance aveugle dans le SDK du vendeur sans contrôle des temporisateurs/rétroactifs/observabilité.
L'absence d'exercices DR : un faussaire « sur papier seulement ».

16) KPI d'évolutivité

Conformité SLO au sommet (p95/p99, taux de réussite).
Headroom par couches en prime time.
MTTS (Mean Time To Scale) - avant l'apparition de ressources supplémentaires.
Backlog/Lag Resolution Time - Temps de saisie des files d'attente après le pic.
Taux d'échec de changement pour une période de croissance active.
Cost/RPS et économies de cache/CDN/edge-offload.
DR Lecture : RTO/RPO en exercice.

17) Exemples de modèles « rapides »

partitions(topic="bets") = ceil(peak_msgs_per_sec / target_msgs_per_partition)
consumers = min(partitions, max_pods); rebalance_on: skew > 1. 5x scale_up_if: lag > 5e5 && rate(lag[5m]) > 5e4

max_connections = poolers pool_size 1. 3 read_routing: primary (write), replicas (read majority)
shard_key: tenant_id or region_id

maxmemory-policy: allkeys-lfu cluster-replicas: 1 evict-alert: rate(evictions[5m]) > 0 && used_mem/limit > 0. 8

guardrails:
- metric: api_p99_ms, threshold: 1. 3 baseline_1d, window: 10m, action: pause_and_rollback
- metric: error_rate, threshold: 2 baseline_1d, window: 5m, action: pause max_step: 10%
step_interval: 15m

18) FAQ

Q : Que mettre à l'échelle en premier ?
R : Goulets d'étranglement selon les données dashboards : files d'attente/caches/lectures OBD. Les chemins d'accès (dépôt/mise/lancement du jeu) sont prioritaires.

Q : Comment comprendre que la mise à l'échelle automatique « rend pire » ?
R : Voir corrélation : scale- up↑, et p99/erreurs ne s'améliorent pas - peut-être que vous « mettez à l'échelle le problème » (downstream étroit/quota). Allumez les casseurs/dégradation.

Q : Avez-vous toujours besoin d'un deuxième fournisseur ?
R : Pour les voies critiques, oui. Sinon, au moins un « mode sécurisé » avec un script et un cache simplifiés.

Q: Active-active или active-passive?
R : Si les exigences de RTO sont faibles et beaucoup d'acteurs régionaux - active-active. Sinon, commencez par active-passive avec un faussaire usagé.