Les rendez-vous DevOps.
Interview, live et tableau ronde du DevOps.
Bonjour à toutes et à tous et bienvenue dans ce premier hors-série de DevOps.
Ce numéro spécial sera consacré aux intervenants du meet-up organisé par Critéo dans leur
locaux de Paris le 7 novembre dernier. Ce meet-up orienté à l'infrastructure est
à l'occasion de rencontrer des personnes travaillant sur des problématiques matérielles,
logiciels ou encore administratives. Au programme du transcaudage vidéo avec
DailyMotion, du déploiement de data centers avec Critéo et du provisioning bare metal
avec le bon point. C'est parti, on écoute ça.
Alors d'abord bonjour. Bonjour. Donc je vais essayer de présenter et d'abord
nous dire de quoi tu as parlé aujourd'hui au meet-up Critéo.
Alors je m'appelle Gilles Viera. Je travaille chez DailyMotion dans l'équipe vidéo architecture.
Donc ma présentation d'aujourd'hui c'était à propos de la conversion des vidéos chez
DailyMotion, donc le terme technique transcaudage et notre nouvelle technologie, enfin la nouvelle
technologie qu'on utilise qui est le transcaudage hardware en utilisant les GPU. Il faut savoir
que chez DailyMotion on transcote beaucoup de vidéos. Donc ce que je disais pendant
la présentation c'est qu'on a à peu près 20 millions de vidéos de transcaudage par
mois. Ça prend beaucoup de ressources, donc d'énergie, de CPU, de consommation d'électricité.
Ça veut dire d'argent bien sûr. Donc quand on peut optimiser on essaye et on a vu cette
solution assez récente en utilisant les cartes graphiques et qui apportait beaucoup
d'atouts que ce soit en termes de consommation d'énergie, en termes de performance et en
termes de prix à l'unité aussi. Et après comment vous avez fait pour convaincre en fait de passer
parce que ça demande de l'investissement forcément, si bien en termes de machine dans votre cas,
mais aussi en termes de temps, en termes de temps d'ingénieur. Comment ça s'est passé ?
Est-ce que ça a été compliqué en fait de convaincre d'aller vers sa solution en tout cas de la tester ?
Non pas spécialement, on l'a fait par littération. On a reçu quelques machines,
on a fait des tests, on savait que ça serait bien mais peut-être pas aussi bien. On a vraiment
testé, on a vu que les performances étaient très bonnes et que la qualité était vraiment
maintenue. Du coup par étape on a essayé, on a fait ça sur quelques machines, on a remplacé un
pierre de la ferme, un cas à la moitié et puis finalement on a fini par tout remplacer parce que
ça marchait bien. Donc il n'y a pas eu vraiment de switch complet de 0 à 100%, ça s'est fait par
étape. Quel est le principal problème rencontré celui qui aurait pu à un moment mettre en
péril le projet ? Est-ce qu'il y en a eu un ou pas ? Je dirais qu'il y a eu la qualité. On avait
quand même un petit doute au début sachant qu'on passe sur des technologies différentes,
moins éprouvées que l'encodage dans FFMP que tout ceux qui connaissent le domaine connaissent
et qui a été éprouvée dans le temps et on passe sur une technologie GPU qui était connue pour
ne pas donner des qualités aussi bonnes mais on a quand même fait beaucoup de tests et surtout
un facteur déterminant c'est une option de cet encodage qui est le looker head dont j'ai parlé
tout à l'heure qui permet de faire des analyses plus poussées sur les trams et obtenir une qualité
vraiment bonne et très proche de ce qu'on avait avant. La fierté c'est qu'on est parti d'une solution
qui était très peu utilisée, c'était très difficile de trouver des documentations, des informations,
des preuves que ça marchait et finalement on est arrivé à quelque chose qui nous a permis de tout
remplacer par cette solution donc on est assez content du résultat parce que c'était pas gagné
d'avance. Est-ce que tu as un dernier mot ? Bah écoutez je vous conseille tous de tester les
accelerations GPU et même chez vous si vous voulez convertir vos vidéos c'est top. Super,
merci beaucoup. Merci. Alors bonjour. Bonjour. Je vais te laisser d'abord te présenter. Alors je m'appelle
Nicolas Perret, je fais partie de l'équiposting chez Crypto et je suis là depuis trois ans. Aujourd'hui
j'ai parlé du processus d'appel-d'oeuvre chez Crypto comment on choisit nos nouveaux data centers.
Chez Crypto on grossit beaucoup donc le rythme qu'on a en ce moment c'est à peu près deux ouvertures de
site par an donc il fallait qu'on formalise tout ça parce qu'il faut qu'on aille plus vite déjà
dans les ouvertures et surtout c'est des très gros investissements donc on ne peut pas se tromper.
C'est pas quelque chose où si on ouvre un data center on se dit ah bah non on devait pas le
faire on vient de perdre 10-15 millions donc il faut vraiment qu'on ait un process clair et j'avais
presque mathématique sur comment on qualifie que ce data center là est bon ou pas. Est-ce que ça
était simple de convaincre sur toute cette méthode à mettre en place est-ce que il a fallu
ce que c'était un processus compliqué je ne sais pas si tu as même eu la réponse.
Alors il y avait un besoin de formaliser qui était là c'était sûr pour comme j'ai été
tout à l'heure pour pas se tromper dans le choix après ce qui a été un peu compliqué c'est de faire
un appel d'offre ça nous rallonge un peu le délai un appel d'offre et bah on va avoir besoin de
trois mois à peu près pour entre la rédaction du document et le dépouillement et le choix de la
personne qui va qui va être sélectionné donc il y avait cette petite crainte de genre
on travaille déjà avec un tel donc on a qu'à aller chez un tel et puis ce sera pareil et ça va être
très très vite été effacé quand on a vu les bénéfices de l'appel d'offre les sites qu'on
choisit qui sont mieux qui correspondent exactement à ce qu'on veut et une partie prix qui n'est pas
négligeable. D'accord et justement comment s'est passé un peu l'évolution est-ce que
il y a eu est-ce que ça a été compliqué ou est-ce que vraiment tout le monde a embrassé le
changement facilement ? Il n'y a plus de réticence il y a deux temps en temps une petite
tentation de se dire on a besoin d'une nouvelle salle vas-y on prend à côté mais ça s'efface
très très vite. D'ailleurs j'ai expliqué qu'on avait à peu près 300 questions pour qualifier un
data center ce qui nous prend le plus de temps c'est le dépouillement des questions on espère
que tout le monde nous répondent la même chose et des fois pour la même question on a des
réponses avec par exemple des unités différentes si on prend cet exemple là on va demander des
exemples bêtes quelle est la charge au sol il y en a qui vont nous répondre en kilo d'autres qui vont
nous répondre en newton donc qui vont nous répondre en nombre de racks qu'on peut empiler
les uns sur les autres du coup quand on doit comparer tout le monde il faut qu'on mette tout
à la même échelle. D'accord est-ce que tu aurais une fierté principal ? Il y a une fierté à chaque
fin de l'RFP en fait parce que tu as passé trois mois à qualifier ton data center et quand tu
l'as choisi et que tu vas et après on commence le déploiement sur site tu es content de te dire
bon bah on est où on voulait et tu vois le résultat et ça te fait plaisir. Super et enfin est-ce
que tu aurais un petit mot à quelque chose que tu n'as peut-être pas eu le temps de dire pendant le
meetup ? Non le meetup il était très orienté data center enfin très orienté RFP et c'est juste
que j'espère qu'on pourra en faire d'autres pour parler des parties un peu plus techniques sur
comment on déploie les serveurs etc. Super merci beaucoup. Merci.
Alors bonjour à vous deux je vais vous laisser vous présenter. Bonsoir moi c'est Xavier Krans
je suis SRE chez Le Bon Coin depuis janvier et moi c'est Félix qu'en tournais et donc je suis aussi
dans l'équipe SRE du Bon Coin depuis un mois et demi. Aujourd'hui on vous a fait une petite
présentation sur comment on est en train de changer notre provisioning baird métal chez Le Bon Coin
et principalement comment on utilise un tool qui est fait par Tumblr qui s'appelle Collinx pour
gérer l'infra et le lifecycle. Pourquoi en fait ? Pourquoi vous avez eu besoin d'arriver à cette
solution là ? Alors le Bon Coin c'est essentiellement une infrastructure bare métal donc là-dessus
on n'avait pas le choix et le workflow actuel était assez time consuming et du coup il fallait
absolument qu'on puisse l'améliorer et en même temps on a essayé d'introduire certains concepts
pour être un peu plus robustes et safe dans une optique SRE. On avait un espèce de setup
format qui marchait à peu près et il manquait en gros une composante lifecycle management qui
puisse du coup être intégré à l'outil qu'on utilise pour communiquer avec nos équipes dans les
data centers. En gros c'était un des trucs qu'on voulait avoir un truc qui gère la maintenance et
le décommissionnement et Collinx c'est ça. Super est-ce que ça a été compliqué d'amener
ce changement là ? Est-ce qu'il a fallu convaincre des gens ?
Alors c'est un changement. Le changement initial n'a pas été difficile à initier parce que d'ailleurs
en fait c'est pas nous qui l'avons initié. Tout le monde était conscient des problèmes que ça avait
et que ça impliquait sur l'infrastructure. Par contre après c'est comment tu sais que tu travailles
avec les gens, comment est-ce que tu fais évoluer, quand tu as des idées, comment est-ce que tu peux
brider certaines personnes en disant ok on va faire ça mais on va faire d'abord un VP et puis on va
passer à suite après. Donc tout le monde rapidement était d'accord pour faire des choses,
d'après ce qu'on m'a raconté. Le problème qu'on a pu rencontrer c'est simplement que parfois
on a voulu faire une modification un peu trop profonde ou toucher un truc un peu trop sacré et là
là on peut avoir un mur. Comment s'est passé l'évolution, le changement d'état en fait de
passer de la solution existante à la solution que vous avez proposée ? Est-ce que comment
c'est une transformation Big Bang ? Alors non globalement c'est une espèce de moitié
greenfield c'est à dire qu'en fait par exemple on n'est pas assez très vite dessus par la
présentation mais on a on a fait des subnets dédiés, deepam, manager automatiquement qui ont
vécu à côté des subnets deepam manuel existants et on a fait un peu tout comme ça en fait.
Donc on avait on a monté une sorte d'infra parallèle mais c'est pas vraiment non plus du
greenfield parce que à un moment ou un autre il faut s'attacher à l'infra existante.
Oui essentiellement ça et surtout que là où on intervient nous c'était essentiellement
sur le provisioning donc plus précisément sur le bootstrapping des OS et donc une fois que la
machine a un OS de base derrière il y a la config management classique qui est encore
utilisé aujourd'hui qui prend le relais par dessus donc au final ça va. Le principal problème c'est
commencer à développer quelque chose, une application parce qu'essentiellement chez le bon
coin on avait une culture très ad insiste et opérateur c'est à dire qu'on prend un truc
on l'installe et puis on le tape la cli et on automatise avec un script gel une crône et
en voiture simone. Là au sédiment il faut qu'on commence à développer un truc. Alors qu'est-ce
que ça veut dire développer à quel rythme on fait, est-ce qu'on m'é déteste ou pas, est-ce qu'on
déploie sur une instance de dev comme on peut la linéer et ainsi de suite. Tout une culture en fait
de développement qu'on n'avait pas et qu'on a dû apprendre sur le tas.
Ouais moi je suis arrivé ça c'était fait, c'est un peu con parce que moi j'étais dev mais du
coup d'un point de vue global le projet pour moi a le plus souffert du fait qu'on avait très peu
d'autométisation network, c'est encore un peu le cas et ça c'est assez chiant parce qu'en fait tu
te retrouves à faire de la compensation au niveau système de trucs qui devraient être network. Et
voilà donc typiquement pour faire notre environnement de dev et test on fait plein de tuto
qu'on pourrait ne pas faire du tout si on était dans un VLAN complètement isolé. Alors notre fierté c'est
que c'est d'être là ce soir déjà, de pouvoir le présenter à l'extérieur, d'être appuyé et de fait
qu'on aussi notre responsable Jean-Luc Bergamo il soit content qu'on soit là qu'on montre ce qu'on
fait et parce qu'on fait pas que du popo. On l'a aussi montré lors d'événements à peu près similaire
en interne il y a aussi un enthousiasme et ça c'était plutôt cool en fait pour des projets
de l'infrastructure où on se dit toujours en tant qu'il s'est mis de voir c'est bon on s'interesse pas
les autres. Donc ça c'est intéressant. Ouais je pense que c'est effectivement pour le moment c'est
la réception après on est enfin moi je considère qu'on n'a pas du tout fini le truc et donc ce
qui me plaît le plus dans le projet qu'on a actuellement c'est que j'ai l'impression qu'on
sait pas mis dans un coin ou dont on n'est pas pouvoir sortir en gros. Et enfin un dernier mot
ou quelque chose que vous n'avez pas pu dire pendant votre présentation ? En itorhique. Camolox,
bon ça a été facile. Non un truc dont on a parlé nous en off c'était quand on a quand
même découpé les choses en espèce de microservice parce que ça c'est le terme à la mode mais en
petite entité qui sa faire son job correctement et la phrase que j'aurais voulu dire et que je
ne sais pas pu dire c'était le schéma qu'on vous présente là est complexe certes mais pas
compliqué et c'est une grande différence à tous les détracteurs des microservice parce que
c'est complexe parce qu'il y a plein de petits morceaux qui doivent travailler ensemble mais
c'est pas compliqué parce que chaque morceau fait bien son taf et une responsabilité est
délimité et ça c'est quand même vachement appréciable quand on doit devoir réaliser,
quand on doit le montrer, l'expliquer aux gens et quand on doit débuguer un truc.
C'est bien, merci beaucoup. C'est sûr cette dernière interview que se termine ce court numéro
spécial. Un grand merci aux intervenants Gilles Viera, Nicolas Perez, Félix,
qu'entournait et Xavier Krans d'avoir répondu à nos questions et à Critéo pour l'organisation du
meet-up. C'était Guilem et moi-même Victor au micro et Bart à la technique. On se retrouve la
prochaine fois pour une nouvelle édition de DevOps, le podcast qui parle de DevOps. A bientôt !