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

Ce que cette vidéo couvre

• - Le mur de l'architecture et le plan directeur
• - 01. Mise à l'échelle verticale vs horizontale
• - 02. Architecture d'équilibrage de charge (L4 vs L7 et vérifications de l'état de santé)
• - 03. Mise à l'échelle automatique 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 contrôlés par YouTube.

- Le mur de l'architecture et le plan directeur

0:00 Chaque ingénieur logiciel est un jour confronté au mur de l'architecture infonuagique. Vous développez une application sur votre ordinateur portable, la mettez en production, et dès que les vrais utilisateurs arrivent, les serveurs plantent, les connexions à la 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 infonuagique en mémorisant trois cents acronymes de produits AWS différents. Mais l'informatique en nuage réelle ne consiste pas à mémoriser les catalogues des fournisseurs : elle est construite sur onze primitives architecturales fondamentales.

0:34 Dans cette "masterclass", nous allons parcourir l'intégralité du plan d'entreprise : de la mise à l'échelle et l'équilibrage de charge au "serverless", au découplage axé sur les événements, aux hiérarchies de stockage et à la mise en réseau infonuagique. 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 de 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 "scale up", signifie prendre votre machine existante et lui 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 une prime de prix exponentielle. La mise à l'échelle horizontale, ou "scale out", signifie conserver 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 : vos serveurs d'applications ne peuvent pas stocker les sessions utilisateur, les fichiers téléchargés ou l'é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 vérifications de l'état 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, se situant entre l'internet public et votre grappe "backend" privée. 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 fonctionnent à la couche transport, acheminant les paquets TCP et UDP bruts basés sur l'adresse IP et le port avec une latence de l'ordre de la microseconde et des millions de requêtes par seconde. Les équilibreurs de charge d'application de couche 7 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 grappe "backend" et des requêtes "slash-static" à un

3:25 magasin d'objets. Crucialement, les équilibreurs de charge effectuent des vérifications de l'état de santé actives. Toutes les quelques secondes, l'équilibreur envoie un "ping" à un point de terminaison de santé sur chaque instance. Si une instance génère trois erreurs cinq cents consécutives ou ne répond pas, elle est automatiquement évincée du groupe avec zéro requête perdue.

- 03. Mise à l'échelle automatique et élasticité

3:45 Concept numéro trois : la mise à l'échelle automatique. Si votre application web a besoin de deux serveurs à trois heures du matin, mais de vingt serveurs lors d'un lancement à midi, cliquer manuellement sur des boutons dans la console cloud est une voie garantie vers les temps d'arrêt et la faillite. L'autoscaling apporte une élasticité dynamique aux groupes de serveurs horizontaux. Un groupe de mise à l'échelle automatique surveille les métriques de performance comme l'utilisation moyenne du CPU, les E/S réseau ou la profondeur du journal de file d'attente. Lorsque l'utilisation moyenne du CPU dépasse un seuil défini — par exemple,

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 le calcul inactif. Pour éviter le "flapping" — où les serveurs sont rapidement créés et détruits dans une boucle sans fin — les architectes cloud configurent des périodes de "cooldown". Concept numéro quatre : le "serverless" (sans serveur).

- 04. Sans serveur (FaaS et microVM Firecracker)

4:53 Pendant des années, les équipes marketing ont présenté le "serverless" comme du code magique fonctionnant dans le ciel. En réalité, le "serverless" utilise toujours des serveurs — mais vous ne les possédez pas, ne les "patchez" pas, et ne les payez pas quand aucun code ne s'exécute. Avec la fonction en tant que service (FaaS) 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, l'environnement d'exécution du nuage démarre une machine

5:23 micro-virtuelle é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 cent. Si un million d'utilisateurs l'atteignent simultanément, le fournisseur lance un million de microVMs concurrentes. Les compromis techniques sont réels : latence de démarrage à froid lors du lancement de nouveaux environnements d'exécution, une limite d'exécution stricte de quinze minutes sur Lambda, et une stricte absence d'état.

5:55 Le "serverless" 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 axée sur les événements (EDA et découplage)

6:05 Concept numéro cinq : l'architecture axée sur 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 le courriel. Cela crée la cascade synchrone de la perdition. Si le fournisseur de courriel tiers subit un problème réseau et prend dix secondes pour répondre, la demande de paiement de votre client expire entièrement avec une erreur. Dans une architecture axée sur 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" sur 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 courriel extraient les messages indépendamment de leurs propres files d'attente SQS dédiées. Si le service de courriel tombe en panne pendant une heure, les messages attendent en toute sécurité, mis en mémoire tampon dans la file d'attente sans une seule commande perdue.

- 06. Orchestration de conteneurs (Docker et Kubernetes)

7:13 Concept numéro six : l'orchestration de conteneurs. Docker a résolu l'empaquetage : il enveloppe le code de votre application, les bibliothèques système, la configuration et l'environnement d'exécution 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 s'effondre. C'est pourquoi des orchestrateurs de conteneurs comme Kubernetes et AWS ECS

7:41 existent. Un orchestrateur fournit un plan de contrôle : un serveur d'API, un magasin d'état etcd, et un ordonnanceur intelligent. Vous déclarez l'état souhaité : je veux dix répliques de mon service d'authentification avec deux gigaoctets de RAM chacune. L'ordonnanceur inspecte le cluster, place les "pods" sur les nœuds avec de la mémoire libre, configure la mise en 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 infonuagique (S3, EBS, bases de données 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 simple compartiment où l'on dépose des fichiers. Dans l'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 cents par gigaoctet par mois,

8:49 ce qui le rend 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, prenant en charge l'accès rapide en lecture et écriture aléatoires 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 offrant des transactions ACID et des jointures complexes,

9:21 et les moteurs NoSQL comme DynamoDB offrant une latence de l'ordre de la milliseconde à 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 "neufs" (basculement multi-AZ)

9:44 Concept numéro huit : la haute disponibilité, ou HA. La disponibilité répond à une question : quel pourcentage de temps votre application est-elle opérationnelle et accessible aux utilisateurs? Dans les contrats d'entreprise, la disponibilité est mesurée en "neufs" (nines). Deux "neufs", 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 "neufs" réduit le temps d'arrêt autorisé à cinquante-deux minutes, et cinq "neufs" ne permet que 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 panne. Dans le nuage, 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 éloignés de plusieurs kilomètres avec une alimentation et un refroidissement indépendants. En exécutant des instances actives dans la zone A et la zone B avec une réplication de base de données synchrone, 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 "neufs" n'est pas le temps de disponibilité)

10:53 Concept numéro neuf : Durabilité versus Disponibilité. C'est le piège conceptuel le plus courant dans les entretiens sur l'architecture cloud. Les ingénieurs utilisent fréquemment ces 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 altération, corruption ou destruction permanente de bits sur dix ans ?

11:24 Regardons 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 renvoyer une erreur 500. Mais S3 promet onze neuf de durabilité : quatre-vingt-dix-neuf virgule neuf 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 moyenne un

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

- 10. Infrastructure en tant que 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 modifications manuelles de la console n'ont pas de piste d'audit, pas de mécanisme de retour en arrière, et provoquent inévitablement une dérive de configuration entre les environnements de staging et de production. Avec des outils d'infrastructure en tant que code comme Terraform,

12:48 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'une réplique de base de données passe par une pull request et une révision par les pairs. une demande de tirage et un examen par les pairs. L'exécution de 'terraform plan' prévisualise le diff exact de l'API avant que quoi que ce soit ne soit touché, et le démarrage d'une réplique identique de votre pile de production prend quatre minutes au lieu de quatre semaines.

- 11. Réseau infonuagique (VPC, sous-réseaux, NAT et groupes de sécurité)

13:20 Concept numéro onze : Réseautage Cloud et Clouds Privés Virtuels (VPC). Lorsque vous déployez des serveurs dans le cloud, ils ne sont pas exposés sur l'internet public brut. Ils vivent à l'intérieur d'une limite isolée définie par logiciel appelée VPC. 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'applications et vos 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 zéro route entrante depuis l'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 strictement 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 achemine 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 travailleurs backend, et votre pile 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 cloud. Maîtrisez ces onze modèles d'architecture, découplez votre état, et construisez des systèmes qui ne peuvent pas échouer. 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 l'antisèche d'architecture complète, abonnez-vous à la newsletter sur The Daily Diff point dev,

15:28 lien ci-dessous. Et c'est la différence 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