Architecture : optimiser l'ingestion à grande échelle d'événements et de journaux d'analyse

Cet article décrit une architecture permettant d'optimiser l'ingestion d'analyses à grande échelle sur Google Cloud Platform (GCP). Pour les besoins de cet article, "grande échelle" signifie plus de 100 000 événements par seconde ou une taille totale de charge utile supérieure à 100 Mo par seconde.

Vous pouvez utiliser les services gérés élastiques et évolutifs de GCP pour collecter de grandes quantités d'événements de journalisation et d'analyse entrants, puis les traiter pour les intégrer dans un entrepôt de données tel que BigQuery.

Toute architecture permettant l'ingestion de quantités importantes de données d'analyse doit prendre en compte les données auxquelles vous devez accéder en temps quasi réel et que vous pouvez gérer après un court délai, avant de les répartir de manière appropriée. Une approche segmentée présente les avantages suivants :

  • Intégrité du journal. Permet de consulter les journaux complets. Aucun journal n'est perdu en raison des limites de quota en streaming ou de l'échantillonnage.
  • Réduction des coûts. Les insertions en flux continu d'événements et de journaux sont facturées plus cher que celles effectuées dans Cloud Storage à l'aide de tâches par lots.
  • Ressources de requête réservées. Le fait de déplacer les journaux de moindre priorité vers le chargement par lots les empêche d'avoir un impact sur les ressources de requête réservées.

Le diagramme d'architecture suivant illustre un tel système et introduit les concepts de chemins réactifs et de chemins à froid pour l'ingestion :

chemins d'ingestion généraux

Présentation de l'architecture

Dans cette architecture, les données proviennent de deux sources possibles :

Après avoir été ingérées par l'une des sources, en fonction des conditions de latence du message, les données sont placées dans le chemin réactif ou dans le chemin à froid. Le chemin réactif utilise une entrée en streaming, qui peut gérer un flux de données en continu, tandis que le chemin à froid est un processus par lots qui charge les données selon une planification que vous déterminez.

Événements de journalisation

Vous pouvez utiliser Stackdriver Logging pour ingérer les événements de journalisation générés par les fonctions de journalisation du système d'exploitation standard. Stackdriver Logging est disponible dans un certain nombre d'environnements Compute Engine, y compris les images standard, et peut également être installé sur de nombreux systèmes d'exploitation à l'aide de l'agent Stackdriver Logging. L'agent de journalisation est le récepteur de journalisation par défaut pour App Engine et Kubernetes Engine.

Chemin réactif

journalisation par chemin réactif

Dans le chemin réactif, les journaux critiques nécessaires à la surveillance et à l'analyse de vos services sont sélectionnés en spécifiant un filtre dans le récepteur de Stackdriver Logging, puis transmis à plusieurs tables BigQuery. Utilisez des tables distinctes pour les niveaux de journalisation ERROR et WARN, puis divisez-les ensuite par service si des volumes élevés sont attendus. Cette meilleure pratique maintient le nombre d'insertions par seconde et par table sous la limite de 100 000 et permet aux requêtes portant sur ces données de bien fonctionner.

Chemin à froid

journalisation par chemin à froid

Pour le chemin à froid, les journaux ne nécessitant pas d'analyse en temps quasi réel sont sélectionnés à l'aide d'un récepteur Stackdriver Logging pointé vers un bucket Cloud Storage. Les journaux sont regroupés et écrits dans des fichiers journaux par lots dans Cloud Storage toutes les heures. Ces journaux peuvent ensuite être chargés par lots dans BigQuery à l'aide du processus d'importation de fichiers Cloud Storage standard, qui peut être lancé à l'aide de la console Google Cloud Platform, de l'interface de ligne de commande (CLI) ou même d'un simple script. Le chargement par lots n'a aucune incidence sur l'ingestion en streaming du chemin réactif ni sur les performances des requêtes. Dans la plupart des cas, il est préférable de fusionner les journaux des chemins à froid directement dans les mêmes tables que les journaux de chemin réactif, afin de simplifier le dépannage et la génération de rapports.

Événements d'analyse

Les événements d'analyse peuvent être générés par les services de votre application dans GCP ou envoyés par des clients distants. L'ingestion de ces événements d'analyse via Cloud Pub/Sub, puis leur traitement dans Cloud Dataflow constituent un système à haut débit et à faible temps de latence. Bien qu'il soit possible d'envoyer les événements d'analyse réactifs ou à froid vers deux thèmes distincts de Cloud Pub/Sub, il est conseillé d'envoyer tous les événements vers un thème et de les traiter à l'aide de tâches Cloud Dataflow réactives et à froid distinctes. De cette manière, vous pouvez modifier le chemin d'un événement d'analyse en mettant à jour les tâches Cloud Dataflow, ce qui est plus facile que de déployer une nouvelle version d'application ou de client.

Chemin réactif

événements de chemin réactif

Certains événements nécessitent une analyse immédiate. Par exemple, un événement peut indiquer un comportement client indésirable ou des acteurs incorrects. Il est conseillé de sélectionner ces événements dans Cloud Pub/Sub en utilisant une tâche d'autoscaling Cloud Dataflow, puis de les envoyer directement à BigQuery. Ces données peuvent être partitionnées par la tâche Dataflow pour garantir que la limite de 100 000 lignes par seconde et par table n'est pas atteinte. Cela permet également aux requêtes de bien fonctionner.

Chemin à froid

événements de chemin à froid

Cloud Dataflow peut pousser les événements qui doivent être suivis et analysés sur une base horaire ou quotidienne, mais jamais immédiatement, vers des objets sur Cloud Storage. Les charges peuvent être démarrées depuis Cloud Storage vers BigQuery à l'aide de la console Cloud Platform, de la CLI ou même d'un simple script. Vous pouvez les fusionner dans les mêmes tables que les événements de chemin réactif. À l'instar du chemin à froid de journalisation, les événements d'analyse chargés par lots n'ont aucun impact sur les ressources de requête réservées et permettent de maintenir la charge du chemin d'ingestion en streaming à un niveau raisonnable.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…