AWS re:Invent 2013 (2.2/2) : Use Cases – Accélérer la délivrance de son contenu via CloudFront et Route 53

Waterfall Graphs

Cet article fait suite à la synthèse des sorties annoncées lors du summit AWS re:Invent 2013 qui s’est déroulé cette année du 12 au 15 Novembre à Las Vegas. Nous allons aborder dans cet article l’accélération de la délivrance du contenu d’un site via CloudFront et Route 53. Cet article va expliquer les mécanismes mis en place au niveau de CloudFront pour optimiser la vitesse de récupération du contenu depuis la source et de distribution vers le navigateur, voire même comment améliorer l’envoi de données depuis un formulaire vers votre serveur Web en passant par CloudFront qui sert de relai. Nous verrons également quels contenus sont éligibles à être cachés.

Cet article se base sur une présentation très intéressante de Kalyanaraman Prasad (AWS) et Parviz Deyhim (AWS), de même que les illustrations qui en sont tirées. Je diverge des avis présentés durant la session sur 2 points que je signalerai dans l’article.

Vous pourrez retrouvez également les autres articles de cette série consacrée au retour d’expérience du summit AWS en suivant ces liens Optimisation de son cluster EMR (Elastic MapReduce)Créer son NAS sur AWS : NFS, CIFS & GFS (GlusterFS) ou bien encore Concept du monitoring à grande échelle avec S3 et EMR par Netflix. C’est parti pour l’article 2.2 de la série ! :o)

Accélérer la délivrance de son contenu via CloudFront et Route 53

Même si on passe beaucoup de temps à optimiser les backends, le ressenti utilisateur provient avant tout du frontend et de la manière de construire la page et de délivrer le contenu au browser. Le CDN (Content Delivery Network) est donc un outil très important de notre architecture pour apporter le contenu au plus près de l’utilisateur final.

Cet article sera articulé dans un mode lessons learned.

Les types de contenus :

  • Static - CSS/JS/images/… – High TTLs - URL type cdn.example.com pointant vers CDN ayant pour origine un storage comme S3 ou un serveur Web.
  • Re-Usable – Contenu personnalisé/API Calls/… – Low TTLs - URL type cdn.example.com pointant vers CDN ayant pour origine un serveur Web.
  • Dynamic/Unique – index.jsp – Zero TTL - URL type www.example.com pointant vers un serveur Web.

Cacher des URLs avec des paramètres comme des APIs Calls (Re-Usable) est une bonne idée, même pour quelques secondes et même si chaque jeu (combinaison) d’arguments génère un item caché différent pour un call sur un type de ressource : /maressource?a=1&b=2 est un item différent de /maressource?a=1&b=3. En effet, il faut prendre en compte le nombre de RPS (Requêtes Par Seconde) pour évaluer le bénéfice : on décharge l’origine du nombre de RPS x TTL (donc économie de ressources – bande passante, CPU, …) et on donne aux utilisateurs un meilleur rendu à partir du moment où le contenu est mis en cache pour la période (TTL), donc pour ceux après le premier utilisateur de chaque période.

Et pourquoi ne pas tout mettre derrière le CDN avec une URL type www.example.com pointant vers le CDN ayant pour origine un serveur Web ou un storage ? Y compris les contenus dynamiques générés à la volée par le serveur Web comme le point d’entrée du site (index.jsp, index.php, …). Nous allons voir cela.

Avantages de CloudFront :

  • Edge Locations permettant de rapprocher le contenu à délivrer du end-user.
  • Optimisations TCP/IP au niveau réseau via connexions persistantes (Keep-Alive).
  • Terminaison SSL (SSL offloading).
  • Prise en charge des verbes POST/PUT pour optimiser l’upload de données.
  • Latency Based Routing (via Route 53, dans le cas d’un déploiement multi-régions).
Waterfall Graphs

Waterfall Graphs

Overall Response Time

Overall Response Time

Analyse du temps de chargement :

  • Utilisation de Waterfall Graphs (extension standard dans les navigateurs) pour déterminer les étapes de chargement d’une ressource dans une page : DNS Lookup => TCP Connection => Time to First Byte => Content Download.

Trouver quels contenus cacher en priorité et détecter des comportements utilisateurs inattendus :

  1. collecter les access logs du serveur web,
  2. stocker les logs dans un storage adapté fonction de la volumétrie : par exemple, si on est sur la plateforme AWS, on peut utiliser RDS, DynamoDB, Redshift ou encore S3 (le stockage par bloc de logs peut être une bonne solution en cas de forte volumétrie),
  3. analyser les logs par divers moyens : requête SQL sur RDS, EMR à partir de données dans DynamoDB, Redshift ou S3,
  4. détecter des top queries.

Optimisation de la délivrance du contenu, même dynamique :

TCP Handshake

TCP Handshake

Improve DNS Time

  • Route 53… Je ne pense pas que Route 53 soit le principal facteur d’optimisation du DNS Time. Même si je ne doute pas de l’efficacité du service, ni de l’intérêt de l’utiliser en termes d’intégration avec CloudFront, ce dont je parle après, c’est avant tout le fait qu’il soit distribué dans les Edges Locations d’AWS qui devrait être mis en avant. Maintenant si vous utilisez un DNS encore plus près de vos end-users, cela fera de la distance en moins à parcourir à la requête de résolution « hostname => IP » et donc améliorera le DNS Time. A noter que le DNS Time dépend également de ce que vous avez renseigné au niveau du DNS (si vous avez configuré un plat de spaghetti au niveau des records, cela peut ralentir la résolution) et des TTLs configurés sur vos records. Maintenant Route 53 fait bien sont office, alors pourquoi ne pas profiter de ce service.

Improve TCP Connection

  • CloudFront avec les connexions persistantes (Keep-Alive) entre CloudFront et l’origine => TCP handshake (cf. image ci-contre) récurrent limité au dialogue entre end-user et CloudFront (donc sur de plus courtes distances).
  • Dans le cas d’une connection SSL, CloudFront prend en charge le SSL offloading avec son certificat ou le vôtre que vous pouvez importer : l’idée est encore d’effectuer ces opérations au plus près du end-user et de décharger l’origine des traitements récurrents comme le SSL offloading sur chaque connexion utilisateur. A noter qu’il est possible post CloudFront de continuer sur du HTTPS jusqu’à l’origine (si nécessaire pour du contenu sensible) ou bien de switcher en HTTP, dans le cas où le HTTPS en pré CloudFront avec été positionné uniquement pour éviter les erreurs du type « la page contient des éléments non sécurisés » dans une page délivrée en HTTPS.
TCP Slow Start

TCP Slow Start

Improve Time To First Byte

  • Autrement connu sous le nom de TTFB, c’est un bon indicateur qui inclut la latence aller/retour de la requête HTTP et le temps de génération de la page (dans le cas d’un contenu dynamique). Par rapport à l’explication fournie dans la présentation, mon avis est différent : pour moi, c’est le fait pour un contenu de pouvoir être caché (type Static et Re-Usable) qui améliore énormément le TTFB (moins de distance physique, sans parler de tous les hops au niveau réseau) et non la gestion du Keep-Alive TCP post CloudFront car le calcul du TTFB commence après l’établissement de la connexion TCP (optimisée), à l’envoi de la requête HTTP. Eventuellement le fait de décharger l’origine de la mise à disposition du contenu cachable peut permettre au serveur de concentrer ses ressources sur la génération du contenu dynamique (et donc d’améliorer la partie génération de la réponse du TTFB).

Improve Content Download Time

  • L’impact du TCP Slow Start (cf. image ci-contre) est minimisé du fait des connexions persistantes entre CloudFront et l’origine.
  • A noter dans ce point l’intérêt du Latency Based Routing (attention : dans ce cas le déploiement de votre site doit être multi-régions, car c’est la latence des services AWS au niveau de la région qui est testée et non celle de votre service), ou autres DNS offrant des capacités similaires, notamment pour les requêtes de contenu dynamique qui reviennent à chaque fois à l’origine.

Intérêts de Route 53

2 intérêts, orientés intégration avec les autres services AWS, que je vois d’utiliser Route 53 plutôt qu’un autre DNS (mais il y en a sûrement d’autres ;ob) :

  • Dans le cadre de la disponibilité plus que de la performance, l’intégration de health checks au niveau de Route 53 sur les points d’entrée (origines) de votre service qui sont couplés avec CloudFront. Le health check n’est pas soumis à une obligation de multi-régions puisque c’est le point d’entrée de votre service qui est testé et non les services (localisés) AWS qui le sous-tendent.
  • Les records ALIAS to A et ALIAS to AAAA qui peuvent remplacer les records A et AAAA et permettant de pointer sur l’alias d’un ELB en entrée de votre service puisqu’il ne faut évidemment pas pointer sur son IP qui change régulièrement.

Optimisation des requêtes PUT/POST :

  • Les données ne sont pas cachées et CloudFront relaie les données uploadées vers l’origine.
  • Les mêmes optimisations que celles pour le contenu dynamique s’appliquent (TCP Handshake & Slow Start entre CloudFront et origine via Keep-Alive et terminaison SSL proche du end-user).

Notes personnelles :

  • Il est important de vérifier, avant d’opter pour un CDN, les fonctions de demande d’éviction d’objets en cache avant la fin du TTL : c’est possible dans CloudFront, cependant il n’y a pas de prise en compte de Regex. Donc il faudra lister tous les objets explicitement : je crois que donner un « répertoire » (un ensemble d’objets avec le même préfixe) dans S3 est possible, mais pas de wildcard.
  • Penser également à versionner vos objets pour les montées de version lors des déploiements pour pouvoir faire cohabiter 2 versions et rollbacker le déploiement en cas de souci.
  • Concernant les prix, Amazon affirme que utiliser CloudFront n’induit pas de surcoût par rapport à la solution d’accéder tout le temps à l’origine. Au vu du système de facturation, cela peut être effectivement le cas, mais il vaut mieux toujours faire le calcul en fonction de votre use-case personnel et si c’est plus cher, voir si le surcoût est acceptable vis-à-vis du gain en expérience utilisateur (comprendre meilleur taux de transformation, …).

Frédéric FAURE @Twitter @Ysance

2 commentaires pour AWS re:Invent 2013 (2.2/2) : Use Cases – Accélérer la délivrance de son contenu via CloudFront et Route 53

Répondre

 

 

 

Vous pouvez utiliser ces balises HTML

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>