2.4 - Mise à l'échelle et répartition de charge
L'objectif 2.4 du Cloud+ CV0-004 couvre la mise à l'échelle et la distribution des charges. Un groupe d'auto-scaling ajoute ou retire automatiquement des instances selon des règles de demande, pour que la capacité suive la charge et éviter de payer des serveurs inactifs. Un répartiteur de charge distribue les requêtes entrantes sur plusieurs serveurs pour l'évolutivité et la résilience ; un répartiteur de couche 7 (application) route selon l'hôte HTTP et le chemin d'URL plutôt que l'IP et le port, permettant un routage basé sur le contenu. Pour des livraisons sûres, un déploiement canary publie vers un petit pourcentage, par exemple 5 % des utilisateurs, surveille les métriques, puis élargit si tout va bien. Tu dois aussi connaître la mise à l'échelle horizontale vs verticale et les tests de santé. Attends-toi à des mises en situation demandant le bon élément - auto-scaling, répartiteur, couche 7 ou canary.
Ajouter/retirer des instances selon la demande = groupe d'auto-scaling. Distribuer les requêtes sur des serveurs = répartiteur de charge. Router par hôte/chemin HTTP = couche 7. Publier vers ~5 %, surveiller, puis élargir = déploiement canary.
Questions d'entraînement
1. Quel composant répartit les requêtes clientes entrantes sur plusieurs serveurs backend ?
- Passerelle NAT
- Répartiteur de charge (bonne réponse)
- Hôte bastion
- Nœud CDN
Un répartiteur de charge distribue le trafic sur les backends sains (round-robin, moins de connexions). Une passerelle NAT donne un accès sortant ; un bastion est un rebond.
2. Quel dispositif ajoute ou retire automatiquement des instances selon des règles de demande ?
- Groupe de placement
- Groupe d'auto-scaling (bonne réponse)
- Groupe de ressources
- Ensemble de disponibilité
Un groupe d'auto-scaling lance/arrête des instances selon des métriques (CPU, file d'attente) pour suivre la demande et réduire le coût. Un groupe de ressources n'est qu'un conteneur d'organisation.
3. Quel type de répartiteur de charge route selon l'hôte HTTP et le chemin d'URL plutôt que l'IP et le port ?
- Couche 4 (transport)
- Couche 7 (application) (bonne réponse)
- Couche 2 (liaison)
- Couche 3 (réseau)
Un répartiteur de couche 7 inspecte les données HTTP (en-tête hôte, chemin, cookies) pour router les requêtes. Un répartiteur de couche 4 ne voit qu'IP et ports, donc plus rapide mais moins fin.
4. Un répartiteur envoie chaque nouvelle requête au backend ayant le moins de connexions actives. Cet algorithme est :
- Rotation round-robin
- Hachage d'IP source
- Moindre connexions (bonne réponse)
- Choix aléatoire pondéré
Le moindre connexions route vers le serveur gérant actuellement le moins de sessions, équilibrant mieux les requêtes inégales ou longues. Le round-robin ignore la charge courante.
5. Avant de migrer, comparer la capacité actuelle à la capacité requise pour trouver les manques est une :
- Analyse d'écart (bonne réponse)
- Test de charge
- Test d'intrusion
- Prévision de coût
Une analyse d'écart compare l'état actuel à l'état cible pour révéler les manques de capacité, de compétences ou de contrôles avant migration. Un test de charge ne mesure que la performance sous stress.
6. Pour qu'un répartiteur renvoie un utilisateur qui revient vers le même backend, vous activez :
- Round-robin
- Affinité de session (bonne réponse)
- Répartition inter-zones
- Vidage de connexions
L'affinité de session (sessions collantes) épingle un client à un backend, utile quand l'état de session est stocké localement. Le round-robin ignore l'affinité et peut casser les sessions locales.