Quelles architectures AWS pour améliorer l’expérience client digitale ?

AWS Serverless

Qu’est-ce qui fait expérience digitale réussie ? Un parcours client fluide, un achat facilité par des informations précises et à jour… tout cela est le fruit d’une organisation DevOps et d’une infrastructure IT permettant de livrer régulièrement très régulièrement de nouvelles fonctionnalités. À travers le retour d’expérience du projet que nous vous présentons ici, nous souhaitons vous faire découvrir l’envers du décor : comment le Cloud AWS aide-t-il à répondre aux exigences des nouveaux projets digitaux, et comment l’organisation des équipes évolue-t-elle pour soutenir ces choix ?

Améliorer le time to market demande d’être agile : les DSI veulent aujourd’hui délivrer très rapidement une première version, sur laquelle itérer très régulièrement afin d’adapter le service en fonction des retours des utilisateurs. Pour les équipes Dev et Ops, cela pose deux challenges majeurs. Cela demande non seulement de pouvoir faire une première mise en production très rapidement, et ensuite déployer très régulièrement en production. Dans le cas qui nous intéresse, l’objectif était de faire une mise en production par jour. Pour répondre à cet impératif, nous avons fait trois choix très structurants :

  • Choisir le Cloud AWS pour bénéficier de la scalabilité et de l’automatisation de la plateforme
  • Utiliser une architecture blue/green pour mettre en production sans interrompre le service
  • Mettre en place une organisation DevOps

Les services managés AWS

L’architecture proposée pour adresser ces challenges fait appel aux services AWS suivants :

  • Amazon VPC, afin d’isoler l’application dans un réseau dédié et de gérer les fluxs de façon sécurisée grâce aux NACLs et Security Groups.
  • Direct Connect assurant une connexion réseau dédiée entre le réseau interne de l’entreprise et le VPC.
  • Cloudfront comme Content Delivery Network afin d’optimiser la performance du site web et donc d’améliorer l’expérience utilisateur.
  • EC2: L’application est distribuée en micro-services. Les serveurs Web de chaque micro-service tournent sur des instances EC2, au sein d’un auto-scaling groupe ayant un minimum de 2 instances (pour assurer la haute disponibilité) et un maximum de 4 instances (pour être capable d’absorber la charge).
  • Bases de données RDS, utilisées comme backend des micro-services.
  • Base de donnée Dynamo DB, utilisée pour le stockage du token temporaire de l’API manager.
  • AWS Lambda utilisé en majorité pour l’intégration continue avec Travis. En effet, Travis est un outil Saas qui ne peut accéder aux machines du VPC car celles-ci ne sont accessibles que depuis le réseau privé de l’entreprise. Toutefois, Travis peut, par appel API, invoquer une fonction lambda, qui s’exécutera dans le VPC, puis qui enverra les commandes souhaitées sur les machines via ssh (par exemple, pour faire la migration des bases de données à chaque déploiement d’une nouvelle version du code).
  • Cloudwatch pour gérer les alertes ainsi que le monitoring des ressources et de certains indicateurs applicatifs comme les nombres d’erreurs 404 et 500.
  • S3, utilisé pour stocker le catalogue produit, toutes sortes de logs ainsi que des fichiers de configuration.
  • IAM pour la gestion des droits des utilisateurs et des rôles des instances EC2.
  • Route 53 pour la gestion des noms de domaine de chaque micro-service, également indispensable à la mise en place du blue-green déploiement.

Architecture Blue/Green

Comment être en mesure de déployer de nouvelles fonctionnalités en production très fréquemment, et sans dégradation du service afin de conserver une expérience utilisateur optimale ? Le blue-green déploiement, qui permet des déploiements sans downtime et des roll-backs quasi-immédiats, apparaît comme la meilleure solution pour répondre à ce besoin.

Le principe du blue-green déploiement est simple. Au lieu de construire une seule stack de serveurs applicatifs en production, deux stacks coexistent, arbitrairement nommées blue et green. Un jeu de bascule DNS permet de faire pointer l’alias DNS, endpoint pour joindre l’application, vers une des deux stacks. Dans notre cas, l’utilisation de Route53 nous a permis de gérer très simplement et automatiquement les bascules.

Si, par exemple, l’alias pointe sur la stack blue, il sera possible de détruire, puis reconstruire les instances de la stack green à partir d’une image portant la nouvelle release, sans engendrer de downtime puisque les serveurs de la stack blue continueront à traiter les requêtes de l’application normalement. Une fois les instances green déployées et opérationnelles, la bascule de l’alias dns vers la stack green opérera la mise en production de façon transparente pour les utilisateurs. En cas de problème, la bascule inverse (vers la stack blue) permettra un retour-arrière simple et rapide. Ainsi il est possible de mettre en production de nouvelles fonctionnalités très rapidement, sans le stress d’une mise en production ratée. Pour les équipes, cela permet de dédramatiser les mises en production tout en contribuant à améliorer le time to market.

Mise en place d’une organisation DevOps

Afin d’aligner les fonctionnalités du site web avec les besoins utilisateurs, les équipes IT doivent déployer des releases très fréquemment. Le modèle d’organisation traditionnel de l’IT, en silo, étant un frein à ce dynamisme, une nouvelle équipe de dev et ops a été constituée pour mieux intégrer les changements organisationnels et techniques qu’impliquent le devops.

En termes d’organisation, l’équipe de développement utilise la méthodologie agile Scrum. Celle-ci permet de redéfinir chaque semaine les objectifs pour coller au mieux aux besoins des utilisateurs, qui peuvent rapidement évoluer. Pour privilégier la communication, Devs et Ops travaillent en étroite collaboration, dans le même Open Space.

Côté technique, la plateforme Web a été hébergée sur le Cloud AWS afin de bénéficier au maximum de la scalabilité et de l’automatisation. L’intégration et la livraison continues ont été mises en place grâce à des outils comme : Git, Travis, AWS SDK (boto3), Docker, Packer et Terraform (pour plus d’informations, lire l’article « 5 conseils pour réussir votre transformation Devops« ).

Commentaires :

A lire également sur le sujet :