PD-247 — Scalabilité horizontale linéaire — auto-scaling microservices (doc 41)¶

Epic : INFRA (PD-193) Sprint : Backlog — Phase 3 roadmap (12–18 mois) Priorité : Low Projet : infra

1. Contexte et motivation¶

1.1 GAP-5 — Engagement architectural non couvert¶

Le document Architecture TechLead (doc 41) stipule :

"Montée en charge linéaire — architecture microservices"

Le cross-référencement des documents corporate (41, 42, 43) avec les spécifications techniques révèle qu'aucune story existante ne couvre les mécanismes d'auto-scaling. Les stories infra existantes couvrent :

• PD-1 — VPC Terraform (infrastructure de base)
• PD-2 — PostgreSQL OVH (base de données)
• PD-7 — HSM FIPS 140-2 (cryptographie)
• PD-8 — Vault (secrets management)

Mais aucune ne traite la scalabilité horizontale dynamique des microservices.

1.2 Position dans le roadmap¶

Cette story est placée en backlog car le roadmap produit prévoit ces capacités en Phase 3–4 :

2. Objectif¶

Définir et implémenter les mécanismes de scalabilité horizontale linéaire des microservices ProbatioVault, garantissant que la capacité de traitement croît proportionnellement au nombre d'instances déployées, conformément aux engagements architecturaux du doc 41.

Critère de linéarité : 2N instances → throughput ≥ 1.7 × throughput(N instances) (coefficient d'efficacité ≥ 0.85).

3. Périmètre¶

3.1 Inclus (Phase 3 — sans Kubernetes)¶

• Configuration auto-scaling OVH (instances VM dynamiques)
• Redis Cluster pour scaling horizontal du cache
• Keepalived/VRRP pour load balancing haute disponibilité
• Métriques de scaling (CPU, RAM, requêtes/s via Prometheus)
• Tests de charge linéaire (benchmark N instances vs N×throughput)
• Dashboard Grafana — visualisation scaling en temps réel

3.2 Inclus (Phase 4 — Kubernetes HPA)¶

• Configuration Kubernetes HPA (Horizontal Pod Autoscaler)
• Seuils de scale-up/scale-down configurables
• PostgreSQL Managed OVH HA (scaling DB)
• SLA de disponibilité en régime scale-up/scale-down

3.3 Exclus¶

• Infrastructure de base VPC (PD-1)
• PostgreSQL initial (PD-2)
• CI/CD pipeline (stories cicd-gouverne)
• Scaling des services cryptographiques HSM (contraintes FIPS 140-2)

4. Architecture cible¶

4.1 Phase 3 — Auto-scaling VM OVH¶

                    ┌─────────────────────────┐
                    │  Load Balancer           │
                    │  Keepalived/VRRP         │
                    │  VIP: 10.0.0.1          │
                    └────────┬───────┬─────────┘
                             │       │
               ┌─────────────┘       └─────────────┐
               ▼                                   ▼
      ┌────────────────┐                  ┌────────────────┐
      │  Backend #1    │  ←── scale-up    │  Backend #N    │
      │  OVH VM        │      (dynamic)   │  OVH VM        │
      └────────────────┘                  └────────────────┘
               │                                   │
               └──────────────┬────────────────────┘
                              ▼
                    ┌─────────────────┐
                    │  Redis Cluster  │
                    │  (3 nodes min)  │
                    └─────────────────┘

4.2 Phase 4 — Kubernetes HPA¶

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: probatiovault-backend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: probatiovault-backend
  minReplicas: 3
  maxReplicas: 50
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

4.3 Métriques Prometheus¶

# Métriques exposées par chaque instance backend
probatiovault_requests_total{method, status, endpoint}
probatiovault_request_duration_seconds{quantile}
probatiovault_active_connections
probatiovault_cache_hit_ratio

5. Invariants¶

6. Critères d'acceptation¶

• CA-247-01 : Un test de charge avec 2N instances produit un throughput ≥ 1.7 × throughput(N instances)
• CA-247-02 : Le HPA déclenche un scale-up automatique quand CPU > seuil configuré pendant > 2 minutes
• CA-247-03 : Le HPA déclenche un scale-down automatique quand CPU < seuil bas pendant > 5 minutes
• CA-247-04 : Aucune perte de session ou de donnée lors d'un scale-down
• CA-247-05 : Le dashboard Grafana affiche les métriques de scaling en temps réel

7. Scénarios de test¶

Scénario 1 — Linéarité du throughput¶

Given N instances backend actives avec un throughput mesuré T(N) When N instances supplémentaires sont déployées (total : 2N) Then le throughput T(2N) ≥ 1.7 × T(N)

Scénario 2 — Scale-up automatique¶

Given le HPA configuré avec seuil CPU à 70% When la charge CPU dépasse 70% sur toutes les instances pendant 2 minutes Then une nouvelle instance est démarrée automatiquement dans les 3 minutes

Scénario 3 — Scale-down sans perte de session¶

Given 10 instances actives avec des sessions utilisateur en cours When la charge diminue et le HPA déclenche un scale-down à 5 instances Then aucune session utilisateur n'est interrompue

Scénario 4 — Minimum d'instances garanti¶

Given le HPA configuré avec minReplicas = 3 When la charge est nulle (nuit, week-end) Then 3 instances restent actives (pas de cold start pour les premières requêtes)

7bis. Diagrammes Mermaid¶

7bis.1 Diagramme d'états — Cycle de scaling HPA¶

Le HPA traverse au moins 4 états distincts. Les transitions sont gouvernées par les seuils CPU/RAM configurables (INV-247-03) et le minimum d'instances garanti (INV-247-04).

stateDiagram-v2
    [*] --> Steady

    Steady --> ScalingUp : CPU > seuil haut (70%)\npendant > 2 min [INV-247-03]
    Steady --> ScalingDown : CPU < seuil bas\npendant > 5 min

    ScalingUp --> Steady : Nouvelles instances ready\nP99 stable [INV-247-02]
    ScalingUp --> ScalingUp : Charge toujours croissante\n(ajout instance supp.)

    ScalingDown --> Steady : Instances drainées\nsessions migrées [INV-247-05]
    ScalingDown --> MinReplicas : replicas == minReplicas (3)\n[INV-247-04]

    MinReplicas --> ScalingUp : CPU > seuil haut (70%)\npendant > 2 min [INV-247-03]
    MinReplicas --> MinReplicas : Charge nulle\n(nuit/week-end)\nreplicas maintenus [INV-247-04]

    note right of Steady
        Throughput linéaire vérifié :
        T(2N) >= 1.7 * T(N) [INV-247-01]
    end note

    note right of ScalingDown
        Drain gracieux obligatoire :
        aucune session perdue [INV-247-05]
    end note

7bis.2 Diagramme de séquence — Scale-up automatique (flux nominal)¶

Interaction multi-service entre Prometheus, HPA, OVH/K8s, Load Balancer, et les instances backend lors d'un scale-up automatique.

sequenceDiagram
    participant P as Prometheus
    participant HPA as HPA Controller
    participant K8S as OVH K8s / VM Orchestrator
    participant LB as Keepalived / LB
    participant B1 as Backend #1..N
    participant BN as Backend #N+1 (new)
    participant RC as Redis Cluster

    Note over B1,P: Charge croissante détectée

    B1->>P: probatiovault_requests_total ↑
    B1->>P: CPU > 70% (seuil INV-247-03)
    P->>HPA: Métriques agrégées (CPU avg > 70%)

    Note over HPA: Évaluation pendant 2 min (CA-247-02)

    HPA->>K8S: Scale-up request (+1 instance)
    K8S->>BN: Provision nouvelle instance
    BN->>RC: Connexion Redis Cluster
    RC-->>BN: OK — session store partagé [INV-247-05]
    BN->>P: Enregistrement métriques
    BN->>LB: Health check OK
    LB->>LB: Ajout backend #N+1 au pool

    Note over LB,BN: Trafic réparti sur N+1 instances

    LB->>B1: Requêtes (part N/(N+1))
    LB->>BN: Requêtes (part 1/(N+1))

    Note over P: Vérification linéarité [INV-247-01] :<br/>T(N+1) >= T(N) * (N+1)/N * 0.85
    P->>HPA: CPU redescend < seuil haut
    HPA->>HPA: Retour état Steady

7bis.3 Diagramme de séquence — Scale-down avec drain gracieux¶

Interaction multi-service lors du scale-down, garantissant aucune perte de session (INV-247-05) et le respect du minimum d'instances (INV-247-04).

sequenceDiagram
    participant P as Prometheus
    participant HPA as HPA Controller
    participant K8S as OVH K8s / VM Orchestrator
    participant LB as Keepalived / LB
    participant BX as Backend #X (à retirer)
    participant RC as Redis Cluster

    Note over P,HPA: Charge basse depuis > 5 min (CA-247-03)

    P->>HPA: CPU avg < seuil bas
    HPA->>HPA: Vérif replicas > minReplicas (3) [INV-247-04]
    HPA->>K8S: Scale-down request (-1 instance)

    K8S->>LB: Retrait backend #X du pool (drain)
    LB->>LB: Stop envoi nouvelles requêtes à #X
    LB->>BX: Attente fin requêtes en cours

    BX->>RC: Flush sessions actives vers Redis [INV-247-05]
    RC-->>BX: ACK — sessions persistées

    BX->>K8S: Graceful shutdown complete
    K8S->>K8S: Terminaison instance #X

    Note over HPA: P99 vérifié stable [INV-247-02]
    HPA->>HPA: Retour état Steady ou MinReplicas

8. Dépendances¶

9. Références¶

• Doc 41 — Architecture TechLead v4.1 (section "Scalabilité" et "Résilience")
• Kubernetes HPA Documentation
• OVH Managed Kubernetes
• Redis Cluster Tutorial

Fin de la spécification PD-247.