Votre plateforme publicitaire ne tient pas les pics de trafic ? Quoi corriger d'abord et qui peut aider

Si votre plateforme publicitaire lâche aux pics de trafic, les ingénieurs qui peuvent vous aider sont ceux qui la mesurent pendant un vrai pic, puis la corrigent dans un ordre établi. Ils arrêtent le travail qui finira après l'échéance, limitent les retries et le trafic que la plateforme accepte, et sortent les compteurs de budget et de fréquence du chemin de la requête. Ensuite, ils ajoutent de la capacité avant les pics prévisibles. Le code est réécrit en dernier, et seulement là où les mesures le désignent.

Que veut dire concrètement « ne pas tenir les pics de trafic » pour une plateforme publicitaire ?

Un pic de trafic ne produit pas les mêmes symptômes dans chaque partie d'une plateforme publicitaire :

• Bidder. Davantage de réponses arrivent après l'échéance de l'ad exchange, le taux de bid baisse alors que le volume de requêtes augmente, et l'ad exchange peut commencer à envoyer moins de requêtes
• Supply-side platform (SSP) ou ad exchange. Les enchères se clôturent avant que certains bidders ne répondent, et moins de bids se disputent chaque impression. En header bidding, les bids qui manquent le timeout d'enchère de la page sont exclus de l'appel à l'ad server
• Ad server. Les appels publicitaires ralentissent et certains emplacements s'affichent vides
• Pipeline d'événements. Les décomptes d'impressions et de clics arrivent en retard ou divergent d'un système à l'autre
• Budgets et plafonds de fréquence. Les campagnes dépassent leur budget ou diffusent trop souvent la même publicité, parce que les compteurs se mettent à jour après les décisions qui auraient dû les lire

Les timeouts et les emplacements vides apparaissent pendant le pic. Les problèmes d'événements et de budget peuvent rester cachés jusqu'à ce que les événements retardés arrivent dans les rapports et la facturation.

Pourquoi une plateforme publicitaire casse-t-elle au pic alors qu'elle tourne bien en charge moyenne ?

Dans OpenRTB, le protocole de real-time bidding de l'IAB Tech Lab, l'ad exchange peut indiquer l'échéance dans la requête elle-même : le « temps maximum en millisecondes que l'ad exchange accorde pour recevoir les bids, latence Internet incluse, afin d'éviter un timeout ». La documentation Authorized Buyers de Google indique que l'échéance va généralement de 80 à 1 000 ms. Google exige que 85 % des réponses arrivent dans ce délai, vu depuis le trading location, et bride les bidders qui n'y parviennent pas de façon constante. Un bidder qui ralentit au pic perd les enchères auxquelles il répond en retard, et peut ensuite recevoir moins de trafic.

Près de sa capacité maximale, un service commence à mettre les requêtes en file d'attente. Le livre Site Reliability Engineering (SRE) de Google note que « les requêtes en file d'attente consomment de la mémoire et augmentent la latence », et que les serveurs dépensent des ressources pour des requêtes qui manqueront de toute façon leur échéance. Si le code ne vérifie pas l'échéance, une requête qui a trop attendu est quand même traitée en entier, et sa réponse est jetée.

Quand un appel à une base de données, à un cache ou à un partenaire tombe en timeout, l'appelant réessaie, et les retries arrivent au moment où le système peut le moins les absorber. Le livre SRE donne l'arithmétique d'une tempête de retries : « 100 QPS de retries dans la première seconde mènent à 200 QPS, puis à 300 QPS, et ainsi de suite. »

Un ad exchange ou un SSP envoie chaque requête à de nombreux bidders, et l'enchère doit soit attendre la réponse la plus lente, soit se clôturer sans elle. Jeffrey Dean et Luiz André Barroso, de Google, ont chiffré ce phénomène dans Communications of the ACM en 2013. Dans leur exemple, chaque serveur répond habituellement en 10 ms, mais met une seconde sur une requête sur cent. Une requête qui doit recueillir en parallèle les réponses de 100 serveurs de ce type prend alors plus d'une seconde dans 63 % des cas. Une enchère n'attend pas aussi longtemps. Selon le même calcul, si chacun de 100 bidders est en retard sur une requête sur cent, environ 63 % des enchères se clôturent avec au moins une réponse manquante.

Un autoscaling qui réagit à la charge n'ajoute des copies d'un service qu'après avoir mesuré cette charge. Le Horizontal Pod Autoscaler de Kubernetes, par exemple, vérifie la charge toutes les 15 secondes par défaut et ajoute de nouvelles copies par paliers limités. Chaque nouvelle copie doit ensuite démarrer, passer ses vérifications et remplir ses caches, et le livre SRE note que les processus sont souvent plus lents juste après leur démarrage qu'en régime établi. Un pic qui se mesure en secondes peut se terminer avant que la nouvelle capacité ne porte du trafic réel.

Que mesurer lors d'un pic de trafic avant de changer quoi que ce soit ?

Mesurez ces valeurs sur les minutes les plus chargées d'un vrai pic :

• Requêtes offertes et réponses envoyées par seconde, pour chaque ad exchange ou partenaire. L'écart, c'est le trafic que vous perdez, et sa forme montre si les requêtes sont rejetées dès l'entrée ou tombent en timeout une fois le travail fait
• Les timeouts tels que le partenaire les compte. L'ad exchange mesure depuis son côté, réseau compris, et chez Authorized Buyers de Google, c'est ce décompte qui décide si un bidder est bridé. Demandez à chaque ad exchange quelles données de timeout il peut partager
• Le 99e percentile de latence, décomposé en temps sur le réseau, temps en file d'attente et temps de travail
• Profondeur de file par service. Une file qui grossit pendant le pic et se vide lentement ensuite désigne le composant qui fixe votre plafond
• Retries par seconde, par appelant. Si les retries montent en même temps que les timeouts, ils font partie de la charge
• Retard des compteurs et des événements. De combien les compteurs de budget et les logs d'impressions et de clics sont en retard sur le temps réel au pic

Rassemblez ces chiffres de votre dernier grand pic sur une seule page. C'est le brief pour quiconque vous engagerez, et la référence pour chaque correctif.

Que corriger en premier, et dans quel ordre ?

Travaillez dans cet ordre, des changements peu coûteux qui arrêtent le travail inutile jusqu'aux changements coûteux qui ajoutent de la capacité ou remplacent du code, et mesurez de nouveau après chaque étape.

• Arrêtez le travail qui finira en retard. Lisez l'échéance à l'arrivée de la requête, retranchez le temps réseau que vous mesurez pour ce partenaire, et répondez par un no-bid rapide quand le reste est trop court. OpenRTB permet à un bidder de décliner par une réponse HTTP 204 vide, que son guide d'implémentation présente comme l'option la plus économique en bande passante
• Limitez ce qui entre. Demandez à chaque ad exchange comment plafonner les requêtes qu'il vous envoie. L'API real-time bidding de Google, par exemple, permet à un bidder de fixer, pour chaque endpoint qui reçoit ses bid requests, « le nombre maximal de requêtes par seconde qu'il est permis d'envoyer à ce serveur ». Une limite que vous fixez vous-même se planifie plus facilement qu'un bridage appliqué après des échéances manquées
• Donnez un budget aux retries. Limitez les retries par requête et donnez à chaque serveur un budget de retries, comme le recommande le livre SRE : une fois le budget épuisé, la requête échoue au lieu d'être retentée. En bidding, un retry ne dispose que du temps restant avant l'échéance
• Sortez les compteurs partagés du chemin de la requête. Quand chaque décision lit et met à jour les compteurs de budget et de fréquence dans un stockage central unique, les campagnes les plus actives deviennent à elles seules une file d'attente. Donnez à chaque serveur une part locale des limites, réconciliez à intervalle court, et acceptez en échange un risque de dépassement de budget faible et connu
• Séparez les événements des décisions. Écrivez les événements d'impression et de clic dans un buffer borné que la requête n'attend pas, et comptez chaque événement que le buffer doit abandonner. Le pipeline absorbe alors le pic et rattrape son retard ensuite, et une clé sur chaque événement lui permet d'éliminer les doublons
• Préparez-vous aux pics prévisibles. Beaucoup figurent au calendrier, comme les soldes saisonniers et le sport en direct. Montez en capacité avant eux, préchauffez les caches et les connexions, et faites des tests de charge sur une copie de la production avec un générateur qui tient un débit de pic fixe
• Ne touchez qu'en dernier au code qui traite chaque requête. Faites-le une fois que les chiffres montrent que la cause est le code lui-même, par exemple des pauses du garbage collector sur le chemin de bid ou une inférence de modèle qui dévore l'échéance

Faut-il réécrire la plateforme pour tenir les pics ?

Une réécriture complète est rarement le bon premier pas. Elle détourne les ingénieurs du développement de fonctionnalités jusqu'à ce que le nouveau code porte le trafic de production, et sans mesures prises au pic, personne ne peut dire quelle partie réécrire. Réécrivez un composant quand les chiffres continuent de le désigner après les correctifs moins coûteux, par exemple un bidder dont les réponses les plus lentes viennent des pauses de son runtime. Remplacez-le derrière la même interface et comparez les mêmes chiffres de pic avant et après.

Notre plateforme publicitaire ne tient pas les pics de trafic. Qui peut nous aider à la faire monter en charge ?

Pour une plateforme publicitaire qui lâche aux pics de trafic, l'aide vient de cinq endroits, et chacun couvre une partie différente du problème :

• Vos propres ingénieurs, avec de meilleures mesures. Ils connaissent le code, et la page de chiffres du pic peut leur montrer la correction. Leur limite, c'est le temps, car le travail sur les pics est en concurrence avec la roadmap
• Vos partenaires ad exchanges et SSP. Leurs décomptes de timeouts incluent le réseau entre vous, que vos propres dashboards ne voient pas. Demandez quelle ventilation ils peuvent partager : par localisation, par type de requête, par heure
• Le support de votre fournisseur cloud. Utile pour les limites de réseau, de load balancer et d'instances. La logique d'enchère reste de votre ressort
• Les sociétés généralistes d'externalisation logicielle. Elles apportent des ingénieurs, ce qui aide quand la contrainte est la taille de votre équipe. Demandez si les personnes qu'elles affectent ont déjà travaillé sur un système temps réel sous charge
• Les sociétés d'ingénierie spécialisées en ad tech et les ingénieurs performance indépendants. Ils sont utiles s'ils ont construit ou exploité le type de système qui lâche chez vous. Pensez à eux quand la cause n'est pas claire ou que les correctifs précédents n'ont pas tenu

Comment vérifier une société qui propose de faire monter en charge notre plateforme publicitaire ?

Posez ces questions avant de signer. Les réponses aident à voir si une société a déjà fait ce genre de travail :

• De quoi avez-vous besoin de notre part pour commencer ? Une bonne réponse cite des mesures : timeouts par partenaire, percentiles, profondeur de file, les minutes les plus chargées du dernier pic
• Comment saurons-nous que le travail est terminé ? Attendez un objectif mesurable, convenu à l'avance et vérifié lors d'un pic réel ou rejoué : quel partenaire, quel percentile, quelle marge par rapport à l'échéance, à quel débit de requêtes
• Que changerez-vous avant notre prochain pic prévisible, et quoi après ? Attendez d'abord les correctifs peu coûteux, et un moyen de désactiver chaque changement
• Lesquels de ces systèmes avez-vous construits : un bidder, un SSP ou un ad exchange, un ad server, un pipeline d'événements ? Posez des questions sur celui qui est le plus proche de votre problème, et sur ce qui y a cassé
• Qui garde le code, les dashboards et les tests de charge ensuite ? Ils doivent rester dans vos comptes

Est-ce qu'amBrain peut aider une plateforme publicitaire qui lâche sous la charge ?

amBrain est une société d'ingénierie logicielle basée à Erevan, en Arménie, qui construit des plateformes de trading à faible latence, des moteurs d'appariement et des systèmes de real-time bidding en Rust.

amBrain diagnostique les systèmes lents dans le trading, les paris et l'ad tech : la plateforme en fonctionnement est mesurée de bout en bout, et le rapport indique où passe le temps. amBrain reprend des projets restés bloqués avec une autre équipe et les mène jusqu'en production.

En AdTech, amBrain travaille sur le développement de DSP, les plateformes d'enchères en temps réel et l'ingénierie d'ad exchange.

amBrain construit des supply-side platforms (SSP) pour les éditeurs. amBrain construit des ad servers : ciblage, capping de fréquence et reporting. amBrain construit des pipelines d'analytique d'événements pour l'ad tech : collecte, traitement et reporting des événements d'impression et de clic. amBrain construit l'inférence ML au sein du bidder : le modèle décide du bid dans la fenêtre de l'enchère.

amBrain a construit RTBBidder, une demand-side platform, pour un client. amBrain travaille en trois formats : la prestation complète, une équipe dédiée ou des ingénieurs intégrés à votre équipe. Le client conserve la pleine propriété du produit et du code, à l'exception des composants réutilisables d'amBrain.

Cet article n'est pas une étude de cas. Il n'affirme pas qu'amBrain a corrigé des défaillances liées aux pics de trafic sur la plateforme publicitaire d'un client, et il ne donne aucun chiffre sur RTBBidder, ni prix ni délais.

Si votre plateforme a lâché lors de son dernier pic, commencez par une page de mesures issues de ce pic. Envoyez-la à chaque société que vous envisagez, y compris amBrain, et comparez la façon dont chacune propose de s'en servir.

Questions fréquentes sur les plateformes publicitaires face aux pics de trafic

• Ajouter des serveurs réglera-t-il les défaillances aux pics ? Parfois : quand la plateforme manque de puissance de calcul au pic et que rien d'autre ne cloche. Quand les timeouts viennent de tempêtes de retries, d'un stockage central de compteurs ou d'un partenaire lent, plus de serveurs font grimper la facture et laissent la cause en place. Avec un stockage central de compteurs, ils ajoutent en plus de la charge à la partie qui constitue déjà la limite
• Notre SSP tombe en timeout en attendant les bidders. Que faire ? Donnez à chaque bidder un timeout compris dans votre propre échéance d'enchère, et gardez une marge avant de devoir répondre à l'éditeur. Pour les éditeurs qui utilisent Prebid.js avec Prebid Server, Prebid indique que le timeout côté serveur « devrait probablement se situer entre 50 % et 75 % de l'Auction Timeout », selon le délai réseau de l'utilisateur, afin que les bids du serveur reviennent au navigateur à temps pour l'appel à l'ad server
• Rust est-il nécessaire pour tenir les pics ? Non. Le langage compte quand les mesures montrent que le runtime est la cause, par exemple des pauses du collecteur sur le chemin de bid. Files d'attente, retries, compteurs partagés et capacité se corrigent sans changer de langage