Sorties Blue-Green et Canary

(Section : Architecture et protocoles)

1) Pourquoi faut-il des « jetons sûrs » ?

Dans les systèmes modernes, la sortie n'est pas seulement la livraison de code, mais aussi une expérience gérée dans la vente : nous minimisons simultanément le risque (ne cassons pas les utilisateurs) et réduisons le temps de rétroaction (voyons rapidement l'effet). Deux stratégies classiques - Blue-Green et Canary - le résolvent différemment, mais avec un objectif commun : le downtime zéro, le recul rapide, l'observation par SLO.

2) Définitions de base

Blue-Green

Nous gardons deux copies complètes de l'environnement : actif (Bleu) sert le trafic, passif (Vert) prépare une nouvelle version. Commutation - atomique (switch/flip) au niveau de l'équilibreur/routeur. Si ça empire, on retourne à Blue.

Canary

Nous roulons en morceaux : d'abord un petit % du trafic (par exemple, 1-5 %), nous observons les métriques/SLO, puis nous augmentons la part (10 % → 25 % → 50 % → 100 %). En cas de dégradation, le retour ou l'arrêt à l'étape stable précédente.

3) Quand quelle approche est la meilleure

• Il faut un retour instantané sans manœuvres difficiles.
• L'architecture/budget permet une double duplication des infrastructures.
• Nous voulons passer les migrations graduées ou les rénovations du quai (OS/JDK/rantajm) isolément.
• L'application/pool de composés est sensible à l'état « mixte » progressif.

• Vous devez minimiser le rayon blast et voir le comportement sur la proportion d'utilisateurs.
• Taux de sortie élevé, livraison progressive comme la norme.
• Il y a une observabilité mature et des gates automatiques (error budget, latency, conversion).
• L'équipe de produits veut vérifier les hypothèses : impact sur la conversion, la rétention, LTV, etc.

4) Principes généraux d'une sortie réussie

Idempotent-artefacts : même image/paquet à toutes les étapes.
Configuration déterministe : configh comme code, comparabilité des environnements.
Observabilité par design : logs, métriques, tracés, alertes ; SLI/SLO à l'avance.
Retour rapide et automatique : le bouton/commande de retour est une partie de la pipline, pas de la magie manuelle.
Modifications compatibles des schémas : stratégie expand-migratoire-contrat (voir § 10).
Routage au niveau L7 (de préférence) : flexibilité par en-têtes/cookies/chemins/versions API.

5) Blue-Green : Architecture et processus

5. 1 Topologie

Deux piles : Blue (actif) et Green (candidat).
Dépendances externes communes : CDN, API externes, files d'attente ; L'OBD est un cas particulier (voir § 10).
Point de basculement : Équilibreur/Ingress/Gateway.

5. 2 Flow étape par étape

1. On soulève Green sous un nouvel artefact (vNext), on fait des tests smok.
2. Course auto contre Green (e2e, contrat, régression).
3. On chauffe le cache/sessions (le cas échéant), on synchronise les jobs/files d'attente d'arrière-plan.
4. Nous passons au trafic vert : flip atomique (DNS TTL bas, Route/Listener swap, Ingress weight = 100 %).
5. Nous observons SLO dans les premières minutes/heures (signaux d'or : latitude, erreurs, saturation + métriques d'affaires).
6. En cas de problème, retour instantané à Blue (flip back).

5. 3 Avantages/inconvénients

Avantages : retour instantané, modèle mental simple, isolation pure.
Inconvénients : doublement de l'infrastructure, complexité avec les composants stateful et les migrations de données.

6) Canary : Architecture et processus

6. 1 Topologie

Un cluster unique ; plusieurs versions du service (stable et canary) derrière un front uni.
Le trafic est divisé en poids (1-5-10-25-50-100 %) ou en ciblages (par titre/cookie/ID).

6. 2 Flow étape par étape

1. Version canariale déplie dans le même cluster/ASG/NSG.
2. Routage d'une partie du trafic (par exemple 1-5 %) sur canary.
3. Contrôles automatiques SLI/SLO et métriques d'entreprise ; gates en CI/CD (taux d'erreur, p95 latency, CPU/RES, conversion, refus/retour).
4. Augmentation progressive de la part du trafic lors du passage des gates.
5. Rollout complet jusqu'à 100 % et désactivation de l'ancienne version ; en cas de dégradation, auto-rollback.

6. 3 Avantages/inconvénients

Avantages : risque minimum pour la plupart des utilisateurs, solution data-driven.
Inconvénients : il faut une observation mature, un routage compétent, un risque de « version skew » entre les instances.

7) Routage du trafic

Niveau L4 : équilibre par IP/ports ; simple, mais peu flexible.
Niveau L7 : règles HTTP/S - par chemin, hôte, en-tête, poupées, agent utilisateur, GeoIP, SNI.

• Routage Weighted (poids 1-100 %).
• Header-based/Cookie-based (verrouillage d'un utilisateur dans un groupe).
• Stick....session (important pour les scripts stateful/cache).
• Shadow/Traffic mirroring (nous mirons les requêtes dans la nouvelle version « virage »).

8) Outils et implémentations (exemples)

Kubernetes: Ingress (NGINX, Contour), Service Mesh (Istio/Linkerd), Argo Rollouts, Flagger.
Облака: AWS ALB/ELB, Route 53 weighted records, ECS/EKS; GCP Load Balancing + NEG; Azure Front Door/App Gateway.
Plates-formes CD : Spinnaker, Argo CD, GitHub Actions + plugins de livraison progressive, GitLab/CD.

9) Observabilité, SLI/SLO et gates

Golden signals: Latency (p95/p99), Error rate (5xx/4xx по типам), RPS, Saturation (CPU/Memory/GC), Queue lag.
Mesures d'affaires : conversion, autorisations, paiements/succès, chèque moyen, refus par étape d'entonnoir.

• Seuil d'erreur (par exemple, error rate canary ≤ baseline + X %).
• La latence p95 n'est pas pire que la baseline à plus de Δ.
• Seuil commercial (par exemple, baisse de conversion
• Le budget d'erreur SLO ne doit pas brûler plus rapidement.

Durée de l'étape : minimum de temps suffisant pour la signification statistique (dépend du trafic).

10) Migration OBD et compatibilité des schémas

La règle principale est que les versions sont sécurisées si les versions arrière et avant sont compatibles.

1. Expand : nous ajoutons de nouvelles colonnes/index/tables sans casser l'ancienne version.

2. Deploy app vNext (lit/écrit dans un nouveau schéma, mais sait aussi travailler avec l'ancien).

3. Données migratoires (background/batch, idempotent, avec chekpoints).

4. Contrat : nous supprimons les anciens champs/fiches après stabilisation.

Anti-modèles : migrations nécessitant un verrouillage exclusif au moment de la commutation Blue-Green ; l'impossibilité de doubler le système ; « double enregistrement » sans déduplication.

11) Retour (rollback) et plans d'accident

Blue-Green : flip instantané sur Blue ; Nous surveillons les « queues » des jobs de fond verts.
Canary : perte de poids (par exemple, 25 % en arrière de 5 % ou 0 %) ; abort automatique sous alerts.
Données : politique réfléchie de répétition/compensation (clés d'identité, modèle « inbox/outbox », déduplication des messages).
Ficheflagi : kill switch rapide pour désactiver les possibilités partiellement déployées.

12) Travailler avec le steat et les sessions

Sticky sessions pour les canaries, ou stocker des sessions à l'extérieur (Redis/Memcached) pour que les versions soient interchangeables.
Chauffer le cache à l'avance (Green warm-up) et tenir compte de l'invalidation lors du flip.
Workers de fond : ne tolérez pas les « courses » entre les versions - séparation des files d'attente ou « leadership » selon la version.

13) Sécurité et conformité

Accès à Green/Canary - par Zero Trust : comptes de service, rôles minimes requis.
Secrets et clés - via KMS/Secrets Manager ; activer la rotation.
Trafic - TLS uniquement ; les versions endpoint's sont clairement marquées ; audit du routage et des actions de sortie.

14) Coût et performance

Blue-Green double l'infrastructure (pour la durée de la sortie ou en permanence) - fixez un budget.
Canary est plus économique, mais nécessite des outils d'observation et du temps d'ingénierie pour l'automatisation.
Optimisation : auto-skating, environnement ephemeral, réduction de la fenêtre d'existence parallèle des versions.

15) Chèques-feuilles

Avant la sortie

• L'image/le billet est promu à partir d'une seule source, les signatures sont vérifiées.
• Plan de test, alertes et gates SLO configurés.
• Migration OBD - en mode expand, plans downgrade disponibles.
• Plan de retour - vérifié dans staging/production-like.

Pendant la sortie

• Les métriques et les logs sont comparés à la baseline.
• Pour Canary, les étapes et les seuils sont fixés ; pour Blue-Green, la volonté de flip-back.
• Les commandes sont au courant, il y a une fenêtre de rétroaction.

Après la sortie

• SLO n'a pas perdu, error budget est normal.
• Migration/nettoyage post-release terminé.
• Rétrospective et mise à jour des playbooks.

16) Erreurs fréquentes et anti-modèles

Jeté sans métriques : pas de données - pas de solution gérable.
Mélange de schémas OBD incompatibles, pas de stratégie downgrade.
Mélange aléatoire du trafic : pas de stick...., les utilisateurs « sautent » entre les versions.
Dépendances stateful masquées (disques locaux, cache in-memory).
Une longue DNS-TTL empêche un flip rapide (Blue-Green).
L'absence de gages automobiles : les solutions manuelles freinent et augmentent les risques.

17) Approches combinées

Bleu-Vert + Canary : d'abord faire rouler Green, puis à l'intérieur de Green faire rouler Canary pour les services individuels.
Shadow/trafic migratoire : avant Canary, nous chassons le trafic miroir dans la nouvelle version.
Feature flags (livraison progressive) : la fonctionnalité est activée au-dessus de la version stable avec des drapeaux « foncés » par segment.

18) Exemples de scénarios (croquis)

1. Nous déployons Green (v2) derrière le nouveau Listener/Ingress.

2. On chauffe les caches, on fait des vérifications de lecture, smoke.

3. On passe au poids vert = 100 %.

4. Nous observons SLO 30-60 minutes ; si tout va bien, on éteint Blue.

1. Canary vNext (répliques 5 %).

2. Nous incluons un trafic de 5 % pour les comptes internes/segment de test.

3. Auto gate : error rate ≤ baseline + 0. 3%, p95 ≤ +20ms.

4. On soulève 10 % → 25 % → 50 % toutes les N minutes au passage des gates.

5. Nous traduisons 100 % ficheflag sur tous les segments ; Nous supprimons l'ancienne version.

19) Variations pour différentes architectures

Monolithe : Blue-Green est plus facile, Canary est plus difficile en raison de l'indivisibilité de la fiche ; utilisez des ficheflags.
Microservices : Canary est naturel ; surveillez les contrats interservices (contrats consumer-driven).
Services Stateful : préférez Blue-Green avec des migrations et des stick....soigneusement conçus.

20) Brève comparaison (résumé)

Vitesse de retour : Bleu-vert = instantanément ; Canary = rapide, mais avec une perte de poids.
Coût de l'infrastructure : Blue-Green ↑ ; Canary ↔︎/↓.
Risque pour les utilisateurs : Canary ci-dessous (nous contrôlons la proportion).
Difficulté de mise en œuvre : Blue-Green est plus facile à démarrer ; Canary exige une forte observabilité et automatisation.
Compatibilité des données/schémas : critique pour les deux ; planifiez expand-migrate-contract.

21) Résultat

Blue-Green et Canary ne sont pas des stratégies mutuellement exclusives, mais des éléments de livraison progressive. Le choix dépend des contraintes de coût, de maturité de l'observation et de la nature des changements. Quelle que soit l'approche, la sortie durable repose sur quatre piliers : automatisation, observabilité, rétrocompatibilité et retour rapide.