Après avoir franchi les étapes de la virtualisation et sécurisé nos fondations avec un réseau virtuel robuste, notre produit est enfin en production. Grâce à l’IA, nous avons développé des fonctionnalités à une vitesse inédite. Les premiers utilisateurs arrivent, le compteur de visites s'affole, et c'est la consécration.
Pourtant, le rêve peut rapidement tourner au cauchemar. Sans crier gare, les premiers retours négatifs tombent : l'interface fige, les requêtes montrent des lenteurs inhabituelles, et pire encore, certaines actions échouent, entraînant des pertes de données.
Notre infrastructure, autrefois si agile en environnement de test, vient de heurter son premier mur de réalité : les limites de charge. Améliorer et adapter notre système pour absorber ce flux devient une priorité absolue, mais cette transition ne doit pas se faire au hasard. Pour passer d’un prototype prometteur à un service hautement disponible et enterprise-ready, nous devons adopter une démarche méthodique d'architecte.
Le point de départ : l'analyse anatomique de notre tuyauterie#
Avant de jeter aveuglément de la puissance de calcul (et du budget) sur nos serveurs, nous devons impérativement identifier la cause racine du problème. C'est ce que nous appelons la recherche du goulot d'étranglement (ou bottleneck), c'est-à-dire de la brique spécifique qui ralentit tout le reste de la chaîne.
Pour bien visualiser le phénomène, imaginons notre infrastructure comme un réseau de tuyauterie :
- Les requêtes de nos utilisateurs sont de l'eau qui entre en masse dans le conduit.
- Notre code, nos bases de données et nos serveurs sont des stations de traitement et des vannes disposées tout au long de ce réseau.
Si l'eau s'accumule et déborde à l'entrée, cela ne signifie pas nécessairement que notre pompe principale (le processeur ou CPU) est trop faible. Le problème vient peut-être d'un filtre encrassé un peu plus loin (une requête SQL mal optimisée) ou d'un tuyau trop étroit (la bande passante réseau). Augmenter la taille de la pompe sans nettoyer le filtre ne fera qu'augmenter la pression et provoquer une rupture brutale du système.
Les ralentissements peuvent donc résulter de deux grands facteurs. D'un côté, nous pouvons être confrontés à une saturation des ressources physiques : notre machine virtuelle n'a tout simplement plus assez de mémoire vive (RAM) ou de puissance CPU pour traiter les demandes simultanées. Mais d'un autre côté, nous faisons peut-être face à l'inefficacité sur le plan de la logique de notre application. Une brique logicielle spécifique n'est pas optimisée, ce qui paralyse l'ensemble du flux de données, même si les serveurs tournent au ralenti.
Optimiser le traitement des données#
Avant de modifier l'infrastructure matérielle, nous pouvons obtenir des gains de performance perceptibles en retravaillant la façon dont nos données sont manipulées.
Le refactoring du code sur le chemin critique#
Lorsque nous développons avec l'aide de l'IA, celle-ci produit un code fonctionnel, mais pas toujours optimisé pour la haute performance. Et les problématiques de performance peuvent se déplacer dans l'application selon l'activité des utilisateurs. Nous pouvons nous retrouver avec une portion de code, appelée le « chemin critique », absorbant une quantité disproportionnée de charge. Par exemple, une boucle imbriquée qui traite des milliers d'éléments en mémoire à chaque clic utilisateur.
En demandant explicitement à notre IA de réécrire cette portion spécifique pour en réduire la complexité algorithmique (la façon dont le traitement est réalisé), nous pouvons réduire drastiquement le temps d'exécution.
L'indexation des bases de données#
C'est un domaine pouvant nécessiter une expertise pointue et une très bonne compréhension de notre application.
Par défaut, lorsqu'on interroge une base de données pour trouver un utilisateur (par exemple par son adresse e-mail), le système effectue souvent un parcours complet de la table (le « Full Table Scan »). Il lit chaque ligne, une par une. Et s'il y a 100 000 utilisateurs, l'opération devient extrêmement lourde.
Mettre en place un index, c'est comme ajouter un index alphabétique à la fin d'un livre épais. La base de données ne lit plus tout l'ouvrage ; elle consulte l'index pour savoir exactement à quelle page se trouve l'information, réduisant le temps de recherche à quelques millisecondes. Pour être efficace, l'index doit être choisi en fonction de la façon dont les utilisateurs accèdent aux données, des liens avec les autres tables, etc. C'est pourquoi une analyse approfondie de notre schéma de base sera nécessaire avant de trouver les bons index.
J'ai connu une équipe qui a fait intervenir un expert pour revoir entièrement leur base de données, et l'ajout des index à lui seul a permis de réduire considérablement les coûts, allant parfois jusqu'à diviser par dix le traitement des requêtes.
Élargir le conduit : trois stratégies majeures pour absorber le flux#
Si l'optimisation du code ne suffit plus, nous devons introduire de nouveaux composants architecturaux pour protéger et répartir la charge sur notre infrastructure.
Le Caching : mettre en cache les données#
La requête la plus rapide est celle que l'on n'exécute pas. La mise en cache consiste à stocker temporairement les résultats des requêtes lourdes ou fréquentes dans une mémoire ultra-rapide.
Plutôt que d'aller interroger la base de données à chaque fois qu'un utilisateur affiche la page d'accueil ou le catalogue produit, notre application récupère directement l'information pré-calculée dans ce « comptoir rapide ». Nous opterons ainsi pour des solutions comme Redis ou Memcached, qui sont des technologies de cache, sur des requêtes particulièrement volumineuses, et qui sont très souvent sollicitées par les utilisateurs. Redis est une technologie bien établie, offrant de nombreuses fonctionnalités plus avancées que Memcached, qui s'est concentré sur la simplicité. Le choix de la technologie dépendra donc des besoins précis.
Parmi les fonctionnalités communes aux deux se trouvent des mécanismes permettant d'automatiser la suppression des données en cache, afin de contrôler le moment où notre application retournera chercher les données en base (par exemple parce qu'on a identifié que ces données deviennent obsolètes au bout de quelques heures ou quelques jours, ou à un moment précis de la journée, etc.).
De cette façon, la base de données respire, et l'utilisateur obtient une réponse instantanée, tout en retrouvant des données restant pertinentes en toutes circonstances.
Le Throttling et le Rate Limiting pour la régulation du trafic#
Pour éviter qu'une vague de trafic soudaine ou qu'une attaque malveillante ne fassent s'effondrer nos serveurs, nous devons poser des garde-fous : c'est le throttling, littéralement la limitation de débit. L'idée n'est pas de rejeter violemment l'utilisateur avec une erreur brute, mais de réguler poliment le débit grâce à des mécanismes intelligents.
Par exemple, un algorithme très courant appelé « token bucket » permet d'attribuer une réserve virtuelle de jetons à chaque utilisateur. Chaque requête consommera alors un jeton, tandis qu'ils se régénèrent à un rythme fixe. Si le seau est vide, les requêtes excédentaires sont temporisées ou rejetées, évitant la surcharge : le système introduit volontairement une infime pause de quelques millisecondes dans le traitement des requêtes.
Nous pouvons également rejeter certaines requêtes répétitives, ce que nous appelons le rate limiting. Cela nous permet de lisser les pics d'activité.
Bien entendu, ces solutions peuvent être combinées pour tirer le meilleur profit selon les différents cas de figure que rencontre notre application. À titre d'exemple concret, j'ai eu l'opportunité d'implémenter un système de throttling avec deux seaux au lieu d'un, de sorte à réduire le délai d'attente si le dépassement reste faible. Nous avions également utilisé Redis pour stocker les compteurs de jetons, et nous avions fait en sorte qu'il soit possible de configurer le throttling différemment en fonction des types de requêtes (lecture de données, modification, etc.) et suivant les utilisateurs.
Le traitement asynchrone pour décorreler la réception du traitement#
Un mécanisme plus poussée consiste à utiliser un Message Broker (un système de messagerie, ou une file d'attente ; l'une des plus connues étant RabbitMQ). Au lieu de traiter immédiatement une action lourde (comme la génération d'une facture en PDF), l'application la dépose dans une file d'attente, qui sera dépilée de façon asynchrone : lorsque le processus de génération des factures est libre, il prend une requête de la file pour la traiter (généralement la plus ancienne, mais il existe plusieurs stratégies différentes).
Le Load Balancing, pour la répartition de charge#
Quand une seule machine virtuelle ne suffit plus, une approche que nous avions déjà eue l'occasion d'évoquer consiste à cloner notre application sur plusieurs instances et à placer un Load Balancer en tête de réseau. Ce composant unique reçoit toutes les requêtes des utilisateurs et les distribue intelligemment entre nos différents serveurs disponibles. Étant spécialisé dans cette tâche, il est beaucoup plus à même de recevoir un très grand volume de requêtes que notre application. C'est donc une stratégie très courante pour s'adapter face à une forte demande sur nos services.
Un exemple très connu de répartiteur de charge est NginX, que nous connaissons également en tant que serveur web. Très performant, polyvalent et massivement utilisé dans l'industrie, ce logiciel permet ainsi de combiner plusieurs services en un.
Nous pouvons également parler d'HAProxy, qui se situe à l'opposé de NginX, dans la mesure où il est spécialisé dans la répartition de charge. Il permet ainsi de gérer la répartition des connexions et requêtes, et de gérer la charge à très grande échelle.
Enfin, nous pouvons également citer Traefik, qui est un challenger récent. Conçu à l'ère des conteneurs (dont nous avons déjà parlé au travers de Docker et Kubernetes) et des micro-services, il s'intègre automatiquement avec nos outils de déploiement et découvre dynamiquement les nouvelles instances applicatives sans nécessiter de reconfiguration manuelle fastidieuse... ce qui en fait un bon outil pour l'auto-scaling, dont nous avons déjà parlé.
Conclusion#
Maîtriser ces concepts théoriques de gestion de charge est indispensable, même si nous déléguons la production du code ou la configuration des scripts à notre IA favorite. Nous ne pouvons pas nous permettre d'être un spectateur passif, car pour mener une analyse efficace avec l'IA lors d'une crise de performance, nous devons être capables de formuler les bonnes hypothèses et d'orienter l'investigation.
Si nous ne comprenons pas la différence entre un index manquant et une saturation de bande passante, nous perdrons un temps précieux à appliquer de mauvais remèdes.
En complément de cet article, nous verrons prochainement comment poser le bon diagnostic et quels outils mettre en place, car pour être efficace, notre IA doit avoir les bonnes informations.
Ressources (et quelques lectures intéressantes)#
- Designing Data-Intensive Applications, de Martin Kleppmann.
- Systems Performance: Enterprise and the Cloud, de Brendan Gregg
- High Performance Web Sites, de Steve Souders
- Site Reliability Engineering (SRE), de l'équipe d'ingénierie Google