Modern DevOps - kill the bottleneck (part 2/2)
0 j'aime131 vues
Le document présente des stratégies pour améliorer la performance des serveurs de cartes, abordant des concepts tels que l'optimisation du rendu des tuiles et l'utilisation de la mise en cache. Il examine les choix techniques en matière d'hébergement et de conception d'architecture, tout en partageant des résultats de tests de charge avec des recommandations pour maximiser l'efficacité. Enfin, il résume une série de défis rencontrés et offre des conseils pour l'optimisation des performances en environnement cloud et dédié.
Modern DevOps - kill the bottleneck (part 2/2)
- 1. Kill the bottleneck Servir des maps à haute performance by Loïc Ortola, CTO jawgmaps
- 2. Les incontournables 1. C’est quoi une carte? 2. Nos choix TKs 3. Rétrospective Load-testing 4. è Continuous improvement
- 3. 1. Qu’entend-on par Carte? 4 métiers principaux dans les maps digitales Geocoding Routing (Itinéraire) Cartes (Fonds de carte) ex : WMTS, WMS, Slippy Map Tiles Données supplémentaires (Vos POIs) ex : WFS
- 4. 1. Qu’entend-on par Carte? Carte de Paris à l’échelle 1:15 000 (zoom 15) Monde entier: 70 trillion pixels
- 5. 1. Qu’entend-on par Carte? Carte de Paris à l’échelle 1:15 000 (zoom 15) Monde entier: 1 billion tiles 256x256 pixels
- 6. 1. Qu’entend-on par Carte? Zoom 0 Scale 1:500 Million Zoom 1 Scale 1:250 Million
- 7. 1. Qu’entend-on par Carte? Rendu jusqu’au Zoom 19: Somme des tuiles des zooms 0 à 19: S = ~= 366 billion tiles
- 8. 1. Qu’entend-on par Carte?
- 9. Ca sert à quoi un map-server? A dessiner des données sur des cartes (routes etc…) A faciliter le stockage / le cache / les flux de données A gérer la stratégie d’import / réimport
- 10. Dessine moi une carte Entrée: Règles de “dessin” Sortie: Moteur de rendu Lecture en DB Clipping / drawing Prend du temps et des ressources quelques ms à plusieurs minutes de rendu utilise le CPU, la mémoire & le disque
- 11. Dessine moi une carte Besoin d’optimisations … sur la DB … sur le style … sur les requêtes
- 12. Optimiser le rendu des tuiles Concept : La Meta-tile Rendre plusieurs tuiles côte à côte, et les découper ensuite Avantages Empêche de saturer les I/O Diminue grandement les connections actives BDD Inconvénients Génère des tuiles inutiles è plus long
- 13. Optimiser le rendu des tuiles Rendement 28/64 = 43% Ex: Meta8 Rendement 28/256 = 11%
- 14. Donc… Impossible de pré-calculer toutes les tuiles du monde à tous les niveaux de zoom. c’est (infiniment) long ça prend trop de place, c’est éphémère Besoin de logiques de “cache” et de “pré-rendu” Système hautement contraint
- 15. Stockage des tuiles et cache Une “map” ó entre 12 et 48 tuiles è Comment diminuer mes I/O quand je vais chercher des données?
- 16. Stockage des tuiles et cache Stocker les tuiles contigues ensemble (Meta-Tile) Concentrer les requêtes demandant la même information Garder un cache mémoire (LRU)
- 17. (Ré-)importer des données Une archive à importer dans une base Des traitements sur la donnée pour le rendu Peut prendre plusieurs heures à quelques jours
- 18. (Ré-)importer des données Attention à la stratégie de mise à jour (fréquence, diff) Besoin d’une stratégie d’invalidation des caches A dimensionner de façon intelligente
- 19. Nos choix TKs Comment bâtir nos services Robustes, scalables et performants
- 20. Hosting strategy
- 21. Hosting Strategy + : Ressources dédiées - : Scalabilité, prix, defaillance HW + : TTM réduit - : Latence, vendor-lock, $ Serveurs Dédiés Cloud + EBS + CDN + ALB + ASG + : Faible Latence, full-control - : Long à dev, risque de failure Cloud + Manuel - : ressource mutualisée
- 23. Micro-Service approach Pros: • Maintenabilité • Micro-Scaling • Technology-independent Cons: • + de chaos, + de failles • Nécessite une infra bien pensée • Coute (en général) plus cher
- 25. Homemade Paradigmes: è Detect-fast, Fail-fast, recover-fast è No recovery automation Service-discovery / DNS: Consul Outils monitoring: Telegraf, Kapacitor Time series DB: InfluxDB
- 27. Reactive Modèle classique: 1 requête = 1 thread 10 requêtes = 10 threads 100 requêtes = 100 threads … Mais combien d’opérations peuvent réellement être exécutées en même temps? Modèle réactif: Des requêtes, des “workers” Optimiser l’activité du thread plutôt que le nombre de threads 27
- 28. Architecture 24 prod servers 6 websites Lab – Manager – Style – Demo – WWW – Swagger 9 public APIs Account – Storage - Static maps – Tile-edge – Auth – Stats – Style Registry – Geocoding – Routing 11 backend services Cassandra – InfluxDB – Telegraf – Grafana – Kapacitor – Consul – Registry – Gitlab – PFSense – YouTrack – PostGreSQL 4 private APIs Keystore – Tile-edge-diff – Tile-edge-renderer –Stats – Tile-edge-worker 2 SDKs Android, iOS
- 29. Load Testing Les conditions aux limites
- 30. Objectifs • Admettre le plus de trafic possible sur chaque machine • Avoir un temps de réponse le plus bas possible
- 31. KPIs • Performance = Maximiser le nombre de requêtes par seconde + 99th percentile <= 800ms 99.9th percentile <= 1200 ms 0 timeout ou requête non satisfaite
- 33. Test de performance • Mode Cluster • Métriques ultra-détaillées • Live reporting
- 34. Architecture dans la Réalité PRISE EN MAIN RAPIDITE EXACTITUDE BANDE PASSANTE CPU MEMOIRE CPU CPU MEMOIRE I/O UTILISATEURS APP CACHES RENDERS APP LB APP LB BANDE PASSANTE CPU
- 35. Architecture Test de Charge EG-30 HG-30 EG-15 HG-120 INJECTEURS APP CACHES RENDERS APP LB APP LB EG-7 • 8 vCores 2,3Ghz • 30 Go RAM • 2 Gbps BP • 2 vCores 2,3Ghz • 7 Go RAM • 300 Mbps BP • 8 vCores 3,1Ghz • 30 Go RAM • 2 Gbps BP • 4 vCores 2,3Ghz • 15 Go RAM • 1 Gbps BP • 32 vCores 3,1Ghz • 120 Go RAM • 4 Gbps BP
- 36. Rétrospective : les embûches Setup Spawn time OVH Manager vs Horizon + Nova + Neutron Déploiement SSHJ + OpenStack Run nf_conntrack_max steal-cpu et network softirq Bande passante
- 37. Rétrospective : avec 4 caches 850 000 utilisateurs en 30 min Entre 1 et 15 map views / user(ó entre 28 et 420 tuiles / user) Sur les 12 zones les plus peuplées du monde entier
- 38. Rétrospective : avec 4 caches 108 k req/s en pointe ó ~25k req/s/cache Moyenne des temps de réponse = 65 ms 99.9th percentile de temps de réponse < 600ms
- 39. Rétrospective : avec 4 caches 2 Gbps atteints sur EG-30 ~10k utilisateurs concurrents
- 40. Rétrospective : avec 4 caches 90% CPU utilisé 5% IOWait Steal & softirq négligeables
- 41. Rétrospective : recommandations Optimiser la bande passante Choisir les bonnes instances (Cloud ou Dédié)? Compression g-zip (tile-edge-cache)? Affiner le tuning kernel / DB / Runtime / Conf file descriptors, ulimit, conntrack PostGIS / profil d’import Optimiser l’architecture Cache de niveau 2 – Object Storage Séparation DB / Render
- 43. 300+ Références 43 Pourquoi n’es-tu pas sur cette liste?
- 44. Jawg Lab Viens, on est bien!
- 45. White Papers 1. Map services: from theory to implementation Disponible maintenant @ http://jawg.io 2. Map services: Benchmarks & high-scale profiles Disponibles sur demande
- 46. Loïc Ortola CEO @ jawg Loïc Ortola @LoicOrtola loic@jawg.io jawgmaps Merci ?