Plus de 800 instances EC2, une centaine de rôles Ansible gérant des outils comme Cassandra, ElasticSearch, Storm et Kafka : le challenge relevé quotidiennement par les équipes d’infrastructure de GumGum fait de l’automatisation une ressource critique qui se doit d’être fiable à 100%. Mais pour répondre aux impératifs métier de mises en production fréquentes, la mise en place d’une organisation DevOps est une condition sine qua non. Lors du TIAD Paris, Florian Dambrine, ingénieur DevOps chez GumGum, a répondu à nos questions sur la transformation DevOps au sein de GumGum.

Quelle est ta mission chez GumGum ?

Aujourd’hui je travaille sur l’automatisation et le devops. Il s’agit de sensibiliser les équipes sur le fonctionnement d’une application sur AWS, de façon à les aider à construire et préparer leur application pour qu’elle soit optimisée pour le cloud, résiliente et scalable. Cette sensibilisation passe aussi par la découverte ou la formation à de nouvelles technologies, l’ouverture à ce qui se passe côté admin, comment cela fonctionne. Les choses évoluent et les développeurs s’intéressent de plus en plus à ce qui se passe en production, en dehors du code.

Qu’est-ce qui fait évoluer les mentalités vers plus de DevOps ?

Le DevOps répond au besoin d’accélération des mises en production. Une bonne communication et une bonne intégration entre les équipes sont indispensables à des mises en production rapides. Les deadlines de mise en production de nouvelles fonctionnalités sont parfois très serrées, et de fait les développeurs se rapprochent des ops pour savoir ce qui peut être fait de leur côté pour assurer une mise en production rapide dès que la version est stable.

« Test driven infrastucture with Ansible », par Florian Dambrine lors du TIAD Paris

Comment la technologie accompagne cette transformation DevOps ?

Le devops s’appuie essentiellement sur l’automatisation. 3 DevOps chez GumGum, 140 automatisations, 4 régions/comptes AWS différents et environ 1000 serveurs gérés par Ansible : ces chiffres permettent de se faire une idée, mais nous avons encore beaucoup de progrès à faire. Aujourd’hui, si on devait se donner une note DevOps, elle serait de 5/10. Cela pour dire que même avec une bonne intégration de l’automatisation il y a encore une grosse marge de progression pour être de vrais DevOps. Le DevOps doit pouvoir offrir des frameworks aux développeurs, leur donner des solutions ou des outils pour qu’ils puissent bâtir une application qui soit la plus proche possible du deploiement en production. Transférer l’application du développement à la production doit se faire en une fraction de seconde.

Quels sont les challenges pour progresser sur ce sujet ?

Cela demande du temps, parce que même si nous avons automatisé de nombreux process comme l’installation de logiciels, il nous faut un plus haut niveau d’automatisation. Il faut créer un cadre de référence, et les outils permettant de ne plus perdre de temps à créer un loadbalancer ou tout autre composant d’infrastructure dont on a besoin de façon récurrente. L’objectif est de pouvoir automatiser de A à Z toute l’infrastructure, et de permettre au développeur de livrer son code sans intervention des Ops, mais en s’appuyant sur un ensemble de bonnes pratiques, contrôlées par le framework Devops.

Quelle est la prochaine étape de cette évolution ?

Il s’agit de faire évoluer le framework vers un plus haut niveau d’automatisation, en automatisant toute la mise en place de l’infrastructure AWS. Cela pourrait se concrétiser dans un portail de services permettant de déployer chaque composant (loadbalancer, autoscaling, etc.) pour le développement ou la production en fonction du besoin. Autre axe d’amélioration de nos mises en production : Docker et les containers. Un fichier Docker fourni par un développeur, c’est comme un package, on doit pouvoir le mettre en production, mais là il faut mettre en place des bonnes pratiques, des règles de construction de ce fichier Docker.

L’introduction de Docker apporte certes des solutions, mais aussi de nouvelles problématiques. Comment pouvons nous réutiliser nos automatisations écrites dans un langage de plus haut niveau pour créer des images Docker de base (Framework Ops qui definit où est l’application, où vont les logs, le démon de supervision comme forever, supervisor, emperor, etc…), plutôt que de régresser et de retourner à l’écriture massive de Bash dans des DockerFiles ? Ainsi, les développeurs n’ont plus qu’a écrire au maximum 5 lignes dans un Dockerfile afin d’obtenir l’image de production.

Nous allons essayer de creuser ce sujet en amenant Docker dans certains projets, et cela demande de fournir certaines images Docker de base (créées par une automatisation Ansible) pour construire les applications rapidement.

Quels sont les outils que vous utilisez actuellement ?

Principalement Ansible pour le Configuration Management qui propose énormément de modules pour interagir avec AWS (démarrage de serveurs, management de security groups, VPC…). En déploiement applicatif, nous travaillons beaucoup avec Jenkins pour le Continuous Integration. Enfin, nous utilisons aussi de nombreux outils AWS, et CodeDeploy pour lancer un déploiement depuis une région de façon à ce qu’il soit ensuite répercuté sur d’autres régions.

Quel regard porte-tu sur l’automatisation ?

L’automatisation répond clairement à un besoin, mais j’irai même jusqu’à dire que cela a fait changer mon approche de travail. Quand je travaille sur un nouveau projet, le plus souvent j’écris directement l’automatisation. Par exemple, en ce moment je teste un nouveau serveur VPN (Pritunl Enterprise), je ne le configure pas à la main, j’automatise immédiatement, ce qui me permet de faire des tests facilement. Je ne fais presque plus d’administration manuelle. Par la suite, on peut toujours réutiliser ce code d’automatisation. Les outils, comme Ansible, sont très simples à utiliser, donc il ne faut pas s’en priver.

Quels sont les enjeux de BigData chez GumGum ?

Nous traitons environ 4Tb/jour de logs (données métier essentielles). En conséquence, nous avons un datawarehouse de plusieurs petabytes, et nous faisons tourner de volumineux jobs Spark pour traiter l’ensemble de nos données. Certains jobs tournent avec 200 machines Amazon. Récemment, nous avons monté un pipeline de traitements de logs (au sens d’une interaction, par exemple un clic sur une publicité) en temps réel, avec pour objectif de traiter 400 000 logs JSON/seconde pour prédire une augmentation du trafic. Comme certaines campagnes publicitaires ont des restrictions de cible (par exemple une thémathique particulière comme le sport ou l’alimentation, une tranche d’âge), quand on ne peut pas afficher la publicité correspondant à la cible, plutôt que de perdre cet espace publicitaire (inventaire), on lance un process de Real Time Bidding (RTB). Dans ce processus d’enchère en temps réel, nous contactons des partenaires avec un réseau d’annonceurs possibles. La meilleure enchère est ensuite sélectionnée et leur annonce affichée sur le site cible. Le RTB génère énormément de logs et d’informations, environ 8 à 10 fois le trafic habituel, et toute interaction durant ce process est loggée et traitée. Côté infrastructure, cela demande de s’adapter afin de pouvoir traiter, reporter et stocker toutes ces données.

Nous avons abordé lors du TIAD le sujet de la désautomatisation, qu’en penses-tu ?

C’est un concept intéressant, et si je dois reconsidérer ma façon de travailler sous l’angle de la désautomatisation, je réalise qu’aujourd’hui je travaille souvent avec le même outil, Ansible. Si je dois automatiser quelque chose, mon réflexe sera d’utiliser Ansible. C’est vrai qu’on a tendance à automatiser sa réflexion, utiliser les outils que l’on connaît, mais il faut garder à l’esprit que d’autres outils existent, savoir laisser ses habitudes de côté et sortir de sa zone de confort pour aller voir ailleurs, aller chercher plus loin. Chez GumGum chaque vendredi est consacré à l’exploration de nouveaux outils, nous essayons de nous former sur des technologies, creuser différents projets open source. Aujourd’hui j’explore Docker, Kubernetes par exemple. Il faut enlever ses œillères et aller voir ce qui se passe ailleurs!

Ivan Sigg dessinant Florian lors du TIAD Paris