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. David Caramelo, Développeur Craftsman passionné depuis 12 ans, actuellement Tech Lead full stack chez Ogury. David s'est forgé son expérience essentiellement dans des startups parisiennes comme Viadeo ou Ogury et dans des cabinets conseil IT comme Xebia. Carles Sistaré, Architecte-Développeur dans les clouds, actuellement Tech Lead de la team Delivery et co-fondateur d’Ogury. Carles a évolué dans le monde de la AdTech en passant par Ad4Screen et en tant qu’amateur de l’open-source en tant que commiteur Node-Kafka et créateur du module grpc-promise.

2. COMMENT PASSER D’UN POC EN PROD
@ PLUSIEURS MILLIARDS DE REQUÊTES ?

3. @CarlesSistare
https://github.com/carlessistare
carles@ogury.co
CARLES SISTARÉ
Founding Team - Delivery Lead Tech

4. @David_Caramelo
https://github.com/dcaramelo
david.caramelo@ogury.co
DAVID CARAMELO
Swat Lead Tech

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

11. ÉTAPE 1
ASYNCHRONISME
*

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

14. ÉTAPE 2
OPTIMISATION DES MÉTRIQUES
*

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

27. HIVE
DATA CLEANSING PARQUET

28. HIVE
DATA CLEANSING PARQUET

29. HIVE
DATA CLEANSING PARQUET

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

38. QUESTIONS ?
carles@ogury.co
david.caramelo@ogury.co

39. carles@ogury.co
david.caramelo@ogury.co