SAP Concur: Elastic Logging como estrategia de DevOps

Esta publicación es un resumen de una charla comunitaria dada en Elastic{ON} 2018. ¿Te interesa ver más charlas como esta? Consulta el archivo de la conferencia o averigua cuándo llegará el Elastic{ON} Tour a una ciudad cercana a ti.

Si alguna vez ingresaste un reporte de gastos, es muy probable que lo hayas hecho a través de SAP Concur. Con más de 45 millones de usuarios en más de 150 países (incluido el 70% de las compañías Fortune 500), Concur es una solución líder en viajes y gastos. Solo en 2016, la oferta SaaS procesó más de 87 000 millones de dólares en gastos, lo que equivale a más de 2.4 millones de comprobantes y 187 millones de dólares en facturación diaria. Puede parecer muchas partidas para contabilidad, pero genera aún más líneas de registro para que una solución de logging las gestione a diario.

Concur lleva más de 20 años en el mercado y, a medida que su oferta de productos creció y evolucionó, también evolucionó su solución de logging. No solo en la tecnología que emplean, sino también en el alcance y la intención de su uso. Inicialmente, una solución basada en SQL empleada para almacenamiento sencillo de logs, su solución actual de logging — construida sobre Elastic Stack — ayuda a promover la propiedad de la aplicación de extremo a extremo y alinea desarrollo, pruebas y operaciones. Y en el futuro, el equipo LAMA (por su sigla en inglés para "Registro, alerta, monitoreo y analíticas") de Concur planea emplear el Machine Learning de Elastic para análisis e información operativos, así como para automatizar despliegues y retrocesos. Dieron grandes pasos en el logging o registro, pero no pasaron del almacenamiento de logs a la analítica de la noche a la mañana.

Originalmente construida sobre una base de datos relacional, su solución de logging ingestaba log data en XML a través de RabbitMQ, y a sus usuarios les encantaba poder consultar fácilmente los logs usando SQL. Pero a medida que crecía la popularidad del servicio, también aumentaba su uso. Cuando el pico de ingesta alcanzó los 200 GB/día, con tasas superiores a 1500 doc/seg, el servicio llegó a sus límites, y los retrasos por rendimiento podían obligar a los usuarios a esperar hasta 20 minutos para que un log estuviera disponible en el sistema. En respuesta, todo lo que el equipo de logging pudo hacer fue poner su base de datos en un hardware más potente, lo cual era un proceso insostenible. Lo que necesitaban era escalabilidad horizontal, así que se propusieron encontrar una mejor solución.

Tras investigar sobre Elasticsearch y escuchar diferentes historias de éxito de empresas en situaciones similares, Concur eligió Elastic Stack como su solución de registro. Era rápido, poderoso y escalable, y (posiblemente lo más importante para sus usuarios internos) tenía un componente de visualización que a sus usuarios les encantaba. Anteriormente, diferentes equipos creaban sus propias interfaces y paneles, a menudo incurriendo en tarifas de licencia por las herramientas que tenían que usar para hacer el trabajo. Con Kibana, Concur contó con una solución unificada de visualización, que eliminó la necesidad de soluciones de visualización internas o de terceros.

La primera implementación de Elastic fue con Elasticsearch 1.1 y Kibana 3, con la ingesta proveniente de Logstash, RabbitMQ (igual que la que usaron con la solución SQL) y Fluentd. El equipo de logging también pudo crear su propio plugin de alertas (un beneficio de la naturaleza de open source de Elastic), ya que aún no existía uno dentro de Elastic Stack. Entre la mayor velocidad de Elasticsearch, las visualizaciones de Kibana y las características de alertas de su plugin Watcher de origen propio, la adopción de servicios aumentó en Concur y la ingesta se disparó hasta 5000 doc/seg. Eso es algo que su solución SQL no podría conseguir.

Crecer de la solución a la estrategia con Elastic

Desde esa implementación inicial, la solución de logging de Concur creció junto con el Elastic Stack. En 2015, actualizaron a Elasticsearch 2.3 y Kibana 4.5, compraron una Suscripción oro y comenzaron a usar Beats (como sustituto de Fluentd), Watcher (para sustituir su solución autóctona) y Shield (por seguridad). También crearon otro plugin personalizado, esta vez una interfaz de agregación personalizada. A medida que mejoró su solución de logging, también lo hizo la adopción, y para 2017, su tasa de ingesta alcanzó los 60.000 doc/seg (4TB/día).

Después de asistir a Elastic{ON} 2017, Concur se actualizó nuevamente, esta vez para aprovechar la búsqueda entre clústeres, la seguridad mejorada (necesaria para garantizar el cumplimiento del GDPR) y otras nuevas características del Elastic Stack que habían aprendido durante la conferencia. Usando la búsqueda entre clústeres, pudieron dividir su clúster monolítico en múltiples y más pequeños clústeres repartidos en múltiples regiones. Esta actualización de versión, así como su cambio a una Suscripción Platino, les ha ayudado a establecer el entorno que usan hoy en día, con una variedad de fuentes de ingesta, clústeres de Elasticsearch en múltiples regiones (5 TB/día en los EE. UU.) y dashboards de Kibana utilizados por operaciones, SRE, soporte, liderazgo ejecutivo y más. Y todo eso es administrado por un equipo LAMA compuesto por seis ingenieros y dos gerentes.

Descubre cómo Concur pasó del almacenamiento de registros a la habilitación de propiedad viendo Elastic @ SAP Concur: Impulsar el camino hacia DevOps y la propiedad de extremo a extremo de Elastic{ON} 2018. También aprenderás cómo habilitaron el despliegue del servicio de logging con un solo clic, cómo configuraron los mapeos (no dinámicos) y campos para más de 200 equipos, y cuáles son sus planes para aprovechar el poder del Machine Learning de Elastic.