Chez Kinsta, nous sommes obsédés par la vitesse : Nos services d’hébergement d’applications, d’hébergement de bases de données et d’hébergement WordPress infogéré fonctionnent tous sur le réseau Premium Tier et les machines C2 les plus rapides de Google Cloud Platform, et nous comptons sur Cloudflare pour garder le pied au plancher pour des dizaines de milliers de clients qui veulent diffuser leur contenu dans le monde entier avec rapidité et sécurité.
En faisant cela, nous avons appris une chose ou deux sur l’utilisation des workers de Cloudflare et des Workers KV pour fournir des règles de mise en cache optimisées pour le contenu statique et dynamique.
Au début de l’année 2023, nous avons redoublé d’efforts dans la gestion du cache Cloudflare, en rendant les caches plus réactifs aux changements de configuration côté client, tout en transférant le gros du travail de diffusion des mises à jour de fonctionnalités de nos administrateurs en arrière-plan vers les workers Cloudflare. L’un des principaux résultats a été une augmentation spectaculaire de la part des données clients mises en cache avec succès, qui a augmenté de 56,3 % entre octobre 2022 et mars 2023.
Les workers Cloudflare et les workers KV nous permettent de personnaliser de manière planifiée chaque requête et chaque réponse avec un minimum d’effort et une latence réduite. Nous n’avons plus besoin de déployer des changements dans des centaines de milliers de conteneurs lorsque nous voulons mettre en œuvre de nouvelles fonctionnalités ; nous pouvons répliquer ou mettre en œuvre la fonctionnalité avec workers et la déployer partout en quelques commandes et clics, nous épargnant ainsi des jours de travail et de maintenance.
Routage des requêtes avec les workers KV
Chaque domaine hébergé par Kinsta est une clé, et sa valeur contient au moins les paramètres de base, comme l’IP et le port de l’origine, ainsi qu’un identifiant aléatoire unique. Ces données étant facilement disponibles dans le workers KV, nous pouvons utiliser les workers pour analyser, manipuler et acheminer les requêtes vers le backend prévu. Nous utilisons également workers KV pour stocker les options d’optimisation des clients telles que Polish, Image Resizing et Auto Minify.
Pour acheminer les requêtes vers des IP et des ports personnalisés, nous utilisons resolveOverride, une propriété de requête spécifique à Cloudflare. Voici un exemple :
// Assign KV values to variables
const { customBackend } = kvdata.kinstaConf;
// Override the backend
cf.resolveOverride = customBackend;Cependant, bien que les workers KV aient bien fonctionné pour acheminer les requêtes, nous avons rapidement remarqué des réponses incohérentes dans notre cache. Parfois, un client activait Polish, et en raison du cache d’une minute des workers KV, de nouvelles requêtes arrivaient avant que les workers KV ne propagent complètement le changement, ce qui nous amenait à mettre en cache des ressources non optimisées. Dans ce cas, le client devait à nouveau vider son cache manuellement. Ce n’est pas le scénario idéal. Les clients étaient frustrés et nous gaspillions des opérations API et de la bande passante GCP en purgeant constamment les caches.
La clé du cache est la clé
Comme nous lisons toujours les données KV des workers du domaine, nous avons réalisé que nous pouvions acheminer les requêtes et personnaliser la clé de cache, en y ajoutant des éléments tels que l’ID du domaine et des caractéristiques susceptibles d’affecter la ressources, comme le Polish. Aujourd’hui, notre clé de cache est fortement personnalisée pour refléter rapidement chaque modification apportée par le client à notre panneau ou à notre API. En modifiant la clé de cache à l’aide des données des workers KV, plus personne n’a besoin de se soucier de vider le cache. Dès que les workers KV propagent les changements, la clé de cache change également, et nous demandons et mettons en cache une nouvelle ressource.
La façon la plus simple de personnaliser la clé de cache est d’y ajouter query params. Par exemple :
let cacheKey = `${request.url}?custom-cache-param-polish=lossy`Bien entendu, vous devez vérifier les paramètres existants dans l’URL pour déterminer le connecteur à utiliser – ? ou & – et vous assurer que vous utilisez un identifiant unique.
Ensuite, vous pouvez utiliser cette nouvelle clé de cache pour enregistrer la réponse avec Cache API ou Fetch – ou les deux.
Cache KV des workers
Les opérations KV des workers sont abordables, mais les chiffres peuvent s’accumuler lorsque vous déclenchez des milliards d’opérations de lecture par jour.
Grâce à la personnalisation de notre clé de cache, nous avons réalisé que nous pouvions mettre en cache les données des workers KV avec le cache API, ce qui permet d’économiser sur les opérations de lecture et éventuellement de réduire la latence en évitant de multiples requêtes GET Workers KV par visiteur. Comme la réponse mise en cache est désormais basée sur l’URL de la demande combinée aux données KV, nous n’avons plus à nous soucier de la mise en cache de contenus périmés.
Cependant, contrairement à de nombreuses applications, nous ne pouvons pas mettre en cache les workers KV pendant de longues périodes. Les clients de Kinsta essaient constamment de nouvelles fonctionnalités, modifient les réglages Polish et Auto Minify, excluant parfois des pages ou des extensions de la mise en cache, et ils veulent voir leurs changements en production dès que possible.
C’est pourquoi nous avons décidé de mettre en micro-cache les données de nos workers KV – en mettant en cache le contenu dynamique ou constamment modifié pendant une très courte période de temps, généralement moins de 60 secondes.
Il est assez simple d’implémenter votre propre logique de mise en cache des workers KV. En voici un exemple :
const handleKVCache = async (event, myCustomDomain) => {
// Try to get KV from cache first
const cache = caches.default;
let site_data = await cache.match( `https://${myCustomDomain}/some-string-ID-kv-data/` );
// Valid KV cache match
if (site_data && site_data.status === 200) {
// ... modify your cached data if necessary, then return it
return site_data;
}
// Invalid cache (expired, miss, etc), get data from KV namespace
site_data = await KV_NAMESPACE.get(myCustomDomain.toLowerCase());
// Cache valid KV responses with Cache API
if (site_data) {
let kvResponse = new Response(JSON.stringify(site_data), {status: 200});
kvResponse.headers.set("Cache-Control", "public, s-maxage=30");
event.waitUntil(cache.put(`https://${myCustomDomain}/some-string-ID-kv-data/`, kvResponse));
}
return site_data;
};(Optionnellement, vous pouvez utiliser BetterKV de FlareUtils.)
Chez Kinsta, nous avons mis en place un cache TTL de 30 secondes pour les données KV des workers, ce qui a permis de réduire les opérations de lecture d’environ 80 %.
En savoir plus
Vous voulez en savoir plus sur les workers et les workers KV ? Consultez la documentation du développeur des workers Cloudflare KV, ou commencez par visiter la page d’accueil dédiée aux workers KV de Cloudflare.
Cet article a été publié à l’origine sur le site web de Cloudflare.
Paulo est un ingénieur DevOps chevronné chez Kinsta, avec un arrière-plan solide en matière d'hébergement et d'optimisation web. Doté d'une expertise en Bash et en JavaScript, il utilise les workers de Cloudflare pour améliorer continuellement les expériences des utilisateurs dans l'hébergement.
Laisser un commentaire