30 milliards de requetes par jour avec une architecture NoSQL

Transcript

Do we have any non-French speakers in the room? Please raise your hand if you don't speak French. Ok, parfait. Très bien, donc on va faire en français. Bonjour, Julien, je suis vice-président engineering de Criteo et on va parler un petit peu de volumétrie aujourd'hui. Pour les quelques personnes dans la pièce qui n'auraient jamais entendu parler de Criteo, il doit bien rester une ou deux, je vais vous expliquer en 30 secondes ce qu'on fait. Donc on est le leader dans le secteur de la publicité en ligne sur ce qu'on appelle le display à la performance, l'affichage à la performance. Qu'est-ce que c'est l'affichage à la performance ? Ça se passe en quatre étapes, très simple. Première étape, vous allez sur un site e-commerce qui a de bonnes chances de faire partie de nos clients. Et puis vous allez consulter des produits. Vous allez cliquer sur des produits, rechercher des produits. Mais dans 97 ou 98% des cas, vous allez quitter ce site sans acheter quoi que ce soit. Et puis ensuite, vous allez continuer votre session de navigation sur Internet. Vous allez lire les informations, vous allez sur Facebook, vous allez lire vos mails, etc. Et dans la très grande majorité des cas, sur ces sites, on aura l'opportunité de vous afficher des publicités. Puisque n'oublions pas que si internet est très majoritairement gratuit, c'est parce que les sites peuvent se financer avec des revenus publicitaires. Voilà, c'était la seule phrase marketing de la présentation. Mais j'aime le rappeler de temps en temps à des esprits un peu chagrins. Et donc, lorsque vous allez sur votre portail de news ou votre site social préféré et si ce site fait partie de notre réseau, notre plateforme va être appelée et en temps réel on va décider ou non d'acheter l'espace publicitaire en question et si on l'achète, on va construire toujours en temps réel une bannière totalement personnalisée avec un annonceur, des produits, un look and feel, tous les éléments graphiques seront personnalisés, en fonction de vos intérêts ou en tout cas de ce que nous pensons à l'instant T être vos intérêts. L'objectif évidemment c'est de vous montrer une manière pertinente et de vous inciter à cliquer dessus pour vous ramener sur le site de l'annonceur et que si tout se passe bien ce clic se transforme en vente. Voilà donc l'affichage à la performance c'est ça. C'est afficher des bannières personnalisées pour générer des clics qui eux-mêmes doivent devenir des ventes. Voilà. J'en dirai pas plus sur le sujet. Si ce n'est que, comme vous pouvez le constater, ça a l'air de fonctionner, puisque Criteo a été créé en 2005, a vécu un premier cycle jusqu'en 2008, où le business model et le produit ont été assez profondément remaniés. Et depuis cette époque-là, le décollage est extrêmement rapide et soutenu. Aujourd'hui, on est plus de 700 dans le monde. On a plus de 3000 clients. Donc, ce sont les grands sites e-commerce, les grandes marques, les sites de voyage, les sites de petites annonces. Enfin, c'est assez varié. On est présent dans 35 pays, donc on livre du trafic dans 35 pays, on a des bureaux dans 15 pays, Europe, États-Unis, Amérique du Sud, Japon, Corée, etc. Voilà, donc une croissance très très forte, et c'est ce qui va nous amener à parler d'infrastructures. Alors j'ai dit qu'on était dans 35 pays sur toutes les grandes zones géographiques, donc sans surprise on va devoir avoir des data centers. Ces petites étoiles là sont nos data centers dans ces différentes zones donc 3 en Europe, 2 aux États-Unis, 2 au Japon. Alors pourquoi est-ce qu'on en a dans chaque zone ? En théorie on pourrait tout servir de Paris, on pourrait livrer des bannières de Paris à Tokyo, il n'y a pas de problème technique particulier pour le faire si ce n'est qu'on n'a pas encore réussi à battre la vitesse de la lumière et que même sur des liens rapides, faire 15 000 km, ça prend un certain temps, c'est ce qu'on appelle la latence, et c'est notre ennemi numéro un. Plus une bannière va s'afficher lentement, moins elle va cliquer. Elle va apparaître très lentement dans la page et elle n'aura aucune efficacité. La raison pour laquelle on a des data centers locaux, c'est déjà se rapprocher des clients, se rapprocher des utilisateurs finaux. Pourquoi on en a plusieurs par zone ? Tout simplement pour des raisons d'équilibrage de charges et pour des raisons de haute disponibilité. Donc si un de nos sites tombe, en Europe par exemple, les deux autres vont pouvoir prendre la main automatiquement en quelques secondes. Tous les sites sont actifs et donc ils peuvent pallier la défaillance d'un de leurs homologues. Donc je l'ai dit, 7 data centers. Alors on s'appuie sur des data centers existants. Néanmoins, à part louer du mètre carré et acheter de l'électricité dont on espère qu'elle ne s'éteint jamais, on fait tout le reste. On achète le matériel, on le déploie, on le câble, on l'opère, on le répare. Tout ça à partir de Paris. Ce qui veut dire que pour nous, la notion de business hours est un concept qui n'existe pas, puisque je dis toujours en plaisantant, quand je prends mon petit déjeuner, il peut y avoir un problème à Tokyo et quand j'essaie de me coucher, il peut y avoir un problème à New York. Donc on a une partie de l'équipe qui est en astreinte et qui gère à distance le bon fonctionnement de ces salles, des liens réseau, etc. On a une assez bonne disponibilité. Je refuse de mettre plus, ça porte malheur, mais en pratique, on fait mieux. Et donc, en termes de trafic, avec nos plus de 3000 clients, nos 35 pays, etc., on arrive donc à ce chiffre. Titre de la présentation, plus de 30 milliards de requêtes HTTP par jour. Donc, on parle de requêtes HTTP entrant sur la plateforme. Voilà, donc toutes les plateformes cumulées. Ce qui nous permet de servir plus d'un milliard de bannières par jour, bien plus d'un milliard, mais notre chiffre officiel pour l'instant c'est un milliard, avec un trafic pic qui est généralement début de soirée, qui se situe aux alentours de 500 000 requêtes par seconde et 25 000 bannières par seconde. Je vous incite à comparer ça aux stats que vous pourrez trouver sur les grands sites e-commerce français, européen, mondiaux. Si on était un site web, on serait un très très gros site web. Je pense que le monsieur qui a parlé avant moi pourrait éventuellement prétendre être devant nous, mais je pense que ça s'arrêterait là. Et on travaille d'ailleurs avec eux, donc ça va. Voilà pour le trafic. Alors, c'est des gros chiffres, ok, très bien, mais en quoi c'est un problème finalement ? Parce qu'on pourrait dire, oui, 30 milliards de requêtes, si c'est des requêtes "bêtes", il n'y a pas grand-chose à faire. Le truc, c'est que nous, on aime la data, donc on va tout loguer. Donc, ces 30 milliards de requêtes, c'est 30 milliards à peu près de lignes de log par jour. Bon, alors si on dit qu'une ligne de log, peu ou prou, ça fait un cas, parce qu'on log vraiment tout, on arrive à des gros chiffres en termes de données à stocker. Et donc on arrive assez vite dans le monde qu'on refuse d'appeler big data, parce que c'est un terme là aussi galvaudé et marketing, et vraiment on préfère parler chez nous de high performance computing parce que notre approche c'est ça, c'est trouver les solutions technologiques pour encaisser ces volumétries. C'est pas tellement d'aller... fabriquer un chaudron magique où on jette des trucs, des tweets, des likes, et puis on touille, et puis il sort quelque chose ou pas. Bon, ça, c'est pas du tout notre jeu. Nous, notre jeu, c'est ça. C'est tous les jours, on doit récupérer 20 teras de données supplémentaires de nos différents data centers et les amener au bon endroit pour qu'elles soient agrégées, traitées, requêtées, etc. Et donc, c'est vraiment une problématique technique. Alors, pour ça, on utilise, je dirais, tout l'arsenal du NoSQL et de l'open source en particulier. MongoDB, j'en parlerai un petit peu après. On utilise la distribution Cloudera d'Hadoop, je vais en parler aussi. On utilise Couchbase, alors pour être honnête, on utilise plutôt même cache et même base qui sont aujourd'hui inclus dans Couchbase, mais on n'utilise pas CouchDB. On utilise pas mal RabbitMQ comme système de message. Et puis de plus en plus, on utilise Storm et Kafka pour fluidifier nos chaînes de logs et essayer de les rendre un petit peu plus temps réel. Je n'ai toujours pas trouvé de logo pour Storm et Kafka. Je n'en ai pas, c'est trop récent. Parlons d'un premier cas d'utilisation chez nous qui sont les catalogues produits. Donc un catalogue produit, c'est un feed de produits qui va être livré par nos annonceurs, par nos clients, donc plus de 3000, et on y trouverait ce que vous attendriez à y trouver, c'est-à-dire des identifiants de produits, des descriptions, un prix, une catégorie, l'URL de l'image, etc. Ça, c'est des informations qui sont essentielles pour nous, parce que c'est à partir de ça qu'on va pouvoir construire les bannières. On en a de toutes les tailles, de toutes les couleurs, de tous les formats, ça va de quelques mégas à plusieurs dizaines de gigaoctets. On en a 30 à 50 % qui changent tous les jours, 30 à 50 % des produits qui sont modifiés tous les jours, ça paraît énorme, on se demande bien ce qu'ils peuvent changer là-dedans, mais on a énormément de modifications, donc ça veut dire beaucoup d'écritures en base de données. Ils sont importés une fois par jour au minimum, par une application maison. Dans certains cas, plus souvent, pour les ventes flash, par exemple, une fois par jour, ce n'est pas suffisant. On peut faire plus. On va répliquer ces données au sein d'une zone géographique. Un catalogue d'un annonceur européen, ces données doivent être présentes sur les trois data centers européens. Peu importe où il a été ingéré, il faut qu'on réplique. Ces données-là vont être accédées par des caches particuliers, les serveurs web au travers de cache, parce qu'avec le trafic qu'on a, il n'est pas question de taper une base de données directement. Donc beaucoup, beaucoup de cache. Et depuis le début, on utilisait Microsoft SQL Server. Voilà. Donc ça, c'était la base de données historique. Et pour être honnête, ça se passait plutôt bien en Europe, surtout parce que les data centers sont proches, il y a assez peu de latence. Mais malgré tout à force de grandir, à force d'ajouter des annonceurs et donc des bases de données pour ces annonceurs et donc des serveurs pour encaisser les bases de données des annonceurs, puisque sur un SQL serveur il n'est pas question de déployer 256 bases même si elles ne font pas grand chose. Ça c'est un truc qu'on a découvert à nos dépens. La taille des bases de données, etc. Et puis l'immense transparence et ouverture de SQL Server, surtout quand il ne marche pas, ont fait qu'on a commencé à se poser un certain nombre de questions. En se disant, on sent que la situation va vite se bloquer, et d'ailleurs elle s'est bloquée aux US. Pourquoi aux US ? D'une part parce qu'on avait de très gros catalogues, il y a d'énormes clients aux US, et parce que la latence entre les deux côtes, c'est plus de 70 millisecondes dans un sens. Donc quand on fait de la réplication transactionnelle, il y a pas mal de blabla qui passe sur les liens réseau et qu'avec une forte latence, ça n'avance pas. Donc on reste bloqué sur une magnifique barre de progression qui n'avance plus. Et là, on commence à se dire qu'il va falloir trouver une autre solution. Donc on a décidé de passer à autre chose et de sortir de l'impasse dans laquelle on était arrivés. Les impacts de fusils de chasse, ça doit être les miens, c'est bien probable. Et donc, après une étude relativement rapide et un choix d'emblée de passer en open source, on a choisi MongoDB. Alors, les personnes dans la salle qui ont fait des migrations de bases de données savent de quoi je parle. Déjà, même passer une version, quand on ne change pas de base, mais juste passer une version majeure, c'est généralement un calvaire. Alors quand on change complètement de produit et un peu de techno, ça peut faire assez peur. Pour une fois, on a été un petit peu prudent et on a essayé d'y aller tranquillement. Première étape, régler le problème de réplication. Le problème, c'était comment on réplique des centaines de gigaoctets par jour entre deux data centers éloignés de 70 millisecondes en termes de réseau. Donc ce qu'on a commencé par faire, c'est importer les catalogues et les répliquer dans MongoDB. Donc on avait des espèces de proxy MongoDB. Mais on poussait quand même le contenu dans les SQL serveurs. Et les web continuaient à taper les SQL serveurs. Bon, ça, ça a enlevé de la pression et ça a réglé le... au moins temporairement aux US. Ensuite, on s'est dit, maintenant, on veut arrêter d'écrire dans SQL Server, on veut que les web tapent directement Mongo. Comment ça se passe ? On a modifié nos applications. On a commencé à faire des tests tout doucement. On a mesuré, mesuré, mesuré. On a vérifié que ça se passait pas mal. Ensuite, une fois qu'on était rassuré, on a commencé à ouvrir les vannes et on a commencé à migrer nos milliers de catalogues vers Mongo. Et on a ajouté des serveurs et on a ajouté des shards, etc. Aujourd'hui, on a 150 machines, le Mongo en production. On a un tera de données en Europe, un milliard de requêtes par jour en Europe. C'est pas mal. Alors, deux ans et demi plus tard, comment ça se passe ? C'est assez stable, c'est facile. Tout le monde le dit, Mongo facile. On confirme. Ça marche bien si vous avez un dataset qui tient en RAM et si vous écrivez modérément. Et tout ce qui est failover et réplication, ça marche très bien. Il y a d'autres choses qui marchent moins bien. L'inverse, c'est-à-dire si vous n'avez pas assez de RAM, si vous écrivez comme des gorets et puis si vous essayez de faire coexister des applications différentes sur le même cluster, ça ne se passe pas très très bien. Donc il vaut mieux dédier vos box à des applications. Bon, il y a encore deux ou trois problèmes. J'étais à New York hier pour en parler avec eux, pour être transparent. On avance avec la roadmap sur eux, mais on pense que ça va aller dans la bonne direction. Deuxième cas d'utilisation chez nous, Hadoop. On a ces 20 teraoctets de logs. Il faut les cruncher dans tout un tas de scénarios, comment ça se passe. On a un premier cluster qui est en production depuis juin 2011. Alors pourquoi on en est arrivé là ? On en est arrivé là parce que la croissance du trafic était tellement brutale début 2011 que tous les outils existants et qui s'appuyaient aussi sur SQL Server se sont totalement englués et on était bloqués. Donc quand je dis express, c'est un terme poli, c'est à l'arrache la définition exacte. Voilà, et au fur et à mesure, on a remplacé tous les traitements traditionnels, donc des développements maison plus du SQL Server, par des jobs Hadoop. On a mis un certain temps à migrer, mais maintenant c'est fait. On s'en sert à la fois pour de la prod, c'est-à-dire faire tourner les jobs de prédiction, de recommandation, le machine learning sur les logs, et puis aussi pour de la business intelligence plus classique. Et on a eu un ROI très net, donc on a augmenté notre taux de clic, on a augmenté notre taux de conversion, voilà, et donc ça, c'est nous au moment où on a vu que nos investissements étaient justifiés, parce qu'on a quand même dépensé un petit peu d'argent dans tout ça. Voilà, et comme on est content, on vient d'en faire un deuxième, qui est en prod depuis un peu plus d'un mois, deux mois, qui fait 6 pétabytes. Et qui grossit encore. Alors Hadoop c'est super, mais attention quand même à 2-3 trucs. J'enfonce une porte ouverte, mais Hadoop c'est du batch. C'est pas du temps réel, et donc si vous voulez du temps réel, il faut que vous regardiez Storm. Attention à la façon dont les données sont présentées, ça a un impact énorme sur les performances des jobs. Donc il y a tout un tas de projets qui ont été créés, fait au fur et à mesure, RC file, etc. Et depuis peu, on travaille en collaboration avec Twitter et Cloudera sur un nouveau projet qui s'appelle Parquet. Et la première release est presque prête et on a de très bonnes perfs. Donc je vous conseille de regarder ça. Bon, vous savez tous que le name node est un spoff. Donc si vous ne faites pas de backup de votre name node, vous le paierez un jour ou l'autre. Et heureusement dans CDH4, vous pouvez faire de l'out dispo. Voilà. Si vous ne faites pas ça, vous êtes mort un jour, je vous le garantis, on parle d'expérience. La réplication HDFS n'est pas toujours ce qu'elle paraît être, il y a une notion de under-replicated blocks qu'il faut bien surveiller. Il faut avoir beaucoup de disques durs dans votre tiroir, vous allez en brûler plein. Il faut que vous inventiez vos outils Ops, Prod pour import-export, monitoring, métrologie parce qu'il n'y a rien dans Hadoop. Ce qu'il y a dans Cloudera n'est pas extraordinaire. Et si vous avez plus d'une centaine d'utilisateurs comme nous, mettez des quotas, travaillez sur le scheduling, sinon vous avez le dernier stagiaire arrivé qui fait tomber le cluster en une requête. Après, on s'occupe de lui. Et à l'échelle, il faut absolument avoir des connaissances en infrastructure. Il faut savoir choisir des serveurs, il faut savoir optimiser du réseau. Ce n'est pas juste du software. Il faut que vous ayez de bonnes compétences. Hadoop, c'est fabuleux, mais attention quand même à ne pas vous lancer à l'aveuglette sur une technologie qui est assez complexe. Voilà, j'ai terminé. Je vous remercie beaucoup de m'avoir écouté.