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 internat...
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éen...
● Croissance exponentielle du traffic
> Manque d’anticipation du succès
● Erreurs SDK Android (restarts, requêtes en doubl...
ÉTAPE 1
OPTIMISATION DE LA CHARGE: ASYNCHRONISME
• Traitement asynchrone de la Data (Kafka)
> Envoyer toutes les requêtes ...
ÉTAPE 1
ASYNCHRONISME
*
ÉTAPE 1
ASYNCHRONISME | QUELQUES CHIFFRES
• 1TB/jour de logs gzipé
• 60k messages/sec de logs kafka
• 1.5 milliards requet...
ÉTAPE 2
OPTIMISATION DES MÉTRIQUES DU MÉTIER (BI)
• Introduction d’Elastic en remplacement de Couchbase
• Mise en place de...
É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 mo...
ÉTAPE 3
OPTIMISATION DES AD REQUESTS
• 1 AdRequest = 1000 campagnes eligibles à checker
• Pour chaque campagne:
> Checker ...
Ad-Request
Capping des campagnes
Android version
SDK version
Localisation
Connectivité
Etc..
Checks
X
Nb de campagnes acti...
Catégorisation des checks
User
Capping user Localisation
Android version
SDK version
Connectivité
Heure
Application
( + Ca...
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
• Optimisation du code Node.js
> Attention aux libs JS pour gérer des modèles
d’objet...
É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 ch...
ÉTAPE 4
OPTIMISATION DU TARGETING
A L’ORIGINE
• Daily Cleansing: HIVE
> 300GB par jour (en 2015)
> 3h par jour
> 12 * c3.8...
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 >...
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...
ÉTAPE 4
OPTIMISATION DU TARGETING
AMELIORATIONS
• Daily Cleansing: HIVE
1TB par jour
1h par jour
• Calcul du targeting Use...
EN RÉSUMÉ
AVANT
MAINTENANT
• 400 Millions Profiles
• 1.5 Milliards Req/Jour
• Temps de réponse <35ms
• Calcul du Targeting...
NOTRE RETOUR D’EXPERIENCE
- Intégrer Gatling dans les tests de la CI
- Découpé votre application par responsabilité
→ Simp...
NOTRE RETOUR D’EXPERIENCE
- Remettre en question constamment votre code
- Mesurer, sonder votre code / Mettre en place des...
PROCHAIN RENDEZ-VOUS
GRPC
• Introduction HTTP2
• Explication Protobuf
• Explication gRPC
• Démo/Live Coding
• Analyse comp...
QUESTIONS ?
carles@ogury.co
david.caramelo@ogury.co
carles@ogury.co
david.caramelo@ogury.co
Comment passer d'un POC en prod @ plusieurs milliards de rêquetes
Prochain SlideShare
Chargement dans…5
×

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

830 vues

Publié le

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.

Publié dans : Technologie
  • Soyez le premier à commenter

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

×