Comment les géants du Web (Instagram, Twitter, etc...) font l'exploit de supporter + d'1 million d'utilisateurs/jour tout en opérant de façon optimale ?
Je t'explique comment scaler une application Web de 0 à plusieurs millions d'utilisateurs
THREAD (Avancé) ⬇️
Je t'explique comment scaler une application Web de 0 à plusieurs millions d'utilisateurs
THREAD (Avancé) ⬇️
L'architecture la + basique qu'un site web classique puisse avoir = un serveur + une base de données.
Le client communique avec le serveur via le protocole HTTP. Le serveur récupére les données stockées en base et les retourne au client en divers format (HTML, JSON...)
Le client communique avec le serveur via le protocole HTTP. Le serveur récupére les données stockées en base et les retourne au client en divers format (HTML, JSON...)
Mais que se passerait t-il si le site connaissait un succes fulgurant avec un nombre d'utilisateurs augmentant de façon exponentielle ?
=> Le serveur sera "débordé" car incapable de gérer toutes les connexions (donc fortes latences, voir indisponibilité totale du site web)
=> Le serveur sera "débordé" car incapable de gérer toutes les connexions (donc fortes latences, voir indisponibilité totale du site web)
2 solutions:
1. Augmenter la puissance de calcul du serveur (= scaling vertical) en ajoutant de la RAM ou en augmentant la puissance du CPU.
+: Simple
-: Impossible augmenter la puissance indéfiniment (plafond). Système non résilient en cas de panne (= single point of failure)
1. Augmenter la puissance de calcul du serveur (= scaling vertical) en ajoutant de la RAM ou en augmentant la puissance du CPU.
+: Simple
-: Impossible augmenter la puissance indéfiniment (plafond). Système non résilient en cas de panne (= single point of failure)
2. Ajouter plus de serveurs au pool de serveurs existant (= scaling horizontal)
+: Permet de scaler à l'infini en fonction de ses besoins. Système plus tolérant aux pannes
-: Plus complexe à implémenter et à gérer (synchro, gestion de l'infra...)
+: Permet de scaler à l'infini en fonction de ses besoins. Système plus tolérant aux pannes
-: Plus complexe à implémenter et à gérer (synchro, gestion de l'infra...)
Ajouter un load balancer permettra de répartir équitablement le traffic entre les serveurs du pool.
On obtiendrait l'archi suivante
On obtiendrait l'archi suivante
Si le serveur 1 tombe, le trafic est redirigé vers le serveur 2. Cela permettra au système de fonctionner normalement.
Si le trafic augmente, on peut ajouter de nouveaux serveurs au pool en fonction des besoins, et le load balancer gèrera les redirections automatiquement
Si le trafic augmente, on peut ajouter de nouveaux serveurs au pool en fonction des besoins, et le load balancer gèrera les redirections automatiquement
Qui dit + d'utilisateurs dit + de trafic en base de données: Si le serveur de base de données tombe, toutes nos données sont perdues. Comment palier à ce problème ?
=> La réplication de base est une solution possible.
On va mettre en place 1 noeud maitre et N nœuds esclaves.
Le noeud maitre traitera les requetes en écriture (insert, update, delete).
Les noeuds esclaves traiteront celles en lecture et se synchroniseront avec le maitre
On va mettre en place 1 noeud maitre et N nœuds esclaves.
Le noeud maitre traitera les requetes en écriture (insert, update, delete).
Les noeuds esclaves traiteront celles en lecture et se synchroniseront avec le maitre
Avantages:
- Meilleures perfs (+ de requetes peuvent être traitées en parallèle)
- Résilience (si un serveur de DB tombe alors pas d'impact car les données sont répliquées dans plusieurs autres noeuds)
On obtient donc l’architecture suivante
- Meilleures perfs (+ de requetes peuvent être traitées en parallèle)
- Résilience (si un serveur de DB tombe alors pas d'impact car les données sont répliquées dans plusieurs autres noeuds)
On obtient donc l’architecture suivante
Mais requêter une base de données est très long.
De plus, certaines requetes sont bcp + fréquentes que d'autres.
Pour améliorer les perfs, on utilise un CACHE qui va stocker temporairement en mémoire les requetes redondantes
De plus, certaines requetes sont bcp + fréquentes que d'autres.
Pour améliorer les perfs, on utilise un CACHE qui va stocker temporairement en mémoire les requetes redondantes
Il est important de garder une archi la + stateless possible.
Pour ça, on ajouter une base NoSQL stockant les données liées aux états (sessions utilisateurs...)
Le client pourra interroger n'importe quel serveurs et chaque serveur pourra fournir les données le concernant
Pour ça, on ajouter une base NoSQL stockant les données liées aux états (sessions utilisateurs...)
Le client pourra interroger n'importe quel serveurs et chaque serveur pourra fournir les données le concernant
On obtient l'archi suivante
Avec des utilisateurs venant des 4 coins du monde, il faut maintenir plusieurs data centers pour minimiser les temps de latence.
Les requetes du client doivent être routées vers le datacenter le + proche en fonction de sa localisation géographique
Les requetes du client doivent être routées vers le datacenter le + proche en fonction de sa localisation géographique
Pour gérer les traitements/communications asynchrones ajouter une file d'attente (RabbitMQ, Kafka...)
Les producteurs y pousseront des taches tandis que des consommateurs (workers) traiteront les taches présentes dans la file afin de garantir un couplage faible
Les producteurs y pousseront des taches tandis que des consommateurs (workers) traiteront les taches présentes dans la file afin de garantir un couplage faible
Enfin, on peut ajouter des composants pour:
- Monitorer les logs du système afin d'identifier les pannes/erreurs
- Monitorer certaines métriques (CPU, RAM, nb de users quotidiens...) pour avoir une vision sur la santé du système
- Monitorer les logs du système afin d'identifier les pannes/erreurs
- Monitorer certaines métriques (CPU, RAM, nb de users quotidiens...) pour avoir une vision sur la santé du système
L'architecture finale
Sources:
- System Design Interview (Alex XU)
- Designing data intensive applications (Martin Kleppman)
- System Design Interview (Alex XU)
- Designing data intensive applications (Martin Kleppman)
Note: Aucune architecture est infaillible à 100%.
Un système distribué ne peut pas être à la fois consistent, tolérant aux pannes et disponible (CAP Theorem)
Un système distribué ne peut pas être à la fois consistent, tolérant aux pannes et disponible (CAP Theorem)
N'oublie pas de retweet + like ce thread pour que ça puisse aider le maximum de personnes !
Follow moi: @CoderNoLimit pour ne rien rater. Si tu as la moindre question, mets-la en commentaire ou contacte-moi directement en DM 😃
Follow moi: @CoderNoLimit pour ne rien rater. Si tu as la moindre question, mets-la en commentaire ou contacte-moi directement en DM 😃
Si la programmation t’intéresse, abonne-toi à ma chaine. Il y a le meilleur contenu du Youtube Game francophone sur la programmation et je compte publier du très lourd:
youtube.com
youtube.com
جاري تحميل الاقتراحات...