Mis à jours 7 mai 2019 Dans cet exemple, vous allez voir comment utiliser les services Azure pour créer des applications Web évolutives sans serveur.
L’autre jour, je me suis retrouvé à regarder un ticker sur un site de pétition qui écrit lentement à un million de signatures. Il était clair que le site était en difficulté, les emails d’authentification ne prenant que 24 heures à être envoyées, les files d’attente étaient remplies de signatures non approuvées en attente d’être écrites dans une base de données.
En regardant le compteur, j’ai commencé à me demander comment créer un service comme celui-ci en utilisant certaines des options de conception de cloud les plus modernes offertes par Azure, en rassemblant de nombreux outils et services que j’ai décrits dans cette rubrique.
L’architecture d’un tel service est relativement simple. Vous avez besoin d’un serveur Web pour collecter les signatures, d’une infrastructure de messagerie pour les livrer à un serveur principal évolutif, d’utiliser les microservices pour les écrire dans une base de données et pour vérifier l’identité de l’expéditeur. Vous pouvez ensuite utiliser d’autres outils de messagerie pour garder une trace des signatures. Vous pouvez aussi utiliser des outils d’analyse et d’apprentissage automatique pour identifier les entrées invalides.
Concevoir un Web tier
Un élément clé d’un service comme celui-ci est le contenu Web. Il est important de choisir le bon framework de développement Web. Si vous envisagez d’utiliser les microservices Azure pour gérer les événements générés par page, une application Web à page unique (SPA) est le framework idéal pour ce faire. Les outils de gestion de contenu Web évolutif d’Azure constituent une plate-forme pour la diffusion de contenu.
Elle utilise son réseau de diffusion de contenu pour mettre à niveau le contenu statique et les modèles de page. La passerelle d’applications intégrée d’Azure Front Door permet de gérer les serveurs d’applications Web qui répartissent les charges et de fournir un pare-feu aux applications Web.
J’utiliserais React en tant que framework Web, car il fonctionne bien dans les SPA et sa réactivité en fait un outil idéal pour une application devant fonctionner sur plusieurs périphériques. Il facilite la connexion des éléments de formulaire à JavaScript, vous permettant de créer une charge utile CloudEvents et de l’envoyer à votre back-office de microservices.
Construire un tel service autour d’une architecture d’événement basée sur la messagerie a beaucoup de sens. Vous devez être capable d’évoluer et de travailler dans un environnement en évolution rapide. La messagerie, en particulier lorsqu’elle est liée à un courtier de messages, peut gérer des infrastructures en constante évolution et des formats de messages basés sur des normes, tels que celui de CloudEvents , et vous fournit un framework pour la création et la construction d’en-têtes de messages et de données utiles.
Traiter les données avec des microservices sans serveur
Toute personne qui construit un site comme celui-ci se pose une question intéressante : comment le mettre à l’échelle ? La solution évidente consiste à tirer parti des technologies informatiques sans serveur et à fournir un service minimal mais hautement évolutif. Au lieu de lancer de nouvelles machines virtuelles à mesure que la charge augmente et de modifier dynamiquement les règles d’équilibrage de charge, vous pouvez activer les instances Azure Functions selon vos besoins, à l’aide d’outils tels que Event Grid pour diriger les messages de votre application Web vers des microservices de traitement de messages.
Concevoir les microservices qui créent une application comme celle-ci est relativement facile. Vous écrivez des données dans une file d’attente et vous les conservez jusqu’à ce que vous ayez vérifié l’utilisateur via une boucle de vérification d’adresse e-mail. Ce processus peut être exécuté en utilisant deux microservices.
Le premier microservice prend un message depuis l’application Web et en écrit le contenu dans une base de données avec un indicateur qui indique une signature provisoire. Le deuxième microservice affiche ensuite un message indiquant que la vérification est requise, en fournissant une adresse e-mail et un jeton de signature à un service de messagerie électronique, qui les insère dans un modèle avant de l’envoyer au signataire.
Utiliser des services de données intelligents
La décision la plus difficile pour quiconque de créer une application cloud moderne consiste peut-être à choisir un back-end de données. Ce n’est pas qu’il n’y ait aucun service qui fonctionnerait, au contraire, il y en a trop ! Si vous stockez des données dans des tables relationnelles traditionnelles, devez-vous les stocker dans un service NoSQL ou tirer parti des fonctionnalités des bases de données graphiques ?
Pour un site de pétition où vous souhaitez exécuter une série de requêtes sur les résultats afin de déterminer les signatures frauduleuses, vous disposez d’un ensemble spécifique d’exigences que vous pouvez utiliser pour déterminer les entrées problématiques. Vous allez stocker un nom, un jeton d’adresse tel que des codes ZIP ou postaux, un horodatage et une adresse d’origine, ainsi qu’un identifiant de pétition.
Cela devrait vous permettre de vérifier d’abord les adresses dupliquées dans le cadre du processus de signature, ainsi que de rechercher les variantes évidentes d’une adresse (par exemple, rechercher le séparateur dans une adresse Gmail, qui n’est pas analysé par Gmail, mais par la plupart des autres moteurs de transfert de courrier électronique).
Les horodatages et les adresses IP peuvent aider à détecter les fraudes, dans le cadre d’un processus de nettoyage par lots exécuté en dehors de l’application de requête. Il est possible de détecter le bourrage de vote évident à partir d’une seule adresse IP, ainsi que les signatures provenant de points de terminaison VPN connus.
Avec de telles requêtes, il est possible d’utiliser quelque chose comme la Cosmos DB d’Azure en tant que plate-forme de données, de l’utiliser pour stocker des données en tant que nœuds de graphes et d’utiliser des requêtes de graphes pour extraire des données. En utilisant un modèle de stockage distribué, vous pouvez créer un back end résilient, à l’aide d’un modèle de cohérence relativement souple pour gérer la réplication entre instances.
En utilisant, par exemple, des modèles de cohérence limités ou basés sur la session, vous pouvez laisser votre application web signée déposer des données dans Cosmos DB, puis créer une page demandant à un utilisateur d’attendre la confirmation de l’adresse e-mail.
Les confirmations et l’apprentissage automatique (machine learning) pour détecter les fraudes
Ceux-ci vous permettent d’attendre la cohérence des différentes instances avant de procéder à des contrôles de fraude élémentaires, puis de déclencher un email approprié. En utilisant une application sans serveur déclenchée par des fonctions JavaScript exécutées dans Cosmos DB, vous pouvez envoyer des emails avec échec, réessayer ou authentifier. Bien qu’Azure dispose des outils nécessaires pour envoyer des messages SMTP, il est préférable d’utiliser un service tiers comme SendGrid, qui a la capacité d’envoyer plusieurs millions de messages en peu de temps (et qui présente l’avantage d’être mis en liste blanche par la plupart des services antispam).
Le message de confirmation envoyé à l’utilisateur contient un jeton signé par cryptographie. Une fois retourné dans un microservice de vérification et vérifié, vous pouvez alors basculer le statut signé de l’entrée de base de données. Un autre service JavaScript interne compte les entrées valides et vous pouvez utiliser SignalR pour fournir un nombre quasi-réel de signataires à une API pouvant être affichés par une page Web ou utilisés par des tiers qui souhaitent suivre la pétition.
En réunissant tous ces éléments, vous obtenez un service de pétition évolutif et capable de gérer les techniques antifraude de base. Vous pouvez rapidement ajouter des outils anti-fraude plus complexes au processus, en utilisant les outils d’apprentissage automatique Azure pour rechercher des modèles de signature inhabituels. Ceux-ci pouvant s’exécuter en dehors du processus de signature. Vous ne les utiliserez que si vous aurez suffisamment de signatures pour qu’ils soient rentables.
Jusqu’à présent, j’ai utilisé les principes modernes de développement dans le cloud pour définir l’architecture de base d’un service évolutif et relativement peu coûteux. Vous pouvez effectuer un travail plus détaillé pour préciser les choses, en construisant des prototypes rapides à tester, avant de commencer avec un produit minimum viable et en ajoutant des fonctionnalités à chaque version ultérieure. En associant les services et l’informatique sans serveur, vous pouvez mettre à l’échelle rapidement en fonction de la demande des utilisateurs, sans avoir à vous engager dans des coûts d’infrastructure virtuelle à très long terme.
Il est utile de mener régulièrement ce type d’exercice de conception avec votre équipe d’architecture, car il vous permet de déterminer des services que vous n’utilisez peut-être pas dans vos applications. C’est un moyen rapide et facile d’apprendre et de partager des idées, avec un petit plus : une fois que vous avez pensé à les utiliser dans une application “greenfield”, vous avez la possibilité de les prendre en compte dans les prochains développements et mises à jour d’applications, ce qui vous permet de réduire le risque de dette technique.
