Un parc informatique d’un millier de machines génère de nombreux Terra Octets de logs. Comment parvenir à y retrouver une information pertinente et comment valoriser les informations contenues dans ces logs ? Au programme : - La centralisation des logs : back to basics; - Cas pratiques : détection d’attaques DoS et refacturation sur plateforme mutualisée; - Une grille Hadoop : en quoi ça consiste ?

1. BarCamp « Big Data, ou comment retrouver
une aiguille dans une botte de foin »
Janvier 2014 @ Paris
Pierre REVELLIN
Responsable Architecture
et Performance

2. 2
Au programme
Contexte et origine du besoin
La première ébauche
Le vrai problème : les ressources CPU vs IOs
Hadoop, une vulgarisation :
Partie 1 : Le stockage
Partie 2 : Le traitement de données
Partie 3 : Quelle implémentation ?
Intégration dans un SI
Big Data au delà d'une mode
Comment valoriser des téra/pétaoctets d'informations ?
Use cases
Le Big Data en France

3. CONTEXTE ET ORIGINE
DU BESOIN

4. 6
Contexte et origine du besoin
Contexte
Site de E-commerce parmi les leaders du marché
Complexe, composé d'applications multi-tiers / instances / multi-sites
Forte visibilité avec un besoin de réactivité très fort.
Problèmes pour exploiter des applications réparties
Répartition sur des périmètres différents des équipes supports /exploitations
Application statefull pour simplifier l'analyse puis statefull'less'
Quid du reporting global ?
Besoin de centraliser l'information
Les logs constituent la première source d’information.

5. 7
LA PREMIERE EBAUCHE

6. 88
La première ébauche
Architecture
Centralisation des logs
Ecriture sur du SAN.
Une implémentation via syslog
Solution éprouvée, multiplateforme
Plusieurs datasources : streaming / fichier
Niveau de Qos : UDP / TCP, bufferisation
Enrichissement de message post émission.
Faiblesse de la solution
Pas de loadbalancing ou failover natif
Pas de travail à la volée des messages
Périmètre de responsabilité diffus ( équ système / équ applicative /dev )
IO concentré nécessite du SAN (10000 à 30000 IO/s ).

7. 9
RESULTATS AU DELA
DES FAIBLESSES
TECHNIQUES

8. 1010
Résultats au delà des faiblesses techniques
Difficulté à valoriser car méconnaissance du contenu des logs
Possibilité quasi infinie, seule limite : l'information est-elle disponible ?
Information mélangée car pas de 'contextualisation' du log mais :
Information commerciale : activité clientèle
Information technique : performance du SI malgré son hétérogénéité.
Problèmes de fond : le traitement des données
Temps nécessaire pour retrouver/traiter une information
Pour traiter il faut normaliser les évènements
Sécurité des informations
Pas de réponse simple au problème du périmètre des équipes supports/exploitations.

9. 11
LE VRAI PROBLEME :
LES RESSOURCES CPU
VS LES IOS

10. 1212
Le vrai problème : les ressources CPU vs les IOs
Problème du CPU vs IO
Test 1 : on lit un fichier de 500mo : 4s environ 123Mos, limité par les IO disques
Test 2 : on grep une ip dans un fichier de 500mo : 12s soit 42Mo/s
Test 3 : on passe en multithread sur le grep : 118Mo/s
La contention est la CPU ou la bande passante pour alimenter le processus.
Optimisation par agrégation de ressources
Problème historique touchant toutes les strates :
Cas des supercalculateurs / RAID / Chunk&Tap sur le réseau.
Ne pas oublier qu'au delà de la largeur des données, la latence d'accès est maîtresse
Pas d'invention : c'est LE moteur de l'évolution des ordinateurs :
Augmenter le nombre d'opération en 'parallèle' : pipelining / hypethreading
La problématique d'IO est résolue par des niveaux de cache (cache niveau 2/3 partagé)
Bank RAM appairé pour doubler la BP
Enfin le multi-core.

11. AGREGATION DE CPU

12. 14
Agrégation de CPU
Décomposer le problème via l’algorithme MapReduce
Plusieurs implémentations
Mongo / CouchDb / Cassandra / Hadoop.

13. HADOOP : UNE
VULGARISATION

14. 16
Partie 1 : le stockage
File System issue de Google FS
Orienté : large scale (100T/Po de donnée) / lecture intensive / lowcost.
Back to basics
Un disque dur est décomposé en secteur de 512 octets
Les secteurs sont organisés en bloc par un système de fichier (FS)
Bloc totalement alloué même pour 10 utilisations.
Hadoop FileSystem : HDFS
Se repose sur les FS natif OS
Utilise des block de 64Mo par défaut
Avec un débit de 100Mo/s et un seek time de 10ms : 1% du temps en latence
Allocation optimisée.

15. 17
Partie 1 : le stockage
HDFS
Autorise un facteur de réplication de block
Les metadatas (genre inode) sont stockés dans un NameNode
Distribution des blocs de données pour améliorer la lecture : anti-défragmentation
Adopte les normes posix.
Méthode d’accès
Accès console
Webapp
Par API (pyhon/java/ruby)
FuseFS.

16. 18
Partie 1 : le stockage
HDFS en schéma :

17. 19
Partie 1 : le stockage
HDFS en schéma :

18. 20
Partie 2 : le traitement des données
La théorie
L'API repose sur 2 fonctions
MAP
Reduce.
Mise en avant de la programmation fonctionnelle vs impérative
Impact fort suivant les indicateurs attendus.
Optimisations 'cachées'
Les maps sont lancés au plus proche des données
Attention à la compression.

19. 21
Partie 2 : le traitement des données
Répartition sur plusieurs nœuds

20. 22
Partie 2 : le traitement des données
Dans la vraie vie … il faut coder
TDD via MRUnit
Difficile de debugger/profiler une application
Le fait d'être en large scale provoque un effet loupe sur le moindre problème de code.
… ou sous traiter
Hive
PIG
SPSS.

21. 23
Partie 2 : le traitement des données
Pour ceux qui aiment être root : tout est disponible sous apache.org
Offre hadoop packagée
En pleine explosion ( HortonWorks/ cloudera / ….)
Attention au mode de licencing
Exemple Splunk : 800k +100k par 500g
Cloudera : au début limité à 10 nœuds puis modification du mode de licencing
Pas à l'abri d'un revirement à la Oracle.
Aucune implémentation ne remplace un expert pour l'exploitation
Les coûts cachés
Injection des données
Nettoyage des données.

22. INTEGRATION
DANS UN SI

23. 25
Intégration dans un SI
Attention aux effets de bord sur le cœur du SI
On parle de centaine de giga jour, switch/cœur de réseau mutualisés
Bande passante inter-sites (Qos MPLS)
CPU/RAM consommé sur les serveurs applicatifs
Lock des ressources (Map/Reduce) de la grille : mise en place de quota
Durée de vie des données ?
Pas de place dans vos travées ?
Utilisation de serveur MoonShot HP 4U : 125 slots à repartir entre CPU est stockage
Cartouche 16 core
Disque de 1 tera.
Recyclage
Faire du capacity planning en recyclant les vieux serveurs en nœuds déstockage.
Externalisation de l’infra
Infra cloud dédiée, coûteuse si vous avez des exigences de temps de traitement.

24. 26
COMMENT
VALORISER DES
TERRA/PETAOCTETS
D’INFORMATION ?

25. 2727
Comment valoriser des téra/pétaoctets d'informations ?
Difficulté à valoriser car méconnaissance du contenu des logs
L'information est-elle disponible ?
Possibilité quasi infinie mais :
Un expert Big Data ne remplacera pas un datascientist
L'information a force de valeur uniquement par sa qualité et sa date de péremption.
Use case réel
GrepIt !
Facturation cliente sur plateforme mutualise
Indicateur de SLA sur du middleware
Détection d'attaque par analyse comportementale.

26. 28
USE CASE

27. 2929
Problématique : trouver un mot clef dans les logs
Map / Reduce basique
Map va filtrer les logs contenant le mot clé
Reduce va simplement écrire les logs lui arrivant.
Use Case 1 : GrepIT

28. 3030
Use case 2 : facturation client sur plateforme mutualisée
Faire du SLA sur du middle tiers mutualisé
Clé de répartition composite
IP / Stats / Htpp Code / Login / URL /Plateforme.
90 percentiles sur 2 sites

29. 3131
Use case 2 : facturation client sur plateforme mutualisée

30. 3232
Use case 3 : détection d’attaque DOS
Problématique : détection de robots qui empêchent la vente de produit
Identifier les comportements anormaux
Map va filtrer les URL utiles, la clé de répartition est l’ip
Reduce va calculer des compteurs :
Nombre de mise en panier
Délai entre 2 mise en panier
Nombre de paiement versus nombre de mise en panier
En sortie on corrèle avec des seuils prédéfinies.
Bannissement d’IP non automatique

31. 3333
Use case 4 : indicateur de SLA sur du middleware
Problématique : vérifier qu’on entre dans le SLA sur du middleware répartie
Identifier les comportements anormaux
Agrégation
Corrélation
Gestion de plusieurs datasources.

32. 34
LES NOUVEAUX
BESOINS

33. 3535
Les nouveaux besoins
Mode batch pas toujours adapté
Introduction d’ElasticSearch / Kibana.
Gestion de la durée de vie de l’information : besoin de streaming

34. BIG DATA AU DELA
D’UNE MODE

35. 37
Big Data au-delà d’une mode
Solutions inventées et adoptées par et pour les leaders de marché
L’algorithme map/reduce remis au goût du jour par Google pour indexer le Web
Hadoop core vient des équipe de Yahoo pour indexer le Web
Difficile de faire mieux avec un équipe R&D (on RivoDB).
Sans engagement :
Pas de technologie propriétaire
Hardware standard
Produit Open Source massivement adopté qui devient donc un standard.
Implications stratégiques au delà du rêve
Permet d'établir des stratégies marketing a court et moyen terme, comment ?
Toute la matière première est là
Nécessite de réelles compétences de Data Scientist
Permet une évolution « maîtrisée » du SI au delà de l'amortissement CAPEX/OPEX
étalé.

36. CONCLUSION

37. 39
Conclusion
N'est qu'un moyen technique, pas la finalité
Ne pas se tromper d'acteur/profil
L'analyse statistique est un métier à par entière (Data Scientist)
Exploitation d'un cluster nécessite un bon niveau d'expertise
De même pour les développements : peu très vite déraper.
Attention aux promesses des sociétés de consulting
Pose des problèmes organisationnels importants
Peu de société en France sont dotées d’un vrai retour d'expérience

38. 40
Références
http://fr.wikipedia.org/wiki/MapReduce
Hadoop : the Definitive guide / O'Reilly
MISC Décembre 2013
Cluster Multiprocesseur / Architecture Paralelle Eyrolles.

39. 41