Rethinking latency-sensitive DynamoDB apps for multicloud, multiregion deployment L'ensemble du processus de livraison d'une annonce se déroule en 200 à 300 millisecondes.Nos recherches de base de données doivent être effectuées en millisecondes d'un seul chiffre.Avec des milliards de transactions par jour, la base de données doit être rapide, évolutive et fiable.Si elle tombe en panne, notre infrastructure de service publicitaire cesse de fonctionner. » – Todd Coleman, co-fondateur technique et architecte en chef de Yieldmo L'ensemble du processus de livraison d'une annonce se déroule en 200 à 300 millisecondes.Nos recherches de base de données doivent être effectuées en millisecondes d'un seul chiffre.Avec des milliards de transactions par jour, la base de données doit être rapide, évolutive et fiable.Si elle tombe en panne, notre infrastructure de service publicitaire cesse de fonctionner. » – Todd Coleman, co-fondateur technique et architecte en chef de Yieldmo L'activité de la publicité en ligne de Yieldmo dépend du traitement de centaines de milliards de demandes d'annonces quotidiennes avec des réponses de latence sous-secondes. Les services de la société dépendaient initialement de DynamoDB, que l'équipe valorisait pour sa simplicité et sa stabilité. Cependant, les coûts de DynamoDB deviennent insoutenables à l'échelle et l'équipe avait besoin de flexibilité multicloud à mesure que Yieldmo s'étendit à de nouvelles régions. Dans un récent discours de Todd Coleman, co-fondateur technique et architecte en chef de Yieldmo, a partagé les défis techniques auxquels la société est confrontée et pourquoi l’équipe a finalement progressé avec l’API compatible DynamoDB de ScyllaDB. Conférence Monster Scale Vous pouvez regarder sa conversation complète ci-dessous ou continuer à lire pour un rappel. https://youtu.be/sk0mIiaOwM8?embedable=true LAG = affaires perdues Yieldmo est une plate-forme de publicité en ligne qui connecte les éditeurs et les annonceurs en temps réel en tant que chargement de page. Presque chaque demande d'annonce déclenche une requête de base de données qui récupère des informations sur l'apprentissage automatique et l'identité de l'appareil. Ces requêtes permettent à ses serveurs d'annonces de: Des ventes aux enchères efficaces Aider les partenaires à décider de l'offre Suivez les annonces qu’ils ont déjà affichées sur un appareil afin que les annonceurs puissent gérer les limites de fréquence et optimiser la livraison des annonces L'ensemble du pipeline publicitaire se termine en seulement 200 à 300 millisecondes, la majeure partie de ce temps étant consacrée aux partenaires qui évaluent et placent les offres. Lorsqu’un utilisateur visite un site Web, une demande d’annonce est envoyée à Yieldmo. La plateforme de Yieldmo analyse la demande. Il demande des publicités potentielles de ses partenaires. Il organise une vente aux enchères pour déterminer l'offre gagnante. La recherche de la base de données doit avoir lieu avant tout appel à des partenaires. Et ces recherches doivent se terminer avec des latences de millisecondes à un seul chiffre. Coleman a expliqué: «Avec des milliards de transactions quotidiennes, la base de données doit être rapide, évolutive et fiable. DynamoDB en pleine croissance L'infrastructure de production de Yieldmo fonctionne sur AWS, donc DynamoDB a été un choix logique alors que l'équipe a construit leur application. Tout d’abord, DynamoDB devenait de plus en plus coûteux à mesure que l’activité s’agrandissait.Deuxièmement, la société voulait la possibilité d’exécuter des serveurs d’annonces sur des fournisseurs de cloud au-delà d’AWS. Coleman a partagé : « Dans certaines régions, par exemple, les centres de données de la côte est des États-Unis, AWS et GCP [Google Cloud Platform] sont assez proches pour que la latence soit minimale. Là, il n’y a aucun problème à frapper notre base de données DynamoDB à partir d’un serveur d’annonces fonctionnant sous GCP. Cependant, lorsque nous avons essayé de lancer un cluster de serveur d’annonces basé sur GCP à Amsterdam tout en accédant à DynamoDB à Dublin, la latence était trop élevée. DynamoDB Alternatives L'équipe de Yieldmo a commencé à explorer des alternatives DynamoDB qui correspondraient à leurs charges de travail de base de données extrêmement lourdes en lecture. Un flux continu de données en temps réel de leurs partenaires, essentiel pour concilier les données de Yieldmo avec celles de leurs partenaires Mises à jour de lots basées sur des informations d’apprentissage automatique tirées de leurs données historiques Compte tenu de cet équilibre de lecture à haute fréquence et d’écriture structurée, ils recherchaient une base de données capable de gérer l’accès à grande échelle à faible latence tout en gérant efficacement les mises à jour simultanées sans dégradation de la performance. L'équipe a d'abord envisagé de rester avec DynamoDB et d'ajouter une couche de mise en cache. Cependant, ils ont constaté que la mise en cache ne pouvait pas résoudre le problème de latence géographique et les erreurs de mise en cache seraient encore plus lentes avec cette option. Ils ont également exploré Aerospike, qui a offert un support de vitesse et de cloud. Cependant, ils ont appris que l'indexation dans la mémoire d'Aerospike aurait nécessité un cluster prohibitivement grand et coûteux pour gérer le grand nombre d'objets de données de petite taille de Yieldmo. Ensuite, ils ont découvert ScyllaDB, qui a également fourni la vitesse et le support cross-cloud, mais avec une API compatible avec DynamoDB (Alternator) et des coûts plus bas. Coleman a partagé: «ScyllaDB a pris en charge les déploiements cross-cloud, nécessité un nombre de serveurs gérables et offert des coûts compétitifs. Le meilleur de tout, son API était compatible avec DynamoDB, ce qui signifie que nous pouvions migrer avec un minimum de changements de code. En fait, un seul ingénieur a mis en œuvre les modifications nécessaires en quelques jours seulement. » ScyllaDB Évaluation, migration et résultats Pour commencer à évaluer comment ScyllaDB fonctionnait dans leur environnement, l’équipe a migré un sous-ensemble de serveurs d’annonces dans une seule région. Cela impliquait la migration de plusieurs téraoctets tout en conservant des mises à jour en temps réel. Processuellement, ils ont copié les données historiques de l’outil de migration basé sur Spark de ScyllaDB, interrompu les tâches de lot ML et utilisé leur architecture Kafka pour reproduire les écrits récents dans ScyllaDB. Mettre une seule table DynamoDB avec ~ 28 milliards d’objets (~ 3,3 TB) a pris environ 10 heures. La prochaine étape consistait à migrer toutes les données dans cinq régions AWS. Cette phase a duré environ deux semaines.Après avoir évalué les performances, Yieldmo a promu ScyllaDB au statut primaire et a finalement arrêté d'écrire à DynamoDB dans la plupart des régions. Réfléchissant sur la migration presque un an plus tard, Coleman a résumé : « Le plus grand avantage est la flexibilité multicloud, mais même sans cela, la migration en valait la peine. Les coûts de base de données ont été réduits d’environ la moitié par rapport à DynamoDB, même avec des prix de capacité réservée, et nous avons vu des améliorations modestes de la latence. ScyllaDB s’est avéré fiable : leur équipe surveille nos clusters, nous alerte sur les problèmes et nous conseille sur l’échelle. Comment ScyllaDB se compare à DynamoDB
