Dailymotion: La performance dans le cloud CRiP Thématique Services IT dans le Cloud 06/11/14
Dailymotion en quelques chiffres? 130 millions visiteurs uniques par mois 3 milliards de vidéos vues par mois 300 millions de visiteurs uniques via le player 85% de l audience à l internationale (Turquie, Japon, US, Pakistan ) 30000 nouvelles vidéos envoyées par jour 40 millions de vidéos hébergées 1200 serveurs et des dizaines de technos en magasin 2 nd service de vidéo en ligne 28 ème site le plus visité au niveau mondial et 1 er site européen (comscore juin 2014)
Qu est ce que la performance? Les temps de réponse côté client Des temps de chargement de la page La santé de nos services La performance business Poser les bonnes questions D avoir les réponses Définir des objectifs D avoir des résultats
Comment la mesurer? Localement / Mondialement Côté serveur / Côté client Temps réel / Sur une période déterminée Toujours / A la demande Réseaux / Système / Applicatif / End-user Indicateur type? (global, moyen, median, saisonnier )
Avec quels outils? Monitoring = alertes Shinken/Nagios -> mail/chat/phone Disponibilité humaine opérationelle Données = graphes et reporting Pinba/collectd/rrd/drraw Logs d erreurs 1ère étape de l analyse
Quid du monitoring à Dailymotion? Vision assez fine 16.000 sondes 400.000 compteurs Essentiellement côté serveur Quelques bonnes initiatives avec Gomez, Webpagetest & Keynote Développement de monitoring spécifique Real User Monitoring Stack ELK pour grapher 100% des logs (API, Mobile ) Graphite/Tessera pour améliorer la graphologie InfiniDB pour le reporting massif Sonar pour le contrôle automatique de la qualité de code Analyse du static cost avant mise en production
Difficultés récurrentes Monitoring essentiellement géré par les équipes opérationnelles Focus trop important sur la partie système et son fonctionnement (CPU, RAM, I/O ) Beaucoup de données mais pas suffisament croisées Pas assez axé sur la partie UX Focus trop important des équipes sur la mise en production Trop de temps passé sur le mettre en prod, superviser et maintenir Pas suffisamment de process sur la partie investigation Pas assez d automatisations Taille de la plateforme Site plus complexe, plus lourd avec plus de services et de requêtes Beaucoup de dette technique au niveau archi/techno
Base insuffisante, quelles solutions? Top Down mieux que Bottom Up GQM : Goal > Questions > Metrics Se concentrer sur son activité Sortir du développement par défaut Limiter les coûts d infrastructure en conservant de l élasticité Arrêter d aligner les machines pour rester scalable S assurer de la qualité de la donnée Mettre en concurrence différents monitoring
GQM et KPI Passer des métriques aux indicateurs Plus facile de trouver la donnée quand on sait quoi chercher Switcher du focus projet au focus produit Rapprocher la donnée et le business Rendre le monitoring accessible à toutes les équipes Ajouter une couche de logique (afficher une page afficher la bonne page) Axer les dashboards sur la partie business
Se concentrer sur le plus utile Pas de développement obligatoire Réduire le temps passé sur la dette technique Gagner du temps sur le déploiement Utiliser des solutions externes si possible Automatiser le maximum de choses Reporting, alerting, analyse, actions Faciliter l analyse des risques en production Gain de temps/homme en résolution de problèmes
Limiter les coûts Réflexion et remise en question récurrente de son archi Ne pas tomber dans le confort historique Benchmark régulier pour le choix des technos Eviter de tomber dans les tendances faciles Maitriser la techno et sa stack complète Migrer constamment et rapidement Eviter la dette technique Séparer les services et les équipes Permettre une meilleure granularité dans la gestion du budget Eviter les machines généralistes taillées pour faire de tout
Avoir confiance dans la donnée Mixer les monitoring Interne et externe Jouer sur la granularité Ne pas nécessairement tout historiser Echantillonner les fonctions peu critiques Détailler quand nécessaire Remonter l info jusqu à la requête finale Avoir le contexte et les métadonnées pour pouvoir reproduire le dysfonctionnement Solution >> Cloud monitoring = Application monitoring
Diversification = mixer cloud et dev maison Github Pas mieux pour la gestion de developpement CDN externes (Akamai, Edgecast, Level 3 ) Idéal pour augmenter la capacité et la qualité de distribution, plus prêt du client, moins de latence Statistiques (GA/SiteCat) Métier différent, ultra concurrentiel avec une forte demande des partenaires Danger potentiel sur la perte de contrôle des données Solutions de monitoring/test externe (Keynote) Idéal pour tester la QA de son site à l internationale BIG QUERY Le cloud par Google, puissant mais cher
Le monitoring de la performance dans le cloud Leader mondial des APM (gestion de la performance des applications). Carnet d adresse énorme : Netflix, Roku, Yahoo!, Brightcove, Fox, Apple, Meetic, Nous Des fonctionnalités en masse : Permet de suivre le flux de transactions à travers tous les niveaux de services et dans un environnement hautement distribué Idéal pour assurer un monitoring sur un service qui n en possède pas ou pour complèter l existant Facilité de déploiement, d utilisation et de customisation Toutes les qualités du cloud dans un seul service (SaaS, API, évolutif, multi technos )
Conclusion Anticiper la performance et les indicateurs nécessaires en amont du projet (KPIs) Conserver un équilibre entre le monitoring interne et l usage du cloud (comparer, bencher, tester) Remettre en question régulièrement les objectifs, les indicateurs et les choix
Questions