A tradução do artigo foi preparada especialmente para os alunos do curso . Está interessado em se desenvolver nesta área? Assista ao masterclass de Egor Zuev (TeamLead na empresa InBit) e junte-se ao próximo grupo do curso: início em 26 de setembro.
Cada vez mais pessoas estão migrando para o AWS Lambda devido à escalabilidade, desempenho, economia e à capacidade de processar milhões, até trilhões, de solicitações por mês. Para isso, não é necessário gerenciar a infraestrutura em que o serviço opera. A auto-escalabilidade permite atender a milhares de solicitações simultâneas por segundo. Acredito que o AWS Lambda pode ser corretamente chamado de um dos serviços mais procurados da AWS.
AWS Lambda
O AWS Lambda é um serviço de computação sem servidor orientado a eventos que permite executar código sem a necessidade de provisionar e administrar servidores, complementando outros serviços da AWS com base na lógica do usuário. O Lambda reage automaticamente a vários eventos (os chamados gatilhos), como solicitações HTTP via Amazon API Gateway, alterações de dados em buckets do Amazon S3 ou tabelas do Amazon DynamoDB; ou você pode executar seu código através de chamadas de API, utilizando o AWS SDK e transições entre estados no AWS Step Functions.
O Lambda executa código em uma infraestrutura de computação altamente disponível e é totalmente responsável pela administração da plataforma subjacente, incluindo manutenção de servidores e do sistema operacional, provisionamento de recursos, escalabilidade automáticas, monitoramento de código e registro. Ou seja, você só precisa fazer o upload do seu código e configurar como e quando ele deve ser executado. O serviço se encarrega de lançá-lo e proporcionar alta disponibilidade ao seu aplicativo.
Quando migrar para o Lambda?
O AWS Lambda é uma plataforma de computação conveniente, adequada para uma variedade de cenários de aplicação, desde que a linguagem e o ambiente de execução do seu código sejam suportados pelo serviço. Se você deseja se concentrar no código e na lógica do negócio, delegando a manutenção de servidores, provisionamento de recursos e escalabilidade a um fornecedor terceirizado por um preço razoável, definitivamente vale a pena migrar para o AWS Lambda.
O Lambda é ideal para a criação de interfaces de programação, e ao utilizar o serviço juntamente com o API Gateway, é possível reduzir significativamente os custos e acelerar a entrada no mercado. Existem várias maneiras de usar as funções Lambda e opções para organizar uma arquitetura sem servidor — cada um pode escolher algo adequado com base no objetivo estabelecido.
O Lambda permite realizar uma ampla gama de tarefas. Assim, com o suporte do CloudWatch, é possível criar tarefas agendadas e automatizar processos individuais. Não há restrições quanto à natureza e intensidade do uso do serviço (são considerados o consumo de memória e o tempo), e nada impede você de trabalhar de forma planejada em um microserviço completo baseado no Lambda.
Aqui é possível criar ações orientadas a serviços que não são executadas continuamente. Um exemplo típico é a escalabilidade de imagens. Mesmo em sistemas distribuídos, as funções Lambda permanecem relevantes.
Portanto, se você não quer se preocupar em alocar e administrar recursos computacionais — experimente o AWS Lambda; se você não precisa de cálculos pesados e intensivos em recursos — também experimente o AWS Lambda; se seu código é executado periodicamente — está correto, você deve experimentar o AWS Lambda.
Segurança
Até o momento, não há queixas sobre a segurança. Por outro lado, como muitos processos internos e características de implementação deste modelo são ocultados do usuário do ambiente gerenciado da AWS Lambda, algumas regras comuns de segurança na nuvem perdem relevância.
Como a maioria dos serviços da AWS, o Lambda é fornecido segundo o princípio de responsabilidade compartilhada entre a AWS e o cliente em termos de segurança e conformidade regulamentar. Este princípio reduz a carga operacional sobre o cliente, uma vez que a AWS assume as tarefas de manutenção, administração e controle dos componentes do serviço — desde o sistema operacional do host e nível de virtualização até a segurança física da infraestrutura.
Falando especificamente sobre o AWS Lambda, a AWS é responsável pela gestão da infraestrutura subjacente, serviços básicos associados, sistema operacional e plataforma de aplicativos. Enquanto isso, o cliente é responsável pela segurança de seu código, armazenamento de dados confidenciais, controle de acesso a esses dados, bem como ao serviço e recursos Lambda (Identity and Access Management, IAM), incluindo dentro das funções utilizadas.
O diagrama abaixo mostra o modelo de responsabilidade compartilhada aplicável ao AWS Lambda. A área de responsabilidade da AWS é marcada em laranja, enquanto a responsabilidade do cliente é mostrada em azul. Como pode ver, a AWS assume mais responsabilidade pelas aplicações implantadas no serviço.
Modelo de responsabilidade compartilhada aplicável ao AWS Lambda
Ambiente de execução do Lambda
A principal vantagem do Lambda é que, ao executar funções em seu nome, o serviço aloca automaticamente os recursos necessários. Você pode evitar gastar tempo e esforço na administração de sistemas e se concentrar na lógica de negócios e na escrita de código.
O serviço Lambda é dividido em duas camadas. A primeira é a camada de controle. De acordo com a Wikipedia, a camada de controle é a parte da rede responsável pelo transporte do tráfego de sinalização e pela roteação. Ela é o componente principal que toma decisões globais sobre alocação, manutenção e distribuição de cargas de trabalho. Além disso, a camada de controle atua como a topologia de rede do provedor de soluções, responsável pela roteação e gerenciamento do tráfego.
A segunda camada é a camada de dados. Assim como a camada de controle, ela possui suas próprias funções. A camada de controle fornece APIs para gerenciar funções (CreateFunction, UpdateFunctionCode) e controla a interação do Lambda com outros serviços da AWS. A camada de dados gerencia APIs de chamadas (Invoke API), que acionam funções Lambda. Após a chamada de uma função, a camada de controle aloca ou seleciona um ambiente de execução existente, previamente preparado para essa função, e então executa o código nele.
O AWS Lambda suporta várias linguagens de programação, incluindo Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 e outras, através de seus respectivos ambientes de execução. O AWS atualiza regularmente esses ambientes, distribui correções de segurança e realiza outras operações de manutenção. O Lambda permite o uso de outras linguagens, desde que você implemente seu próprio ambiente de execução. Nesse caso, você também será responsável pela manutenção dele, incluindo a segurança.
Como tudo isso funciona e como o serviço executará suas funções?
Cada função opera em um ou mais ambientes dedicados, que existem apenas durante o ciclo de vida dessa função e, em seguida, são destruídos. Em cada ambiente, apenas uma solicitação é executada ao mesmo tempo, mas ele é reutilizado se houver várias solicitações em série da mesma função. Todos os ambientes de execução funcionam em máquinas virtuais com virtualização de hardware — os chamados microVM. Cada microVM é atribuída a uma conta específica da AWS e pode ser reutilizada várias vezes por diferentes ambientes para executar diversas funções nessa conta. Os microVM são empacotados nas unidades estruturais da plataforma de hardware Lambda Worker, propriedade da AWS. O mesmo ambiente de execução não pode ser usado por diferentes funções, assim como os microVM são únicos para diferentes contas AWS.
Modelo de isolamento no AWS Lambda
O isolamento dos ambientes de execução é implementado através de vários mecanismos. No nível mais alto, existem cópias separadas dos seguintes componentes em cada ambiente:
- Código da função
- Quaisquer camadas Lambda escolhidas para a função
- Ambiente de execução da função
- Espaço de usuário mínimo baseado no Amazon Linux
Os seguintes mecanismos são aplicados para isolar diferentes ambientes de execução:
- cgroups — limitando o acesso aos recursos da CPU, memória, largura de banda de armazenamento e rede para cada ambiente de execução;
- namespaces — agrupando IDs de processos, IDs de usuários, interfaces de rede e outros recursos gerenciados pelo núcleo Linux. Cada ambiente de execução opera em seu próprio espaço de nome;
- seccomp-bpf — limitando chamadas de sistema que podem ser usadas no ambiente de execução;
- iptables e tabelas de roteamento — isolando ambientes de execução entre si;
- chroot — fornecimento de acesso restrito ao sistema de arquivos subjacente.
Em combinação com as tecnologias proprietárias de isolamento da AWS, os mecanismos listados garantem uma separação confiável dos ambientes de execução. Ambientes isolados dessa forma não podem acessar ou modificar os dados de outros ambientes.
Embora vários ambientes de execução de uma conta AWS possam ser executados em uma única microVM, em nenhuma circunstância as microVM podem ser compartilhadas entre diferentes contas AWS. Para o isolamento das microVM, o AWS Lambda utiliza apenas dois mecanismos: instâncias EC2 e Firecracker. O isolamento de convidados (guest isolation) no Lambda baseado em instâncias EC2 é aplicado desde 2015. O Firecracker é um novo hipervisor de código aberto, projetado especificamente pela AWS para cargas de trabalho sem servidor, apresentado em 2018. O hardware físico em que as microVM são executadas é compartilhado entre cargas de trabalho de diferentes contas.
Salvamento de ambientes e estados dos processos
Embora os ambientes de execução do Lambda sejam únicos para diferentes funções, uma mesma função pode ser invocada várias vezes, ou seja, o ambiente de execução pode existir por várias horas antes de ser destruído.
Em cada ambiente de execução do Lambda, também existe um sistema de arquivos com permissão de escrita, acessível através do diretório /tmp. Seu conteúdo não pode ser acessado de outros ambientes de execução. Quanto ao salvamento dos estados dos processos, os arquivos gravados em /tmp existem durante todo o ciclo de vida do ambiente de execução. Isso permite acumular resultados de várias invocações, o que é especialmente útil para operações dispendiosas, como o carregamento de modelos de aprendizado de máquina.
Transferência de dados das invocações
A interface Invoke API pode ser utilizada em dois modos: modo de eventos e modo de 'request-response'. No modo de eventos, a invocação é colocada em uma fila para execução posterior. No modo de 'request-response', a função é invocada instantaneamente com a carga útil fornecida, após a qual uma resposta é retornada. Em ambos os casos, a função é executada no ambiente Lambda, mas com diferentes caminhos de carga útil.
Durante chamadas do tipo "solicitação-resposta", a carga útil é recebida pela API de processamento de solicitações (API Caller), como o AWS API Gateway ou AWS SDK, no balanceador de carga, e depois na função de execução de chamadas Lambda (Invoke Service). Esta última determina o ambiente adequado para a execução da função e encaminha a carga útil para concluir a chamada. O balanceador de carga recebe tráfego com proteção TLS pela Internet. O tráfego dentro do serviço Lambda - após o balanceador de carga - passa através do VPC interno em uma região específica da AWS.
Modelo de processamento de chamadas AWS Lambda: modo "solicitação-resposta"
Chamadas de eventos podem ser executadas imediatamente ou colocadas em uma fila. Em alguns casos, a fila é implementada através do Amazon SQS (Amazon Simple Queue Service), que transmite chamadas para o serviço de execução de chamadas Lambda por meio de um processo interno de polling (poller). O tráfego transmitido é protegido por TLS, sem qualquer criptografia adicional dos dados armazenados no Amazon SQS.
Chamadas de eventos não retornam respostas - qualquer informação de resposta do Lambda Worker é simplesmente ignorada. Chamadas baseadas em eventos do Amazon S3, Amazon SNS, CloudWatch e outras fontes são processadas pelo serviço Lambda em modo de eventos. Chamadas de streams do Amazon Kinesis e DynamoDB, chamadas de filas SQS, balanceador de carga de aplicativos e API Gateway são processadas no modo "solicitação-resposta".
Monitoramento
Você pode monitorar e auditar funções Lambda usando vários mecanismos e serviços da AWS, incluindo os seguintes.
Amazon CloudWatch
Coleta várias estatísticas, como o número de solicitações, a duração das solicitações e o número de solicitações que resultaram em erro.
Amazon CloudTrail
Permite registrar, monitorar continuamente e manter informações sobre atividades em sua conta relacionadas à sua infraestrutura AWS. Você terá um histórico completo das ações realizadas por meio do console AWS Management Console, AWS SDK, ferramentas de linha de comando e outros serviços da AWS.
AWS X-Ray
Oferece total visibilidade de todas as etapas de processamento de solicitações em seu aplicativo com base no mapa de seus componentes internos. Permite analisar aplicativos durante o desenvolvimento e no ambiente de produção.
AWS Config
Você poderá monitorar as alterações na configuração das funções Lambda (incluindo sua exclusão) e no ambiente de execução, tags, nomes dos manipuladores, tamanho do código, alocação de memória, configurações de tempo limite e parâmetros de paralelismo, bem como a função IAM do Lambda, sub-rede e vinculações de grupos de segurança.
Conclusão
O AWS Lambda oferece um poderoso conjunto de ferramentas para criar aplicações seguras e escaláveis. Muitos métodos de segurança e conformidade regulatória no AWS Lambda são semelhantes aos usados em outros serviços da AWS, embora haja exceções. Desde março de 2019, o Lambda atende às exigências do SOC 1, SOC 2, SOC 3, PCI DSS, a lei dos EUA sobre privacidade e responsabilidade na saúde (HIPAA) e outras regulamentações. Portanto, ao pensar em implementar uma nova aplicação, considere o serviço AWS Lambda — pode ser a melhor opção para sua necessidade.
Fonte: habr.com
