Descubre cómo GoDaddy pasó de clusters en silos a Elasticsearch centralizado y a usar machine learning para mejorar la experiencia del usuario

Esta publicación es una recapitulación de una conversación para la comunidad presentada en <a href="/es/elasticon/conf/2018/sf">Elastic{ON}&nbsp;2018</a>. ¿Te interesa ver más conversaciones como esta? Revisa el archivo de conferencia o descubre cuándo llegará la <a href="/es/elasticon">gira de Elastic{ON}</a> a una ciudad cercana a la tuya.
A GoDaddy se le conoce por el hospedaje web y la administración de dominios, como sabría cualquiera que haya visto el Super&nbsp;Bowl en los últimos años. Pero con más de 17&nbsp;millones de clientes, 75&nbsp;millones de dominios y 10&nbsp;millones de sitios hospedados, también es experta en big data. Para que los sitios se ejecuten sin problemas es necesario contar con información de cada parte de su infraestructura, desde el nivel de parches del servidor virtual hasta los inconvenientes en la red y los ataques malintencionados. Esto podría resultar difícil debido al ingreso de más de 200&nbsp;000&nbsp;mensajes por segundo (búsquedas de DNS, logs del sistema, eventos de negocios y más), pero gracias a su velocidad a escala, el Elastic Stack está a la altura de la tarea.
La introducción de GoDaddy a Elasticsearch fue muy similar a la de otras empresas que usan software open source. Diversos equipos en toda la empresa configuraron sus propios clusters para sus necesidades específicas. Este modelo de despliegue no administrado cumplió su función, pero llevó a que cientos de clusters que se ejecutan en diversas versiones de Elasticsearch analizaran los datos en silos. Como sabían que había una mejor manera de hacerlo, formaron un equipo en torno a la administración del despliegue de Elasticsearch en&nbsp;2014. Este equipo ahora administra más de 60&nbsp;clusters de Elasticsearch que abarcan más de 700&nbsp;contenedores docker, con fuentes que provienen de los equipos de toda la empresa. Estos clusters representan más de 270&nbsp;TB de datos de su entorno HDFS (de 11&nbsp;PB).
Uno de los primeros casos de uso que enfrentó su nuevo equipo de Elasticsearch fue la administración del cumplimiento de los parches en todo el ecosistema. Antes de <a href="/es/products/beats">Beats</a>, en 2014, GoDaddy desarrolló agentes de Windows y Linux (similares a <a href="/es/products/beats/auditbeat">Auditbeat</a> y <a href="/es/products/beats/winlogbeat">Winlogbeat</a>) para enviar datos del sistema a Elasticsearch. Con estos agentes instalados en todos sus servidores (metal expuesto y virtuales), GoDaddy pudo obtener información valiosa sobre los niveles de parches y el cumplimiento de toda su infraestructura. Y gracias al uso de diferentes dashboards y visualizaciones en Kibana, pudo proporcionar fácilmente información detallada sobre los parches a los administradores e ingenieros, y reportes de negocios de alto nivel a los ejecutivos; todo esto a partir de los mismos datos centralizados para que todos estuvieran en la misma página.
Es importante mantener los niveles de parches del servidor para hacer que el tráfico siga fluyendo, y ese flujo ayuda a mantener el interés de los usuarios. Si un sitio web tarda en cargar, los visitantes irán a otro. Por lo tanto, teniendo en cuenta la experiencia de sus millones de clientes, GoDaddy sabía que necesitaba hacer un seguimiento de qué tan bueno era el rendimiento de los centros de datos y de cómo este rendimiento afectaba a los visitantes. Ya tenía todos los datos que necesitaba, debido a que cada componente de sus sistemas generaba logs, pero necesitaba una manera de crear una vista holística.
<h2>Logging centralizado con machine learning para detección de anomalías</h2>GoDaddy necesitaba centralizar y analizar los diversos conjuntos de datos de rendimiento y participación, y el Elastic Stack era la respuesta. Mediante el envío de datos de netflow, datos sFlow, administración de usuario real (RUM) y datos de enrutamiento y relación de emparejamiento a Elasticsearch, GoDaddy pudo obtener una vista mucho más detallada de los datos de la experiencia del usuario y el rendimiento del sistema, un nivel de detalles que solo puede observarse analizando todas las diferentes fuentes de datos al mismo tiempo. Y desde entonces, comenzó a llevar esos datos aún más allá con la ayuda de las características de <a href="/es/products/stack/machine-learning">machine learning de 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;">
Tener acceso centralizado a enormes cantidades de datos del sistema es estupendo, pero rastrear problemas puede ser difícil. GoDaddy hace un seguimiento de cada clic e interacción del usuario en el sitio web, pero debido a que hay millones de páginas funcionando en todo el mundo, no hay forma de que ningún equipo de humanos pueda examinar todos esos datos. Afortunadamente, las características de machine learning de Elastic hacen que la detección de anomalías sea una tarea sencilla. Gracias al trabajo conjunto con expertos en machine learning en Elastic, GoDaddy ha podido implementar trabajos de machine learning enfocados en RUM que facilitaron la detección de anomalías.
<blockquote>“En términos de esfuerzo general, aprovecha al equipo de Elastic. Son de muchísima ayuda. Hemos tenido una estrecha colaboración y llamadas muy frecuentes, un canal de comunicación totalmente abierto en torno a todas las actualizaciones. Si encuentras obstáculos, consúltalos. Son muy buenos en eso”. - Felix Gorodishter, Arquitecto principal, GoDaddy
</blockquote>Mediante la especificación de un umbral para los tiempos de carga de páginas y parámetros en torno al tráfico de las páginas, el equipo de GoDaddy deja que las características de machine learning de Elastic se encarguen de aprender qué es lo normal y lo anormal, y que luego le notifique cuando haya un problema. Para que GoDaddy pueda enfocarse en lo importante, se usa machine learning para eliminar las distracciones.
Descubre cómo GoDaddy aprovecha las características de machine learning para monitorear el rendimiento del sitio hospedado, ve <a href="/es/elasticon/conf/2018/sf/stories-from-the-trenches-at-godaddy-how-big-data-insights-equal-big-money">Historias de las trincheras en GoDaddy: Cómo la información de big data equivale a mucho dinero</a> de <a href="/es/elasticon/conf/2018/sf">Elastic{ON} 2018</a>. También podrás darle un vistazo a las formas interesantes en que usa machine learning para monitorear los KPI de negocios en torno a adopciones de productos y conocer las lecciones que aprendió en el camino.
<a href="/es/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

Cómo mejoro la experiencia del usuario en GoDaddy con machine learning de Elastic

Descubre por qué Lyft tomó la solución de logging operativo en sus propias manos con Elasticsearch autoadministrado.

Esta publicación es una recapitulación de una conversación para usuarios presentada en <a href="/es/elasticon/conf/2018/sf">Elastic{ON} 2018</a>. ¿Te interesa ver más conversaciones como esta? Revisa el archivo de conferencia o descubre cuándo llegará la <a href="/es/elasticon">gira de Elastic{ON}</a> a una ciudad cercana a la tuya.
Lyft necesita una infraestructura tecnológica potente para manejar cientos de millones de viajes en todo el mundo cada año (más de 375&nbsp;millones solo en el 2017) y para asegurarse de que todos sus clientes lleguen a donde necesitan ir. Esto quiere decir que, en 2017, hubo más de 200 microservicios a lo largo de más de 10&nbsp;000 instancias de EC2; una cantidad que aumentaría en los momentos de incrementos estacionales, como víspera de Año Nuevo, (más de 2&nbsp;millones de viajes en un día) y Halloween (más de 2000 viajes por minuto en el punto máximo). Para que todos esos sistemas y viajes sigan funcionando, es importante que los ingenieros de Lyft tengan acceso a todos los logs de operaciones. Para Michael Goldsby y su equipo de Observabilidad, esto quiere decir que deben mantener el flujo del servicio de pipeline de los logs. 
En las primeras épocas de análisis de logging de Lyft, usaban Splunk Cloud como su proveedor de servicios. Pero los límites de retención de su contrato, los backup de ingesta de hasta 30&nbsp;minutos durante los períodos de mucha actividad y los costos asociados con el escalado hicieron que Lyft decidiera cambiar a Elasticsearch.
A finales de 2016, un equipo de dos ingenieros pudo hacer la transición de Splunk a Amazon Elasticsearch Service en AWS en alrededor de un mes. Empezar a usar Elasticsearch fue genial, pero había algunas partes de la oferta de AWS que no eran perfectas. Para empezar, el equipo de Goldsby quería acceder a la versión de Elasticsearch 5.x, pero AWS solo ofrecía la versión 2.3 en ese momento. Además, las instancias nuevas estaban limitadas a Amazon EBS para almacenamiento, que tenía un rendimiento y una confiabilidad por debajo de lo óptimo en la escala de Lyft. Y no todas las API de Elasticsearch estaban expuestas en AWS. Pero estas limitaciones no eran suficientes como para sobrepasar los beneficios de la transición desde Splunk Cloud.
Sin los límites de ingesta (o, al menos, con un aumento radical), el equipo de Observabilidad decidió abrir las compuertas y adoptar una nueva filosofía: “envíanos todos tus logs”. Esto subió las tasas de ingesta rápidamente de 100&nbsp;mil eventos por minuto a 1.5&nbsp;millones por minuto. Con este nuevo enfoque, las cosas se desarrollaron muy bien durante unos cuatro meses. Cuando el equipo de Goldsby experimentó tiempos de espera de ingesta altos, merma de la retención o dashboards de Kibana lentos, lo único que tuvieron que hacer fue escalar verticalmente. Y cuando alcanzaron el límite de 20&nbsp;nodos de AWS, se les dio una excepción especial que les permitió aumentar a 40&nbsp;nodos.
Pero incluso con 40&nbsp;nodos, había problemas. Problemas de clusters en rojo.
Los clusters en rojo eran un problema que el equipo de Goldsby sabía cómo solucionar (reiniciar, reemplazar los nodos, etc.). El verdadero problema era que no tenían acceso directo a sus clusters. En su lugar, tenían que presentar un ticket a Amazon, y a veces esperar por horas durante los momentos máximos del negocio para recibir soporte. Luego, el ticket necesitaría escalarse, ya que la primera línea de soporte no podía acceder a los clusters. Con el tiempo, Lyft descubrió que para acelerar el proceso de escalamiento podía dirigirse directamente a su administrador técnico de cuenta (TAM), quien se encargaría de volver a cambiar los clusters a verde.
Entre las inevitables intervenciones de soporte, el límite de la versión 2.3, el requisito de EBS y otras limitaciones impuestas por AWS (balanceo de cargas round-robin, tiempos de espera de 60&nbsp;segundos, ofuscación de API, etc.), el equipo de Observabilidad decidió volver a cambiar; esta vez a un despliegue de Elasticsearch autoadministrado on-prem. “[En AWS] no obtienes todas las características. No puedes tocar todos los botones”, dijo Goldsby. “Sentíamos que teníamos suficiente experiencia operativa interna con Elasticsearch... [como] para hacerlo”.
Con un equipo apenas mayor que el que usaron para la migración de Splunk, Lyft pudo migrar de Amazon Elasticsearch Service a Elasticsearch autoadministrado en solo dos semanas. Ahora tienen su propio despliegue, así como todas las características que habían establecido anteriormente en AWS. Esto también significa que están a cargo de todos los aspectos operativos de Elastic Stack, incluido mantener los clusters en verde y a sus usuarios (compañeros de trabajo) felices.
Descubre cómo Lyft implementó su despliegue de Elasticsearch autoadministrado viendo la conversación <a href="/es/elasticon/conf/2018/sf/lyfts-wild-ride-from-amazon-es-to-self-managed-elasticsearch">La aventura de Lyft: desde Amazon ES a Elasticsearch autoadministrado para alcanzar un análisis de log operativo</a> en <a href="/es/elasticon">Elastic{ON} 2018</a>. Aprenderás todo sobre las opciones de hardware, las decisiones de administración del ciclo de vida de indexación y más, incluida la diferencia entre “llevar logs de todo y llevar logs de cualquier cosa” en lo que respecta a la calidad de servicio.
 
<a href="/es/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

Cómo mejoro la experiencia del usuario en GoDaddy con machine learning de Elastic

Logging de Operaciones en Lyft: Migrando de Splunk Cloud a Amazon ES a Elasticsearch on-prem

Productos

Compañía

Recursos