Traiter des requètes, de 200K/jour à 200K/min

Talk au sfPot Paris du 18/10

Transcript

1. Traiter des requêtes De 200K/jour à 200K/min
2. Qui sommes-nous
4. Adback, https://adback.co, @adback_co Projet lancé en janvier 2015 3 développeurs (depuis 6 mois) Outil d’analyse des adblockeurs Qui sommes-nous
5. Données analytics Accès BO Précalcul des données Enrichissement des données Qui sommes-nous
6. Existant en mai Projet mono-bloc 3 serveurs chez OVH 1MySql, 1 Redis Quelques commandes consoles Pas de scaling Pas de monitoring Spaghetti code
7. Intégration de nouveaux sites Limitation dans le nombre de traitement Ban par les firewalls OVH en raison de flooding
8. Il faut migrer!!
9. Migration Vers quoi ? Vers où ? Avec quelle technologie ? En combien de temps ? Refactoring ? Chez AWS Les mêmes 2 semaines max Non
10. Identification des différents process Satellites : servir les tags js et récupérer les données Workers : réaliser l’enrichissement des données Worker-cache : réaliser le pré-calcul des données la nuit Back-office : présenter le résultat aux clients
11. Première migration Uniquement Redis vers Elasticache. Pas de modification de code.
12. Première migration Echec car : Lenteur des accès à redis
13. Deuxième migration Concerne plus de services : Satellite Worker Redis Mysql
14. Procedure Fork du projet Utilisation de elastic beanstalk Lancement sur AWS
15. Elastic Beanstalk et docker Permet de lancer plusieurs container sur une instance EC2 Le scaling est réalisé en ajoutant des instances EC2 La configuration se fait par un fichier Dockerrun.aws.json Mise à disposition d’un executable local (eb) Le déploiement peut aussi mettre à jour les containers
16. Configuration
17. En local
18. Structure du projet
19. Déploiement (avec codeship)
20. Résultats
21. Succès Plateforme iso-prod Scalabilité horizontale Déploiement automatique Premières étapes de monitoring
22. Démo
23. Échecs Récupération des ips : $request->getClientIp() => Ip du loadbalancer AWS Limitation de la base MariaDB (1000 insert/sec) Tests
24. Analyse des échecs
25. Modification de la base Séparation des données : Données principales Données d’enrichissement Données pour les statistiques Destination : MariaDB Aurora Redshift
26. Modification de la base Procedure : Les entitées sont décrites par des interfaces Modifications des relations avec les autres entitées
27. Modification de la base Performance en écriture Mais utilisation CPU non optimale
28. Modification de la base Ajout d’un redis local Utilisation de l’AOP
29. Migration de la base De Aurora à Redshift : Extraction des données sous la forme d’un csv Importation dans Redshift en utilisant Embulk
30. Tests Mise en place d’une librairie partagée : Garantie que les données sorties sont bien ré-analysées
31. Optimisation inefficace
32. Optimisation inefficace Réplication Master-slave Tentative de lissage de charge
33. Et ensuite ?
34. Assurer la cohérence des données
35. Assurer la cohérence des données Utilisation de la stack Druid.io/Pivot Druid.io permet l’importation des données en CSV Permet de faire de l’analyse en temps réel
36. Assurer la cohérence des données Utilisation de la stack GGS pour réaliser du monitoring métier Installation d’un agent statsd par container
37. Conclusion
38. Ce qui nous a aidé Être devops : Culture Automatisation Mesure Partage
39. Ce qui nous a aidé Être en remote : Obligation de livrer quelque chose d’utilisable tout de suite Livrer avec la documentation d’utilisation
40. Ce qui nous a aidé Séparer l’implementation de l’utilisation : Rendre le code open-sourcable rapidement Ne pas privilégier l’optimisation sur le design
41. Ce qui nous a aidé Être agile : Cérémonie, stand up, petites tâches Finir les tâches des collègues
42. Questions ?
43. MERCI !