Présentation

L'augmentation du taux d'accès au cache (CHR) avec CloudFront améliore les performances d'une application Web et réduit la charge sur son origine. Le CHR est le ratio entre les demandes HTTP traitées depuis le cache CloudFront et le nombre total de demandes. Les demandes traitées depuis le cache CloudFront bénéficient d'une meilleure latence (par exemple, date du dernier octet), ce qui fait de CHR un bon indicateur du déchargement à l'origine et des performances des applications. Le CHR d'une distribution CloudFront peut être surveillé à l'aide de la métrique CloudWatch relative au taux d'accès au cache. Pour augmenter le CHR, vous pouvez optimiser la configuration de la mise en cache dans CloudFront, activer Origin Shield et optimiser le comportement de votre application.

Création de sites Web à faible latence avec Amazon CloudFront

Augmenter la durée de vie (TTL) du cache

Vous pouvez contrôler la durée pendant laquelle un objet est mis en cache dans CloudFront à l'aide de l'en-tête Cache-Control envoyé par votre origine, délimité par les paramètres Time To Live configurés dans les politiques de cache. L'augmentation des TTL a un impact positif sur le CHR, et il est donc recommandé de :

  • Configurer les en-têtes Cache-Control sur l'origine pour mieux contrôler la TTL dans CloudFront et tirer parti de la mise en cache du navigateur.
  • Mettre en cache les actifs statiques sous forme d'objets immuables (par exemple, Cache-Control : max-age=31536000, immuable) et variez leur chemin d'URL (par exemple /static/app.1be87a.js).
  • Implémenter des ETAGs sur vos objets pour bénéficier de demandes HTTP conditionnelles adressées à votre origine.
  • Pour un contenu plus dynamique tel que le HTML, trouvez le juste équilibre entre la mise en cache (TTL élevé) et la mesure dans laquelle l'application tolère un contenu obsolète (TTL faible).

Optimiser les paramètres de clés de cache

Les paramètres de clé des cache, à l'aide des politiques de cache, indiquent si CloudFront réutilise ou non un objet mis en cache pour une demande HTTP. Des paramètres de clés de cache optimisés créent une relation de 1 à 1 entre des clés de cache uniques et des objets uniques. Prenons l'exemple d'une application Web qui fournit le même /about.html quels que soient les paramètres de requête ajoutés (par exemple, /about.html?utm_medium=social). Si la clé de cache est configurée pour inclure le paramètre de requête utm_medium, CloudFront mettra en cache différentes URL (par exemple, /about.html?utm_medium=socialet/about.html?utm_medium=email) en utilisant deux clés de cache distinctes. Cela se traduit par deux erreurs de cache à l'origine, même si les deux demandes concernent exactement le même fichier sur l'origine, ce qui n'est pas optimal.

La première bonne pratique pour optimiser les paramètres des clé de cache consiste à inclure exclusivement dans le cache des attributs de demande de clé qui font varier les réponses d'origine. Pour y parvenir, il est recommandé ce qui suit :

  • Configurer des comportements de cache distincts pour les objets qui nécessitent des paramètres de clé de cache différents.
  • Si les paramètres de requête, les en-têtes ou les cookies font varier les réponses à l'origine, n'incluez que celles qui le font réellement (par exemple, cookie user_id au lieu de tous les cookies).
  • Utiliser les politiques d'en-tête de réponse dans CloudFront pour gérer CORS, au lieu d'ajouter des en-têtes CORS (par exemple, Origin, Access-Control-Request-Method, Access-Control-Request-Headers) à la clé de cache et gestion du CORS au niveau de l'origine.
  • Décharger le contrôle d'accès vers CloudFront à l'aide d'URL signées, des fonctions CloudFront ou de Lambda@Edge, au lieu d'ajouter un en-tête d'autorisation à la clé de cache et de le gérer au niveau de l'origine.
  • Utiliser la politique de demande d'origine dans CloudFront pour transférer les attributs HTTP à l'origine au lieu de les ajouter à la clé de cache.

La deuxième bonne pratique consiste à normaliser un attribut de demande avant de l'ajouter à la clé de cache afin de réduire la cardinalité de ses valeurs possibles, chacune donnant lieu à une clé de cache unique. Pour y parvenir, il est recommandé ce qui suit :

  • Envoyer les paramètres de requête, lorsqu'ils sont utilisés, dans le même ordre et avec la même casse.
  • Utiliser les en-têtes générés par CloudFront tels que CloudFront-Is-Mobile-Viewer pour identifier un type d'appareil au lieu d'ajouter un en-tête User-agent à la clé de cache.
  • Utilisation des fonctions CloudFront pour appliquer des normalisations avancées, telles que : Réordonner et réduire la casse des paramètres de requête ; Diffuser une version différente d'une page web basée sur l'existence d'un cookie, au lieu d'ajouter le cookie à la clé de cache ; Réduire la variance des réponses qui varient en fonction des pays, lorsque la même réponse peut être envoyée pour un groupe de pays ; Réduire davantage la cardinalité d'Accept-Encoding lorsque la compression est nécessaire, ou la cardinalité des en-têtes de détection d'appareil CloudFront lorsque plusieurs d'entre sont utilisés.

Activer Origin Shield

Par défaut, CloudFront réduit le nombre d'erreurs de cache à l'origine en utilisant deux couches de mise en cache de haut niveau : une couche au niveau du PoP et une autre au niveau du Regional Edge Cache (REC). Un PoP CloudFront est nominalement associé à l'un des plus de 10 REC du monde. Lorsqu'une demande entraîne l'absence de cache au niveau PoP, CloudFront vérifie le cache au niveau du REC associé pour répondre à la demande, et uniquement si elle n'est pas mise en cache dans ce REC, CloudFront transmet la demande à l'origine. Les REC sont isolés les uns des autres pour maintenir une haute disponibilité et, ce faisant, ne partagent pas leurs caches. Par conséquent, lorsque des objets populaires sont demandés depuis différents emplacements dans le monde, CloudFront envoie plusieurs demandes pour les mêmes objets à l'origine à partir de plusieurs REC.

Pour réduire le nombre de demandes transmises à l'origine, vous pouvez activer Origin Shield dans CloudFront, qui constitue une troisième couche de mise en cache de haut niveau entre les REC et votre origine. Au lieu de demander des objets directement à l'origine, les REC essaient d'abord de répondre aux demandes depuis le cache d'Origin Shield.

Optimiser le comportement des applications

Envisagez les modifications au niveau de l'application qui peuvent avoir une influence positive sur le taux d'accès au cache. Les exemples incluent :

  • Réduction des objets de cardinalité servis par votre application. Lorsque votre application produit plusieurs rendus d'un même élément, par exemple différentes tailles d'image pour s'adapter à différents écrans, pensez à limiter le nombre de valeurs possibles pour la largeur et la hauteur.
  • Utilisation de la mise en cache du navigateur. Cela peut être fait à l'aide de l'en-tête Cache-Controlenvoyé par votre origine. Vous pouvez différencier les TTL entre CloudFront et le navigateur soit en utilisant les directives max-age avec s-maxage dans l'en-tête Cache-Control, soit en utilisant l'en-tête Cache-Control pour le navigateur et en contrôlant les TTL CloudFront à l'aide de politiques de cache.
  • Utilisez des demandes de plage d'octets dans vos clients pour ne télécharger que ce qui est nécessaire.

Ressources

Cette page vous a-t-elle été utile ?

 Commentaires