O blog da AWS

Case Neurolake: como usar os pilares do AWS Well-Architected a favor do seu crescimento.

Considerando os ciclos de desenvolvimento ágeis de uma aplicação, pode ser desafiador tomar decisões sobre design e funcionalidades. Para guiar a construção de sistemas seguindo as melhores práticas de arquitetura, a AWS criou o AWS Well-Architected, um framework orientado a maximizar os benefícios de desenvolvimento na nuvem AWS. O Neurolake foi um produto criado seguindo esse framework, aplicando de forma prática os conceitos dos 5 pilares do Well-Architected, que são: Excelência Operacional, Segurança, Resiliência, Eficiência de Performance e Otimização de Custos. Neste post, vamos analisar como nós da Neurotech construímos o Neurolake empregando o Well-Architected e os benefícios gerados para os clientes.

O Neurolake é uma plataforma de Inteligência Artificial e Big Data criada pela Neurotech que se propõe a facilitar a construção de soluções de Machine Learning As A Service (MLaaS). O propósito do serviço é dar oportunidades de negócios e aprendizado para quem acredita no poder dos dados e da inteligência artificial.

Para suportar tudo isso, precisávamos construir a solução da melhor maneira. Durante o desenvolvimento sempre tivemos o nosso mindset voltado para segurança, escalabilidade e custo. Mas, com o tempo, descobrimos que poderíamos ampliar a extensão do nosso mindset. O AWS Well-Architected Framework foi o guia nessa jornada.

O Neurolake nasceu de uma ideia com grande potencial em um cenário em que observamos três grandes oportunidades:

  • Acreditamos que as empresas ainda não potencializam as suas informações ao máximo.
  • Há um volume enorme de dados fora das empresas que não são utilizados.
  • Poucos cientistas e engenheiros de dados estão prontos para aproveitar estas oportunidades.

Dado o momento favorável e a cultura ágil do time, o Neurolake cresceu exponencialmente.

Para se ter uma ideia, hoje a plataforma roda em dez regiões da AWS, temos milhares de instâncias rodando diariamente e 100TB de dados sendo processados mensalmente.

 

Uso dos cinco pilares

A grande vantagem do AWS Well-Architected Framework é a divisão em cinco pilares. A AWS categorizou diversas boas práticas e isso ajuda a criar um plano de ação com mais facilidade. Assim que encontramos os pontos de melhoria e os categorizamos dentro de cada pilar, descobrimos que para escalar bem um produto são necessárias muitas outras coisas além do clássico “escalar com mais máquinas”.

No caso do Neurolake como um todo, estávamos confortáveis no pilar de Otimização de Custos, Performance e Segurança, mas isso não era verdade para Excelência Operacional por exemplo. Apesar de nos preocuparmos com a escalabilidade da solução, existiam alguns problemas de monitoramento e DevOps, onde só conseguiríamos escalar o produto com qualidade resolvendo esses pontos. As boas práticas de como montar um data lake estavam bem claras para o time, mas o Neurolake trazia muito mais desafios.

Nós não tivemos que construir uma arquitetura
escalável e eficiente, mas quatro.

A plataforma foi dividida em quatro grandes componentes independentes, cada um com requisitos e propósitos diferentes. Abaixo temos a quebra sobre cada um deles e como superamos os desafios com ajuda do AWS Well-Architected Framework.

 

Hydra

O Hydra é o responsável pela coleta dos dados em nossas centenas de fontes. Nós subimos grandes clusters, chegando a ter mais de 2.000 instâncias rodando simultaneamente, que capturam dados a todo momento. Essa estrutura chega a capturar 5TB de dados brutos semanalmente. Para sustentar esse sistema nós lançamos mão de tecnologias como Docker, Amazon SQS, instâncias do Amazon EC2, Auto Scaling Groups, além do Amazon Kinesis, que é o grande responsável por receber toda essa carga de dados que chega em alta velocidade.

Para o Hydra, o pilar de Excelência Operacional foi o que trouxe mais ganhos. O monitoramento dos clusters Hydra era muito básico e, pela natureza altamente distribuída da arquitetura, era difícil de evoluir e criar novas métricas. O fato de que os clusters são criados e destruídos com frequência também aumentava muito o custo operacional.

Os clusters Hydra concentraram todos os logs no Amazon Elasticsearch Service, enquanto o Kibana apresenta todo o monitoramento em dashboards em tempo real. Ficou mais fácil não apenas criar novas métricas de controle, mas também, criar reações automáticas para eventos. E isso levou a nossa solução para um novo patamar de eficiência.

Com ajuda do AWS Well-Architected, o time do Hydra adotou várias práticas de DevOps em sua operação. Adotamos AWS CodePipeline, AWS CodeCommit e AWS CloudFormation para automatizar o processo de testes e deploy tanto do código como da arquitetura. Toda a criação e alteração da infraestrutura passou a ser feita programaticamente. Essas novas práticas acabaram com muitas das tarefas operacionais e removeram a possibilidade de erros humanos no deploy. As boas práticas empregadas no Hydra se tornaram quase um padrão e são difundidas diariamente nos outros três componentes.

 

Flame

Para armazenar, estruturar e processar os dados gerados pelo Hydra, nós montamos uma arquitetura automatizada de processamento de Big Data. Usamos Amazon S3, clusters Elasticsearch, clusters do Amazon EMR com Spark, Presto e Hive, geralmente formados por instâncias grandes, como r4.2xlarge e c4.2xlarge,  que mensalmente processam cerca de 100TB de dados. É nessa fase que combinamos os dados para construir inteligência em forma de variáveis.

O pilar de Segurança nos ajudou a elaborar uma jornada para aperfeiçoar e blindar o Neurolake. A jornada nos deu um roteiro do que precisava ser feito e, mais do que isso, foi introduzida na cultura das squads. Todo o time se compromete a ajustar seus recursos e criar os novos, sempre respeitando os padrões de segurança. Revisamos com frequência as políticas do AWS IAM, regras de Security Groups e configurações de VPC, seguindo todas as boas práticas. Também incorporamos novos serviços na solução, como o AWS KMS, que passou a ser usado para gerenciar as chaves responsáveis por encriptar todos os nossos dados.

Outro ganho foi extinguir o acesso SSH às nossas máquinas. O SSH era nosso método padrão de conexão com instâncias EC2 e isso resultava na criação de muitas chaves e muito trabalho operacional para gerenciá-las. A chave também dava ao usuário permissões privilegiadas à infraestrutura, então o SSH passou a ser visto como um potencial ponto de falha. A solução perfeita para reforçar essa segurança foi o AWS Systems Manager Session Manager. O serviço permite conectar com as instâncias via console da AWS e o controle é feito por IAM. O Session Manager acabou com o gerenciamento e com a preocupação de vazamento das chaves, mas o principal ganho foi estimular o time a fechar o acesso humano à infraestrutura. Hoje tanto o Flame quanto os outros três componentes do Neurolake procuram construir a solução tão automatizada quanto possível.

Em relação ao pilar de Custo, também tivemos importantes melhorias para o Flame. Como o Neurolake guarda uma grande quantidade de dados, nos aprofundamos nesse pilar para diminuir os altos custos de armazenamento. O S3 Intelligent-Tiering foi uma das grandes evoluções nesse ponto. A maior vantagem foi que não precisamos fazer um estudo complexo de quais dados são mais ou menos acessados, porque isso já é feito automaticamente pelo serviço. O Flame também reduziu drasticamente o custo quando acabamos com a utilização de Amazon EBS nesse cenário. Todos os artefatos gerados pelas máquinas passaram a ser salvos no Amazon S3, com isso, padronizamos a utilização do Instance Store, que já tem o custo incluído no preço da instância.

 

Prophet

O Prophet é nosso framework de treinamento de modelos. Aqui usamos o que é considerado estado da arte em técnicas de machine learning. O Prophet executa em clusters escaláveis e, por isso, suporta treinar bases de qualquer tamanho em pouco tempo.

O Prophet precisa ser eficiente e o pilar de Performance foi importante nesse quesito. Sabemos que o tamanho da base de treinamento é uma limitação para muitos frameworks de machine learning, mas também sabemos que quanto mais dados usamos para treinar um modelo, melhor tende a ser seu desempenho. O desafio do Prophet era treinar com qualquer tamanho de base em um tempo curto.

Para suportar qualquer base de dados, introduzimos um monitoramento ativo que escala automaticamente os recursos e se adapta a diferentes cenários. Hoje o Prophet conta com vários clusters, com máquinas adequadas para cada tipo de problema.

 

Alfred

A nossa estrutura de disponibilização foi construída para responder rápido e de forma escalável. Usamos Amazon API Gateway, NLB, Amazon EC2, AutoScaling Groups, Spring Boot, Amazon DynamoDB, Amazon Kinesis e Amazon Elasticsearch Service. Tudo configurado e testado para atingir a menor latência possível. Nossa arquitetura suporta milhares de requisições por minuto garantindo um tempo de resposta de menos de 100ms.

Para o Alfred o pilar de Confiabilidade é o mais relevante. Nós já tínhamos implementado várias boas práticas, mas existiam pontos de melhoria, sendo a configuração do Amazon Elasticsearch Service um deles. Nosso cluster rodava em uma única zona de disponibilidade (AZ), e um dia, ele falhou! Por sorte, apenas o índice do Kibana foi corrompido e nós perdemos apenas os Dashboards. Os dados estavam intactos. Depois desse problema passamos a usar clusters multi-AZ para evitar novas falhas e habilitamos os Masters dedicados, sempre em número de três ou cinco, para evitar problemas de split brain. Apesar de ir contra redução de custos, a replicação garante a disponibilidade de todas as partes do Neurolake.

No mundo de disponibilização de soluções, uma das questões mais importantes a ser trabalhada é a de deploy. Quando se deseja disponibilizar uma nova versão, isso deve ser feito da maneira mais automatizada possível para evitar problemas de downtime da aplicação no momento da atualização. Para isso, aplicamos à técnica de Blue-Green Deployment no lançamento das novas versões do Alfred.

Nesse momento, estamos na fase de concepção do nosso “Automated Troubleshooting” que irá nos ajudar a aumentar ainda mais a nossa excelência operacional e confiabilidade da aplicação.

Assim que passamos a ver nosso produto pelas cinco perspectivas do AWS Well-Architected Framework, a maturidade do time também evoluiu. Nossos engenheiros de software, engenheiros de dados e cientistas de dados agora pensam em liberar soluções com a melhores práticas de excelência operacional, confiabilidade, performance, segurança e otimização de custos e isso nos dá muito mais confiança. Nós incorporamos os pilares do AWS Well-Architected na nossa cultura e inclusive os usamos como categorização das atividades no nosso processo.


Sobre os Autores

Eduardo Peixoto Macedo é coordenador de engenharia de dados da plataforma Neurolake. Ele trabalha construindo ferramentas para ajudar seus clientes a construir e evoluir negócios usando o poder dos dados.

 

 

 

 

Rafael Leandro Junior é Arquiteto de Soluções Senior na Amazon Web Services e atua ajudando empresas de diversos segmentos e localidades em suas jornadas na nuvem. Possui mais de 10 anos de experiência em TI, incluindo desenvolvimento de software, arquitetura de sistemas e gestão de equipes de desenvolvimento.

 

 

 

Natália Girolamo é Gerente Técnica de Programas para o serviço Well-Architected Tool e é apaixonada por tecnologia. Ela trabalha na AWS há 2 anos, especialmente interessada em ajudar clientes a avançarem nas jornadas de transformação digital utilizando a nuvem da AWS de forma segura.