Architecture de suivi de pixels sans serveur

Cette solution présente une architecture de suivi de pixels sans serveur pour des cas d'utilisation publicitaires.

En tant qu'annonceur ou agence publicitaire, l'un de vos principaux objectifs consiste à rendre visible votre marque ou celle de vos clients. Pour ce faire, vous pouvez utiliser la publicité en ligne. Si vous faites du bon travail, vos annonces seront diffusées dans des espaces publicitaires appartenant à un éditeur. Cependant, le travail ne s'arrête pas là.

L'un des aspects clés d'une architecture publicitaire consiste à rassembler des données afin d'utiliser au mieux le budget et de comprendre la réaction du public. Dans ce but, vous pouvez utiliser le suivi de pixels. Toutefois, la configuration des serveurs de suivi de pixels implique souvent des frais techniques, tels que la gestion des coûts, la latence, le scaling et la haute disponibilité, pour n'en nommer que quelques-uns. Grâce à cette solution, vous allez apprendre à construire une telle plate-forme tout en limitant les investissements techniques.

La sécurité est toujours un facteur important lorsque vous travaillez avec des données publicitaires. Google Cloud contibue à assurer la sécurité, la protection et la confidentialité de vos données de plusieurs manières. Par exemple, toutes les données sont chiffrées pendant la transmission et au repos. En outre, Google Cloud est conforme aux normes ISO 27001, SOC3, FINRA et PCI.

Pour en savoir plus sur la mise en œuvre de cette solution, vous pouvez suivre le tutoriel.

Concepts

Le processus de suivi de pixels comprend généralement les étapes suivantes :

  1. Un extrait de code est ajouté à la création ou à la page Web pour appeler une URL pointant vers le backend du réseau publicitaire. Exemple :

    <img src=”AD_SERVER_URL?parameters”>
    
  2. Du côté du backend, les serveurs reçoivent la requête, la traitent et renvoient un pixel invisible 1x1. Généralement, ce pixel est créé de façon automatisée. Le renvoi d'un pixel au lieu d'une réponse HTTP 200 ou 304 permet de s'assurer que le navigateur n'affiche pas d'image manquante.

En renvoyant un seul pixel, les exigences de mise en réseau restent assez faibles. Le pixel 1x1 peut facilement être rendu transparent, a peu d'impact sur la mise en réseau et permet d'enregistrer toutes sortes de données, telles que :

  • les paramètres personnalisés, tels que le nom de la page sur laquelle le pixel est affiché ou l'ID utilisateur ;
  • l'environnement basé sur l'utilisateur, tel que le navigateur, l'OS ou le fait que l'annonce s'affiche ou non sur un appareil mobile.

Conditions requises et architecture

Bien que le processus puisse paraître assez simple, il nécessite la mise en place de quelques éléments. Cet exemple repose sur les hypothèses suivantes :

  1. 100 000 impressions en moyenne se produisent chaque seconde, mais le taux d'impressions peut varier.
  2. Les impressions peuvent se produire partout dans le monde.
  3. Toutes les impressions doivent être journalisées, et, une fois ajoutés, ces journaux peuvent représenter plusieurs téraoctets de données par jour.
  4. Tous les journaux peuvent être analysés quotidiennement.

Ces hypothèses impliquent un certain nombre de conditions requises pour la mise en œuvre :

  1. Les capacités doivent pouvoir augmenter et diminuer automatiquement en fonction de la demande.
  2. Une latence en millisecondes dans le monde entier, desservie par un seul domaine, est nécessaire.
  3. Un stockage évolutif pour les journaux avec écritures asynchrones est nécessaire.
  4. Une option de stockage facile à interroger est nécessaire.

Le diagramme suivant montre l'architecture. Notez l'absence de serveurs réels, à la fois pour l'écriture sur la plate-forme d'analyse ou pour la diffusion des pixels.

Architecture de diffusion de pixels sans serveur

Frontends

La première idée qui vient à l'esprit, et qui est généralement mise en œuvre dans le secteur des technologies publicitaires, consisterait à utiliser des serveurs frontend tels que des groupes d'instances Google Compute Engine ou un cluster fédéré Google Kubernetes Engine associé à un autoscaler et qui écrivent leurs journaux dans un stockage d'objets à l'aide d'un agent fluentd. Bien que ces outils soient assez courants, il faudrait que vous configuriez des instances, des modèles, des groupes, des règles de scaling et des scripts de déploiement. Ces opérations peuvent représenter beaucoup de travail.

Cette solution détaille une alternative plus facile à mettre en œuvre, exploitant quelques-uns des produits entièrement gérés de Google Cloud :

  • Google Cloud Storage : stockage d'objets mondial ou régional proposant différentes options (Standard, Nearline et Coldline), ainsi que des prix et des contrats de niveau de service variés en fonction de vos besoins. Dans le cas présent, vous allez utiliser l'option Standard, qui offre une latence en millisecondes faible.
  • Équilibreur de charge HTTP(S) de Google : service global d'équilibrage de charge IP Anycast qui peut s'adapter à des millions de RPS et s'intégrer à Cloud Logging. Google Cloud CDN peut également l'exploiter pour empêcher tout accès inutile à Cloud Storage en mettant en cache le pixel le plus proche de l'utilisateur dans les caches périphériques Google.

L'image suivante montre une configuration d'équilibreur de charge HTTP(S) Google Cloud dans Cloud Console :

L'interface utilisateur affiche la configuration de l'équilibreur de charge HTTP.

Collecte de journaux

L'intégration de l'équilibreur de charge Google Cloud à Cloud Logging facilite considérablement la journalisation de toutes les requêtes dans l'équilibreur de charge, avec une configuration minimale. Les journaux sont enregistrés directement dans les backends Cloud Platform, puis peuvent être exportés dans Cloud Storage, Google Cloud Pub/Sub ou Google BigQuery. Avec cette approche, vous pouvez :

  • surveiller le comportement de votre système à l'aide de Cloud Monitoring, et créer des alertes et des métriques personnalisées ;
  • exporter vos journaux dans différents produits, en fonction de vos besoins :

    • Sauvegarde : exportation dans Cloud Storage ou BigQuery
    • Analyse : exportation dans BigQuery
    • Diffusion en flux pour traitement en temps réel : exportation dans Cloud Pub/Sub

Un journal dans Cloud Logging doit ressembler à l'image suivante, où vous pouvez observer certains éléments :

  • Le pixel a été diffusé à partir du CDN cacheHit: true.
  • Les paramètres d'URL définis dans le code HTML sont visibles.

Le journal Stackdriver affiche les paramètres et le succès de cache.

Cette solution permet d'exporter directement les journaux vers BigQuery à l'aide de l'API de streaming. Il est également possible d'exploiter Google Cloud Dataflow. Pour plus d'informations, consultez la page Étapes suivantes.

Un journal exporté directement dans BigQuery ressemble à l'image suivante, où les colonnes correspondent aux clés des données de type JSON que vous trouvez dans Cloud Logging. Cette image montre une requête qui affiche toutes les données d'un journal spécifique, en fonction du champ insertID créé par Google.

Google BigQuery affiche toutes les données d'un journal.

Analyse des journaux

Une fois vos données chargées dans BigQuery, vous pouvez exécuter des requêtes ad hoc dessus. Voici quelques points à garder à l'esprit :

  • L'utilisation d'une table partitionnée pour chaque jour présente un certain nombre d'avantages, tels que la réduction du nombre d'octets traités par toutes vos requêtes.
  • La scission de vos tables pour chaque groupe d'annonceurs permet également de faciliter la gestion des données, même si cela n'est pas une obligation. Vous pouvez toujours exécuter une union sur ces tables en utilisant des caractères génériques de table.
  • BigQuery est également un excellent outil pour les tâches ETL (Extract, Transform, Load) de base. En fournissant une table de sortie à une requête, vous pouvez traiter les données si nécessaire et les transformer en un format plus présentable. Par exemple, vous pouvez regrouper vos données quotidiennes dans une table hebdomadaire.

L'exemple de code suivant montre un sous-ensemble des champs que vous pouvez trouver dans BigQuery pour chaque impression de pixel. Le paramètre est la liste des paires clé/valeur personnalisées que vous ajoutez et que vous pourrez extraire.

 {
    [...]
    "resource_type": "http_load_balancer",
    "resource_labels_url_map_name": "lb-pixel-tracking",
    "resource_labels_zone": "global",
    "httpRequest_requestMethod": "GET",
    "httpRequest_requestUrl": "YOUR_DOMAIN/pixel.png?YOUR_PARAMETERS",
    "httpRequest_requestSize": "972",
    "httpRequest_status": "200",
    "httpRequest_responseSize": "1320",
    "httpRequest_userAgent": "Go-http-client/1.1",
    "httpRequest_remoteIp": "1.2.3.4",
    "httpRequest_cacheHit": "true",
    [...]
}

Une fois vos données stockées dans BigQuery, vous pouvez commencer à comprendre le comportement des utilisateurs. À l'aide de l'interface utilisateur BigQuery, les analystes disposant de connaissances en SQL peuvent afficher les résultats en quelques secondes, à partir de gigaoctets ou de téraoctets de données.

BigQuery affiche les résultats des requêtes de suivi de pixels.

Tests de charge

Pour vous assurer que cette solution est utilisable en production, vous pouvez configurer un environnement de test de charge distribué basé sur Vegeta. Pour plus de détails, consultez le tutoriel. Comme vous pouvez le voir dans les résultats ci-dessous, cette architecture peut facilement gérer 100 000 RPS.

Graphiques des résultats des tests de charge

Étape suivante

Cette solution présente une architecture de haut niveau pour la diffusion de pixels sans serveur. Pour approfondir l'architecture, vous pouvez exploiter d'autres fonctionnalités de Google Cloud Platform, telles que :

  • DNS : cette solution utilise directement l'adresse IP globale de l'équilibreur de charge, mais vous pouvez également y associer votre nom de domaine en utilisant Google Cloud DNS, par exemple. Un équilibreur de charge peut comporter plusieurs types de backends, tels que Cloud Storage ou Compute Engine.
  • Métriques personnalisées : comme indiqué précédemment, Cloud Logging peut vous servir à créer des métriques personnalisées pouvant être utilisées par Cloud Monitoring pour les alertes ou la surveillance.
  • Google Cloud Bigtable : l'ajout de Cloud Bigtable au pipeline Cloud Dataflow permet à certains de vos serveurs publicitaires d'accéder aux données mises à jour quasiment en temps réel. Bien que Cloud Dataflow puisse toujours charger des données dans BigQuery pour des analyses hors connexion, il peut également écrire sur Bigtable, ce qui offre des lectures à latence à un chiffre lors de l'utilisation de SSD. Cela peut être un bon moyen d'obtenir votre profil utilisateur, par exemple.
  • Google Data Studio : bien que BigQuery propose une interface utilisateur pour exécuter des requêtes SQL, une image vaut parfois mieux qu'un long discours. Data Studio vous permet de visualiser votre analyse à l'aide de tableaux de bord partageables et d'analyses utilisant plusieurs sources de données à la fois.
  • Traitement de journaux : cette solution propose de se concentrer sur l'analyse par lot avec une architecture pouvant évoluer vers des décisions en temps réel. Pour construire une telle architecture, une bonne approche serait d'utiliser :
  • Cloud Pub/Sub : il s'agit d'un système de messagerie mondial entièrement géré. Les éditeurs peuvent publier une quantité énorme de messages dans un sujet via différents clients. Ces messages peuvent ensuite être traités par des nœuds de calcul qui vont les extraire ou les recevoir. Ce système est proposé en tant qu'option lors de l'exportation à partir de Cloud Logging.
  • Cloud Dataflow : il s'agit de l'évolution Google de MapReduce qui offre des fonctionnalités de traitement par lot et par flux sous le même SDK, et qui est Open Source sous Apache Beam. Cloud Dataflow facilite la construction de pipelines avec quelques lignes de code et offre de nombreuses fonctionnalités intéressantes en matière de traitement par flux, notamment les filigranes, les timers et le fenêtrage. Il propose également divers récepteurs, tels que BigQuery (requêtes complètes ad hoc) ou Bigtable (lectures et écritures à faible latence).

    Une telle architecture serait similaire à celle présentée dans le diagramme suivant :

    Architecture avancée

Consulter les tutoriels