L'informatique en nuage expliquée : les 11 concepts d'architecture que vous devez connaître (Masterclass 4K).

Ce que couvre cette vidéo

• - Le mur d'architecture et le plan directeur
• - 01. Mise à l'échelle verticale vs. horizontale
• - 02. Architecture d'équilibrage de charge (L4 vs. L7 et contrôles de santé)
• - 03. Auto-mise à l'échelle et élasticité
• - 04. Sans serveur (FaaS et MicroVM Firecracker)

Transcription traduite

Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont gérés par YouTube.

- Le mur d'architecture et le plan directeur

0:00 Tout ingénieur logiciel est finalement confronté au mur de l'architecture cloud. Vous construisez une application sur votre ordinateur portable, la mettez en production, et dès que de vrais utilisateurs arrivent, les serveurs plantent, les connexions de base de données s'épuisent, et votre facture AWS ressemble à un numéro de téléphone. La plupart des développeurs essaient de résoudre l'ingénierie cloud en mémorisant trois cents acronymes de produits AWS différents. Mais l'informatique cloud réelle ne consiste pas à mémoriser des catalogues de fournisseurs : elle est construite sur onze primitives architecturales fondamentales.

0:34 Dans cette masterclass, nous allons parcourir l'ensemble du plan d'entreprise : de la mise à l'échelle et de l'équilibrage de charge au découplage sans serveur et piloté par les événements, aux hiérarchies de stockage et au réseau cloud. Maîtrisez ces onze concepts, et vous pourrez concevoir n'importe quel backend sur AWS, GCP ou Azure. Ceci est The Daily Diff, dans les coulisses.

- 01. Mise à l'échelle verticale vs. horizontale

0:57 Concept numéro un : la mise à l'échelle. Lorsque votre application connaît une croissance du trafic, vous avez deux façons fondamentalement différentes de gérer la charge : la mise à l'échelle verticale, ou la mise à l'échelle horizontale. La mise à l'échelle verticale, ou scaling up, signifie prendre votre machine existante et ajouter plus de ressources : passer de quatre cœurs de CPU à trente-deux, ou échanger trente-deux gigaoctets de RAM contre cent vingt-huit. La mise à l'échelle verticale ne nécessite aucune modification architecturale : votre code

1:28 et votre base de données restent exactement les mêmes. Mais elle atteint un plafond matériel brutal. Aucune machine au monde n'a dix mille cœurs de CPU, et les instances haut de gamme entraînent un surcoût exponentiel. La mise à l'échelle horizontale, ou scaling out, signifie garder vos serveurs petits et à prix courant, mais exécuter plusieurs instances en parallèle derrière un routeur. Si une instance tombe en panne, les nœuds restants absorbent le trafic avec zéro temps d'arrêt. La règle d'or de la mise à l'échelle horizontale est

2:01 l'absence d'état (statelessness) : vos serveurs d'applications ne peuvent pas stocker de sessions utilisateur, de fichiers téléchargés ou d'état sur leurs disques locaux. L'état doit résider dans une base de données ou un cache externe, permettant à n'importe quel nœud de gérer n'importe quelle requête utilisateur.

- 02. Architecture d'équilibrage de charge (L4 vs. L7 et contrôles de santé)

2:17 Concept numéro deux : l'équilibrage de charge. La mise à l'échelle horizontale semble excellente sur le papier, mais elle introduit un problème immédiat : lorsque dix mille utilisateurs accèdent à votre nom de domaine, quel serveur spécifique reçoit leur trafic ? Un équilibreur de charge agit comme un proxy inverse situé entre l'Internet public et votre cluster de backend privé. Il accepte les connexions TCP ou HTTP entrantes et distribue les requêtes entre vos instances saines.

2:47 Les équilibreurs de charge fonctionnent à deux couches réseau principales. Les équilibreurs de charge réseau de couche 4 (Layer 4 Network Load Balancers) fonctionnent au niveau de la couche transport, acheminant les paquets TCP et UDP bruts basés sur l'adresse IP et le port avec une latence de microseconde et des millions de requêtes par seconde. Les équilibreurs de charge d'application de couche 7 (Layer 7 Application Load Balancers) inspectent le protocole HTTP lui-même : lisant les chemins d'URL, les en-têtes de requête, les cookies et les méthodes HTTP. Cela permet un routage basé sur le chemin : envoyer des requêtes slash-api à votre cluster backend et des requêtes slash-static à un

3:25 magasin d'objets. Surtout, les équilibreurs de charge effectuent des contrôles de santé actifs. Toutes les quelques secondes, l'équilibreur envoie un ping à un point de terminaison de santé sur chaque instance. Si une instance envoie trois erreurs 500 consécutives ou ne répond pas, elle est automatiquement retirée du pool avec zéro requête perdue.

- 03. Auto-mise à l'échelle et élasticité

3:45 Concept numéro trois : l'auto-mise à l'échelle. Si votre application web a besoin de deux serveurs à trois heures du matin, mais de vingt serveurs lors d'un lancement à la mi-journée, cliquer manuellement sur les boutons de la console cloud est un chemin garanti vers le temps d'arrêt et la faillite. L'auto-mise à l'échelle apporte une élasticité dynamique aux pools de serveurs horizontaux. Un groupe d'auto-mise à l'échelle surveille les métriques de performance comme l'utilisation moyenne du CPU, les E/S réseau ou la profondeur du backlog de la file d'attente. Lorsque l'utilisation moyenne du CPU dépasse un seuil défini — disons,

4:19 soixante-dix pour cent pendant trois minutes consécutives — l'autoscaler lance automatiquement de nouvelles machines virtuelles, les enregistre auprès de votre équilibreur de charge, et commence à acheminer le trafic. La mise à l'échelle inverse est tout aussi importante : lorsque la vague de trafic se retire, l'autoscaler met fin aux instances excédentaires afin que vous cessiez de payer pour les ressources de calcul inactives. Pour éviter le « flapping » — où les serveurs sont rapidement créés et détruits dans une boucle de battement sans fin — les architectes cloud configurent des périodes de latence. Concept numéro quatre : Sans serveur.

- 04. Sans serveur (FaaS et MicroVM Firecracker)

4:53 Pendant des années, les équipes marketing ont présenté le sans serveur comme du code magique exécuté dans le ciel. En réalité, le sans serveur utilise toujours des serveurs — mais vous ne les possédez pas, ne les corrigez pas et ne les payez pas quand aucun code n'est exécuté. Avec la fonction en tant que service (Function-as-a-Service) comme AWS Lambda ou Google Cloud Functions, vous écrivez une fonction de gestionnaire autonome. Lorsqu'une requête HTTP, un téléchargement de fichier S3 ou un changement de base de données se produit, le runtime cloud démarre une micro-machine virtuelle

5:23 éphémère comme Firecracker en moins de cinq millisecondes. Votre code s'exécute, renvoie une réponse et s'arrête. Si personne ne visite votre site web pendant trois mois, votre facture de calcul est exactement de zéro dollar et zéro centime. Si un million d'utilisateurs y accèdent simultanément, le fournisseur lance un million de microVMs concurrentes. Les compromis d'ingénierie sont réels : latence de démarrage à froid lors du démarrage de nouveaux runtimes, une limite d'exécution stricte de quinze minutes sur Lambda, et une absence d'état stricte.

5:55 Le sans serveur est imbattable pour les pipelines d'événements et les API sporadiques, mais peu performant pour les WebSockets persistants ou les exécutions d'entraînement de plusieurs heures.

- 05. Architecture pilotée par les événements (EDA et découplage)

6:05 Concept numéro cinq : Architecture pilotée par les événements, ou EDA. Dans les architectures traditionnelles, les services communiquent de manière synchrone. Votre service de paiement appelle le paiement, le paiement appelle l'inventaire, l'inventaire appelle la fraude, et la fraude appelle l'e-mail. Cela crée la cascade de la perdition synchrone. Si le fournisseur de services de messagerie tiers subit un problème réseau et prend dix secondes pour répondre, l'intégralité de la demande de paiement de votre client expire avec une erreur. Dans une architecture pilotée par les événements, les services sont complètement découplés.

6:37 Lorsqu'un client clique sur acheter, le service de paiement n'appelle pas les services en aval. Il publie simplement un événement appelé OrderPlaced vers un bus d'événements central comme Amazon EventBridge ou un sujet SNS. Le paiement est effectué en cinquante millisecondes. Les travailleurs en aval pour le paiement, la déduction d'inventaire et les reçus par e-mail extraient les messages indépendamment de leurs propres files d'attente SQS dédiées. Si le service de messagerie tombe en panne pendant une heure, les messages attendent en toute sécurité mis en tampon dans la file d'attente sans une seule commande perdue.

- 06. Orchestration de conteneurs (Docker et Kubernetes)

7:13 Concept numéro six : Orchestration de conteneurs. Docker a résolu l'empaquetage : il enveloppe votre code d'application, vos bibliothèques système, votre configuration et votre runtime dans une image immuable qui s'exécute de manière identique sur votre MacBook et dans le cloud. Mais empaqueter un conteneur est facile. Exécuter cinq cents conteneurs sur cinquante machines virtuelles physiques est là où l'ingénierie échoue. C'est pourquoi les orchestrateurs de conteneurs comme Kubernetes et AWS ECS

7:41 existent. Un orchestrateur fournit un plan de contrôle : un serveur API, un magasin d'état etcd et un planificateur intelligent. Vous déclarez votre état désiré : je veux dix répliques de mon service d'authentification avec deux gigaoctets de RAM chacune. Le planificateur inspecte le cluster, place les pods sur les nœuds avec de la mémoire libre, configure le réseau interne et concilie continuellement la réalité. Si un nœud subit une défaillance matérielle, Kubernetes détecte la perte et replace instantanément tous les pods déplacés sur des

- 07. Les 4 piliers du stockage en nuage (S3, EBS, DBs et Redis)

8:16 nœuds sains. Concept numéro sept : La hiérarchie du stockage cloud. Les débutants traitent souvent le stockage cloud comme un seul compartiment où l'on dépose des fichiers. Dans une architecture de production, le stockage est divisé en quatre piliers distincts basés sur les modèles d'accès et la latence. Le premier est le stockage d'objets, comme Amazon S3 ou Google Cloud Storage. Vous accédez aux fichiers via des API REST HTTP en utilisant de simples appels PUT et GET. Il offre une capacité horizontale infinie à deux centimes par gigaoctet par mois,

8:49 le rendant idéal pour la vidéo, les téléchargements d'utilisateurs, les journaux et les sauvegardes. Le second est le stockage par blocs, comme Amazon EBS. Ce sont des disques durs virtuels montés directement sur une machine virtuelle spécifique via des interconnexions à haute vitesse. Ils se formatent en systèmes de fichiers standard comme ext4, supportant l'accès rapide en lecture et écriture aléatoire requis par les moteurs de base de données. Le troisième sont les bases de données gérées : les moteurs relationnels comme PostgreSQL sur RDS fournissant des transactions ACID et des jointures complexes,

9:21 et les moteurs NoSQL comme DynamoDB offrant une latence de quelques millisecondes à grande échelle. Et le quatrième sont les caches en mémoire comme Redis. La lecture de données de la RAM prend des microsecondes plutôt que des millisecondes. Les caches se placent devant votre base de données, la protégeant du trafic de lecture répété et gérant les jetons de session utilisateur volatils.

- 08. Haute disponibilité et les « nines » (basculement multi-AZ)

9:44 Concept numéro huit : Haute disponibilité, ou HA. La disponibilité répond à une question : quel pourcentage du temps votre application est-elle opérationnelle et accessible aux utilisateurs ? Dans les contrats d'entreprise, la disponibilité est mesurée en « nines » (nœuds). Deux « nines », ou quatre-vingt-dix-neuf pour cent de disponibilité, permet plus de trois jours et demi de temps d'arrêt chaque année. Quatre « nines » réduit le temps d'arrêt autorisé à cinquante-deux minutes, et cinq « nines » permet à peine cinq minutes de temps d'arrêt total par

10:15 an. Pour atteindre une haute disponibilité, vous devez éliminer les points de défaillance uniques à travers les domaines de défaillance. Dans le cloud, cela signifie déployer sur plusieurs zones de disponibilité. Une zone de disponibilité n'est pas un seul rack : c'est un ou plusieurs centres de données physiques distincts espacés de kilomètres avec une alimentation électrique et un refroidissement indépendants. En exécutant des instances actives dans la zone A et la zone B avec une réplication synchrone de la base de données, un coup de foudre ou une coupure de fibre qui met hors service une installation physique entière entraîne un basculement automatisé.

10:50 en trente secondes sans aucune intervention humaine.

- 09. Durabilité vs. Disponibilité (Pourquoi 11 nines n'est pas le temps de disponibilité)

10:53 Concept numéro neuf : Durabilité contre Disponibilité. C'est le piège conceptuel le plus courant dans les entretiens d'architecture cloud. Les ingénieurs utilisent souvent les mots de manière interchangeable, mais ils mesurent des propriétés complètement différentes. La disponibilité mesure le temps de fonctionnement : puis-je faire un appel API pour lire ou écrire mes données à l'instant même ? La durabilité mesure la préservation : mes données survivront-elles sans dégradation, corruption ou destruction permanente sur dix ans ?

11:24 Prenons Amazon S3 Standard. Son accord de niveau de service offre quatre-vingt-dix-neuf virgule neuf pour cent de disponibilité, ce qui permet environ quarante-trois minutes d'indisponibilité chaque mois où une requête API pourrait retourner une erreur cinq cents. Mais S3 promet onze neuf de durabilité : quatre-vingt-dix-neuf virgule neuf neuf neuf neuf neuf neuf neuf neuf neuf pour cent. Si vous stockez dix millions de fichiers dans S3, vous pouvez statistiquement vous attendre à perdre en

11:56 moyenne un fichier tous les dix mille ans. S3 y parvient en encodant par effacement les objets et en répliquant des blocs sur au moins trois installations de données géographiquement séparées. Pendant une panne majeure du réseau régional, S3 pourrait être temporairement indisponible, mais vos données ne sont jamais détruites.

- 10. Infrastructure as Code (Terraform vs. Console Drift)

12:14 Concept numéro dix : Infrastructure as Code, ou IaC. Au début du cloud computing, les ingénieurs se connectaient à la console de gestion web d'AWS et cliquaient manuellement pour créer des machines virtuelles, configurer des sous-réseaux et attacher des groupes de sécurité. L'industrie appelle cela ClickOps, et en production, c'est un désastre absolu. Les changements manuels via la console n'ont pas de piste d'audit, pas de mécanisme de restauration, et entraînent inévitablement une dérive de configuration entre les environnements de staging et de production. Avec les outils d'Infrastructure as Code

12:48 comme Terraform, OpenTofu, Pulumi ou AWS CDK, vous définissez votre architecture cloud entière dans des fichiers de configuration déclaratifs stockés dans Git. Chaque modification d'un port ouvert ou d'un réplica de base de données passe par une pull request et une revue par les pairs. L'exécution de terraform plan prévisualise le diff API exact avant que quoi que ce soit ne soit touché, et le démarrage d'un réplica identique de votre stack de production prend quatre minutes au lieu de quatre semaines.

- 11. Réseautage en nuage (VPC, sous-réseaux, NAT et groupes de sécurité)

13:20 Concept numéro onze : Réseautage Cloud et Clouds Privés Virtuels. Lorsque vous déployez des serveurs dans le cloud, ils ne sont pas exposés directement sur l'internet public brut. Ils vivent à l'intérieur d'une limite isolée définie par logiciel appelée VPC. À l'intérieur de votre VPC, vous allouez un espace d'adresses IP privées comme dix point zéro point zéro point zéro barre oblique seize, et le divisez en sous-réseaux publics et privés. Un sous-réseau public a un chemin direct vers une passerelle Internet.

13:51 Il contient des actifs accessibles au public comme vos équilibreurs de charge d'application et les passerelles NAT. C'est la seule partie de votre réseau qui possède des adresses IP publiques. Vos serveurs d'applications et bases de données de production vivent strictement dans des sous-réseaux privés sans IP publiques et sans routes entrantes depuis internet. Lorsque vos serveurs backend ont besoin de télécharger des mises à jour de sécurité, leur trafic sortant passe par la passerelle NAT dans le sous-réseau public. Autour de chaque instance se trouvent des groupes de sécurité : des pare-feu virtuels avec état qui appliquent le principe du moindre privilège.

- 12. Le plan d'entreprise complet et le verdict

14:28 Votre groupe de sécurité de base de données n'accepte les connexions sur le port 5432 que depuis le groupe de sécurité de vos serveurs d'applications, rendant toute pénétration extérieure mathématiquement impossible. Avec du recul, ces onze primitives se connectent en un système cohérent. Votre DNS route vers un équilibreur de charge dans un sous-réseau public, les groupes d'autoscaling gèrent les pics de trafic à travers plusieurs zones de disponibilité, les bus d'événements découplent les workers backend, et votre stack entière est déployée depuis Git en utilisant l'Infrastructure as Code.

15:02 Verdict de la masterclass d'aujourd'hui : SHIP IT. Arrêtez de mémoriser des centaines d'acronymes marketing du cloud. Maîtrisez ces onze modèles d'architecture, découplez votre état, et construisez des systèmes qui ne peuvent pas tomber en panne. Dites-moi quel concept cloud vous a donné le plus de maux de tête lorsque vous avez commencé à construire dans les commentaires. Et pour obtenir la feuille de triche d'architecture complète, abonnez-vous à la newsletter sur the daily diff dot dev,

15:28 lien ci-dessous. Et c'est tout pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable.

Sources

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io