Découvrez comment GoDaddy est passée de clusters cloisonnés à un système Elasticsearch centralisé avant de finalement utiliser le machine learning pour

Cet article résume une conférence donnée à l'<a href="/fr/elasticon/conf/2018/sf">Elastic{ON}&nbsp;2018</a>. Vous souhaitez voir d'autres présentations comme celle-ci&nbsp;? Consultez les archives ou renseignez-vous sur les prochaines dates de l'<a href="/fr/elasticon">Elastic{ON} Tour</a>.
Si vous avez regardé le Super&nbsp;Bowl ces dernières années, vous savez certainement que GoDaddy est une entreprise spécialisée dans la gestion de noms de domaine qui offre des services d'hébergement Web. Avec plus de 17&nbsp;millions de clients, 75&nbsp;millions de domaines et 10&nbsp;millions de sites hébergés, GoDaddy maîtrise aussi le big data. Pour s'assurer du bon fonctionnement des sites, l'entreprise doit avoir les yeux rivés sur chaque composant de l'infrastructure, qu'il s'agisse du niveau des correctifs des serveurs virtuels, de légers problèmes de réseau passagers ou d'attaques malveillantes. Avec plus de 200&nbsp;000&nbsp;messages reçus chaque seconde (recherches DNS, logs système, événements métier, etc.), la tâche promet d'être difficile, mais la vitesse évolutive de la Suite Elastic permet de relever ce défi.
La manière dont GoDaddy a adopté Elasticsearch fut semblable à celle d'autres entreprises qui utilisent des logiciels open source. Des équipes variées au sein de l'entreprise commencèrent à configurer leurs propres clusters pour répondre à des besoins précis. Même si ces équipes arrivaient à leurs fins, ce modèle de déploiement désordonné vit naitre des centaines de clusters qui s'exécutaient sur différentes versions d'Elasticsearch pour analyser des données cloisonnées. Consciente de pouvoir mieux faire, l'entreprise forma en 2014 une équipe pour gérer le déploiement d'Elasticsearch. Cette équipe gère aujourd'hui plus de 60&nbsp;clusters Elasticsearch qui englobent plus de 700 conteneurs Docker, avec des flux provenant de toute l'entreprise. Ces clusters contiennent plus de 270&nbsp;To de données qui viennent de leur environnement HDFS (11&nbsp;Po).
Sans attendre, la nouvelle équipe Elasticsearch s'attaqua à la gestion de la conformité des correctifs sur tout l'écosystème de l'entreprise. Dans l'univers pré-<a href="/fr/products/beats">Beats</a> de 2014, GoDaddy développa des agents Windows et Linux (semblables à <a href="/fr/products/beats/auditbeat">Auditbeat</a> et à <a href="/fr/products/beats/winlogbeat">Winlogbeat</a>) pour envoyer des données système à Elasticsearch. En installant ces agents sur tous ses serveurs (physiques et virtuels), GoDaddy obtint de précieuses informations sur le niveau des correctifs et leur conformité dans toute son infrastructure. Grâce aux tableaux de bord et aux visualisations de Kibana, l'entreprise fut capable de fournir des informations précises sur les correctifs aux administrateurs et aux ingénieurs, ainsi que des rapports de haut niveau aux dirigeants, et ce, en accédant aux mêmes données centralisées pour que tout le monde puisse être sur la même longueur d'onde.
Il est important d'assurer la maintenance des niveaux de correctif de serveur pour garantir la fluidité du trafic des sites. Cette fluidité favorise l'engagement des utilisateurs. Si un site Web se charge lentement, les visiteurs s'en vont. Avec ses millions de clients en ligne de mire, GoDaddy était parfaitement consciente qu'elle devait suivre le niveau de performance de ses data centers et en évaluer l'impact sur les visiteurs. Elle disposait déjà de toutes les données nécessaires, car chaque composant de ses systèmes générait des logs, mais elle nécessitait une façon holistique de les analyser.
<h2>Détection des anomalies&nbsp;: logging centralisé avec le machine learning</h2>GoDaddy avait besoin de centraliser et d'analyser ses nombreux ensembles de données de performance et d'engagement, ce qu'elle fit avec la Suite Elastic. En envoyant les données Netflow, sFlow, RUM (Real User Monitoring), de relations de peering et de routage à Elasticsearch, l'entreprise bénéficia d'un panorama bien plus détaillé de l'expérience d'utilisation et des performances système. Ce niveau de détail peut seulement être obtenu en analysant simultanément toutes les différentes sources de données. Depuis, GoDaddy exploite toujours plus ces données grâce aux fonctionnalités de <a href="/fr/products/stack/machine-learning">machine learning d'Elastic</a>.
<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb09951bb4979ea15/5c304e986e9992e16f52993d/go_daddy_RUM.jpg" data-sys-asset-uid="bltb09951bb4979ea15" style="display: block; margin: auto;">
Cela va sans dire que l'accès centralisé à des montagnes de données système confère des avantages inouïs, cependant l'identification des problèmes reste complexe. GoDaddy suit tous les clics et toutes les interactions de chaque utilisateur, mais aucune équipe humaine n'est capable de traiter les données provenant de millions de pages de par le monde. Heureusement, les fonctionnalités de machine learning d'Elastic simplifient la détection des anomalies. En collaborant avec les experts en machine learning d'Elastic, GoDaddy a implémenté des tâches de machine learning axées sur le RUM qui facilitent la détection des anomalies.
<blockquote>"Faites appel à votre équipe Elastic pour contribuer à vos efforts. Elle est vraiment utile. L'étroite collaboration que nous avons établie s'est traduite par de très nombreux appels et une ligne de communication absolument transparente sur toutes les mises à jour. Contactez-les dès que vous êtes bloqués. Ils sont très bons pour résoudre les problèmes." - Felix Gorodishter, architecte en chef, GoDaddy
</blockquote>En indiquant un seuil de durée de chargement et des paramètres de trafic, l'équipe GoDaddy confie aux fonctionnalités de machine learning d'Elastic la tâche d'apprendre ce qui est normal et ce qui ne l'est pas, ainsi que de signaler les problèmes. Le machine learning neutralise le bruit et permet à GoDaddy de se concentrer sur ce qui est important.
Découvrez comment GoDaddy bénéficie des fonctionnalités de machine learning d'Elastic pour monitorer les performances des sites qu'elle héberge en regardant <a href="/fr/elasticon/conf/2018/sf/stories-from-the-trenches-at-godaddy-how-big-data-insights-equal-big-money">Histoires de tranchée chez GoDaddy&nbsp;: des résultats de big data très fructueux</a> de l'<a href="/fr/elasticon/conf/2018/sf">Elastic{ON}&nbsp;2018</a>. Vous pourrez aussi entrevoir comment GoDaddy utilise le machine learning pour monitorer les KPI d'adoption de produit et connaitre les leçons apprises au fil du temps.
<a href="/fr/elasticon/conf/2018/sf/stories-from-the-trenches-at-godaddy-how-big-data-insights-equal-big-money"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1004b59c5e7fde10/5c304e93ad674d236e76489e/go_daddy_cohort_ml.jpg" data-sys-asset-uid="blt1004b59c5e7fde10" alt="" style="display: block; margin: auto;"></a>

go_daddy_banner.jpg

go_daddy_thumb.jpg

Improving the GoDaddy User Experience with Elastic Machine Learning

GoDaddy améliore son expérience d'utilisation grâce au machine learning d'Elastic

Découvrez pourquoi Lyft a pris en main sa propre solution de logging opérationnel avec Elasticsearch auto-géré.

Cet article résume un témoignage d'utilisateur donné à l'<a href="/fr/elasticon/conf/2018/sf">Elastic{ON}&nbsp;2018</a>. Vous souhaitez voir d'autres présentations comme celle-ci&nbsp;? Consultez les archives ou renseignez-vous sur les prochaines dates de l'<a href="/fr/elasticon">Elastic{ON} Tour</a>.
Quelle différence entre Amazon Elasticsearch&nbsp;Service et notre offre Elasticsearch&nbsp;Service officielle&nbsp;? Pour le savoir, comparez les <a href="/fr/aws-elasticsearch-service#full-comparison">offres Elasticsearch&nbsp;Service d'AWS et d'Elastic sur cette page</a>.
Lyft a besoin d'une infrastructure technologique puissante pour gérer des centaines de millions de trajets chaque année dans le monde entier (plus de 375&nbsp;millions rien qu'en 2017) et veiller à ce que tous leurs clients puissent atteindre leur destination. En 2017, cela correspondait à plus de 200&nbsp;microservices sur plus de 10&nbsp;000&nbsp;instances EC2. Ces valeurs sont encore plus importantes pour les périodes de pointe comme pour la Saint-Sylvestre (&gt; 2&nbsp;millions de trajets en un jour) et Halloween (plus de 2&nbsp;000&nbsp;trajets par minute en période de pointe). Pour assurer un fonctionnement parfait de tous ces systèmes et de tous ces trajets, il est important que les ingénieurs de Lyft aient accès à tous les logs opérationnels. Pour Michael&nbsp;Goldsby et son équipe Observability, cela revient à assurer un service de pipeline des logs constant. 
Au début de son expérience d'analyse de logs, Lyft a utilisé le prestataire de services Splunk&nbsp;Cloud. Mais à cause des limites de rétention liées à son contrat, des délais d’ingestion des sauvegardes pouvant atteindre 30&nbsp;minutes en période de pointe, et des coûts associés à la montée en charge, Lyft a décidé de passer à Elasticsearch.
Fin 2016, une équipe de deux&nbsp;ingénieurs a pu réaliser la transition de Lyft de Splunk à Amazon Elasticsearch Service sur AWS en environ deux&nbsp;mois. Le passage à Elasticsearch était fantastique, mais certaines parties de l'offre AWS n'étaient pas parfaites. Pour commencer, l'équipe de Goldsby voulait passer à Elasticsearch&nbsp;5.x, mais AWS ne proposait que la version&nbsp;2.3 à l'époque. De plus, les nouvelles instances étaient limitées à Amazon&nbsp;EBS pour le stockage, et la performance et la fiabilité à l'échelle de Lyft étaient sous-optimales. Enfin, les API Elasticsearch n'étaient pas toutes exposées sur AWS. Mais les limites d'AWS n'étaient rien par rapport aux avantages de la transition depuis Splunk&nbsp;Cloud.
Une fois les limites d'ingestion supprimées (ou du moins, repoussées considérablement), l'équipe Observability a décidé d'ouvrir grand les portes et d'adopter une nouvelle philosophie&nbsp;: "envoyez-nous tous vos logs". Les taux d'ingestion sont rapidement passés de 100&nbsp;000&nbsp;événements par minute à 1,5&nbsp;million d'événements par minute. Cette nouvelle approche a permis un fonctionnement parfait pendant environ quatre&nbsp;mois. Lorsque l'équipe de Goldsby a commencé à rencontrer des expirations des délais d'ingestion, une réduction de la rétention et un ralentissement des tableaux de bord Kibana, il a suffi de monter en charge. Et lorsque la limite de 20&nbsp;nœuds a été atteinte sur AWS, elle a reçu une exception spéciale lui permettant d'utiliser jusqu'à 40&nbsp;nœuds.
Mais même avec 40&nbsp;nœuds, certains problèmes subsistaient. Des problèmes de cluster rouge.
Les clusters rouges étaient un problème que l'équipe de Goldsby savait corriger (redémarrer, remplacer les nœuds, etc.). Le véritable problème, c'est qu'elle n'avait aucun accès direct aux clusters. À la place, il fallait créer un ticket chez Amazon et attendre le support technique, parfois pendant des heures en période de pointe. Le ticket était ensuite remonté, car la première ligne de support technique ne pouvait pas accéder aux clusters. Finalement, Lyft a appris que pour accélérer le processus de remontée, il était possible de s'adresser directement au Technical Account Manager (TAM), qui s'occuperait de faire en sorte que les clusters repassent au vert.
Entre les interventions inévitables du support technique, la limite à la version&nbsp;2.3, l'exigence d'EBS et les autres limites imposées par AWS (équilibrage de charge en round-robin, délais d'expiration de 60&nbsp;secondes, obscurcissement des API, etc.), l'équipe Observability a décidé de procéder à une nouvelle transition, cette fois, vers un déploiement Elasticsearch auto-géré. "[Sur AWS], on ne profite pas de toutes les fonctionnalités. On ne peut pas appuyer sur tous les boutons", explique Goldsby. "Nous sentions que nous avions assez d'expérience opérationnelle avec Elasticsearch en interne pour pouvoir réussir."
Avec une équipe un peu plus importante que celle utilisée pour la migration depuis Splunk, Lyft a pu passer d'Amazon Elasticsearch Service à une solution Elasticsearch auto-gérée en seulement deux&nbsp;semaines. Lyft dispose désormais de son propre déploiement, ainsi que de toutes les fonctionnalités qui étaient auparavant limitées sur AWS. Cela signifie également que l'entreprise est responsable de tous les aspects opérationnels de la Suite Elastic, y compris maintenir ses clusters dans le vert et assurer la satisfaction de ses utilisateurs (collègues).
Découvrez comment Lyft a mis en œuvre son propre déploiement Elasticsearch auto-géré en regardant la présentation <a href="https://www.elastic.co/elasticon/conf/2018/sf/lyfts-wild-ride-from-amazon-es-to-self-managed-elasticsearch">La folle aventure de Lyft d'Amazon&nbsp;ES à Elasticsearch auto-géré pour l'analyse des logs opérationnels</a> à l'<a href="https://www.elastic.co/elasticon">Elastic{ON}&nbsp;2018</a>. Vous découvrirez les choix concernant le matériel, les décisions de gestion du cycle de vie des indices et bien plus, y compris la raison pour laquelle "tout logger" ne signifie pas "logger tout" pour ce qui est de la qualité de service.
<a href="/fr/elasticon/conf/2018/sf/lyfts-wild-ride-from-amazon-es-to-self-managed-elasticsearch"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt666fd2101df677e6/5c57e1848c741b010cbf6af9/lyft_thumb_play.jpg" data-sys-asset-uid="blt666fd2101df677e6" alt="lyft_thumb_play.jpg" style="display: block; margin: auto;"></a>

Articles by Tony Sleva

GoDaddy améliore son expérience d'utilisation grâce au machine learning d'Elastic

Logging opérationnel chez Lyft : migration de Splunk Cloud à Amazon ES et Elasticsearch auto-géré

Produits

Entreprise

Ressources