Caso Neurolake: Cómo utilizar los pilares de AWS Well-Architected Framework en favor de su crecimiento

Teniendo en cuenta los ciclos de desarrollo ágiles de una aplicación, puede ser difícil tomar decisiones sobre su diseño y su funcionalidad. Para guiar la construcción de soluciones siguiendo las mejores prácticas de arquitectura, AWS ha creado el AWS Well-Architected Framework, un marco diseñado para maximizar los beneficios del desarrollo en la nube de AWS. Neurolake fue un producto creado siguiendo este marco, aplicando de manera práctica los conceptos de los 5 pilares del Well-Architected, que son: Excelencia Operativa, Seguridad, Confiabilidad, Eficiencia del Rendimiento y Optimización de Costos. En este post, analizaremos cómo en Neurotech construimos Neurolake empleando el Well-Architected y los beneficios obtenidos para los clientes.

Neurolake es una plataforma de Inteligencia Artificial y Big Data creada por Neurotech, que tiene como objetivo facilitar la construcción de soluciones de Machine Learning As A Service (MLaAs). El propósito del servicio es proporcionar oportunidades de negocios y aprendizaje para aquellos que creen en el poder de los datos y la inteligencia artificial.

Para apoyar todo esto, necesitábamos construir la solución de la mejor manera. Durante el desarrollo, siempre tuvimos nuestra mentalidad enfocada en la seguridad, la escalabilidad y el costo. Pero con el tiempo, descubrimos que podíamos ampliar el alcance de nuestra mentalidad. El AWS Well-Architected Framework fue la guía en este camino.

Neurolake nació de una idea con gran potencial en un escenario donde observamos tres grandes oportunidades:

• Creemos que las empresas todavía no aprovechan su información al máximo.
• Hay una gran cantidad de datos fuera de las empresas que no se utilizan.
• Pocos científicos e ingenieros de datos están preparados para aprovechar estas oportunidades.

Dado el momento favorable y la cultura ágil del equipo, Neurolake creció exponencialmente.

Para tener una idea, hoy en día la plataforma se ejecuta en diez regiones de AWS, contamos con miles de instancias que se ejecutan diariamente y 100 TB de datos que se procesan mensualmente.

Utilización de los cinco pilares

La gran ventaja de AWS Well-Architected Framework es la división en sus cinco pilares. AWS categorizó una serie de buenas prácticas que le permiten crear un plan de acción con mayor facilidad. Tan pronto como encontramos los puntos de mejora categorizados dentro de cada pilar, nos encontramos que, para escalar bien un producto, necesitas muchas otras cosas además del clásico «escalar con más máquinas».

En el caso de Neurolake como un todo, nos sentíamos cómodos en los pilares de Optimización de Costos, Rendimiento y Seguridad, pero no era el caso del pilar de Excelencia Operacional, por ejemplo. Aunque nos preocupaba la escalabilidad de la solución, existían algunos problemas de monitoreo y DevOps, en los que solo podíamos escalar el producto con calidad resolviendo esos puntos. Las buenas prácticas sobre cómo construir un lago de datos estaban muy claras para el equipo, pero Neurolake traía muchos más desafíos.

No tuvimos que construir una arquitectura escalable y eficiente, sino cuatro.

La plataforma se dividió en cuatro grandes componentes independientes, cada uno con diferentes requisitos y propósitos. A continuación se muestra el detalle de cada uno de ellos y cómo superamos los desafíos con la ayuda del AWS Well-Architected Framework.

Hydra

Hydra es responsable de recopilar los datos de cientos de nuestras fuentes. Utilizamos grandes clusters, alcanzando a tener más de 2.000 instancias ejecutándose simultáneamente, que capturan datos en todo momento. Esta estructura captura 5 TB de datos sin procesar semanalmente. Para soportar este sistema, utilizamos tecnologías como Docker, Amazon Simple Queue Service (SQS), instancias de Amazon Elastic Compute Cloud (EC2), Auto Scaling Groups y Amazon Kinesis, quien es el responsable de recibir toda la carga de datos que llega a gran velocidad.

Para Hydra, el pilar de la Excelencia Operacional fue el que más beneficios aportó. El monitoreo de los clústeres de Hydra era muy básico y debido a la naturaleza altamente distribuida de la arquitectura, era difícil evolucionar y crear nuevas métricas. El hecho de que los clusters se crean y se destruyen con frecuencia también aumentaba considerablemente el costo operacional.

Para ello, los clústeres de Hydra concentran todos los logs en Amazon Elasticsearch Service, mientras que Kibana presenta todo el monitoreo en dashboards en tiempo real. Fue más fácil no solo crear nuevas métricas de control, sino también crear acciones automáticas ante eventos. Y eso llevó nuestra solución a un nuevo nivel de eficiencia.

Con la ayuda del AWS Well-Architected, el equipo de Hydra adoptó varias prácticas de DevOps en su operación. Hemos adoptado AWS CodePipeline, AWS CodeCommit y AWS CloudFormation para automatizar el proceso de pruebas y despliegue tanto de código como de arquitectura. Toda la creación y modificación de la infraestructura comenzó a hacerse programáticamente. Estas nuevas prácticas eliminaron muchas de las tareas operativas y eliminaron la posibilidad de errores humanos en el despliegue. Las buenas prácticas empleadas en Hydra se han convertido casi en un estándar y son extendidas diariamente en los otros tres componentes.

Flame

Para almacenar, estructurar y procesar los datos generados por Hydra, creamos una arquitectura automatizada de procesamiento de Big Data. Utilizamos Amazon Simple Storage Service (S3), clusters de Elasticsearch, clusters de Amazon EMR con Spark, Presto y Hive, que normalmente consisten en instancias grandes, como r4.2xlarge y c4.2xlarge, y que cada mes procesan alrededor de 100 TB de datos. Es en esta etapa que combinamos los datos para construir inteligencia en forma de variables.

El pilar de Seguridad nos ayudó a elaborar el camino para perfeccionar y blindar a Neurolake. El camino nos dio un guion de lo que se tenía que hacer y, más que eso, se introdujo en la cultura de los equipos. Todo el equipo se compromete a ajustar sus recursos y crear otros nuevos, respetando siempre los estándares de seguridad. Revisamos con frecuencia las políticas de AWS Identity and Access Management (IAM), las reglas de grupos de seguridad y la configuración de las VPC, siguiendo todas las buenas prácticas recomendadas. También hemos incorporado nuevos servicios a la solución, como AWS Key Management Service (KMS), que pasó a ser usado para gestionar las llaves responsables del cifrado de todos nuestros datos.

Otra ganancia fue eliminar el acceso SSH a nuestras máquinas. SSH era nuestro método estándar de conexión a instancias EC2, y esto dio como resultado la creación de muchas llaves de acceso y un gran trabajo operacional para administrarlas. La llave también daba al usuario permisos privilegiados a la infraestructura, por lo que SSH fue visto como un posible punto de falla. La solución perfecta para reforzar esta seguridad fue AWS Systems Manager Session Manager. El servicio le permite conectarse a las instancias a través de la consola de AWS y el control es ejecutado por IAM. Session Manager puso fin a la gestión y a la preocupación por la fuga de llaves, pero la principal ventaja fue estimular al equipo a cerrar el acceso humano a la infraestructura. Hoy, tanto Flame como los otros tres componentes de Neurolake, buscan construir una solución lo más automatizada posible.

En cuanto al pilar Optimización de Costos, también hemos tenido importantes mejoras para Flame. Debido a que Neurolake posee una gran cantidad de datos, profundizamos en este pilar para reducir los altos costos de almacenamiento. El S3 Intelligent-Tiering fue uno de los principales desarrollos en este punto. La mayor ventaja fue que no necesitabamos hacer un estudio complejo de los datos que se acceden en mayor o menor medida, porque el servicio ya lo hace automáticamente. Flame también redujo drásticamente el costo cuando acabamos con la utilización de Amazon Elastic Block Store (EBS) en este escenario. Todos los artefactos generados por las máquinas pasaron a ser guardados en Amazon S3 y, con eso, estandarizamos el uso del Instance Store, que ya tiene el costo incluido en el precio de la instancia.

Prophet

Prophet es nuestro framework de entrenamiento de modelos. Aquí usamos lo que es considerado estado del arte en las técnicas de aprendizaje automático. Prophet se ejecuta en clusters escalables y, por tanto, admite bases de entrenamiento de cualquier tamaño en poco tiempo.

Prophet tiene que ser eficiente y el pilar de Rendimiento fue importante en ese sentido. Sabemos que el tamaño de la base de entrenamiento es una limitación para muchos marcos de aprendizaje automático, pero también sabemos que cuantos más datos usamos para entrenar un modelo, mejor tiende a ser su desempeño. El desafío de Prophet era entrenar con cualquier tamaño base en poco tiempo.

Para admitir cualquier base de datos, hemos introducido un monitoreo activo que escala automáticamente los recursos y se adapta a diferentes escenarios. Hoy Prophet tiene múltiples clústeres, con máquinas adecuadas para cada tipo de problema.

Alfred

Nuestra estructura de implementación está diseñada para responder de forma rápida y escalable. Utilizamos Amazon API Gateway, Network Load Balancer (NLB), Amazon EC2, AutoScaling Groups, Spring Boot, Amazon DynamoDB, Amazon Kinesis y Amazon Elasticsearch Service. Todo configurado y probado para lograr la latencia más baja posible. Nuestra arquitectura admite miles de solicitudes por minuto garantizando un tiempo de respuesta inferior a 100 ms.

Para Alfred, el pilar de la Fiabilidad es el más relevante. Ya habíamos implementado varias buenas prácticas, pero había puntos de mejora, siendo la configuración de Amazon Elasticsearch Service una de ellas. Nuestro cluster se estaba ejecutando en una sola zona de disponibilidad (AZ) y, un día, éste falló. Por suerte, sólo el índice de Kibana fue corrompido y sólo perdimos los dashboards. Los datos estaban intactos. Después de este problema empezamos a utilizar clusters Multi-AZ para evitar nuevos fallos y habilitamos Masters dedicados, siempre en número de tres o cinco, para evitar problemas de split brain. Aunque va en contra del ahorro de costos, la replicación garantiza la disponibilidad de todas las partes de Neurolake.

En el mundo de la disponibilización de soluciones, uno de los problemas más importantes en los que se debe trabajar es la implementación. Cuando se desea hacer disponible una nueva versión, esto debe hacerse de la manera más automatizada posible para evitar problemas de tiempo de inactividad de la aplicación en el momento de la actualización. Para ello, aplicamos a la técnica Blue-Green Deployments en el lanzamiento de las nuevas versiones de Alfred.

En este momento, estamos en la fase de diseño de nuestro «Automated Troubleshooting» que nos ayudará a aumentar aún más nuestra excelencia operativa y la confiabilidad de las aplicaciones.

Tan pronto como comenzamos a ver nuestro producto desde las cinco perspectivas de AWS Well-Architected Framework, la madurez del equipo también evolucionó. Nuestros ingenieros de software, ingenieros de datos y científicos de datos ahora piensan en lanzar soluciones con las mejores prácticas de la Excelencia Operativa, la Confiabilidad, el Rendimiento, la Seguridad y la Optimización de Costos, y eso nos da mucha más confianza. Incorporamos pilares de AWS Well-Architected en nuestra cultura e incluso los usamos como categorización de actividades en nuestro proceso.

Sobre el autor

Eduardo Peixoto Macedo es coordinador de ingeniería de datos para la plataforma Neurolake. Trabaja en la creación de herramientas para ayudar a sus clientes a construir y desarrollar negocios utilizando el poder de los datos.

Rafael Leandro Junior es arquitecto senior de soluciones en Amazon Web Services y asiste a empresas de diversos segmentos y ubicaciones en sus viajes en la nube. Tiene más de 10 años de experiencia en TI, incluyendo desarrollo de software, arquitectura de sistemas y gestión de equipos de desarrollo.

Natália Girolamo es gerente técnica de programas para Well-Architected Tool y es apasionada por la tecnología. Ha trabajado en AWS durante 2 años, especialmente interesada en ayudar a los clientes a avanzar en sus viajes de transformación digital utilizando la nube de AWS de forma segura.

Revisor

David Felipe Sandoval Alvarado es Solutions Architect en AWS Colombia.