De nombreuses startups sont passées par là: des foules de nouveaux utilisateurs sont enregistrées chaque jour et l'équipe de développement peine à prendre en charge le service.

C'est un problème agréable, mais il y a peu d'informations claires sur le Web pour savoir comment faire évoluer avec précision une application Web de zéro à des centaines de milliers d'utilisateurs. Habituellement, il existe des solutions d'incendie ou l'élimination des goulots d'étranglement (et souvent les deux). Par conséquent, les gens utilisent des astuces assez stéréotypées pour transformer leur projet amateur en quelque chose de vraiment sérieux.

Essayons de filtrer les informations et d'écrire la formule principale. Nous allons progressivement mettre à l'échelle notre nouveau site de partage de photos Graminsta de 1 à 100 000 utilisateurs.

Nous noterons les actions spécifiques à entreprendre pour augmenter l'audience à 10, 100, 1000, 10 000 et 100 000 personnes.

1 utilisateur: 1 voiture

Presque chaque application, qu’il s’agisse d’un site Web ou d’une application mobile, comporte trois éléments clés:

API
base de données
client (application mobile ou site web lui-même)

La base de données stocke des données persistantes. L'API sert les demandes pour et autour de ces données. Le client transfère les données à l'utilisateur.

J'en suis venu à la conclusion qu'il est beaucoup plus facile de parler de mise à l'échelle d'une application si, du point de vue de l'architecture, les entités clientes et les API sont complètement séparées.

Lorsque nous commençons à créer une application, les trois composants peuvent être exécutés sur le même serveur. D'une certaine manière, cela nous rappelle notre environnement de développement: un ingénieur exécute la base de données, l'API et le client sur le même ordinateur.

Théoriquement, nous pourrions le déployer dans le cloud sur une instance de DigitalOcean Droplet ou AWS EC2, comme indiqué ci-dessous:

Cela dit, si le site a plus d'un utilisateur, il est presque toujours logique de mettre en évidence le niveau de la base de données.

10 utilisateurs: prendre la base de données à un niveau distinct

La division d'une base de données en services gérés tels qu'Amazon RDS ou la base de données gérée par l'océan numérique nous sera utile pendant longtemps. C'est un peu plus cher que l'auto-hébergement sur une seule machine ou une instance EC2, mais avec ces services, vous obtenez de nombreuses extensions utiles prêtes à l'emploi qui vous seront utiles à l'avenir: sauvegardes multi-régions, répliques en lecture, sauvegardes automatiques et bien plus encore.

Voici à quoi ressemble maintenant le système:

100 utilisateurs: amener le client à un niveau distinct

Heureusement, notre application a vraiment aimé les premiers utilisateurs. Le trafic devient plus stable, il est donc temps de déplacer le client vers un niveau distinct. Il convient de noter que la séparation d' entités est un aspect clé de la construction d'une application évolutive. Puisqu'une partie du système reçoit plus de trafic, nous pouvons le diviser de manière à contrôler la mise à l'échelle du service en fonction de modèles de trafic spécifiques.

C'est pourquoi j'aime représenter le client séparément de l'API. Il est donc très facile de parler de développement pour plusieurs plates-formes: Web, Web mobile, iOS, Android, applications de bureau, services tiers, etc. Tous ne sont que des clients utilisant la même API.

Par exemple, maintenant, nos utilisateurs demandent le plus souvent de publier une application mobile. La séparation des entités clientes et des API facilite la tâche.

Voici à quoi ressemble le système:

1000 utilisateurs: ajouter un équilibreur de charge

Ca va bien. Les utilisateurs de Graminsta téléchargent de plus en plus de photos. Le nombre d'inscriptions augmente également. Notre seul serveur API a du mal à gérer tout le trafic. Besoin de plus de fer!

L'équilibreur de charge est un concept très puissant. L'idée clé est de placer l'équilibreur devant l'API et de répartir le trafic entre les instances de service individuelles. C'est la façon de faire évoluer horizontalement, c'est-à-dire que nous ajoutons plus de serveurs avec le même code, augmentant le nombre de requêtes que nous pouvons traiter.

Nous allons placer des équilibreurs de charge séparés devant le client Web et devant l'API. Cela signifie que vous pouvez exécuter plusieurs instances qui exécutent le code API et le code client Web. L'équilibreur de charge transmet les demandes au serveur le moins chargé.

Ici, nous obtenons un autre avantage important - la redondance. Lorsqu'une instance échoue (peut-être des surcharges ou des plantages), nous en avons encore d'autres qui répondent toujours aux demandes entrantes. Si une seule instance fonctionnait, en cas d'échec, tout le système tomberait.

L'équilibreur de charge fournit également une mise à l'échelle automatique. Nous pouvons le configurer pour augmenter le nombre d'instances avant la charge de pointe et réduire lorsque tous les utilisateurs dorment.

Avec un équilibreur de charge, le niveau de l'API peut être mis à l'échelle à l'infini, nous ajoutons simplement de nouvelles instances à mesure que le nombre de demandes augmente.

. , PaaS, Heroku Elastic Beanstalk AWS ( ). Heroku , - API. , Heroku — .

10 000 : CDN

Cela aurait peut-être dû être fait dès le début. Le traitement des demandes et la prise de nouvelles photos commencent à charger trop nos serveurs.

À ce stade, vous devez utiliser un service cloud pour stocker du contenu statique - images, vidéos et bien plus encore (AWS S3 ou Digital Ocean Spaces). En général, notre API doit éviter de traiter des choses comme le téléchargement d'images et le téléchargement d'images sur un serveur.

Un autre avantage de l'hébergement cloud est son CDN (dans AWS, ce module complémentaire est appelé Cloudfront, mais de nombreux services de stockage cloud le proposent immédiatement). CDN met automatiquement nos images en cache dans divers centres de données du monde entier.

Bien que notre centre de données principal puisse être situé dans l'Ohio, mais si quelqu'un demande une image au Japon, le fournisseur de cloud fera une copie et l'enregistrera dans son centre de données japonais. La prochaine personne à demander cette image au Japon la recevra beaucoup plus rapidement. Ceci est important lorsque nous travaillons avec des fichiers volumineux, comme des photos ou des vidéos qui prennent beaucoup de temps à télécharger et à transmettre à travers la planète entière.

100 000 utilisateurs: mise à l'échelle du niveau de données

CDN a vraiment aidé: le trafic augmente à pleine vitesse. La célèbre blogueuse vidéo, Maid Mobrick, vient de s'inscrire chez nous et a posté son histoire, comme on dit. Grâce à l'équilibreur de charge, le niveau d'utilisation du CPU et de la mémoire sur les serveurs d'API est maintenu bas (dix instances d'API sont en cours d'exécution), mais nous commençons à obtenir de nombreux délais d'attente pour les demandes ... d'où viennent ces retards?

Après un peu de fouille dans les métriques, nous voyons que le CPU sur le serveur de base de données est chargé à 80-90%. Nous sommes à la limite.

La mise à l'échelle de la couche de données est probablement la partie la plus difficile de l'équation. Les serveurs d'API servent des demandes sans état, nous ajoutons donc simplement plus d'instances d'API. Mais avec la plupartles bases de données échouent. Nous discuterons des systèmes de gestion de bases de données relationnelles populaires (PostgreSQL, MySQL, etc.).

Mise en cache

L'une des façons les plus simples d'augmenter les performances de notre base de données est d'introduire un nouveau composant: le niveau de cache. La méthode de mise en cache la plus courante consiste à stocker des enregistrements de valeurs-clés dans la RAM, tels que Redis ou Memcached. La plupart des clouds ont une version gérée de ces services: Elasticache sur AWS et Memorystore sur Google Cloud.

Le cache est utile lorsqu'un service effectue de nombreux appels répétés à la base de données pour obtenir les mêmes informations. En fait, nous accédons à la base de données une seule fois, enregistrons les informations dans le cache - et n'y touchons plus.

Par exemple, dans notre service Graminsta, chaque fois que quelqu'un accède à la page de profil de l'étoile Mobric, le serveur API demande des informations à son profil dans la base de données. Cela arrive encore et encore. Étant donné que les informations de profil de Mobrick ne changent pas à chaque demande, elles sont idéales pour la mise en cache.

Nous mettrons en cache les résultats de la base de données dans Redis par clé user:idavec une période de validité de 30 secondes. Maintenant, quand quelqu'un entre dans le profil de Mobrick, nous vérifions d'abord Redis, et si les données sont là, nous les transférons simplement directement de Redis. Maintenant, les requêtes sur le profil le plus populaire sur le site ne chargent pratiquement pas notre base de données.

Un autre avantage de la plupart des services de mise en cache est qu'ils sont plus faciles à faire évoluer que les serveurs de base de données. Redis dispose d'un mode de cluster Redis Cluster intégré. Comme un équilibreur de charge¹ , il vous permet de distribuer le cache Redis sur plusieurs machines (sur des milliers de serveurs, si nécessaire).

Presque toutes les applications à grande échelle utilisent la mise en cache; cela fait partie intégrante de l'API rapide. Traitement des demandes plus rapide et code plus productif - tout cela est important, mais sans cache, il est presque impossible d'adapter le service à des millions d'utilisateurs.

Lecture de répliques

Lorsque le nombre de requêtes vers la base de données a considérablement augmenté, nous pouvons faire une chose de plus: ajouter des répliques en lecture dans le système de gestion de base de données. En utilisant les services gérés décrits ci-dessus, cela peut être fait en un seul clic. La réplique en lecture restera pertinente dans la base de données principale et est disponible pour les instructions SELECT.

Voici notre système maintenant:

Actions supplémentaires

Au fur et à mesure que l'application évolue, nous continuerons de séparer les services pour les adapter indépendamment. Par exemple, si nous commençons à utiliser Websockets, il est logique d'extraire le code de traitement Websockets dans un service distinct. Nous pouvons le placer sur de nouvelles instances derrière notre propre équilibreur de charge, qui peut évoluer vers le haut et vers le bas en fonction des connexions Websockets ouvertes et quel que soit le nombre de requêtes HTTP.

Nous continuons également à lutter contre les restrictions au niveau de la base de données. C'est à ce stade que le moment est venu d'étudier le partitionnement et le sharding de la base de données. Les deux approches nécessitent des frais supplémentaires, mais elles vous permettent de faire évoluer la base de données presque à l'infini.

Nous voulons également installer un service de surveillance et d'analyse comme New Relic ou Datadog. Cela permettra d'identifier les requêtes lentes et de comprendre où des améliorations sont nécessaires. À mesure que nous évoluons, nous voulons nous concentrer sur la recherche de goulots d'étranglement et leur résolution - en utilisant souvent certaines idées des sections précédentes.

Sources

Ce message est inspiré de l'un de mes messages préférés à haute évolutivité . Je voulais concrétiser un peu l'article pour les premières étapes des projets et le détacher d'un fournisseur. N'oubliez pas de lire si vous êtes intéressé par ce sujet.

Notes de bas de page

Malgré les similitudes en termes d'équilibrage de charge sur plusieurs instances, l'implémentation de base du cluster Redis est très différente de l'équilibreur de charge. [rendre]

Comment passer de 1 à 100 000 utilisateurs