Plus de dix ans plus tard : l'évolution de l'Instant Purge™

L’invalidation instantanée du cache est essentielle pour la distribution de contenu dynamique. Les dernières nouvelles, les mises à jour d'événements en direct et les promotions e-commerce reposent toutes sur la capacité à purger rapidement les informations obsolètes. 

Pourquoi la purge instantanée est-elle aussi difficile à résoudre aujourd'hui qu'elle l'était lorsque nous l'avons abordée il y a plus de dix ans ? Eh bien, les réseaux de périphérie modernes sont distribués à l'échelle mondiale. Assurer une invalidation quasi simultanée sur tous ces nœuds de cache n'est pas une mince affaire. Nous devons communiquer les événements d'invalidation à chaque nœud actif en quelques millisecondes. De plus, il y a un équilibre constant à maintenir entre la fiabilité, la rapidité, l'échelle et la couverture. Nous devons réduire la latence sans compromettre la cohérence du cache tout en le rendant suffisamment performant pour être véritablement « instantané ». C’est un défi de taille. Il n'est pas étonnant qu'il ait fallu plus d'une décennie pour que d'autres tentent de rattraper.

Centraliser ou décentraliser ? 

Lorsque nous avons abordé ce problème il y a de nombreuses années, nous nous sommes rendu compte qu'il existait deux principales façons de le résoudre : centralisée ou décentralisée. La solution typique consiste à envoyer des requêtes de purge à un système central, qui coordonne ensuite la suppression du contenu des caches dans le monde entier. Bien que cette méthode puisse sembler simple, elle introduit un point de défaillance unique et une latence accrue — ce qui n'est guère idéal pour obtenir des résultats instantanés.

Nous avons commencé à envisager ce défi différemment. Au lieu de nous fier à une structure de commande centralisée, nous nous sommes demandé : et si nous considérions la purge comme un problème de messagerie distribuée qui pourrait être résolu de manière décentralisée ? Au lieu de ramener les requêtes de purge vers un emplacement central, pourquoi ne pas les intercepter en périphérie et utiliser la logique directement là-bas pour les distribuer rapidement ?

Maintenant, cette approche décentralisée n'est pas sans ses défis. C’est plus complexe à créer et cela ajoute de la complexité. Les serveurs peuvent temporairement perdre le contact entre eux, ou les messages peuvent être perdus ou retardés en transit. Mais nous avons trouvé un moyen de résoudre ce problème.

Comment fonctionne Instant Purge™ ?

Nous avons basé notre système sur un algorithme appelé Bimodal Multicast. C’est rapide, compréhensible et garantit que les messages seront livrés à terme. En pratique, voici comment cela fonctionne : lorsqu'un serveur de cache reçoit une requête de purge, il diffuse immédiatement le message à tous les autres serveurs via UDP. Avec des taux de perte de paquets typiques inférieurs à 0,1 % entre nos points of presence (POP), la latence de purge est souvent limitée uniquement par le délai du réseau.

Un concept clé de notre système : nous n'exigeons pas d'accusé de réception pour les messages de purger. En sautant cette étape, nous pouvons réduire la latence de moitié. Nous n'essayons pas non plus d'être trop astucieux en matière de routage. Au lieu de cela, nous diffusons la purger partout. Cela peut sembler inefficace, mais cela simplifie réellement les choses. Tous nos nœuds sont également capables de gérer le même trafic. Cela signifie que nous pouvons envoyer des requêtes de purge partout sans avoir à maintenir des cartes complexes de l’emplacement du contenu. C’est une approche plus simple et plus robuste qui s’adapte bien à mesure que notre réseau se développe.

Notre approche de l'architecture réseau nous confère également un avantage : nous avons créé nos POP pour un stockage cache maximal en périphérie et un contrôle programmatique plus intelligent. En exploitant intentionnellement un nombre réduit de PoP plus performants, nous réduisons la complexité de notre réseau et minimisons le nombre de serveurs devant recevoir des messages de purge. Cette décision architecturale offre des Advantage significatifs pour une purge instantanée. De plus, notre réseau défini par logiciel nous permet d'adapter et d'optimiser notre système de purge à la volée, sans être limité par des contraintes matérielles.

Comment cela s'est-il déroulé ? 

Maintenant, je suis sûr que vous vous demandez : « Ce système s'est-il bien adapté à l'échelle ? » A-t-il continué à bien fonctionner alors que nous avons ajouté de plus en plus de clients et de trafic ? « Votre approche a-t-elle porté ses fruits ? » Eh bien, la réponse courte est oui… comme nous l’avions prévu dans notre conception initiale, nous avons dû itérer sur notre système de purge afin d’augmenter le trafic que nous pouvons gérer et continuer à évoluer à l’échelle. Au fil du temps, nous sommes passés de 2 à 3k purges par seconde en 2018 à environ 60k purges par seconde aujourd’hui. Lorsque nous avons d'abord mis en œuvre la multidiffusion bimodale, elle provenait presque directement des articles académiques, mais il y avait des limites de mise à l'échelle. Au fil du temps, notre système est devenu le nôtre et n’est plus vraiment purement Bimodal Multicast. 

Au fil des ans, nous avons effectué des optimisations et des modifications à notre méthode de purge à trois reprises. Quelques années après avoir initialement introduit notre capacité de purge, nous avons commencé à rencontrer des problèmes d'échelle et de fiabilité en élargissant notre réseau et en gérant la météo sur Internet. Nous avons initialement configuré tous les nœuds sur un POP en tant que pairs sans hiérarchie, où chaque nœud recevait chaque requête de purge et avait la responsabilité de distribuer les paquets à tous les autres nœuds. Dans le but d’optimiser l’échelle à mesure que le nombre de nœuds augmentait et d'améliorer la fiabilité face à la perte de paquets due aux conditions Internet, nous avons envisagé, au lieu d’envoyer des messages de purge à chaque nœud d’un POP, de les envoyer à un seul et de le laisser les rediffuser aux autres nœuds du POP.

Cela a considérablement augmenté notre capacité à l’échelle et a réduit le nombre total d’opérations. Les requêtes de purge sont encapsulées dans des paquets UDP qui sont livrés à au moins deux nœuds sains à chaque point of presence du groupe, qui rediffusent ensuite les paquets aux nœuds voisins sur le réseau local. Ce mécanisme de « double distribution » est notre première couche de défense pour la fiabilité et réduit considérablement les risques qu'une requête soit perdue en transit en raison de la météo sur Internet.

Enfin, l'année dernière, nous avons travaillé sur la purge par lots qui a eu d'énormes répercussions sur la scalabilité (et qui a éliminé les alertes qui réveillaient certains d'entre nous la nuit !). Notre API a toujours permis aux clients de purger par lots avec une série de clés de substitution, mais cela ne constituait pas vraiment une « purge par lots ». Le système découpait le lot en purges individuelles, qui, en cas de volumes élevés, pouvaient inonder le système, nous alertant et nous obligeant à appliquer un rate limit pour ne pas dégrader les performances. Pas idéal pour nos clients ni pour nous. Nous avons donc modifié le système pour gérer réellement la purge par lots, améliorant ainsi la scalabilité et éliminant les Alertes et la limitation du débit. Nous sommes désormais convaincus que nous pouvons atteindre une échelle de centaines de milliers de purges par seconde.

L'avenir d'Instant Purge™

À l’avenir, nous travaillons sur des moyens de rendre notre système de purge encore plus performant et évolutif, et toujours avant que nous en ayons réellement besoin. Nous souhaitons toujours rester en avance sur la demande avec une capacité dix fois supérieure à celle dont nous avons actuellement besoin. Notre objectif est d’augmenter la capacité de centaines de milliers de requêtes par seconde à des millions par seconde, et nous pensons pouvoir étendre les optimisations et techniques que nous avons déjà mises en œuvre pour regrouper les éléments afin d’atteindre le niveau de performances et d’échelle supérieur. C'est un processus continu d'innovation pour garder une longueur d'avance sur les demandes croissantes.

En fin de compte, il s’agit de construire une architecture dynamique capable de s’adapter et d’évoluer à mesure que les besoins évoluent. En abordant le problème différemment et en adoptant la décentralisation, nous avons créé un système qui livre la promesse d’une purge véritablement instantanée. Cet article contient des déclarations « prospectives » qui sont basées sur les croyances et les hypothèses de Fastly et sur les informations actuellement disponibles à Fastly à la date de cet article. Les déclarations prospectives peuvent impliquer des risques connus et inconnus, des incertitudes et d'autres facteurs qui peuvent faire en sorte que nos résultats réels, nos performances ou nos réalisations soient matériellement différents de ceux exprimés ou sous-entendus par les déclarations prospectives. Ces déclarations incluent, mais ne sont pas limitées à, des déclarations concernant la performance future des produits et notre vision et nos objectifs pour les opérations futures. Sauf si la loi l'exige, Fastly n'assume aucune obligation de mettre à jour ces déclarations prospectives publiquement, ou de mettre à jour les raisons pour lesquelles les résultats réels pourraient différer matériellement de ceux anticipés dans les déclarations prospectives, même si de nouvelles informations deviennent disponibles à l'avenir. Les facteurs importants qui pourraient entraîner une différence matérielle entre les résultats réels de Fastly sont détaillés de temps à autre dans les rapports que Fastly dépose auprès de la Securities and Exchange Commission (SEC), y compris dans notre rapport annuel sur le formulaire 10-K pour l'exercice clos le 31 décembre 2024, et nos rapports trimestriels sur le formulaire 10-Q. Des copies des rapports déposés auprès de la SEC sont publiées sur le site web de Fastly et sont disponibles gratuitement auprès de Fastly.