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.
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 ?
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
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
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
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
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