Cet article inaugure une nouvelle série consacrée à des exemples concrets de problèmes rencontrés par les entreprises et explique comment l’App Delivery Network (ADN) de Volterra permet d’y remédier. Cet article aborde plus particulièrement un défi majeur lié aux performances des applications web, auquel les entreprises en ligne du monde entier sont confrontées chaque jour. Ce défi est d’autant plus important que la plupart des consommateurs travaillent depuis leur domicile. J’explique comment Volterra peut aider les entreprises à « abolir la distance » pour leurs applications web afin d’améliorer leurs performances de 77 %, sans avoir à les réécrire.
Qu’est-ce que la performance d’une application web ?
Les performances d’une application web sont généralement mesurées en fonction du temps nécessaire pour que le contenu de la page soit visible, tel que le perçoit l’utilisateur final. Les développeurs web utilisent plusieurs indicateurs pour mesurer les performances de leurs applications web, tels que First Contentful Paint, Largest Contentful Paint ou Document Complete. Dans cet article, j’ai utilisé l’indicateur « Document Complete » pour mesurer les performances de mon application web. Les développeurs web mesurent ces indicateurs à l’aide d’outils tels que Web Page Test, Google Lighthouse ou Rigor.
Pourquoi les performances des applications web sont-elles importantes ?
Une légère dégradation des performances d’une application web a un impact considérable sur l’expérience utilisateur et, par conséquent, sur les ventes réalisées via le portail en ligne. Le géant du commerce électronique Amazon a indiqué qu’une baisse des performances de l’application pendant une seconde entraînait une perte de chiffre d’affaires de 1,6 milliard de dollars. Des entreprises en ligne de nombreux secteurs constatent un impact économique similaire, comme l’indique Akamai dans ce rapport un peu ancien. Google et Microsoft font état de répercussions économiques comparables.
Ces données confirment clairement que les performances des applications web sont une priorité majeure pour les entreprises en ligne.
Quel est le défi ?
Prenons l’exemple concret d’une entreprise en ligne du secteur du e-commerce. De nombreuses entreprises de e-commerce hébergent leur application web dans un ou quelques centres de données, qui ne sont pas présents dans tous les pays où vivent leurs utilisateurs. Lorsque l’utilisateur se trouve dans un pays ou une région différent de celui du centre de données, la forte latence du réseau entre l’utilisateur et le centre de données entraîne des temps de chargement des pages pouvant atteindre 6 à 12 secondes. Comme indiqué précédemment, lorsque le temps de chargement dépasse 5 secondes, la probabilité de rebond atteint 90 %.
Décomposons le chargement d’une page d’application web, comme illustré à la figure 2
- Tout d’abord, une session SSL sécurisée est établie, ce qui nécessite six échanges de messages entre le navigateur de l’utilisateur et l’application web.
- Ensuite, l’application web utilise généralement les cookies du navigateur de l’utilisateur pour déterminer si celui-ci possède un compte auprès du site marchand.
- En fonction du cookie, si l’utilisateur possède un compte, une page de connexion s’affiche ; sinon, une page permettant de passer commande en tant qu’invité lui est proposée.
Le simple échange de six messages nécessaires à l’établissement d’une session SSL sécurisée sur des liaisons à forte latence (potentiellement transatlantiques ou transpacifiques) a assurément une incidence sur le temps de chargement des pages et dégrade par conséquent l’expérience utilisateur.
Comment Volterra ADN peut-il améliorer les performances des applications ?
Il existe de nombreuses techniques permettant d’améliorer les performances d’une application web en l’optimisant, par exemple en compressant les images ou en optimisant les dépendances afin de réduire le temps de chargement des pages. Souvent, ces optimisations ne sont pas possibles en raison des impératifs métier qui déterminent la conception de l’application. Même lorsqu’elles sont possibles, elles ne constituent pas toujours une solution viable, car les développeurs qui ont créé l’application ont quitté l’entreprise ou sont occupés à développer de nouveaux services. C’est pourquoi les équipes DevOps des entreprises de commerce électronique privilégient les solutions capables d’améliorer les performances des applications sans nécessiter de modifications de celles-ci.
Volterra propose deux produits, VoltMesh et VoltStack, qui, associés à l’ADN de Volterra, peuvent améliorer les performances des applications jusqu’à 75 % (voir la démonstration dans la section suivante). VoltMesh de Volterra est un produit de mise en réseau et de sécurité distribué à l’échelle mondiale qui, lorsqu’il est configuré sur l’ADN de Volterra, offre également des fonctionnalités d’accélération des applications. VoltStack de Volterra assure le déploiement distribué des applications et la gestion de leur cycle de vie, ce qui permet aux utilisateurs de déporter certaines parties de leurs applications vers l’ADN de Volterra afin d’en améliorer davantage les performances.
VoltMesh et VoltStack améliorent les performances des applications web des entreprises de commerce électronique de trois manières :
Solution 1 : terminaison SSL (également appelée déchargement TLS) sur Volterra ADN
La solution la plus simple pour améliorer les performances des applications web consiste à effectuer la terminaison des sessions SSL sur l’ADN mondial de Volterra. Les six messages nécessaires à l’établissement de la session SSL sont envoyés localement au point de présence national du réseau mondial et ne transitent pas par des liaisons transatlantiques ou transpacifiques. Une session SSL persistante est maintenue entre le site distant du réseau mondial de Volterra et le serveur d’origine, ce qui améliore encore les performances. Ce fonctionnement est illustré à la figure 3.
Solution 2 : déplacer les traitements sensibles à la latence, tels que le traitement des cookies, vers Volterra ADN
Pour améliorer encore les performances, les entreprises peuvent déployer sur l’ADN les parties de leurs applications sensibles à la latence. Parmi les exemples de composants d’une application web sensibles à la latence figurent le traitement des cookies, GraphQL ou encore le backend-for-frontend. Dans le cas d’une entreprise de commerce électronique, les cookies sont généralement traités afin de déterminer quelle page afficher à l’utilisateur : par exemple, si celui-ci possède un compte, la page de connexion est affichée ; sinon, une page destinée aux visiteurs s’affiche. Le traitement des cookies sur notre ADN améliore considérablement les performances par rapport à un traitement dans des centres de données centralisés ou dans un cloud situé à l’autre bout du monde. Ce fonctionnement est illustré à la figure 4.
Solution 3 : déplacer le front-end de l’application web (par exemple, le catalogue de produits) directement en périphérie, c’est-à-dire dans le magasin physique
De nombreux commerçants, tels que Macy’s, Home Depot et Target, disposent également de magasins physiques dans lesquels les consommateurs consultent le catalogue de produits en ligne afin de localiser les articles et d’accéder à des offres ou à des coupons. Pour améliorer l’expérience utilisateur, ils pourraient choisir de déplacer uniquement le front-end de leur application web vers une infrastructure de calcul située en magasin. Tous les autres composants de leur application, notamment les bases de données, pourraient rester dans le centre de données back-end, car ils sont moins fréquemment sollicités que le catalogue de produits front-end. Cette configuration est illustrée à la Figure 5.
Principes architecturaux clés à prendre en compte dans toute solution
Ce problème relève fondamentalement de l’informatique distribuée sur plusieurs clouds hétérogènes. Les équipes DevOps peuvent opter pour une approche maison en assemblant des solutions disparates proposées par différents fournisseurs, tels que des fournisseurs de cloud public, de CDN ou de services en périphérie, ou acheter une solution clé en main auprès de fournisseurs de plateformes de services de cloud distribué. Les défis sont présentés dans la figure 6.
Voici les grands principes architecturaux que les équipes DevOps doivent prendre en compte lors de l’évaluation d’une solution.
- Environnement d’exécution applicatif cohérent sur plusieurs clouds : L’application des équipes DevOps sera répartie entre leur cloud backend, qui peut être un centre de données privé ou un cloud public, leurs sites en périphérie et leurs magasins physiques, chacun pouvant disposer d’un environnement d’exécution applicatif totalement différent. Les équipes DevOps devraient privilégier les solutions qui s’appuient sur Kubernetes afin de fournir un environnement d’exécution applicatif cohérent dans l’ensemble de ces clouds distribués. Kubernetes uniformise les clouds et facilite le déplacement de composants des applications d’un cloud à l’autre.
- Routage du trafic en fonction de la proximité géographique : Comme le front-end de l’application peut être déployé à différents emplacements — dans le cloud, en périphérie ou en périphérie d’un magasin physique —, toute solution doit garantir que le trafic de l’utilisateur est redirigé vers l’emplacement le plus proche où le service front-end est déployé. En outre, aucune solution envisagée ne doit obliger les équipes DevOps à modifier les politiques de routage Internet.
- Répartition de charge mondiale : Toute solution envisagée doit proposer une répartition de charge mondiale, car les services back-end peuvent être répartis sur plusieurs sites à travers le monde.
- Politiques uniformes de sécurité des applications et du réseau dans plusieurs clouds : Bien que l’emplacement des composants de l’application puisse varier selon la région, toute solution envisagée doit permettre d’appliquer une politique uniforme de sécurité des applications et du réseau, quel que soit le cloud sur lequel le service frontal est déployé.
- Observabilité centralisée sur plusieurs clouds, couvrant les applications et la connectivité réseau : Dans un environnement cloud distribué, il est extrêmement difficile de diagnostiquer les problèmes liés aux applications et à la connectivité sur plusieurs clouds. Toute solution envisagée doit offrir une vue centralisée de la connectivité, de la sécurité et des déploiements d’applications sur plusieurs clouds.
Résultats obtenus grâce aux solutions de Volterra
Configuration du test
La configuration de test décrite ci-après a été utilisée pour démontrer les gains de performances offerts par chacune des solutions Volterra présentées dans la section précédente :
- L’application web utilisée était Online Boutique, une application de démonstration de microservices cloud natifs développée par Google. L’application web se compose de 11 microservices, comme illustré à la figure 7
- Les performances de l’application web ont été mesurées à l’aide de webpagetest.org
- La métrique utilisée pour évaluer les performances de l’application web dans webpagetest.org était « Document Complete »
- L’entreprise est une société européenne de commerce électronique dont les centres de données sont situés à Paris
- L’utilisateur (ou le client) se trouve toujours à San Francisco.
Scénario de test et résultats
Les quatre scénarios suivants ont été testés, et les améliorations de performances sont décrites pour chacun d’eux.
Scénario de référence : tout d’abord, j’établis les performances de référence de l’application web avec l’utilisateur situé à San Francisco et l’application web s’exécutant entièrement dans le centre de données de Paris, comme illustré à la figure 8. Dans ce scénario, les performances de l’application web ont été mesurées à 3,5 secondes.
Scénario de test de la solution 1 : Lors du test de la solution 1, l’utilisateur se trouve toujours à San Francisco et l’application web s’exécute toujours dans le centre de données de Paris. Toutefois, la session SSL est terminée sur le proxy inverse VoltMesh exécuté sur Volterra ADN à San José. Ce scénario est illustré à la figure 9.
VoltMesh crée automatiquement une session SSL persistante entre le proxy inverse exécuté dans le PoP de San José et l’application web exécutée dans le centre de données de Paris. Le temps de réponse de l’application web est passé à 2,9 secondes, soit une amélioration d’environ 18 %.
Scénario de test de la solution 2 : Lors du test de la solution 2, le front-end et le microservice de gestion des devises sont déployés sur l’ADN à San José. Les autres microservices et bases de données continuent de s’exécuter dans le centre de données de Paris. Ce scénario est illustré à la figure 10.
La raison pour laquelle seuls les microservices front-end et de gestion des devises ont été déplacés est que ce sont les seuls sollicités lorsque les utilisateurs naviguent de manière occasionnelle. Le temps de réponse de l’application web passe à 2 secondes, soit une amélioration de 31 % par rapport aux résultats de la solution 1.
Scénario de test de la solution 3 : Lors du test de la solution 3, le front-end et le microservice de gestion des devises ont été déployés sur un Intel NUC standard (4 cœurs virtuels), en périphérie d’un magasin physique.
La raison pour laquelle seuls les microservices front-end et de gestion des devises sont déplacés est que ce sont les seuls sollicités lorsque les utilisateurs naviguent de manière informelle à la périphérie du magasin physique. Le temps de réponse de l’application web passe à 0,8 seconde, soit une amélioration de 60 % par rapport aux résultats de la solution 2.
Synthèse des résultats et valeur économique
Un résumé des résultats des tests et de la valeur économique qui en découle est présenté à la figure 12. La valeur économique peut être déterminée en extrapolant les gains de temps, exprimés en secondes, en fonction de la valeur que représente chaque seconde gagnée pour l’organisation. Par exemple, Amazon estime que chaque gain d’une seconde génère une valeur économique de 1,6 milliard de dollars ; la solution 3 apporte donc une valeur économique de 4,3 milliards de dollars par rapport à la référence.
Comme le montrent ces résultats, les équipes DevOps peuvent améliorer considérablement les performances sans réécrire l’application, en utilisant les trois options proposées dans cet article de blog, tout en maintenant le même niveau de protection de leur application. Pour en savoir plus sur des cas d’usage clients concrets auxquels une plateforme cloud distribuée peut répondre, ou pour me faire part de cas d’usage clients concrets, n’hésitez pas à me contacter via LinkedIn ou Twitter.
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.