Os produtos de funcionalidade como serviço (FaaS), como o AWS Lambda, as Funções do Azure e o Google Cloud Functions, instigaram uma mudança de paradigma na maneira como as equipes de Operações fornecem e gerenciam a infraestrutura de sua organização. Com tarefas administrativas cotidianas, como provisionamento, correção, manutenção de conformidade e configuração de sistemas operacionais, tudo sendo abstraído, sua equipe de operações só tem uma tarefa para trabalhar – escrever código de classe mundial.

Mas é desafiador tem sua parcela de desafios, especialmente quando se trata de monitoramento. Modelos de contêineres efêmeros, juntamente com a incapacidade de acessar servidores subjacentes, renderizaram métodos tradicionais de execução de agentes / daemons para monitorar a infraestrutura inútil.

Neste blog, veremos quais parâmetros você precisa observar enquanto começa a criar suas funções Lambda sem servidor.

Número de invocações

A taxa de solicitações fornece uma idéia da frequência com que sua origem de eventos (gatilho) está publicando eventos para invocar sua função do Lambda. Essas fontes de eventos podem ser qualquer coisa, desde alertas, solicitações HTTP externas, serviços upstream como S3, DynamoDB e Kinesis, ou até mesmo seu próprio aplicativo personalizado. Configurar alarmes e monitorar o número total de solicitações em todas as suas funções é importante se você estiver operando dentro dos limites do nível gratuito do Lambda. Embora você possa usar o nível gratuito da Lambda indefinidamente, ele inclui apenas um milhão de solicitações gratuitas todos os meses.

Duração

Se você estiver executando o código do aplicativo como um serviço de back-end, o tempo de execução pode não ser sua primeira preocupação. Mas se esse código estiver sendo usado para atender a solicitações HTTP externas e um usuário final estiver aguardando na outra linha, será necessário manter o tempo de execução do seu código no mínimo.

Possíveis motivos para execução lenta de código

Começos frios
Partidas a frio entram em cena em vários cenários, como:
Quando sua função é executada pela primeira vez ou após um longo período de tempo.
Quando você atualiza o código do aplicativo para uma versão mais recente.
Quando você ficar sem contêineres quentes ou se a AWS decidir trocar contêineres.

Tentativas de erro

Quando a função do Lambda não puder processar um registro no fragmento, ele interromperá o processamento dos registros subsequentes e continuará tentando até obter êxito ou o registro expirar. Se o erro não for tratado corretamente, isso poderá aumentar ainda mais o atraso entre a origem e a função do evento.

Complexidade

Em seguida vem a complexidade da sua função. Uma função direta que executa processos de backend simples geralmente leva muito pouco tempo, enquanto que uma função complexa que requer dependências externas e bibliotecas para carregar na memória pode levar muito tempo para ser executada.

Lógica de aplicação

Finalmente, há a lógica de negócios da função. Geralmente, uma função Lambda é implantada como um serviço de colagem, conectando diferentes componentes na sua arquitetura de aplicativo. As funções do Lambda normalmente podem chamar qualquer número de serviços de recebimento de dados ou terminais de API externos para que problemas em qualquer um dos recursos de dependência – latência de rede, falta de resposta, acelerações / novas tentativas – possam ser adicionados ao tempo de execução de uma função.

Erros

Exceções não identificadas ocorrendo como parte do tempo de execução do Lambda podem fazer com que o código do aplicativo seja encerrado, levando à falha de execução da função. Para solucionar problemas e depurar sua função, você pode enviar os logs gerados por código para o grupo de log associado à sua função.

Você também pode incorporar seu código com instruções de criação de log para publicar impressões de exceção para métodos específicos. As chamadas de log que você insere dependem da linguagem de script da função. Você pode usar instruções stdout ou stderr comuns ou usar métodos específicos como:
Console.log() for Node.js
Console.write() for C#
logging.debug() for Python
log.debug() for Java

Porém, antes de usar qualquer um deles, certifique-se de que a função do IAM (função de execução) atribuída ao criar a função do Lambda tenha a permissão necessária para publicar os logs de execução de função nos registros do CloudWatch. Se não tiver as permissões corretas, você verá um erro de permissão negada em seus registros.

Estrangulamentos

Se os seus pedidos de invocação de função ficarem limitados, você deve começar a se preocupar. Atualmente, o Amazon Web Services tem um limite superior padrão de 1.000 execuções simultâneas em todas as funções implantadas em uma região específica. Esse limite pode parecer grande, mas muitas execuções de uma única função podem acabar rapidamente tentando limitar as tentativas de invocação de outras funções críticas implantadas na mesma região. Outro ponto importante a ser observado é que a contagem de execução simultânea dependerá de como sua função é chamada.

As fontes de eventos baseadas em fluxo seguem o número de shards igual ao número de modelos de simultaneidade de invocações. Para origens de eventos que não são baseadas em fluxo, você precisa multiplicar as invocações por segundo com o tempo de duração da função para obter a figura de simultaneidade atual. Evite as acelerações e permaneça dentro dos limites de simultaneidade, otimizando suas invocações de função.

Para uma origem de evento que não é baseada em fluxo, como S3, você pode armazenar em buffer a carga usando um serviço como o SQS.
Para uma fonte de eventos baseada em fluxo, como o Kinesis, você pode ficar dentro dos limites especificando o tamanho do lote e diminuindo o número de fragmentos.
Mantenha seus custos com o Lambda sob controle.
Para o AWS Lambda, você é cobrado com base no número de solicitações (incluindo chamadas de teste e erro) e no tempo de execução da função. Então, da perspectiva de sua equipe financeira, essas duas métricas são essenciais.

Encontre o equilíbrio certo

Os recursos utilizados para execução (memória) e o tempo gasto executando a função são inversamente proporcionais entre si. Você pode reduzir o tempo de execução do código do aplicativo aumentando a quantidade de memória alocada, mas acabará pagando mais. Da mesma forma, diminuir a configuração da memória de função pode ajudar a reduzir os custos, mas também aumenta o tempo de execução e, no pior dos casos, leva a tempos de espera ou erros de memória excedidos. Para os titulares de contas da AWS, é essencial encontrar um equilíbrio entre a memória alocada e os custos.

Cada vez que sua função é executada, ela grava uma entrada de log no grupo de log associado. Na imagem acima, você pode ver Duração, Duração faturada, Tamanho da memória e Memória máxima usada. Aqui, é bem direto ver que o usuário tem memória superprovisionada. (A função usa apenas 35 MB durante a execução, mas tem 192 MB configurados.) Observe as entradas de log da sua própria função e compare a Memória Máxima Usada com o Tamanho da Memória para determinar se seu aplicativo precisa de mais memória ou se você tem excesso de provisionamento.

As coisas ficam ainda mais interessantes quando você compara a Duração faturada com a duração. Imagine um cenário em que a duração média de invocação da sua função esteja em algum lugar no intervalo de 1.120 ms e a duração média faturada seja 1.200 ms (a duração faturada é arredondada para os 100 ms mais próximos). Aqui você pode tentar reduzir a configuração de memória da sua função para ver se consegue reduzir o espaço entre as duas.

Conclusão

Para ficar por dentro de tudo o que está acontecendo dentro do seu ambiente Lambda, você realmente precisa de monitoramento sistemático. A melhor maneira de conseguir isso é usando uma solução de monitoramento full-stack como o Site24x7.

Se você é novo no Site24x7 e ainda não experimentou os recursos de monitoramento da infraestrutura da AWS, tudo o que precisa fazer é passar por um processo de configuração inicial. Primeiro, você precisa ativar o acesso à sua conta da AWS criando uma função de IAM entre contas e conceder permissões somente leitura. Quando terminar, em poucos minutos você verá gráficos de séries temporais para cada contador de desempenho, com dados quase em tempo real disponíveis para análise.

ACSoftware / Figo Software seu Distribuidor e Revenda ManageEngine no Brasil

Fone (11) 4063 1007 – Vendas (11) 4063 9639