Implantação de Aplicações em Múltiplas Plataformas de Nuvem Diego Souza1, Thiago Sena1, Everton Cavalcante1, Nélio Cacho1, Thais Batista1,

André Almeida1,2, Frederico Lopes3, Thomas Diniz3, Flávia C. Delicato4, Paulo F. Pires4

1 DIMAp, Universidade Federal do Rio Grande do Norte (UFRN) – Natal, RN 2 Instituto Federal de Educação do Rio Grande do Norte (IFRN) – Parnamirim, RN

3ECT, Universidade Federal do Rio Grande do Norte (UFRN) – Natal, RN 4DCC/IM, Universidade Federal do Rio de Janeiro (UFRJ) – Rio de Janeiro, RJ

{diegodimap, lord.sena, evertonranielly, fred.lopes, thomasfdsdiniz, fdelicato, paulo.f.pires}@gmail.com, andre.almeida@ifrn.edu.br,

thais@ufrnet.br, neliocacho@dimap.ufrn.br

Resumo. Neste artigo descrevemos nossa experiência de implementação e implantação de uma aplicação usando três plataformas de nuvem, com o objetivo de analisar as similaridades e diferenças entre elas, bem como as facilidades e dificuldades com relação à implantação de aplicações usando os serviços providos por essas plataformas. Apresentamos também as lições aprendidas de forma a orientar desenvolvedores e ajudá-los a minimizar ou evitar possíveis problemas enfrentados ao implantar aplicações em nuvem.

Abstract. In this paper we describe our experience in implementing and deploying an application using three cloud platforms, aiming to analyze the similarities and differences between them, as well as the facilities and difficulties regarding to the deployment of applications using services provided by these platforms. Furthermore, we also present the lessons learned in order to guide developers and aid them avoiding possible problems that they may experience when deploying cloud applications.

1. Introdução A Computação em Nuvem (Armbrust et al., 2009; Zhang et al., 2009; Wang et al. 2010; Mell e Grance, 2011) é um paradigma que possibilita o acesso ubíquo e sob demanda a um conjunto de recursos computacionais disponibilizados como serviços. Facilidades de armazenamento, infraestrutura, plataformas e softwares são providos como serviços em ambientes de nuvem.

Atualmente há uma variedade de ambientes de nuvem disponíveis no mercado que dão suporte ao desenvolvimento de aplicações. Amazon Web Services (AWS)1, Google App Engine (GAE)2, Microsoft Azure Platform3 e OpenStack4 são alguns exemplos de ambientes de desenvolvimento de aplicações em nuvem. Esses diferentes ambientes seguem diferentes tipos de modelos de provisão de serviços e cada um fornece uma gama de serviços que se diferenciam em diversos aspectos tais como preço, facilidade de uso e desempenho.

1 Amazon Web Services (AWS) – http://aws.amazon.com 2 Google App Engine (GAE) – http://code.google.com/appengine/ 3 Microsoft Windows Azure – http://www.windowsazure.com/ 4 OpenStack Cloud Software – http://openstack.org/

56 Anais

Dado esse cenário de diversidade de ambientes de nuvem, um dos principais desafios em termos de desenvolvimento de aplicações diz respeito à implementação, implantação e migração de aplicações na nuvem, que são tarefas desafiadoras no sentido da maior complexidade inerente à heterogeneidade desses ambientes (Galán et al. 2009; Sampaio et al. 2011). Tais ambientes não são implementados utilizando padrões comuns; cada um possui sua própria API, ferramentas de desenvolvimento, mecanismos de virtualização, características de governança, tecnologias de implantação e gerenciamento de recursos, etc. Consequentemente, os usuários tendem a optar por implementar suas aplicações em um ambiente específico, tornando-se altamente dependentes de um único provedor de nuvem, problema conhecido como cloud lock-in (Armbrust et al. 2009), sendo impossibilitados de aproveitar as melhores características de diferentes ambientes. Além disso, essa dependência implica que, em caso de indisponibilidade de um serviço do ambiente, a aplicação não tem a flexibilidade de recorrer ao serviço equivalente em outro ambiente.

De forma a endereçar esse problema, este artigo tem como objetivo mostrar aspectos de implementação e implantação de uma aplicação usando três importantes ambientes de nuvem: AWS, GAE e OpenStack. A finalidade é implantar tanto diferentes componentes da mesma aplicação em diferentes nuvens, como também os mesmos componentes em diferentes nuvens. Assim, podemos analisar as similaridades e diferenças existentes entre tais ambientes, bem como analisar as facilidades e dificuldades para implantação de aplicações usando os serviços providos por eles. Este artigo está estruturado da seguinte forma. A Seção 2 discute sobre trabalhos relacionados. A Seção 3 apresenta o exemplo que será usado ao longo desse artigo e os detalhes de implementação e implantação desse exemplo nos diferentes ambientes de nuvem analisados. A Seção 4 discute sobre as lições aprendidas e ressalta vantagens e desvantagens de cada ambiente. Por fim, a Seção 5 contém algumas considerações finais e são delineadas direções para trabalhos futuros.

2. Trabalhos Relacionados Existem vários trabalhos na literatura que descrevem experiências com uso de plataformas de nuvens. Os trabalhos citados nesta seção apresentam as experiências de uso com base na comparação entre várias plataformas utilizadas. No trabalho de Peng et al. (2009) são utilizados fatores como escalabilidade, interface Web, suporte a virtualização, confiabilidade, etc. para avaliar várias plataformas de nuvem (AbiCloud, Eucalyptus, Nimbus e OpenNebula). Por sua vez, Cerbelaud et al. (2009) apresentam as experiências de uso de quatro plataformas (ECP, Eycalyptus, OpenNebula e oVirt) no tocante a gerenciamento de imagens (criação, atualização e armazenamento) e instanciação de imagens (monitoramento, quotas, controle de usuário e gerencia de clusters). Nessa mesma linha, Sempolinski e Thain (2010) descrevem as principais características de três plataformas de nuvem (Eucalyptus, OpenNebula e Nimbus) e apresentam como tais características podem representar problemas na utilização destas plataformas. Finalmente, Endo et al. (2010) apresentam um conjunto de desafios de uso criados pela falta de padronização nas interfaces fornecidas por sete plataformas de nuvem.

As experiências de uso descritas pelos trabalhos relacionados são baseadas em elementos arquiteturais da infraestrutura de cada plataforma analisada, como, por exemplo, o tipo de biblioteca de virtualização suportada por cada plataforma e como tal elemento influencia nas aplicações implantadas. Por outro lado, nosso trabalho tem como foco relatar as mudanças necessárias no código de uma aplicação Web para migrá-la de um ambiente de Nuvem para outro. Tais relatos complementam os existentes na literatura, pois permitem antecipar para o desenvolvedor quais problemas de implementação poderão ser encontrados quando uma mesma aplicação for implantada em mais de uma plataforma de nuvem.

X Workshop em Clouds e Aplicações 57

3. Utilizando Plataformas de Nuvem Nesta seção utilizaremos um estudo de caso para analisar como é feita a implementação e a implantação de funcionalidades de uma aplicação em três das principais plataformas de Nuvem existentes: Amazon Web Services (AWS), Google App Engine (GAE) e OpenStack. Os nossos objetivos são: (i) relatar como implementar e implantar aplicações para essas plataformas de nuvem, e; (ii) ressaltar as vantagens e desvantagens de cada plataforma, bem como levantar as dificuldades que surgiram para cada etapa. Para o estudo de caso, selecionamos o Health Watcher (HW) (Soares et al., 2006), que se trata de uma aplicação Web para registro de queixas e outras informações sobre problemas de saúde em uma cidade. Esta escolha foi motivada pelo fato do HW ser uma aplicação real e bem documentada, tendo sido usada em diferentes contextos. Analisando sua parte técnica, o HW possui requisitos encontrados em diversos sistemas, como interface gráfica Web, persistência relacional, suporte à concorrência e uso de tecnologias de implementação como Java Servlets, JDBC (Java Database Connectivity) e RMI (Remote Method Invocation).

A Figura 1 mostra os módulos do HW que foram implantados utilizando os serviços de nuvem providos por diferentes plataformas.

Figura 1: Módulos do HW e serviços de nuvens.

Para analisar os serviços providos por diferentes plataformas de Computação em Nuvem, usamos alguns módulos do HW, como ilustra a Figura 1. Os módulos do HW e os respectivos serviços de nuvens nos quais eles serão implementados são os seguintes:

• Módulo Web: este módulo é responsável por apresentar a interface gráfica ao usuário, composta por páginas HTML e formulários, que são exibidos através de um navegador web. As requisições dos usuários são feitas através do módulo Web e os retornos dessas requisições são apresentados aos usuários também pelo módulo Web. A implantação do HW na nuvem é feita através da criação de instâncias com suporte a um servidor Web. Usamos o Apache Tomcat como servidor Web para este estudo de caso. As requisições do HW e seus resultados consomem processamento. Com a implantação do HW nas plataformas de nuvem, objetivamos analisar os serviços de capacidade computacional (Amazon EC2, GAE e OpenStack Compute).

• Módulo de Persistência: este módulo é útil para analisarmos os serviços de persistência, relacional ou não, das plataformas de nuvens.

• Módulo de log: com este módulo podemos analisar os serviços de armazenamento de informações simples (e.g. apenas texto) e também serviços de log em nuvem.

58 Anais

• Módulo de Autenticação: o HW possui um módulo de autenticação simples que não é suficiente para testarmos os serviços de autenticação disponíveis nas plataformas de nuvem. Dessa forma, foi necessário desenvolver um módulo de autenticação adicional para este fim.

• Módulo de Gerenciamento de Arquivos: originalmente o HW não possui um módulo de gerenciamento de arquivos; porém, visando analisar este tipo de serviço das plataformas de nuvem, nós o adicionamos ao HW. Assim, é possível associar uma imagem a cada sintoma de uma doença cadastrada no HW e depois exibir esta imagem durante uma consulta àquele sintoma.

Vale salientar que as plataformas AWS e OpenStack categorizam-se como IaaS enquanto que o GAE é PaaS. Desta maneira, os objetivos desses provedores de nuvem diferem um pouco entre si. O AWS e o OpenStack oferecem serviços na nuvem, já o GAE oferece uma camada de middleware para execução de aplicações na nuvem. Todavia, o AWS e o OpenStack também oferecem a possibilidade de se instalar um servidor web e um banco de dados, possibilitando assim a implantação de uma aplicação. Já o GAE não provê um controle total das instâncias, porém é possível implantar aplicações em Java ou Python de maneira simples. Para este estudo de caso, desenvolvido utilizando-se a linguagem Java, as diferenças de objetivos de IaaS e PaaS não influenciam muito, uma vez que os serviços utilizados são semelhantes: servidor web, banco de dados, logging. gerenciamento de arquivos e autenticação.

A seguir, explicaremos cada serviço de nuvem que foi usado para este estudo de caso. Também mostraremos os trechos de código responsáveis pelo acesso ao serviço. Adicionalmente, o processo de implantação de cada módulo na nuvem será detalhado.

3.1. AWS A plataforma Amazon Web Services (AWS) é amplamente utilizada por empresas de vários tamanhos e domínios e provê serviços relacionados a capacidade de processamento, facilidades de armazenamento, e várias outras funcionalidades que permitem que empresas façam a implantação de suas aplicações e serviços a um custo baixo, de maneira flexível, escalável e confiável. Entre tais serviços, podemos destacar: (i) Amazon EC2, que oferece recursos computacionais elásticos através da criação de instâncias de máquinas virtuais para hospedar aplicações; (ii) Amazon SimpleDB, que implementa um banco de dados não relacional; (iii) Amazon S3, que permite o armazenamento de arquivos na nuvem, e (iv) Amazon RDS, que permite a criação de instâncias de bancos de dados relacionais, como MySQL e Oracle.

3.1.1 Módulo Web

Para gerenciar as páginas Web e formulários do HW, optamos por usar o servidor Web Apache Tomcat5 por ser open-source, rápido, leve e estar disponível no AWS. Ele já vem instalado em instâncias pré-configuradas do Amazon Elastic Compute Cloud (EC2)6.

Uma aplicação Web, com extensão .war pode ser implantada em uma instância Amazon EC2 com o Apache Tomcat instalado. Há duas maneiras de executar esta implantação. A primeira é gerando o arquivo .war e executando o seu upload através do Amazon Elastic Block Store (EBS)7. Com isso, uma instância é criada automaticamente no Amazon EC2 e a aplicação é posta em execução em uma URL a ser fornecida pelo Amazon EBS. Essa operação

5 Apache Tomcat – http://tomcat.apache.com/ 6 Amazon Elastic Compute Cloud (EC2) – http://aws.amazon.com/ec2/ 7 Amazon Elastic Block Store (EBS) – http://aws.amazon.com/ebs/

X Workshop em Clouds e Aplicações 59

pode ser feita usando o console de gerenciamento do AWS. A segunda maneira é utilizando o plug-in do AWS para a IDE Eclipse.

3.1.2 Módulo de Persistência

O Amazon Relational Database Service (RDS)8 foi usado para realizar persistência de dados do HW no AWS. Este serviço oferece suporte a banco de dados MySQL e Oracle. Para utilizar o Amazon RDS, é necessário acessar o console do serviço e criar uma instância de banco de dados. Para este estudo de caso, utilizamos o MySQL, versão 5.1.50. Em seguida, é necessário fornecer autorização às máquinas que irão acessar este banco de dados, através do endereço IP das mesmas. Em uma máquina autorizada, já é possível acessar o banco de dados através do seu endpoint, que é um dos atributos do banco de dados no Amazon RDS. A porta para o MySQL é, usualmente, a 3306. Nesse ponto fizemos o restore do banco de dados do HW no Amazon RDS.

O HW já possui toda a infraestrutura necessária à persistência relacional de dados. Para direcionar todos os comandos SQL da aplicação para o banco de dados no Amazon RDS é necessário colocar o endereço do endpoint do banco de dados da nuvem no caminho do Java Database Connectivity (JDBC), conforme o trecho marcado na linha 32 da Figura 2.

Figura 2: Trecho da classe ConstantsHW para conexão com o Amazon RDS.

Figura 3: Trecho da classe LogMechanism com uso do Amazon SimpleDB

3.1.3 Módulo de Log

O HW possui um módulo de log que envia todas as informações relevantes para a classe LogMechanism. O AWS não oferece um serviço de Log explícito, como o GAE, porém, oferece um serviço de armazenamento de informações puramente textuais, chamado Amazon SimpleDB9. Utilizamos este serviço para armazenar as informações de Log do HW. Para realizar o armazenamento das informações de log do HW no SimpleDB, fizemos algumas alterações na classe LogMechanism original. Todas as informações de log do HW são redirecionadas para esta classe, que realiza o armazenamento das informações para futuras auditorias. As alterações realizadas nesta classe são mostradas na Figura 3. Nessa figura, é mostrado o método addLog, que recebe uma mensagem de log e seu respectivo nível de importância. Na linha 80, uma lista para armazenar essas informações é criada. As linhas 97 a 102 adicionam informações a esta lista. Finalmente, na linha 103, essas informações são enviadas ao Amazon SimpleDB, no endereço armazenado na variável domainSDB, definida na classe ConstantsHW, que contém as definições de variáveis que são utilizadas ao longo de todo o projeto HW.

8 Amazon Relational Database Service (RDS) – http://aws.amazon.com/rds/ 9 Amazon SimpleDB – http://aws.amazon.com/simpledb/

60 Anais

3.1.4 Módulo de Autenticação

O AWS possui um serviço de controle de acesso aos seus recursos e serviços, o AWS Identity and Access Management (IAM), no endereço http://aws.amazon.com/iam/. Porém, para utilizá-lo seria necessário alterar de maneira considerável a arquitetura do HW. O HW originalmente está preparado para realizar uma autenticação através de um banco de dados relacional. Para realizar uma autenticação utilizando o IAM da Amazon seria necessário alterar toda a parte de modelo, persistência, padrões de projeto e configurações relacionadas com a funcionalidade de login. Por esse motivo, optamos por não analisar este serviço, uma vez que uma das restrições do estudo de caso é não alterar a arquitetura já consolidada do HW.

3.1.5 Módulo de Gerenciamento de Arquivos

O módulo de gerenciamento de arquivos (GA) não existe no HW original. Este módulo foi adicionado para analisarmos os serviços de GA das plataformas em nuvem. O suporte ao GA foi feito sem mudanças significativas na arquitetura do HW. Adicionamos um campo no formulário de cadastro de novos sintomas, no qual o usuário pode associar uma imagem a cada novo sintoma. Cada imagem é armazenada com o código do sintoma mais a extensão .jpg. Posteriormente, ao consultar uma doença, o usuário poderá visualizar os sintomas e suas respectivas imagens.

No AWS, o serviço de gerenciamento de arquivos é o Amazon Simple Storage Service (S3)10. Para fazer o upload de uma imagem, é preciso criar um objeto PutObjectRequest. Como pode ser visto na Figura 4, esse objeto recebe como parâmetros o nome do bucket (um container para objetos armazenados no Amazon S3 que pode ser recuperado de maneira unívoca através de uma chave de acesso), o nome com o qual a imagem será salva e o arquivo que representa a imagem. Por questões de segurança, apenas o criador do arquivo no Amazon S3 tem autorização para visualizá-lo. Para fornecer permissão para que qualquer pessoa possa ver a imagem, é preciso executar a linha 79, que dá permissão para o público em geral. Por fim, na linha 80, o objeto PutObjectRequest, no caso a imagem, é lançada no Amazon S3.

Figura 4: Classe InsertSymptom com upload de uma imagem para o Amazon S3

3.1.6. Implantação

A implantação da aplicação completa na nuvem requer alguns cuidados e configurações adicionais. As formas de se implantar uma aplicação no AWS já foram mostradas nas subseções anteriores. Veremos, a seguir, as interações que precisam ser configuradas para que haja comunicação entre os módulos do HW. As interações entre módulos do HW que representam comunicação entre serviços no AWS são: (1) módulos Web e Persistência utilizando Amazon EC2 e Amazon RDS; (2) módulos Web e Gerenciamento de Arquivos utilizando Amazon EC2 e Amazon S3.

Para que a interface Web possa se comunicar com o banco de dados na nuvem, é preciso que a aplicação implantada no Apache Tomcat em uma instância do Amazon EC2 possa acessar o banco de dados do HW implantado no Amazon RDS. Para tal, é preciso configurar as permissões de segurança no console do serviço, autorizando o acesso da instância ao banco de dados. A comunicação da interface gráfica com o sistema de arquivos é necessária para que as imagens das doenças possam ser mostradas dentro das páginas HTML. Isto não é trivial, já que

10 Amazon Simple Storage Service (S3) – https://console.aws.amazon.com/s3/

X Workshop em Clouds e Aplicações 61

com a aplicação implantada na nuvem, o sistema de arquivos não é o que usamos normalmente, visto que os arquivos estão em um local diferente do qual se encontram as páginas HTML. Assim, é preciso fornecer permissão de visualização em cada arquivo para que a instância do Amazon EC2 onde está implantado o HW possa exibir as imagens. Isso já é feito automaticamente no código do HW ao fazer o upload de uma imagem para o Amazon S3, conforme detalhado na seção 3.1.5. 3.2. GAE

O Google App Engine (GAE)11 prioriza o suporte a hospedagem de aplicações Web com suporte nativo para Python e Java. A virtualização e elasticidade claramente observadas na plataforma da Amazon são praticamente imperceptíveis no GAE. Isto ocorre porque todo o gerenciamento de virtualização e a elasticidade são feitos de forma automática pelo GAE, de acordo com o número de requisições recebidas por uma aplicação. 3.2.1 Módulo Web

O HW usa a API Java Servlet como um mecanismo de interação com o servidor web. Quando o GAE recebe uma solicitação, ele determina qual classe de servlet deve ser chamada através de um arquivo de configuração XML (web.xml) conhecido como descritor de implantação. 3.2.2 Módulo de Persistência

Para o mecanismo de persistência do HW, foi usada a API JDO (Java Data Object) para o armazenamento de dados no GAE. Essa interface é oferecida pelo DataNucleus Access Platform, uma implementação de código aberto de vários padrões de persistência Java, com um adaptador para o armazenamento de dados do GAE. Essa plataforma de acesso requer um arquivo de configuração chamado jdoconfig.xml, que especifica o armazenamento de dados do GAE como o backend para a implementação do JDO.

Para criar classes JDO, utilizam-se anotações Java para descrever como as instâncias devem ser armazenadas e como devem ser recriadas ao serem recuperadas do armazenamento de dados. No trecho de código apresentado na Figura 5, referente à classe Employee (que representa um funcionário que utiliza o HW), os campos privados da classe são anotados como @Persistent para determinar que o DataNucleus os armazene como propriedades de objetos no armazenamento de dados do Google App Engine. Cada entidade tem uma chave exclusiva entre todas as entidades do GAE, e a chave de um objeto é armazenada em um campo da instância; o campo de chave principal é identificado através do uso da anotação @PrimaryKey.

Figura 5. Anotações referentes à persistência da classe Employee.

Em termos de gerenciamento da persistência de dados, para cada solicitação que usa o armazenamento de dados é requisitada a instância da classe PersistenceManager (já criada com o uso do padrão singleton), como mostrado na linha 26 do trecho de código da classe EmployeeRepositoryJDO apresentado na Figura 6. Para persistir o objeto de uma classe, é invocado o método makePersistent  sendo passado como parâmetro o referido objeto, como mostrado na linha 30 da Figura 6.

11 Google App Engine (GAE) – https://appengine.google.com/

62 Anais

Figura 6. Persistência da classe Employee via JDO usando makePersistent.

A classe javax.jdo.PersistenceManager, própria do JDO, utiliza uma instância

da classe PersistenceManagerFactory para persistir os dados na nuvem do Google. Com isso, basta implantar a aplicação no GAE; se a aplicação for executada localmente, será criado um arquivo binário simulando o serviço de dados BigTable do GAE na máquina local.

3.2.3 Módulo de Log

Para a implementação da funcionalidade de logging do HW no GAE, o primeiro passo foi copiar o arquivo logging.properties, que contém informações sobre o sistema de logging do GAE (basicamente nível default de erros), para o diretório WAR da aplicação e depois definir uma propriedade no arquivo de configuração appengine-­‐web.xml,  ativando assim o serviço de log da Google. Feito isso, na classe LogMechanism, é chamado um método que recebe como parâmetro um objeto que contém as informações de log do HW a serem armazenadas. Com isso, informações importantes são persistidas no serviço de logging do GAE; essas informações podem ser acessadas diretamente pelo navegador através do console de gerenciamento do GAE.

3.2.1.4 Módulo de Autenticação

Considerando a possibilidade de permitir múltiplas formas de autenticação, utilizando contas de infraestruturas de plataformas de nuvem, foi adicionada a autenticação utilizando um serviço Google, o Authentication and Autorization for Google App. Os mecanismos/protocolos/bibliotecas que o desenvolvedor pode utilizar para realizar as tarefas de autenticação são: OAuth 2.0, OpenID e ClientLogin API.

Para submeter o pedido de autenticação é necessário formar uma URL e, através de um pedido do tipo POST, enviar os parâmetros de autenticação. Para realizar esse procedimento, foi utilizada a biblioteca HttpComponents da Apache, que é uma implementação Java dos principais componentes do protocolo HTTP. Conforme disponibilizado na API ClientLogin a URL que deve ser utilizada para enviar uma requisição POST seria https://www.google.com/accounts/ClientLogin?.

Foi criada uma classe GoogleLogin onde é realizada a requisição POST à API ClientLogin para autenticação de usuário. O método estático authenticate recebe como parâmetros o login e a senha da conta que será autenticada. Primeiramente é criado um objeto da classe DefaultHttpClient que representa um cliente HTTP e, em seguida, criado um objeto da classe HttpPost que encapsula uma requisição do tipo POST, fornecendo como parâmetro para o construtor o endereço HTTP da interface ClientLogin. Como estão sendo enviados os dados de usuário e senha, para proteger os mesmos é necessário enviar esses dados codificados, aumentando assim a segurança da requisição. Logo, o cliente HTTP envia a requisição POST ao servidor, cuja resposta é encapsulada em um objeto da classe HttpResponse. Conforme definido na API, se o processo de autenticação, representado pela chamada ao método execute da classe DefaultHttpClient, retornar como resposta a string “OK”, a autenticação foi realizada com sucesso e o método authenticate retorna o valor true (verdadeiro); em caso contrário, houve falha na autenticação e o método retorna o valor false (falso).

X Workshop em Clouds e Aplicações 63

3.2.5 Módulo de Gerenciamento de Arquivos

O GAE provê um serviço chamado Blobstore, que permite o armazenamento de objetos de dados de tamanho até 2 GB, objetos esses denominados blobs e que são exibidos como respostas a manipuladores de solicitação. As aplicações não criam dados de blob diretamente; em vez disso blobs são criados indiretamente, via formulário Web enviado por outra requisição HTTP POST.

Para implementar esse serviço, seria necessário alterar de forma significativa a estrutura do HW, removendo o padrão de projeto Adapter. Por esse motivo, o serviço de sistema de arquivos utilizando Blobstore do GAE não foi incluído, pois uma das restrições do estudo de caso é não alterar a arquitetura já consolidada do HW.

3.2.6. Implantação

Para fazer a implantação do HW no GAE, é necessário que a aplicação tenha um registro de ID, fornecido quando se cria um aplicativo usando o Console de administração do GAE. Depois de registrado o ID para o HW, este é enviado para o GAE usando o plug-in do Eclipse ou uma ferramenta de linha de comando do SDK.

3.3. OpenStack

O OpenStack é um projeto mantido pela Rackspace e NASA com o objetivo de oferecer soluções para todos os tipos de nuvem de maneira escalável e fácil de implementar. Produto de uma comunidade global de desenvolvedores, o OpenStack oferece serviços de processamento (OpenStack Compute), armazenamento de arquivos (OpenStack Storage) e imagem virtual (OpenStack Image). Ele é utilizado por grandes empresas, como é o caso do MercadoLivre12. Neste trabalho criamos uma nuvem privada usando o OpenStack e implantamos o HW para analisar os serviços providos.

3.3.1 Módulo Web

O módulo Web do HW foi implantado na nuvem privada do OpenStack sem maiores alterações, dado que sua API é baseada na do Amazon EC2. Porém, como será descrito em detalhes na seção 3.3.6, foi necessário instalar o servidor Web Apache Tomcat e fazer configurações de permissão de acesso para que fosse possível o acesso ao HW em execução na nuvem privada. Foram configuradas também permissões em portas do sistema operacional Ubuntu relacionadas com o Tomcat e com o MySQL.

3.3.2 Módulo de Persistência

O HW original já possuía um sistema de persistência relacional. Para utilizar este sistema na nuvem privada, fizemos alterações nas configurações de banco de dados do HW e apontamos para utilizar o MySQL instalado na nuvem. O acesso ao banco de dados é feito via JDBC e o endereço do banco de dados é localhost, pois o banco é visto como local pelo HW, e a porta é a 3306. O procedimento de instalação do banco é descrito na seção 3.3.6.

3.3.3 Módulo de Log

O OpenStack não possui um serviço de log. Para que este módulo do HW pudesse ser testado também nesta plataforma, criamos uma tabela no banco de dados e utilizamos o módulo de persistência para armazenar as informações de log da aplicação, a saber, nível de importância,

12 Usuário do OpenStack – http://openstack.org/user-stories/mercadolibre-inc/

64 Anais

mensagem e data/hora. Há também a possibilidade de se salvar o log em arquivo. Como o HW está implantado na nuvem privada, seu acesso ao sistema de arquivos do sistema operacional é similar ao acesso local. Todavia, é preciso dar as devidas permissões no diretório onde o HW salvará os arquivos de log.

3.3.4 Módulo de Autenticação

O HW original possui um módulo de autenticação que utiliza o banco de dados relacional. Como o OpenStack não oferece este serviço de autenticação, optamos por realizar a autenticação utilizando o banco de dados instalado na nuvem privada. Assim, esse módulo não fica comprometido e o HW pode ser executado completamente, já que algumas funcionalidades exigem o login do usuário para serem acessadas.

3.3.5 Módulo de Gerenciamento de Arquivos

A nuvem privada que criamos oferece toda sua capacidade de armazenamento para as aplicações a serem executadas nela. Assim, configuramos o HW para que as imagens enviadas pelos usuários sejam armazenadas nos servidores que compõem a nuvem e fiquem à disposição da aplicação para futura exibição quando consultadas.

3.3.6. Implantação

A nuvem OpenStack usada para hospedar o HW foi criada para a realização deste estudo de caso. O sistema operacional é uma distribuição Linux, Ubuntu Server acompanhado de um software de virtualização. Em uma visão estrutural, a abordagem adotada possibilita o uso de diferentes arquiteturas para instalação da nuvem OpenStack, sendo todas elas compostas por três componentes principais: um nó de controle, um de rede e um ou mais nós de processamentos. Eles podem ser distribuídos em arquiteturas single, dual ou multinode de acordo com a necessidade do usuário, tendo em vista que cada uma tem requisitos de hardware e software específicos. Para a implantação do HW no OpenStack, por questões de simplicidade, foi utilizada a arquitetura single node, onde todos os componentes OpenStack são instalados em uma mesma máquina física.

Depois de feita a instalação de base, ou seja, o sistema operacional acompanhado do software de suporte, foi realizado o deploy do OpenStack Nova de acordo com a arquitetura escolhida. Em seguida foi necessário acessar o nó de controle e configurar as permissões de acesso de usuário e rede. Tendo finalizado esses passos, a nuvem está pronta para receber as instâncias de máquinas virtuais. Elas podem ser geradas diretamente no sistema, usando a ferramenta Euca2ools ou ainda com auxilio de algum software com GUI, como por exemplo, o Dashboard Horizon (que já é instalado durante o deploy do OpenStack Nova) ou com um plug-in do Firefox chamado HibridFox. É importante ressaltar que para criar uma instância é necessário ser um usuário da nuvem, logo para cada usuário é gerado um arquivo de permissão com extensão .pem. Esse arquivo é usando exatamente na criação da instância da máquina Virtualizada, servindo também de chave autenticadora para efetuar o login na máquina instanciada. Este login pode ser feito via ssh, ou ainda através do Horizon, que disponibiliza uma opção de acesso VNC. Com a instância ativa, foi necessário fazer a instalação do Apache Tomcat e do MySQL na própria máquina virtual. Tendo realizado esses procedimentos, a instância estava pronta para a implantação do HW.

Depois de configurada a nuvem do OpenStack, foi feita a restauração do banco de dados do HW e o deploy da aplicação no Apache Tomcat. Configurações adicionais de permissão não foram necessárias, pois a execução é similar a uma execução local. Porém, para acessar a instância e fazer qualquer procedimento, é preciso utilizar ssh e passar o arquivo de permissão.

X Workshop em Clouds e Aplicações 65

4. Discussão

Esta seção tem como objetivo discutir as facilidades e dificuldades de desenvolvimento e implantação do estudo de caso nas três diferentes plataformas de nuvem supracitadas. Para cada módulo do HW foram realizadas configurações distintas para cada ambiente de nuvem, mostrando que há diferenças significativas no processo de implantação de uma aplicação para cada ambiente.

Para a implantação do Módulo Web no AWS e OpenStack foi necessário apenas gerar o arquivo .war e realizar a implantação na instância contendo o Apache Tomcat. Para o GAE, foram feitas algumas alterações no projeto, como no arquivo web.xml. O Módulo de Persistência foi o que apresentou maiores diferenças de uma nuvem para a outra. No AWS foi necessário instanciar um banco de dados MySQL no Amazon RDS e configurar permissões de acesso. Já no OpenStack foi necessário apenas instalar o MySQL na instância e usar como se fosse um banco de dados local, dadas as permissões necessárias de acesso via rede. Já para usar o BigTable do GAE, foi necessário anotar todas as classes relacionadas com a persistência de dados para que o JDO pudesse persistir os dados no banco em questão. Para que o Módulo de Log do HW armazenasse as informações de log no GAE foi necessário apenas alterar uma configuração no arquivo logging.properties e adicionar uma linha de código na classe LogMechanism. Como escolhemos utilizar o Amazon SimpleDB para armazenar essas informações no AWS, foram necessárias algumas alterações de código nas classes ConstantsHW e LogMechanism. Já para salvar o log do HW no OpenStack, nós fizemos uma ligação com o Módulo de Persistência e salvamos os dados em uma tabela do banco de dados. O Módulo de Autenticação foi criado no HW e testado no GAE utilizando o Authentication and Autorization for Google App. A classe GoogleLogin foi criada para realizar a autenticação e algumas alterações foram feitas em outras classes do HW relacionadas com o login. Já para o AWS e OpenStack, foi utilizado o login convencional do HW, que utiliza o banco de dados para realizar a autenticação. O Módulo de Gerenciamento de Arquivos foi testado no AWS utilizando o Amazon S3. Algumas alterações foram feitas na classe InsertSymptom, para que as imagens dos sintomas fossem armazenadas no referido serviço. No OpenStack os arquivos foram armazenados no sistema de arquivos local, como se o HW fosse executado localmente. Não usamos o serviço BlobStore do GAE porque para usá-lo seria necessário alterar a arquitetura do HW.

Os valores a serem pagos variam para cada plataforma de nuvem. Como nós implantamos uma nuvem privada utilizando o OpenStack, podemos considerar que o custo monetário para executar os serviços nessa nuvem foi zero, mas houve necessidade de se remunerar um administrador responsável por configurar a plataforma e seus serviços.. Já para executar o HW durante 90 dias no AWS, com uma média de mil requisições por dia, seria necessário pagar um total de R$ 295,86 e apenas R$ 101,52 no GAE (considerando a extrapolação da cota gratuita que essas plataformas proveem). Uma combinação de execução com diferentes módulos em diferentes nuvens também é possível, resultando em variações nestes preços entre zero, quando todos são executados no OpenStack, e R$ 295,86, quanto todos são executados no AWS durante o mesmo período de tempo.

Sobre o esforço para a realização deste estudo de caso, podemos dizer que o OpenStack foi o mais trabalhoso por ter exigido a criação da nuvem privada, instalação do software necessário e configuração da rede e das permissões. As dificuldades encontradas incluem: (i) o funcionamento de alguns softwares que se deu de maneira diferente da esperada, o que foi corrigido com o uso de uma versão mais recente; (ii) a nuvem ter se mostrado um pouco instável em situações nas quais o servidor ficou sem conexão a rede, de modo que quando a conexão era reestabelecida, os serviços do OpenStack ficavam inativos, e; (iii) o problema de falta de sincronização entre componentes da nuvem, o que foi contornado sincronizando a

66 Anais

nuvem privada com algum servidor externo. O esforço para utilizar o GAE e o AWS pode ser resumido ao aprendizado da API de acesso aos serviços, além do pagamento das taxas devidas.

Um resumo sobre os passos necessários para se implantar cada módulo do HW e o preço de implantação são resumidos na Tabela 1. As células em negrito representam em que plataforma o quesito analisado é mais vantajoso. A última linha da tabela apresenta o preço final para cada plataforma.

Tabela 1 – Visão Geral das Plataformas de Nuvem Quesito/Plataforma AWS GAE OpenStack

Módulo Web -Uso de credenciais -Uso de plugin do Eclipse. -Deploy console do EBS.

-Configuração de arquivos -Estrutura de projeto pré-definida

-Implantação similar à local.

Módulo de Persistência -Permissão para desenvolver -Permissão para acessar

-Uso de JDO -Anotação nos modelos -Configurar jdoconfig.xml

Conexão com o banco é feita através de JDBC como para um banco local.

Módulo de Log -Serviço SimpleDB. -Simples e barato -Aprender API

-Serviço de Log do GAE –Configurar logging.properties e appengine-web.xml.

Foi utilizado o banco de dados do HW para armazenar as informações de Log.

Módulo de Autenticação -Banco de dados do HW

-Serviço de autenticação do GAE . -Criar uma classe para acessar o serviço

-Banco de dados do HW

Módulo de G. de Arquivos

-Serviço S3. -Confiável e barato -API simples.

-Não foi feito no GAE

-Uso do HD da nuvem privada

Implantação -A implantação simples. -Deploy pelo console do EBS.

-Plugin do Eclipse. -Criação e configuração da nuvem.

Preço R$295,86/90 dias R$101,52/90 dias. R$0,00/90 dias.

5. Conclusão

Neste artigo apresentamos as principais experiências adquiridas ao se implantar uma mesma aplicação em três plataformas de nuvem. Estas experiências permitem orientar desenvolvedores sobre possíveis problemas que os mesmos podem enfrentar ao se implantar aplicações nas nuvens. Entre as orientações, destacamos os cuidados com o uso de alguns serviços, como autenticação, persistência, log e armazenamento de arquivos. Além destas contribuições, o artigo também discutiu e demonstrou que, em termos de nuvem pública, a implantação do HW no GAE demandou menos recursos financeiros em comparação com o serviço fornecido pela Amazon. Apesar da implantação dos módulos do HW no OpenStack ter custo zero, dado que foi criada uma nuvem privada, foi preciso reservar um servidor apenas para esta finalidade e alocar uma máquina para hospedar a plataforma. Como resultado, houve uma elevação nos custos de utilização da nuvem privada. Porém, a criação da nuvem privada nos permitiu analisar também o processo de criação desse tipo de provedor de serviço, aumentando nossa visão de apenas usuários de serviços de nuvem para também de provedores de serviço de nuvem. Como trabalhos futuros, pretendemos avaliar, através de diferentes técnicas de teste, fatores adicionais que influenciam na implantação de uma aplicação nas nuvens. Pretendemos também avaliar através da definição e execução de um benchmark qual a relação custo/desempenho de utilizar uma mesma aplicação em várias plataformas de nuvem. Além da realização de testes e análise da execução de um benchmark, pretendemos fazer uma análise do tráfego de dados dentro da nuvem através do uso de softwares como o Lattice (Clayman et al. 2010). Este software também

X Workshop em Clouds e Aplicações 67

poderá ser utilizado para analisarmos o tráfego de dados entre diferentes nuvens, quando a aplicação tiver módulos implantados em nuvens distintas. Nosso objetivo com esses novos trabalhos é coletar informações para que os módulos de uma aplicação sejam implantados em nuvens que apresentem melhores características como preço, disponibilidade, desempenho, dentre outras.

Agradecimentos Esse trabalho foi desenvolvido no contexto do projeto AltoStratus, financiado pelo CTIC/RNP (Rede Nacional de Pesquisa). Thiago Sena e Nélio Cacho são parcialmente apoiados pelo projeto FAPERN PPP-III-013/ 2009. Nélio Cacho é parcialmente apoiado pelo Instituto Nacional de Engenharia de Software (INES), financiado pelo CNPq 573964/2008-4.

Referências Armbrust, M. et al. (2009) Above the clouds: A Berkeley view of Cloud Computing – Technical report.

Reliable Adaptive Distributed Systems Laboratory, University of California at Berkeley, USA. Cerbelaud, D. et al. (2009) “Opening the clouds: Qualitative overview of the state-of-the-art open source

VM-based cloud management platforms”. Proc. of the 10th ACM/IFIP/USENIX Int. Conf. on Middleware (Middleware’09). New York, NY, USA: Springer-Verlag, pp.1-8.

Clayman, S et al (2010) “Monitoring Service Clouds in the Future Internet. Towards the Future Internet - Emerging Trends from European Research. (pp. 115 - 126). IOS Press: Amsterdam, The Netherlands.

Endo, P. et al. (2010) “A survey on open-source Cloud Computing solutions”. Anais do VIII Workshop em Clouds, Grids e Aplicações (WCGA 2010). Porto Alegre, RS: SBC, pp. 3–16.

Galán, F. et al. (2009) “Service specification in cloud environments based on extensions to open standards”. Proc. of the Fourth Int. ICST Conf. on Communication System Software and Middleware (COMSWARE 2009). New York, NY, USA: ACM.

Greenwood, Phil et al. (2007) “On the impact of aspectual decompositions on design stability: An empirical study”. Proc. of the 21st European Conf. on Object-Oriented Programming (ECOOP2007). LNCS, 4609. Springer, pp.176–200.

Mell, P.; Grance, T. (2011) The NIST Definition of Cloud Computing – NIST Special Publication, Reports on Computer Systems Technology. National Institute of Standards and Technology, Gaithersburg, MD, USA.

Peng, J. et al. (2009) “Comparison of several Cloud Computing platforms”. Proc. of the Second Int. Symposium on Information Science and Engineering (ISISE 2009). Piscataway, NJ, USA: IEEE Computer Society, pp. 23-27.

Rittinghouse, J.; Randsome, J. (2010) Cloud Computing: Implementation, management and security. Boca Raton, FL, USA: CRC Press.

Sempolinski, P; Thain, D. (2010) “A Comparison and critique of Eucalyptus, OpenNebula and Nimbus”. Proc. of the IEEE Second Int, Conference on Cloud Computing Technology and Science (CloudCom 2010). Piscatway, NJ, USA: IEEE Computer Society, pp. 417–426.

Soares, Sérgio; Borba, Paulo; Laureano, Eduardo (2006) “Distribution and persistence as aspects”. Software – Practice & Experience 36(7), pp.711–759.

Wang, L. et al. (2010) “Cloud Computing: A perspective study”. New Generation Computing 28(2), pp. 137–146.

Zhang, Q. et al. (2010) “Cloud Computing: State-of-the-art and research challenges”. Journal of Internet Services and Applications 1(1), pp. 7–18.

68 Anais