Grands Systèmes

Cours de SYstèmes Distribués (SYD)

INSA Lyon

Par Damien Reimert

Creative common by-nc-nd

### Qui suis-je ? * Un Tech * Développeur de Jumplyn * Enseignant en Telecom à l'INSA Lyon

## Avertissements, déclarations et conseils --- ### Utilisation des machines de l'INSA N'utilisez pas des machines que vous n'avez pas en visuel et sur laquelle il y a un utilisateur sauf dans le cadre d'un TD/TP où c'est l'objectif du TD/TP. Plus globalement, faites très attention lorsque vous utiliser plusieurs machines en dehors d'une session de TD/TP. Cela peut aller à l'encontre de la charte informatique de l'INSA. --- ### Point de vue Ce cours est mon point de vue sur le sujet. Il est biaisé par mon expérience personnel, mes centres d'intérêts et les retours faits par mes collègues et étudiants. N'hésiter pas à l'aller voir ailleurs. --- ### Technologie L'écosystème évolue très vite. Nous nous concentrons sur les concepts fondamentaux illustrés par les technologies dominantes en 2025. --- ### Javascript Les TDs/TPs utiliseront majoritairement Javascript. --- ## Conseils Prenez des notes. --- ## Questions ? Posez des questions quand les choses vous paraissent floues. Posez des questions quand je vais trop vite. --- ## Usages des IAs Ce cours est écrit par moi-même avec l'aide d'une IA pour effectuer des recherches et générer des images.

## Évaluations * À chaque TD/TP * à 8h01 / 10h11 / 14h01 / 16h11 (pour les miens) * Questions projetées au tableau * entre 5 et 10 minutes * Sur tout ce qui a été vu avant, cours et TD/TP * Sur papier, pensez à amener du papier et un stylo * Sans document, sans électronique.

# Introduction

## Objectifs

Comprendre comment les grandes infrastructures sont mises en place.

Avoir le vocabulaire et les concepts pour en discuter.

Vous donner les clés pour comprendre les architectures logicielles qui font tourner le monde numérique d'aujourd'hui.

Comment les systèmes que vous utilisez tous les jours fonctionnent ?

Jean Dupont

Étudiant en première année d'informatique

## Son idée Vendre des t-shirts pour financer ses études.

Un design

❤.js

### Comment feriez-vous ?

Monolithique basique

Monolithique basique version artistique

Monolithique basique

Monolithique basique version application

Monolithique basique

Monolithique basique version VPS

Monolithique basique

Monolithique basique version VPS avec client

Monolithique pas si basique

Monolithique pas si basique version hébergeur

Monolithique pas si basique

Monolithique pas si basique version extranet

Monolithique pas si basique

Monolithique pas si basique version full

Monolithique pas si basique

Je vous fait grâce du réseau...

En informatique, l'architecture monolithique est un modèle de conception logicielle dans lequel tous les composants d'une application sont étroitement liés et unifiés en une seule base de code et un seul programme exécutable.

### Caractéristiques principales

#### Une seule unité L'application est développée, déployée et exécutée comme une entité unique. L'interface utilisateur, la logique métier et la couche d'accès aux données sont toutes regroupées dans le même processus.

#### Couplage fort Les différents modules de l'application sont fortement interdépendants. Une modification dans un composant peut potentiellement affecter l'ensemble de l'application.

#### Déploiement unique Le déploiement d'une mise à jour, même mineure, nécessite de recompiler et de redéployer l'intégralité du monolithe.

### Avantages

#### Simplicité de développement initial La structure unique est plus facile à démarrer et à gérer pour les petites équipes.

#### Déploiement simple Il n'y a qu'un seul fichier ou package à déployer.

#### Performance Les communications entre les modules sont très rapides car elles se font par des appels de fonction ou de méthode locaux, sans passer par le réseau.

### Inconvénients

#### Difficulté à maintenir La complexité de la base de code augmente avec le temps, rendant la maintenance et l'ajout de nouvelles fonctionnalités plus compliqués.

#### Mise à l'échelle limitée L'application ne peut être mise à l'échelle qu'en dupliquant l'ensemble du monolithe, ce qui peut être inefficace car on ne peut pas mettre à l'échelle un seul composant qui est surchargé.

#### Risque élevé Si une partie de l'application plante, l'intégralité du monolithe peut cesser de fonctionner.

Pour Jean Dupont, comment gérer les pics d'activités ? Exemple de "Vinted Autumn"

Logo Vinted

Fondée en Lituanie en 2008, Vinted a débuté son parcours comme un petit projet communautaire pour la vente et l'échange de vêtements d'occasion.

[État de l'architecture en 2015](https://highscalability.com/vinted-architecture-keeping-a-busy-portal-stable-by-deployin/) : * 7 million users and growing * 2.5 million monthly active users * 200 million requests / day (pageviews + API calls) * 930 million photos * 80 TB raw space for image storage * 60 TB HDFS raw space for analytics data * 70% of traffic comes from mobile apps (API requests) * 3+ hours / week time spent per member * 25 million listed items

Over 220 servers bare metal: * 47 for internal tools (vpn, chef, monitoring, development, graphing, build, backups, etc.) * 38 for the Hadoop ecosystem * 34 for image processing and storage * 30 for Unicorn and microservices * 28 for MySQL databases, including replicas * 19 for the Sphinx search * 10 for resque background jobs * 10 for load balancing with Nginx * 6 for Kafka, 4 for Redis, 4 for email delivery

C'est un monolithe en cours de transformation !

* automatisation et le déploiement continu des centaines de fois par jour * déjà quelques microservices * mais des difficultés de scalabilité pour les BDDs * et d'adaptation aux spécificités locales

Aujourd'hui : * 75 millions de membres inscrits dans plus de 18 pays * 1 milliard d'articles en 2024. * valorisation de 5 milliards d'euros lors d'une vente de parts en 2024.

## Les défis du C2C

[Rapport et sources](https://docs.google.com/document/d/1HCPwhu6ax86wB5k9bBQb5HnJlGcYSaMk7w5kMI_dNZc/edit?usp=sharing) [Résumé visuel](https://gemini.google.com/share/30c4037d0992)

Microservices

Vue artistique des microservices

Microservices

Vue technique des microservices

L'architecture microservices est un modèle de conception logicielle qui structure une application comme une collection de services petits, autonomes et faiblement couplés. Chaque microservice est une unité indépendante qui se concentre sur une fonctionnalité métier spécifique et peut être développé, déployé et mis à l'échelle de manière autonome.

Contrairement à l'architecture monolithique où tous les composants sont regroupés, les microservices communiquent entre eux via des interfaces standardisées (comme les API REST ou les bus de messages) et ne partagent pas leur base de données.

### Caractéristiques principales

#### Découpage fonctionnel Chaque service est organisé autour d'une capacité métier unique. Par exemple, une application de commerce électronique pourrait avoir des microservices distincts pour la gestion des utilisateurs, le traitement des commandes, l'inventaire des produits, et le système de paiement.

#### Indépendance Chaque microservice peut être développé par une équipe différente, dans un langage de programmation différent, et déployé indépendamment des autres services.

#### Faible couplage Les services n'ont qu'une connaissance minimale des autres services et ne dépendent pas de leur implémentation interne.

#### Décentralisation La gestion des données est décentralisée, chaque microservice ayant généralement sa propre base de données.

### Avantages

#### Évolutivité (Scalabilité) Vous pouvez mettre à l'échelle un seul service qui fait face à une charge accrue, sans avoir à dupliquer l'intégralité de l'application.

#### Résilience Si un service tombe en panne, le reste de l'application peut continuer à fonctionner. L'isolation des pannes est une caractéristique clé.

#### Agilité et "Time-to-Market" Les équipes peuvent développer, tester et déployer de nouvelles fonctionnalités plus rapidement, car elles ne travaillent que sur un petit morceau de code.

#### Liberté technologique Les développeurs peuvent choisir les technologies les plus adaptées à la tâche de chaque microservice.

### Inconvénients

#### Complexité de gestion Gérer un grand nombre de services, avec des déploiements et des communications multiples, peut devenir très complexe.

#### Débogage et surveillance Il est plus difficile de suivre une transaction qui traverse plusieurs services.

#### Cohérence des données Le manque de base de données partagée peut rendre la gestion de la cohérence des données plus complexe et nécessite l'utilisation de modèles tels que la "cohérence éventuelle".

#### Coût opérationnel L'infrastructure nécessaire pour le déploiement (comme les conteneurs Docker et les orchestrateurs comme Kubernetes) peut être plus coûteuse à mettre en place.

## Les outils

* Conteneurs : Docker * Orchestrateurs : Kubernetes * Infrastructure As Code (IaC) : Terraform, Ansible * Service Mesh : Istio, Linkerd * Message Brokers : RabbitMQ, Kafka * Continuous Integration / Continuous Deployment (CI/CD) : Jenkins, GitLab CI, GitHub Actions * Monitoring et Logging : Prometheus, Grafana, ELK Stack * Content Delivery Network (CDN) : Cloudflare, Akamai

### Conteneurs Les conteneurs, comme Docker, permettent d'emballer une application et toutes ses dépendances dans une unité standardisée. Cela garantit que l'application fonctionne de la même manière, peu importe où elle est déployée.

### Orchestrateurs Les orchestrateurs, comme Kubernetes, gèrent le déploiement, la mise à l'échelle et la gestion des conteneurs. Ils automatisent de nombreuses tâches opérationnelles, ce qui facilite la gestion des applications conteneurisées.

### Infrastructure As Code (IaC) Des outils comme Terraform et Ansible permettent de gérer et de provisionner l'infrastructure informatique à l'aide de fichiers de configuration lisibles par l'homme. Cela facilite la réplication des environnements et le contrôle des versions de l'infrastructure.

### Service Mesh Un service mesh, comme Istio ou Linkerd, gère la communication entre les microservices. Il offre des fonctionnalités comme le routage, la sécurité, et la surveillance sans nécessiter de modifications dans le code des services.

### Message Brokers Des systèmes comme RabbitMQ ou Kafka facilitent la communication asynchrone entre les microservices. Ils permettent de découpler les services et de gérer les pics de charge.

### Continuous Integration / Continuous Deployment (CI/CD) Des outils comme Jenkins, GitLab CI, ou GitHub Actions automatisent le processus de test et de déploiement des applications. Ils permettent de livrer rapidement et en toute sécurité des mises à jour logicielles.

### Monitoring et Logging Des outils comme Prometheus, Grafana, et la stack ELK (Elasticsearch, Logstash, Kibana) permettent de surveiller la santé des applications et de collecter les logs pour le diagnostic des problèmes. Ils sont indispensables pour maintenir la fiabilité et la performance des systèmes distribués.

### Content Delivery Network (CDN) Des services comme Cloudflare ou Akamai distribuent le contenu statique (images, vidéos, fichiers JavaScript/CSS) à travers un réseau mondial de serveurs. Cela réduit la latence et améliore l'expérience utilisateur en rapprochant le contenu des utilisateurs finaux.

## Penser les systèmes distribués

Construire des systèmes distribués, c'est accepter une réalité : les pannes sont inévitables. * Un disque dur va tomber. * Un réseau va être saturé. * Un service va planter. L'objectif n'est pas d'empêcher les pannes, mais de construire des systèmes résilients qui continuent de fonctionner malgré les pannes. C'est la différence fondamentale entre l'informatique "classique" et les grands systèmes.

### Défis * Latence * Disponibilité * Cohérence

### Solutions * Caching * Réplication * Partitionnement

### Théorème CAP * Cohérence * Disponibilité * Tolérance aux partitions

### Raft Problème : Comment un groupe de serveurs se met-il d'accord sur une valeur (ex: "qui est le leader ?") même en cas de panne ? C'est le problème du consensus distribué. Paxos est un algorithme célèbre mais difficile à implémenter. Raft est un algorithme plus récent et plus simple à comprendre, conçu pour être plus intelligible. Raft est au cœur de etcd, la "base de données" qui stocke l'état de chaque cluster Kubernetes.

## Data et IA