Cet article fait suite à la synthèse des sorties annoncées lors du summit AWS re:Invent 2013 qui s’est déroulé cette année du 12 au 15 Novembre à Las Vegas. Nous allons aborder dans ce dernier article de la série l’utilisation que Netflix fait de EMR et de S3 pour sa télémétrie, comprendre la collecte des métriques de ses infrastructures World Wide en un endroit centralisé pour les utiliser dans le cadre d’un monitoring.
Cet article se base sur une présentation très intéressante de Roy Rapoport (Netflix) qui nous a fait partager l’architecture de Atlas, leur outil maison de monitoring mis en place pour traiter le volume colossale d’informations générées par leur infrastructure, autant au niveau de la collecte que de l’exploitation (analyse). L’un des points cruciaux est de pouvoir avoir un accès rapide à ces millions de métriques, à savoir une faible latence entre la génération de la métrique dans l’infrastructure distribuée et sa mise à disposition sur de multiples dimensions dans l’outil de monitoring centralisé.
Vous pourrez retrouvez également les autres articles de cette série consacrée au retour d’expérience du summit AWS en suivant ces liens Optimisation de son cluster EMR (Elastic MapReduce), Créer son NAS sur AWS : NFS, CIFS & GFS (GlusterFS) ou bien encore Accélérer la délivrance de son contenu via CloudFront et Route 53. C’est parti pour l’article 2.3 de la série ! :o)
Concept du monitoring à grande échelle avec S3 et EMR par Netflix
Netflix possède une infrastructure World Wide construite sur un modèle SOA et déployée sur AWS. L’objectif premier de Netflix en construisant son infrastructure sur AWS n’était pas de réduire les coûts mais bien d’avoir à disposition un environnement scalable pour ne pas être limité.
Un des gros chantiers dans le traitement d’un tel volume de métriques à destination du monitoring est d’une part le stockage, mais également la vitesse de mise à disposition des métriques à destination des consommateurs, qu’ils soient Ops ou bien Business oriented. Nous allons voir comment Netflix a dû faire évoluer son architecture au fil du temps avec la quantité croissante de données collectées dans leur infrastructure.
Cet article sera articulé dans un mode lessons learned.
Culture à Netflix :
- L’optimisation de la rapidité d’innovation est privilégiée par rapport aux coûts engendrés : « Ca coûtera ce que ça coûtera ».
- Intimement lié au principe précédent, ils embauchent des gens brillants (et expérimentés) qui sont autonomes et qui apporteront des expériences et des façons d’aborder les problèmes différentes de celles qui peuvent être « acquises » chez Netflix.
- Une sélection naturelle des processus est effectuée : seuls ceux qui sont utiles sont adoptés par les équipes et appliqués dans le temps.
- Décentralisation de la responsabilité des opérations : les développeurs sont responsables de leur code. Les tâches suivantes sont donc de leur responsabilité : Build, Test, Deploy, Set up alerting and monitoring &… Wake up at 2AM ! ;ob
Ancien système de monitoring :
- Système mis en place par un admin système sur son temps disponible.
- Télémétrie gérée dans un système RRD. Pour plus d’informations sur RRDTool et ses RRAs, vous pouvez lire cet article et celui-ci.
- La tenue à la charge était correcte tant que la quantité de métriques n’a pas explosé. Il a montré ses limites lors des passages successifs de différents paliers : 5/11 => 2 millions de métriques, 9/11 => 10 millions de métriques, 4/12 => 18 millions de métriques.
Nouveau système de monitoring :
La métrique
- Atlas (nouveau système) va prendre le relai de Epic (ancien système). CloudWatch fournit également des métriques. Une UI (User Interface) multi-systèmes va permettre de prendre en compte les 3 sources de métriques afin d’assurer la continuité de l’existant.
- Les métriques restent dans la région (au sens AWS) où elles sont générées pour maintenir une isolation régionale. Un endpoint par région permet de récupérer les métriques localisées et un endpoint global permet de requêter sur toutes les métriques en mode multi-régions.
- Contrairement à avant où l’identification de l’origine du métrique était réalisée de manière centralisée, c’est à présent chaque agent (client) qui envoie l’identité du serveur/application sur lequel il est installé.
- Evolution du nom des métriques : passage d’un nom de métrique (contenant de nombreuses meta-data) d’un style vecteur a.b.c.d.e.f à une liste de paires clé-valeur [(ka=va), (kb=vb), (kc=vc), (kd=vd), (ke=ve), (kf=vf)] (voir photo ci-contre). C’est l’agent qui s’occupe de générer cette liste et de l’adresser au collecteur.
- Les requêtes sur les données collectées sont exécutées via un outil maison puissant qui rend les requêtes complexes possibles, mais… les simples un peu difficiles ! :o)
Utilisation des métriques
- Toutes ces métriques sont utilisées dans des graphiques, dashboards, pour l’alerting, …
- Elles ont besoin d’être remontées rapidement, pas seulement pour le monitoring Ops, mais aussi pour les besoins analytiques de la BI.
- Durant les pics d’utilisation de la donnée, des batchs ou autres peuvent faire monter le nombre de data points requêtés à 2.8G (million) data points/s.
Architecture de Atlas v1
- L’agent sur le serveur/l’application publie la métrique sur le publish cluster (cluster de publication).
- Le poller cluster réalise régulièrement des health checks/snmp requests sur le serveur/l’application et publie également la métrique sur le publish cluster.
- La métrique est ensuite envoyée par le publish cluster au backend (shardé sur plusieurs instances) de la région et agrégée en parallèle par blocs dans des fichiers par ce même publish cluster pour être envoyée sur S3.
- Le backend est accessible via un regional endpoint et également via un global endpoint.
- Cependant le système n’est pas assez véloce.
Architecture de Atlas v2
- Passer le backend sur Cassandra avec du SSD en lieu et place des disques durs… Cher et techniquement pas sûr que ce soit une bonne solution pour répondre au besoin.
- La mémoire ! C’est une bonne solution : tout en mémoire dans des instances m2.4xlarge ! … Beaucoup trop cher compte tenu du volume de données à stocker…
- Essayons de réduire la donnée stockée (la métrique) avant de s’attaquer à l’architecture/infrastructure.
- La métrique est composée de 2 éléments : tags (le nombre d’informations qui joue sur la taille unitaire d’une métrique) & time (la fréquence, c’est à dire la répétition de cette taille).
- Les instances ont une durée de vie courte (un ou deux jours) : il n’est pas nécessaire pour la plupart des métriques de conserver l’identifiant de l’instance, car c’est un événement utilisateur qui nous intéresse et pas un événement utilisateur qui s’est produit sur cette instance particulière.
- Approche par réduction des séries de données : on conserve uniquement pour une série les informations agrégées minimum, maximum, total et count => 3, 5, 9, 14, 20 (une prise par minute, soit 5min) devient min 3, max 20, total 51, count 55. On passe de 5 à 4 data points… Mais si on augmente la taille du time bucket réduit en prenant par exemple une heure (au lieu de 5min) : on passe de 60 data points à 4. Le average n’est pas calculé car il ne permet pas de réductions ultérieures simples, contrairement au couple total & count.
- Mise en place d’un policy driven system exécuté par EMR et proposant 4 actions : preserve (conservation de la donnée intacte), drop (éviction de la donnée), consolidate (réduction de la série de données du time bucket), rollup (cumulatif, somme des valeurs pour un tag donné).
- On obtient donc 4 clusters (voir schéma ci-dessous) dont le premier est alimenté directement par le publish cluster et contient les données intactes des 6 dernières heures. Les suivants sont alimentés à partir des données, stockées dans S3, qui sont passées par EMR pour être réduites (pour rappel, c’est le publish cluster qui dépose les blocs de données agrégées dans S3). Plus on « va vers la droite », plus la réduction est importante.
- Il est possible d’ajouter des policies sur demande.
- Ces policies sont paramétrées dans l’EMR Driver.
- On obtient un stockage indéfini sur S3.
- Note personnelle : c’est le même principe que l’on retrouve dans RRDTool cité précédemment, mais à l’échelle BigData.
- On peut donc, grâce aux policies, cacher des métriques et les réactiver sur demande, définir des granularités spéciales pour des jours spéciaux et se prévenir de voir les clusters d’historisation pollués par une explosion de métriques (un développeur qui ajoute par mégarde une génération de métrique volumineuse) en ajoutant une policy qui drop la métrique avant qu’elle ne soit propagée.
Gain
Le gain est présenté ci-contre, avec les informations suivantes :
- Le Time Horizon correspond à la période de rétention de la donnée.
- La Size correspond au nombre d’instances (de type m2.4xlarge) nécessaires pour chaque cluster du backend.
- Le ratio Instances Per Hour correspond au nombre d’instances nécessaires pour le cluster pour traiter 1h de données. On notera un petit souci sur les arrondis (à l’inférieur) qui amène des résultats surprenants ! ;ob
- Le % Reduction indique le gain par rapport au premier cluster (6H) non réduit.
What’s Next :
Plusieurs pistes sont à l’étude pour améliorer encore l’existant :
- Utilisation des nouveaux types d’instances qui sont apparues entre temps pour réduire les coûts.
- Les utilisateurs des données sont très demandeurs de métriques mais ne demandent pas beaucoup de métriques différentes : l’idée serait de migrer les données les moins demandées sur des stockages moins performants, donc de réduire les coûts.
- Actuellement le délai de remontée d’une alerte par le système de monitoring est de 5 minutes. L’idée serait de mettre en place un nouveau canal dédié à la remontée des alertes pour arriver à un délai de 1 minute pour être prévenu d’un incident sur l’infrastructure World Wide.