Comment nous avons développé une API à haute charge

Nous avons mis en place un cache Varnish devant l’application pour servir de reverse proxy. Toutes les requêtes qui sont déjà en cache dans Varnish sont directement servies par celui-ci. Cette opération est un simple lookup effectué par le système Varnish. Ce dernier est hautement optimisé pour la performance, ce qui rend le processus extrêmement efficace. Ces requêtes prennent seulement quelques millisecondes à être servies.

Métriques

D’après le monitoring de Varnish, la fréquence des requêtes sur 24 heures ressemble à ceci:

Ce screenshot a été pris lors d’une journée typique, sans événement particulier. En journée, Varnish sert entre 40'000 et 100'000 requêtes par minute, avec des pics encore plus élevés. La nuit, l’activité diminue fortement.

Environ ⅔ des requêtes sont des cache hits dans Varnish. Le taux de hit est particulièrement élevé lorsque la charge est forte, ce qui allège considérablement la charge sur l’application backend.

Cette activité entraîne également une consommation de bande passante importante:

Optimiser au maximum la mise en cache

Toutes les requêtes à M-API doivent être authentifiées. Pour atteindre un taux de cache hit élevé, nous utilisons le pattern "user context", qui permet de cacher les requêtes par groupes d’utilisateurs ayant les mêmes permissions, plutôt qu’au niveau de chaque utilisateur·rice authentifié·e. Tu peux en lire plus sur ce pattern dans ce blogpost.

Nous avons aussi configuré Varnish pour nettoyer les paramètres de requête et l’en-tête Accept-Language, afin d’augmenter encore plus le taux de cache hit.

Comme l’application sait quand les données sont modifiées, nous avons défini une longue durée de vie du cache. Nous permettons aussi à l’application d’invalider activement le cache si nécessaire. Nous utilisons le mécanisme xkey de Varnish, qui permet de taguer toutes les réponses et de les invalider par tag.

Beaucoup de résultats de recherche sont des listes de produits, comme celles obtenues via une recherche en texte libre ou par navigation dans les catégories. Lorsque les données changent, l’ordre des résultats de recherche peut aussi changer. Comme nous utilisons un système de pagination, xkey seul ne suffit pas. Une modification affecte non seulement la page où le produit apparaissait auparavant, mais aussi toutes les pages suivantes. Invalider toutes les listes à chaque modification de produit rendrait le cache inutile.

Pour résoudre ce problème, nous utilisons Edge Side Includes (ESI). Les réponses des listes contiennent uniquement des instructions ESI qui font référence aux produits à inclure, mais pas les données elles-mêmes. Grâce à cela, la génération des listes est très efficace, nous permettant d’utiliser une durée de cache courte pour elles.

Varnish interprète l’ESI pour récupérer chaque produit individuellement et assembler la réponse pour le client. Les sous-requêtes pour les produits sont mises en cache plus longtemps et taguées avec leur ID produit, ce qui permet leur invalidation ciblée. Cela garantit que même si la liste est en cache, les produits affichés sont immédiatement mis à jour.

Nous avons également configuré le mode "grace", qui permet à Varnish de servir du contenu obsolète si l’application backend ne répond pas. Dans la plupart des cas d’usage de M-API, une information légèrement dépassée est préférable à une absence de réponse.

Application serveur

Tout ne peut pas être géré par la mise en cache HTTP. Pour les requêtes qui ne peuvent pas être mises en cache ou dont la réponse n’est pas encore en cache, le temps de réponse du backend est critique. PHP, et en particulier le framework Symfony que nous utilisons, est optimisé pour des temps de réponse rapides.

PHP est conçu pour les applications stateless. Dans M-API, chaque requête est totalement indépendante, ce qui permet l’étalonnage horizontal facile. L’infrastructure cloud surveille automatiquement la charge de l’application et ajoute ou supprime des instances en fonction de la demande.

Pour optimiser les temps de réponse, nous avons utilisé un profiler pour identifier les goulots d’étranglement et nous assurer que chaque amélioration apportait un réel gain. Nous avons identifié des données que nous avons ensuite stockées dans un cache applicatif (Redis), ce qui nous a permis de réduire considérablement les requêtes vers MySQL.

Après cette amélioration, une part significative du temps de traitement était consacrée à la conversion des objets en JSON. Nous avons exploré plusieurs solutions pour accélérer ce processus, avec au final une solution beaucoup plus rapide. Tu peux en lire plus dans cet article de blog.

Grâce à ces optimisations, nous avons atteint des temps de réponse d’environ 50 millisecondes pour les réponses produits – même lorsque chaque produit contient plusieurs centaines de KB à plus d’un MB de données JSON.