O blog da AWS

Integração do AWS Lambda com o Quarkus

Por Gerardo Arroyo, Co-Fundador da Flecha Roja Technologies S.A. na Costa Rica
Cristian Romero, Arquiteto de Soluções do Setor Público na AWS

 

O AWS Lambda permite que você execute código sem provisionar ou gerenciar servidores. É pago apenas pelo tempo de computação consumido.

Com o Lambda, você pode executar código para praticamente qualquer tipo de workload sem ter que executar tarefas de gerenciamento. Basta carregar o código e o Lambda cuidará de tudo o que você precisa para executar e dimensionar o código com alta disponibilidade. O código pode ser configurado para ser ativado automaticamente a partir de outros serviços da AWS ou pode ser chamado diretamente de qualquer aplicativo web ou mobile.

Quarkus aparece em um contexto em que a evolução das tecnologias de contêiner, especificamente Kubernetes, modifica os recursos exigidos pelos desenvolvedores Java com padrões de execução vistos em outras estruturas, como Go ou Node.js. Quarkus incorpora otimizações no uso de memória e tempo de inicialização. Isso permite que você, em alguns casos, execute o dobro de aplicativos usando a mesma quantidade de RAM em comparação com outras em comparação com outras stacks Java nativas da nuvem, ou até sete vezes mais instâncias quando o empacotamento tiver sido feito como um binário nativo.

Ao combinar essas duas tecnologias, você percebe os benefícios da execução usando o AWS Lambda: otimização de custos, estratégia de execução e recursos alocados a recursos com o Quarkus, além de tempos de resposta reduzidos e agilidade.

Este exemplo usará o Quarkus 1.7.3-Final, que usa o Java 11 por padrão. A extensão do Quarkus para o AWS Lambda está em fase de pré-visualização no momento da redação desta publicação (setembro de 2020). Isso deve ser levado em consideração ao usá-lo em ambientes de produção ou com alterações que surgem entre as versões.

 

Gerando o projeto com o Quarkus e sua extensão para o AWS Lambda

A criação do projeto pode ser feita de duas maneiras:

  • De um terminal. Com o Maven instalado anteriormente, o seguinte script deve ser executado:
mvn archetype:generate \
-DarchetypeGroupId=io.quarkus \
-DarchetypeArtifactId=quarkus-amazon-lambda-archetype \
-DarchetypeVersion=1.7.3.Final
  • Diretamente do site do Quarkus Code, selecionando a extensão “AWS Lambda” e adicionando o identificador apropriado ao artefato. Para este caso, lambda-quarkus, como o exemplo apresentado na Figura 1.

 

Figura 1. Crie um projeto com a extensão do AWS Lambda sobre o Quarkus

 

Dentro do projeto gerado, existem várias classes com código de exemplo. Um chamado TestLambda, inclui o método HandleRequest que será chamado sempre que essa função for chamada no AWS Lambda.

@Named("test")
public class TestLambda
       implements RequestHandler<InputObject, OutputObject> {

    @Inject
    ProcessingService service;

    @Override
    public OutputObject handleRequest(InputObject input,
                   Context context) {
        return service.process(input)
             .setRequestId(context.getAwsRequestId());
    }
}

Dentro desta classe, deve notar-se:

  • O nome escolhido para a classe com a anotação @Named deve ser modificado na propriedade quarkus.lambda.handler dentro do arquivo application.properties. Este último está localizado em /src/main/resources/.
  • A classe implementa RequestHandler e indica os objetos de entrada e saída no formato JSON.
  • Você pode usar dependência e injeção de contexto (CDI) de um serviço com a anotação @Inject, como mostrado no exemplo.
  • O método handleRequest recebe o contexto de execução do AWS Lambda como o segundo parâmetro, e esse método é modificado com a lógica procurada durante a implementação. Neste artigo, essa lógica será a concatenação de dois parâmetros de entrada.

Depois que as modificações tiverem sido feitas, o arquivo.jar será gerado que será usado para ser executado no AWS Lambda.

mvn clean package

Criação da função no console com o AWS Lambda

O arquivo.jar gerado na etapa anterior é carregado para o serviço AWS Lambda usando o Amazon Web Services Console. No console, você precisará clicar em Criar função selecionando o tempo de execução do Java 11 e atribuindo um nome apropriado para a função, conforme mostrado na Figura 2.

O escopo deste artigo não inclui outros serviços. No entanto, lembre-se de que, se você precisar interagir com  buckets do Amazon S3, armazenamento do Amazon,  DynamoDB ou outros serviços da AWS, você deve ter uma função apropriada do IAM. Neste exemplo, na seção Permissões, uma nova função será criada para o AWS Lambda.

 

Figura 2. Crie a função no AWS Lambda onde o código resultante da primeira etapa é carregado.

 

Se nenhuma alteração foi feita na estrutura do arquivo, o handler deve ser exatamente o seguinte: IO.Quarkus.amazon.Lambda.runtime.QuarkusStreamHandler። handleRequest, conforme detalhado na Figura 3.

 

Figura 3. Handler usado para fazer upload de the.jar para o AWS Lambda.

 

Uma vez que a função foi criada, um teste deve ser feito para validar se ela foi implantada corretamente. As Figuras 4 e 5 mostram os resultados da execução, onde um aquecimento total e tempo de execução de 1,32 milissegundos é observado. Esta execução corresponde à concatenação de duas strings que entram como parâmetros no evento de teste.

 

Figura 4. Configuração do evento de teste.

Figura 5. Resultados da execução do evento.

 

Através do uso de imagens nativas, Quarkus pode otimizar esses tipos de execuções. Este processo será detalhado na próxima seção.

 

Usando uma imagem nativa

Para gerar essa imagem, o projeto deve ser compilado como um executável nativo. Anteriormente, você deve instalar o GraalVM 20.2.0, o Docker e os pré-requisitos indicados neste link. Em seguida, o seguinte comando deve ser executado. Se o teste estiver sendo feito no macOS, adicione a propriedade -dnative-image.docker-build=true para dizer ao Quarkus para usar uma compilação do Docker, pois o AWS Lambda requer um binário linux:

mvn clean install -Pnative -Dnative-image.docker-build=true

O resultado é um arquivo chamado function.zip no diretório de destino. O AWS Lambda exige que o executável dentro desta pasta seja nomeado bootstrap, portanto, deve ser verificado que ele possui essa propriedade. Atualize o ambiente de tempo de execução do AWS Lambda com o arquivo new.zip e selecione o tipo de tempo de execução com a opção Custom runtime, conforme mostrado na Figura 6.

 

Figura 6. Ajustar o ambiente do AWS Lambda a novos requisitos.

 

Em seguida, uma variável de ambiente deve ser adicionada: DISABLE_SIGNAL_HANDLERS com o valor de true. Não fazer isso resultará em um erro de execução devido a incompatibilidades existentes do Quarkus com o ambiente do AWS Lambda.

 

Figura 7. Ajustar a variável de ambiente.

 

A repetição do teste resulta em um resultado bem-sucedido e também uma melhoria significativa no tempo de aquecimento e de execução a frio: no caso anterior, foi de 1,32 milissegundos contra 0,99 milissegundos desta segunda corrida. Em implantações com lógica robusta, com mais uso de memória, esse tipo de otimização será útil para reduzir os tempos de resposta.

 

Figura 8. Execução bem-sucedida do segundo teste.

 

Uma maneira alternativa de criar, atualizar e excluir a função é usar o comando manage.sh gerado pelo archetype do Maven.

 

Conclusão

O Quarkus e o AWS Lambda permitem otimizar os tempos de resposta para funções criadas em Java sob essa estrutura. A criação de imagens nativas terá melhores resultados, e esse procedimento pode ser executado a partir dos respectivos consoles ou do terminal para fornecer flexibilidade no script.
Testar essa forma de execução e evolução para desenvolvedores Java dar-lhes-á benefícios em agilidade, robustez e segurança.

 

Este artigo foi traduzido do Blog da AWS em Espanhol.

 

Sobre os autores

Gerardo Arroyo é um programador Java multi-certificado, AWS Certified Solution Architect e orador ocasional. Co-fundador da Flecha Roja Technologies S.A. na Costa Rica. Flecha Roja Technologies é uma empresa costarriquenha especialista em adotar e acelerar o uso de tecnologias de nuvem. Desde 2001, desenvolve soluções tecnológicas para empresas públicas e privadas com profissionais com importantes certificações.

 

 

 

Cristian David Romero é arquiteto de soluções da Amazon Web Services para o setor público. Cristian tem auxiliado várias instituições do setor público e privado na adoção da tecnologia em nuvem nos últimos 8 anos e tem realizado com sucesso projetos que marcam impacto social ao nível de cidadãos e estudantes em toda a América Latina.

 

 

 

Sobre os revisores

Giovanni Rodríguez é arquiteto de soluções da Amazon Web Services para o setor público. Giovanni ajudou várias entidades governamentais, organizações não governamentais e empresas privadas, na América Latina, a cumprir suas missões e objetivos de negócios. Ele é apaixonado pela nuvem, segurança da informação e análise.

 

 

 

Cristian Castellanos é arquiteto de soluções da Amazon Web Services para o setor público. Cristian ajudou várias instituições educacionais e governamentais a adotar novas tecnologias e a implementar soluções analíticas.

 

 

 

 

Amanda Quinto é arquiteta de soluções da Amazon Web Services para o setor público. Amanda ajudou várias organizações sem fins lucrativos a adotarem tecnologia para solucionar problemas através de Analytics e Devops.