ECAMID: UM MIDDLEWARE PARA NUVEM COMPUTACIONAL
COM SUPORTE À ELASTICIDADE
Dissertação de Mestrado
Universidade Federal de Pernambuco [email protected] www.cin.ufpe.br/~posgraduacao
RECIFE 2014
Centro de Informática
Pós-graduação em Ciência da Computação
Diego Liberalquino Soares Lima
ECAMID: UM MIDDLEWARE PARA NUVEM COMPUTACIONAL
COM 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
RECIFE 2014
Catalogação na fonte
Bibliotecá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.
deral de Pernambuco, sob o título eCaMid: Um Middleware para Nuvem Computacional com Suporte à Elasticidade, orientada pelo Prof. Nelson Souto Rosa e aprovada pela banca examinadora 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 Barros
Coordenadora da Pós-Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco.
Gostaria de agradecer primeiramente aos meus pais, Carmem e Alexandre, por sempre estarem 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 face a todas as adversidades encontradas.
Agradeço também à minha noiva Pollyana, por toda companhia e paciência nestes dois anos. Ambos estivemos fazendo nossos mestrados neste tempo e compartilhamos os mesmos momentos de estresse e sacrifício pessoal. Tivemos ainda que nos manter unidos frente às barreiras de um relacionamento à distância, fruto de nossas escolhas profissionais.
Gostaria de agradecer também a pessoas com quem convivi na minha vida profissional nestes anos, e que demonstraram toda sua compreensão nesta jornada acadêmica. Por isso agradeç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 a minha ausência dos círculos sociais nestes últimos anos, muitos desses que também estavam enfrentando as dificuldades de um mestrado.
Finalmente, agradeço a Tércio Morais e Nelson Rosa pela parceria nos projetos pesquisas de middleware e nuvem que estivemos realizando neste período de mestrado.
Computação em nuvem fornece aplicações, plataformas e servidores virtuais como serviço, e permite que consumidores paguem pela utilização destes serviços sem que eles precisem 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ão são mais necessários. Aplicações distribuídas desenvolvidas em nuvem devem levar em conta a presença da elasticidade para implementar sua arquitetura e serviços. No entanto, o uso efetivo da elasticidade por parte das aplicações pode ser complexo e ocasionar vários erros. Utilizando um middleware orientado a objeto existente (CaMid - Cloud-Aware Middleware), este trabalho apresenta 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 balanceamento de carga. Estes mecanismos foram incorporados ao CaMid e visam maximizar a utilização dos recursos de nuvem à medida que estes são adicionados à infraestrutura da aplicação e mantê-los em funcionamento quando estes recursos são descartados. Para avaliar os mecanismos desenvolvidos, foi realizada uma avaliação experimental para identificar o impacto dos mesmos na execução das aplicações. Foi possível verificar que o CaMid conseguiu utilizar os recursos de nuvem com eficiência a um custo do overhead causado pela coordenação dos vários processos distribuídos.
Cloud computing offers applications, platforms and virtual servers as a service, and allows consumers to pay by the use of these services, without requiring their acquisition. One of the greatest benefits of cloud computing is elasticity, since consumers may request more resources on demand and release them when they are no longer needed. Distributed applications developed by the cloud must take in account the presence of elasticity for implementing its architecture and services. However, the effective use of elasticity by the applications may prove complex 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 mechanisms for supporting elasticity, namely: replication, task coordination, state sharing and load balancing. These mechanisms have been incorporated to CaMid and aim to maximize cloud resources utilization while new resources are being added to application infrastructure, or keep working when 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 during applcation execution. It was possible to verify that CaMid was able to use cloud resources with efficiency at the overhead cost caused by the coordination of the many distributed processes.
2.1 Arquitetura dos serviços de nuvem oferecidos pela Google (JIN et al.,2010) . . 23
2.2 Relacionamento entre modelos de computação em nuvem (RIMAL; CHOI; LUMB,2010) . . . 27
2.3 Arquitetura Genérica de Middleware . . . 31
2.4 Arquitetura de aplicação multi-camadas . . . 32
2.5 Invocação de método remoto em um middleware orientado a objetos . . . 33
2.6 Relacionamento entre padrões de projeto para serviços comuns de um mid-dleware Distributed Object Computing Midmid-dleware (DOC) . . . 38
2.7 Arquitetura em camadas do Cloud-Aware Middleware (CaMid), em uma pilha de serviços de nuvem (MORAIS; LIBERALQUINO; ROSA,2013) . . . 42
2.8 Arquitetura dos serviços de gerenciamento do CaMid . . . 43
2.9 Interação do Local Manager com demais camadas do CaMid (MORAIS; LIBE-RALQUINO; ROSA,2013) . . . 44
2.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) . . . 50
3.2 Visão geral dos componentes do eCaMid. Os elementos de cor branca represen-tam componentes, os de cor cinza represenrepresen-tam serviços, enquanto o elemento preto representa um framework. Os elementos em tracejado são oriundos da arquitetura 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 . . . 53
3.4 Modelo de domínio do subsistema de publish-subscribe . . . 54
3.5 Modelo de domínio do subsistema de escalonamento de tarefas . . . 55
3.6 Modelo de domínio do subsistema de gerenciamento de ciclo de vida . . . 57
3.7 Componentes envolvidos na criação de objetos de sessão. . . 58
3.8 Componentes envolvidos em uma requisição de método remota. . . 59
3.9 Componentes envolvidos em balanceamento de carga . . . 60
3.10 Componentes envolvidos em roteamento de requisições . . . 60
3.11 Balanceamento de carga no eCaMid . . . 61
3.12 Tolerância a falhas no mecanismo de balanceamento de carga. . . 62
4.2 Gráficos de barra para comparação de vazão entre todos os grupos de experimentos 78 4.3 Tempo de resposta vs tempo do experimento para comparação entre os grupos
2.1 Relações entre classes de Remote Objectse mecanismos de gerenciamento de recursos . . . 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 . . . 71 4.2 Tempo de resposta e vazão para o grupo de experimentos Direct-Stateful . . . . 72 4.3 Tempo de resposta e vazão para o grupo de experimentos
Elastic-Clustered-Stateless . . . 73 4.4 Tempo de resposta e vazão para o grupo de experimentos Elastic-Clustered-Stateful 74 4.5 Teste estatístico Mann-Whitney comparando os grupos de experimento
Elastic-Clustered-Stateful e Elastic-Clustered-Stateless . . . 76 4.6 Teste estatístico Mann-Whitney comparando os grupos de experimento
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
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
1 Introdução 16 1.1 O Problema . . . 17 1.2 Soluções Parciais . . . 18 1.3 Proposta . . . 19 1.4 Estrutura da Dissertação . . . 20 2 Conceitos Básicos 21 2.1 Computação em Nuvem . . . 21
2.1.1 Categorias de serviço de nuvem . . . 22
2.1.1.1 SaaS . . . 22
2.1.1.2 PaaS . . . 23
2.1.1.3 IaaS . . . 25
2.1.1.4 Relacionamento entre modelos de computação em nuvem . . 27
2.1.2 Elasticidade . . . 28
2.2 Padrões de Projeto de Middleware e Nuvem . . . 29
2.2.1 Arquitetura e Padrões de Projeto para Middleware . . . 30
2.2.1.1 Middleware Orientado a Objetos . . . 31
2.2.1.2 Gerenciamento de Ciclo de Vida . . . 33
2.2.1.3 Serviços comuns . . . 35
2.2.2 Arquitetura e Padrões de Projeto para Computação em Nuvem . . . 39
2.2.2.1 Padrões de projeto para computação em nuvem . . . 40
2.3 Cloud Aware Middleware . . . 41
2.3.1 Local Manager . . . 43 2.3.2 Global Manager . . . 44 2.4 Considerações Finais . . . 44 3 Proposta 46 3.1 Motivação e Objetivos . . . 47 3.2 Requisitos . . . 48
3.3 Modelo de domínio geral . . . 49
3.4 Arquitetura . . . 51
3.4.1 Coordenação . . . 52
3.4.1.1 Comunicação Publish/subscribe . . . 53
3.4.1.2 Escalonamento de tarefas periódicas . . . 54
3.5 Tecnologias utilizadas . . . 62
3.6 Implantação . . . 64
3.7 Considerações Finais . . . 65
4 Avaliação de Desempenho e Discussão 66 4.1 Objetivos e Metodologia . . . 66
4.1.1 Métricas, Parâmetros e Fatores . . . 67
4.1.2 Técnica de avaliação, carga de trabalho e projeto de avaliação . . . 69
4.2 Resultados . . . 70
4.2.1 Resultados individuais de cada experimento . . . 70
4.2.2 Comparação entre resultados . . . 74
4.3 Discussão . . . 80
5 Trabalhos Relacionados 81 5.1 Tecnologias fundamentais usadas pelo ElasticCamid . . . 81
5.1.1 JGroups . . . 81
5.1.2 Infinispan . . . 82
5.2 Trabalhos de Middleware Desenvolvido para Nuvem . . . 83
5.2.1 Arquitetura Geral de Middleware . . . 84
5.2.2 Multitenancy . . . 85
5.2.3 Interoperabilidade . . . 87
5.2.4 Elasticidade . . . 88
5.2.5 Outros requisitos não funcionais de nuvem . . . 90
5.2.6 Discussão . . . 91
5.2.7 Considerações finais . . . 92
6 Considerações Finais 93 6.1 Trabalhos Futuros . . . 94
1
Introduçã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ço de manutenção e distribuição de energia, provedores de computação em nuvem oferecem uma diversidade de ativos como serviço, onde esses ativos podem ser aplicativos, plataformas de software, 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 uso do serviço e não pela aquisição desses ativos, que é contabilizada de várias formas, como por exemplo 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 dos ativos, geralmente oferecendo algum Service Level Agreement (SLA). Se este ativo for uma plataforma de software, o provedor se encarrega de provisionar a aplicação em uma máquina física ou virtual, replicar esta instalação em múltiplos nós e assim por diante. Caso o ativo seja infraestrutura, 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ário para construir e manter uma infraestrutura de hardware e software, para desenvolver novos aplicativos e para usar e manter software de terceiros. Empresas como Google oferecem pacotes de 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 esses aplicativos 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 virtuais que funcionam de forma similar a uma infraestrutura física, mas sem a necessidade de fazer um grande investimento inicial tanto em aquisição quanto em instalação que é comum em servidores físicos.
Além da vantagem da redução do investimento, o modelo de computação em nuvem permite também evitar o superdimensionamento dos recursos computacionais utilizados. Ativos de 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 novos ativos. No momento em que estes não forem mais necessários, estes poderão ser descartados e devolvidos para o provedor. Este conceito inovador de computação em nuvem é chamado de elasticidade.
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 software e hardware deve ser dimensionada de antemão para atender requisitos não funcionais como desempenho, escalabilidade, disponibilidade e confiabilidade. Essa infraestrutura teria que ser grande o suficiente para suportar os picos de utilização, mas estaria subutilizada em momentos de ociosidade. Com a elasticidade, a infraestrutura não precisa ser superdimensionada, mas pode ser incrementada ou diminuída de acordo com a demanda de recursos computacionais da aplicaçã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óiam no 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 forma eficiente e confiável em um ambiente elástico. Atualmente, é possível desenvolver aplicações elásticas utilizando facilidades específicas de um provedor, sejam essas plataformas ou serviços específicos, ou através do uso de APIs específicas que permitem a gerência desses recursos por parte 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), ou Plataforma como Serviço, o ativo gerenciado consiste em uma plataforma de software, que oferece um modelo de programação para a construção de uma aplicação. A vantagem deste modelo é que a plataforma já implementa os mecanismos de elasticidade, fornecendo para a aplicação um framework ou um conjunto de APIs que devem ser usados para fazer coisas como 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 de PaaS.
Um outro modelo utilizado para o desenvolvimento de aplicação é conhecido como Infrastructure as a Service(IaaS), ou Infraestrutura como Serviço. Neste modelo, o provedor fornece uma infraestrutura virtual, composta por servidores, discos rígidos, balanceadores de
carga entre outros. O provedor também oferece um console ou API para gerenciar os recursos virtuais da nuvem. A vantagem deste modelo é que o usuário pode definir a arquitetura e a tecnologia 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 a aplicação elásticas precisam ser realizadas pelo usuário, através da gerência de recursos virtuais atravé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 costumam oferecer 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 provedor de IaaS, esses serviços específicos podem não estar presentes ou divergir na forma em que funcionam. Existe um esforço para padronizar APIs e serviços de provedores de IaaS. Embora existam 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 seja executada sobre um provedor de nuvem que possua suporte à elasticidade sem utilizar APIs ou serviços específicos de cada provedor, visto que muitos desses serviços são incompatíveis entre si devido à falta de padronização. Desenvolver esses mecanismos de suporte à elasticidade dentro da própria aplicação distribuída pode ser difícil, dado a uma série de complexidades inerentes que são características da elasticidade. Além das complexidades inerentes, podemos citar as complexidades acidentais que são evidenciadas ao misturar lógica do domínio da aplicação com funcionalidades voltadas para o suporte à elasticidade, violando o princípio de projeto de software 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 de programação que abstrai diversas complexidades do desenvolvimento de aplicações distribuídas. Middlewarepode 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 os benefícios encontrados em nuvens PaaS, reduzindo o acoplamento com serviços de um provedor especí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 da elasticidade 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 provedor de nuvem (JAYARAM,2013); outros apenas propõem recursos que refinam o uso de elasticidade, fornecendo capacidades adicionais (AZEEZ et al.,2010).
Distributed Systems(GFADS)1, foi proposto um middleware, que utiliza o paradigma Distributed Object Computing Middleware(DOC), denominado Cloud-Aware Middleware (CaMid). Este middlewarefoi 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 desenvolvedor de 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; gerenciamento automático, que é a capacidade de manipular recursos sem intervenção humana direta; suporte a aplicações cliente-servidor; transparência de localização e acesso; arquitetura baseada em padrões de projeto (MORAIS; LIBERALQUINO; ROSA,2013).
O CaMid foi pensado para gerenciar vários aspectos de uma nuvem IaaS, incluindo aspectos relacionados à elasticidade. Desta forma, o Elastic Cloud-Aware Middleware (eCaMid) poderia ser usado diretamente por aplicações que utilizam o modelo de objetos distribuídos que serão implantadas no ambiente de IaaS ou como blocos fundamentais de um PaaS que usa esse mesmo modelo. No entanto, a sua primeira implementação não possui mecanismos de tolerância a falhas, como tolerância a falha temporária ou permanente de um nó, assim como balanceamento 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, chamada eCaMid, que aprimora os mecanismos existentes para ambientes elásticos. Foram adicionados mecanismos de comunicação em grupo, replicação e balanceamento de carga, que permitem tomar vantagem da adição dinâmica de nós a uma infraestrutura virtual, assim como tratar de forma transparente as falhas de comunicação, ou garantir a consistência das informações quando os mesmos nós são removidos, seja de forma intencional ou por ocasião de falha. Os mecanismos de suporte à elasticidade do eCaMid não dependem de um provedor específico de IaaS, pois todas as funcionalidades foram desenvolvidas internamente ao próprio middleware.
O modelo de programação do antigo CaMid foi estendido para permitir o suporte a objetos stateful, interceptadores, a troca de mensagens entre componentes através de um modelo publish/subscribee a execução de tarefas periódicas, coordenadas entre vários nós. Essas novas funcionalidades apóiam tanto o desenvolvimento de aplicações distribuídas quanto à extensão de funcionalidades 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 de computação em nuvem.
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 deste
trabalho, como uma explanação do conceito de nuvem e elasticidade, uma série de padrões de projeto utilizados em middleware e em computação em nuvem e uma breve explanação sobre a arquitetura do CaMid,
Capítulo 3: apresenta a arquitetura do eCaMid e como as novas funcionalidades
poderão ser utilizadas em um ambiente elástico,
Capítulo 4: apresenta uma avaliação experimental do eCaMid em um cenário onde a
elasticidade é utilizada,
Capítulo 5: este capítulo apresenta os trabalhos relacionados que também procuram
resolver de alguma forma a problema da elasticidade, e
Capítulo 6: apresenta algumas considerações finais sobre os resultados obtidos neste
2
Conceitos Básicos
Neste capítulo, introduziremos as principais tecnologias necessárias ao entendimento do eCaMid. Na primeira seção, faremos uma breve discussão sobre o que é computação em nuvem, o seu modelo de negócio, as principais categorias de serviço de computação em nuvem e a relação entre essas categorias de serviço, com foco em SaaS, PaaS e IaaS. Faremos uma conceituação do que é elasticidade, qual a sua importância para computação em nuvem e como este 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ões arquiteturais 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 esta seção, apresentaremos o CaMid, quais seus objetivos e princípios, qual sua a arquitetura, e como esta é apoiada sobre os padrões discutidos na seção anterior. Faremos também uma discussão sobre 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 de computação utilitária, que tem o potencial de mudar grande parte da indústria de TI, fazendo com que produtos de software sejam oferecidos como serviço e reduzindo os imensos gastos com hardware e pessoas para operarem esses equipamentos". Computação em nuvem pode ser oferecida como uma série de serviços, que oferecem ativos de várias formas, de softwares como suí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 uma entidade externa, este serviço é chamado de nuvem pública, mas quando é oferecido por um departamento ou setor de uma mesma corporação, a oferta de serviço é chamada de nuvem privada.
Computação em nuvem nasceu da necessidade de se operar uma infraestrutura com eficiência através de recursos de software e hardware escaláveis, em resposta à necessidade de
negócios que precisam desenvolver rapidamente aplicações com alto desempenho, escalabili-dade e disponibiliescalabili-dade, sejam estas aplicações analíticas ou aplicações móveis que precisam de respostas em tempo real (MARSTON et al.,2011). Conforme várias empresas de tecnologia ganhavam 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, como aquisiçã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 modelos de 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 de computaçã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 e assim 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 Business HERRICK(2009), um pacote de software que inclui e-mail, criação de documentos como textos e apresentações e compartilhamento de arquivos; redes sociais como Facebook1, que permitem o compartilhamento de mensagens, imagens e videos; serviços de streaming, que incluem o Grooveshark2e Netflix3. Há várias características que geralmente estão presentes em aplicativos fornecidos 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 de assinatura 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 aplicativos precisam ser constantemente atualizados, corrigindo defeitos rapidamente e oferecendo novas funcionalidades e recursos. Desenvolver plataformas de software e hardware que sejam capazes de suportar esses requisitos não funcionais é um dos grandes desafios para os provedores de SaaS.
1http://www.facebook.com 2http://www.grooveshark.com 3http://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 que possibilita o desenvolvimento de aplicações distribuídas. Usuários desses serviços implantam a aplicaçã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 os níveis desejados de Quality of Service (QoS). Cada oferta de PaaS varia bastante de provedor para provedor conservando, contudo, algumas semelhanças. Discutiremos sobre dois populares serviços de PaaS, GAE (SANDERSON,2009) e Heroku (KEMP; GYGER,2013), para entender como funcionam as ofertas de PaaS.
O serviço GAE, Figura 2.1, fornece ao desenvolvedor uma plataforma voltada para aplicações Web. Cada aplicação web é executada em um sandbox, um ambiente que restringe o acesso da aplicação a funcionalidades como acesso a arquivos, limitando-a a utilizar requisições HTTP para páginas presentes na Web, na própria aplicação ou no GAE. Para utilizar outros serviços, como armazenamento de dados, e-mail, XMPP e outros, deve-se utilizar as APIs fornecidas pelo serviço, que por sua vez se encarrega de alocar recursos e distribuir as várias partes da aplicação de forma transparente, garantindo sua escalabilidade. O usuário é cobrado pelos recursos que utiliza do serviço.
Google não revela em detalhes a arquitetura de sua oferta de PaaS, e não existe na literatura uma descrição detalhada dos componentes e como estes interagem para tornar a aplicaçã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 contabiliza número de leituras e escritas, requisições HTTP para serviços externos, logging e outros. O usuário, contudo, não tem controle sobre a quantidade de recursos utilizados numa aplicação GAE e pode apenas indicar o valor máximo que deseja pagar pelo serviço. Este tem a autonomia de 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 de programação (Java, Ruby, Python, Node.js e outras), onde essa aplicação deve ser dividida em vá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 estrutura virtual, 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 receber requisições web externas e um Worker Dyno que executa algum processo auxiliar, como uma rotina batch ou um processo que consome mensagens de uma fila. Dessa forma é possível criar aplicações que dividem tarefas entre diversos processos distribuídos. Além dos dois tipos de dynosmencionados, o Heroku oferece outros dynos especializados que atuam como bancos de dados e servidores de mensagem, por exemplo (KEMP; GYGER,2013).
Cada dyno é executado em uma stack, um conjunto de máquinas virtuais que contém configurações idênticas – sistema operacionais na mesma versão, com versões específicas das linguagens e softwares utilitários da plataforma instalados. Um gerenciador de processos distribuídos é utilizado para escalonar os dynos em cada máquina virtual do stack. Cada usuário pode 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 no GAE. 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 determina quantos dynos serão utilizados e de que tipo. Além disso o Heroku também oferece APIs de serviç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 tecnologia desde que seja compatível com as configurações definidas no stack. Em contrapartida, o framework 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ção aos serviços de IaaS é que este oferece um ambiente pré-configurado, e o gerenciamento e a implantação das aplicações seguem uma arquitetura de processos.
Além dessas ofertas de PaaS, outros serviços merecem destaque. A plataforma Elastic Beanstalk é 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 implantada em 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 middleware em 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ário de nuvem. Essas infraestruturas utilizam virtualização, uma tecnologia que permite simular o funcionamento de hardware através de software. Como os ativos virtuais são constituídos de dados, eles podem ser armazenados, copiados e versionados. O público alvo das ofertas de Infrastructure as a Service(IaaS) são organizações que precisam implantar aplicações de alta escalabilidade com alto controle sobre a tecnologia utilizada, sem ter que lidar com o custo de aquisição, implantação e manutenção de hardware.
Diferentemente das ofertas de PaaS, os ativos oferecidos pelos serviços de IaaS são mais homogêneos, e geralmente são servidores, discos rígidos, redes privadas e balanceadores de carga. Além desses ativos, os provedores costumam oferecer serviços mais específicos, como o Amazon Cloudwatch (VARIA; MATHEW,2012), da suíte AWS, que é usada para monitorar os 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ços ligeiramente similares. Todos os provedores de nuvem disponibilizam uma API que pode ser usada 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 de processamento é 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 em vários tamanhos, dependendo da quantidade de processadores, memória RAM e capacidade de armazenamento. 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 gerenciadas pelo 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 que o provedor ofereça este serviço de duas formas distintas: como um serviço de gerenciamento
4http://www.tsuru.io 5http://cloudfoundry.org 6http://www.openstack.org 7http://www.opennebula.org 8http://www.eucalyptus.com
de blocos virtuais, como o AWS Elastic Block Store, Openstack Cinder e Eucalyptus Storage Controller; ou um serviço de armazenamento chave-valor, tais como AWS Simple Storage Service, Openstack Swift e Eucalyptus Walrus. O primeiro é utilizado como discos rígidos virtuais que aumentam a capacidade de armazenamento de uma máquina virtual, enquanto o armazenamento de chave-valor pode ser usado para armazenar imagens de máquinas virtuais ou 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, como Storage Area Networks (SANs), enquanto servidores de armazenamento chave-valor são bancos de dados completos, particionáveis e de alta escalabilidade.
Além da capacidade de oferecer máquinas virtuais e armazenamento, os provedores de nuvem também oferecem redes virtuais, como é o caso dos serviços Amazon Virtual Private Cloud(Amazon VPC) (VARIA; MATHEW,2012) e Openstack Neutron (OPENSTACK CLOUD ADMINISTRATOR 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 de separar servidores de aplicação e banco de dados em camadas distintas.
Existe uma grande variedade de serviços específicos fornecidos por fornecedores de IaaS. O provedor AWS possui um grande catálogo de serviços, como balanceamento de carga, provisionamento automático (auto scaling), monitoramento (Cloudwatch) entre outros. Outros fornecedores de IaaS públicos, como Google Compute Cloud9 oferecem serviços similares. No espaço de fornecedores de IaaS privados, temos Eucalyptus e Openstack que fornecem balanceamento 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 e armazenamento (apenas discos virtuais). Para que uma aplicação utilize o potencial oferecido pela nuvem, ela deve conhecer quais as facilidades oferecidas pelo provedor; para se manter independente, é necessário que esta possua mecanismos para se adaptar às diferentes ofertas de serviço.
A maioria das iniciativas de padronizar a Computação em Nuvem estão voltadas para o modelo de IaaS, por conta da similaridade dos serviços oferecidos por diferentes provedores, de acordo com a categoria do serviço. Temos Open Cloud Computing Interface (OCCI)10, uma iniciativa 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áquinas virtuais, permitindo que estas sejam migradas de um provedor para outro (LEWIS,2013).
9https://cloud.google.com/products/compute-engine/ 10http://occi-wg.org
11http://www.snia.org/cdmi
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. O modelo de SaaS precisa ser capaz de suportar uma grande quantidade de usuários e manter alta disponibilidade, uma vez que seus serviços podem estar sendo usados por um usuário em qualquer parte do mundo, em diferentes horários. Para isso, uma oferta de SaaS precisa ser construída sobre uma plataforma que forneça esses requisitos, como o oferecido em um modelo de PaaS. Este, por sua vez, precisa de uma infraestrutura eficiente que suporte a elasticidade e provisionamento rápido de recursos, como numa oferta de IaaS. Essa relação entre serviços pode ser ilustrada na Figura 2.2.
Não necessariamente um serviço oferecido por um modelo está apoiado por outro modelo de 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, existem provedores públicos de PaaS que utilizam a infraestrutura de provedores de IaaS, como é o caso do Heroku, que opera sobre a infraestrutura provida pela AWS. O Software chamado CloudApp
13é 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 Netflix14, possuem uma plataforma própria e preferem utilizar a infraestrutura da AWS diretamente.
2.1.2
Elasticidade
Uma das consequências de computação em nuvem foi a conversão de despesas de capital em despesas operacionais (FOX et al.,2009), direcionando os investimentos que antes eram realizados em hardware e soluções de alto poder computacional para despesas de pessoal e ferramentas 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ão estã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 evitar tanto o risco de se ter uma infraestrutura saturada ou subutilizada. Geralmente, o uso médio do poder 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ão de duas a dez vezes. Supondo que durante uma parte do dia sejam necessários 500 servidores para atender a demanda de acesso de uma aplicação (pico), mas no resto do tempo apenas 100 servidores sejam necessários, com uma média de 300 servidores necessários por dia; para se manter disponível e não degradar o desempenho da aplicação durante o pico de utilização, seria necessá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 de mitigar o risco involvido no dimensionamento da infraestrutura, fornecendo a possibilidade de adicionar ou remover novas máquinas virtuais em minutos, ao invés de semanas ou meses em infraestruturas 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, desenvolvida em uma infraestrutura tradicional, para uma infraestrutura ou plataforma fornecida por um provedor de nuvem. Para escolher a arquitetura da solução, quatro requisitos foram levados em conta. O primeiro requisito está relacionado à possibilidade de aumentar ou diminuir o tamanho da 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 as tecnologias 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 se referia 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.com
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 as tecnologias utilizadas no Hackystat. Foi necessário separar os componentes de lógica de negócio e persistência para que fosse possível criar réplicas do primeiro e o segundo fosse adaptável a múltiplos provedores de IaaS. Além da persistência, foi criado um componente que orquestrava as 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 grande grupo que compreende os sistemas distribuídos. O que diferencia sistemas distribuídos de aplicações tradicionais é que um único sistema está dividido em um ou mais processos, que se comunicam através de mensagens, que possuem espaços de memória distintos e interagem juntos com 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ções entre si; desempenho e escalabilidade, onde tarefas que seriam realizadas em um processo podem ser divididas entre vários; compartilhamento de recursos, onde múltiplos processos compartilham recursos 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 processo redundante (SCHMIDT et al.,2013) (VÖLTER; KIRCHER; ZDUN,2005).
Apesar de todos os benefícios, o desenvolvimento de sistemas distribuídos apresenta uma série de desafios. Existem complexidades inerentes e acidentais relacionadas a sistemas distribuídos. Entre as complexidades inerentes temos a necessidade de lidar com falhas parciais de um sistema, qualidade de serviço, deadlock distribuídos, sincronização entre outros. Entre as complexidades acidentais estão as limitações das ferramentas de de desenvolvimento de software para 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ários protocolos, bibliotecas, sistemas operacionais entre outros que resolvem os mesmos problemas e são geralmente incompatíveis entre si (SCHMIDT et al.,2013). Muitas dessas soluções são proprietá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 modelo de 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 processos bastante similar à invocação de funções, onde o cliente fornece uma série de parâmetros e o
servidorretorna uma resposta; o modelo DOC, é uma especialização do modelo RPC, onde as primitivas utilizadas são invocações de métodos de objetos, onde estes podem possuir estado e ser compostos de outros objetos; e o modelo Message Oriented Middleware (MOM), onde filas de mensagem são utilizadas como primitiva, onde produtores e consumidores de mensagens utilizam 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 testados e provados ao longo dos anos, tornando-se soluções refinadas. Padrões de projeto também são utilizados para compor um vocabulário utilizado para compartilhar conhecimento e experiência sobre possíveis problemas computacionais e suas soluções (GAMMA et al.,1993). Existe uma extensa 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 orientado a objeto; eHOHPE; WOOLF(2004) menciona um conjunto de padrões para integrar diferentes sistemas utilizando mensagens e comunicação assíncrona.
Existem padrões de projeto e de arquitetura para aplicações distribuídas que utilizam o paradigma 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 que nasceram neste ambiente e precisam ser pensadas para tirar proveito de todos os benefícios concedidos 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 maneiras na literatura, podemos utilizar uma arquitetura genérica, baseada em camadas, para descrever sua estrutura, como é ilustrada na figura 2.3. Entre as camadas dispostas na figura, podemos evidenciar os dispositivos de Hardware e Sistemas Operacionais e Protocolos, que compreendem todas as APIs e mecanismos de baixo nível que envolvem a comunicação de rede e entre processos 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 de middleware para realizar comunicação.
As camadas que se localizam entre a camada de infraestrutura e a serviços específicos compreendem todas as funcionalidades que estão disponíveis em um middleware. A camada de infraestrutura, é responsável por encapsular mecanismos de baixo nível de um sistema operacional e programação de rede. Entre os mecanismos encapsulados, temos a programação de sockets, gerenciamento de eventos e concorrência. Esta camada também precisa lidar com diferenç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, que fornecem 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ões e entrada e saída de dados para oferecer abstrações de alto nível como filas de mensagens e objetos remotos. Utilizando essas abstrações é possível desenvolver aplicações distribuídas que funcionam de forma similar a aplicações monolíticas, que são executadas sobre um único processo (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, qualidade de serviço, logging, persistência, segurança e transações. Enquanto a camada de distribuição se preocupa com particularidades do modelo de programação, a camada de serviços específicos realiza a gerência de vários recursos distribuídos entre vários processos, tendo uma visão do todo. 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 em middleware 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-servidor que 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 em muitos 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 balanceamento de carga, segurança e gerenciamento de transaçõesGORTON(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ém nenhuma lógica de domínio, que delega todas as invocações de métodos executadas no cliente para o objeto localizado no servidor. Este objeto se chama Remote Object, um objeto que possui ló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 a um componente chamado Client Request Handler. Este componente, por sua vez, se encarrega de entregar a mensagem ao servidor utilizando mecanismos de rede. De forma similar, no lado servidor, um componente chamado Server Request Handler recebe uma mensagem e entrega a mesma ao Invoker, que a desencapsula, obtém a instância do Remote Object, e faz uma chamada de método local a este objeto. Os componentes chamados Marshallers são responsáveis por codificar as mensagens para um stream de bytes e decodificar este stream de bytes em uma mensagem, que será entregue entre do cliente para o servidor e vice-versa. Este processo pode ser 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 da comunicação propriamente dita, o Broker também está encarregado de gerenciar o ciclo de vida dos 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 linguagem orientada a objetos, com suporte à composição, delegação herança, polimorfismo e outras características. O que diferencia Remote Objects de objetos locais é que o estado destes, por conta 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 de alocação de memória manual ou um garbage collector, que retira da memória objetos que não estão sendo utilizados. Em uma aplicação cliente-servidor, podem haver milhares de clientes e Remote Objects. Contudo, um cliente pode ser desconectado por conta de uma falha interna na rede. O Broker, no entanto, não pode simplesmente descartar o objeto por conta de uma queda de conexão, pois o cliente poderia tentar se reconectar e continuar a operação de negócio que estava realizando antes. Ao mesmo tempo, a parte servidor do Broker não pode manter o objeto na memória indefinidamente, pois isso poderia provocar o esgotamento de recursos do sistema operacional 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 cliente que 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ísico ou 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 é que estes devem manter seu estado consistente mesmo após inúmeras chamadas remotas de diversos clientes, levando a problemas de concorrência.
Uma forma de evitar totalmente os problemas de concorrência e esgotamento de memória de Static Instances, é não preservar nenhum estado no Remote Object. Per-Request Instances são objetos que são criados no escopo de uma chamada remota de método. Dessa forma, esses Per-Request Instancespodem ser acessados livremente sem problemas de concorrência, consistência ou esgotamento de memória. A desvantagem de sua utilização é que pode existir a necessidade de 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 e Per-Request Instances. Client-Dependent Instances representam objetos que existem pelo tempo de vida de um cliente. Estes objetos são criados quando um cliente inicia uma conexão com a aplicação e destruídos quando essa conexão é terminada. Client-Dependent Instances reduzem os problemas de concorrência se comparados a um Static Instances, pois este objeto será acessado por 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 certeza absoluta de quando uma conexão é terminada, pois esta pode ser resultado de uma falha de comunicação na rede e não de uma desconexão. Um outro problema é que Client-Dependent Instancesnão estão totalmente imunes a problemas de concorrência, pois uma aplicação pode ser 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 mecanismo Lazy Acquisition (VÖLTER; KIRCHER; ZDUN,2005) se refere em adiar a criação de um Remote Objectapenas quando uma chamada para este é realizada. Esse mecanismo faz com que o estado de um Remote Object somente seja alocado na memória quando este for realmente ser utilizado. 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. Este mecanismo evita o overhead causado pela criação e destruição de um objeto remoto, otimizando a utilização de recursos do sistema operacional. Pooling é melhor utilizado para objetos que nã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 seja alocado 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 um Remote Objectem 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.
KIRCHER; ZDUN,2005) e consiste no armazenamento permanente de um objeto seguido da desalocação do estado da memória. Este recurso é útil ao utilizar uma Static Instance, para liberar 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 de recursos
Static Instance Per-Request Intance Client-Dependent Instance Lazy Acquistion útil implicitamente útil implicitamente útil
Pooling inútil muito útil pouco útil
Leasing pouco útil inútil muito útil
Passivation pouco útil inútil muito útil
O Broker utiliza um componente específico para lidar com o gerenciamento de ciclo de vida, 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, os mecanismos 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 durante algumas 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 de requisitos de qualidade, como transparência de localização, tolerância à falhas e monitoramento de 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ço de Lookup é usado justamente para esta finalidade: ele utiliza uma estrutura de dados que é usada para armazenar a localização de objetos em diferentes servidores. Cada Remote Object possui um identificador 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, o serviç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 Listagem 2.1:
Listagem 2.1: Interface de Serviço de Lookup
v o i d 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 e n d p o i n t ) ;
v o i d 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ço de 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 consiste na 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 de vá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 ser realizado a partir da utilização de várias réplicas do mesmo objeto em diferentes servidores. Esta estratégia é útil não somente para evitar a indisponibilidade, mas também para distribuir a carga de requisições de maneira eficiente entre todas as réplicas.
O padrão de projeto Location Forwarder (VÖLTER; KIRCHER; ZDUN,2005) pode ser utilizado para esta finalidade. Este pode ser concebido como um protocolo onde o cliente recebe uma mensagem de redirecionamento e procura a nova réplica de objeto remoto, ou como um componente que se encarrega de enviar requisições para a réplica adequada, agindo como um intermediário entre o cliente e o objeto remoto. A vantagem da primeira abordagem é a descentralização dos mecanismos de redirecionamento. A desvantagem é que a concepção de um protocolo de redirecionamento pode ser complexo, e o middleware não possui controle total da 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 complexas de balanceamento de carga; a desvantagem desta abordagem é presença de um ponto único de falha, em caso de indisponibilidade deste componente.
Além do mecanismo de redirecionamento de requisições, pode ser usado um protocolo de gerenciamento de grupos para gerenciar todas as réplicas existentes de um Remote Object. O padrão de projeto Object Group (MAFFEIS et al.,1996) é utilizado para esta finalidade: este define um protocolo onde um Broker pode registrar uma réplica específica em um grupo. O Object Groupsubstitui um AOR de um Remote Object em um serviço de Lookup: ao invés de localizar 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 membros registrados ou a todos. Um componente de Location Forwarding poderia ser utilizado nesse aspecto, 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 a partir 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 uma referê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. Cada membro da view é identificada de forma única, e este recurso de identidade pode ser utilizado para selecionar um coordenador do Object Group.
As primitivas get_state e set_state são utilizadas para compartilhar o estado de um Remote Objectentre todos os membros de um Object Group. A primitiva get_state é utilizado por um dos 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 primitivas de compartilhamento de estados são particularmente úteis para efetuar a migração de um Remote Objectde 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 v o i d c r e a t e _ g r o u p ( O b j e c t _ p t r g r o u p , 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 ) ; v o i d j o i n ( O b j e c t _ p t r g r o u p ) ; v o i d l e a v e ( O b j e c t _ p t r g r o u p ) ; s t a t i c v o i d d e s t r o y _ g r o u p ( O b j e c t _ p t r g r o u p ) ; v i r t u a l v o i d g e t _ s t a t e ( AnySeq& s t a t e , B o o l e a n& d o n e ) ; v i r t u a l v o i d s e t _ s t a t e ( c o n s t AnySeq& s t a t e , B o o l e a n& d o n e ) ; v i r t u a l v o i d v i e w _ c h a n g e ( c o n s t View& newView ) ; }
Figura 2.6: Relacionamento entre padrões de projeto para serviços comuns de um middleware DOC
monitorada. Entre os itens que podem ser monitorados estão o Server Request Handler, o Invokere 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íficas de cada componente do middleware orientado a objetos.
Para que o QOS Observer seja utilizado corretamente, o desenvolvedor do middleware deve prover um gancho específico para cada componente a ser medido. Este gancho deve funcionar de forma semelhante àquela encontrada no padrão de projeto Observer (GAMMA et 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ção a todos os QOS Observers registrados. Cada QOS Observer , por sua vez, consulta o estado do Subject e coleta uma série de métricas, como tamanho da mensagem, tempo de execução e quantidade 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 este pode usar um Location Forwarder para distribuir requisições entre várias réplicas de um mesmo Remote Object. Também observamos quais componentes de um middleware DOC podem ser monitorados por QOS Observers.
