Les efforts de DataDome pour ne pas mettre ses infrastructures cloud à genoux
DataDome, spécialiste de la protection contre les bots, est un gros utilisateur de ressources cloud. Si gros qu’il arrive à atteindre les limites que lui allouent ses fournisseurs. Ces acteurs vantent pourtant les capacités illimitées du cloud.
Née en France en 2015, DataDome est une startup basée à New York et spécialisée dans la protection des sites Web, des applications mobiles et des API. Son expertise ? La lutte en temps réel contre les bots. Ces robots sont utilisés pour des attaques en déni de service, des tentatives de détournement de compte, de la collecte de données tarifaires ou encore l’achat de produits en masse (le fameux scalping).
« Après le lancement de notre solution SaaS, nous avons connu une belle croissance en France dans l’e-commerce et les médias auprès d’entreprises comme Leboncoin, BlaBlaCar, Fnac-Darty, etc. » se rappelle Benjamin Fabre, cofondateur et CEO de DataDome.
Aujourd’hui, DataDome réalise environ la moitié de ses revenus en l’Europe et l’autre moitié en Amérique du Nord. « Nous avons 80 % de croissance d’année en année aux États-Unis, mais notre ingénierie est en France, tout comme les deux tiers de nos effectifs », signale le CEO.
Dans son domaine, DataDome se retrouve entre deux eaux. « Nous avons deux types de compétiteurs : les solutions généralistes des fournisseurs cloud ou des CDN de type Akamai, Cloudflare, ou encore Fastly d’un côté. De l’autre, il y a des “pure-players”, comme Human », poursuit Benjamin Fabre.
« La protection contre les bots, c’est un jeu du chat et de la souris permanent ».
Benjamin FabreCEO et cofondateur, DataDome
Tous ces compétiteurs sont concernés par un sujet d’actualisation de leurs solutions. « La protection contre les bots, c’est un jeu du chat et de la souris permanent. Nous sommes toujours en train de nous battre contre les éditeurs de bots qui, eux aussi, innovent », assure le CEO. Selon lui, environ 30 % de sa clientèle couple les fonctions de DataDome avec les fonctionnalités de protection déjà offertes par certains CDN.
Non seulement les éditeurs de bots vendent des outils d’automatisation performants qui imitent fidèlement le comportement des humains, mais les attaquants s’appuient désormais sur les mêmes adresses IP que des utilisateurs lambda.
« Il y a quelques années, les attaques venaient de Russie ou de Chine. Aujourd’hui, les attaques sophistiquées semblent provenir des systèmes Orange, Free, Bouygues Telecom, SFR en France et de Verizon, T-Mobile, A&T, etc. aux États-Unis. Les attaquants passent par des proxy résidentiels », relate le CEO. En clair, les cyberattaquants corrompent des appareils mal protégés connectés aux modems installés chez des particuliers.
D’autres techniques plus pernicieuses consistent à diffuser des applications mobiles pour utiliser de manière plus ou moins légale les adresses IP des smartphones associés. DataDome doit également faire face aux fermes de robots, une des formes les plus industrialisées de constitution de botnets.
Le métier de DataDome
Une fois qu’elle a reçu une requête HTTP suspecte, DataDome s’engage sur un très faible taux de faux positifs. En clair, un humain doit tomber le plus rarement possible sur un Captcha. « Seulement 0,01 % des utilisateurs de nos clients doivent passer un Captcha », énonce Benjamin Fabre. « Même si cela paraît très faible, nos clients sont mécontents quand cela arrive ».
L’éditeur combine des algorithmes de machine learning supervisés, dont le rôle est de détecter les types d’attaques ou les comportements suspects les plus courants, et des algorithmes non supervisés. Ces algorithmes non supervisés ont pour rôle de faire le distinguo entre le trafic généré par des robots et celui généré par des humains lors d’un pic sur un site Web. « Quand un pic de trafic est détecté par notre système, nous avons des algorithmes de clustering qui aident à comparer les requêtes HTTP et d’autres empreintes pour essayer de détecter ce qui est nouveau dans la nature du trafic », relate le CEO de DataDome.
Si les sources de trafics sont inconnues, c’est alors à ce moment-là que DataDome affiche un Captcha pour un petit nombre d’eux. « Si les Captchas sont passés, nous considérons ces nouvelles sources de trafic comme légitimes. S’ils ne sont pas passés, cela veut dire que ce sont des bots et nous les bloquons en temps réel ».
DataDome a développé son propre Captcha censé simplifier le passage de cette étape et respecter la confidentialité des utilisateurs. Pour les robots, cette technologie différente de reCaptcha de Google serait plus difficile à contourner, selon le CEO. Jusqu’à ce que les attaquants trouvent la parade, consent-il.
De (très) gros besoins en ressources IT
Outre le besoin d’une architecture de données efficiente, un tel dispositif réclame d’utiliser d’importantes ressources IT. « Nous devons scaler en même temps que nos clients », avance Benjamin Fabre. « Quand les e-commerçants lancent une opération spéciale, parfois ils nous préviennent, parfois non », illustre-t-il.
DataDome a déployé son architecture sur 25 points de présence dans le monde. « À chaque chargement de page sur un site Web de nos clients, cela fait un appel API synchrone à nos serveurs qui vont attendre que DataDome autorise à ouvrir la page ou non. D’où l’importance de se doter d’une architecture élastique ».
D’autant que la startup s’est imposé une contrainte : l’inférence de ses modèles de machine learning doit se faire en moins de 3 millisecondes. Nous devons être capables de multiplier nos capacités de calcul par 100 en quelques dizaines de secondes », affirme Benjamin Fabre.
Sans surprise, l’éditeur s’appuie sur les services de fournisseurs cloud. « Nous utilisons les services de cinq hébergeurs cloud différents. Les instances AWS représentent 65 % de nos ressources cloud », liste le CEO. En 2021, la plateforme de DataDome s’étendait sur AWS, Azure, GCP, OVH, Scaleway et Vultr.
Comme beaucoup de jeunes entreprises, DataDome a profité des avantages offerts par AWS aux startups, puis est rapidement devenu un partenaire du géant du cloud. Cela ne veut pas dire que l’éditeur se satisfait pleinement de l’offre technique de son fournisseur privilégié. « Nous avons poussé les technologies de scaling d’AWS dans leur retranchement. Parfois, nous avons dû redévelopper de petits éléments parce que ça n’était pas assez rapide », explique Benjamin Fabre.
Lancer en parallèle des centaines d’instances en parallèle n’est pas une pratique aisée, peu importe le fournisseur cloud. « Nous sur-provisionnons environ 50 % des capacités en avance », évoque le CEO. « Il faut que le volume de ressources soit suffisant le temps que les nouvelles ressources s’enclenchent pour absorber un pic ».
Dans le principe, il s’agit pour la startup de collecter des données à l’aide de modules installés sur les sites Web, les applications et les API de ses clients vers des points de présence qui hébergent les serveurs API et les répartiteurs de charge de la startup. Ces deux composants lui permettent de gérer le trafic et d’accepter ou de refuser un accès. Ensuite, elle utilise Apache Kafka et Flink pour envoyer les données vers un cluster Elasticsearch par-dessus lequel s’exécutent des algorithmes d’analyse de comportement. Depuis 2017, DataDome utilise la fonctionnalité Lambda@Edge pour s’intégrer avec le CDN Amazon CloudFront et utiliser les caches régionaux d’AWS.
Un autoscaler « maison » pour accélérer le démarrage des instances
Considérant que les machines d’AWS ne se lançaient pas assez rapidement pour ses besoins, la startup a mis en place son propre autoscaler.
Auparavant, Datadome prenait la décision de la mise à l’échelle en s’appuyant sur la charge CPU. Or, lors d’une attaque, la charge CPU des instances des points de présence atteint rapidement 100 %. Une fois cette valeur atteinte, impossible de prévoir le nombre de machines à déployer.
L’éditeur s’est dit qu’il pourrait mesurer le volume de trafic « au-devant » de son application. Cela implique de mesurer le trafic entrant au niveau des instances EC2, mais cette métrique intègre également les communications entre instances, ce qui biaisait le résultat.
Troisième solution envisagée, la prise de mesure au niveau du répartiteur de charge. Le service Elastic Load Balancing d’AWS peut supporter plusieurs modes d’implémentation, dont des répartiteurs de charge applicative (ALB) et des équilibreurs de charge réseau (NLB). « Les NLB disposent de moins de fonctionnalités, mais leur mise à l’échelle est beaucoup plus performante », constate Benjamin Fabre. « Les métriques des NLB sont les métriques qui remontent le plus tôt dans le processus ».
Or DataDome mettait deux minutes à recevoir cette métrique et une minute supplémentaire pour l’afficher dans l’outil de supervision CloudWatch, qui joue aussi le rôle d’autoscaler chez AWS.
« Désormais, nous avons un système qui agrège le volume de requêtes par seconde, ce qui nous permet de prévoir la montée en charge ». L’autoscaler maison consiste en un script Python sur une machine dédiée déployée dans chaque région AWS.
Ainsi, DataDome peut passer de 10 machines à une centaine en 30 secondes dans la plupart des régions cloud AWS.
Le fait de pouvoir démarrer plusieurs centaines de machines en parallèle n’est pas à la portée de tous les fournisseurs de cloud, assure Benjamin Fabre. « Lancer une centaine de machines en parallèle, cela peut faire peur aux fournisseurs. Nous avons négocié avec AWS pour faire sauter les limitations des services utilisés. La taille du fournisseur, ça compte », lance-t-il.
« Même chez AWS, c’est rare, mais pourtant cela arrive que l’on nous dise qu’il n’y a plus de machines disponibles ».
Benjamin FabreCEO et cofondateur, DataDome
À l’heure où les acteurs du marché vantent les capacités illimitées du cloud, le témoignage de DataDome bat cette idée en brèche. « Même chez AWS, c’est rare, mais pourtant cela arrive que l’on nous dise qu’il n’y a plus de machines disponibles ». Dans ce cas, les solutions ne sont pas nombreuses : attendre que des ressources se libèrent, qu’AWS en installe d’autres ou se fournir ailleurs.
« Même si les fournisseurs essayent d’abstraire leurs serveurs, dans notre cas à nous, nous atteignons régulièrement leurs limites ».
« En revanche, le provisioning en lui-même, chose que seul le fournisseur cloud peut contrôler, est plus performant chez AWS », vante Benjamin Fabre. « Nous avons testé tous les fournisseurs cloud et il y a un écart significatif entre celui offert par AWS et la technologie des autres. Le délai de provisionning chez les autres fournisseurs est au mieux moins rapide, au pire inconstant ».
De manière générale, DataDome trouve son compte auprès des équipes d’AWS.
« Les équipes techniques d’AWS sont très accessibles. Nous avons accès à la personne qui a développé le service ou qui le connaît sur le bout des doigts. Ils ne se contentent pas de “recracher” la documentation », se réjouit le CEO.
C’est notamment cette relation qui a permis de trouver la bonne métrique pour réduire au maximum le temps de démarrage des instances.
Une réflexion en interne pour réduire le nombre de fournisseurs cloud
Dans d’autres cas, la startup a mis de côté ses doutes pour tester l’efficacité des instances EC2 Spot. Si elles sont environ trois fois moins chères que les machines virtuelles standards d’AWS, le fournisseur ne donne pas de garantie quant à la durée d’exécution de ces instances. Après plusieurs essais, DataDome a identifié trois types d’instances EC2 Spot très peu volatiles, ou dont la chute a peu d’impact sur l’environnement de production de la startup.
Ce sont sûrement ces échanges qui détermineront si oui ou non DataDome se passera de ses autres fournisseurs.
« Nous aimerions bien utiliser les Local Zones d’AWS dans les régions où nous n’utilisons pas les services d’AWS actuellement, mais il y a encore des limitations par rapport à nos exigences. Cela nous permettrait de supprimer les autres hébergeurs, de rationaliser nos coûts et nos ressources cloud », annonce le CEO de DataDome.
En décembre 2022, Benjamin Fabre citait les États de la Floride, du Texas aux États-Unis, et la Pologne comme lieux d’implémentation envisagés pour ces Local Zones.
