Pourquoi Cloudflare met en cache en mémoire même les éléments impopulaires
(blog.cloudflare.com)Cloudflare a publié sur son blog son retour d’expérience sur un changement de stratégie de cache qui a permis de réduire jusqu’à 25 % la charge d’écriture sur les SSD. (en anglais) Contrairement à l’idée reçue, Cloudflare a atteint cet objectif en mettant délibérément en cache en mémoire même des éléments peu fréquemment consultés.
Les SSD sont des supports de stockage fragiles face aux écritures. Les cellules de mémoire flash qui stockent les données sur un SSD ont un nombre limité de réécritures possibles, et effacer puis réécrire des données prend relativement longtemps, tout en ralentissant aussi les opérations de lecture. Réduire les écritures est donc une optimisation particulièrement importante sur les SSD.
Comme Cloudflare utilise massivement des SSD NVMe hautes performances dans ses serveurs, l’entreprise s’est naturellement penchée sur cette question. Cloudflare est un fournisseur de CDN, et un CDN peut essentiellement être vu comme un immense cache réseau. Le contenu stocké sur les SSD des serveurs Cloudflare n’est, au fond, que des éléments mis en cache, et leurs observations ont montré qu’une grande partie d’entre eux n’étaient plus jamais consultés après leur premier stockage en cache — ce qu’on appelle des « one-hit wonders ». Il est donc préférable de ne pas écrire ce type d’éléments sur SSD. Lors d’une expérimentation visant à ne pas enregistrer sur SSD les éléments consultés une seule fois, les résultats ont été encourageants : la latence des SSD a baissé de près de 5 %.
Le problème était de savoir comment appliquer cette idée à l’échelle d’un service réel. Ne pas mettre un élément en cache lors du premier accès puis commencer à le mettre en cache à partir du deuxième signifie doubler le nombre d’accès à la source des données. Cela entraîne évidemment des coûts supplémentaires, ce qui irait à l’encontre de l’objectif recherché. Cloudflare a donc hiérarchisé l’écriture du cache en deux étapes. D’abord, tous les éléments sont mis en cache dans la mémoire, qui joue le rôle de « cache court terme », puis seuls les éléments consultés plusieurs fois sont « promus » et écrits sur le SSD, qui sert de « cache permanent ». Les éléments peu consultés sont alors naturellement évincés du cache. Côté lecture, aucune attention particulière n’était nécessaire, car les lectures depuis le SSD sont déjà bien mises en cache par le système d’exploitation.
Bien sûr, l’application concrète de cette idée dans un service en production se fait avec prudence et de façon conservatrice. Cette approche consomme par nature beaucoup de mémoire, ce qui peut entrer en concurrence avec le cache existant du système d’exploitation. De plus, lors des mises à jour des processus serveur en mode déploiement sans interruption, un manque temporaire de mémoire peut survenir et dégrader au final la qualité de service. C’est pourquoi cette idée est progressivement déployée uniquement sur les nouveaux serveurs disposant de suffisamment de mémoire.
Les résultats sont positifs. Après ajustement de la taille du cache, les écritures sur SSD ont diminué de 20 % à 25 % au maximum, ce qui s’est traduit par une baisse de la latence. À l’avenir, Cloudflare prévoit d’étendre cette technique à davantage de serveurs, d’améliorer l’algorithme de promotion en y ajoutant aussi une « rétrogradation », et de construire une hiérarchie prenant en compte non seulement les SSD mais aussi les HDD.
La première chose à laquelle cela m’a fait penser est la technique de ramasse-miettes de Java. Le postulat de base de la plupart des techniques de garbage collection est en effet que [la majorité des objets ne sont utilisés que pendant une très courte durée], ce qu’on appelle l’« hypothèse générationnelle faible » (weak generational hypothesis). Le principe présenté ici semble en être une sorte de variation appliquée à un autre contexte.
3 commentaires
Merci pour ce bon article.
J’ai l’impression qu’il y a pas mal d’articles discrètement intéressants publiés sur le blog de Cloudflare.
Comment gère-t-on un bon blog technique d’entreprise ? https://fr.news.hada.io/topic?id=1698
Je pense que c’est parce que le blogging s’est installé comme une culture interne chez Cloudflare.
C'était très intéressant, merci.
Waouh… même la traduction d’un coup, haha. Merci de partager ce bon contenu.