Ferramenta para Avaliar Arquitecturas de Microsserviço

(1)

Ferramenta para Avaliar Arquitecturas de Microsservic¸o

Jo ˜ao Jos ´e da Costa

Dissertaç ão para obtenç ão do Grau de Mestre em

Engenharia Inform ´atica e de Computadores

Orientador: Prof. Jo ˜ao Coelho Garcia

J ´

uri

Presidente: Prof. Daniel Jorge Viegas Gonc¸alves

Orientador: Prof. Jo ˜ao Coelho Garcia

Vogal: Prof. Lu´ıs Manuel Antunes Veiga

(2)

(3)

Resumo

A arquitectura de microsserviço oferece in úmeras vantagens para os sistemas distribu´ıdos em larga escala, tais como escalabilidade diferenciada, resili ência e optimizaç ão de cada subsistema de forma aut ónoma [Newman, 2015]. Estas vantagens dependem da qualidade de construç ão dos microsserviços, que é um processo complexo e apresenta fundamentalmente desafios arquitecturais e operacionais. A construç ão dum sistema baseado em microsserviços é realizada a partir da conjugaç ão de diversos factores (protocolos de comunicaç ão, replicaç ão, coordenaç ão, frameworks e outros). A conjugaç ão desses factores resulta num conjunto elevado de alternativas de plataforma, cuja decis ão de quais escolher e como avaliar o impacto desta decis ão sob uma base comum n ão é tarefa trivial.

Esta dissertaç ão prop ôs uma ferramenta que permite avaliar o desempenho de variantes de plata-formas subjacentes de sistemas baseado em microsserviços sob uma base comum. As ferramentas actuais para Benchmarking de microsserviços focam-se em sistemas monol´ıticos, por exemplo o TPC-W (um Benchmark reconhecido para avaliaç ão de bases de dados de com ércio online) e muitas outras ferramentas, n ão s ão facilmente aplicadas aos sistemas de microsserviços devido as caracter´ısticas deste modelo arquitectural. A nossa ferramenta permite avaliar e comparar, em termos de d ébito e lat ência, estas diferentes implementaç ões (quer monol´ıticas quer baseadas em microsserviços) inde-pendentemente da implementaç ão espec´ıfica da interface da aplicaç ão. A nossa ferramenta apresentou bons resultados, em termos de correç ão e desempenho, em comparaç ão com o TPC-W e a si mesma quando comparada com instalaç ão georeplicada do serviço Shopping. Os testes realizados mostraram que a nossa ferramenta avalia com boa precis ão e com bom desempenho.

Palavras Chave

(4)

(5)

Abstract

The microservice architecture offers numerous advantages for large-scale distributed systems, such as differentiated scalability, resilience and autonomous optimization of each subsystem [Newman, 2015]. These advantages depend on the quality of building microservices, which is a complex process and fundamentally presents architectural and operational challenges. The system-building based on micro-services results in the combination of several factors (communication protocols, replication, coordination, frameworks, and others). The combination of these factors results in a variety of platform alternatives, whose decision on which to choose and how to evaluate the impact of this decision on a common basis is no trivial task.

This dissertation proposed a Benchmark tool that allows evaluating the performance of underlying platform variants of microservices-based systems. Today’s microservice benchmarking tools focus on monolithic systems, for example, TPC-W (a recognized benchmark for online commerce database eva-luation) and many other tools, are not easily applied to microservice systems due to their characteristics. Our tool allows you to evaluate and compare, in terms of throughput and latency, these different imple-mentations (both monolithic and microservices-based) regardless of the specific implementation of the application interface. Our tool delivered good results in terms of correction and performance compared to TPC-W and itself when compared to the geo-replicated deployment of the Shopping service. The tests performed showed that our tool evaluates with good accuracy and good performance.

Keywords

(6)

(7)

Conte ´

udo

1 Introduc¸ ˜ao 1

2 Fundamentos Te ´oricos e Trabalhos Relacionados 7

2.1 Fundamentos Te ´oricos. . . 9 2.1.1 Microsservic¸os . . . 9 2.1.2 Benchmarks . . . 12 2.2 Trabalhos relacionados . . . 14 2.2.1 Benchmark TPC-W . . . 15 2.2.2 Benchmark RUBiS. . . 16

2.2.3 Benchmark SPEC Web 2009 . . . 17

2.3 Resumo . . . 19

3 Arquitectura 21 3.1 Requisitos . . . 23

3.2 Arquitectura . . . 24

3.2.1 TPC-W microsservic¸o . . . 26

3.3 Fluxo de Trabalho T´ıpico. . . 34

3.3.1 Escalabilidade e populac¸ ˜ao das bases de dados . . . 35

3.3.2 Ativaç ão das mediç ões . . . 35

3.3.3 Execuç ão das mediç ões. . . 36

3.3.4 Encerramento das medic¸ ˜oes . . . 36

3.3.5 Apresentaç ão de relat ório . . . 37

4 Implementaç ão 39 4.1 Detalhes Gerais . . . 41 4.1.1 Comunicaç ão. . . 41 4.1.2 Configuraç ão . . . 42 4.2 Principais Componentes . . . 43 4.2.1 Fase de Pr é-teste . . . 43 4.2.2 Fase de Teste. . . 44

(8)

4.2.3 Fase de P ós-teste . . . 44 5 Avaliaç ão 47 5.1 Configuraç ões . . . 49 5.2 Correcç ão . . . 50 5.3 Desempenho . . . 51 5.4 Resumo . . . 53 6 Conclus ão 55 6.1 Trabalho Futuro . . . 57

(9)

Lista de Figuras

1.1 Arquitecturas de software monol´ıtica - suas caracter´ısticas. . . 3

1.2 Arquitecturas de software de microsservic¸o - suas caracter´ısticas. . . 4

2.1 Arquitecturas de software: Monol´ıtica e Microsservic¸o. . . 10

2.2 Abordagem de Benchmark para avaliac¸ ˜ao de desempenho . . . 13

2.3 Arquitectura do TPC-W. . . 15

2.4 Arquitectura do RUBiS. . . 17

2.5 Arquitectura do SPEC Web 2009.. . . 19

3.1 Arquitectura da nossa ferramenta de Benchmark . . . 24

3.2 Sistema em Avaliaç ão, da express ão em Ingl ês System Under Test (SUT) baseado em Microsserviço. . . 27

3.3 Modelo de Dados do Customer.. . . 28

3.4 Modelo de Dados do Product. . . 29

3.5 Modelo de Dados do Shopping.. . . 30

3.6 Escalabilidade e populac¸ ˜ao das bases de dados. . . 35

3.7 Ativaç ão das mediç ões. . . 36

3.8 Execuç ão das mediç ões. . . 37

3.9 Encerramento das medic¸ ˜oes. . . 37

4.1 Comunicac¸ ˜ao entre os componentes da ferramenta. . . 41

4.2 Execuç ão das mediç ões - Detalhes. . . 44

5.1 Verificaç ão da satisfaç ão dos limites de Interaç ões de Serviço por Segundo, da express ão em Ingl ês Service Interactions Per Second (SIPS) para o TPC-W. . . 51

5.2 Verificaç ão da satisfaç ão dos limites de SIPS para a nossa ferramenta. . . 51

5.3 Comparaç ão de d ébitos SIPS: TPC-W vs Nossa ferramenta. . . 52

(10)

5.5 M ´edia de Tempo de Resposta: TPC-W e Nossa ferramenta . . . 53

5.6 Comparaç ão de D ébitos SIPS: Sem m óduloOrders georeplicado versus m ódulo Orders

(11)

Lista de Tabelas

2.1 Comparaç ão das arquitecturas de software - Microsserviço versus Monol´ıtica. . . 10

2.2 Caracterizac¸ ˜ao dos trabalhos relacionados. . . 20

3.1 Principais funcionalidades do subsistemaCustomer. . . . 28

3.2 Principais funcionalidades do subsistemaProduct.. . . 29

3.3 Principais funcionalidades do subsistemaShopping . . . 29

5.1 Matriz de mistura de interac¸ ˜oes. . . 50

5.2 Matriz de restriç ão de Tempo de Resposta de Interaç ões Web, da express ão em Ingl ês Web Service Interaction Response Time (WIRT) . . . 50

(12)

(13)

Lista de Algoritmos

4.1 GetEndpointGeo: Estrat égia para obter pr óximo endpoint - teste de georeplicaç ão. . . 45

(14)

(15)

Acr ´

onimos

SUT Sistema em Avaliaç ão, da express ão em Ingl ês System Under Test

SQL-DDL Linguagem de definiç ão de dados SQL, da express ão em Ingl ês SQL - Data Definition

Language

SQL Linguagem de Consulta Estruturada, da express ˜ao em Ingl ˆes Structured Query Language

SIPS Interaç ões de Serviço por Segundo, da express ão em Ingl ês Service Interactions Per Second

WIRT Tempo de Resposta de Interaç ões Web, da express ão em Ingl ês Web Service Interaction Response Time

EB Neg ócio Emulado, da express ão em Ingl ês Emulated Business

BSL Tamanho da Sess ão de Neg ócio, da express ão em Ingl ês Business Session Length

RBE Emulador Remoto de Neg ócio, da express ão em Ingl ês Remote Business Emulator

B2B Modelo de Troca de Produtos, Serviços ou Informaç ões entre Empresas, da express ão em Ingl ês Business-To-Business

POV Verificaç ão da Ordem de Compra, da express ão em Ingl ês Purchase Order Verification

PGE Emulador de Portal de pagamento, da express ˜ao em Ingl ˆes Payment Gateway Emulator

ICE Emulador de Controle de Invent ário, da express ão em Ingl ês Inventory Control Emulator

DDD Desenho Orientado a Dom´ınio, da express ˜ao em Ingl ˆes Domain-Driven Design

API Interface de Programa de Aplicaç ão, da express ão em Ingl ês Application Program Interface

(16)

TPC Conselho de Desempenho de Processamento de Transaç ões, da express ão em Ingl ês Transaction Processing Performance Council

HTTP Protocolo de Transfer ência de Hipertexto, da express ão em Ingl ês Hypertext Transfer Protocol

(17)

1

Introduc¸ ˜ao

(18)

(19)

Tradicionalmente as aplicaç ões s ão desenhadas baseadas numa arquitectura monol´ıtica, Figura1.1. Neste modelo arquitectural, as aplicaç ões possuem os m ódulos fortemente acoplados, instalados como um único pacote e executados como um único processo (Figura 1.1.(a)) [Gamma et al., 1994,Taibi et al., 2017]. Todos os componentes s ão combinados num único programa, p.e., as operaç ões do lado do servidor, l ógica de neg ócio, camada de base de dados e integraç ões s ão todas interligadas e inter-dependentes [Alonso et al., 2004].

Esta arquitectura apresenta v árias limitaç ões para os sistemas distribu´ıdos em larga escala, tais como falta de resili ência, escalabilidade limitada, depend ências de instalaç ão dos m ódulos e tanto a qualidade do c ódigo como a agilidade reduzem com o crescimento da aplicaç ão [Newman, 2015,Taibi et al., 2017,Wolff, 2017].

Devido ao forte acoplamento, Figura1.1.(a), qualquer actualizaç ão requer a criaç ão de novo pacote da aplicaç ão. A complexidade do c ódigo aumenta gradualmente em funç ão das modificaç ões, i.e., é dif´ıcil manter uma boa estrutura modular. É imposs´ıvel combinar diferentes tecnologias, p.e., combinar duas tecnologias de base de dados para explorar o melhor de cada uma. A aplicaç ão n ão é resiliente, i.e., é incapaz de resistir a falha de um dos m ódulos. Precisa executar v árias inst ância da aplicaç ão para satisfazer os requisitos de escalabilidade e disponibilidade, Figura1.1.(b), i.e., n ão permitem es-calar e aumentar a disponibilidade apenas dos componentes que apresentam um desempenho limitado (escalabilidade diferenciada, Figura1.2.(b)).

(20)

Devido a estas limitaç ões, actualmente tem sido adoptada a arquitectura de microsserviço, Fi-gura1.2, para o desenvolvimento de aplicaç ões distribu´ıdas em larga escala [Taibi et al., 2017].

Os Microsserviços potenciam uma divis ão da aplicaç ão em unidades aut ónomas, Figura 1.2, de alta coes ão e fracamente acopladas de tal modo que, estas unidades, possam ser desenvolvidas, distribu´ıdas, executadas e mantidas de forma independente [Lewis and Fowler, 2014,Newman, 2015].

Estas unidades s ão componentes da aplicaç ão executadas cada um no seu pr óprio processo comu-nicando atrav és de Web Services ou outros mecanismos similares. Enquanto que em aplicaç ões Mo-nol´ıticas as bibliotecas s ão definidas como componentes vinculadas ao programa e invocadas usando chamadas de funç ão na mem ória [Alonso et al., 2004], na arquitectura de microsserviços os compo-nentes da aplicaç ão s ão os Microsserviços [Newman, 2015,Lewis and Fowler, 2014].

A divis ão da aplicaç ão em unidades, Microsserviços ou subsistemas, permite uma escalabilidade diferenciada, isolamento de dados, liberdade tecnol ógica, f ácil instalaç ão, entrega cont´ınua, alinha-mento organizacional, reutilizaç ão de c ódigo atrav és de chamadas de serviços e resili ência bem como a optimizaç ão de cada subsistema em funç ão da demanda ou da expans ão do dom´ınio de neg ócio de forma ágil [Newman, 2015,Hunter II, 2017,Wolff, 2017].

Figura 1.2: Arquitecturas de software de microsservic¸o - suas caracter´ısticas.

A atractividade dos microsserviços para as aplicaç ões distribu´ıdas em larga escala, motivou em-presas como a Amazon, Microsoft e Netflix a adoptarem este modelo arquitectural e muitas outras a emigrar os seus sistemas para a arquitectura de microsserviços [Taibi et al., 2017,Scholl et al., 2016].

(21)

Os benef´ıcios oferecidos pela arquitectura de microsserviços dependem da qualidade de construç ão dos Microsserviços. A construç ão de Microsserviços é um processo complexo e apresenta fundamen-talmente desafios arquitecturais e operacionais resultante da interaç ão entre os v ários componentes distribu´ıdos que comp õem o sistema [Newman, 2015,Hunter II, 2017,Daya et al., 2015]

Por exemplo, se for solicitado a quatro especialistas o desenho duma arquitectura de microsserviço dado um conjunto de requisitos para uma loja online, podem cada um apresentar uma arquitectura diferente. Este mesmo desenho dado a quatro equipas de desenvolvimento, podem apresentar qua-tro implementaç ões diferentes em termos de tecnologias, frameworks e protocolos. Ao passar para produç ão, dando a quatro administradores de sistema dependendo do cen ário de cada um (centro de dados local ou na nuvem, demanda de pedidos, recursos financeiros e outros), podem propor quatro plataformas diferentes (infraestruturas, ferramentas de monitoramento e outros).

Esta situaç ão ocorre, porque a construç ão duma aplicaç ão baseado em Microsserviços é realizada a partir da conjugaç ão de diversos factores (protocolos de comunicaç ão, replicaç ão, coordenaç ão, tipos de armazenamentos, Frameworks e outros) [Murugesan, 2017,Hunter II, 2017,Daya et al., 2015].

A conjugaç ão desses factores resulta num conjunto elevado de alternativas de plataforma, cuja decis ão de quais escolher e como avaliar o impacto desta decis ão sob uma base comum n ão é tarefa trivial.

Nestas condiç ões, é indispens ável uma ferramenta que permita comparar as v árias combinaç ões e alternativas de soluç ões, em termos de plataforma, sob uma base comum capaz de avaliar o desem-penho destes sistemas de modo a minimizar a complexidade na avaliaç ão das diferentes alternativa de desenho sob uma base comum.

Uma das maneiras mais f áceis e diretas de avaliar diferentes sistemas em termos de desempenho é atrav és de Benchmarking (processo pelo qual é comparado, em termos quantitativos, uma soluç ão em relaç ão a outra considerada como padr ão) [Jain, 1991b,Obaidat and Boudriga, 2010,Fortier and Michel, 2013a].

As ferramentas actuais para Benchmarking de Microsserviços focam-se em sistemas Monol´ıticos, por exemplo o TPC-W [Francisco, 2003] (um Benchmark reconhecido para avaliaç ão de bases de dados de com ércio online) e muitas outras ferramentas [OW2, 2011,SPEC, 2003], n ão s ão facilmente aplicadas aos sistemas de Microsserviços devido as caracter´ısticas deste modelo arquitectural.

Nosso objectivo é fornecer uma nova ferramenta de Benchmark que avalia o desempenho de vari-antes de plataformas subjacentes de sistemas baseado em microsserviços sob uma base comum. É avaliado, em termos de d ébito e lat ência, o desempenho dos servidores de aplicaç ão e de servidores de base de dados associados a cada servidor de aplicaç ão. Em resumo, nossas contribuiç ões neste trabalho podem ser resumidas da seguinte forma:

(22)

(quer Monol´ıticas quer baseadas em Microsserviços), em termos de d ébito e lat ência, e permitir avaliar alternativas de desenhos independentemente da implementaç ão espec´ıfica da interface da aplicaç ão. A ferramenta avalia e compara diferentes alternativa de desenho e instalaç ões (implantaç ões ou deployment em ingl ês) sob uma base comum.

• Propomos uma divis ˜ao do TPC-W em microsservic¸os

• Desenvolvemos o TPC-W microsserviço, que é a vers ão microsserviço do TPC-W baseada na nossa proposta de divis ão.

• Realizamos uma s érie de experimentos para testar a correcç ão e o desempenho da nossa ferra-menta de Benchmark.

Esta dissertaç ão est á composta por 6 cap´ıtulos. No cap´ıtulo 1, é introduzido o trabalho. No cap´ıtulo2, é apresentado os conceitos essenciais para melhor compreens ão do trabalho e uma an álise comparativa dos trabalhos relacionados. No cap´ıtulo3, é feito uma descriç ão da arquitectura da nossa ferramenta de Benchmark e, de seus detalhes de implementaç ão no cap´ıtulo4. No cap´ıtulo5, apre-sentamos e discutimos os resultados da avaliaç ão da nossa ferramenta de Benchmark. E no cap´ıtulo6, encerramos com algumas consideraç ões finais e sugest ões para trabalhos futuros.

(23)

2

Fundamentos Te ´

oricos e Trabalhos

Relacionados

Conte ´

udo

2.1 Fundamentos Te ´oricos . . . . 9

2.2 Trabalhos relacionados. . . 14

(24)

(25)

Neste cap´ıtulo, é apresentado os conceitos fundamentais para melhor compreens ão do conte údo deste documento. Na seç ão 2.1, é introduzido e discutido os Microsserviços e os Benchmarks. Na secç ão2.2, é feita uma an álise comparativa dos trabalhos relacionados. E finalmente, na secç ão 2.3

é apresentado, de forma sucinta, os aspectos mais relevantes relacionados a an álise comparativa feita na secç ão2.2.

2.1 Fundamentos Te ´

oricos

Na subsecç ão2.1.1, é apresentado os conceitos essenciais relacionados aos Microsserviços, desde as suas caracter´ısticas at é aos seus desafios. Finalmente na subsecç ão2.1.2, é apresentado os prin-cipais conceitos relacionados aos Benchmarks.

2.1.1 Microsservic¸os

Microsserviços s ão serviços de fina granularidade, de alta coes ão1 _{e fracamente acoplados, em} que cada serviço é focado numa capacidade de neg ócio e executado em seu pr óprio processo [ New-man, 2015,Scholl et al., 2016], mas trabalham juntos para atender aos requisitos duma determinada aplicaç ão.

A arquitectura de microsserviço, de forma sucinta, é um modelo arquitectural que permite o desenho de aplicaç ões como um conjunto de subsistemas aut ónomos, que se comunicam atrav és de Web Ser-vices ou mecanismos similares. Estes subsistemas podem ser actualizados de forma independente, sem a necessidade de actualizar, igualmente, seus consumidores. Cada subsistema exp õe sua API para colaboraç ão e consome os serviços necess ários, expostos por outros subsistemas, para atender um determinado pedido.

Esta abordagem contrasta com o m étodo tradicional de construç ão de serviços Monol´ıticos. Em que as aplicaç ões possuem os m ódulos fortemente acoplados, instalados como um único pacote e executados como um único processo [Alonso et al., 2004,Gonzalez, 2016]. A Figura 2.1, ilustra as particularidade destes modelos arquitecturais.

Os Microsserviços oferecem muitas vantagens para os sistemas distribu´ıdos em larga escala [ New-man, 2015,Scholl et al., 2016,Hunter II, 2017], desde a liberdade para combinar diversas tecnologias, resistir a falha de subsistemas, optimizar os subsistemas que apresentam desempenho limitado, ins-talar e manter subsistemas de forma independente, at é ao alinhamento organizacional. A Tabela2.1, resume as principais vantagens da arquitectura de microsserviço em relaç ão a arquitectura monol´ıtica. A heterogeneidade tecnol ógica é uma vantagem da arquitectura de microsserviço em relaç ão a ar-quitectura monol´ıtica. A arar-quitectura de microsserviço, permite usar diferentes tecnologias nos

(26)

Figura 2.1: Arquitecturas de software: Monol´ıtica e Microsservic¸o.

Tabela 2.1: Comparaç ão das arquitecturas de software - Microsserviço versus Monol´ıtica.

Microsservic¸o Monol´ıtica

Tecnologia Heterog ˆenea Homog ˆenea

Resili ˆencia Presente Ausente

Escalabilidade Subsistema Sistema

Manutenç ão F ácil Dif´ıcil

Gest ˜ao de dados Descentralizado Centralizado

Alinhamento Organizacional Neg ´ocio Tecnologia

tes subsistemas [Newman, 2015,Scholl et al., 2016]. Isto significa que podemos escolher a ferramenta certa para cada subsistema e aproveitar o melhor que cada uma pode oferecer. Por exemplo, para uma rede social, podemos armazenar as interaç ões dos utilizadores numa base de dados orientada a grafo para refletir facilmente a interconex ão entre os utilizadores, enquanto as publicaç ões dos utiliza-dores podem ser armazenadas numa base de dados orientada a documentos, dando origem a uma arquitetura heterog énea. Pode-se ainda decidir usar uma pilha de tecnologia diferente que ofereça os melhores n´ıveis de desempenho necess ários.

A pr óxima vantagem é a resili ência. É uma qualidade desej ável nos sistemas distribu´ıdos em larga escala, que é apenas oferecida pela arquitectura de microsserviço. Numa aplicaç ão Monol´ıtica, se um serviço falhar, tudo p ára de funcionar. Embora, num sistema Monol´ıtico, podemos executar v árias m áquinas para reduzir as chances de falha, o sistema Monol´ıtico n ão resiste, p.e., a falha total dum serviço. Enquanto que com a arquitectura de microsserviço, podemos construir sistemas que lidam com a falha total dos serviços e degradam a funcionalidade respectiva [Wolff, 2017].

A escalabilidade independente ou diferenciada é outra vantagem. Na arquitectura de microsserviço, cada subsistema pode ser escalado independentemente de outros serviços [Newman, 2015,Wolff, 2017,Gonzalez, 2016]. Isto elimina a necessidade de escalar todo o sistema quando apenas parte do sistema apresenta um desempenho limitado. Executar v árias inst âncias do sistema inteiro, como é requerido na arquitectura monol´ıtica, para garantir a escalabilidade e melhor desempenho tem im-pactos infra-estruturais e operacionais. Por exemplo, ao executar v árias inst âncias do sistema, quando

(27)

apenas alguns subsistemas est ão subcarregados, aloca recursos desnecess ário na nuvem e adiciona desafios administrativo ao n´ıvel operacional. Al ém de que, a alocaç ão de recursos desnecess ário tem custos financeiros adicionais, uma vez que, tipicamente os provedor de serviços de nuvem, cobram pela computaç ão, armazenamento ou outras m étrica de utilizaç ão de recurso.

Analogamente, a f ácil manutenç ão do sistema é outra vantagem dos Microsserços. Numa arquitec-tura monol´ıtica, a substituiç ão dum determinado m ódulo ou actualizaç ão dum novo recurso, requer que todo sistema seja reconstru´ıdo e reinstalado. Isto tem impacto na qualidade de fornecimento de serviço, dentre v ários problemas, a indisponibilidade de serviço é um desafio. Enquanto que, numa arquitectura de microsserviços, é poss´ıvel substituir e actualizar subsistemas de forma independente. Isto permite f ácil optimizaç ão do sistema e agiliza as entregas de actualizaç ões ou novas funcionalidades.

A autonomia dos Microsserviço d á lugar a uma gest ão de dados e de sistemas mais personalizado e f ácil em relaç ão a arquitectura monol´ıtica. Enquanto que numa arquitectura monol´ıtica temos os dados centralizados, que é problema (alteraç ão pode afectar o sistema num todo), na arquitectura de microsserviços temos os dados distribu´ıda, que permite melhor gest ão (esquema de base de dados menor e nos dados a administrar em cada subsistema).

Finalmente, esta mesma autonomia, tamb ém permite permite alinhar melhor a arquitetura à organizaç ão, a minimizar o n úmero de pessoas que trabalham em qualquer base de c ódigo para atingir o ponto ideal de tamanho e produtividade da equipa. As equipas s ão especializadas em determinados dom´ınios e usa a componentizaç ão para terceiros consumirem os seus serviço.

O modelo arquitectural baseado em Microsserviço, emergiu de v árias tend ências tecnol ógicas, padr ões e culturas adoptadas actualmente, tais como virtualizaç ão sob demanda, automaç ão de infra-estrutura, sistemas em escala, pequenas equipas aut ónomas, desenho orientado a dom´ınio e entrega cont´ınua [Newman, 2015,Wolff, 2017].

Muitas organizaç ões, como Amazon e NetFlix, descobriram que ao adoptar a arquitetura de microsserviço, podem fornecer serviços com melhor desempenho, adoptar novas tecnologias sem a necessidade de mudar o sistema num todo, usufruir da liberdade para novo alinhamento organizacional de modo a res-ponder mais r ápido e adequadamente às mudanças inevit áveis [Taibi et al., 2017,Scholl et al., 2016].

Por exemplo a Amazon Web Service, al ém de adoptar os Microsserviços como parte de sua ar-quitectura, promove disponibilizando serviços para simplificar a instalaç ão de Microsserviços em sua plataforma e infraestrutura, como é o caso da Amazon Elastic Container Service (Amazon ECS) [ ECS-AWS, 2015], que é é um serviço altamente escal ável e de alta desempenho para a orquestraç ão.

Outro exemplo, é a Netflix [Netflix, 2015], que al ém de implementar com sucesso a arquitetura de microsserviços em seus serviços de larga escala, com base nas suas experi ências e considerando a complexidade operacional, contribuiram com as suas ferramentas de microsserviços que visam minimi-zar os esforços de implementaç ão de Microsserviços.

(28)

Para que a arquitectura de microsserviço seja vantajosa para as aplicaç ões distribu´ıdas em larga escala, é necess ário lidar com os v ários desafios de construç ão, nomeadamente t écnicos, arquitecturais e operacionais. De forma sucinta os principais desafios s ão [Wolff, 2017,Scholl et al., 2016]:

• Granularidade - determinar a granularidade ideal dum subsistema requer a considerac¸ ˜ao de

v ários factores, tais como tamanho da equipa, impacto da redund ância ou depend ência de c ódigo, comunicaç ão entre os subsistemas, transacç ões, consist ência e muitos outros.

• Complexidade - a comunicaç ão entre os subsistemas atrav és da rede e a gest ão destas comunicaç ões

podem ser muito complexa. Estas comunicaç ões podem afetar negativamente o tempo de res-posta e a lat ência dos subsistemas. Os subsistemas podem falhar, é necess ário garantir que a falha num subsistema n ão resulte na falha de todo o sistema, os subsistemas restantes devem compensar a falha e permitir o funcionamento do sistema, o que pode degradar a qualidade dos serviços. Al ém disto, como Microsserviços s ão sistemas distribu´ıdos, é introduzido os desafios de sistemas distribu´ıdos.

• Lat ˆencia e congestionamento da rede - numa arquitectura de microsservic¸o, um pedido para um

serviço pode envolver m últiplos pedidos a outros serviços para completar a transaç ão web. Al ém das interaç ões entre os microsserviços, cada subsistema pode fazer acesso a sua base de dados ou cache, por exemplo. Todas estas interaç ões podem ter impacto negativo no desempenho da aplicaç ão e como resultado optimizaç ões na rede tornam-se importantes e indispens ável.

• Consist ência de dados - como os dados s ão descentralizados, isto é, como cada subsistema

possui o seu pr óprio esquema ou base de dados, é introduzido os desafios de consist ência e integridade de dados que pode ser dif´ıcil de resolver.

• Roteamento e descoberta de serviço - em ambiente de Microsserviço é necess ário que exista

a capacidade de determinar os endpoints de suas depend ˆencias e rote ´a-los. Isto pode adicionar complexidade.

Para estes e outros desafios existem soluç ões de frameworks, plataformas e ambiente de execuç ão. H á v árias alternativa de desenho e implementaç ão para uma arquitectura de microsserviço e a escolha acerta de uma plataforma que oferece um desempenho ideal requer avaliaç ão das v árias alternativas.

Uma forma simples e objectiva de avaliar diferentes alternativas sob uma base comum é utilizando ferramentas de Benchmark. A subseç ão2.1.2, aborda sobre estas ferramentas.

2.1.2 Benchmarks

Benchmarks s ão ferramenta que permite comparar uma medida (mark, em portugu ês significa marca) a um padr ão preestabelecido, a partir de um ponto de observaç ão (bench, em portugu ês base

(29)

ou refer ência), isto é, um ponto fixo ou refer ência para comparaç ões [Jain, 1991a,Gregg, 2014]. Por exemplo, supondo que desejamos medir a temperatura duma pessoa para aferir o seu estado de sa úde. Para tal precisamos de uma ferramenta, por exemplo um term ómetro, que produz medidas, por exemplo o grau celsius, quando avalia um objecto, por exemplo o corpo da pessoa. Com isto, temos apenas medidas. Para sabermos o estado de sa úde da pessoa precisamos de uma base ou refer ência (bench) para compararmos as medidas ou marcas (mark ) da pessoa e ent ão tirar conclus ões, por exemplo podemos definir a base ou refer ência 37ºC, em que abaixo é considerado um estado normal e acima é considerado um estado de febre. Assim para a pessoa que mediu e obteve a marca 35,5ºC, podemos afirma que o seu estado de sa úde é normal, porque est á abaixo de 37ºC. Analogamente, se desejarmos aferir o desempenho dum sistema computacional, precisamos medir o desempenho, obter marcas, e comparar estas marcas com uma determinada base ou refer ência para podermos aferir o seu estado em termos de desempenho. E para tal, é usado uma ferramenta de Benchmark.

Neste contexto, um benchmark é um programa de alto-n´ıvel, representativo de uma classe de aplicaç ões, utilizado para medir o desempenho dum dado sistema ou para comparar diferentes sis-temas. Para tal, requer o uso de carga de trabalho de teste para exercitar o sistema com foco no componente a ser avaliada [Obaidat, 2010].

Benchmark é sin ónimo para testes de carga de trabalho [Fortier and Michel, 2013b], Figura2.2, em que programas que geram carga de trabalho exercitam um determinado sistema usando um conjunto adequado de instruç ões [Jain, 1991b]. Basicamente, uma carga de trabalho é a combinaç ão de dados de entrada com as operaç ões do sistema em avaliaç ão associadas aos mesmos dados. Os Bench-marks s ão cargas de trabalho aplicadas para an álise de desempenho de sistemas computacionais. E o processo de comparar dois sistemas usando Benchmarks, tipicamente Benchmarks conhecidos e padr ão, é chamado de Benchmarking [Gregg, 2014].

Figura 2.2: Abordagem de Benchmark para avaliac¸ ˜ao de desempenho

Os Benchmarks geram uma carga de trabalho padronizada e fornece informaç ões relevantes para o benchmarking. A coleta de informaç ões relevantes envolvem o monitoramento do sistema enquanto est á sujeito a uma carga de trabalho espec´ıfica e depende de uma selecç ão cuidadosa da carga de trabalho. A carga de trabalho tamb ém é geralmente chamada por carga de trabalho de teste e denota alguma carga de trabalho usada em estudo de desempenho [Jain, 1991a,Gregg, 2014].

(30)

Uma carga de trabalho pode ser real ou sint ético. Uma carga de trabalho real é observada num sistema sendo usado para operaç ões normais, n ão pode ser repetida e, portanto, geralmente n ão é adequado para uso como carga de trabalho de teste. Enquanto que, uma carga de trabalho sint ética, cujas caracter´ısticas s ão semelhantes às da carga de trabalho real, pode ser aplicada repetidas vezes de forma controlada, é desenvolvida e usada para estudo por v árias raz ões, algumas destas raz ões s ão a representatividade, f ácil modificaç ão sem afectar as operaç ões, seguro, port ável e pode possui capacidade de mediç ão [Jain, 1991c,Gregg, 2014].

Existem v ários tipos de carga de trabalho, por exemplo, as cargas de trabalho tradicionalmente usadas para comparar sistemas computacionais, tais como processadores e sistemas timesharing s ão (1) instruç ão de adiç ão, (2) mix de instruç ões e (3) Kernel. E posteriormente, para comparar sistemas de base de dados e redes, por exemplo, (4) programas sint éticos e (5) aplicaç ões de Benchmark.

Por exemplo o TPC-W [Francisco, 2003], um Benchmark reconhecido para avaliaç ão de bases de dados de com ércio online, é um exemplo duma aplicaç ão de Benchmark. A carga de trabalho deste Benchmark, é realizada em um ambiente controlado de com ércio online que simula as actividades de um servidor da Web transacional orientado a neg ócios. Sua carga de trabalho sint ética exercita uma variedade de componentes do sistema associados a esses ambientes. Na subsecç ão2.2.1, é apresentado mais detalhes deste Benchmark.

Um outro exemplo, é o framework Yahoo! Cloud Serving Benchmark (YCSB) [Cooper et al., 2010], que é uma aplicaç ão de Benchmark que permite comparar o desempenho de nova geraç ão de siste-mas de serviço de dados em nuvem. Sua carga de trabalho sint ética constitui um pacote que combina operaç ões de leitura / escrita, distribuiç ões de pedido e assim por diante. Com este pacote é poss´ıvel examinar uma fatia ampla do espaço de desempenho. Pode ser usada para avaliar modelos de con-sist ência, selecionar a base de dados n ão relacional e assim por diante.

Para concluir, o Benchmark é uma abordagem muito utilizada para avaliaç ão de desempenho por aferiç ão2. É muito utilizado para comparar o desempenho de m áquinas diferentes, redesenhar hardware ou software, decis ão em fase de aquisiç ão dum novo sistema, ajudar a optimizar programas e muito mais. Outras t écnicas como modelagem, usada em simulaç ão, p.e., podem ser aplicadas em v árias área incluindo intelig ência artificial e sa úde [Calado et al., 2014], mas para medir e comparar a t écnica de aferiç ão é a que melhor se aplica.

2.2 Trabalhos relacionados

Nesta secç ão, é analisado comparativamente os Benchmarks TPC-W [Francisco, 2003], RUBiS [SPEC, 2003] e SPEC Web 2009 [OW2, 2011], considerando o tipo, o objectivo, a carga de trabalho de

(31)

teste, a m étrica principal e a aplicaç ão em avaliaç ão.

2.2.1 Benchmark TPC-W

O TPC-W [Francisco, 2003] é um Benchmark de Web Service transacional. A carga de trabalho é executada em um ambiente gerido que simula as actividades dum servidor de aplicaç ão transacional orientado a neg ócios. Seu objectivo é medir o desempenho de servidor e o custo por desempenho em lojas online.

A m étrica de desempenho relatada pelo TPC-W é a Interaç ões de Serviço por Segundo, da ex-press ão em Ingl ês Service Interactions Per Second (SIPS). V árias interaç ões de Web Service s ão utilizadas para simular a actividade duma loja online e cada interaç ão est á sujeita a uma restriç ão de tempo de resposta.

Figura 2.3: Arquitectura do TPC-W.

Possui uma arquitectura cliente/servidor, Figura2.3. A esquerda da Figura2.3, est á o componente Emulador Remoto de Neg ócio, da express ão em Ingl ês Remote Business Emulator (RBE) e o com-ponente composto pelos sistemas externos de Verificaç ão da Ordem de Compra, da express ão em Ingl ês Purchase Order Verification (POV), Emulador de Portal de pagamento, da express ão em Ingl ês Payment Gateway Emulator (PGE) e Emulador de Controle de Invent ário, da express ão em Ingl ês In-ventory Control Emulator (ICE). As suas principais responsabilidade s ão:

• ORBE é o componente respons ável por conduzir a carga de trabalho de teste ao Sistema em Avaliaç ão, da express ão em Ingl ês System Under Test (SUT) e realizar as mediç ões.

• O POV é o componente respons ável por validar a informaç ão de cr édito no acto de registo de novo cliente a pedido doSUT.

• OPGEé o componente respons ável por validar o cart ão de cr édito no acto de registo de ordem de compra a pedido doSUT.

(32)

• OICE ´e o componente respons ´avel pelo reabastecimento da loja.

A direita de Figura2.3est á oSUT. OSUTé uma loja online para o com ércio de livros. Possui uma arquitectura monol´ıtica e é integrado a uma base de dados relacional.

A carga de trabalho submetida aoSUTpode incluir (a) navegaç ão, (b) pesquisas de produtos, (c) compras e (d) encomendas. Sua principais interaç ões s ão:

• Registo de novo cliente

• Alteraç ão do m étodo de pagamento • Criar pedido de compra

• Remessa de produto

• Processo de gest ˜ao de estoque • Estado do pedido

• Lista dos produtos recentes • Detalhes de produtos

Nas subsecç ões seguintes (subsecç ão2.2.2e subsecç ão2.2.3), é descrito os outros Benchmarks comparativamente ao TPC-W.

2.2.2 Benchmark RUBiS

O RUBiS [SPEC, 2003] tamb ém é um Benchmark de Web Service transacional, tal como o TPC-W. A carga de trabalho é executada em um ambiente gerido que simula as actividades de um servidor de aplicaç ão transacional orientado a neg ócios. Mas difere parcialmente nos objectivos. O RUBiS tamb ém avalia o desempenho do servidor de aplicaç ão, mas correlaciona com a escalabilidade, i.e., avaliar padr ões de desenho de aplicaç ão e escalabilidade/desempenho de servidores de aplicaç ão.

A sua principal m étrica é o n úmero de pedidos por sess ão. Tal como o TPC-W, v árias interaç ões de Web Service s ão utilizadas para simular a actividade dum sistema de leil ão online. E cada interaç ão é parte duma sess ão de experimento.

Tal como o TPC-W, o RUBiS possui uma arquitectura cliente/servidor, Figura2.4. Os seus principais componentes s ˜ao:

• Clientes: realiza medic¸ ˜oes enquanto submete uma carga de trabalho de teste aoSUT.

• Servidor Web: lida com os pedidos Protocolo de Transfer ˆencia de Hipertexto, da express ˜ao em

Ingl ês Hypertext Transfer Protocol (HTTP) e é capaz de balancear a carga entre m últiplos servi-dores de aplicaç ão.

(33)

Figura 2.4: Arquitectura do RUBiS.

• Servidor de aplicaç ão: é respons ável por executar o servidor RUBis.

• Servidor de base de dados: mantem a base de dados do RUBis.

A carga de trabalho submetida ao SUTpode incluir (a) navegaç ão, (b) vendas e (c) licitaç ão. Em termos de interaç ões, al ém da l ógica de neg ócio principal, o RUBis implementa serviços complemen-tares, como mensagens instant âneas ou grupos de not´ıcias. As interaç ões do RUBis s ão realizadas dentro de sess ões, como referido, e distingue entre tr ês tipos de sess ões do utilizador:

• visitante: os utilizadores n ão precisam se registar, mas t êm permiss ão para navegar.

• comprador: precisa registar-se. Al ´em da funcionalidade fornecida durante as sess ˜oes do

visi-tante, durante uma sess ão do comprador, os utilizadores podem fazer lances para itens e consul-tar um resumo de seus lances, classificaç ões e coment ários atuais deixados por outros usu ários.

• vendedor: precisa registar-se. Esta sess ˜ao exige um emolumento antes que um utilizador possa

colocar um item à venda. Um leil ão começa imediatamente e dura normalmente n ão mais que uma semana. O vendedor pode especificar um preço de reserva (m´ınimo) para o item.

A arquitectura do RUBis é similar a arquitectura do TPC-W, ambas s ão Monol´ıticas, uma única base de dados, um servidor de aplicaç ão que pode ser replicado por quest ões de optimizaç ões.

A seguir na subsecç ão2.2.3, é descrito o benchmark SPEC Web 2009 comparativamente aos ben-chmarks TPC-W e RUBis.

2.2.3 Benchmark SPEC Web 2009

O SPEC Web 2009 [OW2, 2011], tal como o TPC-W e o RUBis, é um Benchmark de Web Service transacional. A carga de trabalho é executada em um ambiente gerido que simula as atividades de um servidor de aplicaç ão transacional orientado a neg ócios. Tamb ém avalia o desempenho de servidor de

(34)

aplicaç ão, como o TPC-W e o RUBis, mas seu objectivo principal é avaliar o desempenho de servidor web ligados a E/S, de modo que seus resultados possam mostrar como a consolidaç ão afeta a lat ência e a efici ência de energia de aplicaç ões ligadas a E/S.

A principal m étrica de desempenho, é dada por X@Y . Onde X, como apresentado na equaç ão2.1, é a m édia geom étrica das sess ões de utilizadores simult âneas (sus) para tr ês tipos de cargas de tra-balho (serviços banc ários, loja online e suporte a download) e Y , como apresentado na equaç ão2.2, representa a m édia geom étrica dos Watts correspondentes registrados.

X = SP ECweb2009 Banking × SP ECweb2009 Ecommerce × SP ECweb2009 Support

3 sus (2.1)

Y = W atts Banking × W atts Ecommerce × W atts Support

3 Watts (2.2)

A m étrica de desempenho principal é derivada das tr ês subm étricas, como uma m édia geom étrica. Os Watts correspondentes a estas subm étricas, tamb ém, s ão derivados como uma m édia geom étrica dos Watts usados durante a execuç ão das cargas de trabalho para serviços banc ários, com ércio electr ónico e suporte a download. Os Watts representa o consumo de energia durante o experimento.

As contagens das subm étricas da carga de trabalho est ão em unidades de sess ões simult âneas. Eles representam o n úmero de sess ões simult âneas do utilizador que oSUTpode oferecer ao atender aos requisitos de Qualidade de Serviço, da express ão em Ingl ês Quality Of Service (QoS) do Bench-mark. Enquanto a m étrica principal oferece contagens de desempenho para o sistema que est á a ser testado, as contagens das subm étricas oferecem uma vis ão de carga de trabalho por carga de trabalho das caracter´ısticas de desempenho dum sistema nos n´ıveis de pico.

Tal como o TPC-W e o RUBiS, o SPEC Web 2009 possui uma arquitectura cliente/servidor, Fi-gura2.5. Os seus principais componentes s ˜ao:

• Clientes: conduz uma carga de trabalho de teste aoSUT. Existe um cliente principal, que

inici-aliza e controla o comportamento dos outros clientes, executa rotinas de iniciinici-alizaç ão no servidor Web e noSimulador e, coleta e armazena os resultados dos testes de Benchmark. Por quest ões

arquitecturais e garantia de qualidade, o cliente principal pode ser alocado num servidor f´ısico separado.

• Simulador: emula um servidor de aplicac¸ ˜ao de backend com o qual o servidor Web deve se

comunicar para recuperar informaç ões espec´ıficas necess árias para concluir uma respostaHTTP

(35)

Figura 2.5: Arquitectura do SPEC Web 2009.

• Servidor Web: lida com os pedidos emitidos pelos clientes.

• Subsistema de armazenamento: mant ´em os dados processados.

Diferente do TPC-W e do RUBis, o SPEC Web 2009 tem diferentes sistemas em avaliaç ão, nomea-damente, serviços banc ários, com ércio electr ónico e suporte de download. Inclui carga de trabalho de teste de energia (baseada na carga de trabalho da loja online) e uma m étrica desempenho/energia.

2.3 Resumo

Na Tabela2.2, é resumida as principais caracter´ısticas dos Benchmarks comparados. Nesta secç ão discutiremos estas caracter´ısticas.

Os Benchmarks apresentados seguem o padr ão arquitectural de tr ês camadas, resultante dum n úmero significativo de aplicaç ões Monol´ıticas em nuvem ou locais antes do surgimento e populari-dade dos Microsserviços. Parte deles, j á est ão descontinuados. Hoje v ários deles, s ão adaptados para estudar caracter´ısticas de aplicaç ão baseadas em Microsserviços em v ários dom´ınios de aplicaç ão, p.e., [Gan et al., 2019].

Estas ferramentas diferem-se em termos de objectivos espec´ıficos, porque em termos de objectivo geral (avaliaç ão de desempenho de servidor de aplicaç ão), s ão similares. A m étrica comum de de-sempenho do servidor e presente nos Benchmarks apresentados é o d ébito sob restriç ão de tempo de resposta. Esta restriç ão pode estar definida explicitamente ou implicitamente. A computaç ão desta m étrica variou em funç ão dos objectivos e da carga de trabalho de cada Benchmark.

(36)

Tabela 2.2: Caracterizac¸ ˜ao dos trabalhos relacionados.

Trabalho Objectivo Carga de

traba-lho

M étrica principal Aplicaç ão

TPC-W Medir o desempenho do

servidor e custo/desem-penho em lojas online.

Navegac¸ ˜ao, pesquisas,

compras e

encomendas.

N ´umero de SIPS medi-dos usando uma mis-tura de carga de trabalho sint ´etica.

Loja online.

RUBis Avaliar padr ões de de-senho de aplicaç ão e escalabilidade/desem-penho de servidores de aplicaç ão. Navegaç ão, vendas e licitaç ão.

N ´umero de pedidos por sess ˜ao.

Sistema de

leil ˜ao online.

SPEC Web 2009

Avaliar o desempenho de servidor web ligados a E/S, de modo que seus resultados possam mos-trar como a consolidaç ão afeta a lat ência e a efici ência de energia de aplicaç ões ligadas a E/S.

Navegaç ão e operaç ões de persist ência.

Dada por X@Y. Onde X é a m édia geom étrica das sess ões de utiliza-dores simult âneas (sus) para os tr ês tipos de car-gas de trabalho e Y repre-senta a m édia geom étrica dos Watts corresponden-tes registrados. serviços banc ários, com ércio electr ónico e suporte de download.

S ão todos Benchmark de aplicaç ão de Web Service transacional. E de modo geral, estes Bench-marks, tentam compreender como o desempenho - medido em termos de tempo de resposta e d ébito - varia à medida que mais utilizadores acessam um Web Site ou p ágina Web.

Embora a avaliaç ão de desempenho é realizada de forma associada a outros factores, tais como dinheiro ou custo de energia. Estes Benchmarks, tentam responder as quest ões t´ıpicas que surgem ao analisar a escalabilidade/desempenho ou desempenho de Web Sites transacionais, p.e., se o Site ser á capaz de fornecer um desempenho aceit ável mesmo com o aumento da carga, qual é o n úmero m áximo de transaç ões que podem ser processadas por segundo, o Site pode ser atualizado de forma simples (por exemplo, adicionando mais servidores ou substituindo servidores existentes por outros mais po-derosos) para suportar volumes de tr áfego mais altos ou é necess ário fazer alteraç ões arquitecturais, entre outras quest ões.

Todos estes Benchmarks foram desenhados para sistemas Monol´ıticos, i.e., tipicamente o foco é um servidor de aplicaç ão integrado a um servidor de base de dados. Nenhum dos Benchmarks apre-sentados é capaz de medir o desempenho de diferentes implementaç ões de Microsserviços sob uma base comum de forma simples. Na secç ão3, é apresentado a arquitectura de soluç ão.

(37)

3

Arquitectura

Conte ´

udo

3.1 Requisitos . . . 23

3.2 Arquitectura . . . 24

(38)

(39)

Neste cap´ıtulo, é definido os requisitos para construç ão da nossa ferramenta de Benchmark na secç ão3.1. Na secç ão3.2, é apresentada a arquitectura da nossa ferramenta de Benchmark. E para finalizar, na secç ão3.3, é descrito o fluxo de trabalho t´ıpico.

3.1 Requisitos

A nossa principal preocupaç ão durante o desenho da nossa ferramenta de Benchmark foi garantir duas principais qualidades, nomeadamente a (1) correcç ão e o (2) desempenho da nossa ferramenta de Benchmark durante as mediç ões e Benckmarking.

Estas operaç ões s ão realizadas durante tr ês fases: (1) Pr é-teste, que consiste na configuraç ão do sistema para garantir as condiç ões iniciais dos experimentos; (2) Teste, que consiste em monitorar os experimentos e colectar dados; E finalmente, a fase de (3) P ós-teste, que consiste na reduç ão dos dados e comparaç ão das marcas.

Importa referir que, a escalabilidade das bases de dados, emulaç ão de terminal e clientes bem como o perfil da carga de trabalho de teste e a mistura de interaç ões é definida em conformidade com a especificaç ão TPC-W, deste modo quest ões relacionada a aproximaç ão a demanda real s ão acauteladas.

Destas preocupac¸ ˜oes referidas, definimos os seguintes requisitos:

• A ferramenta deve funcionar de modo a garantir que as diferentes fases n ão sobrecarreguem-se umas às outras, isto é, que n ão haja interrupç ões ou sobreposiç ões de tarefas (populaç ão das bases de dados, mediç ões ou Benchmarking).

• A ferramenta deve minimizar o impacto de sobrecarga que pode ser introduzida durante as mediç ões bem como validar as mediç ões.

• OSUTdeve ser simples, mas deve possuir as caracter´ısticas relevantes para avaliaç ão que pro-duza resultado com boa precis ão;

As diferentes fases n ão sobrecarregam-se devido a separaç ão clara dos componentes e da organizaç ão dos diferentes subsistemas dentro de cada componente, bem como divido a estrat égia de separaç ão das diferentes fases do experimento. A divis ão de pequenos trabalho nos diferentes subsistemas e a capacidade deste subsistemas colaborarem, permite minimizar o impacto de sobrecarga que pode ser introduzida durante as mediç ões. A divis ão do TPC-W em Microsserviço foi baseada em abordagem orientada a dom´ınio combinado com a caracterizaç ão da carga de trabalho de teste, que permitiu sim-plicidade, mas garantindo as caracter´ısticas relevantes para a avaliaç ão. Na secç ão3.2, é apresentado estes aspectos.

(40)

3.2 Arquitectura

Figura 3.1: Arquitectura da nossa ferramenta de Benchmark

`

A esquerda da Figura 3.1, est á o Gerador de carga. ´E a parte da ferramenta respons ável pela emulaç ão de terminal, dos utilizadores e dos pedidos a serem enviados aoAvaliador para exercitar o

TPC-W microsservic¸o, que ´e oSUT.

Esta parte da ferramenta implementa a especificaç ão TPC-W para conduzir a carga de trabalho de teste em intervalos apropriados utilizado para exercitar oSUT, mas com optimizaç ões para experimen-tos em cen ários de georeplicaç ão.

Esta parte da ferramenta, ´e composta por dois subsistemas principais, nomeadamente o (1) Popu-lator subsistema que preenche as bases de dados com uma carga de trabalho de teste TPC-W e o (2) RBE(Remote Business Emulator) subsistema que conduz a carga de trabalho de teste TPC-W. Suas principais responsabilidades:

• Populator: é respons ável por garantir as condiç ões iniciais para o experimento.

• RBE: é respons ável pela emulaç ão de terminal, utilizadores e carga de trabalho de teste.

No centro da Figura 3.1, est ´a o Avaliador, o elemento principal da nossa ferramenta que

per-mite avaliar e comparar diferentes alternativas de desenho e ou diferentes cen ários de instalaç ão (implantaç ões ou deployments em ingl ês).

´

E a parte da ferramenta respons ável pela mediç ões, registo de marcas e por reportar os resultados.

OAvaliador utiliza a carga de trabalho de teste gerada pelo Gerador de Carga para exercitar oSUTe

colectar dados enquanto monitora o experimento.

OAvaliador possui dois subsistemas principais e um terceiro componente de armazenamento de

(41)

• Monitor: é respons ável pelas mediç ões e monitoramento do experimento.

• Reporter: é respons ável pela reduç ão dos dados, comparaç ão das marcas e por reportar os

resultados.

• Repository: é respons ável por armazenar persistentemente as m étricas recebidas, tempo de

inicializaç ão e interm édios do experimento bem como toda informaç ão relevante relacionada ao estado doAvaliador.

OAvaliador possui sua pr ópria Interface de Programa de Aplicaç ão, da express ão em Ingl ês

Ap-plication Program Interface (API), utilizada para controlar as interaç ões. A Listagem 3.1, ilustra um exemplo daAPIdo Avaliador para mistura de interaç ões com georeplicaç ão semi-controlada peloRBE.

Listagem 3.1: Exemplo daAPIdo Avaliador para mistura de interaç ões com georeplicaç ão semi-controlada pelo RBE. 1 { 2 "mode":{ 3 "region":"us-east-1", 4 "zone":"ZOJJZC49E0EPZ" 5 }, 6 "interaction":"ChangePaymentMethod", 7 "input":{ 8 "customerId":2, 9 "paymentMethod":"CC", 10 "creditInfo":"ASN23Jaksdssa" 11 } 12 }

Para configuraç ão Defined no ficheiro de configuraç ão do Gerador de carga para o modo de

georeplicaç ão, o Gerador de carga controla o encaminhamento de pedido por zona e regi ão, mas

a escolha do endpoint numa dada zona ´e definido peloAvaliador, como ser ´a explicado na Cap´ıtulo4. ´

E responsabilidade doAvaliador ignorar ou utilizar determinados par âmetros no modo de interaç ão

preenchida no pedido. E esta decis ão é tomada em funç ão das configuraç ões iniciais do experimento, realizadas atrav és dos ficheiros de configuraç ão do Gerador de carga e do pr óprio Avaliador. A

Listagem3.2, é um exemplo daAPIdo pedido especial de inicializaç ão do experimento enviado pelo

(42)

Listagem 3.2: Exemplo daAPIdo Avaliador para o pedido especial de inicializac¸ ˜ao de experimento. 1 { 2 "command": "init", 3 "Geo": "Defined", 4 "scale":{ 5 "active": 10000, 6 "item": 2000 7 }, 8 "wirt90":{ 9 "NewCustomer": 1, 10 "ChangePaymentMethod": 3, 11 "CreateOrder": 4, 12 "OrderStatus": 4, 13 "NewProductsList": 1, 14 "ProductDetail": 1, 15 "ChangeItem": 1, 16 } 17 } `

A direita da Figura 3.1, est á o TPC-W microsserviço, o SUT, tamb ém pode ser denominado por Sistema em Avaliaç ão. É a vers ão microsserviço do TPC-W. A subsecç ão3.2.1, apresenta a divis ão arquitectural doSUT.

3.2.1 TPC-W microsservic¸o

O TPC-W Microsserviço é um sistema representativo duma loja online para avaliar o desempenho de plataformas adjacentes. É uma vers ão em Microsserviço do TPC-W Monol´ıtico de nossa autoria.

Este sistema é uma simplificaç ão, mas representativo o suficiente para avaliar o desempenho de diferentes plataformas, duma loja online em ambientes de nuvem com ou sem georeplicaç ão. O sistema modela interaç ão de (1) novo cliente, (2) mudança do m étodo de pagamento, (3) ordem de compra, (4) alteraç ão de item, (5) detalhes de cada item para uma lista de n elementos, (6) estado da ordem de compra, (7) produtos mais recentes, (8) gest ão de estoque e (9) entregas. As duas últimas, i.e. (8) e (9), s ão tarefas administrativas, mas existem como parte do modelo representado pela carga de trabalho (s ão executados como processos em background ).

A divis ão do SUTMonol´ıtico emSUTMicrosserviço, Figura3.2, foi realizada baseada na aborda-gem de Desenho Orientado a Dom´ınio, da express ão em Ingl ês Domain-Driven Design (DDD) [Evans, 2003,Vernon, 2013], que consiste em identificar entidades, serviços, agregaç ões e m ódulos de forma sistem ática. A divis ão obtida é a granularidade ideal para os

(43)

OSUT ´e composto por tr ˆes subsistemas principais, nomeadamente Customer, Product e

Shop-ping. Estes subsistemas s ˜ao considerados base comum para as diferentes alternativas de desenho e

para os diferentes cen ários de instalaç ão. Todos os subsistemas s ão associados a uma base de dados com seu respectivo modelo de dados. Estes subsistemas s ão as partes da plataforma alvos de Ben-chmark e a divis ão das tabelas n ão podem possuir granularidade mais fina do que as propostas nesta secç ão, mas de resto todos os componentes podem ser substitu´ıdos e, como tal, avaliados.

O m ódulo dePOV, m ódulo dePGEe m ódulo deICEs ão sistemas externos aos TPC-W microsserviço, como ilustrado na Figura3.2.

O componenteAvaliador na Figura3.2, serve para ilustrar as interaç ões entre o TPC-W microsserviço

e oAvaliador, i.e., ilustrar, claramente, os componentes que s ˜ao exercitados directamente pelo

Ava-liador (os componentes que s ˜ao alvos de Benchmark ). Como ilustrado na Figura3.1, estes

compo-nentes comunicam internamente entre si e com sistemas externos ao TPC-W microsservic¸o. Embora n ˜ao esteja ilustrado, estes subsistemas (Customer, Shopping e Product) comunicam-se com suas

respectivas base de dados. Cada subsistema tem o seu pr óprio modelo de dados e um conjunto de interaç ões internas e externas.

Figura 3.2:SUTbaseado em Microsservic¸o.

O subsistema Customer, ´e respons ´avel por gerir os clientes. Este subsistema, armazena os

da-dos de contacto, pagamento e endereço de cobrança do cliente, como ilustrado na Figura 3.3, que representa o seu modelo de dados. Este subsistema possui v árias funcionalidade, das quais as

(44)

prin-cipais s ão listadas na Tabela3.1 e o formato de mensagem usada para comunicaç ão é ilustrada na Listagem3.3.

Tabela 3.1: Principais funcionalidades do subsistema Customer.

Funcionalidade Sa´ıda

M ´ODULO CUSTOMER

newCustomer Permite realizar o registo dum novo cliente

no sistema.

Novo Nº da Ordem de Compra e Novo Identificador de Cliente.

changePaymentMethod Permite realizar alterac¸ ˜ao do

m ´etodo de pagamento dum cliente.

Novo m ´etodo de pagamento.

updateCustomerAddress Permite realizar actualizac¸ ˜ao

do enderec¸o de cobranc¸a dum cliente.

cliente actualizado.

findCustomerById Permite recuperar o cliente dado um

identificador.

cliente encontrado.

Figura 3.3: Modelo de Dados do Customer.

O subsistema Product, ´e respons ´avel por gerir os itens e os respectivos estoque. Este

subsis-tema, armazena os dados dos livros, autor e o estoque de produto, como ilustrado na Figura3.4, que representa o seu modelo de dados. Este subsistema possui v árias funcionalidade, das quais as prin-cipais s ão listadas na Tabela3.2 e o formato de mensagem usada para comunicaç ão é ilustrada na Listagem3.4.

O subsistemaShopping, ´e respons ´avel por gerir os pedidos de compra e de remessa. Este

subsis-tema, armazena os dados dos pedidos de compra, carinho de compras e de remessa, como ilustrado na Figura3.5, que representa o seu modelo de dados. Este subsistema possui v árias funcionalidade, das quais as principais s ão listadas na Tabela3.3e o formato de mensagem usada para comunicaç ão

´e ilustrada na Listagem3.5.

Os sistemas externos n ão s ão alvos de Benchmark directo, permitem representar de forma mais realista poss´ıvel a comunicaç ão entre os subsistemas do TPC-W microsserviço e os subsistemas

(45)

ex-Tabela 3.2: Principais funcionalidades do subsistema Product.

M ´ODULO PRODUCT

create Permite realizar o registO do novo produto. Novo produto.

updateStock Permite realizar a actualizac¸ ˜ao do atributo

S LAST MODIFIED da tabela STOCK com a data e hora actual dado um produto.

Produto com estoque actualizado.

newProducts Permite retornar uma lista dos itens

modifi-cados recentemente.

Lista de itens modificados.

getCostOfProducts Permite retornar o custo de cada

pro-duto num lista de propro-dutos.

Lista de itens.

productDetail Permite retornar informac¸ ˜ao detalhada de

produto duma lista de produtos pedidos.

Lista de itens.

Figura 3.4: Modelo de Dados do Product.

Tabela 3.3: Principais funcionalidades do subsistema Shopping

M ´ODULO SHOPPING

create Permite criar um pedido no base de dados e,

em seguida, encaminhar o processo de atendimento para envi ´a-lo.

Novo pedido.

status Permite retornar os ´ultimos n pedidos feitos pelo

cliente.

Lista de pedido.

ternos de fornecimento de servic¸o. Os sistemas externos s ˜ao:

• POV: sistema externo que autoriza cr ´edito para um novo cliente.

• PGE: sistema externo que autoriza pagamentos por cart ˜ao de cr ´edito.

(46)

Figura 3.5: Modelo de Dados do Shopping.

Listagem 3.3: Exemplo de formato de mensagens ProtoBuf para o m ´odulo Customer

1 m e s s a g e B u y e r { 2 i n t 3 2 id = 1; 3 s t r i n g b u s i n e s s _ n a m e = 2; 4 s t r i n g b u s i n e s s _ i n f o = 3; 5 s t r i n g p a s s w o r d = 4; 6 s t r i n g f i r s t _ n a m e = 5; 7 s t r i n g l a s t _ n a m e = 6; 8 s t r i n g p h o n e = 7; 9 s t r i n g e m a i l = 8; 10 f l o a t d i s c o u n t = 9; 11 e n u m M e t h o d T y p e { 12 PO = 0; 13 CC = 1; 14 } 15 m e s s a g e P a y m e n t { 16 s t r i n g c r e d i t _ i n f o = 1; 17 i n t 3 2 p u r c h a s e _ o r d e r _ n u m b e r = 2; 18 M e t h o d T y p e m e t h o d = 3; 19 } 20 m e s s a g e A d d r e s s { 21 i n t 3 2 id = 1; 22 s t r i n g s t r e e t 1 = 2; 23 s t r i n g s t r e e t 2 = 3; 24 s t r i n g c i t y = 4; 25 s t r i n g s t a t e = 5;

(47)

26 s t r i n g zip = 6; 27 } 28 m e s s a g e C o u n t r y { 29 i n t 3 2 id = 1; 30 s t r i n g n a m e = 2; 31 } 32 P a y m e n t p a y m e n t = 10; 33 A d d r e s s a d d r e s s = 11; 34 C o u n t r y c o u n t r y = 12; 35 } 36 m e s s a g e B u y e r L i s t { 37 r e p e a t e d B u y e r b u y e r s = 1; 38 }

Listagem 3.4: Exemplo de formato de mensagens ProtoBuf para o m ´odulo Product

1 m e s s a g e R e c e n t P r o d u c t { 2 i n t 3 2 d u r a t i o n = 1; 3 s t r i n g s u b j e c t = 2; 4 i n t 3 2 l i m i t = 3; 5 } 6 m e s s a g e M a x P r o d u c t D e t a i l I D s { 7 i n t 3 2 max = 1; 8 } 9 m e s s a g e P r o d u c t { 10 m e s s a g e I t e m { 11 i n t 3 2 id = 1; 12 s t r i n g t i t l e = 2; 13 s t r i n g p u b _ d a t e = 3; 14 s t r i n g p u b l i s h e r = 4; 15 s t r i n g s u b j e c t = 5; 16 s t r i n g d e s c r i p t i o n = 6; 17 f l o a t srp = 7; 18 f l o a t c o s t = 8; 19 s t r i n g a v a i l a b l e = 9; 20 s t r i n g i s b n = 10; 21 i n t 3 2 p a g e = 11;

(48)

22 s t r i n g b a c k i n g = 12; 23 s t r i n g d i m e n s i o n s = 13; 24 } 25 m e s s a g e A u t h o r { 26 i n t 3 2 id = 1; 27 s t r i n g f i r s t _ n a m e = 2; 28 s t r i n g l a s t _ n a m e = 3; 29 } 30 m e s s a g e S t o c k { 31 i n t 3 2 id = 1; 32 i n t 3 2 q u a n t i t y = 2; 33 s t r i n g l a s t _ m o d i f i e d = 3; 34 } 35 I t e m i t e m = 1; 36 A u t h o r a u t h o r = 2; 37 S t o c k s t o c k = 3; 38 } 39 m e s s a g e P r o d u c t L i s t { 40 r e p e a t e d P r o d u c t p r o d u c t s = 1; 41 }

Listagem 3.5: Exemplo de formato de mensagens ProtoBuf para o m ´odulo Shopping

1 i m p o r t " c u s t o m e r . p r o t o "; 2 i m p o r t " p r o d u c t . p r o t o "; 3 e n u m S t a t u s T y p e { 4 P E N D I N G = 0; 5 B A C K _ O R D E R E D = 1; 6 } 7 e n u m S h i p T y p e { 8 AIR = 0; 9 UPS = 1; 10 F E D E X = 2; 11 S H I P = 3; 12 C O U R I E R = 4; 13 M A I L = 5; 14 }

(49)

15 m e s s a g e S h i p { 16 i n t 3 2 id = 1; 17 s t r i n g d a t e = 2; 18 S h i p T y p e t y p e = 3; 19 i n t 3 2 a d d r _ i d = 4; 20 f l o a t c o s t = 5; 21 i n t 3 2 o r d e r _ i d = 6; 22 } 23 m e s s a g e O r d e r { 24 i n t 3 2 id = 1; 25 i n t 3 2 c u s t o m e r _ i d = 2; 26 s t r i n g d a t e = 3; 27 f l o a t s u b _ t o t a l = 4; 28 f l o a t tax = 5; 29 f l o a t t o t a l = 6; 30 S h i p s h i p = 7; 31 S t a t u s T y p e s t a t u s = 8; 32 s t r i n g a u t h _ i d = 9; 33 f l o a t d i s c o u n t = 10; 34 } 35 m e s s a g e O r d e r L i n e { 36 i n t 3 2 id = 1; 37 i n t 3 2 o r d e r _ i d = 2; 38 i n t 3 2 i t e m _ i d = 3; 39 i n t 3 2 q u a n t i t y = 4; 40 S t a t u s T y p e s t a t u s = 5; 41 f l o a t c o s t = 6; 42 } 43 e n u m C a r d T y p e { 44 V I S A = 0; 45 M A S T E R C A R D = 1; 46 D I S C O V E R = 2; 47 A M E R I C A N _ E X P R E S S = 3; 48 D I N E R S = 4; 49 } 50 m e s s a g e C a r d { 51 i n t 3 2 id = 1; 52 s t r i n g n a m e = 2;

(50)

53 s t r i n g n u m b e r = 3; 54 s t r i n g e x p i r y = 4; 55 s t r i n g c o d e = 5; 56 i n t 3 2 o r d e r _ i d = 6; 57 C a r d T y p e t y p e = 7; 58 } 59 m e s s a g e C r e a t e O r d e r { 60 B u y e r b u y e r = 1; 61 P r o d u c t L i s t i t e m s = 2; 62 S h i p s h i p = 3; 63 C a r d c a r d = 4; 64 } 65 m e s s a g e O r d e r S t a t u s { 66 B u y e r b u y e r = 1; 67 i n t 3 2 max = 2; 68 r e p e a t e d O r d e r o r d e r s = 3; 69 } 70 m e s s a g e C a r d L i s t { 71 r e p e a t e d C a r d c a r d s = 1; 72 }

3.3 Fluxo de Trabalho T´ıpico

O Fluxo de trabalho segue v árias etapas, algumas etapas ocorrem antes das mediç ões, outras durante e outras depois das mediç ões. Em resumo o fluxo de trabalho t´ıpico tem o seguinte ciclo de vida:

1. Escalabilidade e populaç ão das bases de dados, esta etapa ocorre antes das mediç ões. É deta-lhada na subsecç ão3.3.1

2. Ativaç ão das mediç ões, esta etapa inicializa as mediç ões. É detalhada na subsecç ão3.3.2

3. Execuç ão das mediç ões, esta etapa realiza as mediç ões e o registo de marcas. É detalhada na subsecç ão3.3.3

4. Encerramento das mediç ões, esta etapa encerra as mediç ões. É detalhada na subsecç ão3.3.4

(51)

3.3.1 Escalabilidade e populac¸ ˜ao das bases de dados

Para começar, é necess ário garantir as condiç ões iniciais para o experimento. Para tal, Figura3.6,

o Gerador de carga executa o Populator. O Populator, carrega as configurac¸ ˜oes e inicializa os

par âmetros de escalabilidade das bases de dados. Em seguida, estabelece ligaç ão com oAvaliador

para iniciar as transacç ões relacionadas com a populaç ão inicial. Ao inicializar o Avaliador, este

re-cria as tabelas em cada base de dados doSUT. Por esta raz ão, oPopulator n ão inclui as operaç ões

de eliminaç ão e de criaç ão de tabelas. Para cada transacç ão efectuada peloPopulator, o Avaliador

realiza uma interaç ões para cada Endpoint existente na matriz de georeplicaç ão associada a respec-tiva interaç ão Modelo de Troca de Produtos, Serviços ou Informaç ões entre Empresas, da express ão em Ingl ês Business-To-Business (B2B). A populaç ão das bases de dados é realizada para todos os m ódulos doSUTde forma sequencial. Finalmente, ap ós concluir o processo de populaç ão, oPopulator

solicita estat´ıstica do estado das bases de dados para verificar se todas as operaç ões foram realizadas com sucesso. A principal informaç ão estat´ıstica é a cardinalidade das bases de dados, que é o principal argumento do verificador doPopulator.

Figura 3.6: Escalabilidade e populac¸ ˜ao das bases de dados.

3.3.2 Ativaç ão das mediç ˜

oes

Antes das mediç ões, é necess ário verificar as condiç ões iniciais para o experimento e ativar as mediç ões. Para tal, Figura 3.7, o Gerador de carga executa o RBE que, inicialmente carrega as configuraç ões (inclui o tipo de teste, que pode ser normal ou de georeplicaç ão e, caso seja georepli-cado; o tipo de interaç ão, que pode ser aleat ória ou definida), Listagem4.2, envia um pedido especial de in´ıcio de experimento aoAvaliador. O Avaliador por interm édio do Monitor, carrega as configuraç ões

(52)

(matriz de restriç ão de tempo de resposta e outras configuraç ões), verifica o estado inicial das bases de dados e, se necess ário, verifica a configuraç ão da matriz de georeplicaç ão se satisfazem o tipo de teste solicitado. Se a verificaç ão for satisfeita, oMonitor activa as mediç ões e retornar o estado aoRBE, o estado inclui a lista de zonas e regi ões dispon´ıveis, cardinalidade das bases de dados e se pode ou n ão dar in´ıcio ao experimento.

Figura 3.7: Ativaç ão das mediç ões.

3.3.3 Execuç ão das mediç ˜

oes

Como ilustrado na Figura 3.8, com as condiç ões iniciais satisfeitas e tido a aprovaç ão para in´ıcio do experimento, oRBEinicia os clientes e a seguir executa as interaç ões com oAvaliador com um

tempo de reflex ão probabil´ıstico. OAvaliador recebe o pedido por meio do Monitor e contabiliza. O Monitor realiza o mapeamento do pedido, mede o tempo da operaç ão, verifica se o tempo medido para

a operaç ão satisfaz a matriz de restriç ão, se satisfaz armazena a marca registada, contabiliza resposta e retorna a resposta aoRBErespectivo.

3.3.4 Encerramento das medic¸ ˜

oes

Para encerrar as mediç ões, Figura 3.9, oRBEenvia um pedido especial ao Avaliador. O Avalia-dor atrav és do Monitor, verifica se todos os pedidos foram conclu´ıdos, se todos foram conclu´ıdos com

sucesso, calcula oSIPSglobal, armazena de forma persistente no Repository, encerra as medic¸ ˜oes

(pr óximos pedidos n ão ser ão contabilizados) e retorna uma mensagem de sucesso aoRBE. Se exis-tirem pedidos, incompletos de um determinado tipo de operaç ão, verifica se 90% deste tipo de pedido foram conclu´ıdo com sucesso, calcula oSIPSglobal, armazena de forma persistente no Repository,