A Amazon Web Services (AWS) lançou para o público em geral o Lambda@Edge, permitindo que seus clientes executem funções lambda do Node.js em seus pontos de presença espalhados mundialmente, o que permite respostas dinâmicas com baixa latência para usuários finais.
Com o Lambda@Edge desenvolvedores podem enviar código Node.js para o AWS Lambda, um serviço "serverless" da Amazon que é executado automaticamente de forma escalável e com alta disponibilidade em um ponto de presença próximo ao usuário final, o que melhora a latência e reduz a sobrecarga na origem. O código no Lambda@Edge é disparado por eventos originados do Amazon CloudFront, uma rede de entrega de conteúdo (CDN) que entrega com segurança dados, vídeos, aplicações e APIs para usuários finais com baixa latência e alta taxa de transferência.
O Lambda@Edge é otimizado para casos de uso sensíveis a latência de rede onde os usuários finais estão distribuídos globalmente e (idealmente) toda a informação necessária para tomada de decisão está disponível em um ponto de presença do CloudFront, ou seja, dentro da função e da requisição. Este fato permite aos desenvolvedores:
- Inspecionar cookies e reescrever URLs de forma transparente para fazer testes A/B.
- Retornar conteúdo gerado dinamicamente no ponto de presença, por exemplo, redirecionar usuários não autenticados para uma página de login que é criada sob demanda.
- Responder com objetos específicos de forma a customizar o website que o usuário visualiza baseado no cabeçalho HTTP User-Agent.
- Adicionar, remover ou modificar cabeçalhos (sujeito às seguintes restrições) para direcionar usuários para diferentes objetos em cache.
- Modificar e agrupar cabeçalhos ou URLs para otimizar a utilização do cache.
- Fazer requisições HTTP para outros recursos na internet e utilizar os resultados para customizar a resposta (porém desenvolvedores devem tomar as devidas precauções para minimizar a latência adicional ao realizar estas requisições).
Uma função Lambda@Edge pode ser disparada em resposta a quatro eventos diferentes do CloudFront:
- Requisição do visualizador - Este evento ocorre quando um usuário final ou um dispositivo conectado à internet realizar uma requisição HTTP para o CloudFront, e a requisição chega ao ponto de presença mais próximo ao usuário. O evento contêm a requisição HTTP.
- Resposta ao visualizador - Este evento ocorre quando o servidor CloudFront no ponto de presença está pronto para responder ao usuário final ou dispositivo que fez a requisição. Este evento contém a resposta HTTP.
- Requisição para a origem - Este evento ocorre quando o servidor no ponto de presença do CloudFront ainda não tem o objeto solicitado em seu cache, e a requisição do visualizador está pronta para ser enviada para o backend (e.g. Amazon EC2, ou o load balancer da aplicação, ou Amazon S3).
- Resposta da origem - Este evento ocorre quando o servidor do CloudFront no ponto de presença recebe a resposta do backend.
O diagrama abaixo da documentação do AWS Lambda@Edge ajuda a identificar de forma gráfica os eventos que são disparados durante o ciclo requisição/resposta:
Os desenvolvedores que utilizarem o Lambda@Edge devem estar familiarizados com o padrão de desenvolvimento AWS Lambda, e também devem desenvolver o código para funcionar dentro das seguintes restrições:
- Ambiente de execução - O ambiente de execução atualmente fornece suporte apenas para funções escritas em Node.js e disponibiliza 128 MB de memória para cada função, não oferecendo suporte para bibliotecas ou acesso ao diretório /tmp.
- Timeouts - Funções que utilizem os eventos de requisição para a origem e de resposta da origem devem terminar dentro de 3 segundos. Funções que utilizem eventos requisição do visualizador e resposta ao visualizador devem terminar dentro de 1 segundo.
- Acesso à web service - Funções que utilizem requisição para a origem e resposta da origem, caso terminem em 3 segundos, podem acessar as APIs da AWS e buscar conteúdo via HTTP. Estas requisições sempre são feitas de forma síncrona com a requisição ou resposta originais.
- Versionamento - Após uma atualização de código ser realizada por meio do console Lambda, uma nova versão precisa ser publicada e todos os triggers devem ser reconfigurados para esta nova versão. Após isso, os desenvolvedores devem aguardar que estas modificações sejam replicadas entre os servidores. As funções devem sempre ser referenciadas pelo seu número; $LATEST ou a utilização de um alias não são permitidos.
- Cabeçalhos - consulte a documentação de "Restrições de cabeçalho" para saber quais cabeçalhos são acessíveis, restritos, apenas leitura ou proibidos.
Não existe limite de utilização gratuita para o Lambda@Edge - a duração da função é calculada a partir do início da execução do código até o seu retorno ou finalização de alguma forma, sendo que o cliente será cobrado $0,00005001 para cada GB-segundo usado. Visto que as funções do Lambda@Edge têm o limite fixo de 128MB disponíveis por execução, a cobrança da duração é de $0,00000625125 para cada 128MB-segundo utilizado. Note que as funções do Lambda@Edge são mensuradas em uma granularidade de 50ms, e não pelo padrão de 100ms do AWS Lambda.
Informações adicionais a respeito do AWS Lambda@Edge podem ser encontradas na seguinte publicação de Jeff Barr "Lambda@Edge - Intelligent Processing of HTTP Requests at the Edge" no blog da AWS, na documentação de produto do AWS Lambda@Edge e no guia do desenvolvedor (todos em inglês).