APROFUNDAMENTO NA CATEGORIA
Sem servidor
Introdução
O Aprofundamento na arquitetura sem servidor apresenta conceitos básicos, arquiteturas de referência, recomendações e atividades práticas para ajudar você a começar a criar aplicações sem servidor. Se você for iniciante em arquiteturas sem servidor, esse é o melhor lugar para começar. Para profissionais mais experientes em arquiteturas sem servidor, temos recursos e links para tópicos mais avançados.
O que significa sem servidor?
A arquitetura sem servidor permite criar e executar aplicações e serviços sem preocupações com servidores. Ela elimina as tarefas de gerenciamento de infraestrutura, como provisionamento de servidores ou de clusters, patches, manutenção do sistema operacional e provisionamento de capacidade. Você pode criá-la para praticamente qualquer tipo de aplicação ou serviço de back-end, e cuidaremos de tudo o que for necessário para executar e escalar suas aplicações com alta disponibilidade.
As aplicações sem servidor são orientadas por eventos e fracamente acopladas a sistemas de mensagens ou APIs independentes de tecnologias. Um código orientado por evento é executado em resposta a um evento, como uma alteração no estado ou uma solicitação de um endpoint. As arquiteturas orientadas por eventos desacoplam o código do estado. A integração entre componentes fracamente acoplados é normalmente feita de forma assíncrona, com mensagens.
O AWS Lambda é um serviço de computação sem servidor, adequado a arquiteturas orientadas por eventos. As funções do Lambda são acionadas por eventos por meio de fontes de eventos integradas, como o Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS) e Amazon Kinesis, que podem ser usados para criar integrações assíncronas. As funções do Lambda consomem e produzem eventos que outros serviços podem então consumir.
Os modelos de arquiteturas sem servidor usam o Lambda com outros serviços gerenciados, que também não têm servidores. Além de serviços de streaming e de mensagens, as arquiteturas sem servidor usam serviços gerenciados, como Amazon API Gateway para o gerenciamento de API, o Amazon DynamoDB para datastores e o AWS Step Functions para orquestração. A plataforma sem servidor também conta com um conjunto de ferramentas para desenvolvedores, que inclui o Serverless Application Model (SAM – Modelo de aplicação sem servidor), que ajuda a simplificar as implantações e testes das funções do Lambda e das aplicações sem servidor.
Por que usar a arquitetura sem servidor?
Gerenciamento sem servidor: não é necessário provisionar ou manter nenhum servidor. Sem software ou tempo de execução para instalar, manter ou administrar.
Escalabilidade flexível: sua aplicação pode ser escalada automaticamente ou com o ajuste da capacidade por meio da alternação das unidades de consumo (por exemplo, taxa de transferência ou memória) em vez de unidades de servidores individuais.
Custo-benefício: pague por uma taxa de transferência consistente ou pela duração da execução, e não por unidade de servidor.
Alta disponibilidade automatizada: a arquitetura sem servidor incorpora disponibilidade e tolerância a falhas. Não é necessário definir a arquitetura desses recursos, pois os serviços que executam a aplicação os fornecem por padrão.
Principais serviços sem servidor
As aplicações sem servidor são normalmente criadas usando serviços totalmente gerenciados como blocos de construção nas camadas de computação, dados, mensagens e integrações, streaming, gerenciamento de usuários e identidade. Serviços como o AWS Lambda, API Gateway, SQS, SNS, EventBridge ou Step Functions são o núcleo da maioria das aplicações, e têm o suporte de serviços como DynamoDB, S3 ou Kinesis.
| Categoria |
Serviço |
Descrição |
|---|---|---|
| Computação | AWS Lambda | O AWS Lambda permite a execução de aplicações sem servidor e sem estado em plataformas gerenciadas, compatíveis com arquiteturas de microsserviços, implantações e gerenciamento da execução no nível da função. |
| Proxy de API | API Gateway | O Amazon API Gateway é um serviço totalmente gerenciado que facilita a criação, publicação, manutenção, monitoramento e segurança de APIs em qualquer escala para os desenvolvedores. Ele oferece uma plataforma abrangente para o gerenciamento de APIs. O API Gateway permite o processamento de milhares de chamadas de API simultâneas e administra o gerenciamento do tráfego, a autorização e o controle de acesso, o monitoramento e o gerenciamento de versões da API. |
| Sistemas de mensagens e integração | SNS | O Amazon SNS é um serviço de mensagens de publicação/assinaturas totalmente gerenciado, que facilita desacoplar e escalar microsserviços, sistemas distribuídos e aplicações sem servidor. |
| SQS | O Amazon SQS é um serviço de fila de mensagens que facilita desacoplar e escalar microsserviços, sistemas distribuídos e aplicações sem servidor. |
|
| EventBridge | OAmazon EventBridge é um barramento de eventos sem servidor que facilita a conexão de aplicações usando dados das suas próprias aplicações, de aplicações de Software como Serviço (SaaS) integradas e de serviços da AWS. |
|
| Orquestração | Step Functions |
O AWS Step Functions facilita a coordenação de componentes de aplicações e microsserviços distribuídos, usando fluxos de trabalho visuais. |
Vamos criar!
Aqui estão alguns recursos para ajudar você a conhecer os principais serviços sem servidor.
Crie uma função do Lambda chamada Hello World, usando o console do AWS Lambda e aprenda os conceitos básicos da execução de código sem provisionamento ou gerenciamento de servidores.
Crie uma função do Lambda invocada pelo Amazon S3, toda vez que um arquivo de imagem for carregado em um bucket S3, e crie automaticamente uma miniatura dessa imagem.
Use o console do Lambda para criar uma função do Lambda e um endpoint do Amazon API Gateway para acionar a função criada.
Saiba como usar o AWS Step Functions para criar e executar um fluxo de trabalho sem servidor que coordene várias funções do AWS Lambda.
Princípios básicos
Nesta seção você aprenderá sobre o design orientado por eventos, o fundamento principal das aplicações sem servidores escaláveis.
Uma arquitetura orientada por eventos usa eventos para acionar respostas e se comunicar entre serviços desacoplados. Um evento é uma mudança ou uma atualização no estado, como um item adicionado a um carrinho de compras em um site de comércio eletrônico. Os eventos podem transportar o estado (como o item comprado, o preço ou um endereço de entrega) ou podem ser identificadores (como uma notificação de que um pedido foi despachado, por exemplo).
As arquiteturas orientadas por eventos têm três componentes: os produtores, os roteadores e os consumidores do evento. Um produtor publica o evento no roteador, que filtra e envia os eventos aos consumidores. Os serviços de produtores e de consumidores são desacoplados, o que permite que sejam dimensionados, atualizados e implantados de forma independente.
Para entender porque uma arquitetura orientada por eventos é desacoplada, vamos examinar uma chamada de API síncrona.
Os clientes utilizam os microsserviços fazendo chamadas de API HTTP. O Amazon API Gateway hospeda as solicitações HTTP RESTful e as respostas aos clientes. O AWS Lambda contém a lógica de negócios para processar as chamadas de API recebidas, e usa o DynamoDB como um armazenamento persistente.
Quando invocado de forma síncrona, o API Gateway espera uma resposta imediata e tem um tempo limite de 30 segundos. Se a resposta do Lambda exigir mais de 30 segundos nas fontes de eventos síncronas, você será responsável por escrever todos os códigos para tratar erros e realizar novas tentativas. Por isso, todos os erros ou problemas de dimensionamento que ocorrerem em qualquer componente downstream, após o cliente, como unidades de capacidade de leitura e gravação no DynamoDB, serão retornados ao cliente para tratamento pelo código de front-end. Usando modelos assíncronos e desacoplando esses componentes, você cria um sistema mais robusto e altamente escalável.
Aprenda a implementar um cenário de distribuição de mensagens enviadas por push a vários assinantes, eliminando a necessidade de verificar ou procurar periodicamente atualizações, e permitindo o processamento assíncrono paralelo da mensagem pelos assinantes.
Saiba como criar um produtor e um consumidor de eventos no AWS Lambda, e crie uma regra para rotear os eventos.
As funções do Lambda são acionadas por eventos. Elas executam o código em resposta a esse trigger e também podem gerar seus próprios eventos. Existem várias opções para acionar uma função do Lambda, e você tem bastante flexibilidade para criar fontes de eventos personalizadas para atender às suas necessidades específicas.
Os principais tipos de fontes de evento são:
- Datastores, como o Amazon S3, Amazon DynamoDB ou Amazon Kinesis, podem acionar funções do Lambda. Se armazenarem dados cujas alterações você deseja monitorar, eles poderão potencialmente ser usados como uma fonte de evento.
- Endpoints que emitem eventos podem invocar o Lambda. Por exemplo, quando você pedir que Alexa faça algo, ela emitirá um evento que acionará uma função do Lambda.
- Serviços de mensagens, como Amazon SQS ou Amazon SNS, podem também ser fontes de eventos. Por exemplo, quando você envia algo por push a um tópico do SNS, ele pode acionar uma função do Lambda.
- Quando certas ações ocorrem em um repositório, como a confirmação de código para o repositório do AWS CodeCommit, elas podem acionar uma função do Lambda, por exemplo, para iniciar o processo de criação em CI/CD (integração contínua/entrega contínua).
Saiba tudo sobre a invocação das funções do AWS Lambda, com o guia do desenvolvedor.
Nesta seção, você encontrará um conjunto de arquiteturas de referência que abordam casos de uso comuns de aplicações sem servidor.
-
Microsserviços do RESTful
As tecnologias sem servidor são criadas em infraestruturas altamente disponíveis e tolerantes a falhas, permitindo que você crie serviços confiáveis para as cargas de trabalho de missão crítica. Os principais serviços sem servidor da AWS são altamente integrados a dezenas de outros serviços da AWS, e aproveitam os benefícios da AWS e de ferramentas terceirizadas de outros parceiros. Esse ecossistema facilita o processo de compilação, além de automatizar tarefas, orquestrar serviços e dependências e monitorar os microsserviços. Com os serviços sem servidor da AWS, você paga somente pelo que usa. Isso permite aumentar o uso de acordo com seus negócios e manter os custos reduzidos quando o uso for baixo. Todos esses recursos tornam as tecnologias sem servidor ideais para a criação de microsserviços resilientes.
Exemplo de arquitetura de microsserviço RESTful
Os clientes utilizam os microsserviços fazendo chamadas de API HTTP. O ideal é que seus consumidores tenham um contrato de serviço totalmente integrado à API, para que atinjam expectativas consistentes em relação aos níveis de serviço e ao controle das alterações.
O Amazon API Gateway hospeda as solicitações HTTP RESTful e as respostas aos clientes. Nesse cenário, o API Gateway oferece autorização, controle de utilização, segurança, tolerância a falhas, mapeamento de solicitações e respostas, e otimizações de performance integrados.
O AWS Lambda contém a lógica de negócios para processar as chamadas de API recebidas, e usa o DynamoDB como um armazenamento persistente.
O Amazon DynamoDB armazena persistentemente os dados e escalas dos microsserviços, com base na demanda. Como os microsserviços são geralmente criados para realizar bem uma única tarefa, um datastore NoSQL sem esquema é regularmente incorporado.
-
Processamento de imagens
O processamento de imagens é uma carga de trabalho comum que pode ser orientada por eventos e exige o ajuste dinâmico da escala, o que pode ser feito muito bem pelas tecnologias sem servidor. Normalmente, as imagens são armazenadas no Amazon S3, que pode acionar funções do Lambda para o processamento. Depois do processamento, a função do Lambda pode retornar a versão modificada para outro bucket do S3 ou para o API Gateway.
O diagrama abaixo apresenta a arquitetura do processador de imagens sem servidor que você pode implantar em alguns minutos, usando o guia de implementação da solução e o respectivo modelo do AWS CloudFormation.
O AWS Lambda recupera imagens do bucket do Amazon Simple Storage Service (Amazon S3) e usa o Sharp para retornar uma versão modificada da imagem ao Amazon API Gateway. A solução gera um nome de domínio do Amazon CloudFront, que concede acesso com cache à API do processador de imagens.
Além disso, a solução implanta uma interface de usuário opcional de demonstração, onde você interage diretamente com o endpoint da API do processador, usando arquivos de imagem já existentes na conta. A interface do usuário é implantada em um bucket do Amazon S3 para que os clientes comecem imediatamente a manipular imagens com uma interface da Web simples. O CloudFront é usado para restringir o acesso ao conteúdo do bucket do site da solução.
Implantar a solução >>
-
Processamento de streams
Você pode usar o AWS Lambda e o Amazon Kinesis para processar dados de streaming em tempo real para monitoramento de atividades de aplicações, processamento de pedidos de transações, análise da sequência de cliques, limpeza de dados, geração de métricas, filtragem de logs, indexação, análise de mídias sociais, e telemetria e medição de dados de dispositivos da IoT.
Exemplo da arquitetura de processamento de streams
A arquitetura descrita neste diagrama pode ser criada com um modelo do AWS CloudFormation . O modelo fará o seguinte:
- Criará um stream do Kinesis
- Criará uma tabela do DynamoDB chamada -EventData
- Criará a Função 1 do Lambda (-DDBEventProcessor) que receberá registros do Kinesis e gravará registros na tabela do DynamoDB
- Criará uma política e função do IAM para que o evento que processa a função do Lambda possa ler o stream do Kinesis e gravar na tabela do DynamoDB
- Criará um usuário do IAM com permissões para criar eventos do stream do Kinesis com credenciais que o usuário possa usar em um cliente da API
-
Aplicação Web
Usando a computação sem servidor na AWS, você pode implantar toda a pilha de aplicações Web, sem gerenciar servidores, provisionar capacidade ou pagar por recursos ociosos. Tudo isso sem sacrificar a segurança, a confiabilidade ou a performance. As aplicações Web criadas com as tecnologias sem servidor oferecem alta disponibilidade e podem ser escaladas globalmente sob demanda.
- Os consumidores dessas aplicações Web podem estar concentrados geograficamente ou dispersos por todo o mundo. O uso do Amazon CloudFront não só promove uma experiência de melhor performance para esses consumidores, por meio do armazenamento em cache e do excelente roteamento original, mas também limita as chamadas redundantes para o back-end.
- O Amazon S3 hospeda os ativos estáticos da aplicação Web e é atendido com segurança pelo CloudFront.
- Um grupo de usuários do Amazon Cognito oferece gerenciamento de usuários e recursos de provedor de identidade para a aplicação Web.
- Em vários cenários, quando os usuários fazem o download de conteúdos estáticos do Amazon S3, o conteúdo dinâmico precisa ser enviado ou recebido pela aplicação. Por exemplo, quando um usuário envia dados em um formulário, o Amazon API Gateway atua como o endpoint seguro para fazer essas chamadas e retornar as respostas exibidas pela aplicação Web.
- Uma função do AWS Lambda oferece operações de criação, leitura, atualização e exclusão (CRUD) no DynamoDB para a aplicação Web.
- O Amazon DynamoDB fornece o datastore NoSQL de back-end para escalar de maneira elástica com o tráfego da aplicação Web.
- Os consumidores dessas aplicações Web podem estar concentrados geograficamente ou dispersos por todo o mundo. O uso do Amazon CloudFront não só promove uma experiência de melhor performance para esses consumidores, por meio do armazenamento em cache e do excelente roteamento original, mas também limita as chamadas redundantes para o back-end.
Uma boa prática para implantações em uma arquitetura de microsserviço é garantir que uma alteração não interrompa o contrato de serviço do consumidor. Se o proprietário da API fizer uma alteração que interrompa o contrato de serviço e o consumidor não estiver preparado para isso, poderão ocorrer falhas.
Para entender o impacto da implantação de alterações, você deverá saber quais consumidores estão usando a API. Você pode coletar metadados sobre o uso, usando as chaves de API. Isso pode atuar também como uma forma de contrato, se uma alteração que cause interrupções for feita na API.
Quando os clientes quiserem amenizar o impacto de alterações que causam interrupções a uma API, será possível clonar e direcionar os clientes para um subdomínio diferente (por exemplo, v2.my-service.com), garantindo que os consumidores existentes não sejam afetados. Essa abordagem permite que os clientes implantem somente as novas alterações ao novo contrato de serviço da API, mas tem também desvantagens. Os clientes que adotarem essa abordagem precisarão manter duas versões da API e terão que arcar com as despesas de provisionamento e gerenciamento da infraestrutura.
| Implantação |
Impacto no cliente |
Reversão | Fatores do modelo de eventos |
Velocidade da implantação |
|---|---|---|---|---|
| Todas de uma vez | Todas de uma vez | Reimplantação de uma versão mais antiga | Qualquer modelo de evento com baixa taxa de simultaneidade | Imediatamente |
| Azul/Verde | Todas de uma vez, com algum nível de teste anterior no ambiente de produção | Reversão do tráfego para o ambiente anterior | Melhor para modelos de eventos síncronos ou assíncronos, em cargas de trabalho com simultaneidade média | Minutos ou horas de validação, seguindo imediatamente para os clientes |
| Canário/Linear | Mudança de 1 a 10% no tráfego inicial, com aumentos graduais ou todas de uma vez | Reversão de 100% do tráfego para a implantação anterior | Melhor para cargas de trabalho com simultaneidade alta | De minutos a horas |
-
Todas as implantações de uma vez
Fazer todas as implantações de uma vez envolve fazer alterações nas configurações existentes. Uma vantagem desse estilo de implantação é que as alterações do back-end nos datastores, como um banco de dados relacional, exigem um nível de esforço bem menor para conciliação das transações durante o ciclo de alterações. Apesar desse estilo de implantação exigir baixo esforço e poder ser feito com pouco impacto nos modelos de baixa simultaneidade, ele pode adicionar riscos no caso de reversões, podendo causar inatividade. Um exemplo de uso desse modelo de implantação é em ambientes de desenvolvimento onde o impacto do usuário é mínimo.
-
Implantações azuis/verdes
Com o modelo de implantação azul/verde, os clientes transferem uma seção do tráfego para um novo ambiente (verde), mantendo o ambiente antigo (azul) ativo, caso o sistema precise ser revertido. Ao usar esse modelo, é melhor reduzir as alterações para que as reversões possam ser feitas rápida e facilmente. As implantações azul/verde foram criadas para reduzir a inatividade. Vários clientes estão usando esse modelo para implantações na produção. O API Gateway permite definir facilmente a porcentagem do tráfego que é transferido para o novo ambiente verde, tornando-o uma ferramenta eficiente para esse modelo de implantação.
Esse estilo de implantação é adequado principalmente para arquiteturas sem servidor, que são sem estado e desacopladas da infraestrutura básica.
Você precisará ter os indicadores corretos para determinar se uma reversão é necessária. A melhor prática recomendada é o uso das métricas de alta resolução do CloudWatch, que monitoram em intervalos de 1 segundo e capturam rapidamente as tendências de declínio. Usadas com os alarmes do CloudWatch, você pode permitir uma reversão rápida. As métricas do CloudWatch podem ser capturadas no API Gateway, Step Functions, Lambda (incluindo métricas personalizadas) e DynamoDB.
-
Implantações canário
As implantações canário são uma forma cada vez mais usada de utilizar a nova versão de um software em um ambiente controlado, permitindo ciclos de implantações rápidas. As implantações canário envolvem implantar um pequeno número de solicitações à nova alteração para analisar o impacto em um pequeno número de usuários.
Com as implantações canário no API Gateway, você pode implantar uma alteração no endpoint de back-end (o Lambda, por exemplo), mantendo o mesmo endpoint de HTTP do API Gateway para os consumidores. Além disso, você pode controlar a porcentagem do tráfego direcionado para a nova implantação e para uma troca de tráfego controlada. Um cenário prático da implantação canário pode ser um novo site. Você pode monitorar as taxas de clique em um pequeno número de usuários, antes de transferir todo o tráfego para a nova implantação.
Uso de implantações canário de funções do AWS Lambda com transferência de tráfego aliasSaiba como usar as implantações canário de funções do AWS Lambda.
Implantação gradual de aplicações sem servidorO AWS SAM oferece implantações de Lambda graduais para aplicações sem servidor.