Migration Datadog assistée par IA : coûts réduits de 90 %

Pourquoi Stream Router a dépassé les limites de son stockage clé-valeur

Chez Datadog, le problème était un service de routage devenu goulot d'étranglement. Stream Router est un plan de contrôle interne qui indique aux producteurs où écrire les métriques et aux services d'interrogation où les lire, en choisissant le cluster Kafka, le topic et les partitions de chaque point de données sur une plateforme qui traite plus de cent mille milliards d'événements par jour.

Il est né pour corriger un problème plus ancien. En 2016, le routage était géré par un fichier de configuration de trois lignes, devenu des milliers de lignes modifiées à la main. Stream Router l'a remplacé par un service gRPC dont le chemin d'écriture reposait sur FoundationDB avec un modèle clé-valeur.

À mesure que la table de routage grossissait, les opérations critiques ont atteint les limites de taille de transaction de FoundationDB. Les plus exigeantes prenaient jusqu'à 45 minutes à cause de milliers d'allers-retours séquentiels. Les routes, les flux, les stratégies de partitionnement et les règles sont relationnels par nature : le code chargeait donc des dizaines de milliers d'entrées dans les processus des pods et faisait office de base de données relationnelle en mémoire.

Ce que Datadog a changé dans le modèle de données

La solution était un schéma relationnel. Les ingénieurs ont redessiné le modèle de données autour des relations entre ces entités, afin que les clés étrangères de PostgreSQL appliquent des règles que le code applicatif reconstruisait à la main.

Une forte modularité a rendu la bascule possible : le nouveau Stream Router implémentait la même API sur PostgreSQL à la place de FoundationDB, sans changement nécessaire ailleurs. Il restait à refactoriser tout le code de l'ancien modèle vers le nouveau, et c'est là que l'équipe a fait appel à Claude et Cursor.

Comment Claude et Cursor ont travaillé méthode par méthode

Les modèles ont travaillé dans une boucle serrée, pas seuls. L'ingénieur Arnold Wakim l'a décrit ainsi.

« Ils ne généraient pas du code de façon autonome : pour chaque méthode, nous fournissions l'ancienne implémentation, le nouveau schéma et un test en échec. » Arnold Wakim, ingénieur chez Datadog

Les modèles produisaient une première version, et les tests décidaient si elle était correcte. Le travail s'est déroulé en trois phases : Claude a d'abord décrit l'intention de chaque fonction clé ; les ingénieurs ont ensuite rédigé des prompts ciblés pour corriger les tests en échec, en précisant le comportement attendu et le contexte de la première étape ; enfin, le nouveau service est passé en production selon un schéma blue/green.

Comment l'équipe a protégé le trafic en production

La sécurité en production est venue de l'exécution simultanée des deux systèmes. Deux instances indépendantes de Stream Router, l'une sur PostgreSQL et l'autre sur FoundationDB, traitaient les mêmes requêtes pendant que des feature flags basculaient les clients de l'une à l'autre. Un service de validation dans chaque cluster comparait les réponses de routage et alertait immédiatement l'équipe en cas de divergence.

Là où les modèles ont montré leurs limites

Les modèles avaient des limites nettes, que Wakim énumère. Les prompts de plus haut niveau fonctionnaient mal. Claude écrivait des requêtes qui renvoyaient des résultats corrects mais émettaient bien plus d'allers-retours que nécessaire, et des optimisations comme le traitement par lots, UNNEST et les expressions de table communes demandaient une intervention humaine. Une fois que les ingénieurs avaient écrit le schéma optimisé, les modèles le reproduisaient dans les méthodes suivantes, mais ils ne l'ont jamais trouvé seuls. La consommation de tokens a aussi été élevée, car l'équipe injectait dans la boucle la sortie complète des tests plutôt que des extraits réduits.

Ce que la migration a apporté

Les résultats mesurés sont ceux de l'entreprise. Des opérations de 45 minutes sont tombées à environ une seconde, et les latences sont passées de centaines de millisecondes à quelques-unes. Le stockage des données est devenu jusqu'à 40 fois plus petit, l'usage du processeur et de la mémoire a diminué, et les coûts de base de données ont baissé de 90 %. Datadog indique qu'elle n'aurait pas terminé l'implémentation dans le temps imparti sans outils d'IA.

Ce que cela dit aux équipes qui préparent un refactoring assisté par IA

Pour une organisation d'ingénierie, la tâche est un refactoring de grande ampleur et répétitif sur du code de production, sous contrainte de délai. La migration Datadog assistée par IA suggère où se situe la valeur : les modèles ont accéléré la saisie, tandis que la suite de tests, la conception modulaire et le validateur en parallèle ont rendu cette vitesse sûre. Wakim conclut que la solidité de la suite de tests a déterminé jusqu'où l'équipe pouvait faire confiance au code généré par l'IA. Une équipe sans cette suite obtiendrait le même code plus vite, mais sans moyen de savoir s'il est juste.

Questions et réponses

Comment Datadog a-t-elle utilisé Claude et Cursor dans la migration ?

Pour chaque méthode, les ingénieurs donnaient aux modèles l'ancienne implémentation, le nouveau schéma et un test en échec. Les modèles écrivaient une première version, et les tests montraient si elle était correcte.

Quels résultats la migration vers PostgreSQL a-t-elle produits ?

Datadog indique que des opérations sont passées de 45 minutes à environ une seconde, que les latences sont tombées de centaines de millisecondes à quelques-unes, que le stockage a diminué jusqu'à 40 fois et que les coûts de base de données ont baissé de 90 %.

Que n'ont pas su faire les modèles d'IA ?

Ils ont écrit des requêtes correctes mais lentes. Le traitement par lots, UNNEST et les expressions de table communes ont demandé des ingénieurs, et les modèles n'ont réutilisé ces schémas qu'après les avoir vus.