Em Direção A Uma Ferramenta para A Realização de de Funções

Em direção a uma ferramenta para a realização de benchmarking
de funções serverless em ambientes possivelmente multi-cloud

Eduardo S. d. Moura1
Orientador por Vinicius C. Garcia
Centro de Informática – Universidade Federal de Pernambuco (UFPE)1

Av. Jornalista Aníbal Fernandes, s/n - Cidade Universitária - Recife - PE
esm7@cin.ufpe.br
Resumo. O objetivo deste trabalho é a compreensão e o aprimoramento do processo de
benchmarking de funções serverless do ponto de vista de engenheiros de software
em ambientes possivelmente multi-cloud. Para alcançar este objetivo, foi feita uma
análise do estado da arte, para mapear quais parâmetros são os mais relevantes
para se realizar esse benchmarking, e quais métricas devem ser levadas em
consideração ao se comparar seus resultados. A partir desse estudo, foi projetada e
desenvolvida uma ferramenta capaz de realizar o benchmarking de funções
serverless em ambientes possivelmente multi-cloud, e de consolidar seus resultados
em um relatório, de forma comparativa, possibilitando-a a visualizar os dados de
performance das funções testadas, e ajudando-a a ter intuições sobre o
comportamento das mesmas. Além disso, também foram realizados experimentos
com a tal ferramenta, com alguns dos casos de uso mais comuns de funções
serverless, que por sua vez, exercitam diversos recursos computacionais. Com base
nesses experimentos, houve a coleta de resultados para o levantamento de
discussões acerca da ferramenta, a fim de validar sua viabilidade e mapear
possíveis melhorias que poderão ser implementadas em trabalhos futuros.

Palavras-chave: Serverless functions, benchmarking.
1. Introdução
Esta Seção tem o objetivo de fornecer uma visão geral acerca do trabalho, apresentando o
contexto e as motivações que levaram ao desenvolvimento deste, além de mapear os
principais objetivos a serem alcançados com o seu desdobramento e conclusão, tanto os
gerais, quanto os específicos. E ao final, é possível ter um panorama do que será tratado em
cada uma das seguintes seções do trabalho.
1.1 Contexto e Motivação

Um dos fenômenos que mais impactou no aumento da velocidade da troca de informação
entre indivíduos na era moderna com certeza foi o uso e popularização da Internet. Tal se fez
gradualmente, com a invenção do telégrafo, do telefone, e por último do computador, que
vem provendo capacidades de integrações nunca vistas antes, o que tornou possível a
disseminação desse mecanismo de difusão de informação e meio de interação entre pessoas e
sistemas, independente de região geográfica [1].
A partir desse advento, algumas organizações enxergaram o potencial da rede, que em
um primeiro momento, consistia em sua grande maioria de sites que não tinham finalidades
intrinsecamente lucrativas, para começar a promover seus negócios físicos para os usuários
da internet. Nessa direção, junto com melhoras na infraestrutura da rede, e com seu acesso
cada vez mais facilitado, a internet começa a se tornar um ponto de interesse de empresas e
empreendedores, motivados progressivamente a fazer uso da mesma para se alavancarem.
Esse movimento foi tão grande a ponto de serviços começarem a surgir para operar apenas
por meio da rede.
Com o crescimento dos negócios online, as empresas começaram a investir em
infraestruturas próprias, para poder dar suporte a suas plataformas digitais. Nessa época, era
muito comum as organizações gerenciarem o seu próprio parque de máquinas e data centers,
o que gerava custos elevados, tanto referente à compra de novos equipamentos, à manutenção
dos mesmos. Esse tipo de abordagem é conhecida como aplicações servidas On-premise,
sendo operadas pelas próprias organizações. Apesar de tecnicamente prover um maior
controle de observabilidade, comparadas com aplicações que não seguem essa abordagem,
também implica em um maior risco de investimento em casos de falha de projeto [2].
Continuando na mesma direção, com o avanço da tecnologia, aumento no número de
pessoas conectadas na internet, muitos sistemas e até mesmo negócios foram migrando para
plataformas conectadas na rede, e dessa forma, em considerável parte dos casos, crescendo
sua base de usuários. Nesse cenário de alta competitividade, os sistemas também crescem à
medida que novas funcionalidades são demandadas, e assim, tornando cada vez mais
complexo o processo de desenvolvimento desses.
Na tentativa de amenizar os efeitos do crescimento dos sistemas, em questões de
agilidade na entrega de novas funcionalidades, e até mesmo em termos de escalabilidade das
aplicações, vários estudos foram desenvolvidos nessa mesma linha. Uma corrente afirma que
para alguns casos, faz sentido a fragmentação da aplicação em partes menores, capazes de
serem entregues, escaladas e testadas de forma independente, com cada uma delas possuindo
apenas uma responsabilidade [3].
Nessa ótica, um das arquiteturas de sistema distribuído que surgem, impulsionadas
pelo advento da Cloud Computing, foi a Arquitetura Serverless, que incorpora serviços de
“Backend as a Service” (BaaS) e agrega códigos que são rodados em contêineres efêmeros
numa plataforma de “Function as a Service” (FaaS), tendo como principais objetivos a
redução de custos e de complexidade [4].
Nesse contexto, vários provedores de nuvem como Amazon Web Services [5], Google
Cloud Platform [6] e Microsoft Azure [7], lançaram suas próprias soluções de funções
serverless, respectivamente as AWS Lambdas [8], as Google Cloud Functions [9] e as Azure
Functions [10].
Pelo fato desse paradigma ser consideravelmente novo, e pelas suas implementações
nessas plataformas serem recentes, ainda é uma atividade pouco consolidada a comparação
de performance entre essas funções, agravada pelo fato de cada provedor disponibilizar sua
própria implementação de serverless. Dessa forma, surge assim a necessidade do
entendimento da prática de benchmarking de funções serverless, para que assim seja possível
um aprimoramento nesse processo.
1.2 Objetivos
O objetivo principal deste trabalho é compreender e o aprimorar o processo de benchmarking
de funções serverless do ponto de vista de engenheiros de software em ambientes
possivelmente multi-cloud. Para se alcançar este objetivo, faz-se necessário:
● Identificar quais os parâmetros mais importantes em testes de performance sobre
essas funções;
● Identificar quais são as métricas mais relevantes no processo de comparação dos
resultados desses testes de performance;
● Averiguar se as ferramentas existentes possibilitam a comparação de funções
implantadas em provedores distintos.
1.3 Estruturação do Trabalho

Este trabalho está estruturado da seguinte forma:
● Seção 2: apresenta conceitos;
● Seção 3: explica a metodologia do trabalho, apresentando a sua meta e as questões
que serviram de guia para o desenvolvimento do mesmo;
● Seção 4: expõe a análise do estado da arte acerca do tema do trabalho, tentando
responder as questões levantadas;
● Seção 5: apresenta a ferramenta que foi desenvolvida com base na avaliação feita do
estado da arte;
● Seção 6: apresenta os experimentos realizados utilizando a ferramenta, sob funções
serverless com casos de uso comuns;
● Seção 7: apresenta os resultados dos experimentos e inicia uma discussão acerca dos
mesmos;
● Seção 8: levanta a conclusão do trabalho, avaliando o atingimento da meta e
viabilidade da ferramenta proposta;
● Seção 9: aponta pontos que podem ser atacados em trabalhos futuros, tanto sobre
limitações enxergadas no próprio trabalho, quanto acerca de funcionalidades novas
que podem ser desenvolvidas.
2. Conceitos fundamentais
Esta Seção apresenta e explica os principais tópicos que o trabalho aborda. Por meio deles,
será possível ter um contexto para uma efetiva compreensão da ferramenta proposta na Seção
5.
2.1 Cloud Computing

Segundo Wang [11], Computação em Nuvem é um conjunto de serviços habilitados para a
rede, que provêm infraestruturas computacionais sobre demanda, de forma escalável, com um
uma qualidade de serviço garantida, normalmente personalizadas e pouco custosas, podendo
ser acessadas de uma forma simples. Pode-se então concluir que uma das principais
vantagens desse modelo de computação é a abstração da infraestrutura, que em outro cenário,
deveria ser administrada e mantida pela própria organização, o que provavelmente acarretaria
em custos mais altos do que a contratação de um provedor cloud especializado.
O NIST (National Institute of Standards and Technology) afirma que o esse modelo é
constituído de cinco características fundamentais [12]:
● O consumidor pode provisionar recursos computacionais que necessitar, sem
interferência humana por parte do provedor do serviço;
● Os recursos provisionados devem ser acessíveis ao consumidor por meio de
mecanismos convencionais, como por exemplo, aparelhos celulares, laptops e tablets;
● Os recursos de computação do provedor são agrupados para atender a vários
consumidores, com diferentes recursos físicos e virtuais dinamicamente atribuídos e
reatribuídos de acordo com a demanda do consumidor;
● Os recursos devem ter a possibilidade de serem elasticamente escalados, ou seja,
escalados rapidamente, tanto aumentando quanto diminuindo suas capacidades de
forma dinâmica;
● Sistemas de nuvem devem automaticamente controlar e otimizar seus recursos
utilizando métricas, para diferentes tipos de serviço.
Além disso, o NIST constata que o Computação em Nuvem é apresentado em três
diferentes modelos de serviço [12], que serão explicados logo em seguida.
2.1.1 Software as a Service (SaaS)

O modelo de Software como um Serviço é aquele no qual os clientes são possibilitados de
usar e ou alugar aplicações licenciadas de provedores sem a necessidade de instalar em seus
próprios dispositivos, acessando-as por algum tipo de interface, como por exemplo um
navegador de internet, ou uma API Rest [13]. Dessa forma, esse modelo traz algumas
vantagens, como um maior controle de atualizações e versões por parte do provedor do
software e redução no custo de licenciamento por parte dos clientes, que terão que se
preocupar bem menos em ter uma própria infraestrutura para a disponibilização desse
software em específico.
2.1.2 Platform as a Service (PaaS)

O modelo de Plataforma como um Serviço é aquele que o cliente não busca apenas o uso de
um software, mas sim busca uma solução para prover o desenvolvimento de aplicações por
completo, ao mesmo tempo a hospedando e a entregando como um serviço de nuvem [14], se
situando uma camada abaixo do SaaS. Dessa forma, o consumidor não gerencia a
infraestrutura cloud que roda por baixo (a exemplo de rede, servidores, armazenamento e
sistemas operacionais), mas possui o controle sobre suas aplicações e possivelmente de
algumas configurações do ambiente de hospedagem [12].
2.1.3 Infrastructure as a Service (IaaS)

A Infraestrutura como um Serviço é o modelo que está situado na camada com o menor nível
de abstração que provedores de nuvem fornecem, a ponto de o mesmo ocasionalmente ser
referido como HaaS (Hardware as a Service) . Segundo ARORA et al, esse modelo é
observado quando uma organização terceiriza os equipamentos que utiliza para dar suporte às
suas operações, sendo que os mesmos são mantidos pelo provedor do serviço [15]. A grande
diferença é que o cliente tem controle também sobre recursos que são abstraídos em camadas
superiores, como os sistemas operacionais e armazenamento.
É importante notar que essa Seção, assim como as imediatamente anteriores, foi de
fundamental importância para se ter um contexto, e se entender em que camada que se situam
tais funções serverless, que serão bastante abordadas durante todo o trabalho, e explicadas de
forma mais específica na próxima Seção.
2.2 Serverless Computing

Computação Serverless é um novo paradigma que vem ganhando bastante tração cada vez
mais em sistemas que são hospedados em nuvem, em decorrência de uma grande mudança
em arquitetura de aplicações, em considerável parte empresariais, com a utilização de
microserviços e contêineres [16].
Este é baseado num novo modelo de computação em nuvem chamado FaaS (Function
as a Service), que faz um uso direto da camada de PaaS (vista na Seção 2.1.2), no qual utiliza
funções efêmeras (que não guardam estado) disparadas por eventos, sendo executadas em
contêineres gerenciados pelos provedores de cloud [17]. Esse modelo permite que os
desenvolvedores criem e hospedem aplicações dinamicamente escaladas sob demanda, que
performam uma determinada função [18]. Dessa maneira, não haverá um servidor que vai
ficar sempre no ar, mesmo que não hajam requisições para o mesmo atender. Nesse caso,
haverá contêineres que apenas estão ativos enquanto a função que eles contém estiver
rodando, assim, podendo trazer ganhos financeiros tanto por parte do cliente, quanto por parte
do provedor, pela economia no consumo de recursos.
No intuito de otimizar ainda mais o uso de recursos, em implementações de serverless
em algumas plataformas, existem algumas técnicas de caching e reuso de contêineres para os
casos em que a aplicação é acessada sucessivamente [19]. Esse efeito é perceptível quando
uma função passa algum tempo sem ser invocada. Na próxima vez que ela for chamada,
haverá uma latência um pouco maior na primeira requisição, por causa do tempo de carregar
o contêiner, sendo nomeado como o efeito de “cold-start” [20].
As principais implementações de funções serverless existentes, AWS Lambda [8],
IBM Cloud Functions [21], Google Cloud Functions [9], e Microsoft Azure Functions [10],
oferecem modelos de programação simplificados e muito fáceis de serem configurados para
executar as funções.
É importante também de se destacar que, como outros cenários na computação, o uso
de funções serverless pode não ser o mais efetivo em todas as situações. Casos em que
fazem-se necessários um maior controle sobre a observabilidade da aplicação, em que uma
baixa latência é uma necessidade crítica, e em casos que não se pode ter uma grande
dependência com o provedor cloud, não são recomendados para o uso de FaaS. Ao passo que
cenários onde uma aplicação fique latente uma significante parte do seu tempo e onde a
organização não se tenha expertise em manutenção de servidores, o uso de serverless pode
ser bastante recomendado [49].
2.3 Testes de software

Como o trabalho relacionado a testes de carga em funções serverless, é de fundamental
importância pelo menos o entendimento dos conceitos básicos de teste de software.
Teste de software é definido por qualquer atividade que visa avaliar as características
de um sistema ou mesmo de um simples programa, sendo um indicador da qualidade do
software [22]. Além disso, o ato de testar deve fazer parte do processo de engenharia de
software, utilizando e mantendo o código de teste, melhorando assim a qualidade do sistema
sob teste [23].
Testar o software se torna cada vez mais importante, ao mesmo tempo que sistemas se
tornam cada vez mais complexos, no objetivo de avaliar se alguns de seus critérios de
aceitação estão sendo atingidos e descobrir problemas, já que o código muitas vezes é escrito
por humanos, sendo assim suscetíveis a erro, especialmente num ambiente regido
majoritariamente por sistemas controlados por software [24].
De acordo com Jorgensen [25], testes são derivados de requisitos e especificações,
artefatos de design ou de código fonte. Dessa maneira, cada nível de teste deve estar lado a
lado com cada atividade de desenvolvimento. Esses níveis são:
● Testes de Aceitação: referentes aos requisitos do software;
● Testes de Sistema: referentes ao desenho arquitetural do software;
● Testes de Integração: referentes ao desenho dos subsistemas;
● Testes de Unidade: referentes à implementação do software.
2.3.1 Testes de Carga

Testes de carga, também conhecidos como testes de performance é uma categoria de testes
não funcionais, ou seja, que verificam o comportamento de determinado sistema, quando o
mesmo está sob um volume considerável de carga, a fim de se ter um maior entendimento
sobre aspectos de disponibilidade e estabilidade do sistema [26].
Um teste de performance normalmente simula uma carga grande de usuários
simultaneamente, realizando diversas ações e normalmente transferindo um grande volume
de dados. Por essa razão, esse tipo de teste é naturalmente um dos mais custosos, tanto em
questão de recursos computacionais, quanto no fator tempo, que pode levar até dias.
2.4 Benchmarking
Para poder se comparar a performance as funções serverless, a fim de avaliar seus
comportamentos mediante determinadas situações, torna-se necessário a realização do
processo de benchmarking sobre as mesmas.
O processo de benchmarking é definido pela quantificação dos níveis de performance
entre diferentes participantes a partir de métricas, para assim identificar suas diferenças de
performance, a fim de se mapear quais deles tiveram os melhores resultados. Dessa forma, é
possível quantificar potenciais melhorias para os participantes que não tiveram os melhores
resultados, visando alcançar o nível dos melhores [50].
No objetivo de se dinamizar o cenário no qual todos os participantes de um
benchmarking irão se submeter, são definidos parâmetros. Dessa maneira torna-se factível a
comparação dessas métricas de performance advindas de diferentes configurações, provendo
a possibilidade de uma definição de cenário específica pelo requisitante do benchmarking.
3. Metodologia do Trabalho
Para esse trabalho, foi adotada a abordagem do GQM (Goal Question Metrics) [47] como
metodologia. A Figura 1 ilustra a meta que se busca alcançar na conclusão do trabalho, as
questões que precisam ser levadas em conta e respondidas para que a meta seja cumprida, e
por fim, as métricas que devem ser consideradas para se responder essas perguntas:

Figura 1. Diagrama representando o modelo GQM utilizado
4. Análise do Estado da Arte

4.1 Método
Para a análise do estado da arte, foram utilizados os principais portais científicos, em especial
o IEEE [27], ACM [28] e Springer [29], e também portais agregadores, como o Google
Acadêmico [30] para a busca de trabalhos e artigos relacionados.
Como strings de busca, foram empregadas:
Tabela 1. Palavras-chaves utilizadas para compor a string de busca
Serverless Functions Benchmarking Tool Multi-cloud

FaaS Load Testing Techniques Heterogeneous Cloud
Function as a Service
4.2 Resultados
Com base na pesquisa, foi possível observar que a literatura acerca de benchmarking de
funções serverless em geral não é muito extensa, em decorrência do fato de FaaS ser um
modelo de computação cloud consideravelmente novo. Para se ter ideia, a primeira das
plataformas mais bem sucedidas desse tal modelo foi apenas lançada em 2014, pela AWS, as
chamadas Lambda Functions [31]. Contribuindo também para a análise desse fato, também é
possível constatar que o framework mais conhecido para a utilização dessas funções, o
Serverless Framework, teve sua versão 1.0.0 liberada em 2016 [32].
4.2.1 Parâmetros Mais Utilizados
Durante a fase de pesquisa do trabalho, para entender melhor o uso de testes de carga em
funções serverless, foi de fundamental importância determinar quais são os parâmetros mais
relevantes na configuração desses testes. Para apontar os mesmos, foi utilizado como critério
a quantidade de vezes que foram citados e/ou utilizados em outras ferramentas que se
propõem a realizar esse tal benchmarking.
Em primeira análise, fácil perceber que o parâmetro mais utilizado é o número de
requisições, o que faz bastante sentido ao se levar em consideração a natureza de um teste de
carga inserido num contexto de requisições HTTP. É possível constatar que todos os artigos
analisados utilizam o número de requisições como o parâmetro de configuração principal,
dando base ao processo de benchmarking [32, 33, 34, 35, 36, 37, 38].
Em segundo lugar no ranking, vem o número de requisições concorrentes, que simula
o comportamento de múltiplos clientes realizando requisições simultaneamente. Apesar de
ser menos presente nos trabalhos de referência [36, 38], tem um grande impacto nas métricas,
e torna os casos de teste muito mais fiéis em vários contextos do cotidiano onde as funções
são aplicadas.
4.2.2 Métricas Mais Utilizadas

Durante o processo de análise do estado da arte, foi possível constatar que em todos os
trabalhos considerados, tinham como a base para todas as métricas, dois fatores associados a
uma requisição [32, 33, 34, 35, 36, 37, 38], sendo eles:
● Latência na resposta da requisição
● Sucesso na requisição
A partir desses dois fatores, é possível derivar outros, que tem a função de facilitar o
entendimento do comportamento das funções testadas, de uma forma mais holística, sem a
necessidade de ficar calculando o agregado manualmente a partir de cada requisição. Essas
métricas normalmente se encontram no formato de:
● Número de requisições por segundo
● Latência média das requisições
● Taxa de sucesso
● P95 ( nesse escopo, representa que 95% das requisições tiveram uma latência de
resposta menor que o tempo apontado pela métrica) [48]
● P99 [ 48]
4.2.3 Visualização dos Resultados dos Testes

Em relação à visualização dos resultados dos testes, poucas ferramentas apresentam alguma
solução, principalmente quando se trata de alguma interface gráfica que apoie essa análise.
A solução que se mostra mais comum [34, 37], é a de agregar os resultados dos testes
numa base de dados em série temporal , como o InfluxDB [45], e por meio dele conectar
ferramentas de visualização gráfica, como o Grafana [46], permitindo a observação em séries
temporais.
4.2.4 Capacidade de Testes Multi-cloud
Nesse contexto de benchmarking de funções serverless, um dos principais pontos de
comparação é a performance das funções implantadas em diferentes provedores cloud,
principalmente entre os três mais conhecidos (AWS, GCP, Azure). Dessa forma, por padrão,
os trabalhos que surgem com esse tema [32, 33, 34, 35, 36, 37, 38], focam exatamente em
testes entre provedores diferente, com um conjunto de funções limitadas e predefinidas,
apenas focando em fazer seu benchmarking como sua contribuição, e não oferecendo
propostas de ferramentas com utilidade no dia a dia de um engenheiro de software, mas sim
algo pontual.
5. Proposta de Ferramenta
A load-donkey (disponibilizada conforme o explícito na Seção 5.2) é uma ferramenta que foi
desenvolvida com o propósito de gerar relatórios comparativos a partir dos resultados de
testes de carga configuráveis, realizados sobre funções serverless, que por sua vez podem
estar implantadas em provedores cloud distintos.
Essa ferramenta visa facilitar o processo de benchmarking nesse modelo FaaS,
ajudando principalmente engenheiros de software na visualização, e dessa forma apoiando o
surgimento de insights sobre o comportamento dessa funções sob teste.
5.1 Arquitetura
A load-donkey foi desenvolvida numa arquitetura com a necessidade de facilidade de
extensão em mente. Para tal, a mesma foi implementada em dois principais pacotes, sendo
eles o load-donkey-core e o load-donkey-cli como é possível visualizar na Figura 2.
Figura 2. Representação das camadas da ferramenta

Com o sistema estruturado dessa maneira, é possível a implementação de diferentes
tipos pacotes de apresentação, que irão fazer reuso do pacote no qual a lógica está presente,
tendo assim, pouco o acoplamento entre os módulos e tornando a aplicação
consideravelmente mais extensível.
5.1.1 load-donkey-cli
O pacote load-donkey-cli, como citado anteriormente, funciona apenas como camada de
apresentação, ou seja, torna possível a interação do usuário com o sistema.
Para se instalar a ferramenta, basta executar a seguinte linha de comando num
terminal:
bash install-cli
E para se utilizar a mesma, basta utilizar a seguinte linha de comando num terminal:
load-donkey /path/to/specfile
Ao final da execução, será gerado um diretório chamado load-donkey-reports na
pasta home do usuário. Dentro dele, constará um os arquivos de report, com a extensão html,
contendo um relatório comparando os resultados do benchmark que acabou de ser
performado.
5.1.1.1 Specfile
O Specfile é um arquivo no formato YAML, utilizado pelo load-donkey-cli para descrever a
suíte de testes de carga que devem ser executados. Para facilitar o entendimento, é possível
observar um exemplo de Specfile a seguir:
testEngine: ab
functions:
- address: http://host-aws.com
provider: aws
- address: http://host-gcp.com
provider: gcp
- address: http://host-azure.com
provider: azure
request:
method: POST
contentType: application/json
headers:
- key: Authorization
value: 123
queryParameters:
- key: pageSize
value: 25
bodyFile: /path/to/file/containing/body
parameters:
requestCount: 10000
concurrencyCount: 100
O mesmo utiliza os parâmetros apontados como os mais relevantes na Seção 4.2.1
(Número de requisições e Número de requisições concorrentes), assim como outros campos
que são usados para descrever a requisição que vai ser disparada, os endereços das funções, e
qual o motor de testes que deve ser utilizado.
5.1.1.2 Report
O Report é um arquivo html que consolida as métricas dos resultados dos testes de
performance executados sobre as funções definidas. Ele é gerado de forma dinâmica, a partir
dos resultados fornecidos. Atualmente ele dispõe as seguintes métricas:
● Total Time (in seconds): tempo total que se levou para realizar os testes sobre uma
função;
● Success Count: quantidade de requisições que retornaram resposta;
● Fail Count: quantidade de requisições que não retornaram resposta;
● Requests Per Second: quantidade média de requisições por segundo;
● Mean Time Per Request (in milliseconds): tempo médio por requisição em
milisegundos;
● P95 (in milliseconds): representa que 95% das requisições foram completas em
menos de X milisegundos;
● P99 (in milliseconds): representa que 99% das requisições foram completas em
menos de X milisegundos;
● Longest Request (in milliseconds): tempo de resposta mais longo dentre todas as
requisições em milisegundos.
Um exemplo de métrica apresentada no report é apresentada na Figura 3:

Figura 3. Métrica representando o tempo médio por requisição

É possível verificar que para cada métrica apresentada no Report, seus dados estarão
dispostos em forma de gráfico de barra, no qual seu eixo Y representa o valor numérico para
a determinada métrica, relacionando-se com cada provedor em que a função foi testada,
representando as variáveis categóricas logo abaixo de cada barra.
5.1.2 load-donkey-core
O módulo load-donkey-core é o responsável por receber as especificações dos testes de
performance, e assim executá-los com essas configurações. Por fim, retornar ao requisitante
os resultados consolidados de benchmarking.
A estrutura deste módulo está disponibilizada conforme apresentado na Figura 4:
Figura 4. Diagrama representando os módulos do load-donkey-core

É possível então enxergar que o módulo LoadTester é o responsável por receber as
especificações dos testes que devem ser realizados, delegar para o TestEngine (explicado
detalhadamente na Seção 5.1.2.1) realizar os testes, e por fim devolver o resultado para o
requisitante.
5.1.2.1 TestEngine
TestEngine é o módulo que envolve o motor de testes que de fato vai realizar o
benchmarking. Ele é composto pelas interfaces com as TestEngines em si, como por exemplo
o Apache AB [39], e por dois outros componentes, o Decider e o ResultParser.
O Decider é o componente responsável por interpretar as configurações do teste que
foram passadas e decidir qual motor de testes utilizar. No estado atual da ferramenta, é
possível a utilização de apenas um motor, o anteriormente citado, Apache AB, que foi
escolhida por ser uma solução gratuita e já consolidada nesse escopo.
Já o ResultParser, é responsável por interpretar o resultado retornado pelo motor de
testes e estruturá-lo em um formato genérico, possibilitando que o consumidor do mesmo,
consiga montar suas visualizações de forma totalmente dinâmica a partir de
TestEngineResultConfigs. No caso da TestEngine implementada para se fazer interface com
o Apache AB, foram utilizadas regular expressions para a interpretação de seus resultados.
É possível conferir um exemplo de métrica (tempo médio por requisição, a mesma
utilizada na Figura 4) mapeado no ApacheABResultConfigs logo a seguir:
{
title: 'Mean Time Per Request (in milliseconds)',
key: 'meanTimePerRequest',
regex: /Time per request:\s*(\d+\.\d+) \[ms] $mean$/
}
Tal módulo foi construído desta forma para se adequar ao princípio Open-Closed do
SOLID (conjunto de princípios ajudam a tornar mais fácil a manutenção e extensão do
código) [40], dessa forma, fazendo com que a ferramenta seja facilmente estendida, sem
afetar o funcionamento do que já foi previamente implementado. Nessa ótica, se torna uma
atividade relativamente trivial a implementação de outras interfaces com outros motores de
teste, como o Loadtest[41] e o Artillery [42].
5.2 Disponibilização da Ferramenta

A disponibilização da ferramenta foi feita em um único repositório do GitHub, sob a licença
MIT, de possível acesso pelo seguinte link: https://github.com/eduardosm7/load-donkey.
6. Experimentos com Diferentes Casos de Uso

Já possuindo um prévio contexto da load-donkey, e compreendendo o seu funcionamento
apresentado na Seção anterior, a atual se propõe a realizar alguns experimentos com a
ferramenta, utilizando-se de alguns exemplos de casos de uso de funções serverless,
priorizando os que exercitam diferentes recursos computacionais.
Devido ao fato de essa ferramenta já ser uma ferramenta que se propõe a realização de
benchmarking, e de não ser comum o benchmarking desse tipo de ferramenta, os trabalhos
utilizados como referência [32, 33, 34, 35, 36, 37, 38] não disponibilizam esses dados acerca
de suas ferramentas.
Dessa maneira a avaliação da viabilidade da load-donkey será feita levando em
consideração a sua capacidade de configuração diferentes cenários de teste, de apresentação
das métricas de performance das funções de modo a tornar possível a identificação das
funções que tiveram melhores resultados e assim completando o processo de benchmarking
(definido na Seção 2.4).
Dessa forma, busca-se abranger vários cenários que usam esses mesmos recursos,
para que assim, seja possível analisar não apenas como se a ferramenta se comporta, mas
também como as funções reagem ao serem testadas pela mesma.
6.1 Processamento de Imagem

Para o primeiro conjunto de experimentos, foi decidido realizá-lo utilizando funções
serverless que se propõem a realizar um processamento de imagens. No caso abordado, foram
implantadas três funções, uma em cada provedor cloud, sendo eles AWS, GCP e Azure, com
códigos similares, utilizando Node.js [43] na versão 12. É importante também salientar que
na hora do teste, todas possuíam 256mb de memória e se localizavam na região do Norte da
Virgínia, na região Leste dos Estados Unidos.
Além de exercitar uma série de importantes recursos computacionais, segundo a
CNCF (Cloud Native Computing Foundation) , o processamento de multimídia é um dos
casos de uso mais comuns para funções serverless [44], fazendo assim com que esse seja um
exemplo bastante acurado com a realidade.
É possível observar na Figura 5 um diagrama de como se dá o fluxo desse
experimento, no contexto de uma requisição:
Figura 5. Diagrama representando o fluxo do experimento de processamento de imagem

Essas funções recebem uma imagem no formato de base64 pelo corpo da requisição.
Logo após o recebimento da requisição, ela é interpretada para que logo em seguida, seja
aplicado um filtro de borrado sobre a imagem em questão. Após esse processamento ser
realizado, imagem é salva em disco e é retornada uma resposta com status 200 caso tudo
tenha ocorrido com sucesso. Logo em seguida, é exposta a implementação de uma dessas
funções, em específico a da AWS:
'use strict';
const jimp = require('jimp');
exports.handler = async (event) => {

const image = JSON.parse(event.body).image;
blur(image, console.log("Success"));
return {
statusCode: 200
};
};
function blur(base64Image, callback) {

const base64Data =
base64Image.replace(/^data:image\/png;base64,/, "");
const imageBuffer = Buffer.from(base64Data, 'base64');
jimp.read(imageBuffer, function(err, image) {
image.blur(10);
image.write('output.png', callback)
});
}
Com esse fluxo, torna-se possível o teste de três dos recursos computacionais mais
comumente utilizados. São eles a CPU (processador), memória e disco.
Para a realização dos testes, serão utilizadas as configurações descritas na Tabela 2,
que foram definidas a partir das combinações entre parâmetros base e o tamanho da imagem
a ser processada, no objetivo de se observar o efeito dessa variação de configuração nas
métricas:
Tabela 2. Configurações utilizadas para o experimento de processamento de imagem
Número de requisições Número de requisições Tamanho da imagem
concorrentes
10 1 90kb
100 10 90kb
1000 100 90kb
10 1 180kb
100 10 180kb
1000 100 180kb
6.2 Variação no Tamanho do Payload

Para esse experimento, foi mais uma vez tomado como base o estudo da CNCF, que aponta
que um dos outros casos de uso mais frequentes para a utilização de FaaS é o de HTTP REST
API, que por sua vez, podem ter tamanhos de payload variáveis.
Nessa ótica, este experimento vai na linha de analisar os efeitos da mudança do
tamanho do payload de resposta na performance das funções, baseado no feito por
MARTINS et al [36].
Da mesma forma que para o experimento anterior, também foram implementadas
funções nos 3 principais provedores cloud (AWS, GCP, Azure), tendo como ambiente
Node.js 12, todas com 256mb de memória alocada e localizadas na região do Norte da
Virgínia.
Diferente do experimento da Seção 6.1, o atual é bem mais simples. As funções
recebem na requisição o tamanho do payload em kilobytes que a resposta deve conter. Para
que evitar um processamento desnecessário que causaria ruído nas métricas, foram pré
definidas no código 4 strings contendo tamanhos de respectivamente 32kb, 64kb, 128kb e
256kb, e nessa ótica, focando no recurso de rede.
O trecho de código seguinte representa a implementação da função em questão, na
AWS, com os valores das strings dos payloads substituídos por placeholders, dado o tamanho
das mesmas :
'use strict';
exports.handler = async (event) => {

const responsePayloadSize =
event.queryStringParameters.responsePayloadSize;
const payload = getPayload(responsePayloadSize);
return {
statusCode: 200,
body: JSON.stringify({
message: `Payload[${responsePayloadSize}] ${payload}`,
}),
};
};
function getPayload(size) {
switch (size) {
case '32':
return '<32kb_string>';
case '64':
case '128':
case '256':
}
}

Para rodar os testes, serão utilizadas as configurações descritas conforme a Tabela 3,
que foram definidas a partir das combinações entre parâmetros base e o tamanho do payload
que constará na resposta de cada requisição, no objetivo de se observar o efeito dessa
variação de configuração nas métricas:
Tabela 3. Configurações utilizadas para o experimento de variação no tamanho do payload
Número de requisições Número de requisições Tamanho do payload de
concorrentes resposta
10 1 32
100 10 32
1000 100 32
10 1 64
100 10 64
1000 100 64
10 1 128
100 10 128
1000 100 128
10 1 256
100 10 256
1000 100 256

7. Resultados e Discussões

7.1 Resultados dos Experimentos

As Tabelas 4 e 5 apresentam respectivamente os resultados dos experimentos de
processamento de imagem e do impacto do tamanho do payload.
É importante salientar que todos os testes foram feitos com as funções serverless
“aquecidas”, ou seja, todas as funções foram previamente rodadas num intervalo de até 2
minutos, na tentativa de se reduzir um possível efeito de cold-start, citado na Seção 2.
Tabela 4. Resultados do experimento de processamento de imagem
Nº de Nº de Tamanh Provedor Tempo Nº de P95 (em P99 (em
requisições requisições o do total (em sucessos segundos) segundos)
concorrentes arquivo segundos)
10 1 90kb AWS 29,270 10 4,377 4,377
10 1 90kb GCP 35,181 10 13,990 13,990
10 1 90kb Azure 22,098 10 4,710 4,710
100 10 90kb AWS 34,505 100 5,073 6,428
100 10 90kb GCP 33,522 100 3,854 14,908
100 10 90kb Azure 33,778 100 7,181 9,043
1000 100 90kb AWS 112,808 1000 18,431 24,589
1000 100 90kb GCP 113,591 998 17,796 27,709
1000 100 90kb Azure 228,072 997 17,179 112,310
10 1 180kb AWS 26,922 10 4,672 4,672
10 1 180kb GCP 23,325 10 4,278 4,278
10 1 180kb Azure 24,896 10 5,427 5,427
100 10 180kb AWS 37,138 100 5,537 7,079
100 10 180kb GCP 30,261 100 5,374 8,968
100 10 180kb Azure 37,980 100 5,813 8,968

1000 100 180kb AWS 249,253 1000 39,022 49,923
1000 100 180kb GCP 253,691 998 36,199 60,495
1000 100 180kb Azure 316,497 1000 36,662 203,807
Tabela 5. Resultados do experimento de variação no tamanho do payload

Nº de Nº de Tamanh Provedor Tempo Nº de P95 (em P99 (em
requisições requisições o do total (em sucessos segundos) segundos)
concorrentes payload segundos
de )
resposta
10 1 32 AWS 6.903 10 1,047 1,047
10 1 32 GCP 5.033 10 0,622 0,622
10 1 32 Azure 8.591 10 0,921 0,921
100 10 32 AWS 5.891 100 0,695 0,736
100 10 32 GCP 5.453 100 0,545 1,037
100 10 32 Azure 9.709 100 1,251 4,545
1000 100 32 AWS 17.169 1000 3,164 5,474
1000 100 32 GCP 6.258 1000 0,911 1,199
1000 100 32 Azure 46.491 999 1,899 3,138
10 1 64 AWS 7.060 10 0,819 0,819
10 1 64 GCP 5.033 10 0,606 0,606
10 1 64 Azure 8.535 10 0,921 0,921
100 10 64 AWS 5.493 100 0,550 0,643
100 10 64 GCP 5.576 100 0,950 1,394
100 10 64 Azure 9.103 100 0,956 0,957
1000 100 64 AWS 16.509 1000 2,987 4,838
1000 100 64 GCP 6.421 1000 1,119 1,492
1000 100 64 Azure 19.098 1000 2,875 4,772
10 1 128 AWS 7.364 10 0,819 0,819

10 1 128 GCP 4.848 10 0,514 0,514
10 1 128 Azure 8.781 10 0,973 0,973
100 10 128 AWS 7.077 100 0,719 0,742
100 10 128 GCP 5.726 100 1,070 1,140
100 10 128 Azure 9.271 100 0,923 0,968
1000 100 128 AWS 17.305 1000 3,812 5,466
1000 100 128 GCP 12.461 1000 2,392 4,016
1000 100 128 Azure 17.238 1000 2,616 3,914
10 1 256 AWS 7.168 10 0,819 0,819
10 1 256 GCP 5.279 10 0,614 0,614
10 1 256 Azure 8.932 10 1,017 1,017
100 10 256 AWS 5.749 100 0,718 0,792
100 10 256 GCP 5.547 100 0,541 1,111
100 10 256 Azure 9.052 100 0,921 0,922
1000 100 256 AWS 20.855 1000 3,623 5,522
1000 100 256 GCP 7.072 1000 1,299 1,722
1000 100 256 Azure 19.122 1000 2,972 4,589
7.2 Discussões dos Experimentos

Analisando os resultados de performance do primeiro experimento, que tem foco no
processador, memória e disco, é perceptível que para os testes que com as configurações mais
leves (10 requisições com 1 concorrente e 100 requisições com 10 concorrentes) não é
possível concluir de maneira muito assertiva qual das funções possui a melhor performance,
já que os resultados não apresentam uma correlação entre o tamanho da imagem enviada e o
tempo médio por requisição. Essa relação apenas é constatada claramente quando se compara
as amostras com as configurações mais pesadas (1000 requisições com 100 concorrentes).
Nesses casos é perceptível que as funções implantadas na AWS e GCP possuem uma
performance equiparável. Já a função implantada na Azure apresentou tempos médios por
requisição consideravelmente maiores, assim como suas taxas de falha.
Um fator que pode justificar determinado comportamento, pode ser suposto a partir
métrica de P99, que indicou valores excessivamente maiores que os concorrentes,
possivelmente por configuração de timeout muito grande, fazendo com que algumas
requisições demorassem mais a responder ao invés de falhar, o que em determinados
cenários, pode fazer bastante sentido.
Para o segundo experimento, que por sua vez, não exigia tantos recursos das funções,
mas mais a rede envolvida, foi exposto que nesse específico cenário, as funções conseguiram
lidar muito melhor com número de requisições mais elevados (1000 requisições com 100
concorrentes), tendo latências médias por requisição consideravelmente inferiores.
Ao se analisar o efeito do tamanho do payload de resposta na performance das
funções, não foi possível notar alguma efeito de causalidade direto, pelo menos não para as
configurações utilizadas, mas aparenta que o aumento no tempo de resposta e as taxas de erro
subiam em decorrência do aumento de requisições. A função implantada na GCP foi a que
apresentou a maior estabilidade às variações das configurações, se comportando
consideravelmente melhor principalmente nos casos de maior estresse, em comparação às
outras. E como no experimento anterior, mais uma vez a da Azure foi a que pior performou.
Sumarizando, foi notável que a load-donkey possibilitou de forma simples a definição
de diferentes casos de testes de performance, sob todas as funções serverless definidas, de
maneira simples a partir dos SpecFiles (definidos na Seção 5.1.1.1).
Logo após a realização dos testes, a ferramenta foi capaz de apresentar de forma
comparativa as métricas de performance das funções testadas, facilitando o processo de
identificação de quais funções apresentaram melhores resultados referentes às determinadas
métricas, assim possibilitando a quantificação das diferenças entre suas performances.
Além disso, foi possível perceber que a load-donkey não demonstrou nenhum sinal de
instabilidade nem de lentidão durante todos os experimentos realizados. Por meio dela, foi
possível a obtenção de todos os resultados e também dos insights destacados anteriormente.
8. Conclusão
Pode-se então concluir que este trabalho atinge satisfatoriamente seu propósito, exposto na
Seção 3, de entender e aprimorar o processo de benchmarking em funções serverless
implantadas em ambientes possivelmente multi-cloud.
A partir de uma análise do estado da arte, vista na Seção 4, foi viável a elucidação das
questões fundamentais que nortearam o trabalho. Com essas respostas, foi desenvolvida uma
ferramenta capaz de realizar o benchmarking de funções serverless, que fizesse uso dos
parâmetros e métricas mais relevantes envolvidas nesse processo e que pode ser utilizada em
um contexto cotidiano, sobre funções definidas pelos próprios engenheiros de software, em
ambientes multi-cloud ou não.
Com os experimentos realizados, foi perceptível a viabilidade no uso da ferramenta,
que tornou possível fácil a configuração de inúmeros casos de teste, a apresentação de várias
métricas de performance já consolidadas de forma comparativa, e que demonstrou total
estabilidade em sua aplicação, apontando métricas capazes de fornecer insights valiosos sobre
o comportamento das funções testadas, que por sua vez, foram implementadas tendo como
base nos casos mais comuns de aplicações de serverless.
9. Trabalhos Futuros
Durante o desenvolvimento deste trabalho, algumas limitações foram percebidas na
ferramenta:
● Aprimoramento visual do report, utilizando-se de técnicas de design e visualização de
dados, a fim de torná-lo mais fácil de se interpretar as métricas consolidadas, assim
aumentando a propensão de se tirar insights sobre os dados;
● Criação de outros módulos na camada de interface de usuário, como por exemplo uma
API REST, que pode ser consumida por outros serviços;
● Implementação de interfaces com outros motores de teste de carga, tornando possível
suas utilizações e gerando métricas específicas desses motores;
● Implementação de mecanismo de coleta de logs dos próprios provedores cloud,
fornecendo métricas que não são capazes de ser obtidas por meio dos motores, como
por exemplo, o custo de cada execução das funções;
● Fazer com que a própria ferramenta aponte qual das funções sob teste teve o melhor
desempenho, a partir de uma função utilidade com fatores definidos pelo usuário.
10. Referências
[1]LEINER, Barry M. et al. A brief history of the Internet. ACM SIGCOMM Computer
Communication Review, v. 39, n. 5, p. 22-31, 2009.
[2]WINKLER, Till J.; BROWN, Carol V. Horizontal allocation of decision rights for
on-premise applications and software-as-a-service. Journal of Management Information
Systems, v. 30, n. 3, p. 13-48, 2013.
[3]THÖNES, Johannes. Microservices. IEEE software, v. 32, n. 1, p. 116-116, 2015.
[4]ROBERTS, Serverless Architectures. 2018. Acesso em: 09/04/20. Disponível em:
<https://martinfowler.com/articles/serverless.html>.
[5]Amazon Web Services, AWS. Acesso em: 09/04/20. Disponível em:
<https://aws.amazon.com/pt/>.
[6]Google Cloud, Google Cloud Platform. Acesso em: 09/04/20. Disponível em:
<https://cloud.google.com/>.
[7]Microsoft Azure, Microsoft Azure. Acesso em: 09/04/20. Disponível em:
<https://azure.microsoft.com/pt-br/>.
[8]Amazon Web Services, AWS Lambda. Acesso em: 09/04/20. Disponível em:
<https://aws.amazon.com/pt/lambda/>.
[9]Google Cloud, Cloud Functions. Acesso em: 09/04/20. Disponível em:
<https://cloud.google.com/functions?hl=pt-br>.
[10]Microsoft Azure, Azure Functions. Acesso em: 09/04/20. Disponível em:
<https://azure.microsoft.com/pt-br/services/functions/>.
[11]WANG, Lizhe et al. Cloud computing: a perspective study. New Generation Computing,
v. 28, n. 2, p. 137-146, 2010.
[12]MELL, Peter et al. The NIST definition of cloud computing. 2011.
[13]BOKHARI, Mohammad Ubaidullah; SHALLAL, Qahtan Makki; TAMANDANI, Yahya
Kord. Cloud computing service models: A comparative study. In: 2016 3rd International
Conference on Computing for Sustainable Global Development (INDIACom). IEEE,
2016. p. 890-895.
[14]Khalidi, Y. A. 2011. "Building a Cloud Computing Platform for New Possibilities,"
Computer (44), pp 29- 34.
[15]ARORA, Pankaj; WADHAWAN, Rubal Chaudhry; AHUJA, Er Satinder Pal. Cloud
computing security issues in infrastructure as a service. International journal of advanced
research in computer science and software engineering, v. 2, n. 1, 2012.
[16]NGINX Announces Results of 2016 Future of Application Development and Delivery
Survey. Acesso em: 12/11/20. Disponível em:
<https://www.nginx.com/press/nginx-announces-results-of-2016-future-of-application-dev
elopment-and-delivery-survey/>.
[17]Larry Seltzer. 2018. Serverless computing explained | HPE. Acesso em: 12/11/20.
Disponível em:
<https://www.hpe.com/us/en/insights/articles/serverless-computing-explained-1807.html>.
[18]HALL, Adam; RAMACHANDRAN, Umakishore. An execution model for serverless
functions at the edge. In: Proceedings of the International Conference on Internet of
Things Design and Implementation. 2019. p. 225-236.
[19]Tim Wagner. 2014. Understanding Container Reuse in AWS Lambda. Acesso em:
12/11/20. Disponível em:
<https://aws.amazon.com/blogs/compute/container-reuse-in-lambda/>.
[20]Colby Tresness. 2018. Understanding serverless cold start. Acesso em: 12/11/20.
Disponível em:
<https://azure.microsoft.com/pt-br/blog/understanding-serverless-cold-start/>.
[21]IBM Cloud, IBM Cloud Functions. Acesso em: 12/11/20. Disponível em:
<https://www.ibm.com/br-pt/cloud/functions>.
[22]Hetzel, Bill (1984). The Complete Guide to Software Testing. QED Information
Sciences. ISBN 0-89435-110-9.
[23]CRAIG, Rick David; JASKIEL, Stefan P. Systematic software testing. Artech house,
2002.
[24]JORGENSEN, Paul C. Software testing: a craftsman’s approach. CRC press, 2018.
[25]AMMANN, Paul; OFFUTT, Jeff. Introduction to software testing. Cambridge University
Press, 2016.
[26]Sten Pittet. The different types of software testing. Acesso em: 12/11/20. Disponível em:
<https://www.atlassian.com/continuous-delivery/software-testing/types-of-software-testin
g>.
[27]IEEE, IEEE Xplore. Acesso em: 12/11/20. Disponível em:
<https://ieeexplore.ieee.org/Xplore/home.jsp>.
[28]ACM Digital Library, ACM Journals. Acesso em: 12/11/20. Disponível em:
<https://dl.acm.org/journals>.
[29]Springer, Springer Link. Acesso em: 12/11/20. Disponível em:
<https://link.springer.com/>.
[30]Google, Google Acadêmico. Acesso em: 12/11/20. Disponível em:
<https://scholar.google.com.br/?hl=pt>.
[31]JANGDA, Abhinav et al. Formal foundations of serverless computing. Proceedings of
the ACM on Programming Languages, v. 3, n. OOPSLA, p. 1-26, 2019.
[32]Austen Collins. 2016. Releasing Serverless Framework V.1 & Fundraising. Acesso em:
<https://www.serverless.com/blog/releasing-serverless-framework-v1-and-fundraising>.
[33]KIM, Jeongchul; LEE, Kyungyong. Functionbench: A suite of workloads for serverless
cloud function service. In: 2019 IEEE 12th International Conference on Cloud Computing
(CLOUD). IEEE, 2019. p. 502-504.
[34]MALAWSKI, Maciej et al. Benchmarking heterogeneous cloud functions. In: European
Conference on Parallel Processing. Springer, Cham, 2017. p. 415-426.
[35]SOMU, Nikhila et al. PanOpticon: A Comprehensive Benchmarking Tool for Serverless
Applications. In: 2020 International Conference on COMmunication Systems &
NETworkS (COMSNETS). IEEE, 2020. p. 144-151.
[36]MARTINS, Horácio; ARAUJO, Filipe; DA CUNHA, Paulo Rupino. Benchmarking
Serverless Computing Platforms. Journal of Grid Computing, p. 1-19, 2020.
[37]MAISSEN, Pascal et al. FaaSdom: A Benchmark Suite for Serverless Computing. arXiv
preprint arXiv:2006.03271, 2020.
[38]ROBSON, Ricardo. 2018. Em direção a um Framework Serverless para Docker Swarm.
Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) - Centro de
Informática, Universidade Federal de Pernambuco. 2018
[39]Apache, ab - Apache HTTP server benchmarking tool. Acesso em: 12/11/20. Disponível
em: <https://httpd.apache.org/docs/2.4/programs/ab.html/>.
[40]Samuel Oloruntoba. 2020. S.O.L.I.D: The First 5 Principles of Object Oriented Design.
Acesso em: 12/11/20. Disponível em:
<https://www.digitalocean.com/community/conceptual_articles/s-o-l-i-d-the-first-five-prin
ciples-of-object-oriented-design>.
[41]Loadtest. Acesso em: 12/11/20. Disponível em:
<https://github.com/alexfernandez/loadtest>.
[42]Artillery. Acesso em: 12/11/20. Disponível em: <https://artillery.io/>.
[43]Node.js. Acesso em: 12/11/20. Disponível em: <https://nodejs.org/en/>.
[44]Cloud Native Computing Foundation, CNCF WG-Serverless Whitepaper v1.0. Acesso
em: 16/11/20. Disponível em:
<https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf
_serverless_whitepaper_v1.0.pdf>.
[45]InfluxData, InfluxDB. Acesso em: 15/11/20. Disponível em:
<https://www.influxdata.com/products/influxdb/>.
[46]GrafanaLabs, Grafana. Acesso em: 15/11/20. Disponível em: <https://grafana.com/>.
[47]BASILI, V. GQM approach has evolved to include models. IEEE SOFTWARE, v. 11, n.
1, p. 8-8, 1994.
[48]Zachary Tong. 2014. Averages Can Be Misleading: Try a Percentile. Acesso em:
<https://www.elastic.co/blog/averages-can-dangerous-use-percentile>.
[49]Andrea Passwater. 2017. When (and why) not to go serverless. Acesso em: 07/12/20.
Disponível em: <https://www.serverless.com/blog/when-why-not-use-serverless>.
[50]STAPENHURST, Tim. The benchmarking book. Routledge, 2009.

Em Direção A Uma Ferramenta para A Realização de de Funções

Enviado por

Dados do documento

Descrição:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Descrição:

Direitos autorais:

Formatos disponíveis

Em Direção A Uma Ferramenta para A Realização de de Funções

Título original:

Enviado por

Descrição:

Direitos autorais:

Formatos disponíveis

Em direção a uma ferramenta para a realização de ​benchmarking

de funções ​serverless ​em ambientes possivelmente ​multi-cloud

Orientador por Vinicius C. Garcia

Centro de Informática – Universidade Federal de Pernambuco (UFPE)​1

1.1 Contexto e Motivação

1.3 Estruturação do Trabalho

2.1 Cloud Computing

2.1.1 Software as a Service (SaaS)

2.1.2 Platform as a Service (PaaS)

2.1.3 Infrastructure as a Service (IaaS)

2.2 Serverless Computing

2.3 Testes de software

2.3.1 Testes de Carga

Figura 1. Diagrama representando o modelo GQM utilizado

4. Análise do Estado da Arte

Serverless Functions Benchmarking Tool Multi-cloud

4.2.2 Métricas Mais Utilizadas

4.2.3 Visualização dos Resultados dos Testes

Figura 2. Representação das camadas da ferramenta

Figura 3. Métrica representando o tempo médio por requisição

Figura 4. Diagrama representando os módulos do load-donkey-core

5.2 Disponibilização da Ferramenta

6. Experimentos com Diferentes Casos de Uso

6.1 Processamento de Imagem

Figura 5. Diagrama representando o fluxo do experimento de processamento de imagem

const jimp = require('jimp');

exports.handler = async (event) => {

function blur(base64Image, callback) {

100 10 90kb

1000 100 90kb

100 10 180kb

1000 100 180kb

6.2 Variação no Tamanho do Payload

exports.handler = async (event) => {

100 10 32

1000 100 32

100 10 64

1000 100 64

100 10 128

1000 100 128

1000 100 256

7.1 Resultados dos Experimentos

10 1 90kb AWS 29,270 10 4,377 4,377

10 1 90kb GCP 35,181 10 13,990 13,990

10 1 90kb Azure 22,098 10 4,710 4,710

100 10 90kb AWS 34,505 100 5,073 6,428

100 10 90kb GCP 33,522 100 3,854 14,908

100 10 90kb Azure 33,778 100 7,181 9,043

1000 100 90kb AWS 112,808 1000 18,431 24,589

1000 100 90kb GCP 113,591 998 17,796 27,709

1000 100 90kb Azure 228,072 997 17,179 112,310

10 1 180kb AWS 26,922 10 4,672 4,672

10 1 180kb GCP 23,325 10 4,278 4,278

10 1 180kb Azure 24,896 10 5,427 5,427

100 10 180kb AWS 37,138 100 5,537 7,079

100 10 180kb GCP 30,261 100 5,374 8,968

100 10 180kb Azure 37,980 100 5,813 8,968

1000 100 180kb GCP 253,691 998 36,199 60,495

1000 100 180kb Azure 316,497 1000 36,662 203,807

Em direção a uma ferramenta para a realização de benchmarking

de funções serverless em ambientes possivelmente multi-cloud

Centro de Informática – Universidade Federal de Pernambuco (UFPE)1