Dans le monde de l'audio programmatique, 101 ms signifient zéro revenu. Ce n'est pas un problème de performance, c'est un problème de survie.  Nous gérons une plateforme DSP de publicité audio qui traite environ   Chaque requête doit être reçue, évaluée et traitée en moins de   Si ce délai est dépassé, l'enchère est annulée. À 101 ms, nous sommes tout simplement invisibles. 350 millions de requêtes par jour, soit près de 2 milliards par semaine. 100 millisecondes.  Nous y parvenons avec une équipe d'ingénieurs de trois personnes et une facture cloud inférieure à 10 000 $ par mois. La même équipe gère l'ensemble de l'infrastructure : l'infrastructure de l'entreprise, la couche applicative, les bases de données et l'exploitation.   L'écosystème RTB  Si vous n'êtes pas un expert en publicité numérique, voici un résumé : la publicité programmatique fonctionne selon le principe des enchères en temps réel (RTB).  Du côté de l'offre, on trouve   . Ce sont des plateformes comme AdsWizz ou Triton qui agrègent l'inventaire publicitaire de milliers d'applications et d'éditeurs : lecteurs de podcasts, applications de streaming et autres plateformes audio. les SSP (Supply-Side Platforms)  Du côté de la demande se trouvent   des systèmes comme le nôtre qui représentent les annonceurs et décident, en temps réel, s’il convient d’enchérir sur une impression donnée. les DSP (Demand-Side Platforms) –  Lorsqu'un utilisateur ouvre une application de podcast et qu'un emplacement publicitaire se libère, l'application communique avec sa plateforme SSP. Celle-ci envoie alors des demandes d'enchères à plusieurs DSP. Notre système reçoit cette demande, évalue l'utilisateur et les campagnes en cours, calcule le prix de l'enchère et renvoie une réponse. L'ensemble de ce processus doit s'effectuer en moins de 100 ms, de bout en bout.  Ici, la latence n'est pas qu'un simple indicateur. Elle est le produit lui-même.  Une fois ce constat admis, il est devenu évident que les modèles d'applications web classiques ne convenaient pas. Nous ne pouvions pas nous permettre de longs sauts réseau entre les microservices, et encore moins les coûts d'hébergement liés à une infrastructure Kubernetes tentaculaire. Pour survivre, nous devions impérativement concevoir notre application en tenant compte des contraintes.  Cette contrainte n'était pas théorique. Au début, lorsque nous disposions encore de crédits cloud, l'efficacité ne nous préoccupait pas outre mesure. Une fois ces crédits épuisés, chaque décision architecturale a soudainement eu un coût réel. C'est alors que nous avons dû revoir notre approche et repenser l'architecture du système en privilégiant la latence, les coûts et la simplicité d'utilisation.  Ce qui suit est l'architecture qui permet à une équipe de trois personnes de gérer un système RTB mondial à grande échelle, sans dépenser une fortune ni perdre le sommeil.  1. La géographie comme premier filtre : concevoir pour la physique des réseaux  Les principales plateformes SSP audio avec lesquelles nous sommes intégrés —   — sont hébergées aux États-Unis, en Europe et en Asie du Sud-Est. Notre couche applicative, qui gère la logique des campagnes pour les annonceurs basés en Inde, est située en Inde. Triton, AdsWizz, Magnite (anciennement Rubicon) et MCTV  Le temps d'aller-retour réseau brut entre ces régions est d'environ   , avant même l'exécution de toute logique applicative. Cela représente déjà plus du double du budget autorisé. 240 millisecondes  La solution était simple mais non négociable. Nous avons déployé nos clusters d'enchères sur   : USA-Ouest (Oregon), UE-Centre (Francfort) et Asie-Pacifique (Singapour et Hong Kong). quatre régions AWS stratégiques  Cela garantit que lorsqu'un SSP envoie une demande d'enchère, notre distance au matériel est négligeable (généralement de l'ordre de quelques millisecondes), laissant ainsi la majeure partie du budget de 100 ms pour le calcul proprement dit.  2. L'hybride monolithe-microservices   Nous avons opté pour une architecture intermédiaire entre une architecture monolithique traditionnelle et une architecture de microservices. Au lieu de répartir les services sur le réseau, nous regroupons un   , puis nous faisons évoluer ces machines virtuelles horizontalement derrière un équilibreur de charge global. petit cluster de services étroitement couplés sur une seule machine virtuelle  À l'intérieur de chaque VM (traitée comme un nœud unique), cela ressemble à un système distribué miniature :    : Un conteneur d'entrée unique qui fait office de régulateur du trafic interne. Nginx    : 3 à 5 répliques du service d’enchères Node.js exécutées sur la même machine pour utiliser pleinement le processeur. Enchérisseur    : Une instance Redis locale exécutée directement en parallèle du code. Redis  L'avantage principal réside dans la localité des données par défaut. Le soumissionnaire n'a pas besoin de traverser le réseau pour récupérer les données ; il les lit directement depuis l'hôte local. Cela nous permet également d'augmenter considérablement   . En utilisant des machines virtuelles plus grandes (par exemple, c6i.xlarge) et en partageant un seul ensemble de données en mémoire entre plusieurs nœuds de calcul, nous obtenons un rapport RAM/CPU bien meilleur, minimisant ainsi le gaspillage tout en maximisant le débit. la densité des ressources  3. La logique : échouer rapidement  Pour respecter un délai de 100 ms, un code rapide ne suffit pas. Le système doit décider rapidement quand ne pas effectuer de tâches.  La plupart des requêtes d'enchères entrantes n'aboutiront jamais. Autoriser ces requêtes à accéder à l'état, aux bases de données ou aux chemins d'écriture est le moyen le plus rapide de dépasser le budget de latence. Nous structurons le système d'enchères sous forme d'arbre de décision, ordonné par « probabilité d'échec », en exécutant d'abord les vérifications les moins coûteuses.  Les vérifications se déroulent plus ou moins dans cet ordre :    : une grande partie des offres échouent à cette étape. Il s’agit d’une comparaison simple qui donne des résultats quasi instantanés. Vérification géographique    : si la géographie est validée, nous vérifions les contraintes de la plateforme et du périphérique. Vérifications du système d'exploitation et du périphérique    : Vérification de la correspondance de l'application avec notre inventaire autorisé. Ciblage éditeur/application    : Ce n'est que si une requête passe ces filtres que nous abordons des chemins plus lourds (données au niveau utilisateur, logique budgétaire et de cadence, ou tout ce qui nécessite une coordination). Logique d'état  En défaillant rapidement, nous rejetons 90 % du trafic en quelques microsecondes, réservant ainsi les cycles CPU aux offres qui aboutissent réellement.  4. Architecture des données : Redis pour les règles, Aerospike pour les profils  Nous avons divisé notre architecture de données en deux niveaux en fonction des modèles d'accès et du coût de l'obsolescence des données.  Les règles : Redis local  Chaque nœud stocke les métadonnées « chaudes » (campagnes actives et plafonds budgétaires) dans son instance Redis locale. Un processus cron utilise un   , interrogeant notre API centrale toutes les 60 secondes pour télécharger les données les plus récentes. modèle de récupération  À notre échelle, cette expiration de 60 secondes des données engendre un risque :   . Si plusieurs nœuds traitent simultanément les mêmes données budgétaires obsolètes, ils risquent de dépenser plus que le budget alloué au client. le dépassement budgétaire  Nous gérons cela grâce à un   : la taille du parc de nœuds est prise en compte dans le contrôle budgétaire. À mesure que le nombre de nœuds actifs augmente, chaque nœud réduit dynamiquement la part de budget qui lui est allouée. Même si un nœud utilise des données obsolètes, ses limites locales sont déjà bridées en fonction de la taille actuelle du parc de nœuds. Les dépenses diminuent progressivement au lieu de connaître des pics, et le système converge lors du prochain cycle d'actualisation. mécanisme de freinage  Profils : Aerospike (L’avantage SSD)  La consultation des profils de données utilisateur, la limitation de la fréquence d'envoi et le reciblage nécessitent un accès en moins d'une milliseconde à des ensembles de données massifs et modifiables. Un SGBDR traditionnel ne peut pas supporter cette charge à notre tarif.  Nous utilisons   pour cette couche car il est optimisé pour traiter les SSD comme stockage principal, plutôt que de conserver l'intégralité des données de travail en RAM. Cela nous garantit une latence prévisible tout en réduisant considérablement le coût du matériel par rapport à une solution basée uniquement sur la RAM comme ElastiCache. Aerospike  Pour que cette couche reste abordable, nous sommes intransigeants sur la qualité des données :  La règle des 10 jours : nous ne conservons que les données des utilisateurs actifs au cours des 10 derniers jours.  La limite des 10 millions : nous réduisons activement l’ensemble de données aux quelques millions d’utilisateurs les plus actifs.  Si un utilisateur cesse d'interagir, ses données sont supprimées. Cette mesure permet de maintenir les coûts de stockage stables, tandis que le fournisseur se concentre uniquement sur les utilisateurs les plus pertinents.  5. Le secret de l'« asynchrone » : découpler la charge  Notre première version tentait techniquement d'être asynchrone. Nous envoyions immédiatement la réponse de l'offre et laissions la fonction Node.js continuer à s'exécuter en arrière-plan pour écrire le journal dans MongoDB.    : le trafic n’est pas constant ; il connaît des pics. Lors des pics de charge, même si la réponse aux enchères était épuisée, nos conteneurs Node.js restaient « en attente », maintenant des connexions ouvertes et consommant des ressources CPU pour tenter de terminer les écritures dans la base de données. Cela a contraint notre autoscaler à créer davantage de machines virtuelles pour gérer l’   , ce qui a fini par saturer notre base de données de connexions. Le piège accumulation d’écritures    : Nous sommes passés du « code asynchrone » à une «  ». Nous avons introduit   comme amortisseur entre l’enchérisseur et le processus d’écriture. Désormais, l’enchérisseur envoie un message à Kafka et libère immédiatement ses ressources. L’écriture est gérée par un ensemble de consommateurs distinct, à un rythme contrôlé. Solution  architecture asynchrone Kafka  6. Évaluation comparative : Mesurez, ne devinez pas  À cette échelle, deviner les types d'instances est coûteux. C'est pourquoi, au lieu de nous fier à la théorie, nous avons effectué des tests de performance.  Nous avons formulé des hypothèses : la limitation du processus d’enchères (calcul ou mémoire), le nombre optimal de processus de travail par nœud et l’impact de la taille de l’instance sur la latence. Nous avons effectué des tests sur plusieurs familles d’instances AWS de différentes tailles et en faisant varier le nombre de services d’enchères exécutés sur un même nœud.  Nous avons adopté la même approche pour la couche de données, en testant différents types de machines pour voir ce qui fonctionnait le mieux pour MongoDB en conditions de charge réelle, en privilégiant une latence stable plutôt qu'un débit maximal.  Tout ceci a été validé par des tests de charge simulant un débit de requêtes par seconde (QPS) comparable à celui de la production, et mesurant les temps de réponse et la latence de queue. Certaines hypothèses se sont avérées exactes, d'autres non.  La conclusion était simple :   . avec un budget de 100 ms, les benchmarks surpassent systématiquement la théorie  7. FinOps : Comment nous maintenons la facture à 10 000 $  Les startups ne meurent pas lors de pics de trafic. Elles meurent lorsque leurs crédits cloud sont épuisés. Pour nous, la maîtrise des coûts n'est pas une option, elle fait partie intégrante de la conception du système.  Certaines économies proviennent de la négociation. Nous avons transféré la facturation via un revendeur pour bénéficier d'une réduction forfaitaire sur volume. Concernant la bande passante, nous nous sommes engagés à   , ce qui nous a permis de négocier une réduction de plus de 60 % sur le prix du CDN par rapport aux tarifs à la demande. Au vu de notre trafic, cet engagement a eu un impact significatif. environ 1 Po de transfert mensuel  Nous séparons également les problématiques : les serveurs d’enchères sans état fonctionnent sur une capacité spot fortement réduite, tandis que les bases de données avec état utilisent des instances prévisibles et de longue durée de vie.  À notre échelle, stocker des centaines de millions d'enregistrements par jour représente un risque considérable. Les journaux d'enchères détaillés ont une durée de conservation courte, de l'ordre de quelques jours, et non de plusieurs mois. Les données que nous souhaitons conserver sont agrégées en temps réel (toutes les heures plutôt que par événement) et déplacées vers des solutions de stockage moins coûteuses et optimisées pour les requêtes. Les données nécessaires uniquement à des fins de conformité ou d'audits historiques sont stockées à froid, ce qui permet de réduire les coûts de 80 à 90 % par rapport aux solutions standard.  Le meilleur moyen de faire des économies, cependant, n'est pas une réduction, mais le   . taux d'utilisation  La plupart des systèmes font fonctionner les processeurs à 20-30 % « par sécurité ». Le nôtre n'en a pas besoin. Grâce à son architecture tolérante aux pannes et conçue pour une réduction progressive de la charge, nous pouvons faire fonctionner les processeurs à   . Nous ne payons pas pour les cycles d'inactivité. Si nous payons pour un cœur, c'est que ce cœur est en cours d'exécution. 80 % d'utilisation sans problème  Cette mentalité, qui considère l'efficacité comme une contrainte de premier ordre, permet de maintenir la facture stable malgré l'augmentation du trafic.  8. Travailler à trois : la philosophie des « frais de scolarité »  Gérer une infrastructure mondiale avec une équipe de trois personnes n'est possible que si la charge est supportée par les systèmes, et non par les individus. Nous concevons nos opérations de manière à éliminer toute intervention humaine du chemin critique et à supprimer autant que possible les points de défaillance uniques. Nous évitons également les cloisonnements de rôles : chaque ingénieur maîtrise l'ensemble de la pile technologique, ce qui garantit que la connaissance opérationnelle ne constitue jamais un point de défaillance unique.  L'infrastructure est jetable par défaut. Si un nœud dysfonctionne, nous ne le déboguons pas sur place : nous le supprimons et laissons le système de mise à l'échelle automatique le remplacer. La restauration est plus rapide que l'investigation, et chaque instance est issue d'un état connu et propre.  L'observabilité est importante, mais les tableaux de bord seuls ne suffisent pas à une petite équipe. Nous utilisons des alertes exploitables (via Datadog) qui se déclenchent uniquement lorsqu'une intervention humaine est nécessaire. Si un cluster régional ralentit ou si un utilisateur prend du retard, nous sommes alertés. Tout le reste est automatisé.  L'automatisation n'a cependant rien de magique. Nous devons toujours payer des frais de scolarité de temps à autre.  Lors d'un incident survenu au début de l'année, une tâche en arrière-plan chargée de mettre à jour le budget a échoué sans avertissement. Le soumissionnaire a continué à fonctionner avec des données obsolètes et a dépensé de l'argent pour une campagne qui aurait dû être terminée : un cas classique de « soumissionnaire zombie ». Nous avons remboursé le client, corrigé l'erreur et renforcé le système grâce à des contrôles de présence surveillés par Datadog. La mise à jour du budget est désormais explicitement indiquée et le moindre silence déclenche une alerte. Si le soumissionnaire ne reçoit pas de mise à jour valide, il est fermé.  Dans une petite équipe, les erreurs sont inévitables.  Les répéter est facultatif.  Conclusion  Aucune des décisions de ce système n'est exotique prise individuellement. Son efficacité repose sur leur effet cumulatif.  La physique des réseaux définit les limites. La localité et la logique de défaillance rapide protègent le chemin de 100 ms. Les limites asynchrones absorbent les pics de trafic. La mesure remplace l'intuition. La maîtrise des coûts et une utilisation élevée garantissent une rentabilité optimale. Les opérations sont conçues de manière à ce que l'intervention humaine ne soit nécessaire que lorsque le système ne peut se rétablir de lui-même.  Il ne s'agit pas ici d'un article sur les technologies publicitaires ou une architecture spécifique. C'est un rappel qu'à grande échelle,   . Lorsque la latence, le coût et les effectifs sont considérés comme des exigences primordiales, l'architecture qui en découle tend à être plus simple, et non plus complexe. les contraintes ne sont pas des obstacles, mais des éléments essentiels à la conception  L'objectif n'était pas de construire quelque chose d'impressionnant, mais quelque chose qui survive.

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Cet audio est produit dans la langue originale de l'histoire !

2 milliards de requêtes, délais de 100 ms, 10 000 $ par mois : concevoir un système RTB mondial optimisé

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Télégramme : le pont de Crypto Island vers le continent

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Vous voulez gagner un concours d’écriture HackerNoon ? Voici ce que recommandent les gagnants du concours #crypto-api

Télégramme : le pont de Crypto Island vers le continent

Comment améliorer votre flux de travail par 10 : 17 applications essentielles

HackerNoon Decoded: The Top 10 Countries Where HackerNoon Is the Most Active

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps