Technologie et infrastructure → Architecture cloud et SLA
Architecture cloud et SLA
1) Pourquoi les SLA et comment les gérer
SLA (Service Level Agreement) est une promesse extérieure aux entreprises/partenaires sur la disponibilité, la rapidité et l'exactitude du service.
SLO (Service Level Objective) - Niveaux cibles internes pour les commandes.
SLI (Service Level Indicator) est une métrique mesurable sur laquelle le SLO est évalué.
L'iGaming/fintech est caractérisé par des fenêtres dures de pics (tournois, paris, périodes de déclaration, jours de salaire), une forte dépendance à l'égard des fournisseurs PSP/KYC et de la géographie. Les SLA doivent tenir compte de ce comportement et l'architecture doit fournir des garanties non seulement moyennes, mais aussi percentiles.
2) Terminologie de base
Disponibilité (Availability) : Proportion de demandes réussies par intervalle.
Latence - P50/P95/P99 pour les opérations clés.
Erreur - définissez exactement (5xx, temporisation, erreur professionnelle ?).
RTO (Recovery Time Objective) : Combien de temps vous pouvez récupérer.
RPO (Recovery Point Objective) - Combien de données vous pouvez perdre en cas d'accident.
Error Budget - 1 − SLO, « stock » pour les modifications et les incidents.
3) Cadre d'architecture cloud sous SLA
3. 1 Multizonalité (Multi-AZ)
Réplication d'état (OBD, cache, file d'attente) à un minimum de 2-3 AZ.
Standbye froid/chaud, échouage automatique.
Équilibreurs locaux (L4/L7) avec chèques santé per-AZ.
3. 2 Multiregion
Atout : Faible RTO/RPO, consistance et coût plus complexes.
Actif-passe (hot/warm) : moins cher, le RTO est plus grand, mais le contrôle des données est plus facile.
Itinéraire géographique (GeoDNS/Anycast), isolation « blast radius ».
3. 3 Entrepôts et données
Bases de données transactionnelles : réplication synchrone au sein d'une région, interrégionale asynchrone.
Cache : répliques croisées, mode « local reads + async warmup ».
Stockage d'objets : versioning, boucles de vie, replication cross-région.
Files d'attente/streaming : clusters miroirs/flux multi-régionaux.
3. 4 Isolation des circuits
Séparation des services critiques (payments/wallet) et des tâches analytiques « lourdes ».
Rate-limits/quotas entre les boucles afin que les rapports ne « mangent » pas la prod.
4) Modèles de haute disponibilité
Bulkhead & Pool Isolation - Isolation des pools de connexions et de ressources.
Circuit Breaker + Timeouts - protection contre la dépendance des intégrations externes.
Idempotency - nous répétons les demandes sans double débit.
Graceful Degradation - Lors de la dégradation, nous désactivons les fiches non tundamentales (avatarks, filtres étendus).
Backpressure : Contrôlez le flux entrant, empêchez les files d'attente jusqu'à l'horizon.
Chaos/Failure Injection sont des « échecs » planifiés pour tester les hypothèses de fiabilité.
5) Stratégies DR (Disaster Recovery)
Choix : paiements/portefeuille - minimum Hot Standby ; contenu/catalogue - Warm ; Rapports - Backup & Restore avec des fenêtres claires.
6) Sur SLI/SLO : comment mesurer correctement
6. 1 SLI par niveau
SLI client : end-to-end (y compris la passerelle et les fournisseurs externes).
Service SLI : latence « pure »/erreurs de service.
Business SLI : CR (registratsiya→depozit), T2W (time-to-wallet), taux PSP-decline.
6. 2 exemples de SLO
Disponibilité de l'API Core : ≥ 99. 95 % en 30 jours.
Latence d'initiation payout : P95 ≤ 350 ms, P99 ≤ 700 ms.
Livraison des webhooks PSP : ≥ 99. 9 % pendant 60 secondes (avec retraits).
Rapports de données Freshness : ≤ 10 min lag dans 95 % des cas.
6. 3 Error Budget Policy
50 % du budget est consacré aux changements (sorties/expériences), 50 % aux incidents.
La combustion du budget → la frise, juste la stabilisation.
7) Performances et évolutivité
HPA/VPA avec signaux orientés SLO (non seulement CPU, mais aussi files d'attente/latence).
Skaling prédictif basé sur les horaires et les pics historiques.
Warm pools/pré-échauffement des connexions à la base de données/PSP avant les tournois.
Cache et edge - Réduire la RTT, en particulier pour les répertoires de jeux et les assets statiques.
8) Couche réseau et trafic global
Anycast/GeoDNS pour minimiser la latence et la localisation des accidents.
Politiques d'échec : échantillons de santé de la région, seuils, « stick.... » avec TTL.
mTLS/WAF/Rate Limit au bord, protection contre le trafic de bot.
Contrôle egress à PSP/KYC par allow-list et retraits SLA-aware.
9) Données et consistance
Choix du niveau de cohérence : rigoureux (payments) vs eventual (catalogue/classements).
CQRS pour décharger la lecture et les verticaux des commandes critiques.
Outbox/Inbox pour la livraison d'événements « exactement une fois ».
Migrations sans downtime : expand-migrate-contract, double enregistrement pendant les changements MAJOR.
10) Observabilité (Observability) sous SLA
Traces via la passerelle : corrélation 'trace _ id' avec le partenaire/région/version de l'API.
SLO-dashboards avec burn-rate, « météo » par région et fournisseurs.
Alertes par symptômes et non par symptômes proxy (pas CPU, mais P99/erreurs).
Synthétiques : contrôles externes des pays du target (TR, BR, EU...).
Audit et reporting : Exporter SLI/SLO vers un portail partenaire.
11) Sécurité et conformité
Segmentation des réseaux et gestion des secrets (KMS/Vault).
Cryptage en vol/repos, Tokenization PAN/PII.
Politiques d'accès par rôle pour les amiraux/opérateurs.
Logs immuables (WORM) et rétentions pour l'audit.
Réglementation : stockage dans la région, rapports, probabilité de l'exécution du SLA.
12) FinOps : SLA comme moteur de valeur
Mettez les prix sur SLO déviations : combien coûte + 0. 01 % de disponibilité ?
Profilez les fenêtres de pointe, ne gonflez pas la puissance constante.
Right-sizing et « spot où tu peux » pour les tâches d'arrière-plan.
Quotas et budgets pour les circuits, ne tolérez pas la dégradation « gratuite ».
13) Tests de fiabilité
Session GameDay/Chaos : désactivation AZ/PSP, retards dans les files d'attente, interruptions BGP.
DR-dry : formation régulière pour changer de région avec des objectifs de RTO.
Load & Soak : longues courses avec de vrais profils de paris/tournois.
Incidents de replay : bibliothèque de faisceaux connus et de scripts de lecture.
14) Le côté processeur de la SLA
Catalogue SLO : propriétaire, formule, métriques, sources, alertes.
Changements via RFC/ADR : évaluation de l'impact sur le budget error.
Postmortems : amélioration de l'architecture et des rangements, ajustement de SLO.
Communications avec les partenaires : bulletins d'information, page de statut, maintenance planifiée.
15) Exemples de SLI/SLO/rapports
15. 1 Formules
SLI_availability = (успешные_запросы / все_запросы) 100%
SLI_latency_P99 = перцентиль_99(латентность_запроса)
SLI_webhook_D+60 = доля вебхуков, доставленных ≤ 60 сек15. 2 Exemple de jeu de SLO pour l'API Core
Disponibilité (30 jours) : 99. 95%
P95 endpoint '/v2/payouts/create ': ≤ 350 ms
Erreurs 5xx (glissant 1 h) : <0. 3%
Webhook delivery ≤ 60 сек (P99): ≥ 99. 9%
RPO pour portefeuille : ≤ 60 secondes, RTO ≤ 5 min
15. 3 Rapport SLA (pressing)
Fait par : 99. 97% (SLO 99. 95%) +
Violations : 2 épisodes dans la région BR en raison des temps PSP (cumulés de 8 min).
Mesures : ajout d'un routage intelligent par code de défaillance, augmentation du pool de connexion warm à PSP-B.
16) Chèque de mise en œuvre
1. Les chemins utilisateur critiques et les SLI correspondants ont été définis.
2. SLO pour 30/90 jours + error budget policy.
3. Multizonalité et plan de RD avec des objectifs RTO/RPO, régulièrement flashé.
4. Synthèse de géo-target, dashboard per-region/per-PSP.
5. Modèles de résilience : circuit breaker, backpressure, idempotency.
6. Stratégie de dégradation et flags de fonctionnalité pour les fiches à désactiver.
7. FinOps : budgets par contours, prévisions des pics, pools warm.
8. Sécurité : segmentation, cryptage, audit.
9. Documentation SLA pour les partenaires, processus de communication.
10. Rétrospective et révision du SLO tous les 1 à 2 trimestres.
17) Anti-modèles
Promettez un SLA sans SLI mesurable et une technique de comptage transparente.
Compter la disponibilité « à l'entrée du service » en ignorant la passerelle/les fournisseurs.
S'appuyer uniquement sur la latence moyenne en ignorant les résidus P99.
DR « sur papier », manque de vrais entraînements.
Ressources « éternelles » sans limites : un rapport vole la prod.
Mélanger la prod et l'analyse lourde dans un seul cluster/OBD.
18) Résultat
L'architecture cloud sous SLA est une combinaison de patterns techniques (multi-AZ/région, isolation, données tolérantes aux pannes), de processus (SLO, error budget, DR-dri) et d'économie (FinOps). Donnez-vous le droit aux pannes prévues : testez la tolérance aux pannes, mesurez par percentiles, limitez le « rayon d'explosion » et communiquez ouvertement. Alors les promesses de SLA ne deviendront pas un marketing, mais une pratique d'ingénierie gérée.