Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Comment passer d'un POC en prod @ plusieurs milliards de rêquetes

907 views

Published on

Ogury est la plateforme de data mobile qui permet d’accéder aux données comportementales des profils de plus de 400 millions de mobinautes répartis dans plus de 120 pays. Monter une stack haute fréquence n’est pas facile, David et Carles vous parleront de leur retour d'expérience.

Durant cette présentation, Carles et David vous propose de revivre avec eux l’évolution de l’architecture d’Ogury. D’un POC monolite à une architecture micro-service orienté perf, constituée des 700 instances chez AWS.

Published in: Technology
  • Be the first to comment

Comment passer d'un POC en prod @ plusieurs milliards de rêquetes

  1. 1. COMMENT PASSER D’UN POC EN PROD @ PLUSIEURS MILLIARDS DE REQUÊTES ?
  2. 2. @CarlesSistare https://github.com/carlessistare carles@ogury.co CARLES SISTARÉ Founding Team - Delivery Lead Tech
  3. 3. @David_Caramelo https://github.com/dcaramelo david.caramelo@ogury.co DAVID CARAMELO Swat Lead Tech
  4. 4. ● Données comportementales de 400 millions de profils uniques (via SDK) ● Des milliers de campagnes publicitaires internationales ● Publicité ciblée ● Évolution vers le programmatique PLATEFORME DE DATA MOBILE C’est quoi ?
  5. 5. PLATEFORME DE DATA MOBILE DATA Publicités ciblées Campagnes
  6. 6. ARCHITECTURE DE DÉPART SDK Android simpliste AdServer Monolithe à tout faire Outils de stats pas adaptés
  7. 7. SCHÉMA ORIGINAL DU POC * * Avec l’acceptation explicite du mobinaute, Guidelines Google et Conforme avec les lois Européennes
  8. 8. ● Croissance exponentielle du traffic > Manque d’anticipation du succès ● Erreurs SDK Android (restarts, requêtes en double) > SDK non-maîtrisé ● Temps de réponse trop longs (> 300 ms) ● Métriques BI de campagnes peu fiables > On rate des impressions et des clicks ● Performances business pas bonnes LES PROBLÈMES COMMENCENT
  9. 9. ÉTAPE 1 OPTIMISATION DE LA CHARGE: ASYNCHRONISME • Traitement asynchrone de la Data (Kafka) > Envoyer toutes les requêtes entrantes sur Kafka > Favoriser les traitements en arrière plan > Rejouer les requêtes entrantes en cas d’erreur • Découpage du monolithe > Consumers Kafka pour les traitements lourds en asynchrone • BONUS : Envoyer un paramétrage au SDK > Maîtrise du comportement du SDK à distance
  10. 10. ÉTAPE 1 ASYNCHRONISME *
  11. 11. ÉTAPE 1 ASYNCHRONISME | QUELQUES CHIFFRES • 1TB/jour de logs gzipé • 60k messages/sec de logs kafka • 1.5 milliards requetes HTTP par jour • 12 * c3.2xlarge pour kafka (8 Cores / 15GB RAM) • 5 * m3.large pour zookeeper (2 Cores / 7GB RAM) • 30 topics kafka / 16 partitions / 24h rétention / Repl. Factor 3
  12. 12. ÉTAPE 2 OPTIMISATION DES MÉTRIQUES DU MÉTIER (BI) • Introduction d’Elastic en remplacement de Couchbase • Mise en place de Kafka Consumer pour calcul des métriques LIVE en arrière plan • Stockage des métriques sur S3 • Chargement des métriques depuis S3 directement sur Elastic
  13. 13. ÉTAPE 2 OPTIMISATION DES MÉTRIQUES *
  14. 14. ÉTAPE 2 OPTIMISATION DES MÉTRIQUES | QUELQUES CHIFFRES
  15. 15. ÉTAPE 2 OPTIMISATION DES MÉTRIQUES | QUELQUES CHIFFRES 13GB/Jour = 16 Millions Documents/Jour
  16. 16. ÉTAPE 2 OPTIMISATION DES MÉTRIQUES | QUELQUES CHIFFRES • Pas de stockage de sources, on indexe juste • 3 * t2.medium en mode Master (affectation de shard) (4GB RAM) • 6 * m4.4xlarge en mode Data (indexation et search) (64GB RAM) • 2 * t2.medium en mode Client (proxy-segmentation, agrégation des résultats et cache)
  17. 17. ÉTAPE 3 OPTIMISATION DES AD REQUESTS • 1 AdRequest = 1000 campagnes eligibles à checker • Pour chaque campagne: > Checker Targeting, geoloc, cappings, black/whitelist de publisher, ... > Checker la vitesse de délivrance de chaque campagne > Prioritisation inter-campagne par rapport à la perf potentiel du user > ... SOLUTION Pré Calcul de Segments en LIVE avec un minimum de campagnes éligibles > Publisher/Heure/Pays/OSVersion/SDKVersion/Connectivité
  18. 18. Ad-Request Capping des campagnes Android version SDK version Localisation Connectivité Etc.. Checks X Nb de campagnes actives (>1000) Complexité : N * M (M > 1000) ÉTAPE 3 OPTIMISATION DES AD REQUESTS
  19. 19. Catégorisation des checks User Capping user Localisation Android version SDK version Connectivité Heure Application ( + Capping campaign) Context ÉTAPE 3 OPTIMISATION DES AD REQUESTS
  20. 20. Ad-Request Capping user Checks user X Campagne Context (< 20) Complexité : 1 * M (M < 20) AD-REQUEST : > 300 ms → 125 ms ÉTAPE 3 OPTIMISATION DES AD REQUESTS
  21. 21. ÉTAPE 3 OPTIMISATION DES AD REQUESTS *
  22. 22. ÉTAPE 3 OPTIMISATION DES AD REQUESTS • Optimisation du code Node.js > Attention aux libs JS pour gérer des modèles d’objets JSON, car elles clonent les objets JSON > Faire en sorte que tout soit passé par référence • Optimisation trafic réseau > Migration des service internes en gRPC
  23. 23. ÉTAPE 3 OPTIMISATION DES AD REQUESTS Optim Clone Objets JSON HTTP KeepAlive vs gRPC
  24. 24. ÉTAPE 4 OPTIMISATION DU TARGETING • Cluster EMR pour le calcul du ciblage publicitaire > La meilleure pub possible pour chaque mobinaute • Procédures Hadoop pour traiter 1TB data journaliers • Logs bruts en JSON, et beaucoup de doublons (premières versions SDK) • Jobs coûteux car beaucoup de traitement de string SOLUTION Migration Parquet + Intégration d’Automates dans les jobs Hadoop MR
  25. 25. ÉTAPE 4 OPTIMISATION DU TARGETING A L’ORIGINE • Daily Cleansing: HIVE > 300GB par jour (en 2015) > 3h par jour > 12 * c3.8xlarge (les plus chères à l’époque) • Calcul du targeting User-Campaign: HADOOP MR > String1 LIKE “%String%” > 8h > 12 * c3.8xlarge
  26. 26. HIVE DATA CLEANSING PARQUET
  27. 27. HIVE DATA CLEANSING PARQUET
  28. 28. HIVE DATA CLEANSING PARQUET
  29. 29. Application A Application B Application C Etc.. Evénements users X Nb de campagnes actives (>1000) Complexité : N * M (N > 10 milliards & M > 100K) Critère 1 Critère 2 Critère 3 Etc.. HADOOP Map Reduce avec des AUTOMATES
  30. 30. HADOOP MAP REDUCE AVEC DES AUTOMATES
  31. 31. Application A Application B Application C Etc.. Evénements users X Automate Complexité : N * 1 (N > 10 milliards) Temps de réponse < 10 ns HADOOP MAP REDUCE AVEC DES AUTOMATES
  32. 32. ÉTAPE 4 OPTIMISATION DU TARGETING AMELIORATIONS • Daily Cleansing: HIVE 1TB par jour 1h par jour • Calcul du targeting User-Campaign: HADOOP MR Automate 20min
  33. 33. EN RÉSUMÉ AVANT MAINTENANT • 400 Millions Profiles • 1.5 Milliards Req/Jour • Temps de réponse <35ms • Calcul du Targeting: 1.5h • 700 instances • 22 noeuds Redshift • 13 BD Postgres • IT team > 40 devs • 50k Profiles • 200k Req/Jour • Temps de réponse >300ms • Calcul du Targeting: 10h • IT team 2 devs
  34. 34. NOTRE RETOUR D’EXPERIENCE - Intégrer Gatling dans les tests de la CI - Découpé votre application par responsabilité → Simplification de la mise en place de l’asynchronisme ( → scalabilité) Step 1 : OPTIMISATION DE LA CHARGE Step 2 : OPTIMISATION DES MÉTRIQUES DU MÉTIER (BI) - Conserver l’ensemble des events systèmes - Réfléchissez bien aux besoins avant de choisir les outils. - Tests intégrations et tests unitaires sont la clé d’une croissance d’un système contrôlée
  35. 35. NOTRE RETOUR D’EXPERIENCE - Remettre en question constamment votre code - Mesurer, sonder votre code / Mettre en place des APIs techniques → Alerte - Catégoriser les traitements : maintenant VS plus tard - Ne pas croire que les libs sont parfaites → Contribuer et faite de PR :) Step 3 : OPTIMISATION DES AD REQUESTS Step 4 : OPTIMISATION DU TARGETING - HIVE archaïque, mais toujours le meilleur choix pour transformer de données - N’hésitez pas à charger des automates dans du Map Reduce
  36. 36. PROCHAIN RENDEZ-VOUS GRPC • Introduction HTTP2 • Explication Protobuf • Explication gRPC • Démo/Live Coding • Analyse comparative de perfs carles@ogury.co david.caramelo@ogury.co
  37. 37. QUESTIONS ? carles@ogury.co david.caramelo@ogury.co
  38. 38. carles@ogury.co david.caramelo@ogury.co

×