Projets sur AWS

Création d'une application Web moderne

Déployer une application Web, se connecter à une base de données et analyser le comportement des utilisateurs

Module 5 : Appréhender le comportement des utilisateurs

Dans ce module, vous appréhenderez le comportement des utilisateurs à l'aide d'AWS Lambda et d'autres services sans serveur.

Présentation

Maintenant que votre site Mythical Mysfits est pleinement opérationnel, voyons comment mieux comprendre comment les utilisateurs interagissent avec le site Web et Mysfits. Nous pourrions très facilement analyser les actions que l'utilisateur effectue sur le site Web, qui entraînent des changements de données dans notre backend, lorsque des Mysfits sont adoptés ou aimés.

Or, comprendre les actions qu'effectuent vos utilisateurs sur le site Web avant de décider d'aimer ou d'adopter un mysfit peut vous aider à améliorer l'expérience utilisateur à l'avenir. Ainsi, les utilisateurs adopteront plus rapidement des mysfits. Pour nous aider à recueillir ces informations, chaque fois que l'utilisateur clique sur un profil mysfit, nous permettrons au site Web frontend d'envoyer une demande de faible envergure à l'API d'un nouveau microservice que nous allons créer. Ces enregistrements seront traités en temps réel par une fonction de code sans serveur, agrégée et stockée en vue d'une future analyse que vous souhaiteriez effectuer.

Les principes de conception d'applications modernes privilégient les services ciblés, découplés et modulaires. Ajoutez plutôt des méthodes et des capacités supplémentaires au sein du service Mysfits existant avec lequel vous avez travaillé jusqu'ici. Nous allons créer un nouveau service découplé afin de recevoir des événements de clic par les utilisateurs, depuis le site Web Mysfits. Cette pile entière a été représentée en utilisant un modèle CloudFormation qui a été fourni.

Diagramme d'architecture

Appréhender le comportement des utilisateurs

Pourquoi choisir AWS Lambda pour cette implémentation ?

Lambda convient parfaitement pour les applications guidées par les données, qui doivent réagir en temps réel aux changements de données, aux modifications de l'état du système ou aux actions des utilisateurs. Ces applications se connectent généralement aux magasins de données pour accéder aux données et les analyser en vue d'un traitement par lot, l'analyse des flux et l'interférence machine learning. Lambda convient pour ces applications, car ce service est intégré aux magasins de données tels que Kinesis Data Streams et Data Firehose, S3, CloudWatch Events, CloudWatch Logs et DynamoDB, avec un total de 17 sources d'événements aujourd'hui.   

Ressources sans serveur utilisées dans ce module

Flux de diffusion AWS Kinesis Firehose : Kinesis Firehose est un service de diffusion en temps réel hautement disponible et géré, qui accepte les enregistrements de données et qui les ingère automatiquement dans plusieurs destinations de stockage possibles dans AWS, comme un bucket Amazon S3 ou un cluster d'entrepôt de données Amazon Redshift. Kinesis Firehose permet également à l'ensemble des enregistrements reçus par le flux d'être automatiquement fournis à une fonction sans serveur créée avec AWS Lambda. Cela signifie que le code que vous avez écrit peut effectuer n'importe quel traitement ou n'importe quelle transformation des enregistrements avant qu'ils soient agrégés et stockés dans la destination configurée.

Bucket Amazon S3 : un nouveau bucket sera créé dans S3. L'ensemble des enregistrements d'événements de clics traités y seront agrégés en fichiers et stockés en tant qu'objets.

Fonction AWS Lambda : AWS Lambda permet aux développeurs d'écrire des fonctions de code qui contiennent uniquement ce que leur logique exige et de déployer, d'invoquer, de rendre leur code hautement fiable et évolutif sans avoir besoin de gérer l'infrastructure. Dans cet exemple, une fonction de code sans serveur est définie à l'aide d'AWS SAM. Cette fonction sera déployée dans AWS Lambda, écrite dans Python, puis traitera et enrichira ensuite les enregistrements de clics reçus par le flux de diffusion. Le code que nous avons écrit est très simple et l'enrichissement aurait pu être effectué sur le site Web frontend sans aucun traitement ultérieur. La fonction extrait des attributs supplémentaires à propos des clics sur Mysfit pour augmenter la pertinence des enregistrements de clics (données qui ont déjà été extraites par le site Web frontend). Dans le cadre de cet atelier, le code a toutefois pour but de démontrer les possibilités architecturales liées à l'inclusion d'une fonction de code sans serveur pour effectuer un traitement ou une transformation nécessaire en temps réel, avant que les enregistrements soient stockés. Une fois que la fonction Lambda est créée et que le flux de diffusion Kinesis Firehose est configuré en tant que source d'événements pour la fonction, le flux de diffusion fournira automatiquement les enregistrements de clics en tant qu'événements pour la fonction de code que nous avons créée, recevra les réponses renvoyées par notre code et fournira les enregistrements mis à jour vers le bucket Amazon S3 qui a été configuré.

Amazon API Gateway REST : AWS Kinesis Firehose fournit une API de service comme d'autres services AWS. Dans ce cas, nous utilisons son opération PutRecord pour intégrer les enregistrements des événements de clics utilisateurs dans le flux de diffusion. Or, le but n'est pas que notre site Web frontend soit directement intégré avec l'API PutRecord Kinesis Firehose. Nous devrions alors gérer les informations d'identification AWS dans notre code frontend pour autoriser ces demandes API vers l'API PutRecord. L'API AWS directe dont nous dépendons serait alors exposée aux utilisateurs (ce qui pourrait encourager des visiteurs malintentionnés à ajouter des enregistrements au flux de diffusion qui ne seraient pas correctement formés ou qui nuiraient à notre objectif, qui est de comprendre le comportement réel des utilisateurs). Au lieu de cela, nous allons donc utiliser Amazon API Gateway pour créer un service proxy AWS pour l'API PutRecord de Kinesis Firehose. Cela nous permet de créer notre propre point de terminaison public RESTful qui ne nécessite pas de gérer des informations d'identification AWS sur le frontend pour les demandes. Nous allons également utiliser un modèle de mappage des demandes dans API Gateway, qui nous permettra de définir notre propre structure de charge des demandes, qui limitera les demandes à notre structure attendue et qui transformera ensuite ces demandes dûment formées dans la structure demandée par l'API PutRecord Kinesis Firehose.

Rôles IAM : Kinesis Firehose nécessite un rôle de service qui lui permet de fournir les enregistrements reçus en tant qu'événements pour la fonction Lambda qui a été créée, ainsi que les enregistrements traités vers le bucket S3 de destination. L'Amazon API Gateway nécessite également un nouveau rôle, qui permet à l'API d'invoquer l'API PutRecord dans Kinesis Firehose pour chaque demande API reçue.

Instructions de mise en œuvre

  • A : Création d'un nouveau référentiel CodeCommit

    Cette nouvelle pile que vous allez déployer à l'aide de CloudFormation ne comprendra pas les ressources de l'environnement de l'infrastructure, mais le code de l'application exécuté par AWS Lambda pour traiter les événements de diffusion. Pour joindre la création de notre infrastructure et de notre code en un seul déploiement, nous allons utiliser un autre outil AWS préinstallé dans l'IDE AWS Cloud9 - AWS SAM CLI. Le code pour les fonctions AWS Lambda est fourni au service en chargeant le code de fonction dans un package .zip vers un bucket Amazon S3.

    La SAM CLI automatise ce processus pour nous. Ce processus nous permet de créer un modèle CloudFormation qui référence localement dans le système de fichiers, où est stocké l'ensemble du code pour notre fonction Lambda. Ensuite, la SAM CLI rassemble ces informations dans un fichier .zip, le charge dans un bucket Amazon S3 qui a été configuré et crée un nouveau modèle CloudFormation indiquant l'emplacement dans S3 où le package .zip créé a été chargé en vue du déploiement vers AWS Lambda. Nous pouvons ensuite déployer ce modèle CloudFormation généré par la SAM CLI sur AWS et observer la création de l'environnement avec la fonction Lambda utilisant le package de code chargé par la SAM CLI.

    Tout d'abord, nous allons créer un nouveau référentiel CodeCommit où le code du service de diffusion s'exécutera :

    aws codecommit create-repository --repository-name MythicalMysfitsStreamingService-Repository

    Dans la réponse à cette commande, copiez la valeur pour « cloneUrlHttp ». Cette valeur devrait ressembler à ceci : https://git-codecommit.REPLACE_ME_REGION.amazonaws.com/v1/repos/MythicalMysfitsStreamingService-Repository.

    Ensuite, clonez ce nouveau référentiel vide dans notre IDE :

    cd ~/environment/
    git clone {insert the copied cloneValueUrl from above}
    B : Copie de la base du code du service de diffusion

    Nous allons maintenant déplacer notre répertoire de travail dans ce nouveau référentiel :

    cd ~/environment/MythicalMysfitsStreamingService-Repository/

    Ensuite, copiez les composants de l'application du module 5dans ce nouveau référentiel du répertoire :

    cp -r ~/environment/aws-modern-application-workshop/module-5/app/streaming/* .

    Nous allons copier le modèle CloudFormation pour ce module également.

    cp ~/environment/aws-modern-application-workshop/module-5/cfn/* .
  • A : Utilisation de Pip pour installer des dépendances de la fonction Lambda

    Le référentiel du répertoire est maintenant configuré, avec tous les artefacts fournis :

    Un modèle CFN pour créer l'ensemble de la pile.

    Un script Python contenant le code pour notre fonction Lambda : streamProcessor.py.

    Les clients AWS suivent généralement cette approche pour stocker leurs modèles CloudFormation, ainsi que le code de leur application dans un référentiel. De cette façon, toutes les modifications effectuées au niveau de l'application et de son environnement peuvent être suivies à un seul endroit.

    Toutefois, si vous observez le code dans le fichier streamProcessor.py, vous remarquerez qu'il utilise les demandes du package Python pour formuler une demande API au service Mythical Mysfits que vous avez créé précédemment. Les bibliothèques externes ne sont pas comprises automatiquement dans l'environnement d'exécution AWS Lambda, car des clients AWS différents peuvent dépendre de différentes versions de plusieurs bibliothèques, etc.

    Vous devrez joindre toutes vos dépendances de bibliothèques avec votre fonction de code Lambda avant de les charger dans le service Lambda. Pour ce faire, utilisez le pip Manager du package Python. Dans le terminal Cloud9, exécutez la commande suivante pour installer les packages de demande et leurs dépendances localement, ainsi que le code de votre fonction :

    pip install requests -t .

    Une fois cette commande effectuée, vous constaterez que plusieurs dossiers de packages Python supplémentaires sont stockés dans le référentiel de votre répertoire.

    B : Mise à jour du code de la fonction Lambda

    Nous devons ensuite procéder à un changement de code avant que le code de notre fonction Lambda soit prêt à être déployé. Une ligne dans le fichier streamProcessor.py doit être remplacée par le point de terminaison API pour l'API de votre service Mysfits, le même point de terminaison API pour le service que vous avez créé dans le module 4 et que vous avez utilisé sur le site Web frontend.

    replace-api-endpoint

    Ce service est responsable de l'intégration avec la table Mysfits dans DynamoDB. Dès lors, même si nous pouvions écrire une fonction Lambda qui serait directement intégrée avec la table DynamoDB également, nous empiéterions sur les objectifs du premier microservice et nous nous retrouverions avec plusieurs bases de codes séparées, intégrées avec la même table. Au lieu de cela, nous allons les intégrer avec cette table par le biais du service existant et disposerons d'une architecture d'applications découplée et modulaire.

    C : Intégration de votre code dans CodeCommit

    Effectuons les changements au niveau du code dans le nouveau référentiel afin qu'ils soient enregistrés dans CodeCommit :

    git add .
    git commit -m "New stream processing service."
    git push
  • A : Création d'un bucket S3 pour les packages de code de fonction Lambda

    Cette ligne ayant été modifiée dans le fichier Python, et notre code publié, nous sommes désormais prêts à utiliser la SAM CLI AWS pour rassembler l'ensemble de notre code de fonction, le charger dans S3 et créer le modèle CloudFormation déployable, afin de créer notre pile de diffusion.

    Tout d'abord, utilisez la CLI AWS pour créer un nouveau bucket S3 dans lequel charger nos packages de codes de fonction Lambda. Les noms des buckets S3 doivent être globalement uniques parmi l'ensemble des clients AWS. Vous devez donc remplacer la fin du nom de ce bucket par une chaîne qui vous est unique :

    B : Utilisation de la SAM CLI pour rassembler votre code pour Lambda

    Une fois votre bucket créé, nous sommes désormais prêts à utiliser la SAM CLI pour rassembler et charger notre code, puis transformer le modèle CloudFormation. Assurez-vous de remplacer le dernier paramètre de la commande par le nom du bucket que vous venez de créer ci-dessus (cette commande part également du principe que votre terminal se trouve toujours dans le répertoire de travail du référentiel) :

    sam package --template-file ./real-time-streaming.yml --output-template-file ./transformed-streaming.yml --s3-bucket replace-with-your-bucket-name

    Si vous y parvenez, vous verrez que le fichier que vous venez de créer, transformed-streaming.yml, existe dans le répertoire ./MythicalMysfitsStreamingService-Repository/. Si vous en observez le contenu, vous verrez que le paramètre CodeUri de la fonction Lambda sans serveur a été mise à jour avec l'emplacement de l'objet où la SAM CLI a chargé votre code.

    C : Déploiement de la pile avec AWS CloudFormation

    La SAM CLI renvoie également la commande CloudFormation qui doit être exécutée pour créer notre nouvelle pile. Or, étant donné que notre pile crée des ressources IAM, vous devrez ajouter un paramètre supplémentaire à la commande. Exécutez la commande suivante pour déployer la pile de diffusion :

    aws cloudformation deploy --template-file /home/ec2-user/environment/MythicalMysfitsStreamingService-Repository/cfn/transformed-streaming.yml --stack-name MythicalMysfitsStreamingStack --capabilities CAPABILITY_IAM

    Le microservice de traitement en temps réel est créé une fois que la création de la pile est terminée.

    Dans les futurs scénarios dans lesquels seules des modifications de code ont été effectuées dans votre fonction Lambda, et que le reste de votre pile CloudFormation n'est pas modifié, vous pouvez répéter la même SAM CLI AWS et les mêmes commandes CloudFormation que ci-dessus. L'environnement de l'infrastructure restera ainsi inchangé, mais un code sera déployé dans votre fonction Lambda.

  • A : Mise à jour du contenu du site Web

    Maintenant que la pile de diffusion est pleinement opérationnelle, nous devons maintenant publier une nouvelle version de notre frontend Mythical Mysfits, comprenant le JavaScript qui envoie des événements à notre service lorsqu'un utilisateur clique sur un profil Mysfit.

    Le nouvel index est inclus à l'adresse suivante : ~/environment/aws-modern-application-workshop/module-5/web/index.html.

    Le fichier contient les mêmes espaces réservés que le module 4 qui doivent être mis à jour, ainsi qu'un espace réservé supplémentaire pour le nouveau point de terminaison du service de traitement de diffusion que vous venez de créer. Pour les valeurs variables précédentes, reportez-vous au précédent fichier index.html que vous avez mis à jour dans le cadre du module 4.

    Effectuez la commande suivante pour que la nouvelle pile de diffusion puisse extraire le nouveau point de terminaison de l'API Gateway pour votre service de traitement de diffusion :

    aws cloudformation describe-stacks --stack-name MythicalMysfitsStreamingStack
    B : Intégration de la nouvelle version du site dans S3

    Remplacez la valeur finale dans index.html pour le streamingApiEndpoint. Vous êtes alors prêts à publier la mise à jour finale de votre page d'accueil Mythical Mysfits :

    aws s3 cp ~/environment/aws-modern-application-workshop/module-5/web/index.html s3://YOUR-S3-BUCKET/

    Actualisez à nouveau votre site Web Mythical Mysfits dans le navigateur. Vous disposez désormais d'un site qui enregistre et publie chaque fois qu'un utilisateur clique sur un profil Mysfits !

    Pour visualiser les enregistrements qui ont été traités, ils arriveront dans le bucket S3 de destination qui a été créé dans le cadre de votre MythicalMysfitsStreamingStack.

    Maintenant que vous avez terminé l'architecture d'une application moderne, nous vous encourageons à explorer la console AWS et les différents services que vous avez créés pour lancer Mythical Mysfits !

  • Assurez-vous de supprimer toutes les ressources créées lors de l'atelier pour que ces ressources ne vous soient pas facturées plus longtemps que vous en avez l'intention. Nous vous conseillons d'utiliser la console AWS pour explorer les ressources que vous avez créées et les supprimer une fois que vous avez terminé.

    Pour les deux cas pour lesquels vous avez provisionné les ressources avec AWS CloudFormation, vous pouvez supprimer ces ressources en exécutant la commande CLI suivante pour chaque pile :

    aws cloudformation delete-stack --stack-name STACK-NAME-HERE

    Pour supprimer toutes les ressources que vous avez créées, consultez les consoles AWS suivantes, qui comprennent les ressources que vous avez créées pendant l'atelier Mythical Mysfits :

Conclusion

Cette expérience avait pour but de vous donner un aperçu des tâches d'un développeur, qui conçoit et crée des architectures d'applications modernes sur AWS. Les développeurs sur AWS provisionnent des ressources par programmation à l'aide de la CLI AWS, réutilisent les définitions des infrastructures via AWS CloudFormation, créent et déploient automatiquement des modifications de code à l'aide de la suite d'outils pour développeurs AWS de services de code, et font appel à plusieurs capacités de calcul et d'applications de services, qui ne vous demandent pas de provisionner ou de gérer des serveurs.

Ensuite, pour en savoir plus sur le fonctionnement interne du site Web Mythical Mysfits que vous avez créé, consultez les modèles CloudFormation fournis et les ressources déclarées avec ces modèles.

Nous espérons que vous avez apprécié l'atelier AWS sur les applications modernes ! Ce didacticiel est également hébergé sur GitHub pour que vous puissiez envoyer une question si vous avez des recommandations. Vous aurez également la possibilité d'initialiser une demande GitHub si vous souhaitez améliorer le code.

Si vous souhaitez en savoir plus sur le développement sur AWS, consultez notre Centre pour développeurs AWS.

Félicitations !

Vous avez conçu une application moderne sur AWS.
Partagez-la avec vos amis ou envoyez-nous vos commentaires.

Twilight Glitter est impressionné par votre travail