Options d'infrastructure pour les charges de travail de diffusion publicitaire (partie 1)

Cet article présente les composants partagés sur différentes plates-formes de technologies publicitaires, y compris les serveurs publicitaires et les enchérisseurs. L'article vous propose des options permettant de mettre en œuvre ces composants.

Les serveurs publicitaires et les enchérisseurs constituent souvent des plates-formes complémentaires dont les technologies se chevauchent. Pour éviter la redondance de contenu, cet article et sa partie 2 fournissent le contexte nécessaire à la compréhension de la série d'articles suivante :

Pour une présentation générale de la série et de la terminologie utilisée, consultez la page Construire des plates-formes publicitaires (présentation).

Considérations relatives à la plate-forme

Lorsque vous utilisez une plate-forme côté achat ou côté vente, veuillez prendre en compte les éléments suivants :

  • Plate-forme de calcul : les plates-formes publicitaires programmatiques comprennent plusieurs services, chaque service offrant une ou plusieurs fonctions. Déterminez le plus tôt possible si vous pouvez intégrer tout ou partie de ces fonctions dans un conteneur ou si le service doit être exécuté directement sur des instances de machine virtuelle (VM).
  • Emplacements géographiques : déployer votre infrastructure au plus près de vos clients et de vos fournisseurs permet de diminuer la latence réseau.
  • Reproductibilité : lorsque vous répliquez un système dans différentes régions du monde, il est important que vous puissiez déployer partout la même infrastructure pour assurer la cohérence sur l'ensemble de la plate-forme.
  • Équilibrage de charge : les charges liées aux technologies publicitaires ne peuvent pas être gérées par une seule machine. Répartissez les requêtes internes et externes sur plusieurs serveurs.
  • Autoscaling : les charges liées aux demandes d'annonces fluctuent au cours de la journée. Vous pouvez réduire les coûts et augmenter la disponibilité en configurant le scaling automatique de votre système.
  • Communication réseau : l'utilisation d'un système distribué soulève des questions de communication. Par exemple, supposons que vous enchérissiez dans l'Oregon aux États-Unis mais que votre base de données de gestion des campagnes se trouve en Europe. Même si la communication consiste en une synchronisation hors connexion, vous ne souhaiterez probablement pas communiquer sur l'Internet public.

Plate-forme de calcul

Google Cloud propose plusieurs options pour exécuter vos charges de travail de calcul, dont voici le détail :

  • App Engine pour exécuter une interface utilisateur Web en éliminant la majorité des coûts opérationnels.
  • Compute Engine pour l'installation et la gestion de bases de données relationnelles ou de codes personnalisés non compatibles avec App Engine.
  • Google Kubernetes Engine (GKE) pour configurer des interfaces sans état ou pour exécuter des applications en conteneurs.

Ces options sont des recommandations et sont souvent interchangeables. Ce sont vos exigences qui vont constituer le facteur décisif, qu'elles s'expriment en termes de coûts, de coûts opérationnels ou de performances.

Compute Engine et GKE sont compatibles avec les VM préemptives, qui sont souvent utilisées pour les charges de travail de technologies publicitaires en vue de réduire les coûts. Les VM préemptives ne peuvent être préemptées qu'avec un avertissement d'une minute. Toutefois, vous pouvez effectuer les opérations suivantes :

  • Si vous utilisez Compute Engine, deux groupes d'instances gérés distincts (l'un préemptif et l'autre avec des VM standards) peuvent résider derrière le même équilibreur de charge. Veillez à ce que l'un des groupes soit constitué de VM standards. Ceci permet à votre interface d'être toujours en mesure de gérer les requêtes entrantes. Le schéma suivant illustre cette approche.

    deux groupes d'instances gérés distincts dans le même équilibreur de charge

  • Si vous utilisez GKE, vous pouvez limiter les coûts en intervenant sur la disponibilité. Pour ce faire, créez des pools de nœuds non préemptifs et préemptifs dans votre cluster GKE.

Emplacements géographiques

Les annonceurs peuvent vouloir cibler des clients dans toutes les régions du monde. L'ajout de quelques millisecondes à l'une des interfaces utilisateur de la plate-forme n'affectera pas l'expérience de vos annonceurs lorsqu'ils visualisent, par exemple, des données de performances. En revanche, une distance réseau supplémentaire qui ajoute quelques millisecondes à la réponse d'enchères nécessite votre attention. Ces quelques millisecondes d'écart peuvent s'avérer décisives pour l'acceptation de l'enchère de l'annonceur et la diffusion de son annonce au client.

Google Cloud est présent dans plusieurs régions, telles que us-east, us-west, europe-west, asia-southeast et asia-east. Chaque région comprend plusieurs zones pour offrir à la fois une disponibilité élevée et des capacités de scaling.

Si la latence est un facteur essentiel, vous devrez peut-être répartir certains de vos services entre ces zones dans différentes régions. Vous pouvez personnaliser la configuration en fonction de vos besoins. Par exemple, vous pouvez disposer de serveurs frontend dans les régions us-east4 et us-west1, mais stocker des données dans une base de données située dans la région us-central. Dans certains cas, vous pouvez répliquer une partie des données de la base de données localement sur les serveurs frontend. Sinon, vous pouvez utiliser une instance Cloud Spanner multirégionale.

Reproductibilité

La reproductibilité simplifie la maintenance et le déploiement. Il est essentiel de pouvoir exécuter la plate-forme dans tous les emplacements géographiques pertinents pour renvoyer les offres avant la date limite critique. Pour assurer la reproductibilité, chaque région doit fonctionner de façon similaire. La principale différence réside dans la charge de travail, et le nombre de machines et de zones nécessaires pour s'adapter à la demande régionale.

Avec Compute Engine, les modèles d'instance constituent la base permettant de configurer des groupes d'instances gérés régionaux similaires. Ces groupes peuvent se trouver dans différentes régions à proximité des plates-formes SSP et sur plusieurs zones afin d'assurer une haute disponibilité. Le schéma suivant illustre ce processus.

Configurer des groupes d'instances gérés régionaux à l'aide d'un modèle d'instance

Les conteneurs offrent un niveau d'abstraction plus élevé que la virtualisation de machine. Kubernetes facilite la reproductibilité des applications de manière native grâce aux fichiers de configuration YAML. Ceux-ci permettent de définir des pods, des services et des déploiements de manière cohérente sur différents clusters.

Équilibrage de charge

Les deux scénarios principaux suivants nécessitent un équilibrage de charge :

Si vous décidez d'utiliser Kubernetes pour certaines parties de l'infrastructure, nous vous recommandons d'opter pour GKE. Certaines fonctionnalités de Kubernetes peuvent nécessiter une mise en œuvre supplémentaire si votre fournisseur ne les accepte pas de manière native. Avec GKE, Kubernetes peut utiliser les fonctionnalités natives de Google Cloud :

GKE est également compatible avec l'équilibrage de charge natif en conteneurs afin de réduire les délais de mise en réseau et les éventuels sauts de réseau supplémentaires. En règle générale, l'équilibreur de charge empêche le routage d'une requête vers une instance qui n'héberge pas de pod du service demandé.

Scaling

Comme votre plate-forme doit pouvoir analyser et calculer des milliards de demandes d'annonces par jour, l'équilibrage de charge est indispensable. En outre, une seule machine ne suffirait pas à l'exécution de cette tâche. Toutefois, le nombre de requêtes a tendance à fluctuer tout au long de la journée, ce qui signifie que votre infrastructure doit pouvoir évoluer en fonction de la demande.

Si vous décidez d'utiliser Compute Engine, vous pouvez créer des groupes d'instances gérés pour l'autoscaling à partir de modèles d'instance. Vous pouvez ensuite faire évoluer ces groupes en fonction de différentes métriques, telles que la charge HTTP, l'utilisation du processeur et des métriques personnalisées Cloud Monitoring, comme la latence des applications. Vous pouvez également utiliser une combinaison de ces métriques.

Les décisions d'autoscaling sont basées sur la moyenne des métriques durant les dix dernières minutes. Elles s'effectuent chaque minute à l'aide d'une fenêtre glissante. Chaque groupe d'instances peut posséder son propre ensemble de règles de scaling.

Si vous décidez d'utiliser GKE, l'autoscaler de cluster de Kubernetes, vous pouvez le mettre en œuvre de manière native à l'aide de l'autoscaler de cluster GKE. L'autoscaler de cluster GKE se comporte différemment de l'autoscaler de cluster Compute Engine. Il génère des nœuds lorsque de nouveaux pods ne peuvent plus être planifiés sur les nœuds existants en raison d'un manque de processeur ou de mémoire sur les nœuds sous-jacents. La réduction de capacité s'effectue automatiquement lorsque le processeur ou la mémoire sont de nouveau disponibles.

Communications réseau

Les clouds privés virtuels (VPC) peuvent s'étendre sur plusieurs régions. En d'autres termes, si vous disposez d'instances dupliquées de base de données avec accès en lecture dans la région us-east, et d'une base de données maître dans la région asia-southeast au sein du même VPC, ces dernières peuvent communiquer en toute sécurité à l'aide de leurs adresses IP ou noms d'hôte privés, sans jamais quitter le réseau Google.

Dans le schéma suivant, toutes les instances se trouvent dans le même VPC. Elles peuvent communiquer directement sans passer par un réseau privé virtuel, même si elles se trouvent dans des régions différentes.

Toutes les instances sont situées sur le même VPC et dans des régions différentes

Les clusters GKE se voient attribuer un VPC lors de leur création et peuvent utiliser bon nombre de ces fonctionnalités réseau existantes.

Google propose également deux types d'infrastructure réseau :

  • Premium : utilise le réseau privé mondial de Google. Privilégiez cette option pour les charges de travail critiques telles que la réplication de bases de données interrégionale.
  • Standard : privilégiez cette option si vous souhaitez faire des économies et que vous pouvez utiliser l'Internet public.

Lorsque vous utilisez des produits gérés tels que Cloud Bigtable, Cloud Storage ou BigQuery, Google Cloud fournit un accès privé à ces produits via le VPC.

Interface utilisateur

Votre interface utilisateur est importante, mais elle implique des coûts techniques moindres, car elle gère des charges de travail beaucoup plus réduites. Elle offre aux utilisateurs de la plate-forme la possibilité d'administrer des ressources publicitaires, telles que des campagnes, des créations, des factures ou des enchères. L'interface permet également d'interagir avec des outils de création de rapports, par exemple pour contrôler les performances des campagnes ou des annonces.

Ces deux fonctionnalités nécessitent que les serveurs Web fournissent une interface utilisateur à l'utilisateur de la plate-forme, et que les datastores stockent des données transactionnelles ou analytiques.

Diffusion Web

Votre interface publicitaire doit pouvoir :

  • offrir une haute disponibilité ;
  • traiter des centaines de requêtes par seconde ;
  • être disponible dans le monde entier avec une latence acceptable afin d'offrir une bonne expérience utilisateur ;
  • fournir une interface utilisateur.

L'interface comprend généralement des fonctionnalités telles qu'un tableau de bord et des pages permettant de configurer les annonceurs, les campagnes et leurs composants associés. La conception de l'interface utilisateur elle-même est une discipline distincte qui dépasse le cadre de cet article.

Afin de minimiser les coûts techniques, nous vous recommandons d'utiliser App Engine comme plate-forme d'interface. Ceci vous permettra de réduire le temps consacré à la gestion de l'infrastructure de votre site Web. Envisagez d'utiliser des environnements d'exécution personnalisés si besoin. Vous pouvez également utiliser GKE ou Compute Engine si votre pile d'applications préférée présente d'autres exigences.

Datastores

Les interfaces utilisateur comportent deux types de datastores :

Traiter des requêtes

Interfaces

Les requêtes sont envoyées vers un point de terminaison HTTP(S) fourni par votre plate-forme pour y être traitées. Les composants clés sont les suivants :

  • Un équilibreur de charge capable de traiter plusieurs centaines de milliers de RPS (requêtes par seconde).
  • Un pool d'instances pouvant évoluer rapidement en fonction de plusieurs KPI (indicateurs clés de performance).
  • Une API éventuelle qui contrôle et/ou authentifie le point de terminaison.

Compute Engine et GKE représentent de bonnes options en tant que plates-formes de calcul :

  • Compute Engine utilise Cloud Load Balancing et les groupes d'instances gérés mentionnés dans la section sur le scaling.
  • GKE utilise Cloud Load Balancing et un Ingress (ou la passerelle d'entrée Istio), l'autoscaler horizontal de pods et l'autoscaler de cluster.

Étant donné que le scaling des pods est plus rapide que celui des nœuds, GKE peut offrir une fonctionnalité d'autoscaling plus rapide en fonction du niveau du service. GKE est également compatible avec l'équilibrage de charge natif en conteneurs afin d'optimiser le routage des requêtes directement vers une instance qui héberge un pod du service correspondant.

La limitation et l'authentification peuvent se gérer à l'aide de technologies telles qu'Apigee ou la plate-forme Service Infrastructure.

Analyse

Les demandes d'annonce sont généralement au format JSON ou protobuf et contiennent des informations telles que l'adresse IP, l'agent utilisateur ou la catégorie de site. Il est essentiel d'extraire ces données, qui peuvent également contenir des informations détaillées sur l'utilisateur (unique), puis d'en récupérer des segments pour sélectionner et filtrer les annonces.

Filtrage statique

Certaines demandes, généralement reçues côté acheteur, peuvent être rejetées à l'aide de règles statiques. Un filtrage anticipé de ce type permet de réduire la quantité de données ainsi que le traitement complexe qu'elles nécessitent en aval.

Les règles peuvent être des listes noires d'éditeurs ou une exclusion de type de contenu. Lors de l'initialisation, les nœuds de calcul peuvent extraire et charger ces règles à partir d'un fichier hébergé sur Cloud Storage.

Sélection des annonces

La sélection des annonces peut s'effectuer dans différents services ou plates-formes, tels que le serveur publicitaire de l'éditeur, le serveur publicitaire de l'annonceur ou la DSP. Il existe différents niveaux de complexité lors de la sélection d'une annonce :

  • Certaines sélections peuvent s'avérer aussi simples que celle d'une annonce pour une catégorie spécifique du site Web ou de la page de l'éditeur. Dans ce cas, les prix restent identiques pour chaque annonce.
  • Des sélections plus avancées intègrent les attributs et les segments des utilisateurs, et impliquent éventuellement des systèmes de recommandation d'annonces basés sur le machine learning.
  • Les systèmes d'enchères RTB prennent généralement les décisions les plus complexes. Les annonces sont sélectionnées en fonction d'attributs tels que les segments d'utilisateurs (uniques) et les prix des enchères précédentes. La sélection inclut également un calcul de l'enchère afin d'optimiser son prix par demande.

La fonction principale de votre système est de choisir l'annonce la plus pertinente. Vous devez prendre en compte de nombreux facteurs, tels que des algorithmes avancés basés sur des règles ou des algorithmes de sélection ML. Toutefois, cet article se concentre sur le processus de haut niveau et sur les interactions avec les différents datastores.

Le processus de sélection des annonces comprend les étapes suivantes :

  1. Récupérer les segments associés à l'utilisateur ciblé à partir du magasin de profils utilisateur (uniques).
  2. Sélectionner les campagnes ou les annonces qui correspondent le mieux aux segments de l'utilisateur. Cette sélection requiert la lecture de métadonnées à partir du magasin de gestion des métadonnées. C'est pourquoi ce magasin nécessite la mise en œuvre de l'un des modèles de stockage à lecture intensive.
  3. Filtrer les campagnes ou les annonces sélectionnées en conformité avec les métriques, par exemple le budget restant, stocké dans l'un des magasins de contexte.
  4. Sélectionner l'annonce.

Les étapes liées aux enchères et mises aux enchères côté enchérisseur sont plus nombreuses, et les exigences de latence y sont plus strictes. Pour plus d'informations sur les exigences appliquées à l'enchérisseur lors de la sélection de l'annonce, consultez la page Options d'infrastructure pour les enchères RTB (partie 4).

Modèles de stockage à lecture intensive

La plupart des décisions prises lors de la sélection d'une annonce nécessitent des données intelligentes qui :

  • sont lues en millisecondes, parfois en sous-millisecondes ;
  • sont écrites dès que possible, en particulier pour les compteurs sensibles au facteur temps ;
  • sont souvent écrites dans le cadre d'un processus hors connexion utilisant des tâches d'analyse ou de machine learning en arrière-plan.

La manière dont vous choisissez votre datastore dépend de la priorité que vous accordez aux exigences suivantes :

  • Réduction des latences de lecture ou d'écriture : si la latence est un facteur essentiel, vous avez besoin d'un magasin proche de vos serveurs et capable de gérer des lectures ou des écritures rapides à grande échelle.
  • Réduction des coûts opérationnels : si vous avez une petite équipe d'ingénieurs, vous aurez peut-être besoin d'une base de données entièrement gérée.
  • Scaling : pour pouvoir gérer des millions d'utilisateurs ciblés ou des milliards d'événements par jour, le datastore doit effectuer un scaling horizontal.
  • Adaptation du style de requête : certaines requêtes peuvent utiliser une clé spécifique, tandis que d'autres peuvent avoir besoin de récupérer des enregistrements répondant à un ensemble de conditions différent. Dans certains cas, les données de la requête peuvent être encodées dans la clé. Dans d'autres cas, les requêtes peuvent avoir besoin de capacités de type SQL.
  • Optimisation de l'actualisation des données : certains compteurs, tels que le budget, doivent être mis à jour le plus rapidement possible. D'autres données telles que le segment d'audience ou des compteurs (par exemple, les limites quotidiennes) peuvent être mises à jour plus tard.
  • Réduction des coûts : il n'est pas toujours économique ni pratique d'utiliser une seule base de données pour gérer chaque jour des milliards de lectures et d'écritures avec une grande cohérence à l'échelle mondiale, et ce dans le but de réduire les DevOps.

Il existe différentes options permettant de répondre aux exigences de lecture intensive. Celles-ci incluent les instances dupliquées avec accès en lecture, les systèmes de mise en cache, les bases de données NoSQL en mémoire et les bases de données NoSQL gérées orientées colonnes.

Instances dupliquées avec accès en lecture des systèmes SGBDR

Lorsque vous utilisez Cloud SQL (ou un SGBDR équivalent, installé et géré sur Compute Engine), vous pouvez décharger les lectures de l'instance maître. De nombreuses bases de données offrent une compatibilité native avec cette fonctionnalité. Les nœuds de calcul peuvent demander les informations nécessaires de différentes manières :

  • Ils utilisent des instances dupliquées avec accès en lecture correspondant au nombre de nœuds de calcul.
  • Ils utilisent un proxy de pooling.

Le schéma suivant illustre ce processus.

Base de données où les lectures sont déchargées de l'instance maître

Les instances dupliquées avec accès en lecture sont conçues pour diffuser du trafic à lecture intensive, mais l'évolutivité n'est pas linéaire et les performances peuvent pâtir d'un plus grand nombre d'instances dupliquées. Si vous avez besoin de lectures ou d'écritures évolutives, avec une cohérence globale et des coûts opérationnels minimes, envisagez d'utiliser Cloud Spanner.

Couche de mise en cache locale

Vous pouvez utiliser une couche de mise en cache telle que Redis sur Compute Engine avec des instances dupliquées locales facultatives sur les nœuds de calcul. Cette couche peut considérablement réduire la latence associée à la lecture et à la mise en réseau. Le schéma suivant illustre cette couche.

Minimiser la latence en exploitant une couche de mise en cache

Si vous décidez d'utiliser Kubernetes dans cette situation, vérifiez le DaemonSet et l'affinité pour vous assurer que :

  • vous limitez la quantité de données répliquées ;
  • les données restent proches d'un pod de diffusion.

Bases de données NoSQL en mémoire orientées valeur/clé

Déployez une base de données en mémoire, comme Aerospike ou Redis, pour fournir des lectures rapides à grande échelle. Cette solution peut s'avérer utile pour les données et les compteurs régionaux. Si vous êtes préoccupé par la taille des structures de données stockées, vous pouvez également exploiter des bases de données en mémoire capables d'écrire sur des disques SSD. Le schéma suivant illustre cette solution.

Une base de données en mémoire capable d'écrire sur des disques SSD

Bases de données NoSQL gérées orientées colonnes

Les datastores orientés colonnes sont des espaces de stockage par valeur/clé capables de fournir des lectures et des écritures rapides à grande échelle. Vous pouvez installer une base de données Open Source courante telle que Cassandra ou HBase.

Si vous optez pour un stockage de ce type, nous vous recommandons d'utiliser Cloud Bigtable afin de minimiser les coûts opérationnels. Ces systèmes de stockage vous permettent de faire évoluer vos opérations d'entrée/sortie (IOP) de manière linéaire suivant le nombre de nœuds. En concevant la clé de manière appropriée, les opérations de lecture du sélecteur d'annonces et les opérations d'écriture du pipeline de données peuvent atteindre une vitesse de l'ordre de la milliseconde au premier octet sur des pétaoctets de données. Le schéma suivant illustre ce processus.

Datastores orientés colonnes

Stockage d'objets statiques

Pour les données statiques pouvant être enregistrées au format protobuf, AVRO ou JSON, les nœuds de calcul peuvent se charger à partir de Cloud Storage lors de l'initialisation, et conserver le contenu en mémoire RAM. Le schéma suivant illustre ce processus.

Charger des données depuis Cloud Storage

Il n'existe pas de solution universelle. Choisissez une solution en fonction de vos priorités, et tentez de trouver un équilibre entre la latence, les coûts, les opérations, les performances de lecture/écriture et la taille des données.

Solution Latence Coût Coûts opérationnels Performances de lecture/écriture Taille des données
Instances dupliquées avec accès en lecture des systèmes SGBDR Millisecondes En fonction du service ou du calcul Élevés Limitées Limitée
Cloud Spanner Millisecondes En fonction du service Faibles Scaling linéaire suivant le nombre de nœuds Pétaoctets
Systèmes de stockage en mémoire Sous-milliseconde En fonction du calcul Élevés Scaling suivant le nombre de nœuds Scaling suivant le nombre de nœuds
Cloud Bigtable De l'ordre de la milliseconde En fonction du service Faibles Scaling linéaire suivant le nombre de nœuds Pétaoctets

Datastores publicitaires

Cette section couvre les options de stockage de données répondant aux besoins de l'un des trois scénarios suivants :

  • Les magasins de diffusion d'annonces sont utilisés par les services concernés par la sélection d'annonces. La diffusion de charges de travail nécessite une faible latence et la capacité de gérer des milliards de lectures par jour. La taille des données dépend du type de données.
  • Les magasins analytiques s'utilisent hors connexion via des requêtes ad hoc ou des pipelines de données par lots. Ils peuvent stocker des centaines de téraoctets de données quotidiennement.
  • Les magasins de création de rapports/tableaux de bord peuvent être utilisés pour des tableaux de bord prédéfinis, des séries temporelles ou des rapports personnalisés. Ces options permettent de différencier votre interface, pour que les utilisateurs de votre plate-forme puissent obtenir rapidement des informations et visualiser les performances de leur entreprise.

Les magasins de diffusion d'annonces peuvent ensuite se diviser comme suit :

  • Le magasin de gestion des métadonnées, qui est utilisé lors de la sélection de campagnes et d'annonces pertinentes. L'interface utilisateur génère et met à jour les données. Ces données ont besoin de persistance.
  • Le magasin de profils utilisateur (uniques), qui est utilisé lors du profilage de l'utilisateur (unique) afin de le faire correspondre à une annonce. Les données sont principalement mises à jour à l'aide d'événements (partie 2). Ces données ont besoin de persistance.
  • Le magasin de contexte de diffusion, qui sert à filtrer les annonces et les campagnes en fonction de plusieurs compteurs, tels que les limites liées au budget ou au nombre d'expositions. Les données sont mises à jour à l'aide d'événements. Ces données sont fréquemment écrasées.

Magasin de gestion des métadonnées

Le magasin de gestion des métadonnées contient les données de référence auxquelles vous appliquez des règles lors de la sélection d'annonces. Certaines ressources stockées ici sont spécifiques à une plate-forme, mais d'autres peuvent se chevaucher :

  • Pour un serveur publicitaire côté vente, les éditeurs gèrent les données relatives aux campagnes, aux créations, aux annonceurs, aux espaces publicitaires et aux prix. Certaines interfaces peuvent également accorder l'accès à leurs acheteurs.
  • Pour un serveur publicitaire côté achat, les acheteurs gèrent les données relatives aux campagnes, aux créations, aux annonceurs et aux prix. Les annonceurs peuvent régulièrement mettre à jour ces données via une interface utilisateur.
  • Pour une plate-forme DSP, les acheteurs gèrent les données relatives aux campagnes, aux créations, aux annonceurs et aux prix des enchères. Les annonceurs peuvent régulièrement mettre à jour ces données via une interface utilisateur.

Le magasin des métadonnées contient des données semi-statiques relationnelles ou hiérarchiques :

  • Les écritures sont le résultat des modifications apportées par les utilisateurs de la plate-forme via l'interface. Elles se produisent rarement.
  • Les données sont lues des milliards de fois par jour par les serveurs de sélection d'annonces.

Du côté de l'interface utilisateur, la base de données des métadonnées relatives aux campagnes doit pouvoir gérer les relations et les hiérarchies des ressources et stocker plusieurs mégaoctets de données, voire même quelques gigaoctets. La base de données doit également permettre des lectures et des écritures à hauteur de plusieurs centaines de requêtes par seconde. Pour répondre à ces exigences, Google Cloud propose plusieurs options de base de données, à la fois gérées et non gérées :

  • Cloud SQL : service de base de données entièrement géré pouvant exécuter MySQL ou PostgreSQL.
  • Datastore : service de base de données NoSQL hautement évolutif, géré et distribué. Il est compatible avec les transactions ACID, fournit un langage de requête de type SQL et présente des niveaux de cohérence à terme et élevés.
  • Spanner : base de données relationnelle à scaling horizontal offrant des lectures intensives et cohérentes, des transactions mondiales et des réplications interrégionales. Elle peut également gérer des lectures et écritures intensives.
  • Personnalisée : vous pouvez également installer et gérer de nombreuses bases de données propriétaires ou Open Source (telles que MySQL, PostgreSQL, MongoDB ou Couchbase) sur Compute Engine ou GKE.

Vos exigences peuvent vous aider à déterminer l'option la plus adaptée. Toutefois, à un niveau élevé, vous pouvez utiliser Cloud SQL, car ce service est compatible avec les données relationnelles. Cloud SQL est également un service géré qui fournit des options d'instances dupliquées avec accès en lecture.

Comme indiqué précédemment, le magasin des métadonnées est utilisé non seulement par les utilisateurs de la plate-forme pour la création de rapports ou l'administration, mais également par les serveurs qui sélectionnent les annonces. Ces lectures se produisent des milliards de fois par jour. Vous pouvez aborder ces exigences de lecture intensive de deux manières :

  • En utilisant une base de données capable de gérer des écritures cohérentes à l'échelle mondiale et des milliards de lectures par jour, telle que Spanner.
  • En dissociant les lectures et les écritures. Cette approche est possible parce que les métadonnées ne sont pas souvent modifiées. Vous pouvez obtenir plus d'informations dans la partie relative aux exportations (dans la partie 2).

Magasin de profils utilisateur (uniques)

Ce magasin contient des utilisateurs (uniques) et les informations qui leur sont associées. Celles-ci fournissent des insights essentiels pour sélectionner une campagne ou une annonce à la demande. Les informations peuvent inclure les attributs de l'utilisateur (uniques), vos propres segments ou des segments importés depuis des tierces parties. Dans le contexte des enchères RTB, les segments importés incluent souvent des recommandations de prix d'enchères.

Ce datastore doit pouvoir stocker des centaines de gigaoctets, voire des téraoctets de données. Le datastore doit également être en mesure de récupérer des enregistrements uniques dans un délai maximal de l'ordre de la milliseconde. La quantité de données que vous stockez dépend de la précision de vos informations utilisateur (uniques). Vous devriez pouvoir récupérer au moins une liste de segments pour l'utilisateur ciblé.

Le magasin est mis à jour fréquemment en fonction des interactions des utilisateurs (uniques) avec les annonces, des sites qu'ils visitent ou des actions qu'ils entreprennent. Plus il y a d'informations, plus le ciblage est précis. Vous pouvez également utiliser des plates-formes de gestion de données tierces pour enrichir vos données propriétaires.

Cloud Bigtable ou Datastore sont des bases de données couramment utilisées pour les données utilisateur (uniques). Ces deux bases de données sont parfaitement adaptées aux lectures et écritures aléatoires d'enregistrements uniques. N'utilisez Cloud Bigtable que si vous disposez d'au moins plusieurs centaines de gigaoctets de données.

D'autres bases de données courantes telles que MongoDB, Couchbase, Cassandra ou Aerospike peuvent également être installées sur Compute Engine ou sur GKE. Bien que ces bases de données nécessitent souvent davantage de gestion, certaines peuvent offrir plus de flexibilité, avec éventuellement une latence plus faible et, dans certains cas, une réplication interrégionale.

Pour en savoir plus, consultez la section sur la correspondance utilisateur (dans la partie 4).

Magasins de contexte

Le magasin de contexte sert souvent à stocker des compteurs, par exemple des limites de fréquence et de budget restant. La fréquence d'actualisation des données dans le magasin de contexte varie. Par exemple, une limite quotidienne peut être propagée quotidiennement, alors que le budget de la campagne restant nécessite d'être recalculé et propagé le plus rapidement possible.

Selon le modèle de stockage que vous choisissez, les compteurs que vous mettez à jour et les capacités de la base de données choisie, vous pouvez écrire directement dans la base de données. Vous pouvez également dissocier la mise en œuvre à l'aide d'un modèle publish/subscribe avec un système de messagerie, tel que Cloud Pub/Sub, pour mettre à jour le magasin après le calcul.

Les modèles suivants sont parfaitement adaptés aux magasins de contexte :

  • Cloud Bigtable
  • Le modèle NoSQL régional en mémoire orienté valeur/clé
  • Le modèle de mise en cache régional

Grâce au scaling horizontal, ces magasins peuvent gérer les écritures et les lectures à grande échelle. Les pages Options d'infrastructure pour les serveurs publicitaires (partie 3) et Options d'infrastructure pour les enchères RTB (partie 4) décrivent de manière plus détaillée certaines de ces options.

Exemple de gestion d'un compteur de budget dans un environnement distribué

Vous définissez des budgets dans l'outil de gestion de campagne. Vous souhaitez éviter les dépassements de budget pour vos campagnes, car la plupart du temps, les annonceurs ne paient pas ces impressions supplémentaires. Toutefois, dans un environnement distribué, il peut être difficile d'agréger des compteurs comme le budget restant, en particulier lorsque le système peut recevoir des centaines de milliers de demandes d'annonces par seconde. Les campagnes peuvent rapidement dépasser leur budget en quelques secondes si le budget global restant n'est pas consolidé rapidement.

Par défaut, un nœud de calcul dépense une partie du budget sans savoir ce qu'ont dépensé ses nœuds de calcul frères. Ce manque de communication peut conduire à une situation dans laquelle le nœud de calcul dépense une somme qui n'est plus disponible.

Ce problème peut être réglé de différentes façons. Les options ci-dessous mettent toutes deux en œuvre un gestionnaire de budget global, mais chacune adopte un comportement différent.

  1. Notifier les nœuds de calcul de l'épuisement du budget : le gestionnaire de budget suit les dépenses et envoie des notifications à chacun des nœuds de calcul lorsque le budget de la campagne est épuisé. En raison de la probabilité de niveaux élevés de requêtes par seconde, les notifications doivent être envoyées en une seconde afin de limiter rapidement les dépassements de budget. Le schéma suivant illustre le fonctionnement de ce processus.

    Notification concernant l'épuisement du budget

  2. Allouer de manière récurrente des parties du budget à chaque nœud de calcul : le gestionnaire de budget divise le budget restant global en montants plus petits, qui sont alloués à chaque nœud de calcul individuellement. Les nœuds de calcul dépensent leur propre budget local. Une fois celui-ci épuisé, ils peuvent en demander davantage. Cette option présente les avantages suivants :

    1. Les nœuds de calcul doivent attendre que le gestionnaire de budget leur alloue un nouveau montant avant toute nouvelle dépense. Cette approche évite les dépassements de budget, même si certains nœuds de calcul restent inactifs pendant un certain temps.
    2. Le gestionnaire de budget peut adapter le montant alloué envoyé à chaque nœud de calcul en fonction de son comportement de dépenses à chaque cycle. Le schéma suivant illustre ce processus.

      Le gestionnaire de budget alloue un budget à chaque nœud

Quelle que soit l'option choisie, les compteurs de budget sont calculés en fonction du modèle de tarification convenu entre l'éditeur et l'annonceur. Il existe plusieurs cas de figure :

  • Si le modèle prévoit une facturation sur la base du CPM, une impression facturable envoie un événement au système qui réduit le budget restant en fonction du prix défini pour mille impressions.
  • Si le modèle prévoit une facturation sur la base du CPC, un clic utilisateur envoie un événement au système, qui diminue le budget restant en fonction du prix défini par clic.
  • Si le modèle prévoit une facturation sur la base du CPA, un pixel de suivi placé sur la propriété de l'annonceur envoie un événement au système, qui diminue le budget en fonction du prix par action.

Le nombre d'impressions est souvent supérieur au nombre de clics, de plusieurs ordres de grandeur. Le nombre de clics est quant à lui souvent supérieur à la conversion, de plusieurs ordres de grandeur. L'ingestion de ces événements nécessite une infrastructure de traitement des événements évolutive. Cette approche est discutée plus en détail dans l'article sur le pipeline de données.

Magasin analytique

Le magasin analytique est une base de données permettant le stockage et le traitement hors connexion de téraoctets de données ingérées quotidiennement. Il ne s'agit donc pas d'un traitement en temps réel. Exemple :

  • Les données utilisateur (uniques) sont traitées hors connexion pour identifier les segments associés, qui sont à leur tour copiés dans des bases de données plus rapides, comme la base de données de profils utilisateur, à des fins de diffusion. Ce processus est expliqué dans la section relative aux exportations.
  • Les requêtes sont fusionnées avec les impressions et les actions utilisateur (uniques) afin d'agréger les compteurs hors connexion utilisés dans un magasin de contexte.

Magasin de création de rapports/tableaux de bord

Le magasin de création de rapports/tableaux de bord est utilisé dans l'interface utilisateur et fournit des informations sur les performances des campagnes ou des inventaires. Il existe différents types de rapports. Vous pouvez tous les proposer ou seulement quelques-uns, y compris des fonctionnalités d'analyse personnalisées et des tableaux de bord semi-statiques, dont la mise à jour est effectuée à intervalles de quelques secondes ou en temps réel.

Vous pouvez tirer parti des fonctionnalités d'analyse de BigQuery. Si vous utilisez des vues pour limiter l'accès aux données, et que vous les partagez en conséquence avec vos clients, vous pouvez attribuer aux utilisateurs de votre plate-forme des capacités d'analyse ad hoc via votre propre interface utilisateur ou leurs propres outils de visualisation. Toutes les entreprises n'offrent pas cette option, mais il s'agit d'un véritable plus à proposer à vos clients. Pensez à utiliser des tarifs forfaitaires pour ce cas d'utilisation.

Si vous souhaitez proposer à vos clients des fonctionnalités OLAP avec une latence allant de l'ordre de la milliseconde à la seconde, envisagez d'utiliser une base de données devant BigQuery. Vous pouvez regrouper des données à des fins de création de rapports et les exporter depuis BigQuery vers la base de données de votre choix. Les bases de données relationnelles, comme celles compatibles avec Cloud SQL, sont souvent utilisées dans ce contexte.

Étant donné qu'App Engine, ou toute autre interface qui agit pour le compte de l'utilisateur, se sert d'un compte de service, BigQuery considère que les requêtes proviennent d'un seul utilisateur. En conséquence, BigQuery peut mettre en cache certaines requêtes et renvoyer plus rapidement les résultats précédemment calculés.

Les tableaux de bord semi-statiques sont également couramment utilisés. Ces tableaux de bord utilisent des KPI pré-agrégés qui sont écrits par un processus de pipeline de données. Les magasins sont la plupart du temps basés sur le modèle NoSQL, comme Firestore pour faciliter les mises à jour en temps réel, ou Memorystore pour la mise en cache des couches. L'actualisation des données dépend généralement de la fréquence des mises à jour et de l'étendue de la fenêtre utilisée pour agréger vos données.

Étapes suivantes