Blog de Amazon Web Services (AWS)

Case Neurolake: Cómo utilizar los pilares de AWS Well-Architected para su crecimiento.

Teniendo en cuenta los ciclos de desarrollo ágiles de una aplicación, puede ser difícil tomar decisiones sobre diseño y funcionalidad. Para guiar los sistemas de construcción siguiendo las mejores prácticas arquitectónicas, AWS ha creado AWS Well-Architected, 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 de Well-Architected, que son: Excelencia operativa, seguridad, resiliencia, eficiencia del rendimiento y optimización de costes. En este post, analizaremos cómo en Neurotech construimos Neurolake empleando Well-Architected y los beneficios generados 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 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. AWS Well-Architected Framework fue la guía en este viaje.[MOU1]

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 dispuestos a aprovechar estas oportunidades.

Dado el tiempo favorable del equipo y la cultura ágil, 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 de cinco pilares. AWS ha categorizado una serie de buenas prácticas y esto le ayuda a crear un plan de acción con mayor facilidad. Tan pronto como encontramos los puntos de mejora y los categorizamos dentro de cada pilar, encontramos que para escalar bien un producto necesitas muchas otras cosas además del clásico «subir con más máquinas».

En el caso de Neurolake en su conjunto, nos sentimos cómodos en el pilar de Optimización de Costos, Rendimiento y Seguridad, pero esto no era cierto para la Excelencia Operacional, por ejemplo. Aunque nos preocupaba la escalabilidad de la solución, hubo algunos problemas de supervisión y DevOps, en los que solo podíamos escalar el producto con calidad resolviendo estos puntos. Las buenas prácticas sobre cómo construir un lago de datos fueron muy claras para el equipo, pero Neurolake trajo muchos más desafíos.

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

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

Hydra

Hydra es responsable de recopilar datos de nuestras cientos de fuentes. Subimos clústeres grandes, alcanzando 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 admitir este sistema, utilizamos tecnologías como Docker, Amazon SQS, instancias de Amazon EC2, Grupos de Auto Scaling y Amazon Kinesis, que es responsable de recibir toda esta carga de datos que llega a alta velocidad.

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

Los clústeres de Hydra han concentrado todos los registros en Amazon Elasticsearch Service, mientras que Kibana cuenta con todos los controles en los paneles en tiempo real. Es más fácil no solo crear nuevas métricas de control, sino también crear reacciones automáticas para eventos. Y eso llevó nuestra solución a un nuevo nivel de eficiencia.

Con la ayuda de AWS Well-Architected, el equipo de Hydra ha adoptado varias prácticas de DevOps en su funcionamiento. Hemos adoptado AWS CodePipeline, AWS CodeCommit y AWS CloudFormation para automatizar el proceso de pruebas e implementar código y arquitectura. Toda la creación y alteración de la infraestructura comenzó a realizarse 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 están generalizadas diariamente en los otros tres componentes.

Flame

Para almacenar, estructurar y procesar los datos generados por Hydra, hemos creado una arquitectura automatizada de procesamiento de Big Data. Utilizamos Amazon S3, clústeres de Elasticsearch, clústeres de Amazon EMR con Spark, Presto y Hive, que normalmente consisten en instancias grandes como r4.2xlarge y c4.2xlarge, 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 un viaje a Neurolake perfecto y blindado. El viaje nos dio un guión de lo que había que hacer y, más que eso, se introdujo en la cultura de los escuadrones. Todo el equipo se compromete a ajustar sus recursos y crear otros nuevos, respetando siempre los estándares de seguridad. Repasamos con frecuencia las directivas de AWS IAM, las reglas de grupos de seguridad y la configuración de VPC, siguiendo todas las prácticas recomendadas. También hemos incorporado nuevos servicios a la solución, como AWS KMS, que ahora se ha utilizado para gestionar las claves responsables del cifrado de todos nuestros datos.

Otra ganancia fue extinguir 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 claves y un gran trabajo operativo para administrarlas. La clave también dio al usuario permisos privilegiados para 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 lo realiza IAM. Session Manager puso fin a la gestión y la preocupación clave de fuga, 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 la solución lo más automatizada posible.

En cuanto al pilar Costo, 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 necesitamos hacer un estudio complejo de los datos a los que se accede más o menos, porque el servicio ya lo hace automáticamente. Flame también redujo drásticamente el costo cuando terminamos de usar Amazon EBS en este escenario. Todos los artefactos generados por las máquinas se han guardado en Amazon S3, por lo que hemos estandarizado el uso del almacén de instancias, que ya tiene el costo incluido en el precio de la instancia.

Prophet

Prophet es nuestro modelo de marco de entrenamiento. Aquí usamos lo que se considera estado del arte en las técnicas de aprendizaje automático. Prophet se ejecuta en clústeres escalables y, por lo tanto, admite bases de entrenamiento de cualquier tamaño en poco tiempo.

Prophet tiene que ser eficiente y el pilar de Desempeño era 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 el rendimiento. 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

Nuestro marco de implementación está diseñado para responder de forma rápida y escalable. Utilizamos Amazon API Gateway, 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, lo que garantiza 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, y la configuración de Amazon Elasticsearch Service era una de ellas. Nuestro clúster se estaba ejecutando en una sola zona de disponibilidad (AZ), y un día falló. Por suerte, sólo el índice de Kibana estaba dañado y sólo perdimos los paneles. Los datos estaban intactos. Después de este problema empezamos a utilizar clústeres Multi-AZ para evitar nuevos fallos y habilitar Masters dedicados, siempre en número de tres o cinco, para evitar problemas de cerebro dividido. 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 entrega de soluciones, uno de los problemas más importantes en los que se debe trabajar es la implementación. Cuando desee 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 Deployment en el lanzamiento de las nuevas versiones de Alfred.

En este momento, estamos en la fase de diseño de nuestra «Solución de problemas automatizada» que nos ayudará a aumentar aún más nuestra excelencia operativa y la fiabilidad de las aplicaciones.

Tan pronto como vimos 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 para la excelencia operativa, la fiabilidad, 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 los autores

 

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.