Entrez dans le monde serverless en créant un scraper automatique de Twitter sur AWS en cinq étapes simples

Cet article a été écrit avant le changement de nom de Twitter et la suppression ultérieure de son API. Même si vous ne pourrez pas reproduire l’exemple tel quel, l’idée s’applique exactement de la même manière pour n’importe quelle autre API. Quelques exemples intéressants pour vous entraîner : celle de Binance ou celle d’Openweather.

Serverless ou “le nom le plus mal choisi de l’histoire”

Si vous débutez votre carrière dans la data, ou si vous commencez tout juste à découvrir le monde du cloud, vous avez sûrement croisé plus d’une fois le terme serverless. Même si le nom pourrait laisser penser qu’il s’agit de quelque chose sans serveurs, l’idée est en réalité complètement différente.

Serverless signifie que la personne qui développé n’a pas accès à l’infrastructure sous-jacente, généralement fournie par un fournisseur cloud (AWS, GCP, Azure, etc.).

Il faut mentionner que le monde serverless gagne du terrain ces dernières années car il présente des avantages significatifs tant pour les développeurs que pour le métier :

• Même si c’est une arme à double tranchant, l’avantage pour les data scientists et les développeurs en général est qu’on prend peu de risques d’installer quelque chose qui pourrait casser un environnement.

• Côté business, dans la plupart des cas, une bonne architecture serverless pilotée par événements génère une meilleure efficacité en termes de coûts et de contrôle sur ce qui se fait dans l’organisation.

Le monde serverless peut être intimidant, alors le mieux c’est de le voir en action. Ceci est le premier de trois articles où on va progressivement avancer vers une architecture de plus en plus automatisée, en faisant grandir un développement où on va interroger l’API de Twitter et stocker les résultats dans S3 pour les exploiter ensuite.

Au boulot !

Ce dont on va avoir besoin à cette étape :

• Une API Key développeur Twitter (la v2 de l’API s’obtient instantanément et suffit pour notre cas).

• Un accès à AWS avec les rôles qui nous permettent d’interagir entre Lambda, S3 et EventBridge.

• Un bucket dans S3.

En optionnel, l’accès à un notebook AWS SageMaker (et les rôles requis, en particulier pour se connecter à S3).

Étape 1 : Monter et tester le scraper

Voyons le code du scraper :

• Avec tweepy, on peut interagir avec les services de Twitter. La documentation est très complète et offre des méthodes et classes tant pour la v1 que la v2 de l’API.

• On s’authentifie via l’OAuthHandler, où on va passer le bearer token que Twitter nous donne à la création de cette application. Il est très important de préserver la sécurité de ces clés d’accès, qui ne sont en aucun cas publiques. Normalement, on commence par le mettre “comme ça”, mais plus tard on verra comment stocker cette clé dans une variable d’environnement de la Lambda qui va exécuter l’appel à Twitter.

• On sélectionne les champs du tweet qui nous intéressent.

• La query peut être n’importe quoi… comme des news sur Magic. Oui, c’est la query avec laquelle j’ai testé ; et non, je ne regrette rien.

• D’abord on instancie le client avec notre clé d’accès et on cherche les tweets avec quelques paramètres de notre choix.

• On convertit la réponse en dataframe Pandas, et voila !

Étape 2 : Uploader les données dans un bucket AWS

L’étape suivante est de les uploader dans un bucket S3 (stockage simple d’objets) pour les exploiter à volonté.

Voyons comment :

• Maintenant la query définitive est en place : on va chercher ce qui se dit sur Ethereum, mais ça peut être n’importe quoi !

• On instancie une variable avec le nom de notre bucket. Cette façon indirecte de construire les destinations (ne pas faire l’appel direct au nom dans la création de l’objet s3.Bucket mais la variable BUCKET dans la cellule 8) sera très utile par la suite (et c’est une bonne pratique).

• Justement dans la cellule 8, on voit qu’avec boto3 (la bibliothèque Python pour interagir avec les services AWS) on instancie l’accès à S3, et avec ça, l’accès au bucket avec lequel on veut travailler.

• Attention : pour uploader vers S3, il faut d’abord sauvegarder les données sur disque (les dumper), parce que ce dataframe qu’on a récupéré de Twitter est stocké uniquement en RAM (on sauvegarde dans test.csv).

• Pour l’uploader, via l’objet bucket on indique le chemin et nom du fichier qu’on veut uploader (“test.csv”) et la même chose pour le fichier tel qu’on veut qu’il apparaisse dans le cloud, dont le chemin et le nom peuvent parfaitement être différents (et le seront sûrement, comme dans l’exemple, où il s’appelle “test2.csv”) :

Étape 3 : Construire les lambda layers

On accélère un peu et on passe à fond dans le cloud !

Les lambdas sont des fonctions en tant que service : on met le code et AWS monte une infrastructure derrière pour l’exécuter. Comme l’idée est que tout soit le plus léger possible, les lambdas embarquent de base uniquement les bibliothèques essentielles.

C’est pourquoi, pour utiliser une bibliothèque un peu moins basique (ça peut surprendre, mais ça inclut Pandas !), il faut ajouter des couches (layers) qui étendent les fonctionnalités de base.

AWS en propose quelques-unes par défaut pour les cas courants (on va utiliser celle qui ajoute Pandas, justement), mais pour les cas moins classiques (comme Tweepy), il faut les construire à la main, et pour ça il faut faire une installation locale de la bibliothèque.

Avant de créer la lambda elle-même, construisons cette layer :

• On fait un classique pip install, mais en ajoutant l’argument -t, qui indique le target où on veut l’installer. Dans ce cas, on indique un dossier appelé python que j’ai créé au préalable : ce nom est obligatoire pour que la Lambda puisse fonctionner.

• On voit qu’une fois terminé, dans le dossier python restent tous les éléments de l’installation de la bibliothèque.

Avec ça fait, l’étape suivante est de le compresser et de l’uploader comme layer de lambda, ce qu’on peut faire en uploadant le fichier ou en indiquant un chemin vers un S3 contenant le .zip. Heureusement, l’interface vous guide et ce n’est pas une étape complexe : la seule obligation est de donner un nom à la layer (dans notre cas, tweepy).

Étape 4 : Construire la lambda

Tout est prêt, on peut construire la lambda elle-même.

• On a besoin d’un nom (au choix), d’un runtime (Python 3.8) et d’une architecture (x86_64).

• Côté permissions, il en faut un qui ait accès en écriture à S3. Si vous ne savez pas comment faire, voici un post où on explique la marche à suivre.

Avec ça, un éditeur de texte s’ouvre où on peut mettre notre code. La nouvelle version a peu de changements mais significatifs :

• Il y a une fonction appelée “lambda_handler” au milieu. Sans entrer dans les détails, c’est la fonction qui sera exécutée automatiquement par AWS, donc tout le code qu’on veut exécuter doit aller à l’intérieur.

• De haut en bas : on importe les bibliothèques et on instancie quelques variables avec des noms. À travers la concaténation de ces variables, on va construire tant les chemins des fichiers que les noms eux-mêmes de manière programmatique :

1. LOCAL_LAMBDA_FOLDER : Pour pouvoir sauvegarder sur disque dans le contexte d’une lambda, il faut écrire ce qu’on veut dans le dossier tmp/.

2. FOLDER_STRUCTURE : Via boto3, on peut uploader vers n’importe quel emplacement, tant que le chemin est correct. Avec cette méthode, on construit une structure propre pour stocker les données.

• D’abord on obtient un timestamp qu’on va utiliser pour construire le nom du fichier, en lui ajoutant l’extension du fichier sur la ligne juste en dessous.

• Ce LOCAL_FILENAME (la date + l’extension) sera utilisé pour construire le chemin de destination dans S3 (en respectant la structure du datalake) et le chemin où il sera stocké après le dump.

• Ici on utilise les variables d’environnement de Lambda pour cacher l’API Key. Via OS, on accède à une variable d’environnement appelée BEARER_TOKEN qu’on définit dans l’interface, dans la section correspondante :

• Enfin, on ajoute quelques prints dans la console pour superviser les logs.

Avec le code prêt et préparé, on ajoute les couches. En haut, sous le nom de la fonction, se trouve la section Layers. Le processus est simple : cliquer et ajouter les couches souhaitées :

• D’abord, dans l’option AWS Layers, choisir AWSDataWrangler-Python38 (celle qui correspond à la version de la Lambda).

• Ensuite, dans Custom Layers, choisir l’option qu’on a créée.

Il ne reste plus qu’à la tester ! Pour ça, on clique sur Test, on donne n’importe quel nom à l’événement et on lance le test. Si tout s’est bien passé, dans votre dossier S3 vous devriez voir un fichier .csv fraîchement créé.

Étape 5 : Programmer l’exécution

La dernière étape est de configurer l’événement qui déclenche l’exécution de la lambda de façon périodique. Pour ça, on clique sur Add Trigger et on construit la règle :

Détail sympathique : en plus des classiques expressions cron (UNIX), il accepte certaines expressions en anglais (comme dans l’exemple). On clique sur Add, et si tout s’est bien passé, ça s’exécutera toutes les cinq minutes.

Et ensuite ?

• La partie sur l’événement et ses tests : jusque-là ça semble ésotérique, mais c’est un élément crucial dans l’orchestration via EventBridge.

• Pour l’instant, tout est sauvegardé dans le même dossier, et ce n’est clairement pas la bonne façon de stocker des données dans un datalake. Pour ça, il faut partitionner les données, en stockant chaque élément dans des dossiers bien plus segmentés en fonction du moment où l’information a été extraite de Twitter.

Mais ça, ce sera dans la partie 2 !