Moving Viadeo to AWS

Transcript

Merci beaucoup. Bonjour à tout le monde. Ça fait toujours extrêmement plaisir de voir des conférences techniques à Paris. J'ai vécu une époque où il n'y en avait absolument aucune. Maintenant, il y en a de plus en plus. C'est génial. Je suis Julien Simon, je suis CTO de Viadeo. Et je vais vous parler aujourd'hui du choix qu'on a fait et de la migration qu'on est en train de mener. Je repositionne Viadeo en quelques instants. C'est une société française qui a été créée en 2005, qui est leader sur le marché français avec 9 millions de membres et qui, au fil du temps, s'est étendue en Russie, en Chine, en Afrique francophone. Voilà, c'est tout ce que je vais dire sur Viadeo, vous connaissez. Je ne suis pas venu parler spécifiquement de ça aujourd'hui. Viadeo en 2015, c'est toujours un réseau social professionnel. On a toujours des pages de profil. J'ai mis la mienne, vous m'excuserez. Je serais ravi de me connecter, n'hésitez pas. Donc toujours une page de profil, un flux d'actualité qui a été refondu très récemment, qui est beaucoup plus agréable et beaucoup plus riche, où vous voyez l'actualité de votre réseau, où vous voyez des suggestions de personnes à contacter, où vous voyez des articles recommandés, etc. Et puis de plus en plus, sur Viadeo, on va trouver de nouvelles fonctionnalités qui correspondent évidemment à de nouveaux projets. Alors j'en ai listé quelques-unes : Face to Face, qui permet de mettre en communication des recruteurs et des candidats de manière un peu différente qu'au travers d'annonces. Un autre service qui s'appelle Let's Meet, qui permet de faire des rencontres professionnelles, pour le reste vous faites ce que vous voulez, qui vous permet de rencontrer des clients potentiels, des candidats potentiels, enfin, de rencontrer physiquement des gens qui font partie de votre réseau. Et puis un autre service qui permet de noter son entreprise, qu'on appelle Rate to Company, qui permet de donner du feedback sur tout un tas de critères. Voilà, et donc tous ces projets, évidemment, ont été menés dans les mois passés, nécessitent du développement, nécessitent de l'infrastructure, et vont nécessiter une remise en cause dans certains cas de la plateforme, et donc vont poser un certain nombre de questions techniques. En termes d'infrastructure, aujourd'hui, on a une infrastructure qui est majoritairement physique, qui est hébergée aux États-Unis, on a à peu près 200 serveurs Linux. On utilise différents back-ends. Je suis sûr qu'il y a des gens dans la salle qui utilisent aussi ces technos-là. On a du MySQL, on a de l'Elasticsearch, on a du Hadoop, on a tout ça. Et surtout, on a une plateforme de service qu'on appelle Casper, qui a été développée en Java à l'époque, qui est, je n'ai pas peur de l'affirmer, le plus beau design web que j'ai eu l'occasion de voir. Et je le dis d'autant plus aisément que je ne suis pas l'architecte de cette plateforme. Voilà. Donc c'est une plateforme qui est basée sur un pattern qui s'appelle CQRS. Je vous laisse regarder ça sur Wikipédia ou ailleurs. Il y a peut-être des gens qui font du CQRS dans la salle, ça m'intéresserait d'en discuter avec eux. Donc CQRS, c'est tout simplement séparer au niveau de l'architecture les commandes entrantes et les commandes sortantes, d'avoir des flux totalement séparés. C'est une plateforme qui est événementielle avec un bus de données et tous nos projets sont développés suivant DDD en domain driven design. Donc voilà, très belle plateforme Java qui a été totalement refaite en 2014, qui est en production et qui est très modulaire, ce qui va être important pour la suite. Au-dessus de cette plateforme, on a une application web qui a été développée en Node.js, qu'on appelle Limbo. Donc le front de Viadeo que vous voyez aujourd'hui, c'est ça, c'est du Node.js. Plus tous les frameworks JavaScript à la mode que vous pouvez imaginer. Et évidemment, on a des applications mobiles. C'est une grosse partie de notre trafic aujourd'hui. Donc on a des applications iOS, Android qui tournent sur à peu près tous les devices que vous pouvez avoir dans votre poche. Voilà, donc un stack relativement riche, une plateforme relativement complexe, une taille d'infrastructure qui est déjà respectable. Donc ça c'est pour la partie physique. Et c'est ça qu'il va falloir déménager. Néanmoins, via des hauts utilisent AWS depuis un certain temps et je trouvais intéressant de revenir aussi sur ça. Comme tout le monde, on a besoin de stocker des fichiers, on a besoin de stocker des backups, on a des archives, des snapshots de bases de données, tout ce qu'on peut imaginer. Donc ça commence évidemment sur S3. En 2012, Viadeo a eu un petit souci au siège, une petite inondation, ou une grosse inondation, et les quelques serveurs qui étaient hébergés là-bas, donc pas les serveurs de production, j'insiste, mais les serveurs d'IT interne, les serveurs de développement, etc., ont subi un léger souci. Et voilà, tout a été complètement détruit, l'armoire électrique, les serveurs, tout est parti à la poubelle. Jamais personne ne montre ça, mais moi j'aime bien montrer ce qui marche pas, donc voilà, je trouve ça rigolo. Ce qui est surtout intéressant, c'est que tout a été reconstruit très vite. Le choix traditionnel aurait été de commander des serveurs, des switches, de passer la serpillière et de repartir pour un tour. Ça aurait pris un peu de temps. Et donc, ils ont fait le choix de dire : "Bon, non, on va dans AWS, go." Tout a été refait en deux jours. Il y avait entre 20 et 30 serveurs. Une certaine taille déjà. Et donc là, ils ont commencé à faire du VPC, à faire des VM, etc. Et je trouve très intéressant finalement que le vrai déclencheur de l'adoption d'AWS chez Viadeo, ça soit un désastre. C'est un moment où on se dit : "Oui, on peut appeler l'intégrateur, on peut commander des serveurs, mais ça va prendre des semaines. Est-ce qu'il n'y a pas une autre solution ?" Et bien il y en avait une. Ensuite, Viadeo s'est mis à faire de plus en plus de traitements de données, à faire du MapReduce, à faire des choses comme ça. Notamment pour faire ce genre de petits services, de petites boîtes, proposer des données sur le front. Et ça continue. Donc plus de data, toujours plus. Aussi bien pour le site, pour la partie visible, que pour l'analytics. On a une nouvelle infrastructure analytics qui utilise un logiciel qui s'appelle Snowplow, qui n'est pas une technologie Amazon, mais que je vous recommande, qui permet d'avoir des trackers de données vraiment super, hautement recommandés. Donc on stocke dans S3 et après on envoie dans Redshift. On a commencé à faire deux, trois trucs, on est vraiment juste au début de cette histoire-là, et on a à peu près 20 millions d'événements par jour aujourd'hui. Et puis on a aussi de la personnalisation de contenu, donc les fameux articles qui peuvent vous intéresser avec du MapReduce, avec du Spark, etc. Donc un point de départ finalement désastreux au sens propre du terme et puis après plutôt de l'infra froide, c'est-à-dire du back-end, du traitement de données, du stockage, etc. Pas vraiment de choses en lien directement connecté au site. Et donc tout ça, ça nous amène aujourd'hui à un point où on a de l'infra dans trois régions, deux aux US, et puis quelques petites choses en Europe, mais très très minimes. Quatre VPC, une centaine d'instances réparties entre strictement de l'interne et de la production. Un peu de stockage dans S3. Voilà, alors pas mal de services, je les ai tous listés parce que, évidemment, quand on dit qu'on utilise EC2, S3, etc., on a envie d'utiliser assez vite, on utilise IAM pour l'authentification, assez vite on va faire du load balancing, etc. Finalement, au fil du temps, sans avoir l'impression d'en faire beaucoup, Viadeo a adopté pas mal de services qui ont été utilisés. Ça nous amène donc à fin 2014 ou un certain nombre de questions se posent sur l'infrastructure physique. La première, c'est comment améliorer l'agilité de l'infrastructure parce que tout le monde parle toujours d'agile, donc on parle de gestion de produits, d'MVP, de trucs comme ça en dev, et puis après à un moment, tout ce petit monde-là, je l'espère, est efficace, va vite, et puis à la fin quelqu'un dit : "Ah ouais, mais au fait, il nous faut des serveurs." Je parle d'expérience, il va nous falloir 200 serveurs pour lundi, est-ce que tu peux ? Et bien non, je ne peux pas. Je ne les ai pas, désolé. Et donc ce problème-là, finalement, la scalabilité doit aller jusqu'au bout de la chaîne. Et l'agilité, elle doit aller jusqu'au bout de la chaîne. Sinon, vous êtes très rapide au début, et puis après vous êtes scotché pendant des semaines en attendant que votre constructeur, votre intégrateur vous livre. Et puis il y a le côté expérimentation. Comment est-ce qu'on a envie de se monter un cluster Hadoop ou que sais-je pendant une semaine pour faire un truc. On a envie que ça aille vite, on n'a pas envie que ça coûte cher. Comment on fait ? Même si on a des serveurs sous la main, on préfère les garder pour de la vraie prod. Alors comment on fait ? Le deuxième point, c'est un sujet important pour tout le monde, qu'on soit une petite startup ou une boîte déjà établie, c'est est-ce que je dépense mon argent efficacement ? Et là, il y a vraiment deux points. Est-ce qu'on peut éviter de faire des gros chèques à chaque fois qu'on a envie d'ajouter de l'infrastructure ou de rafraîchir l'infrastructure ? Est-ce qu'on peut éviter le sketch avec le CFO sur "Je t'assure, il me faut un million de dollars, sinon on ne va pas y arriver" ? Et puis, deuxième point, est-ce que la nuit, finalement, je ne peux pas éteindre 80% de mon infra parce que je n'ai juste pas de trafic à cette heure-là ? Le troisième point qui est important, c'est comment est-ce qu'on peut avoir un plan de disaster recovery plus efficace que ce qu'on a aujourd'hui ? J'ai mentionné que notre data center était à San Francisco. Vous imaginez assez bien le genre de cauchemar qu'on peut faire ? Donc on a un plan de disaster recovery, mais il est perfectible et on veut travailler là-dessus. Et on n'a pas envie de bâtir un deuxième data center. On pourrait trouver une zone où il n'y a pas de tremblement de terre, pas d'inondation, pas de choses comme ça. Ça doit exister, mais on n'a pas envie de bâtir un deuxième data center. Et puis il y a toujours ce point-là qui est plus de data, plus de data, plus de data. Et typiquement, pour faire du Hadoop, pour faire du Spark, pour faire de l'Analytics à gros volume, il faut de gros serveurs. Ce ne sont pas les petites configurations. Il faut beaucoup de disques. Et ça, en hébergement traditionnel, ça coûte cher. Et c'est d'autant plus embêtant que généralement, ce sont des charges qui ne sont pas des charges lissées. Il y a des gros pics pendant une heure et puis après, il n'y a plus rien pendant peut-être deux jours. Dimensionner au pic pour des serveurs qui ne font rien 95% du temps, c'est un peu dommage. On a creusé ça. Ce débat-là a eu lieu pendant un certain temps chez nous. On a fait pas mal d'études et on s'est dit qu'on ne voyait finalement qu'une bonne solution qui était... de tout mettre dans AWS. Et pareil, Stéphane l'a expliqué tout à l'heure, mais le point important pour nous, c'est qu'on veut faire notre vrai boulot. Alors chacun peut avoir sa définition du vrai boulot, mais en tout cas dans mon équipe, personne ne considère que c'est son boulot d'aller changer des disques durs cassés ou d'aller ouvrir des cartons et de raquer des serveurs pendant des jours et des jours. On a tous fait ça, ça a été amusant jusqu'à un certain point, je pense que maintenant, on a envie de faire autre chose. Et autre chose, c'est améliorer notre site, améliorer nos services. On ne veut plus avoir d'ennuis avec les constructeurs de matériel, on ne veut plus avoir d'ennuis avec les intégrateurs, on ne veut plus avoir d'ennuis avec les licences. Je pourrais écrire un livre sur le sujet. Je ne veux plus passer ma journée et ma soirée et mes week-ends à gérer ce genre de problème. J'en ai ras-le-bol, je le dis. Je suis désolé s'il y a des constructeurs ou des intégrateurs dans la salle. De toute façon, je me suis fâché avec tout ce que je veux dire de France et de Navarre donc il n'y a aucun problème. L'expérimentation, le redéploiement, le scaling, tout ça c'est à portée de clic. Et puis il y a un point qui peut-être vous n'avez pas encore étudié à fond mais c'est l'écosystème finalement de toutes les boîtes, toutes les boîtes SaaS qui tournent dans AWS. Alors ça change tous les jours, il y en a plein, mais ça devient presque un réflexe de dire : "Tiens, on voudrait faire ce truc-là, est-ce qu'il y a pas quelqu'un dans un partenaire SaaS dans AWS qui fait déjà ce truc-là ?" Voilà, c'est assez intéressant, ça accélère encore vos projets. Bon, il y a un point, j'enfonce une porte ouverte, mais on l'utilise depuis des années, ça marche, voilà, ça marche, il n'y a pas vraiment de soucis, pas vraiment de surprise en tout cas beaucoup moins qu'avec de l'infrastructure physique. CloudFormation, c'est de la magie, voilà, c'est magique. C'est une structure à Scott, on pousse dans GitHub et puis on a des serveurs. Moi je vais vous montrer ça après, c'est super, j'adore. Et le time to serveur, on part toujours de time to market, mais dans le time to market, il y a un petit la fin du planning qui est le time to serveur et il est en minutes, voilà, il est en minutes, pas en jours, pas en semaines, pas en mois. Il y a un point aussi qui est important pour nous, c'est qu'on est prêt à le faire et on a envie de le faire. On n'a pas de soi-disant problème culturel où on n'a pas de résistance du tout. On a vraiment des gens qui ont envie d'y aller, autant les devs que les ops, même si chez nous la frontière est de plus en plus floue. Il n'y a aucun problème de genre là, il n'y a pas de bataille, il n'y a pas de précarité. Donc on veut tous y aller. Voilà, c'est pour ça que j'ai choisi cette image de fond parce que vraiment elle représente bien notre état d'esprit aujourd'hui. Le dernier point qui est quand même important aussi, c'est qu'on veut mesurer assez finement le ROI et optimiser le coût de nos projets et avec AWS, c'est assez facile de taguer ses instances et de voir combien ça coûte, puis on a la facture détaillée. Voilà, nos principes, c'est quoi ? C'est l'automatisation, on veut tout automatiser, absolument tout. Il doit rien y avoir qui doit être automatisé qui peut être automatisé qui ne le soit pas. Tout doit être scalable, si possible automatiquement, et on veut une sûreté de fonctionnement élevée. Il y a le côté disaster recovery donc le côté haute disponibilité, mais il y a aussi le côté "ça doit marcher tout seul" et on doit pas se lever la nuit. On veut faire de l'intégration continue et du continuous delivery à tous les niveaux, sur l'infra, sur les instances, sur les applicatifs. Tout doit être testé et validé avant de partir en prod. On a fait le choix d'avoir une intégration profonde avec les services d'AWS. Quand je dis profonde, c'est qu'on va profondément utiliser les VPC, on va profondément utiliser IAM, on va profondément utiliser d'autres services comme ça de base. On n'essaie pas d'abstraire AWS. On va dans AWS et on y va pour de vrai. On veut vraiment avoir l'effet de levier maximum sur l'élasticité, le load balancing, etc. Pour la partie applicative, on va garder notre stack pour l'instant. Donc, on ne va pas remplacer tous nos MySQL par RDS juste pour le plaisir. On va essayer d'être assez conservateur là-dessus, il y a déjà pas mal de boulot, sauf s'il y a vraiment, voilà, si c'est trop bon pour passer, sauf si vraiment c'est une idiotie de ne pas aller sur une techno, comme en l'occurrence Redshift, je suis assez fan de Redshift, et il faut se dire que là, peut-être, effectivement, il faut transitionner un bout de l'infra. Donc on va tout bouger, mais on ne fait pas de Big Bang, cette erreur-là, je l'ai déjà faite, je ne recommencerai pas. Donc on y va graduellement. Et donc il faut se dire qu'on va avoir du parallel run. On va avoir un bout de plateforme front dans AWS, un bout de plateforme front dans notre data center. Donc il faut réfléchir à ça. Alors j'ai parlé d'infrastructure Ascot, donc je vais vous montrer comment on l'a fait. Au passage, je tiens à saluer les gens de mon équipe qui sont dans la salle et qui ont beaucoup travaillé là-dessus. Je ne fais que présenter. C'est eux qui ont fait tout le boulot. Donc on va pousser dans GitHub notre config Puppet et notre config CloudFormation. Il y en a un bout qui va partir dans Jenkins et dans Packer pour bâtir l'image. Le reste va aller dans CircleCI pour validation. Puis dans S3. Donc là, dans S3, on a notre infrastructure qui est décrite exhaustivement et validée. On additionne les deux, on jette tout ça dans CloudFormation et on a des serveurs. Et ça, c'est magique pour quelqu'un qui a passé quelques années de sa vie à acheter beaucoup de serveurs et à attendre patiemment qu'ils soient déployés, enfin, installés, etc. C'est de la magie et je ne ferai pas marche arrière. Je pense qu'une fois qu'on l'a utilisé, on ne fait pas marche arrière. Et donc, le chemin complet, là, c'est quelques minutes. Il y a quand même quelques points à valider et à travailler. Alors, on a une plateforme qui existe. Si vous partez d'une feuille blanche, c'est une chose. Nous, on a déjà une plateforme, on a déjà des technos, on a déjà des choses. On essaie de ne pas faire complètement copier-coller de la plateforme dans AWS. Il y a des choses qu'on a envie de changer, qu'on doit changer, mais on ne peut pas tout changer. Donc, il faut accepter à court terme quelques compromis sur la performance et sur le coût. Il y a certains bouts de la plateforme qui fonctionneront peut-être un peu moins bien ou un peu plus cher dans AWS que dans l'infra-physique, bon, OK, tant que ça reste acceptable, eh bien, on l'accepte. Évidemment, vous savez bien, tous les gens qui ont déménagé le savent, quand on habite depuis des années au même endroit et qu'on déménage, on trouve des trucs sous le tapis, on trouve des trucs, on ouvre tous les placards, on vide tout et on a des surprises. Alors, de temps en temps, de bonnes surprises, et souvent de mauvaises. Donc, toute la dette technique que vous avez accumulée sur l'infra, vous allez la retrouver, elle va vous bondir au visage. Quelques exemples qui nous tracassent en ce moment, toutes les règles de load balancing. Donc on a des load balancing matériels et au fil des années, ils ont accumulé un certain nombre de règles, de réécriture d'URL, de routage de trafic, des choses comme ça. Et là, il va falloir les démarquer parce que sur l'élastic load balancing, on ne peut pas le faire. Et donc, ça, c'est vraiment je vous conseille d'utiliser le moins possible de ce genre de trucs si vous avez des load balancers, vous le paierez plus tard. Tout le monde a un petit filtre ou deux dans un coin qui est utilisé par tous les serveurs de la plateforme, il va falloir le bouger, il va falloir trouver ce qu'il y a dessus, etc. Puis tous les vieux serveurs oubliés dans un coin qui servent encore un peu mais qui ont un vieux MySQL très très vieux ou qui ont une vieille version de n'importe quoi. Il va falloir soit les réinstaller, soit les garder comme ça. Il faut choisir. Enfin voilà, bref, tout ce que vous avez accumulé, toute la poussière, toutes les vieilleries que vous avez laissées traîner, là maintenant, vous allez devoir les nettoyer. Donc il faut prévoir ça dans le projet. On a dit qu'on voulait faire... ou en tout cas qu'on allait faire du parallel run. Donc ça suppose une bonne connectivité entre votre infra historique et le cloud. Donc là, il y a un produit qui s'appelle Direct Connect, qui est un lien réseau dédié. Bon, fortement conseillé, ça ne coûte pas très très cher, et puis ça vous permet d'avoir un lien dédié, fiable, et sur lequel vous pourrez faire vos migrations de données, votre monitoring, enfin tout ce que vous voulez. On pensait dégager tous nos CDN et mettre CloudFront partout. On s'est rendu compte que la performance de CloudFront entre régions n'est pas extraordinaire. Elle est dans la petite moyenne. Donc on a fait le choix de garder un deuxième CDN pour les parties du site qui sont les plus importantes en termes de performance. Si vous déployez dans la même région que vos utilisateurs, il n'y a pas de problème. Mais pour nous, comme on est aux US, c'est un peu compliqué. Et puis quand même, histoire de se fâcher encore un peu avec des fournisseurs, on a des engagements de contrat sur notre hébergement historique. Malheureusement, il va un peu plus loin que ce que j'aimerais et il va falloir le terminer. Donc c'est une négociation qui est un petit peu compliquée. Donc mon conseil là-dessus, c'est faites très attention au renouvellement automatique et faites très attention aux durées de vos contrats. Plus c'est court, mieux c'est, parce que le jour où vous voulez sortir, ils ne vous feront pas de cadeau. Qu'est-ce qu'on peut dire en conclusion ? Déjà, on peut dire qu'on est en plein dedans. Donc j'espère que j'aurai le plaisir de revenir dans quelques mois pour vous dire que c'est terminé. Mais franchement... Il y a quelques années, j'ai mis ça à cette date un peu au hasard, mais c'est vrai qu'en réfléchissant, c'est à peu près l'état d'esprit d'il y a cinq ans, c'était : "Mais pourquoi est-ce qu'on ferait du cloud ? Pourquoi ?" Non, on a un métier, on sait faire de l'infra-physique, on pense que c'est essentiel, etc. Qu'est-ce qu'on irait faire dans des plateformes virtuelles ? Bof, on ne veut pas. Et franchement, maintenant, la question c'est pourquoi ? pourquoi ne pas y aller ? Et je vous dis ça d'autant plus aisément que pendant à peu près dix ans, moi j'ai fait de l'infra-physique. Et je me dis franchement, je vois les problèmes que j'ai eu avec ça et le gain que je peux avoir avec un cloud comme AWS, je me dis pourquoi je n'irai pas ? Qu'est-ce qui fait que je n'irai pas ? Alors, je ne suis pas évangéliste AWS, je le précise donc il peut y avoir de bonnes raisons de pas y aller, il peut y avoir de bonnes raisons de pas y aller, on pourra en parler, j'ai plus de temps, je vais pas l'aborder, j'entends très bien que certaines sociétés ont des raisons importantes bloquantes pour y aller, mais franchement, la plupart des gens avec qui je discute, c'est juste de mauvaises raisons, voilà, c'est juste de mauvaises raisons. Donc soit ils ont la trouille, soit ils ont une équipe de prod qui traîne les pieds, soit... soit, soit, soit. Bon, voilà, on peut en parler après, mais je pense que la plupart des raisons, on peut les démonter assez facilement. Alors après, on entend toujours, c'est une mode, ça y est, voilà, c'est la mode. Non, moi, je ne pense pas que ce soit une mode. Je ne pense pas que ce soit une mode. Vous avez vu la liste des boîtes ? C'est marrant de les appeler encore des startups tellement elles sont énormes et tellement elles gagnent d'argent, mais bon, vous avez vu la liste tout à l'heure. C'est une mode ça ? Enfin, moi je ne crois pas. Le cloud pour moi c'est juste la manifestation digitale de l'infrastructure. Si on pense que le cloud c'est une mode, alors la photo digitale c'est une mode, le MP3 c'est une mode, les DivX c'est une mode. PayPal, c'est une mode, Bitcoin, c'est une mode. Alors, tout est une mode à ce moment-là, et puis on continue à vivre dans le passé. Voilà, c'est juste maintenant, comme tout le reste, l'infrastructure est digitale. Vous écrivez votre config, vous la poussez, vous avez vos serveurs. Voilà, c'est tout, il faut l'admettre, le monde a changé. En tout cas, en ce qui nous concerne, on peut constater chaque jour qu'à AWS, nous aide à améliorer notre site, nous aide à innover plus vite, à livrer plus vite. C'est juste une réalité. Voilà, j'espère vous voir prochainement sur Viadeo. Je vous remercie beaucoup de votre attention. Je voudrais remercier également Amazon de m'avoir invité. C'est toujours un plaisir de participer. Et puis, last but not least, je voudrais remercier mon équipe pour le super boulot qu'ils font sur ce projet comme sur tous les autres projets. Merci beaucoup et bonne journée.