MongoDB Paris 2012: Hadoop et MongoDb

Comment analyser chaque jour des téra de logs générés par plus de 600 JVMs en production, sans impacter leur fonctionnement ? Nous vous présenterons durant cette session la solution Big Data 100% Open Source mise en place chez un des plus grands sites du web européen. Une architecture basée sur syslog-ng, Flume, Hadoop, MongoDb et Play!, qui n'a rien à envier aux géants d'outre-atlantique ! Venez découvrir comment nous avons divisé par 20 le temps de détection et de traitement des incidents. Mais aussi comment BigData a permis de nouvelles utilisations des logs à la fois techniques et surtout métier, comme la détection des fraudes, l’analyse de traffic web, BI en temps réel, ... À travers ce retour d'expérience, nous vous proposons de vivre, au coeur d'une des plus exigeantes productions de France, la mise en place de ce projet digne des très grands du web

Transcript

1. Hadoop et MongoDb by Pablo Lopez @pLopezFr 1 au secours de téraoctets de logs inexploitables chez l’un des plus grands sites marchands européens.
2. Abstract • Une plateforme de production hors normes, exigeante • Une solution BigData innovante • De nombreux usages • Voir toujours plus grand 2
3. 3 Speaker Pablo Lopez @pLopezFr blog.xebia.fr Big Data Architect DevOps Fort Traffic Performance
4. C’est l’histoire d’une startup... 4
5. La course à l’armement 5 • ~500 serveurs de production • 80 applications • 5 JVMs / serveur • 13 niveaux de load balancing. !" #!" $!!" $#!" %!!" %#!" &!!" &#!" '!!" '#!" !"#$%&''(&')&%*&+%)'(&',%"(+-."/' &/0%&'1223'&0'1241'
6. Une mine d’informations... 6 • Logs techniques / fonctionnelles / analytiques • 5 à 10 fichiers de logs par JVMs • 7 Go de logs / serveur / jour
7. ... et un calvaire pour les équipes 7 • Rotation trop rapide • Collecte semi automatisée • Transferts laborieux • Volume à traiter colossal
9. Les fonctionnalités recherchées 9 •Centraliser •Sécuriser •Analyser •Informer •Archiver •En temps réel
10. De grandes responsabilités 10 • Disponibilité 99,995 % • Temps de réponse sous la seconde • Base de données = Single Point of Failure • Coûts maitrisés
11. Big Data et open source 11
12. Centraliser 12
13. Centraliser (v2) 13
14. Sécuriser 14
15. Analyser 15
16. Informer / Archiver 16
17. Vue end-to-end 17
18. Vue end-to-end 17 12:49:22.203 DEBUG
19. Vue end-to-end 17 12:49:22.203 DEBUG
20. Vue end-to-end 17 12:49:22.203 DEBUG
21. Vue end-to-end 17 12:49:22.203 DEBUG
22. Vue end-to-end 17 12:49:22.203 DEBUG 12:49:22.203 DEBUG
23. Vue end-to-end 17 12:49:22.203 DEBUG 12:49:22.203 DEBUG
24. Vue end-to-end 17 12:49:22.203 DEBUG 12:49:22.203 DEBUG
25. Vue end-to-end 17 12:49:22.203 DEBUG 12:49:22.203 DEBUG
26. Vue end-to-end 17 12:49:22.203 DEBUG
27. Vue end-to-end 17 {service:HelloWorld, count:2}
28. Vue end-to-end 17 {service:HelloWorld, count:2}
29. Vue end-to-end 17 {service:HelloWorld, count:2}
30. Vue end-to-end 17
31. Le défi du temps réel 18 !" #" $!" $#" %!" %#" &!" &#" '!" '#" Temps d’exécution du job en minutes
32. Le défi du temps réel 18 !" #" $!" $#" %!" %#" &!" &#" '!" '#" Temps d’exécution du job en minutes Version initiale
33. Le défi du temps réel 18 !" #" $!" $#" %!" %#" &!" &#" '!" '#" Temps d’exécution du job en minutes Version initiale Tuning infrastructure
34. Le défi du temps réel 18 !" #" $!" $#" %!" %#" &!" &#" '!" '#" Temps d’exécution du job en minutes Version initiale Tuning infrastructure Tuning code
35. Utilisation quotidienne 19
36. Utilisation quotidienne 19
37. Utilisation quotidienne 19
38. Utilisation quotidienne 19
39. Zoom sur MongoDb 20
40. Flexibilité 21 • Map/Reduce, version initiale { "_id" : ObjectId("4fce8144bbaed5a2436f3a86"), "PageURL" : "http://myDomain.com/mapage/", "Day" : "2012-01-01", "Views" : "10" } • Map/Reduce, version évoluée { "_id" : ObjectId("4fd8eebc2a27d319d1324a31"), "PageURL" : "http://myDomain.com/mapage/", "Day" : "2012-06-14", "Views" : "10", "AverageDisplayTime" : "101" }
41. Maturité des API 22 Cluster MongoDb TCP TCP !"#$%&'%()**+(,-)./ 01+234567588-9:).+ 5885;<58=>?*9+56:
42. Haute disponibilité 23 Cluster MongoDb Member 2 Primary Arbiter Member 1
43. Scalabilité 24 Cluster MongoDb Shard B Shard C Shard A
44. Architecture 25 TaskTraker Map Reduce Mongos ShardA - Member 1 ShardB - Member 1 ShardC - Voter ShardA - Member 2 ShardB - Voter ShardC - Member 2 ShardA - Voter ShardB - Member 2 ShardC - Member 1 Mongo Config Mongo Config Mongo Config TaskTraker Map Reduce Mongos TaskTraker Map Reduce Mongos TaskTraker Map Reduce Mongos
45. Next architecture 26 TaskTraker Map Reduce Mongos ShardA - Primary ShardA - Secondary ShardB - Voter ShardB - Primary Mongo Config Mongo Config TaskTraker Map Reduce Mongos TaskTraker Map Reduce Mongos TaskTraker Map Reduce Mongos ShardA - Voter ShardB - Secondary Mongo Config
46. Réservé aux grands ? 27
47. L’équipe 28 • Philippe Martin martinphilippe@yahoo.com • Arnault Jeanson @ArnaultJeanson • Jean-Philippe Hautin @JpHautin • Jawed Khelil • François Ostyn • Pierre Revellin • Olivier Del Favero
48. Des questions ? 29