Stratégies de sortie : bleu-vert et canary

(Section : Technologie et infrastructure)

Résumé succinct

Le bleu-vert vous permet de basculer instantanément entre deux piles pleines (bleu/vert) avec le retour le plus simple. Canary augmente progressivement la part du trafic sur la nouvelle version sous le contrôle des jeux SLO (latence, taux d'erreur, métriques d'affaires). Pour iGaming, c'est une façon de sortir sans downtime au sommet des tournois et des promotions, tout en conservant une p99 et une qualité stables.

1) Quand quoi choisir

Blue-green - versions rapides, complexité minimale, besoin d'un budget « double » de cluster/ressources. Bon pour API/front sans migration d'état complexe.
Canary - les sorties à haut risque (nouvelles flocons, changements critiques), permet de « capturer » la dégradation de 1 à 5 % du trafic. Nécessite la télémétrie et des gats automatiques.

2) Principes architecturaux

1. Routage au niveau L7 : équilibreur/Ingress/service-mesh (modules de trafic pondéré, cookie/flag-routing).
2. Dépendances isolées : configurations, ficheflags, secrets, caches - séparément pour les révisions.
3. Compatibilité des données : Migration des systèmes OBD compatibles (expand→migrate→contract).
4. Observabilité : étiquettes individuelles/étiquettes de version en métriques/logs/tracés.
5. Auto-gates : comparaison p95/p99, taux d'erreur, KPI d'entreprise ; rollback automatique.

3) Bleu-vert : modèle de base

Flux

1. On déploie Green (copie de Blue) → on réchauffe les caches/connexions.
2. Nous lançons des tests santé/smoke.
3. Nous passons du trafic (DNS/LB/Ingress) au trafic vert.
4. Nous gardons Blue dans un état « chaud » comme fallback jusqu'au bout de la fenêtre.

Exemple : basculer au niveau Ingress (idée)

yaml
Annotated/Backend Option - In Prod, it is usually controlled by the spec operator/rollout:
rules:
- host: api. example. com http:
paths:
- path: /
backend:
service:
name: api-green # used to be api-blue port:
number: 80

Avantages/inconvénients

Un simple rebond (ramené par Blue).
Temps de sortie prévisible.
Nécessite un double emploi des ressources.
Risque de « big bang » sans mesure canarienne.

4) Canary : développement progressif

Flux

1. Le trafic shadow (en option) → 1 % du trafic réel → 5 % → 25 % → 50 % → 100 %.
2. À chaque étape, des gates SLO/métriques d'affaires.
3. Lors de la dégradation - auto-retour et conservation des artefacts de diagnostic.

Exemple : Argo Rollouts (fragment)

yaml apiVersion: argoproj. io/v1alpha1 kind: Rollout metadata: { name: payments-api }
spec:
strategy:
canary:
canaryService: payments-canary stableService: payments-stable steps:
- setWeight: 5
- pause: { duration: 5m }
- analysis:
templates:
- templateName: slo-latency
- setWeight: 25
- pause: { duration: 10m }
- analysis:
templates:
- templateName: error-rate
- setWeight: 50
- pause: { duration: 20m }
- setWeight: 100

Exemple : Flagger + Istio/NGINX (idée)

yaml apiVersion: flagger. app/v1beta1 kind: Canary metadata: { name: games-api }
spec:
targetRef:
apiVersion: apps/v1 kind: Deployment name: games-api service:
port: 80 analysis:
interval: 1m threshold: 5 metrics:
- name: request-success-rate thresholdRange: { min: 99 }
- name: request-duration thresholdRange: { max: 300 }
webhooks:
- name: smoke url: http://tester/smoke

5) Chauffage et contrôle de l'état

Caches/sources : Réchauffez le cache Redis/HTTP/CDN, préparez le pool de connexion warm à la base de données/PSP.
ML/LLM/modèles : balayage des poids/indices/embeddings, cache KV, requêtes primaires pour « réchauffer ».
Fichiers/artefacts : contenu statique, modèles, configurations - fournir à l'avance dans le volume/sidecar local.
Ficheflagi : rollout pour 1 à 5 % du public/segment, possibilité d'emergency-kill.

6) Bases de données : stratégie « expand → migrate → contract »

1. Expand : ajoutez nullable/nouvelles colonnes/index, supportez les deux versions.
2. Migrate : le code utilise un nouveau schéma ; les anciennes voies restent valides.
3. Contrat : nous supprimons les anciens champs/index après avoir complètement scanné.

Dans les journaux, enregistrez la version du schéma et du client ; toutes les modifications sont idempotentes.
Pour les migrations lourdes - jobs de fond, throttling et « stop-the-world » fenêtres d'accord.

7) Observabilité et Gates (SLO/SLA)

Mesures SRE : p50/p95/p99, taux d'erreur, saturation (CPU/GPU/IO), queue-depth, temps de démarrage à froid.
Mesures commerciales : conversion des paiements, taux de réussite, temps de retrait (TTW), réponses promotionnelles.
Qualité du contenu/LLM : tokens/s, longueur de réponse, toxicité, score RAG.
Gates : Auto-promotion/reculez au-delà des seuils et/ou à la chute de la « métrique utile ».

gate:
p95_latency_ms <= 250 error_rate %  <= 1. 0 payment_conv  >= baseline - 0. 3%
action:
promote      rollback

8) Sortie-orchestration et intégration avec CI/CD

GitOps : Modifications de version/poids - via PR dans le référentiel manifeste.
Contrôle automatique : smoke/e2e avant le début du trafic.
Plan de sortie : calendrier des étapes canaries, responsables, chaines ChatOps, fenêtres de retour.
Archivage des artefacts : configurations de routage, snepshots de dashboards, logs de comparaison de métriques.

9) Multi-région et edge

Ordre : d'abord la région « la moins critique »/RR, puis les principales.
Routing basé sur le latin : suivez les SLO locaux ; ne mélangez pas le trafic sans raison.
DR-vision : Blue in the region-A pourrait devenir un site DR pour Green dans la région-B.

10) Sécurité et conformité de sortie

Images/charts signés, SBOM ; vérification des signatures dans les admissions-politiques.
Secrets : seulement les gestionnaires externes ; versions indépendantes pour Blue/Green.
PII/Régionalité : Ne détournez pas le trafic de PII à travers une région « étrangère » ; masquer les logs lors de la comparaison.
Audit : qui a promu, quels gates ont fonctionné, où est le retour.

11) Exemples de configurations

NGINX : branche canarienne par cookie/titre (idée)

nginx map $http_x_canary $canary {
default 0;
"1"   1;
}

upstream api_stable { server stable:80; }
upstream api_canary { server canary:80; }

server {
location / {
if ($canary) { proxy_pass http://api_canary; }
proxy_pass http://api_stable;
}
}

Feature-flag « fractional rollout » (pseudo)

yaml feature: new_checkout rollout:
percentage: 5 criteria:
country: ["TR", "BR", "MX"]
cohort: "new-users"
kill_switch: true

12) Runbooks (scénarios types)

La croissance p99 sur канаре : arrêter промоушен → augmenter batch/timeout, déconnecter lourd фичи dans les drapeaux → redémarrer la partie подов.
Baisse de la conversion des paiements : comparer les itinéraires PSP/fiches, activer le shadow loging, revenir à stable.
Problème avec la migration OBD : geler le trafic en écriture, activer le mode read-only, annuler le schéma (si possible), les jobs de correction d'urgence.
L'incident PII : couper la version canarienne, revoquer les secrets, le rapport et l'audit.

13) Chèque de mise en œuvre

1. Définir la politique : où est le bleu-vert, où est le canary ; ce qui est considéré comme « critique ».
2. Configurez le routage pondéré (Ingress/mesh/routeur).
3. Fixez les gates SLO-seuil et les auto-reculs.
4. Mettre en œuvre les expand→migrate→contract pour l'OBD ; tests de migration.
5. Activez le chauffage des caches/modèles et des connexions warm-pool.
6. Entrez GitOps et journalisez toutes les activités de sortie.
7. Visualiser la comparaison des métriques (vs canarien stable).
8. Effectuez un game-day : simulez un back/échec gate/problème OBD.
9. Documentez les runbooks et le « bouton rouge » (kill-switch).
10. Planifiez des sorties multi-régions à tour de rôle plutôt qu'en même temps.

14) Anti-modèles

Sortie canarienne sans gates et télémétrie → détection tardive des dégradations.
Mélange du schéma OBD : annihilant les migrations jusqu'à la scission du code.
Un cache/file d'attente partagé pour Blue et Green sans isolation → une influence réciproque.
Basculement DNS avec faible TTL sans vérification - « flapping » du trafic.
Les secrets/confidences communs aux deux révisions → un retour en arrière complexe.
Le trafic dans la prod sans shadow/smoke est un risque de « big bang ».
Absence de kill-switch/feature-flag pour un arrêt rapide.

Résultats

Blue-green permet une commutation instantanée et facile, canary - risque géré et détection précoce des problèmes. Dans iGaming, les deux schémas sont combinés : canard sur les changements « aigus » + bleu-vert comme mécanisme de base sans downtime. Ajoutez des gates SLO, des GitOps, de l'échauffement, de la compatibilité OBD et de l'isolation des dépendances - et les versions seront prévisibles, les retraits rapides et les mesures p99 et commerciales stables même en période de pointe.