SlideShare une entreprise Scribd logo
COMMENT PASSER D’UN POC EN PROD
@ PLUSIEURS MILLIARDS DE REQUÊTES ?
@CarlesSistare
https://github.com/carlessistare
carles@ogury.co
CARLES SISTARÉ
Founding Team - Delivery Lead Tech
@David_Caramelo
https://github.com/dcaramelo
david.caramelo@ogury.co
DAVID CARAMELO
Swat Lead Tech
● 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 ?
PLATEFORME DE DATA MOBILE
DATA
Publicités ciblées
Campagnes
ARCHITECTURE DE DÉPART
SDK Android simpliste AdServer Monolithe
à tout faire
Outils de stats
pas adaptés
SCHÉMA ORIGINAL DU POC
*
* Avec l’acceptation
explicite du mobinaute,
Guidelines Google et
Conforme avec les lois
Européennes
● 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
É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
ÉTAPE 1
ASYNCHRONISME
*
É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
É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
ÉTAPE 2
OPTIMISATION DES MÉTRIQUES
*
ÉTAPE 2
OPTIMISATION DES MÉTRIQUES | QUELQUES CHIFFRES
ÉTAPE 2
OPTIMISATION DES MÉTRIQUES | QUELQUES CHIFFRES
13GB/Jour = 16 Millions Documents/Jour
É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)
É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é
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
Catégorisation des checks
User
Capping user Localisation
Android version
SDK version
Connectivité
Heure
Application
( + Capping campaign)
Context
ÉTAPE 3
OPTIMISATION DES AD REQUESTS
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
ÉTAPE 3
OPTIMISATION DES AD REQUESTS
*
É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
ÉTAPE 3
OPTIMISATION DES AD REQUESTS
Optim Clone Objets JSON
HTTP KeepAlive vs gRPC
É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
É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
HIVE
DATA CLEANSING PARQUET
HIVE
DATA CLEANSING PARQUET
HIVE
DATA CLEANSING PARQUET
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
HADOOP MAP REDUCE
AVEC DES AUTOMATES
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
ÉTAPE 4
OPTIMISATION DU TARGETING
AMELIORATIONS
• Daily Cleansing: HIVE
1TB par jour
1h par jour
• Calcul du targeting User-Campaign: HADOOP MR
Automate
20min
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
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
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
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
QUESTIONS ?
carles@ogury.co
david.caramelo@ogury.co
carles@ogury.co
david.caramelo@ogury.co

Contenu connexe

Similaire à Optimisations et Performances d'un POC en prod @ plusieurs milliards de requêtes ?

Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...Amazon Web Services
 
MongoDB 3.6 Customer Deck pptx.pptx
MongoDB 3.6 Customer Deck pptx.pptxMongoDB 3.6 Customer Deck pptx.pptx
MongoDB 3.6 Customer Deck pptx.pptxMongoDB
 
Les nouveautés de MongoDB 3.6
Les nouveautés de MongoDB 3.6Les nouveautés de MongoDB 3.6
Les nouveautés de MongoDB 3.6MongoDB
 
What's new in MongoDB 3.6
What's new in MongoDB 3.6What's new in MongoDB 3.6
What's new in MongoDB 3.6MongoDB
 
Meetup Google Cloud
Meetup Google CloudMeetup Google Cloud
Meetup Google CloudPierre Coste
 
gRPC, échange à haute fréquence!
gRPC, échange à haute fréquence!gRPC, échange à haute fréquence!
gRPC, échange à haute fréquence!David Caramelo
 
gRPC, ECHANGES A HAUTE FREQUENCE !
gRPC, ECHANGES A HAUTE FREQUENCE !gRPC, ECHANGES A HAUTE FREQUENCE !
gRPC, ECHANGES A HAUTE FREQUENCE !Carles Sistare
 
Oxalide MorningTech #1 - BigData
Oxalide MorningTech #1 - BigDataOxalide MorningTech #1 - BigData
Oxalide MorningTech #1 - BigDataLudovic Piot
 
Track 2 - Atelier 1 - Big data analytics présenté avec Intel
Track 2 - Atelier 1 - Big data analytics présenté avec IntelTrack 2 - Atelier 1 - Big data analytics présenté avec Intel
Track 2 - Atelier 1 - Big data analytics présenté avec IntelAmazon Web Services
 
Meetup Google Cloud
Meetup Google CloudMeetup Google Cloud
Meetup Google CloudPierre Coste
 
L'automatisation dans les reseaux d'entrerprise
L'automatisation dans les reseaux d'entrerpriseL'automatisation dans les reseaux d'entrerprise
L'automatisation dans les reseaux d'entrerpriseCisco Canada
 
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...OCTO Technology
 
Monitoring applicatif : Pourquoi et comment ?
Monitoring applicatif : Pourquoi et comment ?Monitoring applicatif : Pourquoi et comment ?
Monitoring applicatif : Pourquoi et comment ?Kenny Dits
 
Retour d'expérience sur Pentaho Data Integration - ce que PDI nous a apporté
Retour d'expérience sur Pentaho Data Integration - ce que PDI nous a apportéRetour d'expérience sur Pentaho Data Integration - ce que PDI nous a apporté
Retour d'expérience sur Pentaho Data Integration - ce que PDI nous a apportéAdrien Futschik
 
Stockage et analyse temps réel d'événements avec Riak chez Booking.com
Stockage et analyse temps réel d'événements avec Riak chez Booking.comStockage et analyse temps réel d'événements avec Riak chez Booking.com
Stockage et analyse temps réel d'événements avec Riak chez Booking.comDamien Krotkine
 
Core Web Vitals, les indicateurs de vitesse qui réconcilient UX et SEO
Core Web Vitals, les indicateurs de vitesse qui réconcilient UX et SEOCore Web Vitals, les indicateurs de vitesse qui réconcilient UX et SEO
Core Web Vitals, les indicateurs de vitesse qui réconcilient UX et SEOWeLoveSEO
 
AWS Paris Summit 2014 - T3 - Du temps réel au data warehouse : capturez et an...
AWS Paris Summit 2014 - T3 - Du temps réel au data warehouse : capturez et an...AWS Paris Summit 2014 - T3 - Du temps réel au data warehouse : capturez et an...
AWS Paris Summit 2014 - T3 - Du temps réel au data warehouse : capturez et an...Amazon Web Services
 
TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au ...
TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au ...TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au ...
TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au ...Publicis Sapient Engineering
 
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...OCTO Technology
 
Comment M6 personnalise l’expérience utilisateur du service 6Play avec DataSt...
Comment M6 personnalise l’expérience utilisateur du service 6Play avec DataSt...Comment M6 personnalise l’expérience utilisateur du service 6Play avec DataSt...
Comment M6 personnalise l’expérience utilisateur du service 6Play avec DataSt...DataStax
 

Similaire à Optimisations et Performances d'un POC en prod @ plusieurs milliards de requêtes ? (20)

Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
Track 2 - Atelier 3 - Comment Ysance met le cloud au service du digital avec ...
 
MongoDB 3.6 Customer Deck pptx.pptx
MongoDB 3.6 Customer Deck pptx.pptxMongoDB 3.6 Customer Deck pptx.pptx
MongoDB 3.6 Customer Deck pptx.pptx
 
Les nouveautés de MongoDB 3.6
Les nouveautés de MongoDB 3.6Les nouveautés de MongoDB 3.6
Les nouveautés de MongoDB 3.6
 
What's new in MongoDB 3.6
What's new in MongoDB 3.6What's new in MongoDB 3.6
What's new in MongoDB 3.6
 
Meetup Google Cloud
Meetup Google CloudMeetup Google Cloud
Meetup Google Cloud
 
gRPC, échange à haute fréquence!
gRPC, échange à haute fréquence!gRPC, échange à haute fréquence!
gRPC, échange à haute fréquence!
 
gRPC, ECHANGES A HAUTE FREQUENCE !
gRPC, ECHANGES A HAUTE FREQUENCE !gRPC, ECHANGES A HAUTE FREQUENCE !
gRPC, ECHANGES A HAUTE FREQUENCE !
 
Oxalide MorningTech #1 - BigData
Oxalide MorningTech #1 - BigDataOxalide MorningTech #1 - BigData
Oxalide MorningTech #1 - BigData
 
Track 2 - Atelier 1 - Big data analytics présenté avec Intel
Track 2 - Atelier 1 - Big data analytics présenté avec IntelTrack 2 - Atelier 1 - Big data analytics présenté avec Intel
Track 2 - Atelier 1 - Big data analytics présenté avec Intel
 
Meetup Google Cloud
Meetup Google CloudMeetup Google Cloud
Meetup Google Cloud
 
L'automatisation dans les reseaux d'entrerprise
L'automatisation dans les reseaux d'entrerpriseL'automatisation dans les reseaux d'entrerprise
L'automatisation dans les reseaux d'entrerprise
 
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
 
Monitoring applicatif : Pourquoi et comment ?
Monitoring applicatif : Pourquoi et comment ?Monitoring applicatif : Pourquoi et comment ?
Monitoring applicatif : Pourquoi et comment ?
 
Retour d'expérience sur Pentaho Data Integration - ce que PDI nous a apporté
Retour d'expérience sur Pentaho Data Integration - ce que PDI nous a apportéRetour d'expérience sur Pentaho Data Integration - ce que PDI nous a apporté
Retour d'expérience sur Pentaho Data Integration - ce que PDI nous a apporté
 
Stockage et analyse temps réel d'événements avec Riak chez Booking.com
Stockage et analyse temps réel d'événements avec Riak chez Booking.comStockage et analyse temps réel d'événements avec Riak chez Booking.com
Stockage et analyse temps réel d'événements avec Riak chez Booking.com
 
Core Web Vitals, les indicateurs de vitesse qui réconcilient UX et SEO
Core Web Vitals, les indicateurs de vitesse qui réconcilient UX et SEOCore Web Vitals, les indicateurs de vitesse qui réconcilient UX et SEO
Core Web Vitals, les indicateurs de vitesse qui réconcilient UX et SEO
 
AWS Paris Summit 2014 - T3 - Du temps réel au data warehouse : capturez et an...
AWS Paris Summit 2014 - T3 - Du temps réel au data warehouse : capturez et an...AWS Paris Summit 2014 - T3 - Du temps réel au data warehouse : capturez et an...
AWS Paris Summit 2014 - T3 - Du temps réel au data warehouse : capturez et an...
 
TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au ...
TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au ...TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au ...
TEch4Exec - OUI.sncf propose des voyages moins chers grâce au Big Data et au ...
 
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
UN ÉLÉPHANT QUI SE BALANÇAIT … Comment mettre en musique les big data et valo...
 
Comment M6 personnalise l’expérience utilisateur du service 6Play avec DataSt...
Comment M6 personnalise l’expérience utilisateur du service 6Play avec DataSt...Comment M6 personnalise l’expérience utilisateur du service 6Play avec DataSt...
Comment M6 personnalise l’expérience utilisateur du service 6Play avec DataSt...
 

Optimisations et Performances d'un POC en prod @ plusieurs milliards de requêtes ?

  • 1.
  • 2. COMMENT PASSER D’UN POC EN PROD @ PLUSIEURS MILLIARDS DE REQUÊTES ?
  • 5. ● 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 ?
  • 6. PLATEFORME DE DATA MOBILE DATA Publicités ciblées Campagnes
  • 7. ARCHITECTURE DE DÉPART SDK Android simpliste AdServer Monolithe à tout faire Outils de stats pas adaptés
  • 8. SCHÉMA ORIGINAL DU POC * * Avec l’acceptation explicite du mobinaute, Guidelines Google et Conforme avec les lois Européennes
  • 9. ● 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
  • 10. É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
  • 12. É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
  • 13. É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
  • 15. ÉTAPE 2 OPTIMISATION DES MÉTRIQUES | QUELQUES CHIFFRES
  • 16. ÉTAPE 2 OPTIMISATION DES MÉTRIQUES | QUELQUES CHIFFRES 13GB/Jour = 16 Millions Documents/Jour
  • 17. É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)
  • 18. É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é
  • 19. 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
  • 20. Catégorisation des checks User Capping user Localisation Android version SDK version Connectivité Heure Application ( + Capping campaign) Context ÉTAPE 3 OPTIMISATION DES AD REQUESTS
  • 21. 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
  • 22. ÉTAPE 3 OPTIMISATION DES AD REQUESTS *
  • 23. É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
  • 24. ÉTAPE 3 OPTIMISATION DES AD REQUESTS Optim Clone Objets JSON HTTP KeepAlive vs gRPC
  • 25. É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
  • 26. É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
  • 30. 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
  • 31. HADOOP MAP REDUCE AVEC DES AUTOMATES
  • 32. 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
  • 33. ÉTAPE 4 OPTIMISATION DU TARGETING AMELIORATIONS • Daily Cleansing: HIVE 1TB par jour 1h par jour • Calcul du targeting User-Campaign: HADOOP MR Automate 20min
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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