Le Blog Amazon Web Services

Marianne – Une infrastructure serverless pour mieux servir les lecteurs

Cet article est écrit par Jérôme Petit, CTO digital chez CMI France, en collaboration avec Achraf Souk, Principal Solutions Architect, spécialiste des services Edge d’AWS.

Introduction

Lancé en 1997, Marianne est le plus jeune des magazines d’information. En quelques chiffres, Marianne c’est 998.000 lecteurs, 10 millions de visiteurs uniques par mois, et 709.000 abonnés aux réseaux sociaux.

Le magazine rencontrait beaucoup de freins technologiques liés à son ancienne plateforme, limitant ainsi sa possibilité d’accélérer son développement digital. L’infrastructure de publication de Marianne était vieillissante avec des problématiques de performance, de scalabilité, de maintenabilité, de sécurité et de coûts. Le souhait des équipes de Marianne était de disposer d’une plateforme innovante, évolutive, agile et performante pour offrir la meilleure expérience possible à ses lecteurs. Marianne est un site d’informations, il doit pouvoir absorber d’importantes fluctuations de trafic qui dépendent de l’actualité, tout en prenant en compte les contraintes budgétaires du magazine.

Les équipes de Marianne ont décidé de relever ce défi en migrant l’ensemble des applications sur AWS. Cet article explique l’architecture du site web de Marianne, et tout particulièrement celle de la plateforme d’hébergement et de diffusion qui sert le site web aux lecteurs.

Architecture globale

Pour répondre à ces challenges, les équipes de Marianne ont conçu une solution basée sur une architecture en microservices et serverless. Chaque microservice est responsable d’une logique spécifique de la solution. Ils communiquent avec les autres microservices à travers Amazon API Gateway, ou bien d’une façon découplée à travers des services comme Amazon SNS ou Amazon SQS. L’approche serverless supprime la nécessité de gérer des serveurs Linux ou Windows, et donc simplifie la maintenance et les opérations. L’approche microservice quant à elle facilite l’évolutivité de la solution grâce à la séparation des responsabilités d’une part et, d’autre part, améliore la disponibilité du système grâce au découplage des microservices.

Dans le diagramme d’architecture ci-dessous, les composantes en vert représentent les différents microservices responsables du processus de publication initié par les rédacteurs chez Marianne. La plateforme d’hébergement et de diffusion est constituée par les deux composants en gris.

architecture marianne

Quand un rédacteur chez Marianne crée un nouvel article dans le Content Management System (CMS), plusieurs microservices sont déclenchés pour traiter le nouvel article, l’intégrer au site web, et le rendre disponible aux lecteurs.

D’abord, le nouvel article est reçu par un microservice d’intégration avec le CMS à travers une requête d’API. Ensuite, le contenu est analysé et validé (respect de l’unicité de certaines données, le caractère obligatoire de certains champs), puis transformé en un format standard après extraction de certaines méta-données, comme les différents crop des images, ou la connection avec les pages d’auteurs. A partir de cette étape, plusieurs microservices sont orchestrés en fonction des actions effectuées sur un article par le rédacteur (par exemple : publier, dépublier ou prévisualiser). Dans le cas spécifique de la publication d’un nouvel article, un microservice responsable de la gestion du cycle de vie des articles est appelé pour mettre à jour les pages web associées comme celle de l’auteur, la page web principale, ou la page de rubrique. Enfin, pour chacune des pages modifiées, un microservice génère le code HTML correspondant, et le dépose sur un bucket Amazon S3 de la plateforme d’hébergement et de diffusion. Cette plateforme dispose d’un microservice pour la transformation d’image à la volée, par exemple pour changer la taille d’une image.

Plateforme d’hébérgement et de diffusion

La plateforme d’hébergement et de diffusion sert les pages web aux lecteurs de Marianne d’une façon performante, scalable et sécurisée à l’aide d’Amazon CloudFront depuis un bucket Amazon S3. Amazon CloudFront est le service Content Delivery Network (CDN) d’AWS, qui permet de mettre en cache le contenu de Marianne au plus près des lecteurs, pour réduire le temps de chargement des pages. Le système utilise Lambda@Edge pour implémenter des fonctionnalités plus avancées, comme la génération dynamique de certaines pages et la redirection de pages inexistantes. Lambda@Edge est une extension de CloudFront qui permet de personnaliser le contenu via l’éxecution de code écrit en JavaScript ou Python. Cette personnalisation se fait au plus près du lecteur pour optimiser les performances.

Marianne - plateforme de diffusion

Cette plateforme comprend les principaux composants suivantes :

  • un bucket Amazon S3 pour stocker les pages et leur contenu,
  • plusieurs distributions CloudFront pour cacher ce contenu au plus proche des lecteurs
  • plusieurs fonctions Lambda@Edge pour gérer la génération des pages, la sécurité, les redirections d’URL etc …

Génération dynamique des pages

Dans chacune des pages de Marianne, il y a des blocs de contenus qui sont mis à jour à des fréquences différentes. Ainsi, le menu du site change rarement, comparé au bloc affichant les derniers articles. Si ces différents blocs sont stockés dans un même fichier dans S3, il faudrait garder un temps de mise en cache (TTL) minimal pour pouvoir publier les nouveaux articles rapidement. Cette configuration ne serait pas optimale en termes de performance, parce que les blocs qui changent peu ne profitent pas d’un long TTL dans le cache de CloudFront. La solution est de composer dynamiquement la page, à partir de différents blocs stockés séparément sur S3, et servis avec différents TTL de cache. Cette composition dynamique peut se faire dans plusieurs endroits. Marianne a décidé de le faire au niveau de CloudFront avec Lambda@Edge en utilisant la technique des Edge Side Includes (ESI).

Avec la technique ESI, une page nécessitant une composition dynamique fait référence aux blocs qui doivent être ajoutés par une balise HTML <esi:include src= "URL DU BLOC" />. L’attribut src donne l’information permettant de savoir où il faudrait aller pour récupérer le bloc et l’intégrer à la page. Par exemple, voyez la page ci-dessous :

Marianne - ESI

 

Dont le code source ressemble à :

<div class="layout-grid_aside layout-grid_aside-top">
    <div class="layout-grid_aside-item layout-grid_aside-item--banner">
        <div id="banner-aside-1" class="layout-grid_aside-sticky"></div>
    </div>
    <div class="layout-grid_aside-item">
        <esi:include src="esi/block-most-read"/>
    </div>
</div>
 
<div class="layout-grid_full">
    <esi:include src="esi/block-marianne-tv"/>
</div>
 
<div class="layout-grid_main">
    <ul id="headline-l1-l3" class="layout-grid_list layout-grid_list--borderless">
        <li class="layout-grid_item layout-grid_item--list">
            <article class="thumbnail thumbnail--wide">
            ...
</div>

Une fonction Lambda@Edge est configurée sur un événement « Origin Request » de la distribution CloudFront, pour pouvoir mettre en cache la page générée dynamiquement.

Quand la fonction est déclenchée pour une page, elle va d’abord télécharger la page du bucket S3.

Ensuite, la page est analysée pour retrouver toutes les balises ESI, en récupérer l’attribut src et télécharger en parallèle les blocs correspondants. Finalement, les balises ESI dans la page demandée sont remplacées par les blocs téléchargés, pour ainsi générer la page finale qui est servie au lecteur de Marianne.

Avant d’envoyer la page générée, la fonction Lambda@Edge ajoute des entêtes améliorant la sécurité de la page et un TTL de cache qui correspond à la valeur la plus faible entre celle de la page d’origine et ceux des ESI.

Pour améliorer la performance et la disponibilité des pages web Marianne, les optimisations suivantes ont été implémentées :

  • Dans la configuration de CloudFront, des « caches behaviors » sont créés au plus spécifiques pour exécuter la fonction Lambda@Edge seulement pour les pages qui contiennent des balises ESI,
  • Le code de la fonction Lambda@Edge maintient des connections TCP/TLS persistantes vers la distribution CloudFront qui sert le contenu pour améliorer les performances, comme expliqué dans cet article,
  • La fonctionnalité « Origin Failover » de CloudFront est utilisée, pour servir une version sans ESI des pages de Marianne depuis un autre Bucket S3, si la génération dynamique échoue dans Lambda@Edge.

Redirections

Pour maximiser l’indexation par les moteurs de recherches (Search Engine Optimization – SEO), les URLs de l’ancien site de Marianne sont redirigées dynamiquement vers le nouveau site. Pour ce faire, des « cache behavior » spécifiques sont créés dans la configuration de CloudFront. Ils correspondent aux contenus qui nécessitent une redirection comme les pages auteurs et tags. Sur ces « caches behaviours », deux fonctions Lambda@Edge sont utilisées pour générer automatiquement une redirection vers le contenu :

  • Une fonction sur l’événement « Origin Request », pour rediriger certains schémas d’URL connus à l’avance,
  • Une fonction sur l’événement « Origin Response », pour rediriger le lecteur dans le cas où le contenu n’est pas trouvé sur S3.

Dans les deux cas, cette réponse de redirection est mise en cache dans CloudFront.

Résultats

L’ensemble des applications (site web, mobile) déployées sur AWS offrent une plus grande visibilité à la marque Marianne sur le digital. En quelques chiffres, le temps de crawl moyen du site est passé de 700 ms à 270 ms, le trafic a augmenté de 41% et les coûts ont été réduits de 40%.

Grâce à AWS, le magazine Marianne bénéficie d’une plateforme digitale innovante, sans contrainte, et avec les dernières technologies. Plusieurs optimisations de l’architecture seront considérées par Marianne dans le futur, comme, par exemple, un projet d’optimisation de la gestion des images pour améliorer le SEO, ou une gestion du cycle de vie plus avancée des fichiers sur S3 pour réduire les coûts de stockage.