Ce guide vous aide à découvrir ce que vos clients disent de vos produits et services sur les sites de réseaux sociaux, tels que Twitter. Au lieu de filtrer les données Twitter manuellement, vous pouvez créer un système d'alerte en temps quasi réel qui utilise les données de Twitter et classe les tweets à l'aide d'un modèle prédéfini de Hugging Face Hub.
Diagramme d'architecture
Étape 1
Une tâche Amazon Elastic Container Service (Amazon ECS) s’exécute sur une infrastructure sans serveur gérée par AWS Fargate et maintient une connexion ouverte à l’API Twitter.
Étape 2
Le jeton Bearer Twitter est stocké de manière sécurisée dans AWS Systems Manager Parameter Store, et l’image du conteneur est hébergée sur Amazon Elastic Container Registry (Amazon ECR).
Étape 3
Lorsqu’un nouveau tweet arrive, il est placé dans une file d’attente Amazon Simple Queue Service (SQS).
Étape 4
La logique de la solution réside dans les microservices de la fonctions AWS Lambda, coordonnés par AWS Step Functions.
Étape 5
Un modèle de classification Hugging Face est hébergé sur les points de terminaison sans serveur Amazon SageMaker.
Étape 6
Amazon Comprehend extrait les sentiments, les phrases clés et les entités. Si possible, Amazon Comprehend extrait l'emplacement.
Étape 7
Amazon Location Service transforme le nom d’un lieu en coordonnées.
Étape 8
Le tweet et les métadonnées sont envoyés à Amazon Simple Storage Service (Amazon S3), et Amazon Athena interroge les tweets traités à l’aide du SQL standard.
Étape 9
Amazon Lookout for Metrics recherche les anomalies dans le volume de mentions par catégorie. Amazon Simple Notification Service (Amazon SNS) envoie une alerte aux utilisateurs lorsqu’une anomalie est détectée.
Étape 10
Nous recommandons de configurer un tableau de bord Amazon QuickSight afin que les utilisateurs professionnels puissent facilement visualiser les informations.
Étape 1
Une tâche Amazon Elastic Container Service (Amazon ECS) s’exécute sur une infrastructure sans serveur gérée par AWS Fargate et maintient une connexion ouverte à l’API Twitter.
Étape 2
Le jeton Bearer Twitter est stocké de manière sécurisée dans AWS Systems Manager Parameter Store, et l’image du conteneur est hébergée sur Amazon Elastic Container Registry (Amazon ECR).
Étape 3
Lorsqu’un nouveau tweet arrive, il est placé dans une file d’attente Amazon Simple Queue Service (SQS).
Étape 4
La logique de la solution réside dans les microservices de la fonctions AWS Lambda, coordonnés par AWS Step Functions.
Étape 5
Un modèle de classification Hugging Face est hébergé sur les points de terminaison sans serveur Amazon SageMaker.
Étape 6
Amazon Comprehend extrait les sentiments, les phrases clés et les entités. Si possible, Amazon Comprehend extrait l'emplacement.
Étape 7
Amazon Location Service transforme le nom d’un lieu en coordonnées.
Étape 8
Le tweet et les métadonnées sont envoyés à Amazon Simple Storage Service (Amazon S3), et Amazon Athena interroge les tweets traités à l’aide du SQL standard.
Étape 9
Amazon Lookout for Metrics recherche les anomalies dans le volume de mentions par catégorie. Amazon Simple Notification Service (Amazon SNS) envoie une alerte aux utilisateurs lorsqu’une anomalie est détectée.
Étape 10
Nous recommandons de configurer un tableau de bord Amazon QuickSight afin que les utilisateurs professionnels puissent facilement visualiser les informations.
Piliers AWS Well-Architected
Le cadre AWS Well-Architected vous permet de comprendre les avantages et les inconvénients des décisions que vous prenez lors de la création de systèmes dans le cloud. Les six piliers du cadre vous permettent d'apprendre les bonnes pratiques architecturales pour concevoir et exploiter des systèmes fiables, sécurisés, efficaces, rentables et durables. Grâce à l'outil AWS Well-Architected Tool, disponible gratuitement dans la console de gestion AWS, vous pouvez examiner vos charges de travail par rapport à ces bonnes pratiques en répondant à une série de questions pour chaque pilier.
Le diagramme d'architecture ci-dessus est un exemple de solution créée en tenant compte des bonnes pratiques Well-Architected. Pour être totalement conforme à Well-Architected, vous devez suivre autant de bonnes pratiques Well-Architected que possible.
-
Excellence opérationnelleLire le livre blanc sur l'excellence opérationnelle
Vous pouvez annuler les modifications apportées à l’architecture à l’aide d’un modèle AWS CloudFormation. Si les déploiements échouent dans Fargate et Lambda, ils peuvent être automatiquement restaurés vers les versions précédentes.
-
SécuritéLire le livre blanc sur la sécurité
Pour déployer cette architecture, vous devez configurer un utilisateur ou un rôle de Gestion des identités et des accès (IAM) avec les autorisations appropriées pour les services. En outre, les données stockées dans Amazon S3 sont chiffrées à l’aide d’une clé AWS Key Management Service (AWS KMS).
-
FiabilitéLire le livre blanc sur la fiabilité
Les données sont stockées dans Amazon S3, un service de stockage d'objets qui offre une durabilité de 99,999999999 %. Si vos données sont critiques pour votre entreprise, vous pouvez implémenter la réplication interrégionale S3 (CRR) afin de répliquer les données dans d'autres régions AWS à des fins de reprise après sinistre. Lorsque des anomalies supérieures à un certain seuil se produisent, Amazon SNS vous envoie des alertes afin que vous puissiez résoudre rapidement le problème.
-
Efficacité des performancesLire le livre blanc sur l'efficacité des performances
AWS gère les tâches administratives pour les services gérés, telles que les correctifs et les mises à jour afin de maintenir l'efficacité des performances. Des services tels que Lookout for Metrics et Amazon Location sont spécifiquement conçus pour détecter les anomalies et ajouter des données de localisation aux applications, respectivement.
-
Optimisation des coûtsLire le livre blanc sur l'optimisation des coûts
Dans ce guide, la majorité des données sont consommées directement dans AWS via Athena et QuickSight, ce qui réduit le montant des frais de transfert de données. Le transfert de données sortantes via Amazon SNS n'a lieu que pour les anomalies dépassant les seuils définis par l'utilisateur. De plus, cette architecture utilise des services sans serveur, de sorte que vous ne payez que pour les ressources que vous consommez.
-
Développement durableLire le livre blanc sur le développement durable
Les services sans serveur se mettent à l'échelle en fonction de l'utilisation, de sorte que vous n'avez pas à faire fonctionner une infrastructure inactive pour répondre à la croissance de la demande.
Ressources d'implémentation
L'exemple de code est un point de départ. Il s'agit d'un document validé par l'industrie, prescriptif mais non définitif, et d'un aperçu pour vous aider à commencer.
Contenu connexe
Créez un système d’alerte en temps réel basé sur les actualités avec Twitter, Amazon SageMaker et Hugging Face
Avis de non-responsabilité
Les exemples de code, les bibliothèques de logiciels, les outils de ligne de commande, les preuves de concept, les modèles ou toute autre technologie connexe (y compris tout ce qui précède qui est fourni par notre personnel) vous sont fournis en tant que contenu AWS en vertu du contrat client AWS ou de l'accord écrit pertinent entre vous et AWS (selon le cas). Vous ne devez pas utiliser ce contenu AWS dans vos comptes de production, ni sur des données de production ou autres données critiques. Vous êtes responsable des tests, de la sécurisation et de l'optimisation du contenu AWS, tel que les exemples de code, comme il convient pour une utilisation en production, en fonction de vos pratiques et normes de contrôle de qualité spécifiques. Le déploiement de contenu AWS peut entraîner des frais AWS pour la création ou l’utilisation de ressources payantes AWS, telles que l’exécution d’instances Amazon EC2 ou l’utilisation du stockage Amazon S3.