diego liberalquino soares lima · 2019-10-25 · um middleware orientado a objeto existente (camid...

Diego Liberalquino Soares Lima

ECAMID: UM MIDDLEWARE PARA NUVEM COMPUTACIONAL

COM SUPORTE À ELASTICIDADE

Dissertação de Mestrado

Universidade Federal de Pernambuco

[email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE2014

www.cin.ufpe.br/~posgraduacao

Universidade Federal de Pernambuco

Centro de InformáticaPós-graduação em Ciência da Computação

Diego Liberalquino Soares Lima

ECAMID: UM MIDDLEWARE PARA NUVEM COMPUTACIONALCOM SUPORTE À ELASTICIDADE

Trabalho apresentado ao Programa de Pós-graduação em

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Nelson Souto Rosa

RECIFE2014

Catalogação na fonteBibliotecária Jane Souto Maior, CRB4-571

L732e Lima, Diego Liberalquino Soares ECAMID: um middleware para nuvem computacional com

suporte à elasticidade. / Diego Liberalquino Soares Lima. – Recife: O Autor, 2014.

98 f.: il., fig., tab.

Orientador: Nelson Souto Rosa. Dissertação (Mestrado) – Universidade Federal de

Pernambuco. CIn, Ciência da Computação, 2014. Inclui referências.

1. Sistemas distribuídos. 2. Computação em nuvem. 3. Middleware. I. Lima, Diego Liberalquino Soares (orientador). II. Título.

004.36 CDD (23. ed.) UFPE- MEI 2014-190

Dissertação de Mestrado apresentada por Diego Liberalquino Soares Lima ao programa dePós-Graduação em Ciência da Computação do Centro de Informática da Universidade Fe-deral de Pernambuco, sob o título eCaMid: Um Middleware para Nuvem Computacionalcom Suporte à Elasticidade, orientada pelo Prof. Nelson Souto Rosa e aprovada pela bancaexaminadora formada pelos professores:

———————————————————————–Prof. Adilson Barbosa Lopes

Departamento de Informática e Matemática Aplicada/UFRN

———————————————————————–Prof. Kiev Santos da Gama

Centro de Informática/UFPE

———————————————————————–Prof. Nelson Souto Rosa

Centro de Informática/UFPE

Visto e permitida a impressão,Recife, 13 de agosto de 2014

———————————————————————–Profa. Edna Natividade da Silva BarrosCoordenadora da Pós-Graduação em Ciência da Computação do

Centro de Informática da Universidade Federal de Pernambuco.

Dedico este trabalho aos meus pais, Alexandre e Carmem, e

à minha futura esposa, Pollyana, por todo apoio que me foi

dado nesta jornada repleta de obstáculos.

Agradecimentos

Gostaria de agradecer primeiramente aos meus pais, Carmem e Alexandre, por sempreestarem do meu lado ao longo deste mestrado, aconselhando-me nos momentos de dúvida,incentivando-me nos momentos de angústia e colaborando em todas as atividades cotidianas.Sem o apoio de vocês, jamais teria conseguido iniciar o mestrado, tão pouco manter-se nele facea todas as adversidades encontradas.

Agradeço também à minha noiva Pollyana, por toda companhia e paciência nestes doisanos. Ambos estivemos fazendo nossos mestrados neste tempo e compartilhamos os mesmosmomentos de estresse e sacrifício pessoal. Tivemos ainda que nos manter unidos frente àsbarreiras de um relacionamento à distância, fruto de nossas escolhas profissionais.

Gostaria de agradecer também a pessoas com quem convivi na minha vida profissionalnestes anos, e que demonstraram toda sua compreensão nesta jornada acadêmica. Por issoagradeço a Juliano Rabelo e Saulo Cadete da Document Solutions; Rodolfo Max, José Neto,Alan, Tony, Thiago, Eduardo e Felipe, da Petroquímica Suape; Jefferson, Frederico, Janisson,Anderson, Helder, Jairo e Cícero da Dataprev.

Além destes quero agradecer a todos os amigos que mantiveram apoio, mesmo com aminha ausência dos círculos sociais nestes últimos anos, muitos desses que também estavamenfrentando as dificuldades de um mestrado.

Finalmente, agradeço a Tércio Morais e Nelson Rosa pela parceria nos projetos pesquisasde middleware e nuvem que estivemos realizando neste período de mestrado.

A distributed system is one in which the failure of a computer you didn’t even

know existed can render your own computer unusable.

—LESLIE LAMPORT

Resumo

Computação em nuvem fornece aplicações, plataformas e servidores virtuais comoserviço, e permite que consumidores paguem pela utilização destes serviços sem que elesprecisem ser adquiridos. Um dos grandes benefícios da computação em nuvem é a elasticidade,uma vez que consumidores podem requisitar mais recursos sob demanda e liberá-los quando nãosão mais necessários. Aplicações distribuídas desenvolvidas em nuvem devem levar em conta apresença da elasticidade para implementar sua arquitetura e serviços. No entanto, o uso efetivoda elasticidade por parte das aplicações pode ser complexo e ocasionar vários erros. Utilizandoum middleware orientado a objeto existente (CaMid - Cloud-Aware Middleware), este trabalhoapresenta o projeto e a implementação dos mecanismos básicos para suporte à elasticidade,tais como: replicação, coordenação de tarefas, compartilhamento de estado e balanceamentode carga. Estes mecanismos foram incorporados ao CaMid e visam maximizar a utilizaçãodos recursos de nuvem à medida que estes são adicionados à infraestrutura da aplicação emantê-los em funcionamento quando estes recursos são descartados. Para avaliar os mecanismosdesenvolvidos, foi realizada uma avaliação experimental para identificar o impacto dos mesmosna execução das aplicações. Foi possível verificar que o CaMid conseguiu utilizar os recursos denuvem com eficiência a um custo do overhead causado pela coordenação dos vários processosdistribuídos.

Palavras-chave: Sistemas Distribuídos. Computação em Nuvem. Middleware. Elasticidade.

Abstract

Cloud computing offers applications, platforms and virtual servers as a service, andallows consumers to pay by the use of these services, without requiring their acquisition. Oneof the greatest benefits of cloud computing is elasticity, since consumers may request moreresources on demand and release them when they are no longer needed. Distributed applicationsdeveloped by the cloud must take in account the presence of elasticity for implementing itsarchitecture and services. However, the effective use of elasticity by the applications may provecomplex and error prone. By the use of an existing object oriented middleware (CaMid - Cloud-Aware Middleware), this work presents the project and implementation of the basic mechanismsfor supporting elasticity, namely: replication, task coordination, state sharing and load balancing.These mechanisms have been incorporated to CaMid and aim to maximize cloud resourcesutilization while new resources are being added to application infrastructure, or keep workingwhen the cloud resources are being discarded. In order to evaluate the developed mechanisms,an experimental evaluation has been done to identify the impact of these mechanisms duringapplcation execution. It was possible to verify that CaMid was able to use cloud resources withefficiency at the overhead cost caused by the coordination of the many distributed processes.

Keywords: Distributed Systems. Cloud Computing. Middleware. Elasticity.

Lista de Figuras

2.1 Arquitetura dos serviços de nuvem oferecidos pela Google (JIN et al., 2010) . . 232.2 Relacionamento entre modelos de computação em nuvem (RIMAL; CHOI;

LUMB, 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3 Arquitetura Genérica de Middleware . . . . . . . . . . . . . . . . . . . . . . . 312.4 Arquitetura de aplicação multi-camadas . . . . . . . . . . . . . . . . . . . . . 322.5 Invocação de método remoto em um middleware orientado a objetos . . . . . . 332.6 Relacionamento entre padrões de projeto para serviços comuns de um mid-

dleware Distributed Object Computing Middleware (DOC) . . . . . . . . . . . 382.7 Arquitetura em camadas do Cloud-Aware Middleware (CaMid), em uma pilha

de serviços de nuvem (MORAIS; LIBERALQUINO; ROSA, 2013) . . . . . . 422.8 Arquitetura dos serviços de gerenciamento do CaMid . . . . . . . . . . . . . . 432.9 Interação do Local Manager com demais camadas do CaMid (MORAIS; LIBE-

RALQUINO; ROSA, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.10 Interação do Global Manager com demais camadas do CaMid (MORAIS; LIBE-

RALQUINO; ROSA, 2013) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1 Elementos básicos do modelo de domínio do Elastic Cloud-Aware Middleware

(eCaMid) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.2 Visão geral dos componentes do eCaMid. Os elementos de cor branca represen-

tam componentes, os de cor cinza representam serviços, enquanto o elementopreto representa um framework. Os elementos em tracejado são oriundos daarquitetura do CaMid, enquantos os elementos em linha contínua foram adicio-nados ao eCaMid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.3 Estilos de comunicação um-para-um e um-para-muitos . . . . . . . . . . . . . 533.4 Modelo de domínio do subsistema de publish-subscribe . . . . . . . . . . . . . 543.5 Modelo de domínio do subsistema de escalonamento de tarefas . . . . . . . . . 553.6 Modelo de domínio do subsistema de gerenciamento de ciclo de vida . . . . . . 573.7 Componentes envolvidos na criação de objetos de sessão. . . . . . . . . . . . . 583.8 Componentes envolvidos em uma requisição de método remota. . . . . . . . . 593.9 Componentes envolvidos em balanceamento de carga . . . . . . . . . . . . . . 603.10 Componentes envolvidos em roteamento de requisições . . . . . . . . . . . . . 603.11 Balanceamento de carga no eCaMid . . . . . . . . . . . . . . . . . . . . . . . 613.12 Tolerância a falhas no mecanismo de balanceamento de carga. . . . . . . . . . 623.13 Diagrama de implantação para nós do eCaMid . . . . . . . . . . . . . . . . . . 64

4.1 Gráficos de barra para comparação de tempo de resposta médio entre todos osgrupos de experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4.2 Gráficos de barra para comparação de vazão entre todos os grupos de experimentos 784.3 Tempo de resposta vs tempo do experimento para comparação entre os grupos

de experimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Lista de Tabelas

2.1 Relações entre classes de Remote Objectse mecanismos de gerenciamento derecursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.2 Cenários possíveis para falha de um nó e o impacto causado (WILDER, 2012) . 40

4.1 Tempo de resposta e vazão para o grupo de experimentos Direct-Stateless . . . 714.2 Tempo de resposta e vazão para o grupo de experimentos Direct-Stateful . . . . 724.3 Tempo de resposta e vazão para o grupo de experimentos Elastic-Clustered-

Stateless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 734.4 Tempo de resposta e vazão para o grupo de experimentos Elastic-Clustered-Stateful 744.5 Teste estatístico Mann-Whitney comparando os grupos de experimento Elastic-

Clustered-Stateful e Elastic-Clustered-Stateless . . . . . . . . . . . . . . . . . 764.6 Teste estatístico Mann-Whitney comparando os grupos de experimento Elastic-

Clustered-Stateful e Elastic-Clustered-Stateful . . . . . . . . . . . . . . . . . . 77

Lista de Acrônimos

AOR Absolute Object Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

API Application Programming Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Amazon VPC Amazon Virtual Private Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

AWS Amazon Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

WS-BPEL Business Process Execution Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

CaMid Cloud-Aware Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

CDMI Cloud Data Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

DDS Data Distribution Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

DHT Distributed Hash Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

DOC Distributed Object Computing Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

EC2 Elastic Compute Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

eCaMid Elastic Cloud-Aware Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

GAE Google App Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

GDS Global Data Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

GFADS Research Group on Foundations and Applications of Distributed Systems . . . . . 18

IaaS Infrastructure as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

ICME Intercloud Message Exchange Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

IDS Intrusion Detection System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

JVM Java Virtual Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

MIS Monitoring Information Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

MOM Message Oriented Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

OCCI Open Cloud Computing Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

OMG Object Modeling Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

OSGi Open Service Gateway initiative . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

OVF Open Virtualization Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26

OWL Web Ontology Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

P2P Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

PaaS Platform as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

QoS Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

REST Representational state transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .88

RMI Remote Method Invocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

RPC Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

SaaS Software as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SAN Storage Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

SLA Service Level Agreement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

SNMP Simple Network Management Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

SOA Service Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

UUID Universally Unique Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Sumário

1 Introdução 161.1 O Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2 Soluções Parciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.3 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.4 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Conceitos Básicos 212.1 Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.1.1 Categorias de serviço de nuvem . . . . . . . . . . . . . . . . . . . . . 222.1.1.1 SaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.1.1.2 PaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.1.1.3 IaaS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.1.4 Relacionamento entre modelos de computação em nuvem . . 27

2.1.2 Elasticidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2 Padrões de Projeto de Middleware e Nuvem . . . . . . . . . . . . . . . . . . . 29

2.2.1 Arquitetura e Padrões de Projeto para Middleware . . . . . . . . . . . 302.2.1.1 Middleware Orientado a Objetos . . . . . . . . . . . . . . . 312.2.1.2 Gerenciamento de Ciclo de Vida . . . . . . . . . . . . . . . 332.2.1.3 Serviços comuns . . . . . . . . . . . . . . . . . . . . . . . . 35

2.2.2 Arquitetura e Padrões de Projeto para Computação em Nuvem . . . . . 392.2.2.1 Padrões de projeto para computação em nuvem . . . . . . . 40

2.3 Cloud Aware Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.3.1 Local Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.3.2 Global Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

2.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 Proposta 463.1 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.2 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3 Modelo de domínio geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.4 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4.1 Coordenação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.4.1.1 Comunicação Publish/subscribe . . . . . . . . . . . . . . . . 533.4.1.2 Escalonamento de tarefas periódicas . . . . . . . . . . . . . 54

3.4.2 Compartilhamento de Estado . . . . . . . . . . . . . . . . . . . . . . . 55

3.4.2.1 Gerenciamento de ciclo de vida de objetos remotos . . . . . 563.4.3 Balanceamento de Carga . . . . . . . . . . . . . . . . . . . . . . . . . 59

3.5 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.6 Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

4 Avaliação de Desempenho e Discussão 664.1 Objetivos e Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.1.1 Métricas, Parâmetros e Fatores . . . . . . . . . . . . . . . . . . . . . . 674.1.2 Técnica de avaliação, carga de trabalho e projeto de avaliação . . . . . 69

4.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 704.2.1 Resultados individuais de cada experimento . . . . . . . . . . . . . . . 704.2.2 Comparação entre resultados . . . . . . . . . . . . . . . . . . . . . . . 74

4.3 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5 Trabalhos Relacionados 815.1 Tecnologias fundamentais usadas pelo ElasticCamid . . . . . . . . . . . . . . 81

5.1.1 JGroups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.1.2 Infinispan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5.2 Trabalhos de Middleware Desenvolvido para Nuvem . . . . . . . . . . . . . . 835.2.1 Arquitetura Geral de Middleware . . . . . . . . . . . . . . . . . . . . 845.2.2 Multitenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 855.2.3 Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 875.2.4 Elasticidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 885.2.5 Outros requisitos não funcionais de nuvem . . . . . . . . . . . . . . . 905.2.6 Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915.2.7 Considerações finais . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

6 Considerações Finais 936.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Referências 95

161616

1Introdução

Computação em Nuvem é um paradigma que relaciona sistemas distribuídos e com-putação utilitária. Assim como concessionárias de energia elétrica, que fornecem um serviçode manutenção e distribuição de energia, provedores de computação em nuvem oferecem umadiversidade de ativos como serviço, onde esses ativos podem ser aplicativos, plataformas desoftware, bancos de dados virtuais, infraestrutura virtual, hardware e outros (JIN et al., 2010).Da mesma forma que usuários do serviço de energia elétrica, usuários de nuvem pagam pelo usodo serviço e não pela aquisição desses ativos, que é contabilizada de várias formas, como porexemplo tempo de uso, quantidade de dados armazenado, tráfego de rede etc.

Uma nuvem é um conjunto de ativos fornecido por um provedor específico e gerenci-ados pelos seus usuários através de interfaces gráficas, consoles ou Application Programming

Interfaces (APIs). Os provedores escondem detalhes relacionados à manutenção e operação dosativos, geralmente oferecendo algum Service Level Agreement (SLA). Se este ativo for umaplataforma de software, o provedor se encarrega de provisionar a aplicação em uma máquinafísica ou virtual, replicar esta instalação em múltiplos nós e assim por diante. Caso o ativo sejainfraestrutura, o provedor se encarrega de gerenciar máquinas virtuais dos usuários em um pool

de máquinas físicas gerenciadas pelo provedor entre outras operações (RIMAL; CHOI; LUMB,2010).

O que torna a computação em nuvem atraente é a diminuição do investimento necessáriopara construir e manter uma infraestrutura de hardware e software, para desenvolver novosaplicativos e para usar e manter software de terceiros. Empresas como Google oferecem pacotesde software de produtividade e serviços de email (Google Apps for Business) (HERRICK, 2009),acessíveis através da internet em poucos cliques, sem a necessidade de instalar e manter essesaplicativos localmente (MARSTON et al., 2011), em um modelo conhecido como Software as

a Service (SaaS). Outros provedores de nuvem como a Amazon (VARIA; MATHEW, 2012)permitem a aquisição de infraestrutura, como máquinas e sistemas de armazenamento virtuaisque funcionam de forma similar a uma infraestrutura física, mas sem a necessidade de fazer umgrande investimento inicial tanto em aquisição quanto em instalação que é comum em servidoresfísicos.

1.1. O PROBLEMA 17

Além da vantagem da redução do investimento, o modelo de computação em nuvempermite também evitar o superdimensionamento dos recursos computacionais utilizados. Ativosde um provedor de computação em nuvem podem ser adquiridos e descartados rapidamente.Logo, se é previsto um aumento na utilização do serviço, pode ser solicitado a aquisição de novosativos. No momento em que estes não forem mais necessários, estes poderão ser descartados edevolvidos para o provedor. Este conceito inovador de computação em nuvem é chamado deelasticidade.

Aplicações distribuídas que foram pensadas para o ambiente de nuvem podem se be-neficiar do conceito de elasticidade. No modelo tradicional, toda a infraestrutura de softwaree hardware deve ser dimensionada de antemão para atender requisitos não funcionais comodesempenho, escalabilidade, disponibilidade e confiabilidade. Essa infraestrutura teria que sergrande o suficiente para suportar os picos de utilização, mas estaria subutilizada em momentosde ociosidade. Com a elasticidade, a infraestrutura não precisa ser superdimensionada, maspode ser incrementada ou diminuída de acordo com a demanda de recursos computacionais daaplicação. Esse fato torna os ambientes de computação em nuvem muito mais eficientes no ge-renciamento de recursos que infraestruturas tradicionais (MARSTON et al., 2011) (TALUKDER;ZIMMERMAN; A, 2010).

1.1 O Problema

A elasticidade não apenas é um dos grandes benefícios para aplicações que se apóiamno modelo de computação em nuvem, mas também um grande desafio para os desenvolvedores.A arquitetura dessas aplicações precisa ser pensada para que estas possam operar de formaeficiente e confiável em um ambiente elástico. Atualmente, é possível desenvolver aplicaçõeselásticas utilizando facilidades específicas de um provedor, sejam essas plataformas ou serviçosespecíficos, ou através do uso de APIs específicas que permitem a gerência desses recursos porparte da aplicação.

Provedores de nuvem oferecem diversos modelos de serviço que apóiam o desenvol-vimento de software distribuído. Em um deles, chamado Platform as a Service (PaaS), ouPlataforma como Serviço, o ativo gerenciado consiste em uma plataforma de software, queoferece um modelo de programação para a construção de uma aplicação. A vantagem destemodelo é que a plataforma já implementa os mecanismos de elasticidade, fornecendo paraa aplicação um framework ou um conjunto de APIs que devem ser usados para fazer coisascomo armazenar dados ou tratar requisições externas. A desvantagem é que a aplicação estaráfortemente acoplada às APIs, frameworks e serviços específicos oferecidos pelo provedor dePaaS.

Um outro modelo utilizado para o desenvolvimento de aplicação é conhecido comoInfrastructure as a Service (IaaS), ou Infraestrutura como Serviço. Neste modelo, o provedorfornece uma infraestrutura virtual, composta por servidores, discos rígidos, balanceadores de

1.2. SOLUÇÕES PARCIAIS 18

carga entre outros. O provedor também oferece um console ou API para gerenciar os recursosvirtuais da nuvem. A vantagem deste modelo é que o usuário pode definir a arquitetura e atecnologia utilizada na aplicação e pode estar sempre utilizando as tecnologias mais recentes(RIMAL; CHOI; LUMB, 2010). A desvantagem é que os ajustes necessários por tornar aaplicação elásticas precisam ser realizadas pelo usuário, através da gerência de recursos virtuaisatravés de APIs ou consoles específicos de cada provedor.

Para facilitar a implantação de soluções elásticas, provedores de IaaS também costumamoferecer serviços específicos que incluem agentes de monitoramento, balanceadores de carga,sistemas de armazenamento chave/valor entre outros. No entanto, de acordo com o provedorde IaaS, esses serviços específicos podem não estar presentes ou divergir na forma em quefuncionam. Existe um esforço para padronizar APIs e serviços de provedores de IaaS. Emboraexistam diversos padrões para computação em nuvem, sejam estes abertos ou padrões de facto,muitos deles ainda não são maduros o suficiente ou amplamente adotados (LEWIS, 2013).

Pelos motivos mencionados acima, é bastante difícil desenvolver uma aplicação que sejaexecutada sobre um provedor de nuvem que possua suporte à elasticidade sem utilizar APIs ouserviços específicos de cada provedor, visto que muitos desses serviços são incompatíveis entresi devido à falta de padronização. Desenvolver esses mecanismos de suporte à elasticidade dentroda própria aplicação distribuída pode ser difícil, dado a uma série de complexidades inerentesque são características da elasticidade. Além das complexidades inerentes, podemos citar ascomplexidades acidentais que são evidenciadas ao misturar lógica do domínio da aplicaçãocom funcionalidades voltadas para o suporte à elasticidade, violando o princípio de projeto desoftware conhecido como Separation of Concerns.

1.2 Soluções Parciais

Middleware é uma solução ligada diretamente ao desenvolvimento de aplicações dis-tribuídas. Tradicionalmente, middleware tem sido empregado para fornecer um modelo deprogramação que abstrai diversas complexidades do desenvolvimento de aplicações distribuídas.Middleware pode ser utilizado para prover serviços que tornem transparentes as complexida-des associadas a um ambiente elástico. O uso de middleware em nuvens IaaS pode trazer osbenefícios encontrados em nuvens PaaS, reduzindo o acoplamento com serviços de um provedorespecífico e fornecendo uma variedade maior de modelos de programação e tecnologias.

Entre os diversos sistemas de middleware propostos que visam resolver o problema daelasticidade e que foram testados em nuvens reais, alguns são voltados a domínios específicos,como é o caso de soluções de computação paralela e em grade (CALHEIROS et al., 2012);alguns dependem de ferramentas específicas que não estão presentes nos serviços de um provedorde nuvem (JAYARAM, 2013); outros apenas propõem recursos que refinam o uso de elasticidade,fornecendo capacidades adicionais (AZEEZ et al., 2010).

Em um trabalho anterior do grupo Research Group on Foundations and Applications of

1.3. PROPOSTA 19

Distributed Systems (GFADS)1, foi proposto um middleware, que utiliza o paradigma Distributed

Object Computing Middleware (DOC), denominado Cloud-Aware Middleware (CaMid). Estemiddleware foi pensado para o ambiente de computação em nuvem e seu principal objetivo étornar transparente (invisível) a complexidade de gerenciamento da nuvem para o desenvolvedorde aplicação distribuída. Os princípios que guiam a arquitetura do CaMid são: cloud-awareness,ou a capacidade de monitorar e controlar os recursos disponíveis da aplicação; gerenciamentoautomático, que é a capacidade de manipular recursos sem intervenção humana direta; suportea aplicações cliente-servidor; transparência de localização e acesso; arquitetura baseada empadrões de projeto (MORAIS; LIBERALQUINO; ROSA, 2013).

O CaMid foi pensado para gerenciar vários aspectos de uma nuvem IaaS, incluindoaspectos relacionados à elasticidade. Desta forma, o Elastic Cloud-Aware Middleware (eCaMid)poderia ser usado diretamente por aplicações que utilizam o modelo de objetos distribuídosque serão implantadas no ambiente de IaaS ou como blocos fundamentais de um PaaS que usaesse mesmo modelo. No entanto, a sua primeira implementação não possui mecanismos detolerância a falhas, como tolerância a falha temporária ou permanente de um nó, assim comobalanceamento de carga e mecanismos mais eficientes de comunicação entre nós.

1.3 Proposta

Este trabalho propõe uma extensão à implementação e arquitetura do CaMid, chamadaeCaMid, que aprimora os mecanismos existentes para ambientes elásticos. Foram adicionadosmecanismos de comunicação em grupo, replicação e balanceamento de carga, que permitemtomar vantagem da adição dinâmica de nós a uma infraestrutura virtual, assim como tratar deforma transparente as falhas de comunicação, ou garantir a consistência das informações quandoos mesmos nós são removidos, seja de forma intencional ou por ocasião de falha. Os mecanismosde suporte à elasticidade do eCaMid não dependem de um provedor específico de IaaS, poistodas as funcionalidades foram desenvolvidas internamente ao próprio middleware.

O modelo de programação do antigo CaMid foi estendido para permitir o suporte aobjetos stateful, interceptadores, a troca de mensagens entre componentes através de um modelopublish/subscribe e a execução de tarefas periódicas, coordenadas entre vários nós. Essas novasfuncionalidades apóiam tanto o desenvolvimento de aplicações distribuídas quanto à extensão defuncionalidades internas ao middleware.

A principal contribuição deste trabalho foi mostrar os benefícios da utilização de co-municação em grupo, replicação e balanceamento de carga em uma arquitetura de middleware

orientado a objeto, tornando-a mais adequada para a utilização em ambientes elásticos decomputação em nuvem.

1http://www.gfads.org/

1.4. ESTRUTURA DA DISSERTAÇÃO 20

1.4 Estrutura da Dissertação

Este trabalho está dividido em 6 capítulos, incluindo este capítulo introdutório.

� Capítulo 2: introduz conceitos básicos úteis para compreender a proposta destetrabalho, como uma explanação do conceito de nuvem e elasticidade, uma série depadrões de projeto utilizados em middleware e em computação em nuvem e umabreve explanação sobre a arquitetura do CaMid,

� Capítulo 3: apresenta a arquitetura do eCaMid e como as novas funcionalidadespoderão ser utilizadas em um ambiente elástico,

� Capítulo 4: apresenta uma avaliação experimental do eCaMid em um cenário onde aelasticidade é utilizada,

� Capítulo 5: este capítulo apresenta os trabalhos relacionados que também procuramresolver de alguma forma a problema da elasticidade, e

� Capítulo 6: apresenta algumas considerações finais sobre os resultados obtidos nestetrabalho e propõe trabalhos no futuro.

212121

2Conceitos Básicos

Neste capítulo, introduziremos as principais tecnologias necessárias ao entendimentodo eCaMid. Na primeira seção, faremos uma breve discussão sobre o que é computação emnuvem, o seu modelo de negócio, as principais categorias de serviço de computação em nuveme a relação entre essas categorias de serviço, com foco em SaaS, PaaS e IaaS. Faremos umaconceituação do que é elasticidade, qual a sua importância para computação em nuvem e comoeste tipo de solução é implantada nas categorias de serviço discutidas anteriormente.

Na seção seguinte, faremos uma discussão sobre o que é middleware e quais padrõesarquiteturais e de projeto apóiam o seu desenvolvimento. Faremos uma discussão também de vá-rios padrões de projeto que são relevantes para o contexto de aplicação em nuvem. Seguindo estaseção, apresentaremos o CaMid, quais seus objetivos e princípios, qual sua a arquitetura, e comoesta é apoiada sobre os padrões discutidos na seção anterior. Faremos também uma discussãosobre as deficiências arquiteturais e de implementação do CaMid em relação à elasticidade.

2.1 Computação em Nuvem

Segundo FOX et al. (2009), computação em nuvem "é a materialização da ideia decomputação utilitária, que tem o potencial de mudar grande parte da indústria de TI, fazendocom que produtos de software sejam oferecidos como serviço e reduzindo os imensos gastoscom hardware e pessoas para operarem esses equipamentos". Computação em nuvem pode seroferecida como uma série de serviços, que oferecem ativos de várias formas, de softwares comosuítes de produtividade como é o caso do serviço Google App Engine (GAE) (HERRICK, 2009) àplataformas de software e infraestruturas virtuais complexas, como Amazon Web Services (AWS)(VARIA; MATHEW, 2012). Quando estes serviços são oferecidos através da Internet, por umaentidade externa, este serviço é chamado de nuvem pública, mas quando é oferecido por umdepartamento ou setor de uma mesma corporação, a oferta de serviço é chamada de nuvemprivada.

Computação em nuvem nasceu da necessidade de se operar uma infraestrutura comeficiência através de recursos de software e hardware escaláveis, em resposta à necessidade de

2.1. COMPUTAÇÃO EM NUVEM 22

negócios que precisam desenvolver rapidamente aplicações com alto desempenho, escalabili-dade e disponibilidade, sejam estas aplicações analíticas ou aplicações móveis que precisam derespostas em tempo real (MARSTON et al., 2011). Conforme várias empresas de tecnologiaganhavam maturidade na utilização de tecnologias como virtualização e Service Oriented Archi-

tecture (SOA), foi possível construir infraestruturas robustas onde operações de rotina, comoaquisição de servidores virtuais, aconteciam de forma automática e transparente (FURHT, 2010)(JIN et al., 2010). Após o esforço de automatizar a gerência desses ativos, foram criados modelosde monetização para que estes pudessem ser disponibilizados como serviços.

2.1.1 Categorias de serviço de nuvem

Dependendo do ativo oferecido em um serviço, podem existir vários tipos de ofertas decomputação em nuvem. Há várias taxonomias de computação em nuvem descritas na literatura,como Hardware as a Service, Data as a Service, Storage as a Service, Business as a Service eassim por diante. No entanto, dentre todas as taxonomias descritas, três estão sempre presentes:SaaS, PaaS e IaaS.

2.1.1.1 SaaS

A primeira categoria, Software as a Service (SaaS), trata de aplicações que são dispo-nibilizadas como serviços para um usuário específico, um grupo de usuários ou uma empresa.A exemplo de aplicativos SaaS, temos o Dropbox DRAGO et al. (2012), um sistema de ar-mazenamento e compartilhamento de arquivos; o já mencionado Google Apps for BusinessHERRICK (2009), um pacote de software que inclui e-mail, criação de documentos como textose apresentações e compartilhamento de arquivos; redes sociais como Facebook1, que permitemo compartilhamento de mensagens, imagens e videos; serviços de streaming, que incluem oGrooveshark2 e Netflix3. Há várias características que geralmente estão presentes em aplicativosfornecidos como SaaS: todos estes são acessíveis pela Internet, através de vários dispositivos,permitem algum tipo de troca de informações entre os seus usuários ou possuem modelos deassinatura que permitem pagar mais para obter algum tipo de vantagem no serviço.

Esses aplicativos geralmente possuem requisitos não funcionais complexos, como dispo-nibilidade, escalabilidade, desempenho e confiabilidade. Além destes requisitos, esses aplicativosprecisam ser constantemente atualizados, corrigindo defeitos rapidamente e oferecendo novasfuncionalidades e recursos. Desenvolver plataformas de software e hardware que sejam capazesde suportar esses requisitos não funcionais é um dos grandes desafios para os provedores deSaaS.

1http://www.facebook.com2http://www.grooveshark.com3http://www.netflix.com


Figura 2.1: Arquitetura dos serviços de nuvem oferecidos pela Google (JIN et al., 2010)

2.1.1.2 PaaS

A segunda classificação de serviço oferecido em computação em nuvem, Platform as a

Service (PaaS), consiste em uma plataforma de software que um framework ou uma API quepossibilita o desenvolvimento de aplicações distribuídas. Usuários desses serviços implantam aaplicação na plataforma e definem parâmetros que informam a quantidade de recursos necessários,enquanto o provedor do serviço se encarrega de provisionar a infraestrutura necessária para osníveis desejados de Quality of Service (QoS). Cada oferta de PaaS varia bastante de provedorpara provedor conservando, contudo, algumas semelhanças. Discutiremos sobre dois popularesserviços de PaaS, GAE (SANDERSON, 2009) e Heroku (KEMP; GYGER, 2013), para entendercomo funcionam as ofertas de PaaS.

O serviço GAE, Figura 2.1, fornece ao desenvolvedor uma plataforma voltada paraaplicações Web. Cada aplicação web é executada em um sandbox, um ambiente que restringe oacesso da aplicação a funcionalidades como acesso a arquivos, limitando-a a utilizar requisiçõesHTTP para páginas presentes na Web, na própria aplicação ou no GAE. Para utilizar outrosserviços, como armazenamento de dados, e-mail, XMPP e outros, deve-se utilizar as APIsfornecidas pelo serviço, que por sua vez se encarrega de alocar recursos e distribuir as váriaspartes da aplicação de forma transparente, garantindo sua escalabilidade. O usuário é cobradopelos recursos que utiliza do serviço.

Google não revela em detalhes a arquitetura de sua oferta de PaaS, e não existe naliteratura uma descrição detalhada dos componentes e como estes interagem para tornar aaplicação disponível. É possível que a solução utilize uma espécie de middleware que provêacesso a todas APIs oferecidas e de algum outro serviço que trata de distribuir a aplicação entre


várias máquinas, que podem ser físicas ou virtuais.Pelo modelo de cobrança adotado no GAE, é possível verificar que cada porção da

aplicação é monitorada, desde o acesso a sua datastore (chamada Bigtable), que contabilizanúmero de leituras e escritas, requisições HTTP para serviços externos, logging e outros. Ousuário, contudo, não tem controle sobre a quantidade de recursos utilizados numa aplicaçãoGAE e pode apenas indicar o valor máximo que deseja pagar pelo serviço. Este tem a autonomiade ditar quantas instâncias serão necessárias e qual a forma de balanceamento de carga usada,por exemplo.

A plataforma Heroku suporta aplicações Web escritas em diferentes linguagens deprogramação (Java, Ruby, Python, Node.js e outras), onde essa aplicação deve ser dividida emvários pedaços a serem executados em containers chamados dynos. De forma similar ao GAE,um dyno representa um sandbox ou container que isola uma aplicação de outra em uma estruturavirtual, mas sem as mesmas restrições que foram mencionadas anteriormente no GAE.

Existem dois tipos principais de dynos, um Web Dyno, que é responsável por receberrequisições web externas e um Worker Dyno que executa algum processo auxiliar, como umarotina batch ou um processo que consome mensagens de uma fila. Dessa forma é possível criaraplicações que dividem tarefas entre diversos processos distribuídos. Além dos dois tipos dedynos mencionados, o Heroku oferece outros dynos especializados que atuam como bancos dedados e servidores de mensagem, por exemplo (KEMP; GYGER, 2013).

Cada dyno é executado em uma stack, um conjunto de máquinas virtuais que contémconfigurações idênticas – sistema operacionais na mesma versão, com versões específicasdas linguagens e softwares utilitários da plataforma instalados. Um gerenciador de processosdistribuídos é utilizado para escalonar os dynos em cada máquina virtual do stack. Cada usuáriopode verificar quais dynos estão em execução em um determinado momento.

O modelo de cobrança utilizado no Heroku é mais simples do que aquele utilizado noGAE. O usuário é cobrado por cada dyno utilizado e um preço mais específico para os dynos

especializados. O usuário no Heroku tem mais controle dos recursos que utiliza, que determinaquantos dynos serão utilizados e de que tipo. Além disso o Heroku também oferece APIs deserviços para que os dynos sejam monitorados pelo usuário e agentes que reinicializam dynos

que se encontrem inoperantes ou com o desempenho degradadao (KEMP; GYGER, 2013).Diferente da plataforma GAE, que restringe à aplicação o uso de APIs mais restritas e

uma arquitetura específica, o Heroku dá total liberdade ao usuário de usar qualquer tecnologiadesde que seja compatível com as configurações definidas no stack. Em contrapartida, oframework ou tecnologia utilizados devem ser adaptar ao ambiente fornecido pelo Heroku,de forma similar ao que acontece com ofertas de IaaS. O diferencial do Heroku em relaçãoaos serviços de IaaS é que este oferece um ambiente pré-configurado, e o gerenciamento e aimplantação das aplicações seguem uma arquitetura de processos.

Além dessas ofertas de PaaS, outros serviços merecem destaque. A plataforma ElasticBeanstalk é parte do catálogo AWS e é composto de várias máquinas virtuais pré-configuradas


com software específico, com serviços de escalabilidade automática (VARIA; MATHEW, 2012).A plataforma Tsuru4 é uma implementação open source do Heroku, que pode ser implantadaem instalações privadas de IaaS. De forma similar, Cloud Foundry5 é outro PaaS open source

voltado para infraestruturas privadas.De forma geral, podemos observar que os PaaS podem ser compostos de middleware

específico e de um serviço de gerenciamento que é responsável por provisionar este middlewareem uma infraestrutura física ou virtual.

2.1.1.3 IaaS

Além das ofertas de PaaS, ainda há provedores que fornecem infraestrutura ao usuáriode nuvem. Essas infraestruturas utilizam virtualização, uma tecnologia que permite simular ofuncionamento de hardware através de software. Como os ativos virtuais são constituídos dedados, eles podem ser armazenados, copiados e versionados. O público alvo das ofertas deInfrastructure as a Service (IaaS) são organizações que precisam implantar aplicações de altaescalabilidade com alto controle sobre a tecnologia utilizada, sem ter que lidar com o custo deaquisição, implantação e manutenção de hardware.

Diferentemente das ofertas de PaaS, os ativos oferecidos pelos serviços de IaaS são maishomogêneos, e geralmente são servidores, discos rígidos, redes privadas e balanceadores decarga. Além desses ativos, os provedores costumam oferecer serviços mais específicos, como oAmazon Cloudwatch (VARIA; MATHEW, 2012), da suíte AWS, que é usada para monitoraros recursos da aplicação e servir de métrica para outros serviços da AWS, como Auto Scaling.Os serviços específicos costumam ser exclusivos de cada provedor, alguns oferecem serviçosligeiramente similares. Todos os provedores de nuvem disponibilizam uma API que pode serusada para gerenciar esses ativos.

Os serviços disponibilizados pelos provedores de IaaS podem ser divididos em 4 ca-tegorias: processamento, armazenamento, rede virtual, e serviços específicos. O serviço deprocessamento é a base de todos os serviços de IaaS. Este permite o gerenciamento, monitora-mento, cópia e provisionamento de servidores virtuais. O provedor oferece os servidores emvários tamanhos, dependendo da quantidade de processadores, memória RAM e capacidade dearmazenamento. Usuários e fornecedores externos fornecem pacotes que contém um sistema ope-racional e uma distribuição de software, conhecidos como imagens, que também são gerenciadaspelo provedor de IaaS. Todos os provedores de IaaS oferecem o serviço de poder computacional,incluindo nuvens públicas (AWS) e privadas (Openstack6, Opennebula7, Eucalyptus8.

A segunda categoria de serviço IaaS trata de armazenamento de dados. É comum queo provedor ofereça este serviço de duas formas distintas: como um serviço de gerenciamento

4http://www.tsuru.io5http://cloudfoundry.org6http://www.openstack.org7http://www.opennebula.org8http://www.eucalyptus.com


de blocos virtuais, como o AWS Elastic Block Store, Openstack Cinder e Eucalyptus StorageController; ou um serviço de armazenamento chave-valor, tais como AWS Simple StorageService, Openstack Swift e Eucalyptus Walrus. O primeiro é utilizado como discos rígidosvirtuais que aumentam a capacidade de armazenamento de uma máquina virtual, enquanto oarmazenamento de chave-valor pode ser usado para armazenar imagens de máquinas virtuaisou diretamente por aplicações distribuídas, sob a forma de bancos de dados não relacionais.Serviços de armazenamento de bloco dependem de estruturas da infraestrutura física, comoStorage Area Networks (SANs), enquanto servidores de armazenamento chave-valor são bancosde dados completos, particionáveis e de alta escalabilidade.

Além da capacidade de oferecer máquinas virtuais e armazenamento, os provedores denuvem também oferecem redes virtuais, como é o caso dos serviços Amazon Virtual Private

Cloud (Amazon VPC) (VARIA; MATHEW, 2012) e Openstack Neutron (OPENSTACK CLOUDADMINISTRATOR GUIDE, 2014). Esses software permitem a emulação de redes virtuais,como roteadores e switches qua atuam na camada de rede, dispositivos de firelwall e outros.Através desse softwares é possível separar a infraestrutura em várias camadas, como é o caso deseparar servidores de aplicação e banco de dados em camadas distintas.

Existe uma grande variedade de serviços específicos fornecidos por fornecedores deIaaS. O provedor AWS possui um grande catálogo de serviços, como balanceamento de carga,provisionamento automático (auto scaling), monitoramento (Cloudwatch) entre outros. Outrosfornecedores de IaaS públicos, como Google Compute Cloud 9 oferecem serviços similares.No espaço de fornecedores de IaaS privados, temos Eucalyptus e Openstack que fornecembalanceamento de carga através do Network Controller e Neutron, respectivamente.

Nem todos os serviços mencionados são unanimidade em provedores de IaaS. Open-nebula e Cloudstack, por exemplo, oferecem apenas os serviços de poder computacional earmazenamento (apenas discos virtuais). Para que uma aplicação utilize o potencial oferecidopela nuvem, ela deve conhecer quais as facilidades oferecidas pelo provedor; para se manterindependente, é necessário que esta possua mecanismos para se adaptar às diferentes ofertas deserviço.

A maioria das iniciativas de padronizar a Computação em Nuvem estão voltadas para omodelo de IaaS, por conta da similaridade dos serviços oferecidos por diferentes provedores, deacordo com a categoria do serviço. Temos Open Cloud Computing Interface (OCCI) 10, umainiciativa para padronizar as APIs voltadas para o controle de máquinas virtuais; Cloud Data

Management Interface (CDMI) 11, uma API para serviços de armazenamento de dados; Open

Virtualization Format (OVF) 12 que define formatos específicos para os metadados de máquinasvirtuais, permitindo que estas sejam migradas de um provedor para outro (LEWIS, 2013).

9https://cloud.google.com/products/compute-engine/10http://occi-wg.org11http://www.snia.org/cdmi12http://www.dmtf.org/standards/ovf


Figura 2.2: Relacionamento entre modelos de computação em nuvem (RIMAL; CHOI;LUMB, 2010)

2.1.1.4 Relacionamento entre modelos de computação em nuvem

É possível observar uma possível relação entre as ofertas de SaaS, PaaS e IaaS. Omodelo de SaaS precisa ser capaz de suportar uma grande quantidade de usuários e manteralta disponibilidade, uma vez que seus serviços podem estar sendo usados por um usuário emqualquer parte do mundo, em diferentes horários. Para isso, uma oferta de SaaS precisa serconstruída sobre uma plataforma que forneça esses requisitos, como o oferecido em um modelode PaaS. Este, por sua vez, precisa de uma infraestrutura eficiente que suporte a elasticidade eprovisionamento rápido de recursos, como numa oferta de IaaS. Essa relação entre serviços podeser ilustrada na Figura 2.2.

Não necessariamente um serviço oferecido por um modelo está apoiado por outro modelode computação em nuvem. Não há evidências de que o GAE opere sobre um serviço de IaaS.Na verdade, o GAE foi desenvolvido anos depois da plataforma mencionada. Contudo, existemprovedores públicos de PaaS que utilizam a infraestrutura de provedores de IaaS, como é o casodo Heroku, que opera sobre a infraestrutura provida pela AWS. O Software chamado CloudApp13 é uma aplicação que segue o modelo SaaS, especializada em compartilhamento de imagens,documentos, video e outros ativos, através da plataforma Heroku. Outros provedores de SaaS,

13http://www.getcloudapp.com/


como Netflix 14, possuem uma plataforma própria e preferem utilizar a infraestrutura da AWSdiretamente.

2.1.2 Elasticidade

Uma das consequências de computação em nuvem foi a conversão de despesas decapital em despesas operacionais (FOX et al., 2009), direcionando os investimentos que anteseram realizados em hardware e soluções de alto poder computacional para despesas de pessoal eferramentas para gerenciar o potencial de computação em nuvem. Este fator se deve a elasticidade,uma vez que é possível obter recursos da nuvem e depois descartar uma parte quando estes nãoestão sendo utilizados.

Em uma infraestrutura tradicional, existe o custo associado à aquisição de recurso(hardware), instalação e operação da infraestrutura. Esta deve ser bem planejada para evitartanto o risco de se ter uma infraestrutura saturada ou subutilizada. Geralmente, o uso médio dopoder computacional da infraestrutura física costuma variar entre 5% e 20% (SIEGELE, 2008),mas durante picos de utilização, o uso do poder computacional pode aumentar numa dimensãode duas a dez vezes. Supondo que durante uma parte do dia sejam necessários 500 servidorespara atender a demanda de acesso de uma aplicação (pico), mas no resto do tempo apenas 100servidores sejam necessários, com uma média de 300 servidores necessários por dia; para semanter disponível e não degradar o desempenho da aplicação durante o pico de utilização, serianecessária uma infraestrutura 1.7 vezes maior do que a média de uso dos servidores (FOX et al.,2009). O paradigma de computação em nuvem, devido à elasticidade, oferece uma forma demitigar o risco involvido no dimensionamento da infraestrutura, fornecendo a possibilidade deadicionar ou remover novas máquinas virtuais em minutos, ao invés de semanas ou meses eminfraestruturas tradicionais.

Utilizar a elasticidade com eficiência não é uma tarefa fácil. BABAR; CHAUHAN(2011) menciona os desafios de migrar uma aplicação chamada Hackystat15, desenvolvidaem uma infraestrutura tradicional, para uma infraestrutura ou plataforma fornecida por umprovedor de nuvem. Para escolher a arquitetura da solução, quatro requisitos foram levados emconta. O primeiro requisito está relacionado à possibilidade de aumentar ou diminuir o tamanhoda nuvem de acordo com critérios de desempenho. O segundo requisito estava relacionadoà portabilidade da aplicação para diferentes provedores de nuvem, que deveriam suportar astecnologias utilizadas pela aplicação. O terceiro requisito se referia a portabilidade de dados(persistência), aos mecanismos de persistência de diferentes provedores. O quarto requisito sereferia a necessidade de uma visão única do sistema: embora a infraestrutura fosse dinâmica,com vários componentes replicados, deveria ser possível acessar todas essas réplicas como umúnico componente.

14http://www.netflix.com15http://csdl.ics.hawaii.edu/research/hackystat/

2.2. PADRÕES DE PROJETO DE MIDDLEWARE E NUVEM 29

Para atender esses requisitos foram realizadas modificações na arquitetura da Hackystat.Foram utilizados os serviços de IaaS, uma vez que ofertas de PaaS não possibilitavam utilizar astecnologias utilizadas no Hackystat. Foi necessário separar os componentes de lógica de negócioe persistência para que fosse possível criar réplicas do primeiro e o segundo fosse adaptável amúltiplos provedores de IaaS. Além da persistência, foi criado um componente que orquestravaas requisições do Hackystat para as réplicas criadas em diferentes máquinas virtuais (BABAR;CHAUHAN, 2011).

2.2 Padrões de Projeto de Middleware e Nuvem

Aplicações executadas no ambiente de computação em nuvem estão dentro do grandegrupo que compreende os sistemas distribuídos. O que diferencia sistemas distribuídos deaplicações tradicionais é que um único sistema está dividido em um ou mais processos, que secomunicam através de mensagens, que possuem espaços de memória distintos e interagem juntoscom um objetivo único (GHOSH, 2010).

As vantagens de um sistema distribuído sobre sistemas monolíticos são: localização geo-gráfica distribuída, em que várias aplicações em diferentes localidades podem trocar informaçõesentre si; desempenho e escalabilidade, onde tarefas que seriam realizadas em um processo podemser divididas entre vários; compartilhamento de recursos, onde múltiplos processos compartilhamrecursos em comum, como é o caso de bancos de dados compartilhados; e tolerância a falhas,uma vez que a falha em um processo pode ser compensada pela existência de um outro processoredundante (SCHMIDT et al., 2013) (VÖLTER; KIRCHER; ZDUN, 2005).

Apesar de todos os benefícios, o desenvolvimento de sistemas distribuídos apresentauma série de desafios. Existem complexidades inerentes e acidentais relacionadas a sistemasdistribuídos. Entre as complexidades inerentes temos a necessidade de lidar com falhas parciaisde um sistema, qualidade de serviço, deadlock distribuídos, sincronização entre outros. Entre ascomplexidades acidentais estão as limitações das ferramentas de de desenvolvimento de softwarepara lidar com esse cenário, além da falta de APIs portáveis entre diferentes infraestruturas.Um outro problema é a reinvenção e redescobertas de conceitos e técnicas voltadas para de-senvolvimento de aplicações distribuídas: existe na indústria de sistemas distribuídos váriosprotocolos, bibliotecas, sistemas operacionais entre outros que resolvem os mesmos problemase são geralmente incompatíveis entre si (SCHMIDT et al., 2013). Muitas dessas soluções sãoproprietárias, sem utilizar padrões abertos já difundidos na indústria.

Tradicionalmente, Middleware tem sido empregado para tornar transparentes as com-plexidades inerentes de um sistema distribuído, fornecendo, ao mesmo tempo, um modelode programação mais abstrato que pode ser utilizado pelos desenvolvedores desses sistemas.Existem várias categorias de Middleware, dependendo do tipo de modelo de programação uti-lizado: O modelo de Remote Procedure Call (RPC) torna a comunicação entre dois processosbastante similar à invocação de funções, onde o cliente fornece uma série de parâmetros e o


servidor retorna uma resposta; o modelo DOC, é uma especialização do modelo RPC, onde asprimitivas utilizadas são invocações de métodos de objetos, onde estes podem possuir estadoe ser compostos de outros objetos; e o modelo Message Oriented Middleware (MOM), ondefilas de mensagem são utilizadas como primitiva, onde produtores e consumidores de mensagensutilizam essas filas para se comunicar de indiretamente (VÖLTER; KIRCHER; ZDUN, 2005).

O desenvolvimento de Middleware tem sido fortemente apoiado por padrões de projetos.Estes representam um conjunto de boas práticas no projeto do software, pois já foram testadose provados ao longo dos anos, tornando-se soluções refinadas. Padrões de projeto também sãoutilizados para compor um vocabulário utilizado para compartilhar conhecimento e experiênciasobre possíveis problemas computacionais e suas soluções (GAMMA et al., 1993). Existe umaextensa literatura sobre a aplicação desses padrões a sistemas distribuídos: SCHMIDT et al.(2013) inclui padrões para lidar com concorrência e programação de redes; VÖLTER; KIRCHER;ZDUN (2005) mostra os componentes fundamentais para a construção de Middleware orientadoa objeto; e HOHPE; WOOLF (2004) menciona um conjunto de padrões para integrar diferentessistemas utilizando mensagens e comunicação assíncrona.

Existem padrões de projeto e de arquitetura para aplicações distribuídas que utilizam oparadigma de computação em nuvem (WILDER, 2012) (HOMER et al., 2014) (REESE, 2009).WILDER (2012) ilustra diversas soluções para problemas comuns de computação em nuvem,como escalabilidade horizontal, auto-escalabilidade, consistência eventual, tolerância a falhas,entre outros. O foco deste trabalho está voltado para o desenvolvimento de aplicações quenasceram neste ambiente e precisam ser pensadas para tirar proveito de todos os benefíciosconcedidos pelo paradigma de computação em nuvem.

2.2.1 Arquitetura e Padrões de Projeto para Middleware

Enquanto middleware pode ser definido de várias formas e é descrito de várias maneirasna literatura, podemos utilizar uma arquitetura genérica, baseada em camadas, para descreversua estrutura, como é ilustrada na figura 2.3. Entre as camadas dispostas na figura, podemosevidenciar os dispositivos de Hardware e Sistemas Operacionais e Protocolos, que compreendemtodas as APIs e mecanismos de baixo nível que envolvem a comunicação de rede e entreprocessos de um mesmo sistema operacional. A última camada, constituída pela aplicação,compreende toda a lógica de domínio, que por sua vez utiliza todas as camadas abstratas demiddleware para realizar comunicação.

As camadas que se localizam entre a camada de infraestrutura e a serviços específicoscompreendem todas as funcionalidades que estão disponíveis em um middleware. A camadade infraestrutura, é responsável por encapsular mecanismos de baixo nível de um sistemaoperacional e programação de rede. Entre os mecanismos encapsulados, temos a programaçãode sockets, gerenciamento de eventos e concorrência. Esta camada também precisa lidar comdiferenças entre APIs de sistemas operacionais. A camada de infraestrutura oferece para a camada


Figura 2.3: Arquitetura Genérica de Middleware

de distribuição uma série de componentes reusáveis, independentes de sistema operacional, quefornecem mecanismos de entrada e saída de dados e gerenciamento de conexões (SCHMIDT,2002).

A camada de distribuição esconde todos mecanismos de gerenciamento de conexõese entrada e saída de dados para oferecer abstrações de alto nível como filas de mensagens eobjetos remotos. Utilizando essas abstrações é possível desenvolver aplicações distribuídasque funcionam de forma similar a aplicações monolíticas, que são executadas sobre um únicoprocesso (SADJADI; MCKINLEY, 2003).

A camada de serviços comuns reside sobre a camada de distribuição, oferecendo funcio-nalidades ligadas a requisitos não funcionais da aplicação, como tolerância a falhas, qualidadede serviço, logging, persistência, segurança e transações. Enquanto a camada de distribuição sepreocupa com particularidades do modelo de programação, a camada de serviços específicosrealiza a gerência de vários recursos distribuídos entre vários processos, tendo uma visão dotodo. Os serviços oferecidos nesta camada podem ser reusados em diferentes tipos de aplicações,independentemente de seu domínio.

Os serviços específicos tratam de funcionalidades voltadas a um determinado domínio,voltados a requisitos funcionais e não funcionais. Entre os serviços específicos utilizados emmiddleware temos o controle de transações financeiras, controles de aviação (radar, navegação,controle de armamento), entre outros (SCHMIDT, 2002).

2.2.1.1 Middleware Orientado a Objetos

Middleware Orientado a Objetos (MOO) é utilizado para comunicação cliente-servidorque utiliza objetos como principal abstração. Existem várias tecnologias de MOO, como CORBA,RMI, EJB, DCOM (EMMERICH; KAVEH, 2002). Embora esta tecnologia seja aplicável emmuitos domínios distintos, é comum encontrá-la em aplicações cliente-servidor multi-camadas,como pode ser observado na figura 2.4. Aplicações multi-camada utilizam comunicação síncrona


Figura 2.4: Arquitetura de aplicação multi-camadas

(request-reply) entre camadas, com suporte a serviços intermediários tais como balanceamentode carga, segurança e gerenciamento de transações GORTON (2011).

O cliente manipula objetos localmente em sua aplicação quando, de fato, este objeto estálocalizado no lado servidor. O objeto do lado do cliente é um Proxy, um objeto que não contémnenhuma lógica de domínio, que delega todas as invocações de métodos executadas no clientepara o objeto localizado no servidor. Este objeto se chama Remote Object, um objeto que possuilógica de domínio, pode possuir estado e tem seu ciclo de vida controlado pelo servidor.

Um Proxy delega requisições de cliente a um componente conhecido como Requestor.Este transforma a requisição de um cliente em uma mensagem, que é encapsulada e delegada aum componente chamado Client Request Handler. Este componente, por sua vez, se encarregade entregar a mensagem ao servidor utilizando mecanismos de rede. De forma similar, no ladoservidor, um componente chamado Server Request Handler recebe uma mensagem e entrega amesma ao Invoker, que a desencapsula, obtém a instância do Remote Object, e faz uma chamadade método local a este objeto. Os componentes chamados Marshallers são responsáveis porcodificar as mensagens para um stream de bytes e decodificar este stream de bytes em umamensagem, que será entregue entre do cliente para o servidor e vice-versa. Este processo podeser observado com a figura 2.5 (VÖLTER; KIRCHER; ZDUN, 2005).

O conjunto formado pelo Requestor, Invoker, Client Request Handler e Server Request

Handler são componentes básicos de uma estrutura maior, chamada de Broker. Além dacomunicação propriamente dita, o Broker também está encarregado de gerenciar o ciclo de vidados objetos e fornecer ganchos para as chamadas dos serviços específicos e de domínio.


Figura 2.5: Invocação de método remoto em um middleware orientado a objetos

2.2.1.2 Gerenciamento de Ciclo de Vida

Um Remote Object funciona de forma similar a um objeto comum em uma linguagemorientada a objetos, com suporte à composição, delegação herança, polimorfismo e outrascaracterísticas. O que diferencia Remote Objects de objetos locais é que o estado destes, porconta da dinâmica da comunicação entre cliente e servidor, precisa ser gerenciado pelo Broker.Em um ambiente de uma linguagem orientada a objetos, podem ser utilizados mecanismos dealocação de memória manual ou um garbage collector, que retira da memória objetos que nãoestão sendo utilizados. Em uma aplicação cliente-servidor, podem haver milhares de clientes eRemote Objects. Contudo, um cliente pode ser desconectado por conta de uma falha interna narede. O Broker, no entanto, não pode simplesmente descartar o objeto por conta de uma quedade conexão, pois o cliente poderia tentar se reconectar e continuar a operação de negócio queestava realizando antes. Ao mesmo tempo, a parte servidor do Broker não pode manter o objetona memória indefinidamente, pois isso poderia provocar o esgotamento de recursos do sistemaoperacional e consequentemente na queda do servidor.

Por esse motivo, Remote Object s são classificados de três formas diferentes, como Static

Instances, Per-Request Instances e Client-Dependent Instances (VÖLTER; KIRCHER; ZDUN,2005). Static Instances, são objetos que preservam seu estado independentemente do clienteque os consulta e sua memória é preservada durante toda a existência do Broker. Esta estratégiaé útil quando a vida deste objeto está ligada diretamente a existência de um dispositivo físicoou processo. No entanto, a existência de muitas Static Instances podem levar ao esgotamento


de memória do sistema operacional. Um outro problema relacionado a Static Instances é queestes devem manter seu estado consistente mesmo após inúmeras chamadas remotas de diversosclientes, levando a problemas de concorrência.

Uma forma de evitar totalmente os problemas de concorrência e esgotamento de memóriade Static Instances, é não preservar nenhum estado no Remote Object. Per-Request Instances sãoobjetos que são criados no escopo de uma chamada remota de método. Dessa forma, esses Per-

Request Instances podem ser acessados livremente sem problemas de concorrência, consistênciaou esgotamento de memória. A desvantagem de sua utilização é que pode existir a necessidadede guardar estado dentro da aplicação, tornando esta estratégia inútil para esta finalidade.

Uma terceira classificação representa o meio termo entre o uso de Static Instances ePer-Request Instances. Client-Dependent Instances representam objetos que existem pelo tempode vida de um cliente. Estes objetos são criados quando um cliente inicia uma conexão com aaplicação e destruídos quando essa conexão é terminada. Client-Dependent Instances reduzem osproblemas de concorrência se comparados a um Static Instances, pois este objeto será acessadopor um único cliente. As desvantagens dessa abordagem é que se existirem centenas de clientes,centenas de Client-Dependent Instances serão criados. O Broker também não pode certezaabsoluta de quando uma conexão é terminada, pois esta pode ser resultado de uma falha decomunicação na rede e não de uma desconexão. Um outro problema é que Client-Dependent

Instances não estão totalmente imunes a problemas de concorrência, pois uma aplicação podeser acessada por múltiplas interfaces utilizando uma mesma conexão.

Além das estratégias básicas, o Broker pode utilizar diferentes mecanismos de gerencia-mento de recursos dependendo da estratégia de ciclo de vida utilizada. O primeiro mecanismoLazy Acquisition (VÖLTER; KIRCHER; ZDUN, 2005) se refere em adiar a criação de umRemote Object apenas quando uma chamada para este é realizada. Esse mecanismo faz com queo estado de um Remote Object somente seja alocado na memória quando este for realmente serutilizado. Este padrão é útil para todas as estratégias de ciclo de vida de objetos.

Um segundo mecanismo de gerenciamento de recursos é o uso de Pooling (VÖLTER;KIRCHER; ZDUN, 2005), ou a criação de um pool de objetos que podem ser reutilizados. Estemecanismo evita o overhead causado pela criação e destruição de um objeto remoto, otimizandoa utilização de recursos do sistema operacional. Pooling é melhor utilizado para objetos quenão possuem identidade ou estado e são tratados de forma igual, como é o caso de Per-Request

Instances. Pooling pode também ser utilizado para objetos com estado, desde que este sejaalocado dinamicamente pelo Broker.

O terceiro mecanismo de gerenciamento de recursos se chama Leasing (VÖLTER;KIRCHER; ZDUN, 2005) e consiste em atribuir um tempo de expiração para a alocação de umRemote Object em memória. Caso esse objeto não seja acessado durante o tempo de expiração,o mesmo é destruído. Este recurso é essencial quando se usa a estratégia Client-Dependent

Instance, eliminando objetos alocados por um cliente quando estes não estão sendo utilizados.O último mecanismo de gerenciamento de recursos é chamado de Passivation (VÖLTER;


KIRCHER; ZDUN, 2005) e consiste no armazenamento permanente de um objeto seguido dadesalocação do estado da memória. Este recurso é útil ao utilizar uma Static Instance, paraliberar a utilização de memória nos casos desses objetos estarem sendo pouco acessados.

A Tabela 2.1 mostra a relação entre as três classificações de Remote Objectse os meca-nismos de ciclo de vida que podem ser utilizados por cada um:

Tabela 2.1: Relações entre classes de Remote Objectse mecanismos de gerenciamento derecursos

Static Instance Per-Request Intance Client-Dependent InstanceLazy Acquistion útil implicitamente útil implicitamente útilPooling inútil muito útil pouco útilLeasing pouco útil inútil muito útilPassivation pouco útil inútil muito útil

O Broker utiliza um componente específico para lidar com o gerenciamento de ciclo devida, chamado Lifecycle Manager (VÖLTER; KIRCHER; ZDUN, 2005). Este componente éresponsável por criar e gerenciar Remote Objectse utilizar, de acordo com a sua categoria, osmecanismos de gerenciamento de recurso adequados. Adicionalmente, o Lifecycle Manager

pode prover uma série de callbacks para que a aplicação execute ações específicas durantealgumas etapas do ciclo de vida.

2.2.1.3 Serviços comuns

Um middleware DOC dispõe de vários serviços que podem ser utilizados para tratar derequisitos de qualidade, como transparência de localização, tolerância à falhas e monitoramentode qualidade de serviço. Três padrões de projeto podem ser usados com essa finalidade, Lookup

e Location Forwarding e QOS Observer.Uma das vantagens principais de middlewares DOC é a transparência de localização,

onde um cliente pode acessar um Remote Object sem definir exatamente a localização. O serviçode Lookup é usado justamente para esta finalidade: ele utiliza uma estrutura de dados que é usadapara armazenar a localização de objetos em diferentes servidores. Cada Remote Object possui umidentificador lógico único no middleware, este chamado de Absolute Object Reference (AOR),que é vinculado a dados de localização pelo serviço de Lookup. A partir desse identificador, oserviço de Proxy consegue descobrir a localização exata de um Remote Object em uma rede.Sem esse identificador lógico, o cliente precisaria informar dados de localização daquele objeto,como IP e porta (como na pilha de protocolos TCP/IP) (VÖLTER; KIRCHER; ZDUN, 2005).

O Serviço de Lookup possui pelo menos três primitivas, como pode ser visto na Listagem2.1:

Listagem 2.1: Interface de Serviço de Lookup

p u b l i c i n t e r f a c e Lookup {


void r e g i s t e r ( A b s o l u t e O b j e c t R e f e r e n c e aor ,E n d p o i n t e n d p o i n t ) ;

void u n r e g i s t e r ( A b s o l u t e O b j e c t R e f e r e n c e a o r ) ;E n d p o i n t f i n d ( A b s o l u t e O b j e c t R e f e r e n c e a o r ) ;

}

A primeira primitiva, chamada register, é utilizada para vincular um AOR a um endereçode rede, chamado endpoint, que representa a localização física do objeto na rede. A segunda,unregister é utilizada para retirar um AOR do serviço de Lookup. A primitiva find consistena utilização de uma AOR para obter a localização física (endpoint) de um objeto remoto.Obtendo essa informação é possível construir um Proxy que faça referência a um Remote Object

correspondente (BUSCHMANN; HENNEY; SCHMIDT, 2007).Será necessário para o cliente a localização física do serviço de Lookup. O processo de

obtenção dessa localização é chamado de bootstrapping. O bootstrapping pode ser resolvido devárias formas, seja fornecendo manualmente as informações de localização ou mais elaborada,através de um broadcast (KIRCHER; JAIN, 2004).

Além da transparência de localização, é importante garantir que um Remote Object

esteja sempre disponível mesmo que um processo servidor falhe temporariamente. Isso pode serrealizado a partir da utilização de várias réplicas do mesmo objeto em diferentes servidores. Estaestratégia é útil não somente para evitar a indisponibilidade, mas também para distribuir a cargade requisições de maneira eficiente entre todas as réplicas.

O padrão de projeto Location Forwarder (VÖLTER; KIRCHER; ZDUN, 2005) podeser utilizado para esta finalidade. Este pode ser concebido como um protocolo onde o clienterecebe uma mensagem de redirecionamento e procura a nova réplica de objeto remoto, ou comoum componente que se encarrega de enviar requisições para a réplica adequada, agindo comoum intermediário entre o cliente e o objeto remoto. A vantagem da primeira abordagem é adescentralização dos mecanismos de redirecionamento. A desvantagem é que a concepção deum protocolo de redirecionamento pode ser complexo, e o middleware não possui controle totalda distribuição de carga entre as várias réplicas. A segunda abordagem, de se utilizar o Location

Forwarder como um componente, é a possibilidade de se utilizar várias abordagens complexasde balanceamento de carga; a desvantagem desta abordagem é presença de um ponto único defalha, em caso de indisponibilidade deste componente.

Além do mecanismo de redirecionamento de requisições, pode ser usado um protocolode gerenciamento de grupos para gerenciar todas as réplicas existentes de um Remote Object. Opadrão de projeto Object Group (MAFFEIS et al., 1996) é utilizado para esta finalidade: estedefine um protocolo onde um Broker pode registrar uma réplica específica em um grupo. OObject Group substitui um AOR de um Remote Object em um serviço de Lookup: ao invés delocalizar cada objeto individualmente, o serviço de Proxy passa a registrar a referência de um


grupo. Requisições destinadas a este Object Group são redirecionada a algum dos membrosregistrados ou a todos. Um componente de Location Forwarding poderia ser utilizado nesseaspecto, provendo mecanismos eficientes de balanceamento de carga.

O protocolo utilizado por um Object Group é dividido em gerenciamento de membros,gerenciamento de view e compartilhamento de estado. O gerenciamento de grupos é realizado apartir das primitivas create_group, destroy_group, join e leave, que permitem, respectivamente,a criação de um Object Group, sua destruição, a entrada de um membro e a saída deste.

Uma view é uma representação do estado atual de um Object Group, e contém umareferência para cada membro. Quando um novo membro se junta ou deixa um Object Group,todos os membros existentes recebem uma nova view, indicando quais são os participantes. Cadamembro da view é identificada de forma única, e este recurso de identidade pode ser utilizadopara selecionar um coordenador do Object Group.

As primitivas get_state e set_state são utilizadas para compartilhar o estado de um Remote

Object entre todos os membros de um Object Group. A primitiva get_state é utilizado por umdos membros do Object Group para compartilhar o estado atual do objeto. A primitiva set_state éutilizada para os novos membros do grupo, que obterão o estado atual das réplicas. As primitivasde compartilhamento de estados são particularmente úteis para efetuar a migração de um Remote

Object de uma localização para outra.A Listagem 2.2 ilustra as primitivas de comunicação de um Object Group agrupadas em

uma interface de uma linguagem oritentada a objeto:

Listagem 2.2: Primitivas de comunicação do padrão Object Group

c l a s s GroupBOA : v i r t u a l p u b l i c BOA {

s t a t i c vo id c r e a t e _ g r o u p ( O b j e c t _ p t r group ,c o n s t P r o t o c o l P o l i c y& p o l i c y= d e f a u l t _ p o t o c o l _ p o l i c y ) ;

void j o i n ( O b j e c t _ p t r group ) ;void l e a v e ( O b j e c t _ p t r group ) ;s t a t i c vo id d e s t r o y _ g r o u p ( O b j e c t _ p t r group ) ;

v i r t u a l vo id g e t _ s t a t e ( AnySeq& s t a t e ,Boolean& done ) ;

v i r t u a l vo id s e t _ s t a t e ( c o n s t AnySeq& s t a t e ,Boolean& done ) ;

v i r t u a l vo id view_change ( c o n s t View& newView ) ;

}

A qualidade de serviço apresentada por um middleware orientado a objetos deve ser


Figura 2.6: Relacionamento entre padrões de projeto para serviços comuns de ummiddleware DOC

monitorada. Entre os itens que podem ser monitorados estão o Server Request Handler, oInvoker e cada Remote Object individualmente. O padrão de projeto QOS Observer (VÖLTER;KIRCHER; ZDUN, 2005) é usado justamente para esta finalidade, coletar métricas específicasde cada componente do middleware orientado a objetos.

Para que o QOS Observer seja utilizado corretamente, o desenvolvedor do middlewaredeve prover um gancho específico para cada componente a ser medido. Este gancho devefuncionar de forma semelhante àquela encontrada no padrão de projeto Observer (GAMMAet al., 1993), onde é criado um Subject para cada gancho, que por sua vez registra vários QOS

Observers. Quando acontece uma mudança de estado no Subject, este envia uma notificaçãoa todos os QOS Observers registrados. Cada QOS Observer , por sua vez, consulta o estadodo Subject e coleta uma série de métricas, como tamanho da mensagem, tempo de execução equantidade de invocações (VÖLTER; KIRCHER; ZDUN, 2005).

A figura 2.6 ilustra os serviços comuns abordados nesta seção, e seu relacionamento.Verificamos que o serviço de Proxy pode registrar uma referencia a um Object Group e estepode usar um Location Forwarder para distribuir requisições entre várias réplicas de um mesmoRemote Object . Também observamos quais componentes de um middleware DOC podem sermonitorados por QOS Observers.


2.2.2 Arquitetura e Padrões de Projeto para Computação em Nuvem

Aplicações desenvolvidas para o ambiente de computação em nuvem possuem diferençasarquiteturais fundamentais. Elas são particionadas e executadas em vários nós, ao invés de umúnico grande máquina física. Devem ser possível adicionar ou remover recursos computacionaiscom facilidade e continuar funcionando corretamente quando este fato acontece. Utilizam comu-nicação assíncrona e uma arquitetura fracamente acoplada. São constantemente monitoradasmesmo quando nós são descartados.

Conceitualmente, um nó representa uma unidade lógica de um sistema, que possuirecursos de hardware. A lógica de aplicações é executada em nós computacionais e seus dadosarmazenados em nós de dados. Um nó pode ser representado por uma máquina física, umamáquina virtual ou um cluster de várias máquinas. Em nuvens IaaS, nós representam máquinasvirtuais (WILDER, 2012).

Um dos requisitos não funcionais que aplicações em ambiente de nuvem necessitam éescalabilidade, que pode ser dividida em dois tipos não mutuamente exclusivos: escalabilidadevertical ou escalabilidade horizontal. A escalabilidade vertical trata do aumento da capacidade denós existentes, enquanto a horizontal se refere a adição de novos nós à infraestrutura da aplicação.Escalabilidade é tanto uma necessidade de aplicações transacionais, que lidam com acessos demilhares de usuários simultaneamente, mas também de aplicações analíticas que precisam lidarcom grandes volumes de dados em tempo real (REESE, 2009).

Uma das vantagens de um ambiente de nuvem é a ilusão de escalabilidade infinitadecorrente da elasticidade, sobretudo em nuvens públicas. No entanto, não é possível tirarproveito desta escalabilidade se a arquitetura da aplicação não é inerentemente escalável (VARIA,2010). A contenção de recursos em uma aplicação pode limitar a sua capacidade de alcançar aescalabilidade, gerando gargalos em pontos específicos como acesso a dados ou conexão de rede(WILDER, 2012).

A arquitetura de aplicação nativa de nuvem também deve ser projetada para lidar comfalhas. Uma máquina virtual pode se tornar indisponível após receber uma grande carga deacessos, os dados armazenados em um nó podem ser perdidos, o balanceador de carga podefalhar, um mestre numa configuração mestre-escravo pode falhar. A melhor maneira de lidarcom falhas de infraestrutura é tornar a próprio software resiliente (VARIA, 2010).

A tabela 2.2 exibe uma série de cenários onde a falha em um nó pode ocasionar na falhada aplicação. A falha em um nó pode ser causada por um problema de hardware (infraestru-tura física), alguma operação interna do provedor ou alguma solicitação do administrador daaplicação.

A melhor estratégia para lidar com este cenário é assumir sempre o pior caso, onde onó será perdido e os dados locais também. Se um único nó pode falhar, devem haver diversasréplicas redundantes de um mesmo nó. Este também não poderá armazenar dados localmente. Aaplicação não deve parar de funcionar por conta da falha de um nó. Caso exista a necessidade de


Tabela 2.2: Cenários possíveis para falha de um nó e o impacto causado (WILDER,2012)

Cenário Iniciado Por AlertaPrévio

ImpactoFalha súbita +reinicialização Falha súbita de hardware Não

Dados locais sãoperdidos

Desligamento de nó +reinicialização

Provedor de nuvem (substituição dehardware, atualização de software) Sim

Dados locais podemestar disponíveis

Desligamento de nó +reinicialização

Aplicação (atualização, bug ereinicialização gerenciada) Sim

Dados locaisestão disponíveis

Desligamento de nó +terminação Aplicação (destruição de um nó) Sim

Dados locaisestão perdidos

manter estado na aplicação, este estado deve ser compartilhado com os outros nós, através dautilização de um serviço de armazenamento compartilhado (WILDER, 2012).

Deve ser possível iniciar aplicações em nuvem com o mínimo de esforço, automatizandoo processo de iniciação e implantação. Isso pode ser realizado através da criação de imagens ede scripts de inicialização. Deve ser realizado monitoramento constante dos recursos utilizadospela aplicação, a fim de obter métricas que representem a qualidade de serviço da aplicação.Por fim, é necessário definir uma estratégia para automatizar a inicialização de novos nós daaplicação seja com base em carga de trabalho, sazonalidade ou algum outro fator influenciadopela qualidade de serviço (VARIA, 2010) (WILDER, 2012) (BALIGA et al., 2011) (MARSTONet al., 2011).

2.2.2.1 Padrões de projeto para computação em nuvem

No trabalho desenvolvido por HOMER et al. (2014), podemos identificar vários padrõesde projeto que são relevantes para o desenvolvimento de aplicações em nuvem. Serão citadosaqueles que foram utilizados na arquitetura proposta por este trabalho.

A partir dos princípios arquiteturais vistos anteriormente, é possível destacar que aplica-ções executadas em ambiente de nuvem precisam ser particionadas e ter tarefas divididas entrevários nós. No entanto, às vezes é preciso que uma tarefa seja executada unicamente em todaa aplicação distribuída. Para realizar este tipo de operação é necessário coordenar as váriasréplicas para que apenas uma seja capaz de executar a tarefa em questão. O padrão de projetoLeader Election (HOMER et al., 2014) é usado para esta finalidade. É escolhido um líder entreos vários processos existentes e este líder é responsável por executar aquela tarefa entre todosos nós existentes. O líder pode ser um processo fixo ou pode ser utilizado um mecanismo desincronização – como um lock distribuído.

Existe a necessidade de monitorar a saúde de todos os nós de uma aplicação de nuvem,para saber se cada um está operando corretamente, visando garantir a disponibilidade da aplicação.O padrão de projeto Health Endpoint Monitoring (HOMER et al., 2014) consiste na utilização dechecagens funcionais para os vários nós da aplicação e receber uma indicação de funcionamento

2.3. CLOUD AWARE MIDDLEWARE 41

correto. Existem várias formas de realizar esta checagem, seja utilizando códigos de status ouexaminando o conteúdo de respostas para analisar se foi recebida a resposta correta.

Deve haver cuidado em como o monitoramento da aplicação pode ser realizado. Se oagente de monitoramento realizar checagens muito frequentes, poderá comprometer o funcio-namento da aplicação. O próprio agente de monitoramento pode estar com prolemas, logo, éimportante que este faça checagens em seus próprios módulos. esporadicamente.

Como falhas são inerentes a uma aplicação em um ambiente computação em nuvem,ao utilizar um serviço, este pode apresentar uma falha total ou temporária. Os padrões deprojeto Retry e Circuit Breaker (HOMER et al., 2014) consistem, respectivamente: em ummecanismo para evitar falhas temporárias de serviço através da utilização de um mecanismoonde a requisição realizada pelo cliente é tentada novamente; na utilização de condições queevitam a comunicação com um serviço que está aparentemente em mal funcionamento. Ospadrões funcionam de forma complementar, onde o Circuit Breaker evita que a ocorrência deum Retry em um serviço que está aparentemente desabilitado.

2.3 Cloud Aware Middleware

O Cloud-Aware Middleware (CaMid) MORAIS; LIBERALQUINO; ROSA (2013) é umtrabalho de pesquisa desenvolvido pelo grupo Research Group on Foundations and Applications

of Distributed Systems (GFADS) com a finalidade de desenvolver um middleware orientado aobjetos que possui mecanismos de gerenciamento de nuvem que funcionassem de forma automá-tica e transparente a uma aplicação. O trabalho desenvolvido por MORAIS; LIBERALQUINO;ROSA (2013) apresenta as seguintes contribuições: uma arquitetura de middleware baseada emcamadas de middleware consolidada na literatura (SCHMIDT, 2002); utilizar os serviços denuvem para aprimorar os mecanismos de distribuição (transparência de localização e acesso,modelo de comunicação); integrar as várias camadas de nuvem verticalmente, como uma camadaortogonal a IaaS, PaaS e SaaS; tornar o gerenciamento da nuvem transparente, como parte dosmecanimsos de distribuição.

Os princípios que guiam a arquitetura do CaMid são: cloud-awareness ou ciência denuvem, a capacidade de monitorar e controlar os recursos disponíveis da aplicação de formatransparente, incluindo virtualização, elasticidade e outros; gerenciamento automático, queé a capacidade de manipular recursos sem intervenção humana direta; suporte a aplicaçõescliente-servidor multi-camada; transparência de localização e acesso; arquitetura baseada empadrões de projeto consolidados (MORAIS; LIBERALQUINO; ROSA, 2013). A arquiteturado CaMid é divida em três camadas, e serve como um dos componentes de um PaaS , em umambiente de aplicação em nuvem, como pode ser observado na figura 2.7.


Figura 2.7: Arquitetura em camadas do CaMid, em uma pilha de serviços de nuvem(MORAIS; LIBERALQUINO; ROSA, 2013)

O CaMid implementa a arquitetura de um middleware DOC. A camada de infraestruturado CaMid serve como uma interface para as APIs de programação em rede do sistema operacionalde uma máquina virtual. Ela é composta de dois componentes principais, o Client Request

Handler e um Server Request Handler , que encapsulam mecanismos de comunicação, como oestabelecimento de conexões de rede e transmissão de dados. A camada de distribuição provêtransparência de acesso à aplicação, fornecendo uma abstração de middleware orientado a objeto,utilizando os componentes Proxy, Requestor, Invoker, Remote Object e Marhsaller. Na camadade serviços o CaMid provê uma série de serviços reusáveis que são utilizados para aprimoraro gerenciamento do sistema como um todo. Seus serviços estão divididos em duas categorias,serviço de nomes e serviço de gerenciamento. O serviço de nomes implementa o padrão deprojeto Lookup, enquanto o serviço de gerenciamento é utilizado para promover a ciência denuvem.

Os serviços de gerenciamento providos pelo CaMid foram divididos de acordo com seucontexto. O contexto local consiste em operações locais, requisições, migração de serviçose desempenho. O contexto global inclui todos os nós de um sistema, incluindo aplicações erecursos de infraestrutura. Neste contexto, o serviço de gerenciamento, utilizando a API degerenciamento de nuvem, nomeada como o componente IaaS Manager, monitora todos osrecursos da nuvem, como o número de VMs ativas, sua localização e o desempenho da redevirtual. Dados coletados dos contextos locais e globais são identificados por uma chave, que écomposta de um Universally Unique Identifier (UUID), informação de contexto, tipo de recurso,id do recurso e localização.

A quantidade de informações obtidas do IaaS Manager depende do provedor. Algunsfornecem informação completa, como máquina virtual, localização na estrutura física, enquantooutros limitam as informações fornecidas, como é o caso de informações de hardware emprovedores de nuvem pública.

A figura 2.8 representa os componentes de gerenciamento do CaMid e sua interação comas demais camadas. São dois componentes principais de gerenciamento, o Local Manager, para


Figura 2.8: Arquitetura dos serviços de gerenciamento do CaMid

o contexto local e o Global Manager no contexto global. O Local Manager é subdividido emdois outros componentes, o Local Monitor, que monitora os recursos de qualidade da aplicação eo Local Controller que gerencia os recursos internos do nó, como o número de threads ativase objetos remotos. O Local Manager notifica o Global Manager periodicamente, fornecendoinformações locais como métricas de desempenho dos componentes de distribuição e objetosremotos, uso de CPU do sistema virtualizado, entre outros. O Global Manager interage com oIaaS Manager para obter informações adicionais da infraestrutura de nuvem, envia instruçõespara os Local Managers e podem atualizar informações no contexto de Local Managers.

2.3.1 Local Manager

A figura 2.9 ilustra os componentes do Local Manager, que consistem no Monitoring

Information Service (MIS) , os Observers e o Local Controller. Os Observers são uma realizaçãodo padrão de projeto QOS Observer, e é utilizado para coletar informações de qualidade doscomponentes da camada de infraestrutura, camada de distribuição, objetos remotos e sistemaoperacional virtual. Estes podem ser divididos em System Observers, que coletam informaçõesdo sistema operacional, como CPU e memória. É utilizado também para informar inconsistênciasentre as leituras das apis do IaaS Manager. Os Handler Observers são responsáveis por monitoraras requisições, incluindo as métricas vazão e tempo de resposta de todo o middleware. Os Invoker

Observers coletam informações da camada de distribuição, mais precisamente do componenteInvoker. Por fim, os Remote Service Observers visam a coleta de métricas dos objetos remotos,como tempo de resposta. O MIS coleta informações dos Observers e registra essas informaçõesem tabelas internas, e usa os componentes da camada de distribuição para enviar e receberinformações ao Global Manager. O MIS e os Observers constituem o componente Local

2.4. CONSIDERAÇÕES FINAIS 44

Figura 2.9: Interação do Local Manager com demais camadas do CaMid (MORAIS;LIBERALQUINO; ROSA, 2013)

Monitor.O Local Controller executa ações demandadas pelo Global Manager, incluindo a ini-

cialização de objetos remotos, atualização de informações do sistema (localização de nós edesalocação de recursos de IaaS .

2.3.2 Global Manager

A arquitetura do Global Manager é ilustrada na figura 2.10. O Global Manager éresponsável pelo monitoramento e controle do sistema como um todo. O IaaS Requestor

requisita informações da nuvem IaaS, como as máquinas virtuais existentes e informação demonitoramento de cada uma delas, como tamanho da memória, CPU, ferramenta de virtualizaçãoutilizada. Da mesma forma que os IaaS Requestors, os Global Managers recebem informaçõesde cada Local Manager específico. Nos dois casos, cada pedaço de informação é coletado porum Observer específico.

As informações dos dois componentes são consolidas no Information Processor, combi-nando as informações obtidas. Essas informações podem servir de insumo para ações que podemser acionadas através do Global Controller. É responsabilidade do Global Controller suportar aalocação e retirada de máquinas virtuais, replicação dos objetos remotos em novas instâncias demáquinas virtuais e balanceamento de carga.

2.4 Considerações Finais

Neste capítulo, foi apresentado o conceito de computação em nuvem, quais suas vanta-gens a respeito de infraestruturas tradicionais e suas características. Foi realizada uma catego-


Figura 2.10: Interação do Global Manager com demais camadas do CaMid (MORAIS;LIBERALQUINO; ROSA, 2013)

rização de cada modelo de oferta de serviço de computação em nuvem – SaaS, PaaS e IaaS –observando as vantagens e desvantagens de cada um e como estes modelos se relacionam.

Foi realizada uma revisão dos conceitos de middleware, qual a sua definição e quaismodelos de comunicação possíveis, ilustrando uma arquitetura que compreende suas camadasprincipais – infraestrutura, distribuição, serviços comuns e serviços específicos. O modelo demiddleware orientado a objetos (ou middleware DOC) foi analisado e foram descritos os seuscomponentes principais através de padrões de projeto documentados na literatura, incluindopadrões relativos a gerenciamento de ciclo de vidas de objetos remotos serviços comuns. Ob-servamos algumas caracterísiticas fundamentais de aplicações desenvolvidas para computaçãoem nuvem, onde foi citada a necessidade de utilizar uma arquitetura tolerante a falhas, tornar aaplicação fácil de implantar e utilizar scripts de automação baseados em sazonalidade.

Por fim, foram introduzidos os princípios arquiteturais do CaMid, os padrões de projetoque o apóiam e os seus componentes principais.

Estes tópicos formam os conceitos básicos necessários para entender a motivação e aproposta deste trabalho, e serão utilizadas para justificar as escolhas tomadas pelo desenvolvi-mento dos mecanismos de suporte a elasticidade do CaMid, que serão mencionados no próximocapítulo.

464646

3Proposta

Construir uma aplicação para nuvem, que possa tirar proveito da elasticidade não é umatarefa simples. A aplicação deve ser pensada para estar particionada em vários nós diferentes.Deve ser possível adicionar mais nós à infraestrutura facilmente e ter benefícios imediatos naescalabilidade do sistema. A aplicação deve continuar disponível mesmo quando um nó torna-seindisponível, seja esta devido a uma falha acidental ou devido ao desligamento manual solicitadopelo usuário de nuvem. Os vários componentes da aplicação também precisam coordenar suasatividades, saber como escalonar tarefas paralelas e possuir capacidade de se comunicar de formaassíncrona. Caso a aplicação precise manter estado, este deve ser compartilhado entre todos osnós, para evitar que a queda de um ocasione em indisponibilidade dos serviços oferecidos pelaaplicação. Esses são os princípios básicos que tornam uma aplicação adequada a um ambienteelástico de computação em nuvem.

A arquitetura do CaMid (MORAIS; LIBERALQUINO; ROSA, 2013) prevê o suporte àelasticidade, mas não menciona os componentes ou serviços que oferecem este suporte. Nestecapítulo vamos detalhar as extensões realizadas à arquitetura do CaMid para que este possa sebeneficiar das vantagens proporcionadas pela elasticidade. O CaMid, acrescido deste conjuntode extensões, será chamado de Elastic Cloud-Aware Middleware (eCaMid).

A próxima seção apresenta os princípios que guiaram o desenvolvimento do Elastic

Cloud-Aware Middleware (eCaMid). Em seguida iremos definir os requisitos necessários para osuporte à elasticidade. Será proposta uma arquitetura que utilize três mecanismos de suporteà elasticidade: comunicação em grupo, que trata da capacidade de gerenciar um grupo de nós,verificando quais desses nós são membros ativos do grupo, provendo meios eficientes de trocade mensagens entre eles e coordenando a execução de tarefas em um ambiente distribuído;replicação, a capacidade de criar nós redundantes que compartilham estado; e balanceamento decarga, que visa distribuir as requisições de uma aplicação entre as diversas réplicas, evitando asobrecarga de um nó único.

Serão detalhadas também as tecnologias utilizadas para a concepção dos mecanismos deelasticidade e de que forma o middleware pode ser implantado em uma infraestrutura de nuvem.

3.1. MOTIVAÇÃO E OBJETIVOS 47

3.1 Motivação e Objetivos

O CaMid (MORAIS; LIBERALQUINO; ROSA, 2013) é um middleware orientado aobjetos. Logo, seu modelo de programação é baseado em objetos remotos que são compostos poroutros objetos que se comunicam através de chamadas de método. Objetos podem ou não conterestado e caso possuam, este estado deve ser gerenciado pelo middleware, evitando que objetossejam armazenados indefinidamente na memória. Objetos e suas réplicas estarão distribuídosentre vários nós e as requisições realizadas pelos clientes podem ser balanceadas entre os nósexistentes. Deve ser possível ainda acessar o estado de cada objeto em todos os nós, evitandoque a falha de um no ocasione na indisponibilidade na aplicação.

A primeira implementação do CaMid (MORAIS; LIBERALQUINO; ROSA, 2013)introduziu vários componentes importantes: Naming Service, Global Manager, Local Manager eas camadas de comunicação e distribuição. O Naming Service e Global Manager, particularmente,são componente centrais do CaMid, por isso, eles devem sempre estar replicados para evitar quealguma falha nestes ocasione na parada completa do middleware.

Os componentes de gerenciamento do CaMid, Global Manager e Local Manager co-letam informações do ambiente através de Observers, mas a comunicação entre processos domiddleware ainda acontece através de chamadas de método remotas. O CaMid deveria interme-diar a comunicação entre Subjects (objetos que são monitorados e geram eventos) e Observers,provendo um estilo de comunicação assíncrono, através da troca de mensagens. Deve ser pos-sível enviar mensagens de um componente localizado em um nó a outro presente em outronó, utilizando um estilo de comunicação Publish/Subscribe. Publishers publicam mensagensatravés de uma fila, enquanto os Subscribers tratam essas mensagens. Este estilo de comunicaçãotambém pode ser utilizado pela aplicação, que pode combinar o estilo de troca de mensagenscom à chamada de métodos de objetos remotos.

Os componentes de gerenciamento do CaMid também precisam executar tarefas emintervalos periódicos. Os System Observers, componentes do Local Manager no CaMid res-ponsáveis por captar informações de utilização de CPU e memória, dependem de agentes queobtêm informações periodicamente do sistema operacional. Os Observers do Global Manager

também dependem de agentes que obtém informações do IaaS Requestor periodicamente. Estescomponentes estarão dispersos em vários nós, portanto as tarefas desempenhadas por estesagentes devem ser coordenadas. Essas tarefas podem ser executadas localmente em cada nó,ou devem ser executadas uma vez para um grupo de nós. As aplicações também devem poderutilizar este recurso, implementando seus próprios agentes.

Estes mecanismos do CaMid precisam ser aprimorados para tomar vantagem da elas-ticidade. No capítulo anterior, foram citadas algumas características fundamentais que umaaplicação distribuída precisa ter para que tome vantagem do paradigma de computação em nuvem:particionamento em múltiplos nós; capacidade de adicionar ou remover nós dinamicamente;preservação do comportamento da aplicação em caso de falha de um nó; modelo de comunicação

3.2. REQUISITOS 48

escalável e fracamente acoplado sem contenção de recursos.Por isso, o eCaMid estende a arquitetura original, visando cumprir os seguintes objetivos:

� Aprimorar os mecanismos de coordenação entre os nós existentes, sabendo quaisobjetos foram publicados em cada nó e quando um nó está ativo ou inativo.

� Realizar balanceamento de carga entre os nós, de forma que um único nó não sejasobrecarregado.

� Preservar o estado de objetos entre os nós, mesmo em decorrência de falha dosmesmos.

� Utilizar mecanismos de comunicação entre os componentes do middleware que sejaassíncrono e funcione independentemente da dimensão atual da infraestrutura domiddleware.

� Agendar e distribuir tarefas periódicas entre os vários nós distintos, independentes desua dimensão.

3.2 Requisitos

A partir dos objetivos mencionados na seção anterior, foram identificados os seguintesrequisitos para o eCaMid:

� Gerenciar réplicas de nós: O eCaMid poderá adicionar vários nós à sua infraestru-tura, onde existem várias réplicas de um mesmo nó. Cada réplica será identificadaindividualmente e monitorada, para saber que réplicas estão ativas em um dadoinstante;

� Gerenciar estado de objetos remotos: o estado dos objetos remotos será compar-tilhado entre vários nós. O eCaMid deve prover um serviço que permita acessar oestado a partir de qualquer nó;

� Gerenciar ciclo de vida de objetos: objetos com estado devem ser gerenciados pelomiddleware. As estratégias de gerenciamento de ciclo de vida devem levar em contaa distribuição do objeto em diferentes nós;

� Efetuar comunicação Publish/Subscribe: componentes e objetos do eCaMid pode-rão trocar mensagens, onde emissores publicam mensagens que são recebidas pelosreceptores interessados;

� Escalonar tarefas: Agentes podem ser usados para implementar ações periódicas,que podem ser executadas para cada nó existente do middleware ou para todos osnós; e

3.3. MODELO DE DOMÍNIO GERAL 49

� Realizar balanceamento de carga: requisições encaminhadas para objetos remotosdevem ser distribuídas entre todos os nós existentes.

É possível identificar quatro atores que interagem com o eCaMid, a aplicação cliente,a aplicação servidor, o provedor de nuvem e uma ou mais máquinas virtuais. A aplicaçãocliente, que será mencionada apenas como cliente. O cliente conhece as interfaces dos objetospublicados na parte servidor do eCaMid e realiza requisições remotas para esses objetos. Aaplicação servidor define os objetos remotos, subscribers e tarefas que serão gerenciados peloeCaMid. O Provedor de nuvem fornece uma API que é usada pelo componente Global Manager

para monitorar as máquinas virtuais existentes e os nós. As máquinas virtuais provêm o ambienteem que processos do eCaMid serão executados. Cada máquina virtual identificada pelo provedorde nuvem deverá possuir pelo menos um endereço de rede.

Três tipos possíveis de Stakeholders poderão utilizar o eCaMid, desenvolvedores deaplicações, de middleware e provedores de nuvem. Desenvolvedores de aplicações distribuídasutilizarão o modelo de programação oferecido pelo middleware para desenvolver soluções es-pecíficas para o ambiente de computação em nuvem. Desenvolvedores de middleware poderãomanter, atualizar as funcionalidades fornecidas pelo eCaMid e propor novas estensões. Provedo-res de nuvem poderão utilizar o eCaMid como blocos básicos para a criação de serviços de PaaSsobre uma infraestrutura de IaaS.

O eCaMid também apresenta os seguintes requisitos não funcionais:

� Independência de provedor de Infraestrutura de Nuvem: Os serviços funcionaisdo eCaMid que suportam a elasticidade não devem depender de serviços fornecidospor um provedor específico, seja este um provedor público ou privado;

� Desempenho: O eCaMid deve fazer uso de todas as máquinas virtuais fornecidaspelo provedor de nuvem com eficiência. O uso dos mecanismos de suporte à elastici-dade do middleware devem utilizar os recursos da nuvem de forma mais eficiente;

� Estrutura baseada em padrões de projeto: As soluções implementadas peloeCaMid devem fazer uso de vários padrões arquiteturais e de projeto presentes na lite-ratura para resolver problemas já conhecidos, de forma a minimizar as complexidadesacidentais que são próprias de sistemas distribuídos.

3.3 Modelo de domínio geral

Nas duas últimas seções, pudemos identificar os objetivos e requisitos do middleware. Noentanto, para facilitar a compreensão da arquitetura do eCaMid, podemos ilustrar os elementosque compõem o domínio do problema que o middleware pretende resolver, assim como osrelacionamentos entre esses elementos. A figura 3.1 ilustra o modelo inicial deste domínio, queserá explicado a seguir.

3.3. MODELO DE DOMÍNIO GERAL 50

Figura 3.1: Elementos básicos do modelo de domínio do eCaMid

O Provedor de Nuvem fornece uma API para gerência dos serviços de nuvem e umconjunto de Máquinas Virtuais. As Máquinas Virtuais são identificadas unicamente para oprovedor de nuvem, e possuem um endereço IP único que pode ser alcançado pelo cliente. Umprocesso do eCaMid que é executado sobre uma máquina virtual é chamado de Nó. Vários nóscompõem um conjunto chamado de Cluster, que por sua vez monitora as máquinas virtuaisfornecidas pelo provedor de nuvem através de sua API. Cada nó é identificado de forma únicano cluster.

Uma Aplicação é um conjunto de vários Componentes agrupados em uma unidade espe-cífica. A aplicação é implantada em um cluster, que por sua vez gerencia todos os componentesda aplicação. Um componente é um objeto administrado pelo middleware, e pode ser realizadocomo: uma Tarefa que é executada periodicamente; um Observer que trata eventos oriundos daaplicação ou do próprio middleware; e um conjunto de Objetos Remotos. Todos os componentespodem possuir objetos remotos como dependência, mas o mesmo não é possível com as outrasduas especializações. Um nó é responsável por executar a representação física de um componenteem algum instante onde este está sendo utilizado. Um Cliente localiza objetos remotos atravésdo cluster ou do próprio nó, e utiliza a invocação de métodos remotos para fazer requisições aum objeto remoto.

Todos esses elementos, com exceção de Tarefa e Cluster já estavam presentes no mid-dleware original MORAIS; LIBERALQUINO; ROSA (2013). Os elementos definidos nestaseção constituem apenas os elementos mais básicos do modelo. Ao longo das próximas seções,novos elementos serão introduzidos ao modelo, ao passo que as funcionalidades do eCaMidserão detalhadas.

3.4. ARQUITETURA 51

3.4 Arquitetura

A Figura 3.2 representa os elementos que compõem o eCaMid. Da mesma forma que aimplementação inicial do CaMid, a arquitetura do eCaMid é dividida em três camadas: infra-estrutura, distribuição e serviços. Alguns novos componentes e serviços foram adicionados àarquitetura. Na camada de infraestrutura, foi adicionado o Group Communication Framework,Cluster Request Handler e Group Channel. Na camada de distribuição, foram adicionados oCluster Event Bus, Task Scheduler, Invocation Router e Lifecycle Manager. Além dos compo-nentes mencionados, foram adicionados os serviços Load Balancing Service e Storage Service

na camada de serviços. Os componentes Server Request Handler, Client Request Handler, Re-

questor, Invoker, Management Service e Naming Service já existiam na implementação original(MORAIS; LIBERALQUINO; ROSA, 2013).

Figura 3.2: Visão geral dos componentes do eCaMid. Os elementos de cor brancarepresentam componentes, os de cor cinza representam serviços, enquanto o elemento

preto representa um framework. Os elementos em tracejado são oriundos da arquiteturado CaMid, enquantos os elementos em linha contínua foram adicionados ao eCaMid.

O Group Communication Framework é o componente fundamental dos mecanimos decoordenação e responsável por estabelecer um cluster, localizar e identificar membros (nós) eprover mecanismos de comunicação multicast. O Group Channel e Cluster Request Handler

são dois componentes da camada de infraestrutura responsáveis por enviar e receber mensagens

3.4. ARQUITETURA 52

multicast. Os componentes Task Scheduler e Cluster Event Bus utilizam o Group Communication

Framework para prover serviços de coordenação em nível mais alto.O componente Lifecycle Manager é responsável por controlar a criação e destruição de

objetos. Para isto, ele utiliza o Storage Service para armazenar os objetos remotos e um conjuntode estratégias para gerenciar o estado dos objetos remotos. O Storage service, por sua vez, é umaabstração para um sistema de armazenamento chave-valor que suporta controle de transação etratamento de eventos. É possível acessar o Storage Service a partir de qualquer um dos nós domiddleware. O componentes Lifecycle Manager e Storage Service constituem os mecanismos decompartilhamento de estado utilizados pelo eCaMid.

O componente Invocation Router é utilizado na camada de distribuição para distribuirrequisições de objetos remotos aos diversos nós de um cluster. Este componente utiliza o Load

Balancing Service para definir como a carga de requisições será distribuída. O Load Balancing

Service é um componente que define uma série de políticas de balanceamento de carga. Essescomponentes utilizam as facilidades providas pelo framework de comunicação em grupo paradistribuir requisições recebidas dos clientes.

3.4.1 Coordenação

O eCaMid funciona como uma série de nós agrupados em uma entidade lógica deno-minada cluster. Este cluster precisa de meios eficientes para troca de mensagens entre nós,utilizando diferentes estratégias de comunicação, como um-para-um, um-para-muitos e muitos-para-um. Também precisa ter a capacidade para verificar que membros estão ativos, quandoum novo nó é adicionado ou quando um nó deixa o grupo, com a capacidade de executar açõesespecíficas quando algum desses eventos acontece. O gerenciamento de membros do eCaMid érealizado através da utilização do framework de comunicação em grupo.

Este framework utiliza o padrão de projeto Object Group (MAFFEIS et al., 1996), mas aoinvés de gerenciar réplicas de objetos remotos, este gerencia nós de um cluster. Cada membro docluster recebe um identificador. O conjunto de todos os membros ativos do cluster compõem umaView. Quando algum membro entra ou sai do grupo, uma nova View é gerada. O framework decomunicação em grupo provê uma série de gatilhos para execução de ações quando determinadoseventos ocorrem no cluster, como a geração de uma view ou a falha de comunicação de um dosmembros do nó.

Algumas ações precisam ser executadas de forma única em todo o cluster. O padrãode projeto Leader Election (HOMER et al., 2014) define um processo que é utilizado paradeterminar um líder, o membro do cluster que realizará uma determinada tarefa em favor detodos os outros membros. O eCaMid utiliza o evento de aquisição da view para executar umaação de atribuição de papéis específicos a cada nó.

Um desses papéis é chamado de coordenador, um papel atribuído pelo próprio frameworkde comunicação em grupo. O coordenador é o membro mais antigo do cluster e é responsável

3.4. ARQUITETURA 53

por executar tarefas específicas para o próprio framework. Os demais membros do cluster sãochamados workers e são responsáveis por receber chamadas de método remotas. Um outropapel definido é o Task Executor, que define um nó responsável por gerenciar os agentes queexecutarão tarefas periódicas no cluster.

Além dos mecanismos de gerência de grupo, o eCaMid possui dois componentes queoferecem uma infraestrutura alternativa que pode ser usada para comunicação intra-cluster.Enquanto o Client Request Handler e Server Request Handler são usados na comunicaçãocliente-servidor, o Group Channel é usado para enviar mensagens a outros membros do grupo,utilizando o identificador do nó ao invés do endereço de rede.

O Group Channel suporta o estilo de comunicação unicast (um para um, com semânticarequest-reply) e multicast (um para muitos, com semântica fire-and-forget). O Cluster Request

Handler é o componente de infraestrutura que recebe mensagens do Group Channel e asencaminha para outros componentes da camada de distribuição, como o Invoker e Cluster

Event Bus. O Group Communication Framework age como um intermediário entre esses doiscomponentes. A Figura 3.3 ilustra este estilo de comunicação.

Figura 3.3: Estilos de comunicação um-para-um e um-para-muitos

3.4.1.1 Comunicação Publish/subscribe

Os componentes Group Channel e Cluster Request Handler são dois componentesfundamentais para a execução de tarefas assíncronas no eCaMid. No entanto, ambos sãocomponentes de baixo nível. Os componentes da camada de serviço e a aplicação necessitam deum modelo de programação mais abstrato.

Uma forma de implementar a comunicação assíncrona entre os diversos componentes éatravés da troca de mensagens. Utilizando um modelo Publish/subscribe, um publisher podeenviar uma mensagem específica sem saber ao certo o destinatário. As mensagens são entreguesa todos os subscribers interessados na mesma. A Figura 3.4 mostra os elementos de domínio

3.4. ARQUITETURA 54

deste subsistema.

Figura 3.4: Modelo de domínio do subsistema de publish-subscribe

No escopo do eCaMid, as mensagens trocadas entre componentes são chamadas deeventos. Eventos podem ter três naturezas: locais, onde o evento publicado por um publisher éentregue para todos subscribers no mesmo nó; eventos de broadcast, onde o evento publicado emum publisher é destinado aos subscribers em todos os nós do middleware; e eventos de cluster,onde o publisher em um nó publica uma mensagem que deve ser entregue a todos os publisherslocalizados em um dos nós membros do cluster, de forma a balancear a entrega de requisiçõesentre nós.

O componente responsável por publicar os eventos e encaminhar aos subscribers inte-ressados chama-se Cluster Event Bus. Este componente é composto de duas partes: o Message

Router, responsável por enviar e receber mensagens para os destinatários locais e remotos,encapsulando as chamadas ao Group Channel e o Cluster Request Handler; o Local Event Bus éresponsável por entregar os eventos recebidos a todos os subscribers localizados neste nó.

A principal finalidade do mecanimso de comunicação Publish-Subscribe é prover ummodelo de comunicação para os componentes de monitoramento do eCaMid, pertencentes aoLocal Manager e Global Manager que se comuniquem de forma fracamente acoplada e semcontenção de recursos. No entanto, esses mecanismos também estão disponíveis para aplicaçõesque utilizem o eCaMid que desejem utilizar um mecanismo de comunicação assíncrona maissimples, sem todas as garantias e complexidades de um middleware orientado a mensagens.

3.4.1.2 Escalonamento de tarefas periódicas

O eCaMid e a aplicação podem necessitar de uma infraestrutura para executar tarefasperiódicas. A coordenação e execução dessas tarefas é responsabilidade do componente Task

3.4. ARQUITETURA 55

Figura 3.5: Modelo de domínio do subsistema de escalonamento de tarefas

Scheduler. O modelo de domínio para o subsistema de escalonamento de processos é mostradona Figura 3.5.

As tarefas periódicas podem ser classificadas como tarefas locais e tarefas de cluster.Tarefas locais são executadas no contexto de execução de cada um dos nós, enquanto tarefas decluster são executadas em um nó específico em prol de todo o cluster. Como exemplo de tarefasperiódicas locais, temos o processo de extração das métricas de uso de CPU e memória que éexecutada em cada nó pelo Local Manager. Como exemplo de tarefa de cluster, temos um dosagentes do Cluster Manager que solicita periodicamente do provedor de nuvem o status de todasas máquinas virtuais usadas pelo middleware.

O componente Task Scheduler está presente em todos os nós e pode executar qualquertipo de tarefa periódica. O Task Scheduler recebe eventos relacionados à criação de uma view apartir do Task Coordination Observer. O evento de criação de view informa para o Task Scheduler

quais os membros atuais do cluster. Caso o Task Scheduler atual seja o coordenador da view,este será o responsável por executar as tarefas periódicas do cluster. Caso contrário, apenas astarefas locais são executadas. O Task Scheduler também responde a eventos de desligamento donó, interrompendo a execução de tarefas locais e de cluster de maneira graciosa.

3.4.2 Compartilhamento de Estado

Todos os nós em um cluster do eCaMid são réplicas idênticas uns dos outros, de forma amanter a aplicação que reside sobre o middleware tolerante a falhas. Todos os componentes dacamada de serviços, como o Local Manager, o Global Manager e Naming Service estão presentesem todos os nós, embora sejam executados apenas nos nós que possuem essa responsabilidade.A maioria dos componentes da camada de serviços necessita armazenar dados, como a tabela deLookup presente no serviço de nomes. No entanto, esses dados não podem estar armazenadosapenas na memória de um nó, pois em caso de falha do mesmo, o cluster perderá esses dados.

3.4. ARQUITETURA 56

Por esse motivo, o eCaMid provê o Storage Service, uma abstração para um repositóriochave-valor cujos dados armazenados são compartilhados por todos os nós de um cluster, ondecada nó acessa o Storage Service como se este fosse um componente local. Este repositóriotem suporte à expiração de dados e controle de transações para garantir a atomicidade dasoperações realizadas. Várias estratégias de concorrência podem ser utilizadas no eCaMid, comoconcorrência eventual, locking otimista e locking pessimista. O Storage Service pode ser utilizadopela aplicação como um repositório de dados ou como cache de outras fontes de dados.

O Storage Service não faz uso do sistema de armazenamento chave-valor fornecidopela nuvem, uma vez que nem todos os provedores dispõem deste serviço, como é o caso dasinfraestruturas privadas OpenNebula e CloudStack. Ao invés disso, o Storage Service utilizadono eCaMid funciona como um cache distribuído, onde cada nó do cluster conta como umapartição deste sistema de armazenamento.

Os mecanismos de comunicação peer-to-peer utilizados pelo Storage Service são trans-parentes aos componentes do middleware, que utilizam de forma similar a um sistema dearmazenamento local. Cada vez que um determinado valor é armazenado no Storage Service,esta entrada na tabela de armazenamento é replicada para outros N nós, onde N é determinadopela configuração do middleware e é igual ou menor que a quantidade de nós presentes em umCluster. Quando um nó é adicionado ou removido, o Storage Service redistribui as entradas evalores armazenados entre os nós presentes.

3.4.2.1 Gerenciamento de ciclo de vida de objetos remotos

Objetos são a principal abstração usada pelo eCaMid. Objetos podem depender de outrosobjetos e cada um deles pode ser stateful ou stateless. Eles podem ser acessados localmente, nomesmo processo em que está sendo executado ou através de chamadas de método remotas.

O acesso a estes objetos, sejam locais, distribuídos, stateless ou stateful, deve ser trans-parente. Para garantir esta forma de transparência, objetos remotos precisam ser gerenciadospelo eCaMid, que controla como esses objetos são alocados, descartados ou acessados de formaconsistente por todos os nós de um cluster.

A Figura 3.6 ilustra o modelo de domínio para o subsistema de gerenciamento de ciclode vida do eCaMid.

O componente Lifecycle Manager é responsável por gerenciar o ciclo de vida dos objetosremotos do eCaMid. Para isto, são implementadas as estratégias Per-Request Instance e Client-

Dependent Instance para definir de que forma o estado desses objetos será preservado. Aoutilizar um objeto remoto que usa a estratégia Per-Request Instance, um novo objeto será criadoa cada requisição recebida de um cliente.

Objetos remotos que possuem estado utilizam a estratégia Client-Dependent Instance,que consiste em manter o estado do objeto enquanto o cliente mantém uma conexão ativa com oeCaMid. Uma conexão ativa é chamada de Sessão, que é identificada através de um UUID. OLifecycle Manager utiliza o UUID para guardar um objeto que representa a sessão de um cliente

3.4. ARQUITETURA 57

Figura 3.6: Modelo de domínio do subsistema de gerenciamento de ciclo de vida

através do Storage Service. Juntamente com o objeto de sessão, é guardado o estado de todos osobjetos remotos cujo escopo está atrelado à sessão. Os objetos de sessão são armazenados noStorage Service pelo Lifecycle Manager.

O Lifecycle Manager utiliza um mecanismo de Leasing para gerenciar a alocação derecursos de sessão. É definido um tempo de expiração (leasing) para todos os objetos de sessãoarmazenados. Caso este objeto de sessão não seja acessado por um tempo superior ao tempode expiração, o Storage Service descarta o objeto de sessão, liberando os recursos que foramalocados.

A resiliência do estado dos objetos é garantida pelo Storage Service, onde cada objetode sessão é armazenada como uma entrada na tabela chave-valor e replicado para os outros nós.Existe a garantia de que o estado de um objeto esteja disponível no Cluster desde que no máximoN-1 nós falhem abruptamente, onde N é o número de nós onde cada entrada chave-valor, sem achance de que o Storage Service consiga sincronizar esses objetos para os demais nós.

Uma estratégia de consistência eventual é utilizada para manter o estado do objeto desessão consistente sobre todos os demais nós. Caso o objeto seja acessado concorrentementeem múltiplos nós e seu estado seja alterado, o último valor a ser atualizado será armazenado noStorage Service. O problema de se utilizar mecanismos mais eficazes de controle de concorrênciaé que esses mecanismos tendem a dificultar a escalabilidade da aplicação quando existe umagrande quantidade de nós disputando os mesmos recursos. No entanto, o risco de acessar Client-

Dependent Instances inconsistentes é pequeno, visto que apenas um cliente em dado momentopode realmente acessar este objeto. Caso, o mesmo cliente faça uma atualização dos objetos emdois nós diferentes simultaneamente, a última atualização ao estado do objeto irá sobrescrever aentrada existente na tabela de armazenamento.

Por esse motivo, o eCaMid não suporta a estratégia Static Instance, visto que o nívelde concorrência ao estado deste tipo de objeto poderia limitar de forma severa a escalabilidadedo middleware, ou impedir que este mantivesse um estado consistente. Portanto, componentes

3.4. ARQUITETURA 58

Figura 3.7: Componentes envolvidos na criação de objetos de sessão.

do middleware que precisam guardar estado (como Naming Service, Global Manager e Local

Manager) utilizam o Storage Service diretamente.A Figura 3.7 mostra os elementos envolvidos durante a criação de um proxy que será

usado para acessar um objeto remoto. O cliente, quando deseja acessar um objeto remoto (sejaeste stateless ou stateful), utiliza o Session Factory para iniciar uma conexão com o eCaMid. OSession Factory solicita a criação de uma sessão para o Naming Service, que gera um UUID, epublica uma mensagem de criação de sessão através do Cluster Event Bus. Este componentenotifica o Lifecycle Manager de um nó específico do evento de criação da sessão, que por suavez cria o objeto que representa a sessão, posteriormente o armazenando no Storage Service.

O Session Factory cria um objeto chamado SessionHandler, que representa a sessãocriada pelo cliente. Este session handler é uma representação da conexão criada pelo cliente parao cluster. O Session Handler também é responsável por localizar objetos remotos e criar Proxies

que representam essas instâncias. Os Proxies são usados pelo cliente para realizar chamadasremotas de método.

A Figura 3.8 ilustra os elementos envolvidos na invocação de métodos remotos. Quandoo cliente invoca um método em um Proxy, este constrói uma mensagem chamada de Method

Request Message. Esta mensagem é entregue ao Requestor, que insere outros cabeçalhos namensagem, obtém o endereço de rede do nó que possui a instância do objeto e por fim envia amensagem através de componentes de infraestrutura. O Invoker recebe uma Method Request

Message, extrai o identificador da sessão e solicita a criação de um objeto remoto ao Lifecycle

Manager. Caso o objeto remoto possua estado, este será criado utilizando o estado armazenadona sessão.

3.4. ARQUITETURA 59

Figura 3.8: Componentes envolvidos em uma requisição de método remota.

O modelo de domínio inicial do eCaMid, apresentado na Figura 3.1, mostra que todosos componentes do eCaMid podem acessar objetos remotos. No entanto, apenas objetos queutilizam a estratégia Per-Request Instance podem ser referenciados por Observers e Tarefas,visto que a informação de sessão não está presente em operações assíncronas.

3.4.3 Balanceamento de Carga

Para fazer uso dos recursos do cluster de forma eficiente, o eCaMid fornece um meca-nismo de balanceamento de carga, que é adaptado ao modelo de comunicação característico dossistemas de middleware orientados a objeto.

Durante o processo de criação de uma View, alguns dos nós do tipo worker são escolhidospara atuar como Routers, nós que encaminham requisições para outros nós, incluindo elesmesmos. Os Routers são selecionados utilizando um algoritmo de Leader Election, escolhidosa partir dos nós mais antigos do cluster, considerando algumas restrições: um nó não pode sercoordenador e router ao mesmo tempo, a não ser que só exista um único nó em todo o cluster; aquantidade de routers no cluster deve respeitar a proporção de 1 router para cada N workers,onde o valor padrão de N é igual a 5. Essas restrições são utilizadas para evitar que os nósutilizados como routers se tornem pontos únicos de falha, e não se tornem gargalos a medidaque o cluster aumenta de tamanho. Em caso de adição ou indisponibilidade de um nó, um novoevento de criação da View é disparado, e o Load Balancing Service seleciona novamente os nósque exercerão o papel de routers.

A Figura 3.9 ilustra os componentes envolvidos pelos mecanismos de balanceamento

3.4. ARQUITETURA 60

Figura 3.9: Componentes envolvidos em balanceamento de carga

de carga. O componente Load Balancing Observer contém vários callbacks que verificam achegada de eventos do framework de comunicação em grupo. O Load Balancing Service contémheurísticas para realizar a escolha dos nós que terão o papel de routers e utiliza o Storage Service

para registrar essa informação. O Naming Service consulta o Load Balancing Service para obtera localização dos routers. Um subcomponente do Load Balancing Service é chamado de Load

Balancing Strategy e consiste em uma heurística de balanceamento de carga.Uma parte importante do subsistema de balanceamento de carga se refere ao roteamento

de requisições, que pode ser observado a partir da figura 3.10. Method Request Messages podemser de dois tipos: Direct Request, destinadas a um objeto remoto específico; e requisições degrupo, destinadas a um grupo de objetos.

Figura 3.10: Componentes envolvidos em roteamento de requisições

O Invocation Router é um componente existente na camada de distribuição que é respon-sável por distribuir Method Request Messages para os demais nós de um cluster eCaMid. Elerecebe Method Request Messages a partir do Server Request Handler. Caso sejam requisições

3.4. ARQUITETURA 61

diretas, este encaminha para o Invoker; caso contrário, utiliza o Load Balancing Strategy paralocalizar o nó a quem deve ser entregue a mensagem do tipo Group Request. Quando possui essalocalização, o Invocation Router a encaminha para um nó remoto através do Group Channel.Várias implementações de Load Balancing Strategy podem existir, para diferentes algoritmosde balanceamento de carga. O eCaMid, nativamente, implementa os algoritmos Round-Robin eRandom-Robin.

O processo de comunicação entre cliente e servidor através do eCaMid é similar aoprocesso existente em um middleware orientado a objeto tradicional. A Figura 3.11 ilustra umdiagrama de sequência com todos os passos necessários para realizar a comunicação Cliente/-servidor utilizando os mecanismos de balanceamento de carga providos pelo eCaMid. Várioscomponentes foram omitidos do diagrama, de forma a simplificar o entendimento:

Figura 3.11: Balanceamento de carga no eCaMid

1. Cliente solicita ao Naming Service a referência a um grupo de objeto remoto (1);

2. Naming Service consulta o Load Balancing Service para obter a localização de umrouter, utilizando essa informação para construir um AOR e retorná-lo ao cliente(1.1);

3. Cliente recebe o AOR do Naming Service, constrói um Proxy e o utiliza-o pararealizar chamadas de método remotos (2);

4. Ao receber a chamada de método, o Invocation Router consulta o Load Balancing

Strategy para saber a que nó deverá encaminhar a requisição (2.1);

3.5. TECNOLOGIAS UTILIZADAS 62

5. Se o nó for o mesmo que do Invocation Router, este encaminha a Method Request

Message para o Invoker e recebe a resposta da invocação remota (2.2). Caso contrário,o Invocation Router utiliza o Group Channel como intermediário para enviar oMethod Request Message ao nó destino (2.3); e

6. Invoker responde a requisição que, por sua vez, é encaminhada de volta para oInvocation Router. O Invocation Router encaminha a resposta recebida ao clienteque iniciou a chamada remota (2.3.1).

O Invocation Router pode falhar, devido a uma indisponibilidade ou desligamento do nó.Neste caso, a parte cliente do middleware deve tratar essa falha de forma transparente, refazendouma consulta ao serviço de nomes. O processo descrito na Figura 3.12 ilustra essa situação:

Figura 3.12: Tolerância a falhas no mecanismo de balanceamento de carga.

1. O cliente realiza uma chamada remota a um nó específico. Por estar indisponível, ocliente recebe uma falha de conexão, que é tratada de forma transparente pelo cliente(1);

2. Os componentes da porção cliente do middleware realizam uma consulta ao serviçode nomes, obtendo uma nova referência para o nó em que o objeto remoto encontra-selocalizado (2);

3. O cliente realiza uma requisição ao novo nó, e recebe a resposta da invocação remota(3).

É importante observar que alguns componentes foram omitidos do diagrama para simpli-ficar a explicação do processo.

3.5 Tecnologias utilizadas

A implementação do eCaMid depende de várias tecnologias para implementar as suasfuncionalidades.

3.5. TECNOLOGIAS UTILIZADAS 63

O framework de comunicação em grupo utilizado pelo eCaMid chama-se JGroups. Oscomponentes Group Channel e o Cluster Request Handler são duas abstrações criadas peloeCaMid com a finalidade enviar e receber mensagens em um ambiente intra-cluster.

A implementação atual do Storage Service utiliza a tecnologia Infinispan (MARCHIONI,2012) para criar vários repositórios chave-valor distribuídos com finalidades específicas. OStorage Service define um repositório para cada serviço específico do eCaMid. Cada repositóriopossui configurações específicas: os repositórios do Local Manager e Global Manager utilizamum repositório chave-valor básico; os repositórios do Naming Service e Load Balancing Service

são otimizados para leitura de informações, portanto, utilizam um cache L1 provido peloInfinispan para conservar os dados mais requisitados na memória de cada nó; o repositórioutilizado pelo Lifecycle Manager é configurado para descartar os valores armazenados apósum tempo de expiração definido, além de utilizar um gerenciador de transações para garantir aconsistência da atualização do estado de objetos remotos que é acessado em diversos nós de umcluster.

Para fazer a "cola"de seus vários subsistemas, o eCaMid usa em seu núcleo um frameworkde injeção de dependências chamado Guice (VANBRABANT, 2008). Esta tecnologia forneceum container que é responsável pela criação de cada objeto utilizado no eCaMid e de cada umade suas dependências. Todos os componentes internos do eCaMid são objetos gerenciados peloGuice. Os componentes do eCaMid estão agrupados na forma de módulos: existe um módulocom as funcionalidades principais, como invocação de métodos remotos, gerenciamento de ciclode vida e a API de storage; um módulo com a implementação do Storage Service; um módulocom as funcionalidades de coordenação e clustering, utilizando o JGroups; um módulo comos mecanismos de balanceamento de carga usados no eCaMid; e por fim, um módulo com osserviços de gerenciamento, o Local Manager e Global Manager.

A aplicação que usa o eCaMid também utiliza o mecanismo de módulos do Guice paradefinir quais componentes irão compor a aplicação. O eCaMid provê uma API específica paraconfiguração de um módulo de uma aplicação, permitindo que este defina todos os objetosremotos, a estratégia de ciclo de vida de cada um deles, um conjunto de subscribers e tarefasperiódicas. O Lifecycle Manager fornece um conjunto de extensões ao Guice que permitea utilização das estratégias de ciclo de vida de middleware (Per Request Instance e Client

Dependent Instance) através dos mecanismos de injeção de dependência.O Guice também permite a utilização de interceptadores e programação orientada a

aspectos, permitindo a criação de comportamentos secundários que podem ser aplicados emdiferentes contextos da aplicação. Os coletores de métricas de QoS utilizados no eCaMidutilizam interceptadores em métodos específicos dos componentes Server Request Handler eInvoker para calcular o tempo de resposta e o número de vezes que determinado método foiinvocado. Adicionalmente, os interceptadores fornecidos pelo Guice poderiam ser usados paraimplementar mecanismos de segurança e controle de transação.

3.6. IMPLANTAÇÃO 64

Figura 3.13: Diagrama de implantação para nós do eCaMid

3.6 Implantação

O eCaMid é distribuído como uma biblioteca. O desenvolvedor da aplicação precisadesenvolver um módulo, onde declara quais são os objetos remotos, tarefas de background e subs-

cribers que serão gerenciados pelo middleware. Um componente chamado eCaMidClusterServer

é utilizado para incluir todos os módulos definidos pela aplicação e para iniciar a execução domiddleware. A Figura 3.13 ilustra a arquitetura de implantação do eCaMid.

Cada nó individual precisa, de alguma forma, descobrir os seus vizinhos e iniciar umcluster, uma etapa conhecida como bootstrapping. A estratégia utilizada pelo eCaMid é definirpelo menos um nó encarregado de centralizar os mecanismos de descoberta dos demais nós. Oendereço de rede utilizado por ambas as máquinas virtuais deve ser conhecido previamente. Osnós executados sobre as duas máquinas virtuais devem ser executados em modo de administradordo cluster e os endereços de ambas as máquinas virtuais devem ser passadas como parâmetro.

Os dois nós mencionados podem ser categorizados como nós fixos, e são utilizados pelosdemais nós para localizar os outros membros do cluster. Foram escolhidos a presença de doisnós, para que o primeiro atue como nó principal e o segundo como failover. Contudo, qualquernúmero de nós fixos pode ser usado, e o uso de mais de um nó fixo existe para garantir ummecanismo de failover, evitando um ponto central de falha. Caso algum dos nós fixos falhe, érecomendado que o usuário o reinicie com exatamente as mesmas configurações, como endereçoIP, para que o cluster não perca a capacidade de bootstrapping.

O demais nós do eCaMid são chamados de nós elásticos e podem ser ativados a qualquer


momento pelo usuário. Cada nó elástico precisa saber a localização dos dois nós fixos paraentão descobrir a localização dos demais membros do cluster. À medida que novos nós elásticossão adicionados à infraestrutura do middleware pelo usuário de nuvem, os novos membrosutilizarão uma configuração inicial para localizar os nós fixos e serão adicionados ao cluster

dinamicamente.O cliente do eCaMid está implantado em uma máquina virtual separada. Para realizar a

ação de bootstrapping, o cliente precisa saber o endereço de rede de um nó fixo para então acessaro serviço de nomes que está implantado em ambos. A partir do serviço de nomes, o clienteobterá a localização de um dos routers, que será o intermediário do cliente para a realização derequisições remotas.

3.7 Considerações Finais

Neste capítulo, foram apresentados os objetivos e requisitos da arquitetura do eCaMid.Em seguida, foram explicados todos os mecanismos adicionados à arquitetura do CaMid origi-nal: coordenação, comunicação assíncrona, execução de tarefas, compartilhamento de estado,gerência de ciclo de vida e balanceamento de carga. Nas demais seções foram explicadas astecnologias utilizadas pelo eCaMid para prover seus serviços e uma arquitetura de implantaçãopara o mesmo.

666666

4Avaliação de Desempenho e Discussão

No capítulo anterior, foram apresentados vários mecanismos que estendem as funciona-lidades fornecidas pelo CaMid original, de forma a suportar o desenvolvimento de aplicaçõeselásticas na nuvem. No entanto, a arquitetura e os mecanismos apresentados precisam ser valida-dos, para que seja possível quantificar os benefícios de desempenho e escalabilidade trazidospelas novas funcionalidades.

Neste capítulo, iremos apresentar uma avaliação experimental que foi realizada com oeCaMid. Iniciaremos este capítulo citando os objetivos da avaliação e a metodologia utilizada.Em seguida, serão mostrados os resultados obtidos a partir da avaliação e será realizada umaanálise dos benefícios e prejuízos dos novos mecanismos do eCaMid nos cenários avaliados.

4.1 Objetivos e Metodologia

A avaliação experimental usada no eCaMid utiliza a metodologia sistemática definidapor JAIN (1991), voltada para avaliação de desempenho. O experimento realizado no eCaMidvisa provar que os mecanismos de coordenação, replicação e balanceamento de carga nãocausam a queda de desempenho da aplicação. É necessário também provar que o mecanismode balanceamento de carga utilizado consegue preservar o desempenho da aplicação quandonós são adicionados dinamicamente em um cluster, provando que seus mecanismos internos sãocapazes de reagir a mudanças de topologia rapidamente.

Para implementar a avaliação foi desenvolvida uma aplicação simples, que foi desenvol-vida utilizando o modelo de programação do eCaMid. Esta aplicação é constituída de um objetoremoto chamado PasswordEncryptionService que contém um método que aplica um hashing

criptográfico a uma senha, utilizando o algoritmo PBKDF2WithHmacSha1, com um salt de 64bits e uma senha de 160 bits. Este algoritmo aplica várias funções de hash à senha utilizadaiterativamente, com o objetivo de aumentar o tempo necessário para realizar um ataque de forçabruta que visa descobrir a senha original a partir do hash gerado. O objetivo desta aplicação éprover um kernel possa executar uma operação que é exigente em termos de processamento (usode CPU), é comum em aplicações de nuvem (hashing criptográfico de senha) e não depende de

4.1. OBJETIVOS E METODOLOGIA 67

um mecanismo de persistência durável, como é o caso de um banco de dados.Duas versões do mesmo objeto foram construídas. Na versão stateless, um salt é gerado

a cada vez que um método é chamado e é aplicado o hashing criptográfico à senha utilizandoeste salt e o número de iterações do algoritmo. Na versão stateful, o salt é criado apenas naconstrução do objeto, permanecendo na memória mesmo a cada execução.

Dois diferentes cenários foram utilizados para fazer a avaliação experimental do eCaMid.O primeiro consiste no uso de uma máquina virtual representando a aplicação cliente e umaaplicação servidor com um conjunto de objetos remotos, o serviço de nomes e o global manager,que é executada em uma segunda máquina virtual. Neste primeiro cenário, o middleware éexecutado sem os mecanismos de suporte à elasticidade fornecidos pelo eCaMid, visando criarum ambiente similar ao utilizado na avaliação experimental do CaMid original.

O segundo cenário é bastante similar ao primeiro, com uma máquina virtual contendo ocliente e a outra com a parte servidor. Neste caso, no entanto, os mecanismos de coordenação,compartilhamento de estado e balanceamento de carga foram ativados. Adicionalemente, novosnós seriam adicionados ao cluster em intervalos regulares, através de um script, cada umexecutado uma nova máquina virtual. Apenas um nó fixo será utilizado, sem a utilização defailover, visto que esta avaliação não procura avaliar os mecanismos de disponibilidade domiddleware. Este cenário visa criar um ambiente onde são utilizados os recursos de elasticidadedo eCaMid, incluindo a sua capacidade de adaptação ao redimensinamento da infraestrutura.

4.1.1 Métricas, Parâmetros e Fatores

As métricas utilizadas para avaliar o desempenho do eCaMid são tempo de resposta evazão. As métricas tempo de resposta e vazão visam medir o desempenho e escalabilidade dosistema.

A fórmula usada para medir o tempo de resposta é: Tresposta = t f im − tinicio , onde t f im

representa o instante em que a requisição foi concluída com sucesso e tinicio representa o instanteem que a requisição foi iniciada. Para o cálculo do tempo de resposta, apenas as requisições quecompletaram com sucesso são contabilizadas.

A fórmula usada para calcular a vazão é: V = RsucessoT , onde Rsucesso representa o número

de requisições completadas com sucesso e T representa um intervalo temporal específico.A métrica de tempo de resposta é calculada para cada requisição realizada durante a

avaliação. Já a métrica de vazão é calculadas uma vez ao final da avaliação, utilizando o númerode requisições para um intervalo específico.

Uma série de parâmetros podem afetar as métricas mencionadas: (1) Número total declientes concorrentes em um intervalo X; (2) O número total de iterações utilizado pelo algoritmoPBKDF2WithHmacSha1; (3) Tamanho do salt utilizado; (4) Tamanho do hash gerado; (5) Taxade transferência da rede; (6) Capacidade de processamento da máquina virtual; (7) Quantidadede servidores virtuais; (8) Estado de objeto remoto.


As aplicações, em ambos os cenários, devem ter a escalabilidade suficiente para atenderum grande número de requisições simultâneas. O número de clientes que realizam requisiçõesinfluenciam diretamente as métricas de tempo de resposta e vazão. O tempo de resposta dosistema avaliado deve apresentar um valor baixo quando o número de clientes é pequeno, e devecrescer à medida que o número de clientes aumenta. A vazão não apresenta o mesmo tipo devariação. Caso o número de clientes seja baixo, a vazão deve apresentar um valor baixo. A vazãodo sistema aumenta com um número de clientes até alcançar um ponto de saturação. Após esteponto, a vazão do sistema tende a cair. Este comportamento pode ser provado analiticamenteatravés da teoria das filas (BAKOUCH, 2011).

O número de iterações, dos parâmetros que afetam o mecanismo de hashing criptográfico,possui a maior influência sobre as métrica de desempenho, pois este tem um impacto direto sobrea complexidade computacional do algoritmo. Logo, se o número de iterações é grande, maiorserá o tempo de resposta do sistema e menor a vazão. Pode ser fixado um tamanho de hash e salt

entre os valores recomendados enquanto são variados os valores de número de iterações paraaumentar ou diminuir o tempo de resposta (TURAN et al., 2010).

A taxa de transferência da rede pode influenciar diretamente o desempenho e escala-bilidade do sistema avaliado. Por este motivo, para os dois cenários avaliados, é utilizado umambiente de rede homogêneo. A mesma estratégia é adotada para a capacidade de processamento,utilizando máquinas virtuais com a mesma configuração em todos os cenários avaliados.

A quantidade de servidores virtuais usados na avaliação tem pouca influência no desem-penho, mas grande influência na escalabilidade do sistema avaliado. No primeiro cenário, umúnico servidor virtual é utilizado, enquanto no segundo cenário, é utilizado um único servidorvirtual e mais quatro servidores virtuais são adicionados através do script que executa o testede desempenho. Foi escolhido o número total de cinco servidores virtuais para que fosse pos-sível observar o ganho incremental nas métricas ao se adicionar novos servidores virtuais nainfraestrutura.

Caso o objeto remoto apresentado pelo sistema testado possua estado durante a execuçãodo middleware, este pode afetar de maneira adversa o desempenho do sistema avaliado porconta do esforço necessário para manter este estado consistente. Caso este mesmo objeto sejautilizado concorrentemente, a sincronização dessas requisições adicionam um impacto sobre odesempenho do middleware. Se este estado for compartilhado com outros nós, como é o caso dosegundo cenário, o custo de sincronização afetará diretamente o tempo de resposta e vazão daaplicação.

Dentre os parâmetros citados, alguns foram escolhidos como fatores do experimento.Foram escolhidos parâmetros que podem ser variados durante a geração da carga de trabalhorealizada no experimento e que são pertinentes para ambos os cenários. Os fatores escolhidos, eseus respectivos valores são:

� Número de clientes: Foram utilizados os valores 50, 100, 150 e 200 para a quanti-dade de clientes simultâneos. Estes valores são suficientes para testar a aplicação em


cenários diversos.

� Número de iterações para o algoritmo PBKDF2WithHmacSha1: Foram selecio-nados os valores 8000, 16000, 32000 e 64000 iterações para o algoritmo de hashing

criptográfico.

� Estado do objeto remoto: Este fator possui dois níveis: com estado (stateless) esem estado (stateful).

4.1.2 Técnica de avaliação, carga de trabalho e projeto de avaliação

Foi escolhida a técnica de experimentação para realizar a avaliação de desempenho doeCaMid. Esta técnica permite testar um protótipo real do middleware, em uma situação que seaproxima do uso real de uma aplicação distribuída.

O provedor de nuvem escolhido foi o AWS, onde o serviço Elastic Compute Cloud (EC2)foi utilizado para provisionar as máquinas virtuais que foram usadas nos experimentos e forneceruma imagem que já continha uma instalação prévia do eCaMid e um script de inicialização.As máquinas virtuais utilizadas em todos os experimentos e cenários eram da classe m1.small,com 1.7 GB de memória RAM e 1 Compute Unit1 e localizadas na zona us-west-2a. Em cadamáquina virtual foi instalado o sistema operacional Ubuntu Server 64 bits 12.04.

Uma máquina virtual separada foi utilizada para simular os clientes do sistema avaliado.Um programa sintético foi utilizado para simular os clientes, registrar o tempo de resposta decada requisição e registrar se esta foi terminada com sucesso ou não. Cada cliente é simuladoatravés de uma thread separada, onde cada cliente realiza uma nova requisição, com um intervaloentre cada requisição. O valor deste intervalo é definido como uma variável aleatória distribuídoatravés de uma função gaussiana, com média de 300 ms e desvio padrão de 100 ms.

Cada experimento teve uma duração de 12 minutos, onde um minuto é utilizado comotempo de espera para que o programa sintético seja carregado e estabilizado (warm-up). Osegundo minuto do experimento é utilizado para iniciar cada cliente em intervalos regulares(ramp-up). Supondo que sejam 200 clientes usados no experimento, então um novo cliente éiniciado a cada 30 segundos.

O programa sintético foi criado através da utilização da ferramenta JMeter (APACHEJMETER, 2013). Foi criado um Sampler específico do JMeter que utiliza a parte cliente doeCaMid para se comunicar com a parte servidor da aplicação, onde o cluster está desativadono primeiro cenário e ativado no segundo. Através do JMeter foi possível implementar osmecanismos de simulação de clientes, warm-up e ramp-up utilizados no experimento.

Os objetos remotos que contém a função de hashing criptográfico, podem ou não conterestado. Na implementação stateless, um novo valor de salt é gerado para cada nova requisição

11 Compute Unit é equivalente a capacidade de processamento de um processador Opteron, com 1.0 GHz,fabricado em 2007

4.2. RESULTADOS 70

do método de hashing, portanto, duas invocações para aplicação de hashing à mesma senhairão produzir hashes diferentes. Na implementação stateful, o valor do salt é gerado durantea invocação do primeiro método. Invocações susbsequentes para a mesma senha irão gerar omesmo hash. O valor retornado por objetos stateful é usado para verificar se houve algum errode consistência. Objetos stateless utilizam a estratégia Per-Request Instance, enquanto objetosstateful Client-Dependent Instance.

Ao final de cada experimento, as máquinas virtuais foram reiniciadas e todos as partesda aplicação, cliente ou servidor, foram reiniciados, para reduzir a possibilidade de saturaçãodos recursos gerenciados pelo sistema operacional da máquina virtual e da própria aplicação. Osexperimentos foram conduzidos em horário comercial, para evitar algum problema relacionado àmanutenção da infraestrutura do provedor de nuvem.

4.2 Resultados

Foram realizados vários experimentos para avaliar todos os fatores e seus níveis em cadacenário específico. Os experimentos foram divididos em grupos, que são nomeados de acordocom o cenário e o tipo de objeto remoto utilizado. O cenário onde é utilizado apenas uma máquinavirtual cliente e outra máquina virtual servidor é chamado de "Direct", enquanto o experimentoonde novas máquinas virtuais são adicionadas é chamado de "Elastic-Clustered". Este nome éseguido pelo tipo de objeto utilizado, ou seja, Stateless ou Stateful. Desta forma, temos ao todo,quatro grupos de experimentos: Direct-Stateless, Direct-Stateful, Elastic-Clustered-Stateless eElastic-Clustered-Stateful.

4.2.1 Resultados individuais de cada experimento

O primeiro grupo de experimentos, Direct-Stateless, consiste no uso do primeiro cenário,com apenas um único servidor virtual, sem o mecanismo de clustering ativo e um objeto remotostateless.

A Tabela 4.1 mostra os valores de tempo de resposta para o primeiro cenário (um clientee um único servidor), utilizando um objeto stateless. Podemos observar que o tempo de respostasofre grande influência do número de iterações e número de clientes. Fixando o número deiterações e aumentando o número de clientes, podemos verificar um aumento proporcional notempo de resposta. Se fixarmos em 8000 iterações e comparando ao experimento com 50 clientes,temos um aumento de 111,83% no tempo de resposta ao se utilizar 100 clientes, um aumento de224,01% para 150 clientes e um aumento de 333,66% para 200 clientes. Ao fixar o número declientes e aumentar o número de iterações, o tempo de resposta também aumenta. Se fixarmosem 200 clientes, e tomando como base de comparação o experimento com 8000 iterações, temosum aumento no tempo de resposta de 93,40% para 16000 iterações (2x), 271,46% para 32000iterações (4x) e 609,29% para 64000 iterações.

4.2. RESULTADOS 71

A vazão neste grupo de experimentos é bastante influenciada pelo número de iteraçõesdo algoritmo, uma vez que ao fixar o número de clientes e aumentar o número de iterações,é possível verificar uma queda no valor da vazão. Podemos tomar como base o experimentorealizado com 100 clientes e 8000 iterações. É possível notar uma queda de 47,59% na vazão aoaumentar o número de iterações para 16000, 73,13% para 32000 iterações e 85,88% para 64000iterações. Fixando o número de iterações e aumentando o número de clientes, não é possívelverificar uma mudança significativa no valor da vazão. Tomando como base o experimentorealizado com 16000 iterações e 50 clientes, temos: um aumento de 0,98% na vazão, para 100clientes; um aumento de 1,50% para 150 clientes; e um aumento de 2,03% para 200 clientes.Este comportamento revela que a vazão pode aumentar de acordo com o número de clientes,mas logo alcança um ponto de saturação, uma vez que um único servidor não pode oferecer umavazão superior ao valor determinado.

Tabela 4.1: Tempo de resposta e vazão para o grupo de experimentos Direct-Stateless

Número deClientes

Número deIterações

Tempo deRespostaMédio (ms)

DesvioPadrão doTempo deResposta

Vazão( reqs

s )

50 8000 1912.48 398.13 21.4850 16000 3900.64 799.03 11.3250 32000 7827.18 1595.72 5.8550 64000 15766.51 3404.48 2.96100 8000 4051.24 820.81 21.81100 16000 7994.80 1636.08 11.43100 32000 15841.15 3454.87 5.86100 64000 30125.43 7554.98 3.08150 8000 6196.63 1247.62 21.87150 16000 12054.57 2538.94 11.49150 32000 23489.23 5597.71 5.96150 64000 44718.56 12588.79 3.16200 8000 8293.75 1703.16 22.02200 16000 16040.37 3564.74 11.55200 32000 30808.19 7935.22 6.07200 64000 58826.57 18205.86 3.21

O grupo de experimentos Direct-Stateful consiste em um conjunto de experimentosrealizados utilizando um único servidor virtual, onde um cliente faz chamadas a um objetoremoto stateful. A Tabela 4.2 ilustra as métricas obtidas com a realização deste grupo deexperimentos. O tempo de resposta e vazão apresentam comportamento bastante similar àqueleverificado ao grupo de experimentos anterior. Fixando um número de iterações em 8000, otempo de resposta apresenta aumentos de 105,53% para 100 clientes, 215,21% para 150 clientese 323,76% para 200 clientes, quando comparados ao tempo de resposta do experimento queutiliza apenas 50 clientes.

4.2. RESULTADOS 72

A vazão apresenta comportamento bastante similar ao primeiro experimento, ondediminui à medida que o número de iterações aumenta, mas não apresenta diferença significativaao aumentar o número de clientes. Fixando o parâmetro de 8000 iterações e aumentando etomando como base o experimento com 50 clientes, é possível notar um aumento na vazão de4,56% para 100 clientes, 4,52% para 150 clientes e 0% para 200 clientes.

No entanto, o contrário acontece ao aumentar o número de iterações do experimento. Aofixar o parâmetro de 50 clientes e usando o valor da vazão do experimento para o nível de 8000iterações como referência, podemos notar uma redução de 45% na vazão ao se comparar com omesmo experimento utilizando 16000 iterações, 73% comparado ao experimento com 32000iterações e finalmente redução de 85,58% se comparado ao experimento com 64000 iterações.

Os valores da vazão mostram que o desempenho do sistema é fortemente afetado pelonúmero de iterações utilizados pelo algoritmo, mas a capacidade de servir requisições não sealtera conforme são aumentados o número de clientes para 100, 150 e 200.

Tabela 4.2: Tempo de resposta e vazão para o grupo de experimentos Direct-Stateful

Número deClientes




Vazão( reqs

s )

50 8000 1997.32 683.69 20.5950 16000 3920.87 740.21 11.2650 32000 8272.07 1355.26 5.5050 64000 15695.76 3036.36 2.97100 8000 4105.07 681.57 21.53100 16000 8275.17 1087.22 10.73100 32000 15904.29 3152.28 5.84100 64000 31440.58 4781.80 2.87150 8000 6295.79 1007.08 21.52150 16000 11978.64 1402.58 10.71150 32000 23275.31 5065.11 5.89150 64000 44999.69 11665.05 3.11200 8000 8463.90 918.67 20.59200 16000 16203.36 3153.84 11.43200 32000 31837.73 4952.01 5.72200 64000 58895.39 16956.20 3.17

O terceiro grupo de experimentos, Elastic-Clustered-Stateless, utiliza o segundo cenário(um único servidor virtual, com novos nós adicionados em intervalos regulares de 2 minutos)utilizando objetos stateless. Este grupo de experimento visa mostrar o aumento da vazãoresultantes do uso de clustering e balanceamento de carga, em uma infraestrutura dinâmica.

A Tabela 4.3 mostra os valores de tempo de resposta, vazão e proporção de erros obtidosdurante os experimentos. O tempo de resposta para este grupo de experimentos aumenta à medidaque o número de iterações e número de clientes é elevado. Fixando o número de clientes em 50

4.2. RESULTADOS 73

e utilizando como base o experimento em que o número de iterações é igual a 8000, podemosafirmar que o tempo de resposta médio apresenta um aumento de 96,27% para 16000 iteraçõesdo algoritmo, 328,92% para 32000 iterações e 673,67%, para 64000 iterações. Fixando-se onúmero de iterações em 8000, e tomando como base o experimento realizado com 50 clientes,podemos verificar que o tempo de resposta sofre um aumento de 154,91% para 100 clientes,286% para 150 clientes e 441,57% para 200 clientes.

A vazão, assim como nos grupos de experimentos anteriores, apresenta uma queda,conforme o número de iterações é elevado e mantém-se estável caso seja aumentado o número declientes. Tomando como base o experimento com 8000 iterações e 50 clientes, a vazão apresentauma redução de 4,67% ao elevar o número de clientes para 100, 1,01% para 150 clientes e 2,03%para 200 clientes. Mantendo-se 50 clientes e tomando-se como base o valor do fator de 8000iterações, a vazão apresenta redução de 39,64% ao aumentar o número de iterações para 16000,69,61% para 32000 iterações e 82,46% para 64000 iterações. Da mesma forma que os demaisgrupos de experimentos, a vazão apresentou pouca variação ao aumentar o número de clientes eapresentou uma redução significativa ao aumentar o número de iterações do algoritmo.

Tabela 4.3: Tempo de resposta e vazão para o grupo de experimentosElastic-Clustered-Stateless

Número deClientes




Vazão( reqs

s )

50 8000 692.73 1402.10 47.3250 16000 1359.65 839.53 28.5650 32000 2971.23 2473.77 14.3850 64000 5359.47 2894.16 8.30100 8000 1765.87 2026.29 45.11100 16000 2996.27 1538.87 28.58100 32000 6228.81 5546.95 14.19100 64000 10687.89 4811.57 8.42150 8000 2673.91 2464.86 46.84150 16000 4859.51 3251.26 27.23150 32000 8779.19 5783.85 15.33150 64000 15964.65 6466.65 8.35200 8000 3751.62 2528.46 46.36200 16000 6442.87 4582.37 27.64200 32000 12083.41 6798.01 14.73200 64000 22564.70 11843.50 7.91

O último grupo de experimentos, Elastic-Clustered-Stateful, utiliza o mesmo cenárioque o grupo de experimento anterior, mas utilizando um objeto stateful. Os valores de tempo deresposta e vazão para este grupo de experimentos podem ser encontrados na Tabela 4.4.

Da mesma forma que os demais grupos de experimentos, o tempo de resposta médiotende a aumentar conforme o número de clientes ou o número de iterações aumenta. Utilizando

4.2. RESULTADOS 74

como referência o experimento com 50 clientes e 8000 iterações, podemos notar um aumento de118,28% quando é elevado para 100 o número de clientes, 207,36% para 150 clientes e 313,77%para 200 clientes. Com o mesmo experimento de referência, podemos notar um aumento de93,40% quando o número de iterações é elevado para 100, 207,36% quando elevado para 150 e313,77% quando elevado para 200 clientes. Esses aumentos percentuais mostram um aumentoaproximadamente proporcional no tempo de resposta médio em relação ao número de clientes.

A vazão neste grupo de experimentos também é fortemente influenciada pelo número deiterações do algoritmo, mas pouca diferença em relação ao número de clientes. Tomando comobase o experimento com 50 clientes e 8000 iterações, podemos notar uma redução de 2,79% navazão quando o número de clientes é elevado para 100, um aumento de 6,79% quando elevadopara 150 clientes e um aumento de 6,84% para 200 clientes. Utilizando o mesmo experimentocomo referência, a vazão sofre uma redução de 44,62% ao aumentar o número de iterações para16000, 71,86% para 32000 iterações e 84,89% para 64000 iterações.

Tabela 4.4: Tempo de resposta e vazão para o grupo de experimentosElastic-Clustered-Stateful

Número deClientes




Vazão( reqs

s )

50 8000 2095.47 671.43 19.7250 16000 4052.72 665.77 10.9250 32000 8231.49 1122.49 5.5550 64000 15621.19 2988.64 2.98100 8000 4574.11 850.11 19.17100 16000 8322.15 1421.50 10.98100 32000 15930.67 3150.86 5.83100 64000 28666.47 4133.83 2.90150 8000 6440.65 1027.45 21.06150 16000 12957.76 1410.84 10.55150 32000 23718.77 5258.13 5.87150 64000 36216.29 5351.00 2.89200 8000 8670.54 1430.04 21.07200 16000 16480.27 3196.92 11.24200 32000 28915.12 4386.49 5.68200 64000 37511.40 8177.64 3.01

4.2.2 Comparação entre resultados

A Figura 4.1 mostra uma série de gráficos de barra que demonstram a diferença entre osvalores de tempo de resposta, comparando o número de clientes e o grupo de experimento, paracada valor específico do número de iterações. É possível observar através de todos os gráficosque o tempo de resposta médio do grupo de experimentos Elastic-Clustered-Stateless apresenta

4.2. RESULTADOS 75

o menor valor, comparado aos demias grupos de experimento.O tempo de resposta para os grupos de experimentos Elastic-Clustered-Stateful, Direct-

Stateless e Direct-Stateful apresentam valores similiares nas Figuras 4.1a e 4.1b. No entanto,para níveis maiores do fator número de iterações, podemos observar que o tempo de respostamédio do grupo de experimento Elastic-Clustered-Stateful tende a ser menor quando comparadoaos grupos de experimento Direct-Stateless e Direct-Stateful.

(a) Tempos de resposta vs número de clientes comnúmero de iterações igual a 8000

(b) Tempos de resposta vs número de clientes comnúmero de iterações igual a 16000

(c) Tempos de resposta vs número de clientes comnúmero de iterações igual a 32000

(d) Tempos de resposta vs número de clientes comnúmero de iterações igual a 64000

Figura 4.1: Gráficos de barra para comparação de tempo de resposta médio entre todosos grupos de experimentos

Podemos comprovar esta diferença no tempo de resposta através da comparação dosvalores de tempo de resposta entre o grupo de experimentos Elastic-Clustered-Stateful e os

4.2. RESULTADOS 76

grupos Direct-Stateless e Direct-Stateful. Considerando o tempo de resposta como uma variávelaleatória T , que possui uma distribuição não normal. Podemos definir como hipótese nula queT1 = T2, ou como hipótese alternativa que o valor de T1 < T2, onde T1 corresponde ao tempo deresposta do grupo de experimentos Elastic-Clustered-Stateful e T2 aos tempos de resposta dosexperimentos Direct-Stateless e Direct-Stateful.

Tabela 4.5: Teste estatístico Mann-Whitney comparando os grupos de experimentoElastic-Clustered-Stateful e Elastic-Clustered-Stateless

Número deClientes


U P-Value

50 8000 91278977 1.0050 16000 24948474 1.0050 32000 6066395.5 0.2650 64000 1261866 1.00e-31100 8000 91278977 1.00100 16000 24948474 1.00100 32000 6066395.5 0.26100 64000 1261866 1.00e-31150 8000 91278977 1.00150 16000 24948474 1.00150 32000 6066395.5 0.26150 64000 1261866 1.00e-31200 8000 91278977 1.00200 16000 24948474 1.00200 32000 6066395.5 0.26200 64000 1261866 1.00e-31

4.2. RESULTADOS 77

Tabela 4.6: Teste estatístico Mann-Whitney comparando os grupos de experimentoElastic-Clustered-Stateful e Elastic-Clustered-Stateful

Número deClientes


U P-Value

50 8000 87649073.5 1.0050 16000 24387313.5 1.0050 32000 5805891.5 0.0850 64000 1223735 1.04e-31100 8000 87649073.5 1.00100 16000 24387313.5 1.00100 32000 5805891.5 0.08100 64000 1223735 1.04e-31150 8000 87649073.5 1.00150 16000 24387313.5 1.00150 32000 5805891.5 0.080150 64000 1223735 1.04e-31200 8000 87649073.5 1.00200 16000 24387313.5 1.00200 32000 5805891.5 0.08200 64000 1223735 1.04e-31

Como a variável aleatória T não possui uma distribuição normal, foi aplicado o testeestatístico Mann-Whitney, com nível de significância 0.05. Os valores dos testes estatísticos,que mostram uma comparação dos grupos de experimentos Elastic-Clustered-Stateful e Direct-

Stateless, podem ser encontrados na Tabela 4.5 e a comparação entre os grupos Elastic-Clustered-

Stateful e Direct-Stateful na Tabela 4.6. O valor U representa o valor do teste estatísticoMann-Whitney. Apenas nos experimentos onde o número de iterações é igual a 64000, pudemosrejeitar a hipótese nula. Para este valor do número de iterações, o tempo de resposta do grupo deexperimentos Elastic-Clustered-Stateful é menor. Em todos os outros casos, pudemos observarque a hipótese nula foi aceita.

Podemos observar os valores de vazão, de todos os grupos de experimentos, comparadosatravés da Figura 4.2. O grupo de experimentos Elastic-Clustered-Stateless apresentou um valorbastante superior da métrica vazão, para qualquer valor de número de iterações e número declientes. Já os grupos Elastic-Clustered-Stateful, Direct-Stateless e Direct-Stateful apresentaramvalores de vazão bastante semelhantes.

4.2. RESULTADOS 78

(a) Vazão vs número de clientes com número deiterações igual a 8000

(b) Vazão vs número de clientes com número deiterações igual a 16000

(c) Vazão vs número de clientes com número deiterações igual a 32000

(d) Vazão vs número de clientes com número deiterações igual a 64000

Figura 4.2: Gráficos de barra para comparação de vazão entre todos os grupos deexperimentos

A Figura 4.3 mostra o comportamento do tempo de resposta ao longo do experimento.Foram escolhidos os valores de 50 e 200 para o fator número de clientes e os valores 8000 e64000 para o fator número de iterações, pois estes representam os maiores e menores níveis decada fator. Todos os grupos de experimento foram tratados em cada gráfico.

4.2. RESULTADOS 79

(a) Tempo de resposta vs tempo do experimentopara os valores de 50 clientes e 8000 iterações

(b) Tempo de resposta vs tempo do experimentopara os valores de 50 clientes e 64000 iterações

(c) Tempo de resposta vs tempo do experimentopara os valores de 200 clientes e 8000 iterações

(d) Tempo de resposta vs tempo do experimentopara os valores de 200 clientes e 64000 iterações

Figura 4.3: Tempo de resposta vs tempo do experimento para comparação entre osgrupos de experimentos

No início do experimento é comum, na fase de ramp-up, apresentar valores de tempo deresposta que aumentam lentamente antes do primeiro minuto. Após a fase de ramp-up, o tempode resposta tende a aumentar um pouco mais até atingir um ponto de saturação, que ocasiona emum valor estável para o tempo de resposta. Durante o início de alguns experimentos, foi possívelobservar um pico repentino no tempo de resposta, mas que logo em seguida alcançou os valoresde ramp-up comuns.

Nos grupos de experimentos Elastic-Clustered-Stateless e Elastic-Clustered-Stateful

foram adicionados novos nós nos intervalos de 2, 4, 6 e 8 minutos do tempo do experimento.

4.3. DISCUSSÃO 80

Particularmente no experimento Elastic-Clustered-Stateless, podemos observar picos no tempode resposta quando são alcançados estes instantes, seguidos por quedas bruscas no tempo deresposta, atingindo um ponto de saturação inferior ao anterior. Ao final de cada experimento dogrupo Elastic-Clustered-Stateless, o valor do tempo de resposta deste grupo de experimentos éinferior ao dos demais grupos.

Os grupos Direct-Stateless e Direct-Stateful apresentaram um comportamento bastantesimilar em todos os experimentos, visto que não há muita diferença entre eles. Já o grupo deexperimentos Elastic-Clustered-Stateful apresentou comportamento similar as Figuras 4.3a, 4.3be 4.3c, apresentando um ponto de saturação inferior apenas no gráfico mostrado na Figura 4.3d.

4.3 Discussão

Pudemos verificar que o grupo de experimentos Elastic-Clustered-Stateless apresentouo melhor desempenho para todos os valores de número de clientes e número de iterações, nocenário testado. Este comportamento era esperado, pois neste grupo a carga de trabalho do clienteé distribuída entre vários servidores virtuais, utilizando mecanismos eficientes de balanceamentode carga.

Foi possível observar também a redução no tempo de resposta proporcionado pelaadição de novos nós à infraestrutura durante os experimentos do grupo Elastic-Camid-Stateless,mostrando que os mecanismos de coordenação e balanceamento de carga do eCaMid podemresponder rapidamente à adição de novos nós. Contudo, os picos no tempo de resposta queocorreram nos gráficos 4.3a, 4.3c e 4.3d, mostram o custo de coordenação relacionado à adição denovos nós. No entanto, estes picos, em nenhum dos casos, ocasionaram uma perda significativado desempenho ao longo do experimento.

O grupo de experimentos Elastic-Clustered-Stateful, não apresentou uma melhora signifi-cativa nos tempos de resposta, a não ser quando foi utilizado um valor de 64000 para o parâmetronúmero de iterações. Esta diferença tornou-se mais evidente conforme o número de clientes seaproximava do maior valor, ou seja, 200 clientes. O ganho no tempo de resposta foi ocasionadopelo uso dos mecanismos de balanceamento de carga, visto que o sistema como um todo possuíaum ponto de saturação menor para esta métrica. Já a vazão do sistema não foi afetada, mesmoquando foram usados os maiores valores dos parâmetros de número de iterações e númerosclientes.

Contudo, torna-se evidente que o mecanismo de compartilhamento de estado entre osnós tem um grande impacto sobre o desempenho do middleware, especialmente se comparado aogrupo de experimentos Elastic-Clustered-Stateless, uma vez que este grupo apresentou valoresmenores de tempo de resposta e maiores de vazão em todos os experimentos realizados. Estecusto é compensado pela capacidade de manter o estado do sistema acessível a todos os nósconforme estes são adicionados à infraestrutura e ao mesmo tempo evitar que este estado sejaperdido em caso de desligamento de um nó.

818181

5Trabalhos Relacionados

Neste capítulo, serão explicados os vários trabalhos que estão relacionados ao eCaMid.Serão examinadas as tecnologias usadas pelo eCaMid para prover seus mecanismos de coorde-nação e compartilhamento de estado. Ao mesmo tempo, discutiremos os vários trabalhos demiddleware desenvolvidos nos últimos anos que tem como foco o desenvolvimento e integraçãoe gerenciamento de aplicações no ambiente de computação em nuvem.

5.1 Tecnologias fundamentais usadas pelo ElasticCamid

Na capítulo 3, nós citamos algumas tecnologias que são usadas como blocos básicospara os mecanismos de coordenação e compartilhamento de estado do eCaMid: JGroups,que fornece blocos básicos para implementação de comunicação em grupo (MONTRESOR;DAVOLI; BABAOGLU, 2001); e Infinispan, um Datagrid que provê uma API chave-valor paraarmazenamento de objetos, com suporte a transações, queries, transações, expiração e revogaçãode dados (MARCHIONI, 2012).

5.1.1 JGroups

JGroups (MONTRESOR; DAVOLI; BABAOGLU, 2001) é um toolkit que permite autilização de comunicação em grupo em uma aplicação distribuída. JGroups implementa opadrão Object Group (MAFFEIS et al., 1996), oferecendo para a aplicação um conjunto decallbacks que são utilizados para implementar operações específicas de comunicação em grupo,como criação de View, compartilhamento de estado, recepção de mensagens e detecção de falhas.

Um dos componentes principais fornecidos pelo JGroups, é chamado de JGroups (BAN;BLAGOJEVIC, 2013). Através do JGroups é possível criar uma conexão a um grupo existente,obter o endereço dos membros existentes, incluindo o próprio endereço e enviar mensagenspara os demais membros. As callbacks de comunicação de grupo são registradas pela aplicaçãoatravés do JGroups.

O JGroups depende de uma pilha de protocolos que, quando agrupados, oferecemum conjunto de funcionalidades a aplicação. Os primeiros protocolos da pilha do JGroups

5.1. TECNOLOGIAS FUNDAMENTAIS USADAS PELO ELASTICCAMID 82

estão relacionados à camada de transporte da pilha de protocolos TCP/IP, e incluem suporte aTCP e UDP. Logo acima dos protocolos de transporte, existem os protocolos de descoberta demembros, responsáveis por realizar o bootstrapping da comunicação em grupo e detecção denovos membros. Os próximos protocolos da pilha oferecem funcionalidades auxiliares comodescoberta de nós indisponíveis, fragmentação e ordenamento de mensagens, garbage collectionde mensagens recebidas e outros. Acima destes protocolos auxiliares, estão os serviços degerenciamento de grupo, que adicionam ou removem membros de um grupo e acionam oscallbacks de mudança na View.

Acima dos protocolos e JGroups, JGroups também oferecem um conjunto de blocosbásicos, que permitem a utilização das seguintes funcionalidades: comunicação request-replysíncrona ou assíncrona com o uso de Futures, com suporte a unicast e multicast; serviçosde locking e contador distribuídos; execução de jobs em cluster; e finalmente, tabelas hashdistribuídas.

Apesar de prover inúmeras funcionalidades, vários recursos do JGroups são bastantecomplexos, e por isso, de difícil utilização em uma aplicação de mais alto nível. O JGroups éútil como parte da camada infraestrutura de um middleware mais complexo (MONTRESOR;DAVOLI; BABAOGLU, 2001). O eCaMid utiliza o JGroups justamente neste tipo de situação,onde provê abstrações de mais alto nível como objetos remotos, tarefas e subscribers, e criando a"cola"necessária para utilizar o JGroups para seus mecanismos de comunicação e coordenaçãode nós de forma transparente para a aplicação.

5.1.2 Infinispan

Mencionamos no capítulo 3, que o Storage Service do eCaMid utiliza o Infinispan

(MARCHIONI, 2012) para criar uma série de repositórios distribuídos que são utilizados peloscomponentes Naming Service, Management Services (Local Manager e Global Manager) eLifecycle Manager. O Infinispan é utilizado por servidores de aplicação como o JBoss Application

Server (CHAUDHARY et al., 2014) para prover mecanismos de cache e armazenamento dedados (como sessões HTTP) em memória, em um ambiente distribuído (SURTANI et al., 2014).

O Infinispan utiliza o JGroups em sua camada de infraestrutura para prover mecanismosde comunicação Peer-to-Peer (P2P) entre nós de um cluster. A partir desta camada de comu-nicação, o Infinispan oferece suporte a replicação de dados, transações distribuídas, queries emecanismos de expiração de dados. O infinispan pode ser executado como um banco de dadosdistribuído, ou pode ser funcionar de forma embarcada em uma aplicação.

O infinispan possui três modos de funcionamento: replicação, invalidação e distribuição.No modo de replicação, toda informação armazenada em um nó é replicada a todos os demaisnós de um cluster. Este modo de funcionamento depende da utilização de mecanismos demulticast fornecidos pelo JGroups. A escalabilidade do modo replicação é comprometida àmedida que mais nós são adicionados ao cluster Infinispan, visto que o custo de sincronização

5.2. TRABALHOS DE MIDDLEWARE DESENVOLVIDO PARA NUVEM 83

das informações torna-se mais alto.No segundo modo de operação, invalidação, o Infinispan não compartilha o estado com

outros nós, mas opera como um cache para um banco de dados externo. Objetos extraídos dobanco de dados externo são armazenados localmente na memória de um nó. Caso o objetoseja atualizado no banco de dados, uma mensagem de invalidação é enviada para os nós quearmazenam o objeto na memória, que removem o objeto do cache.

No modo de distribuição, o Infinispan utiliza uma função de hashing para determinar emque nós uma determinada informação será armazenada. Quando a aplicação armazena um objetoatravés da API chave-valor, a função de hashing é aplicada a chave. O hash gerado é utilizadopara determinar a que segmento o objeto será armazenado. A cada segmento é designado umcerto número de nós, chamados de donos. Um dos donos é chamado de dono primário, e osdemais são chamados de donos backup. Logo, caso um dono primário torne-se indisponível, umdos donos backup assumirá o lugar de dono primário.

Um conjunto de segmentos constituem um espaço espaço de chave. O tamanho doespaço de chave é configurável, mas adota um valor de 100 segmentos por padrão. À medida quenovos nós são adicionados ou removidos de um cluster, o Infinispan distribui os nós existentesde forma homogênea entre os segmentos. A função de hashing utilizada para mapear chaves deobjetos tende a distribuir de forma igual os objetos entre os segmentos existentes. Isso é possívelporque o Infinispan utiliza uma função de hashing consistente, que é comum em implementaçõesde Distributed Hash Tables (DHTs) encontrados na literatura (SHEN; XU, 2008) (GUPTA et al.,2003).

O modo distribuído do Infinispan permite que este possa manter a escalabilidade mesmoque milhares de nós sejam adicionados à infraestrutura, visto que o estado de um objeto éreplicado apenas para uma fração dos nós do cluster. O eCaMid adota, por padrão, o Infinispan

em seu modo distribuído e embarcado, visando simplificar o processo de implantação do mesmoe tornar possível que sejam adicionados milhares de nós à infraestrutura do middleware.

5.2 Trabalhos de Middleware Desenvolvido para Nuvem

É possível encontrar na literatura um grande número de trabalhos sobre middlewarepara computação em nuvem. Estes trabalhos costumam abordar vários temas incluindo: umaarquitetura geral para middleware no contexto de computação em nuvem (ABBADI, 2011a)(ABBADI, 2011b); multi-tenacidade, ou a capacidade de compartilhar uma mesma infraestruturaou plataforma com múltiplas aplicações (AZEEZ et al., 2010) (KäCHELE; HAUCK, 2013);interoperabilidade, seja por criar uma plataforma interoperável entre múltiplos provedores(MAXIMILIEN et al., 2009) (MERLE; ROUVOY; SEINTURIER, 2011), ou criando meioseficientes de comunicação entre nuvens (AMIN et al., 2012); elasticidade (RANJAN et al., 2010)(JAYARAM, 2013), seja através de mecanismos que suportam a adição dinâmica de recursosà infraestruta de nuvem ou o provisionamento automático de nós; requisitos não funcionais de


aplicações na nuvem, criando mecanismos de suporte à segurança e confiabilidade (CAMPBELL;MONTANARI; FARIVAR, 2012), tolerância a falhas (BEHL et al., 2012).

Nas próximas subseções, serão explicados esses vários trabalhos e seu relacionamentocom o eCaMid, discutindo seus pontos em comum e suas diferenças. Será também exploradocomo o eCaMid pode evoluir com base nos mecanismos apresentados nos mesmos trabalhos.

5.2.1 Arquitetura Geral de Middleware

ABBADI (2011b), em seu trabalho, cita que a nuvem pode ser dividida em três camadas:a camada física representa os servidores físicos, sistemas de armazenamento e rede de compu-tadores; a camada virtual consiste nos recursos virtuais que são operam sobre a camada física;por fim, a camada de aplicação contém as aplicações que são hospedadas na nuvem atravésda camada virtual. Além destas três camadas horizontais, temos verticalmente a camada dearmazenamento de dados, rede e servidores. Middleware serve como cola entre estas camadas,provendo serviços de adaptabilidade, resiliência, escalabilidade, disponibilidade e segurança.

Quatro elementos definem os objetivos da camada virtual, propriedades do usuário in-cluem requisitos da camada virtual que devem ser definidos pelo usuário, como característicasde máquinas virtuais e armazenamento, SLAs, segurança e privacidade. Propriedades da infra-estrutura são capacidades definidas pelos arquitetos da solução de nuvem, que compreendemdistribuição, redundância, confiabilidade e conectividade. Políticas de infraestrutura definemcontroles para os operadores da nuvem. Mudanças e Incidentes representam mudanças naconfiguração da camada virtual.

Além desses elementos, ABBADI (2011b) definiu que serviços de middleware da camadavirtual devem possuir um conjunto de funções. A primeira, a adaptabilidade, consiste em definirum conjunto de ações em resposta a mudanças de configuração, que podem ser resultados defalhas de componente, realocação e aumento de demanda. Estas ações acionam as capacidadesde escalabilidade, que instrui um aumento vertical (mais capacidade para um componente) ouhorizontal (mais componentes) na infraestruturavirtual. Parte das ações da função de adaptabili-dade ativam a função chamada de arquiteto do sistema, que por sua seleciona uma arquiteturapara a adaptação que deve ser realizada, com base na escalabilidade, gerenciamento de processose redundância. O arquiteto do sistema aciona a função de resiliência, que representa ações deadministradores do sistema, fazendo com que a comunicação entre servidores e dispositivos derede mantenham a comunicação e mesmo em caso de falha. A função de resiliência oferecesuporte às funções de confiabilidade, responsável por manter a integridade do sistema evitandoque dados ou informações sejam perdidos, e disponibilidade, que possui distribui requisições eoferece caminhos redundantes de comunicação entre os componentes da infraestrutura virtual.

Os serviços de middleware na camada de aplicação devem implementar funções seme-lhantes – adaptabilidade, escalabilidade, resiliência, disponibilidade e confiabilidade –, masvoltadas para o gerenciamento de recursos virtuais (ABBADI, 2011a). Três tipos de middleware


podem ser usados na camada de aplicação para suportar estas funções. O Server Backend

Middleware suporta sistemas de armazenamento em máquinas virtuais dedicadas. O Server

Middle-tier Middleware suporta servidores de aplicação e web, que podem ser combinadosde diferentes formas, e executados sobre uma mesma ou múltiplas máquinas virtuais. Já oClient Frontend Middleware é responsável por tornar o acesso ao Server Middle-tier Middleware

transparente.O eCaMid pode ser classificado como um middleware da camada de aplicação. Sua

arquitetura possui uma parte cliente e uma parte servidor, que podem representar, respectivamente,Client Frontend Middleware e o Server Middle-tier Middleware. O eCaMid implementa asfunções de resiliência, através do protocolo do Naming Service, disponibilidade, através do Load

Balancing Service e Group Communication Framework e confiabilidade através do Storage

Service.

5.2.2 Multitenancy

Multitenancy é a capacidade de múltiplos tenants fazerem uso do mesmo recurso deforma isolada e independente. No caso de middleware para nuvem, múltiplas aplicações oumódulos podem compartilhar de um mesmo conjunto de máquinas virtuais, ou de um conjuntode nós de um middleware. A implementação atual do eCaMid não possui suporte a multitenancy.O uso de multitenancy, no entanto, beneficiaria este middleware, por oferecer mecanismos desuporte mais granulares à elasticidade.

AZEEZ et al. (2010), em seu trabalho, propõe um middleware baseada em SOA paradesenvolvimento e execução de serviços e composições utilizando multitenancy. Aplicações emSOA, neste contexto, podem ser divididos em execução, segurança e dados. A parte de execuçãoconsiste de vários Web Services e composições dos mesmos em Workflows e Mashups. Dadossão armazenados através de bancos de dados e outros sistemas de armazenamento e usadospelos elementos de execução. Segurança pode ser definida através de serviços de autenticação,autorização, não-repudiação e confiabilidade que são ortogonais aos elementos de execução edados.

O middleware proposto por AZEEZ et al. (2010) chama-se WSO2 Carbon. No cernedo middleware, há módulo central, chamado de Core, um motor que é responsável pelo car-regamento, linking e execução de componentes de aplicação e gerenciamento do middleware,baseados no padrão Open Service Gateway initiative (OSGi). Web Services das aplicações sãodisponibilizados como bundles OSGi e gerenciados pelo Core. Um módulo Security disponi-biliza para a aplicação serviços de gerenciamento de usuários, autenticação e autorização. Oisolamento entre diferentes aplicações é provido através do módulo de Service Execution, queimpede que as execuções e dados de cada tenant se mantenham isolados, protegendo-os porexemplo, do uso de código malicioso para alterar o comportamento dos serviços. O módulo Data

Access provê uma abstração para acesso a registros e repositórios de dados do Core, incluindo


localização de serviços. Da mesma forma que o Service Execution o módulo de Data Access

provê isolamento de acesso entre diversos tenants. Todos estes módulos são executados sobre ummotor de execução chamado de Apache Axis2, que permite a implantação de vários componentes.

No trabalho desenvolvido por KäCHELE; HAUCK (2013), foi desenvolvido um mid-dleware com suporte a multitenancy chamado COSCA que usa um modelo de programaçãoinspirado em OSGi. Este middleware introduz um conceito chamado de frameworks virtuali-

zados, que tem a capacidade de mapear um conjunto de bundles em uma aplicação, onde cadaaplicação é mantida de forma isolada. Múltiplos frameworks são executados sobre uma mesmaJava Virtual Machine (JVM), de forma isolada, em múltiplos classloaders sob a gerência de umsecurity-manager. Cada JVM é executada sobre um servidor físico separado, sem a necessidadede uma intermediação de uma camada de IaaS. O COSCA, desta forma, constitui um PaaS queopera diretamente sobre uma plataforma de hardware.

Esta plataforma também mantém um componente chamado Distributed Service Registry,que funciona como um componente central utilizado para registrar serviços de aplicaçõescadastrados em cada nó, como um serviço de Lookup. Cada JVM mantém um serviço demonitoramento que verifica a utilização decada componente de uma aplicação através da mediçãodo uso de CPU e chamada de serviços. Quando um componente está consumindo uma grandequantidade de recursos, ele é implantado em outro nó, com replicação. Quando uma única JVMestá com todos os seus recuros exauridos, um dos componentes da aplicação é migrado paraoutro nó. A implantação é possível graças a um serviço de provisionamento compatível comOSGi (KäCHELE; HAUCK, 2013).

O COSCA, possui algumas limitações quanto acoplamento entre diferentes componentesde uma mesma aplicação (KäCHELE; HAUCK, 2013). Há situações em que estes componentesnão podem ser migrados e replicados separadamente. Por isso a estrutura deles é investigada, ecaso seja detectado um forte acoplamento entre os mesmos, estes são tratados como um únicocomponente. O middleware também não oferece suporte a compartilhamento de estado, o quelimita o potencial de escalabilidade por dificultar a replicação e composição de componentesda aplicação. A estratégia utilizada neste caso é implementar o compartilhamento de estadoatravés de uma base de dados externa, como um banco de dados relacional ou um serviço decoordenação como o Zookeeper (APACHE ZOOKEEPER, 2014).

Em ambos os trabalhos foi constante a presença da tecnologia OSGi para implementarmecanismos de modularização e multi-tenacidade. Um subsistema OSGi poderia ser adicionadoao núcleo do eCaMid e definir serviços que garantam a segurança e isolamento de aplicações.Este mecanismo poderia implementado no eCaMid para para oferecer um controle de elasticidademais granular, onde múltiplas aplicações compartilham do mesmo conjunto de máquinas virtuais.

Da mesma forma, o COSCA poderia se beneficiar dos mecanismos de balanceamentode carga e compartilhamento de estado do eCaMid, que tornaria o serviço mais adequado àimplantação em máquinas virtuais e não dependeria de mecanismos armazenamento de estado ecoordenação externos.


5.2.3 Interoperabilidade

A interoperabilidade, no contexto de computação em nuvem, pode ter dois significados:um mecanismo de comunicação destinado a integrar diferentes aplicações executadas em múlti-plas nuvens; uma plataforma que possa ser executada por muitas linguagens de programação,em diversos provedores diferentes de nuvem.

O trabalho desenvolvido por AMIN et al. (2012) constitui o primeiro tipo de interope-rabilidade. O Intercloud Message Exchange Middleware (ICME) é um middleware que utilizaum padrão de comunicação por troca de mensagens e presença, chamado de Data Distribution

Service (DDS), desenvolvido pelo Object Modeling Group (OMG). O serviço DDS depende deum componente chamado de Global Data Space (GDS), que funciona como um ponto centralpara o registro de tópicos, em um estilo de comunicação Publish/Subscribe, que desacopla osparticipantes da comunicação.

O ICME extende as funcionalidades providas pelo DDS, através da definição de ummodelo de informação que reflete um cenário de computação em nuvem. Os participantesdo modelo de informação fornecido pelo ICME são chamados de entidade. Um dos tipos deentidade é chamado de Message, que por sua vez pode ser de do tipo Request e Response. Aentidade define os tipos possíveis de mensagem é denominado MessageType, e consiste emuma enumeração que possui uma entrada específica para cada mensagem. Cada mensagem serelaciona com uma QoS Policy, que é definida através de um conjunto de QoS Parameters.

A entidade chamada Resource Description contém uma descrição de todos os recursosda nuvem sob uma representação em forma de ontologia, descrito através do formato Web

Ontology Language (OWL) (AMIN et al., 2012). A ontologia armazenada por esta entidadereflete a estrutura de implantação da nuvem, com cada nível hierarquia representando um objetodiferente como fornecedor, middleware,aplicação, capacidade, sistema operacional e outros.Esta ontologia é usada em conjunto com QoS Policies, que identificam o melhor caminho para aentrega de um Message para um Subscriber específico.

O modelo de comunicação oferecido pelo ICME é próprio para interação entre aplicaçõescujas partes são executada em domínios distintos. O eCaMid, em contrapartida foi pensado paraser executado em uma única nuvem, como um cluster único. O ICME poderia ser utilizadocomo intermediário de múltiplos clusters do eCaMid, cada um implantado em um conjunto derecursos diferentes, como, por exemplo, diferentes provedores de nuvem presentes em uma únicafederação.

O segundo tipo de interoperabilidade é implementado pelo middleware conhecido comoIBM Altocumulus (MAXIMILIEN et al., 2009). O IBM Altocumulus visa tornar possívela implantação de uma aplicação sobre múltiplos provedores de IaaS públicos (i.e. AWS),provedores de PaaS (i.e. GAE) e nuvens privadas (como Eucalyptus). Além dos provedores denuvem, o middleware também visa a implantação de aplicações em diferentes linguagens de


programação e frameworks, como Ruby on Rails 1, Python/Django 2, JavaEE3 e Hadoop 4. Porsuportar esses diferentes frameworks, o Autocumulus visa execução de diferentes tarefas emmúltiplas nuvens, como é o caso de criar instâncias, executar imagens e configurar componentes.Também é objetivo do middleware permitir a repetição da execução das mesmas tarefas, regras etopologias em múltiplas nuvens, assim como a capacidade de monitorar métricas que medem odesempenho das aplicações.

A arquitetura do Altocumulus é composto de um dashboard, que define uma interfacepara usuários do middleware, destinadada a definir as melhores práticas de implantação deaplicações e gerenciar as credenciais de acesso à diferentes provedores de nuvem. A API eo API Tester são componentes que expõem a API Representational state transfer (REST) doAltocumulus. O Core é um componente que implementa a API, que é usada pelo Dashboarde as aplicações dos usuários. O Core contém um conjunto de scripts, regras e adaptadores denuvem que permitem a execução de ações em múltiplas nuvens para diferentes tipos de usuários(MAXIMILIEN et al., 2009).

O eCaMid, assim como o Altocumulus, foi pensado como uma plataforma que pudesseser implantada em diversos provedores de nuvem. O eCaMid no entanto, tem um escopo maisrestrito, por ser pensado como um middleware que deve ser implantado em nuvens do tipoIaaS para apoiar o desenvolvimento de aplicações orientadas a objeto que sejam compatíveiscom a tecnologia Java. No entanto, como o eCaMid é um middleware orientado a objetos, suaprincipal função é fornecer um modelo de programação para aplicações de nuvem, enquanto oAltocumulus provisiona e configura diferentes aplicações em diferentes tipos de nuvens diferentes.O Altocumulus e o eCaMid poderiam funcionar de forma complementar, onde o primeiro seriausado para provisionar e configurar o segundo em diferentes provedores e máquinas virtuais.

5.2.4 Elasticidade

A elasticidade é uma característica bastante peculiar ao modelo de computação em nu-vem. A elasticidade é a capacidade de diminuir ou aumentar os recursos de nuvem de acordo coma demanda da aplicação, evitando os riscos associados ao subdimensionamento e superdimensi-onamento da infraestrutura. Para que um middleware ofereça suporte a elasticidade, ele deveapresentar meios para que a aplicação continue funcionando em decorrência da reconfiguraçãodinâmica da infraestrutura ou que o middleware forneça serviços específicos que gerencie deforma ativa a elasticidade, com a implantação e desligamento de outros nós. Os trabalhos queserão mostrados a seguir procuram atender pelo menos uma dessas características.

RANJAN et al. (2010), em seu trabalho, desenvolveu um middleware baseado em umaarquitetura P2P cuja finalidade é auxiliar na descoberta de serviços, provisionar aplicações em

1http://rubyonrails.org/2https://www.djangoproject.com/3http://www.oracle.com/technetwork/java/javaee/overview/index.html4http://hadoop.apache.org/


nós específicos da infraestrutura de nuvem e proporcionar um mecanismo de balanceamento decarga. A vantagem do uso de plataformas P2P no contexto de elasticidade é a sua capacidadede se manter funcional mesmo em decorrência de desligamento e ativação de novas máquinasvirtuais, e de conter mecanismos de comunicação de alta escalabilidade.

O middleware conhecido como Cloud Peers é parte de uma oferta de PaaS e é compostode três camadas. A primeira camdada consiste em uma infraestrutura de roteamento auto-organizável baseada em DHT, fornecendo um overlay para diversas máquinas virtuais, mantendouma tabela de roteamento para cada endereço IP de um peer. A segunda camada oferecemecanismos de organização de dados, índices distribuído e replicação. Estes índices suportam oarmazenamendo de chaves e queries multidimensionais, onde cada registro é armazenado emmúltiplos nós, evitando a perda de informação em caso de falha de um peer. A terceira consisteem serviços de descoberta de nós, coordenação e troca de mensagens. Através dos serviços daterceira camada, são registrados as máquinas virtuais existentes, os serviços publicados em cadaum e mecanismos de troca de mensagens baseado no padrão Publish/Subscribe (RANJAN et al.,2010).

O eCaMid também utiliza um mecanismo de comunicação P2P para localizar e coordenardiversos nós baseada em JGroups, mas que funciona de forma diferente de uma DHT. eCaMid eo Cloud Peers também diferem por suas finalidades. O principal foco do eCaMid é proporcionarum modelo de programação baseado em objetos distribuídos. Já a finalidade do Cloud Peers éprover mecanismos eficiente de provisionamento de aplicações em máquinas virtuais e oferecerserviços de localização e coordenação.

Um outro trabalho tem a finalidade de prover serviços de elasticidade (JAYARAM, 2013).O middleware chamado de ElasticRMI fornece uma extensão ao middleware Remote Method

Invocation (RMI), um middleware orientado a objetos que é parte do núcleo da linguagem java.O ElasticRMI define um conceito de um Elastic Object Pool, um conjunto de objetos

(baseados no padrão Object Group), que está distribuído em diferentes nós de uma infraestrutura.Invocações direcionadas a um dos objetos presentes no Elastic Object Pool são direcionadas aosdemais membros, como um mecanismo de balanceamento de carga. Um sistema de armazena-mento chamado Hyperdex (HYPERDEX, 2014) é usado para armazenar o estado dos objetosdistribuídos. Um framework de gerenciamento de cluster, chamado Apache Mesos (APACHEMESOS, 2014), é responsável por distribuir processos de um Elastic Object Pool entre váriasmáquinas físicas ou virtuais (JAYARAM, 2013).

O eCaMid e o ElasticRMI são bastante semelhantes, pois ambos são middlewaresorientados a objetos que visam manter serviços de suporte à elasticidade. Ambos utilizam opadrão de projeto Object Group para distribuir requisições remotas entre diversos nós.

Algumas características, no entanto, diferenciam o eCaMid e o ElasticRMI. Enquantoo balanceamento de carga realizado pelo ElasticRMI é realizado para um grupo formado porum conjunto de objetos semelhantes, o mesmo mecanismo, no eCaMid, é realizado para umgrupo de nós semelhantes de uma mesma infraestrutura. Um nó do eCaMid pode conter vários


objetos distribuídos, que possuem alguma dependência entre si. O eCaMid também suportaestilos de comunicação Publish/Subscribe e a coordenação de tarefas periódicas em um cluster.O sistema de armazenamento e coordenação utilizado pelo eCaMid utiliza um modelo P2P queé embarcado no próprio middleware visando facilitar o deployment e configuração, enquantoo ElasticRMI depende de serviços instalados externamente como o Hyperdex e Apache Mesos.Estes serviços também precisam ser provisionados e dimensionados visando os requisitos nãofuncionais de escalabilidade, desempenho e disponibilidade para que o ElasticRMI possa adquirirestas mesmas características.

O ElasticRMI, no entanto, é capaz de realizar o redimensionamento do tamanho de umElastic Object Pool dinamicamente, baseado em métricas de desempenho. Embora provedoresde nuvem, tipicamente, não possuam instalações nativas de um framework como Apache Mesos,este poderia ser útil como parte de uma oferta de PaaS. O eCaMid ainda carece de um mecanismosemelhante, e poderia se beneficiar de ferramentas de provisionamento e implantação.

5.2.5 Outros requisitos não funcionais de nuvem

Diferentes requisitos não funcionais de computação em nuvem podem motivar o desenvol-vimento de arquiteturas e a criação de serviços de middleware. Entre os requisitos mencionadosnesta seção, temos segurança, confiabilidade e tolerância à falhas.

O trabalho desenvolvido por CAMPBELL; MONTANARI; FARIVAR (2012) defineuma arquitetura de middleware para aplicações de missão crítica executadas em um ambientede computação em nuvem. Estes ambientes precisam suportar requisitos restritos de segurança,disponibilidade e desempenho em tempo real. Aplicações de missão crítica precisam ser so-bretudo confiáveis, com a garantia que determinada operação foi realmente concluída em umintervalo predeterminado. Para que seja possível garantir estes requisitos, deve ser possívelutilizar mecanismos de monitoramento robustos, que possam identificar de forma imediata econfiável problemas de segurança e disponibilidade. Ao mesmo tempo este middleware demissão crítica precisa de agentes que respondam de imediato à violações detectadas.

O middleware for assured clouds contém um subsistema composto por agentes querecebem eventos de diversas fontes, sejam estas externas como é o caso de switches openflow,dispositivos que utilizam o protocolo Simple Network Management Protocol (SNMP) (roteadorese switches) e Intrusion Detection Systems (IDSs), ou de fontes internas, que utilizam agregadoresde evento que fazem parte da infraestrutura do middleware. Estes eventos coletados por um agentesão encaminhados a um motor de inferência de regras interno ao próprio agente, que verificamproblemas de conformidade. Caso seja detectado uma violação de conformidade, estes devemnotificar os componentes que administram os sistemas de comunicação, gerando mudançasna configuração e comportamento, impedindo que novos erros sejam repetidos (CAMPBELL;MONTANARI; FARIVAR, 2012).

O eCaMid não foi pensado no contexto de aplicações de missão críticas, e não é meta


de seu desenvolvimento e evolução garantir estes requisitos. No entanto, os agentes de monito-ramento descritos por CAMPBELL; MONTANARI; FARIVAR (2012) poderiam ser providoscomo módulos externos ao eCaMid, para satisfazer os requisitos não funcionais de aplicaçõesespecíficas.

BEHL et al. (2012), em seu trabalho, definiu uma solução para execução de diferentesworkflows baseados em web services, com suporte a tolerância a falhas. No núcleo da soluçãodesenvolvida, há um motor de processos de negócio compatível com a linguagem Business

Process Execution Language (WS-BPEL). Um processo de negócio é um fluxo de ações denegócio complexas que invocam capacidades específicas de diversos web services, estes querealizam operações de negócio de maior granularidade.

Motores WS-BPEL precisam guardar dados intermediários, tratar exceções e expressarfluxos de execução. No entanto, infrastruturas tradicionais que utilizam esta tecnologia sãodeficientes em mecanismos de tolerância a falhas. Para solucionar o problema, os motoresWS-BPEL e web services precisam ser replicados. Os web services, em particular, devemser acessados através de proxies, que usam um serviço de coordenação externo, o Zookeeper

(APACHE ZOOKEEPER, 2014). Este serviço de coordenação serve para armazenar configuraçãoe informação relevante para o sistema, detectar quando algum dos nós falha e realizar a ordenaçãodas requisições (BEHL et al., 2012). Uma definição de processo de negócio, ao ser carregadapelo motor WS-BPEL, deve ser transformada para incluir estes proxies no lugar de chamadasdiretas aos webservices. As requisições entregues pelos motores de regra de negócio aos webservices devem conter uma semântica de At Most Once, para assegurar que uma operação denegócio tenha sido realizada múltiplas vezes em um fluxo BEHL et al. (2012).

Assim como o eCaMid, o trabalho desenvolvido por BEHL et al. (2012) faz uso de ummecanismos de coordenação de processos, neste caso o Zookeeper. O Zookeeper, no entanto,atua de forma externa à aplicação, implantado como um conjunto de processos independentes.

5.2.6 Discussão

Foi possível observar nas subseções anteriores vários trabalhos que utilizam middlewarepara implementar várias funcionalidades como multitenancy, interoperabilidade, elasticidade edar apoio a outros requisitos não funcionais de aplicações distribuídas. Muitos dos middlewaresdesenvolvidos por estes trabalhos, no entanto, nem são middlewares orientados a objeto, nempossuem foco em modelos de programação distribuídos.

Apenas parte desses trabalhos possuem implementação e foram testados em uma nuvemreal, como o eCaMid. Alguns dos trabalhos de middleware desenvolvidos nestas pesquisaspossuem mecanismos bastante similares aos implementados no eCaMid, mas que se diferenciampor abordar estratégias diferentes ou modelos de programação distintos. Através deste estudo,também foi possível verificar vários pontos de melhoria e avanços a serem implmentados emtrabalhos futuros.


5.2.7 Considerações finais

Neste capítulo, foram listadas as tecnologias usadas pelo eCaMid para implementar seusmecanismos de coordenação e compartilhamento de estado. Em seguida, foram mencionadosvários trabalhos que visam a utilização de middleware para implementar várias funcionalidadescomo multitenacidade, interoperabilidade, elasticidade e dar apoio a outros requisitos nãofuncionais. Uma breve discussão foi iniciada para elicitar a motivação do desenvolvimento doeCaMid.

939393

6Considerações Finais

Os primeiros capítulos explicaram as principais motivações para o desenvolvimentodo eCaMid e as ideias básicas que fundamentam os conceitos utilizados na concepção da suaarquitetura. Foram explicados os principais conceitos de computação em nuvem e elasticidade.Também foi realizado um estudo sobre os padrões arquiteturais e de projeto, e seus relaciona-mentos, para definir os blocos básicos e uma linguagem padrão para os componentes do projetodo eCaMid.

O terceiro capítulo introduziu os aperfeiçoamentos realizados à arquitetura original,para aprimorar o suporte à elasticidade. Como contribuições principais do eCaMid, podemosmencionar o uso de mecanismos de coordenação, replicação e balanceamento de carga, quevisam aumentar a escalabilidade do middleware quando novos nós são adicionados, e continuarfuncionando quando esses nós são desligados. Adicionalmente, o eCaMid introduziu novasfuncionalidades (tarefas periódicas, e comunicação Publish/Subscribe) que aumentam o escopodo eCaMid para tipos de carga de trabalho que são complementares ao estilo de comunicação demiddlewares orientados a objetos e são relevantes para o paradigma de computação em nuvem.

Uma avaliação experimental foi usada, no quarto capítulo, para avaliar o comportamentodo eCaMid em diferentes cenários. Dada as condições do experimento, os mecanismos debalanceamento de carga do eCaMid mostraram um melhor resultado quando foram utilizadosobjetos remotos que não possuem estado. Quando esses objetos remoto possuem estado, asincronização deste entre vários nós apresentou uma perda considerável de desempenho, mas emcontrapartida, tornou possível que o mesmo objeto fosse acessado consistentemente entre váriosnós.

No quinto capítulo, foi realizado um breve estudo sobre os trabalhos de middleware queforam desenvolvidos para a nuvem. Foram identificados diversos pontos comuns e divergentesentre o eCaMid e esses trabalhos, assim como estratégias usadas nestes que podem servir comomelhorias para o eCaMid em trabalhos futuros.

Através deste trabalho foi possível criar um middleware orientado a objetos que é capaz deutilizar a elasticidade de um ambiente de nuvem para aprimorar seus mecanismos de distribuição.Este middleware se baseou mas melhores práticas para o desenvolvimento de aplicações na

6.1. TRABALHOS FUTUROS 94

nuvem, levando em conta as peculiaridades deste ambiente e desenvolveu mecanismos de suporteà elasticidade dentro do próprio middleware.

Ainda que o eCaMid careça da mesma maturidade de outras soluções de middlewaredo mercado e da academia, este pode servir como prova de conceito para implementação demecanismos de suporte à elasticidade em outras plataformas mais maduras. Os mecanismosusados neste trabalho podem também ser adaptados para outros tipos de modelo de comunicação,como é o caso de servidores web, balanceadores de carga inteligentes e servidores de aplicação.

6.1 Trabalhos Futuros

A evolução do eCaMid pode ser realizada em diversas direções. O sistema atual desincronização de estado do eCaMid é limitado pelas capacidades do Infinispan, que provê asabstrações necessárias para a implementação de um serviço de armazenamento em memóriadistribuído. O eCaMid pode ser expandido para utilizar outros key-value stores distribuídos,como é o caso do Redis1 e Memcached2. O desempenho destas soluções de armazenamentopode ser comparado e avaliado em que cenários cada uma dessas tecnologias apresenta o melhorresultado.

O suporte à elasticidade pode ser aprimorado através da implementação de um serviçoque realize a implantação e provisionamento de máquinas virtuais de forma automática, com baseem parâmetros de qualidade coletados a partir dos componentes de gerenciamento do eCaMid.O uso de multitenancy possibilitará um controle mais granular sobre a elasticidade, provendoisolamento a múltiplas aplicações em um mesmo cluster do eCaMid.

O uso de interoperabilidade entre múltiplas nuvens pode favorecer à implantação doeCaMid em um cenário multi-cluster. Este cenário consiste em um conjunto de clusters queutilizam algum mecanismo de integração (como mensagens assíncronas) e balancemento decarga de acordo garantias de nível de serviço de múltiplos provedores ou distribuição geográfica.

A implementação atual do eCaMid não oferece suporte a mecanismos de segurança. Estaimplementação poderia ser estendida para incluir serviços de autenticação e controle de acessobaseado em políticas e papéis.

1http://redis.io/2http://memcached.org/

959595

Referências

ABBADI, I. Middleware Services at Cloud Virtual Layer. In: COMPUTER ANDINFORMATION TECHNOLOGY (CIT), 2011 IEEE 11TH INTERNATIONALCONFERENCE ON. Anais. . . [S.l.: s.n.], 2011. p.115–120.

ABBADI, I. M. Middleware Services at Cloud Application Layer. In: ABRAHAM, A.et al. (Ed.). Advances in Computing and Communications. [S.l.]: Springer BerlinHeidelberg, 2011. p.557–571. (Communications in Computer and Information Science, v.193).10.1007/978-3-642-22726-4_58.

AMIN, M. B. et al. Intercloud Message Exchange Middleware. In: INTERNATIONALCONFERENCE ON UBIQUITOUS INFORMATION MANAGEMENT ANDCOMMUNICATION, 6., New York, NY, USA. Proceedings. . . ACM, 2012. p.79:1–79:7.(ICUIMC ’12).

APACHE JMeter. Accessed: 2014-04-30, http://jmeter.apache.org/.

APACHE Mesos. Accessed: 2014-07-20, http://mesos.apache.org/.

APACHE Zookeeper. Accessed: 2014-07-15, http://zookeeper.apache.org/.

AZEEZ, A. et al. Multi-tenant SOA middleware for cloud computing. In: CLOUDCOMPUTING (CLOUD), 2010 IEEE 3RD INTERNATIONAL CONFERENCE ON. Anais. . .[S.l.: s.n.], 2010. p.458–465.

BABAR, M. A.; CHAUHAN, M. A. A Tale of Migration to Cloud Computing for SharingExperiences and Observations. In: ND INTERNATIONAL WORKSHOP ON SOFTWAREENGINEERING FOR CLOUD COMPUTING, 2., New York, NY, USA. Proceedings. . . ACM,2011. p.50–56. (SECLOUD ’11).

BAKOUCH, H. S. Probability, Markov chains, queues, and simulation. Journal of AppliedStatistics, [S.l.], v.38, n.8, p.1746–1746, 2011.

BALIGA, J. et al. Green Cloud Computing: balancing energy in processing, storage, andtransport. Proceedings of the IEEE, [S.l.], v.99, n.1, p.149–167, Jan 2011.

BAN, B.; BLAGOJEVIC, V. Reliable group communication with JGroups 3.x. Accessed:2014-06-30, http://www.jgroups.org/manual/html/index.html.

BEHL, J. et al. Providing Fault-tolerant Execution of Web-service-based Workflows WithinClouds. In: ND INTERNATIONAL WORKSHOP ON CLOUD COMPUTING PLATFORMS,2., New York, NY, USA. Proceedings. . . ACM, 2012. p.7:1–7:6. (CloudCP ’12).

BUSCHMANN, F.; HENNEY, K.; SCHMIDT, D. C. Pattern-Oriented SoftwareArchitecture Volume 4: a pattern language for distributed computing (v. 4). [S.l.]: Wiley, 2007.

CALHEIROS, R. N. et al. The Aneka platform and QoS-driven resource provisioning for elasticapplications on hybrid Clouds. Future Generation Computer Systems, [S.l.], v.28, n.6, p.861– 870, 2012. Including Special sections SS: Volunteer Computing and Desktop Grids and SS:Mobile Ubiquitous Computing.

http://jmeter.apache.org/

http://mesos.apache.org/

http://zookeeper.apache.org/

http://www.jgroups.org/manual/html/index.html

REFERÊNCIAS 96

CAMPBELL, R.; MONTANARI, M.; FARIVAR, R. A middleware for assured clouds. Journalof Internet Services and Applications, [S.l.], v.3, n.1, p.87–94, 2012.

CHAUDHARY, N. et al. JBoss Enterprise Application Platform 6.2 Administration andConfiguration Guide. Accessed: 2014-06-30, https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Administration_and_Configuration_Guide/index.html.

DRAGO, I. et al. Inside Dropbox: understanding personal cloud storage services. In: ACMCONFERENCE ON INTERNET MEASUREMENT CONFERENCE, 2012., New York, NY,USA. Proceedings. . . ACM, 2012. p.481–494. (IMC ’12).

EMMERICH, W.; KAVEH, N. Component technologies: java beans, com, corba, rmi, ejb andthe corba component model. In: SOFTWARE ENGINEERING, 2002. ICSE 2002.PROCEEDINGS OF THE 24RD INTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.],2002. p.691–692.

FOX, A. et al. Above the clouds: a berkeley view of cloud computing. Dept. Electrical Eng.and Comput. Sciences, University of California, Berkeley, Rep. UCB/EECS, [S.l.], v.28,p.13, 2009.

FURHT, B. Cloud Computing Fundamentals. In: FURHT, B.; ESCALANTE, A. (Ed.).Handbook of Cloud Computing. [S.l.]: Springer US, 2010. p.3–19.

GAMMA, E. et al. Design Patterns: abstraction and reuse of object-oriented design. In:NIERSTRASZ, O. (Ed.). ECOOP’ 93 — Object-Oriented Programming. [S.l.]: SpringerBerlin Heidelberg, 1993. p.406–431. (Lecture Notes in Computer Science, v.707).

GHOSH, S. Distributed systems: an algorithmic approach. [S.l.]: CRC press, 2010.

GORTON, I. Essential software architecture. [S.l.]: Springer, 2011.

GUPTA, I. et al. Kelips: building an efficient and stable p2p dht through increased memory andbackground overhead. In: KAASHOEK, M.; STOICA, I. (Ed.). Peer-to-Peer Systems II. [S.l.]:Springer Berlin Heidelberg, 2003. p.160–169. (Lecture Notes in Computer Science, v.2735).

HERRICK, D. R. Google This!: using google apps for collaboration and productivity. In:ANNUAL ACM SIGUCCS FALL CONFERENCE: COMMUNICATION ANDCOLLABORATION, 37., New York, NY, USA. Proceedings. . . ACM, 2009. p.55–64.(SIGUCCS ’09).

HOHPE, G.; WOOLF, B. Enterprise integration patterns: designing, building, and deployingmessaging solutions. [S.l.]: Addison-Wesley Professional, 2004.

HOMER, A. et al. Cloud Design Patterns: prescriptive architecture guidance for cloudapplications. [S.l.]: Microsoft patterns & practices, 2014.

HYPERDEX. Accessed: 2014-07-20, http://hyperdex.org/.

JAIN, R. The art of computer system performance analysis: techniques for experimental design,measurement, simulation and modeling. New York: John Willey, [S.l.], 1991.

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.2/html/Administration_and_Configuration_Guide/index.html



http://hyperdex.org/

REFERÊNCIAS 97

JAYARAM, K. Elastic Remote Methods. In: EYERS, D.; SCHWAN, K. (Ed.). Middleware2013. [S.l.]: Springer Berlin Heidelberg, 2013. p.143–162. (Lecture Notes in Computer Science,v.8275).

JIN, H. et al. Tools and Technologies for Building Clouds. In: ANTONOPOULOS, N.;GILLAM, L. (Ed.). Cloud Computing. [S.l.]: Springer London, 2010. p.3–20. (ComputerCommunications and Networks).

KäCHELE, S.; HAUCK, F. J. Component-based Scalability for Cloud Applications. In:INTERNATIONAL WORKSHOP ON CLOUD DATA AND PLATFORMS, 3., New York, NY,USA. Proceedings. . . ACM, 2013. p.19–24. (CloudDP ’13).

KEMP, C.; GYGER, B. Professional Heroku Programming. [S.l.]: John Wiley & Sons, 2013.

KIRCHER, M.; JAIN, P. Pattern-oriented software architecture vol 3: patterns for resourcemanagement. [S.l.]: Wiley, 2004.

LEWIS, G. Role of Standards in Cloud-Computing Interoperability. In: SYSTEM SCIENCES(HICSS), 2013 46TH HAWAII INTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.],2013. p.1652–1661.

MAFFEIS, S. et al. The Object Group Design Pattern. In: COOTS. Anais. . . [S.l.: s.n.], 1996.v.96, p.12–12.

MARCHIONI, F. Infinispan Data Grid Platform. [S.l.]: Packt Publishing Ltd, 2012.

MARSTON, S. et al. Cloud computing — The business perspective. Decision SupportSystems, [S.l.], v.51, n.1, p.176 – 189, 2011.

MAXIMILIEN, E. M. et al. IBM Altocumulus: a cross-cloud middleware and platform. In:ACM SIGPLAN CONFERENCE COMPANION ON OBJECT ORIENTED PROGRAMMINGSYSTEMS LANGUAGES AND APPLICATIONS, 24., New York, NY, USA. Proceedings. . .ACM, 2009. p.805–806. (OOPSLA ’09).

MERLE, P.; ROUVOY, R.; SEINTURIER, L. A reflective platform for highly adaptivemulti-cloud systems. In: ADAPTIVE AND REFLECTIVE MIDDLEWARE ONPROCEEDINGS OF THE INTERNATIONAL WORKSHOP, New York, NY, USA. Anais. . .ACM, 2011. p.14–21. (ARM ’11).

MONTRESOR, A.; DAVOLI, R.; BABAOGLU, O. Middleware for Dependable NetworkServices in Partitionable Distributed Systems. SIGOPS Oper. Syst. Rev., New York, NY, USA,v.35, n.1, p.73–96, Jan. 2001.

MORAIS, T. de; LIBERALQUINO, D.; ROSA, N. Cloud-Aware Middleware. In: ADVANCEDINFORMATION NETWORKING AND APPLICATIONS (AINA), 2013 IEEE 27THINTERNATIONAL CONFERENCE ON. Anais. . . [S.l.: s.n.], 2013. p.780–787.

OPENSTACK Cloud Administrator Guide. Accessed: 2014-06-20,http://docs.openstack.org/admin-guide-cloud/content/.

RANJAN, R. et al. Peer-to-Peer Cloud Provisioning: service discovery and load-balancing. In:ANTONOPOULOS, N.; GILLAM, L. (Ed.). Cloud Computing. [S.l.]: Springer London, 2010.p.195–217. (Computer Communications and Networks).

http://docs.openstack.org/admin-guide-cloud/content/

REFERÊNCIAS 98

REESE, G. Cloud application architectures: building applications and infrastructure in thecloud. [S.l.]: "O’Reilly Media, Inc.", 2009.

RIMAL, B.; CHOI, E.; LUMB, I. A Taxonomy, Survey, and Issues of Cloud ComputingEcosystems. In: ANTONOPOULOS, N.; GILLAM, L. (Ed.). Cloud Computing. [S.l.]:Springer London, 2010. p.21–46. (Computer Communications and Networks).

SADJADI, S. M.; MCKINLEY, P. K. A survey of adaptive middleware. Michigan StateUniversity Report MSU-CSE-03-35, [S.l.], 2003.

SANDERSON, D. Programming Google App Engine: build and run scalable web apps ongoogle’s infrastructure. [S.l.]: "O’Reilly Media, Inc.", 2009.

SCHMIDT, D. C. Middleware for Real-time and Embedded Systems. Commun. ACM, NewYork, NY, USA, v.45, n.6, p.43–48, June 2002.

SCHMIDT, D. C. et al. Pattern-Oriented Software Architecture, Patterns for Concurrentand Networked Objects. [S.l.]: John Wiley & Sons, 2013. v.2.

SHEN, H.; XU, C.-Z. Hash-based proximity clustering for efficient load balancing inheterogeneous {DHT} networks. Journal of Parallel and Distributed Computing, [S.l.], v.68,n.5, p.686 – 702, 2008.

SIEGELE, L. Let it rise: a special report on corporate it. [S.l.]: Economist Newspaper, 2008.

SURTANI, M. et al. Infinispan User Guide. Accessed: 2014-06-30,http://infinispan.org/docs/6.0.x/user_guide/user_guide.html.

TALUKDER, A.; ZIMMERMAN, L.; A, P. Cloud Economics: principles, costs, and benefits. In:ANTONOPOULOS, N.; GILLAM, L. (Ed.). Cloud Computing. [S.l.]: Springer London, 2010.p.343–360. (Computer Communications and Networks).

TURAN, M. S. et al. Recommendation for password-based key derivation. NIST specialpublication, [S.l.], v.800, p.132, 2010.

VANBRABANT, R. Google Guice: agile lightweight dependency injection framework. [S.l.]:Apress, 2008.

VARIA, J. Architecting for the cloud: best practices. Amazon Web Services, [S.l.], 2010.

VARIA, J.; MATHEW, S. Overview of amazon web services. Amazon Web Services, [S.l.],2012.

VÖLTER, M.; KIRCHER, M.; ZDUN, U. Remoting Patterns: foundations of enterprise,internet and realtime distributed object middleware. [S.l.]: Wiley. com, 2005.

WILDER, B. Cloud Architecture Patterns. [S.l.]: "O’Reilly Media, Inc.", 2012.

http://infinispan.org/docs/6.0.x/user_guide/user_guide.html

diego liberalquino soares lima · 2019-10-25 · um middleware orientado a objeto existente (camid...

Documents