Organiser une démo
Se connecter à la console
  • Technologie

  • Solution

Comment nous avons construit notre plateforme d'analyse sur AWS en un jour

décembre 29, 2020 by Jawad Stouli

Chez Didomi, nous avons récemment mis en place une première version de notre plateforme d'analyse et de rapport pour les mesures commerciales (et non pas pour les mesures purement techniques ou opérationnelles). Nous voulions commencer à collecter des mesures commerciales et disposer d'un moyen facile de les collecter, les stocker, les interroger et les représenter graphiquement qui serait 1) adapté à notre taille (nous sommes encore une assez petite entreprise), 2) rentable (voir n° 1) et 3) suffisamment flexible et évolutif pour que nous n'ayons pas besoin de le revoir dans 6 mois.

 

Sommaire 

 

 


 

Quels sont les événements que nous collectons ?

 

Nous aidons les entreprises à se mettre en conformité avec la réglementation sur la protection de la vie privée (RGPD, ePrivacy, etc.). Notre principale source d'événements est donc notre SDK qui est déployé sur les sites web ou les applications mobiles et qui affiche des bannières, des formulaires et d'autres éléments pour gérer la vie privée des utilisateurs.

 

Nous voulions pouvoir suivre des événements tels que le nombre de fois que notre SDK est chargé (c'est-à-dire le nombre de pages vues), les sites web sur lesquels il est déployé, la fréquence à laquelle les utilisateurs interagissent avec lui, etc. Cela sera utilisé à la fois en interne et pour construire un tableau de bord orienté client à terme.

 

Vous voulez vous mettre en conformité avec la réglementation sur la protection de la vie privée ? 

 

Découvrir Didomi pour la Conformité

 

La solution

 

 

Ce que nous voulions construire est presque banalisé de nos jours. Le flux de travail comporte deux parties :


1) Une API pour collecter les événements des utilisateurs qui sont convertis en un flux qui peut être consommé en interne par différents services. La sortie du flux est stockée de manière fiable pour une utilisation à long terme et un traitement par lots.
2) Un moteur d'interrogation et un frontal pour exécuter des requêtes et représenter les résultats sous forme de graphique (également appelé outil de BI).

 

J'ai déjà utilisé Hive/Spark (je suis un grand fan de Qubole et de Databricks, par exemple), j'ai donc envisagé ces options : elles sont incroyablement puissantes mais aussi très complexes et coûteuses à exploiter et certainement pas adaptées à notre taille. Nous faisons appel à AWS pour une grande partie de nos opérations et nous avons donc commencé à examiner les solutions qu'ils proposent. La réponse est : beaucoup. Bien qu'il faille parfois faire des efforts pour comprendre ce que fait chaque produit, ils ont fait beaucoup de chemin pour offrir des produits d'analyse solides.

 

Nous avons fini par mettre en place l'infrastructure suivante :


  • Les événements sont envoyés à notre API (un serveur API Feathers Node.js standard fonctionnant sur Elastic Beanstalk / Elastic Container Service) par nos SDK
  • Notre API envoie des événements sous le nom de JSON à AWS Firehose
  • Firehose rassemble les bûches (jusqu'à 5 minutes ou 5 MB) et les envoie à S3
  • AWS Athena est utilisé pour exécuter SQL sur nos événements stockés sur S3
  • Redash (pas un produit AWS cette fois-ci !) nous permet de gérer facilement nos requêtes et de générer des graphiques/tableaux de bord internes avec Athena comme backend

 

Documentation technique

 


Difficultés

 

La mise en place s'est déroulée sans problème et nous n'avons pas rencontré de difficultés majeures. Nous avons cependant découvert certaines limites des produits AWS et ils semblent être assez jeunes à ce stade :

1) Firehose
AWS Firehose n'est pas très flexible et écrit simplement les données que vous envoyez à S3. Vous pouvez y exécuter une fonction Lambda, mais nous n'avons pas encore essayé cela.
Il ne permet pas de transformer automatiquement les données dans un autre format (par exemple, j'aurais préféré stocker Parquet plutôt que JSON) et les chemins S3 qu'il utilise ne sont pas compatibles avec les partitions Hive de sorte qu'il n'est pas possible de partitionner les tables Athena. Avec des journaux horodatés, cela rendra les requêtes coûteuses assez rapidement.

2) Athéna / Glue / Quicksight
Cela semble être le trio idéal pour ce type d'infrastructure sur l'AWS et nous avons essayé de les utiliser tous. Athena est le moteur d'interrogation, Glue hébergerait le métastore (c'est-à-dire le schéma de nos bases de données et de nos tableaux) et QuickSight pourrait être utilisé pour créer des graphiques et des tableaux de bord. Or, Glue et QuickSight ne sont pas disponibles dans notre région. Bien que nos serveurs API soient distribués, nous voulons stocker les données à Francfort (nous nous conformons au GDPR, souvenez-vous, donc le stockage des données en Europe est important pour nous).

3) Documentation et références Athena en ligne
Il est assez difficile de trouver une documentation détaillée sur Athéna. Il semble utiliser Presto comme moteur (https://aws.amazon.com/athena/faqs/) mais une grande partie de la documentation de AWS est quelque peu incomplète (traiter les dates/heures d'enregistrement, par exemple, est délicat) et le produit est suffisamment récent pour qu'il n'y ait pas grand chose à trouver sur StackOverflow/Google en termes d'aide communautaire. On finit par passer par les questions de Presto/Hive et on fait beaucoup d'essais jusqu'à ce qu'on trouve une fonction qui soit réellement prise en charge par Athena.

Si nous regardons l'histoire de l'évolution des produits AWS, nous pouvons voir que nous sommes vraiment au début de l'histoire pour Athena : un noyau très solide qui fait ce qu'il doit faire de manière très fiable mais pas beaucoup plus que cela. Ils continueront certainement à ajouter de nouvelles fonctionnalités au fil du temps.


Est-ce que cela en vaut la peine ?

 

Dans l'ensemble, la mise en œuvre de l'ensemble du dispositif est vraiment facile. Il nous a fallu moins d'une journée pour la faire fonctionner, même s'il est important de noter que nous avions une certaine expérience préalable de la construction de systèmes similaires et que nous savions où nous allions. Nous utilisons CloudFormation pour automatiser toutes nos piles sur AWS, de sorte que notre installation finale est entièrement gérée et reproductible dans d'autres régions si nécessaire et nous sommes susceptibles d'opérer dans quelques régions différentes pour garder les données des utilisateurs aussi proches que possible de l'utilisateur final.

Le modèle de prix comparé au coût d'une solution basée sur Hive ou Spark est très (très !) favorable pour une entreprise de notre taille. Nous payons quelques dollars par mois pour tout cela, sans coût initial et nous savons que le prix évoluera naturellement avec notre croissance.

À notre taille et pour le nombre d'événements que nous traitons quotidiennement, nous aurions pu opter pour une approche plus simple (Postgres, par exemple) et garder Athena/Redash comme couche d'interrogation. Cela étant dit, je voulais vraiment essayer Firehose et j'avais déjà une bonne expérience de ce type de gestion d'événements, de sorte qu'il ne semblait pas trop sophistiqué et que je savais qu'il serait facile et fiable.


Conclusion


C'est notre histoire. L'infrastructure complète semble assez simple, même si si vous pensez à ce que fait chaque composante et à l'échelle et à la profondeur qui se cachent derrière chacune d'elles, vous vous rendrez compte de la quantité de travail qu'il nous aurait fallu pour la construire sans les services AWS. Je suis étonné de voir à quel point l'industrie et les services de navigation aérienne ont grandi. Je suis client d'AWS depuis plus de 7 ans maintenant dans différentes entreprises : lorsque j'ai commencé à les utiliser, ils ne faisaient pratiquement rien d'autre que de l'EC2 et du RDS et, bien que cela soit déjà très puissant, il ne s'agissait "que" de serveurs virtuels.

C'est fou comme il est devenu facile de construire, d'orchestrer et d'automatiser une infrastructure fiable, distribuée et évolutive pour les API en temps réel, l'analyse, l'IA et bien d'autres choses encore de nos jours. Cela aide également les startups comme Didomi à construire une infrastructure que nous n'aurions pas pu nous permettre à l'époque et favorise l'innovation plus que toute autre chose.

PS : Je suis évidemment partial car mon expérience avec les autres fournisseurs de cloud computing est quelque peu limitée, mais il ne s'agit pas d'un article de blog "AWS contre les autres".

 

Vous voulez en savoir plus ? Contactez-nous

 

Didomi pour les développeurs

 

Articles reliés