Cet article fait partie de notre guide: Guide : tout savoir sur Hadoop

Bouygues Telecom déploie Cloudera pour réduire les incidents de la 4G

L'opérateur voulait comprendre à chaud les incidents réseaux en interprétant mieux ses logs. C'est chose faite avec la distribution Hadoop, qui lui a "fait gagner des clients entreprises" dixit son responsable SI Réseaux

par

Yann Serra, LeMagIT

Publié le: 22 juin 2015

« Nous sommes un acteur majeur de la 4G et nous avons la volonté d’offrir la meilleure expérience possible à nos utilisateurs sur l’ensemble de nos réseaux mobiles », tel est le leitmotiv de Stéphane Goyat, le responsable SI du réseau chez Bouygues Telecom.

Comme les autres opérateurs, Bouygues Telecom utilise des outils dits de QoS (Quality of Service) qui permettent à son réseau de véhiculer le mieux possible les données.

Mais si le QoS sert à contourner les incidents, les découvrir vite et les comprendre est une autre histoire.

« Le problème est que les indicateurs ne sont pas assez précis. Ce sont essentiellement des fichiers de logs avec des codes d’alertes difficilement déchiffrables par un humain et sans aucun recouvrement entre les informations géographiques, matérielles, etc. Nous visons l’Excellence of Service et pour y parvenir nous avions besoin de nous rapprocher au maximum du ressenti de nos utilisateurs », lance Stéphane Goyat.

C’est donc tout naturellement qu’il s’intéresse au phénomène Big Data dès que celui-ci commence à faire parler de lui, il y a un peu plus de deux ans.

Les possibilités de traitement de données hétérogènes en temps réel - pour transformer les codes des logs en messages compréhensibles par un humain - et d’affichage de courbes sur un outil de BI - pour avoir un aperçu à un instant T de l’état du réseau - l’intéressent au plus haut point.

Installer soi-même du Big Data grâce à l’Open source

L’équipe SI réseau Big Data passe toute la fin de l’année 2013 à se documenter sur les solutions possibles.

Stéphane GOYAT

Ils comparent en particulier les différentes implémentations d’Hadoop, la solution Open source la plus en vogue en matière de Big Data. « Nous avons en définitive retenue la distribution de Cloudera. Cette solution était la plus déployée sur le marché, ce qui nous permettait d’avoir un nombre suffisant de retours de la part d’autres utilisateurs. De plus, Cloudera inspirait particulièrement confiance avec la présence dans ses troupes de Doug Cutting, l’inventeur même du framework HDFS », se souvient Stéphane Goyat.

Surtout, le moteur Impala de Cloudera présente l’extrême avantage de pouvoir relier les traitements d’Hadoop aux tableaux de bord Business Object que les ingénieurs réseaux de Bouygues Telecom utilisent déjà.

Pour l’équipe réseau de Bouygues Telecom, le Big Data promet de ne pas représenter une rupture technologique trop importante. « Nous utilisions déjà des bases NoSQL pour faire des requêtes a postériori sur les fichiers de log. C’est la même technique qui sert à Hadoop pour traiter en temps réel ces données », indique Stéphane Goyat.

De fait, début 2014, Stéphane Goyat et son équipe entreprennent de télécharger et de déployer eux-mêmes la version Open source de Cloudera sur un cluster. « Nous mettons un point d’honneur à ne délivrer à nos utilisateurs que ce que nous savons faire, ce qui explique que nous ayons tout fait en interne », ajoute-t-il.

Un cluster pour tout savoir en 60 secondes

Le cluster Cloudera doit traiter 30 à 50 Go de données par heure, soit 20 à 40 000 événements par seconde aux heures de pointe. « Notre objectif est qu’il se passe moins de 60 secondes entre le moment où l’on collecte les logs depuis les cellules et le moment où les données sont utilisables par les ingénieurs. Pourquoi 60 secondes ? Surtout pour se fixer un challenge ; nos ingénieurs veulent que la solution soit la plus rapide possible et 60 secondes est un chiffre symbolique qui marque les esprits », témoigne Stéphane Goyat.

La configuration mise en place par l’équipe SI du réseau de Bouygues Telecom se compose alors de serveurs achetés chez HP. Chacun contient 36 à 48 To de stockage (sur 16 ou 12 disques selon les modèles), 32 cœurs Xeon et 128 Go de RAM. Ils fonctionnent sous le Linux CentOS 6.5. Sur les 30 nœuds du cluster, 20 font office de Data-nodes, c’est-à-dire de nœuds traitant et stockant les données.

« Nous avons passé trois à quatre mois sur la mise en place ce cluster. Car même si nous utilisions des scripts Ansible pour déployer automatiquement le système et les briques Cloudera sur chaque nœud, nous avons cherché longtemps le bon paramétrage de l’OS. Nous voulions avoir une démarche qualité dans la conception des règles de déploiement », se souvient Stéphane Goyat.

Comprendre à chaud et anticiper sur le long terme

En entrée, chaque fichier de log contient entre 20 à 30 informations sous la forme de codes numériques. Le cluster Cloudera, via les moteurs Spark et Flink de traitement des flux, transforment ces informations en des messages en français qu’il va chercher sur un dépôt interne.

Sur le même sujet

Cette donnée traitée est ensuite indexée dans une base NoSQL Elasticsearch, également stockée dans le cluster, mais sur des nœuds dédiés.

Enfin, le contenu de cet index alimente les tableaux de bord Kibana (également produits par Elasticsearch) sur le poste des ingénieurs. « Cette partie de notre solution permet aux ingénieurs d’identifier en temps réel un problème et sa cause sur le réseau. Le bénéfice est que l’ingénieur réagit plus vite. Il peut immédiatement lancer des procédures pour router les flux sur d’autres infrastructures du réseau, ou activer des services supplémentaires sur les infrastructures en place. On ne perd plus de temps à se demander comment résoudre le problème après avoir reçu un appel pour nous signaler une panne », raconte Stéphane Goyat.

Simultanément à l’indexation des signaux dans la base Elasticsearch, des batchs sont exécutés toutes les heures sur les données du cluster Cloudera pour croiser les indicateurs et dégager les tendances techniques.

« Nous faisons en quelque sorte de la maintenance prédictive. Nous voulons savoir comment se comporte tel type de smartphone connecté à tel type d’antenne dans telle zone, afin de bien mieux anticiper les incidents futurs que nous ne le faisions auparavant », commente le responsable SI du réseau.

Les batchs sont des scripts écrits par un datascientist pour les moteurs de traitements Spark, Flink, Hive (requêtes façon SQL) et Oozie (déclenchement de procedures).

« Notre datascientist - nous n’en avons qu’un - s’entretient régulièrement avec nos ingénieurs réseau sur leurs besoins. Puis son travail consiste à transformer ces besoins en formules. Et il est inutile de préciser qu’un profil comme le sien, à la fois expert en réseaux et en données, ne se trouve pas au coin de chaque rue », se félicite Stéphane Goyat.

Et aussi

Et d’ajouter que si le cluster Hadoop traite pas loin de 600 To de données par an, la plus grande partie de celles-ci est détruite au bout de quelques semaines, pour des raisons légales. « Il est donc nécessaire d’être très rapidement opérationnel sur les batchs. Utiliser une distribution comme Cloudera, avec toutes les briques déjà prêtes à utiliser est d’un grand confort. Nous sommes là pour produire du code métier, pas pour réinventer la roue », dit-il.

Gagner des clients en prouvant sa crédibilité

La solution a été montrée aux ingénieurs réseau à la rentrée 2014. « Le problème est que nos utilisateurs ont été emballés par ce qui n’était alors qu’une Proof-of-Concept. Ils ne pouvaient plus s’en passer. Nous avons alors décidé de souscrire à du support auprès de Cloudera pour passer au stade de la configuration critique opérationnelle », s’amuse Stéphane Goyat.

La solution est opérationnelle en 24-7 depuis le début de l’année 2015.

Stéphane Goyat en tire un bilan positif. « Elle nous a fait gagner des clients entreprises, car elle nous a rendus plus crédibles en prouvant que nous pouvions avoir des statistiques en temps réel et réagir aussi en temps réel. Les ingénieurs sont encore en train de prendre en main l’outil et le bénéfice le plus flagrant aujourd’hui est la rapidité de leur réponse aux incidents réseau. La partie maintenance prédictive est plus complexe et demande encore un peu de temps pour montrer des résultats tangibles », conclut-il.