UNIVERSIDADE DO SUL DE SANTA CATARINA
DERIK JONATAN LIMA
PROPOSTA DE ARQUITETURAS PARA DESENVOLVIMENTO DE APLICAÇÕES
CORPORATIVAS VOLTADAS AO AMBIENTE DE NUVEM
Monografia apresentada ao Curso de Especialização em
Engenharia de Projetos de Software da Universidade do
Sul de Santa Catarina, como requisito parcial à obtenção
do título de Especialista em Engenharia de Projetos de
Software.
Orientador: Prof. Osmar De Oliveira Braz Junior, M.Eng.
Florianópolis
2013
DERIK JONATAN LIMA
DIRETRIZES, PADRÕES E BOAS PRÁTICAS NO DESENVOLVIMENTO DE
APLICAÇÕES CORPORATIVAS VOLTADAS AO AMBIENTE DE NUVEM
Esta monografia foi julgada adequada à obtenção do
título de Especialista em Engenharia de Projetos de
Software e aprovada em sua forma final pelo Curso de
Especialização em Engenharia de Projetos de Software
da Universidade do Sul de Santa Catarina.
Florianópolis, 16 de Abril de 2014.
______________________________________________________
Prof. Osmar De Oliveira Braz Junior, M.Eng.
Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Jean Carlo Rossa Hauck, DR.
Universidade do Sul de Santa Catarina
Dedico esta monografia aos meus pais,
Evandro e Fabiana e a minha irmã, Petlyn.
AGRADECIMENTOS
Aos meus pais pelo apoio e grande incentivo, não só neste trabalho, como na vida.
Ao professor Osmar, pela sua orientação.
Ao criador da cerveja, por ter criado o líquido que impulsionou muitas ideias para
o presente trabalho.
“If ignorance is bliss, then knock the smile off my face.” (Rage Against The
Machine).
RESUMO
A computação em nuvem veio para auxiliar as empresas de desenvolvimento de software a
manterem seu foco, preocupando-se menos com infraestrutura e mais com o desenvolvimento
do software em si. A infraestrutura como serviço na nuvem (Infrastructure as a Service, IaaS)
permitiu a criação e evolução de diversas empresas que precisaram de pouco ou nenhum
investimento inicial em hardware e infraestrutura de rede. O presente trabalho visa estudar os
serviços que uma dessas empresas de infraestrutura na nuvem oferece, A Amazon Web
Services (AWS), que é a maior no segmento, assim como as boas práticas de arquitetura
específicas para a infraestrutura na nuvem. Como objetivo, este trabalho fará um comparativo
entre uma arquitetura de uma aplicação legada real, que roda da maneira tradicional, com
servidores físicos próprios, e o que deveria ser alterado para que a mesma funcionasse
utilizando da melhor maneira possível os recursos da infraestrutura em nuvem.
Palavras-chave: Computação em Nuvem. Infrastructure as a Service. Arquitetura. Amazon
Web Services.
ABSTRACT
Cloud computing is here to help companies that developing software to keep your focus,
worrying less about infrastructure and more with the development of the software itself.
Infrastructure as a cloud service (Infrastructure as a Service, IaaS) allowed the creation and
evolution of several companies that needed little or no upfront investment in hardware and
network infrastructure. The present work aims to study the services of one of these companies
in the cloud infrastructure offers, the Amazon Web Services (AWS), which is the largest
company of IaaS, as well as the best practices of architecture specific for cloud infrastructure.
As a goal, this work will make a comparison between an architecture for a real legacy
application that runs in the traditional way, with their own physical servers, and what should
be changed so that it would work the best way possible using the resources of the cloud
infrastructure.
Keywords: Cloud Computing. Infrastructure as a Service. Architecture. Amazon Web
Services.
LISTA DE ILUSTRAÇÕES
Figura 1: Quadrante mágico para provedores de Infraestrutura como Serviço........................14
Figura 2: Console de gerenciamento dos serviços disponibilizados pela AWS.......................23
Figura 3: Screenshot da área de seleção de região do console da AWS, mostrando as atuais
opções de regiões......................................................................................................................29
Figura 4: Zonas de disponibilidades (VERAS, 2013, p. 41).....................................................30
Figura 5: Detalhe da zona de disponibilidade (VERAS, 2013, p. 43)......................................31
Figura 6: Regiões e zonas de disponibilidade (VERAS, 2013, p. 43)......................................31
Figura 7: Níveis de Multitenancy (CHATE, 2010, p. 5)...........................................................36
Figura 8: Arquitetura para hosting de uma aplicação Web.......................................................47
Figura 9: Arquitetura para alta tolerância a falhas e alta disponibilidade utilizando o Elastic
Load Balancing.........................................................................................................................50
Figura 10: Arquitetura para alta tolerância a falhas e alta disponibilidade utilizando o Elastic
IP...............................................................................................................................................51
Figura 11: Diagrama de deployment mostrando a atual infraestrutura que roda as aplicações
da empresa hipotética................................................................................................................52
Figura 12: Uma representação do lado do servidor da interface com o usuário. (BURNS,
2009, p. 37)...............................................................................................................................54
LISTA DE TABELAS
Tabela 1: Frameworks utilizados para suportar o modelo MVC nas aplicações da empresa
hipotética...................................................................................................................................53
LISTA DE SIGLAS
IaaS – Infrastructure as a Service
PaaS – Plataform as a Service
SaaS – Software as a Service
AWS – Amazon Web Services
NIST – National Institute of Standards and Technology
IBM – International Business Machines
CSA – Cloud Security Alliance
REST – Representational State Transfer
SOA – Service-oriented Architecture
WS – Web Services
MVC – Model-view-controller
SUMÁRIO
1 INTRODUÇÃO...............................................................................................................................12
2 REVISÃO BIBLIOGRÁFICA.......................................................................................................18
3 PROPOSTA DE ARQUITETURAS PARA A NUVEM...............................................................46
4 CASO DE USO: APLICAÇÃO LEGADA....................................................................................52
5 CONCLUSÃO..................................................................................................................................57
REFERÊNCIAS................................................................................................................................58
12
1
INTRODUÇÃO
Muitas empresas, principalmente startups1, encontram dificuldades para conseguir
investimentos para iniciar seus negócios. Em alguns casos, faz-se necessário um grande
investimento inicial em infraestrutura computacional para suportar grandes acessos a uma
nova aplicação. Por exemplo, para lançar uma nova rede social, é necessário um grande
investimento em infraestrutura para poder suportar uma grande quantidade de usuários.
(HOWARD, 2010)
Gerenciar a infraestrutura computacional é bastante complexo, pois é difícil saber
exatamente o quanto, em recursos computacionais, você precisará para suportar sua aplicação.
Além disso, cada aplicação pode utilizar os recursos computacionais disponíveis (Ex:
Processamento, memória, armazenamento, performance de rede, entre outros.) de maneiras
diferentes. Algumas aplicações exigem um grande armazenamento de dados, outras exigem
maior processamento, entre outros. (VARIA, 2010)
Se a empresa optar por fazer um grande investimento em infraestrutura, pode vir a
ter um grande prejuízo se a aplicação não der certo. Por outro lado, caso a aplicação cresça
demais e não possua a infraestrutura suficiente, a empresa poderá perder mercado por falta de
performance da sua aplicação para atender a demanda necessária. (VARIA, 2010)
Possuir uma infraestrutura computacional grande também requer custos adicionais
com energia, espaço físico, aluguel de salas, segurança e pessoas capacitadas para gerenciar
esses recursos. (VARIA, 2010)
A computação em nuvem vem para acabar com o problema citado acima.
Computação em nuvem é um novo conceito para abstrair o acesso aos recursos
computacionais, utilizando-os sob demanda. Por recursos computacionais, entende-se: redes,
servidores, armazenamento, aplicações, serviços, entre outros. Esses recursos devem estar
disponíveis rapidamente, com o mínimo esforço de configuração ou interação com o provedor
de serviço. (MELL, 2011)
Conforme REESE (2009, p. 16):
1
Uma startup compreende de uma a oito pessoas, a maioria desenvolvedores, que se uniram para criar
uma base de código cujos benefícios eles oferecerão ao mundo, especialmente o mundo online. Essa base de
código, muitas vezes, pode ser acessado através da Web. (WALSH, 2009, p. 8)
13
“A nuvem é onde você vai para usar tecnologia conforme sua necessidade, pelo
tempo que você precisar e nenhum minuto a mais. Você não instala nada no seu
computador pessoal e você só paga pela tecnologia quando você está utilizando-a.”
A computação em nuvem possui diversas modalidades. Segundo a proposta de
padronização da National Institute of Standards and Technology (NIST), essas modalidades
se dividem em três (MELL, 2011):

Infrastructure as a Service (IaaS);

Plataform as a Service (PaaS), e;

Software as a Service (SaaS).
O IaaS é responsável pelos recursos computacionais providos por um provedor de
nuvem, limitando-se a parte física (hardware) dos recursos, como processamento,
armazenamento, tráfego de rede, entre outros. (MELL, 2011)
Já o PaaS é responsável pelas plataformas de desenvolvimento providas por um
provedor de nuvem. Por plataformas de desenvolvimento entende-se servidores de aplicação 2,
APIs3 para acesso aos recursos disponibilizados, através de uma ou mais linguagens de
programação, entre outros. Nessa modalidade o cliente não possui acesso aos recursos de
hardware. (MELL, 2011)
O SaaS é responsável pelas aplicações providas por um provedor de nuvem. Essas
aplicações rodam totalmente online, não sendo necessário instalar nada localmente. O acesso
a essas aplicações pode ser feito de computadores, dispositivos móveis, entre outros. (MELL,
2011)
No capítulo Revisão Bibliográfica (Capítulo 2), esses temas serão explicados com
maior profundidade.
Para tornar o trabalho mais específico e objetivo, utilizaremos como base para
aplicação dos conceitos propostos a estrutura da Amazon Web Services (AWS) que, segundo
Gartner, é a empresa líder em IaaS.
2
3
Servidor de aplicação refere-se ao processo que fornece as funções que são necessárias para suportar os
aplicativos do usuário. (ALBERTONI, 2010)
API significa Application Programming Interface. Uma API pode fornecer um gancho para colegas,
parceiros ou desenvolvedores terceiros, provendo acesso a dados e serviços para construir aplicações, como
aplicativos para dispositivos móveis, rapidamente. (JACOBSON, 2012)
14
Figura 1: Quadrante mágico para provedores de Infraestrutura como Serviço.
Fonte: <http://www.gartner.com/technology/reprints.do?id=1-1IMDMZ5&ct=130819&st=sb>. Acesso em: 20
dez. 2013.
O presente trabalho será focado apenas no IaaS, que é o modelo de serviço na
computação em nuvem no qual poderemos aplicar arquiteturas para aplicações.
1.1
JUSTIFICATIVA
A arquitetura de sistemas tradicionais foi projetada para utilizar uma infraestrutura
única, com pouca ou nenhuma elasticidade4. É bastante complexo fornecer recursos
computacionais a medida que a demanda cresce. Sendo assim, o cenário mais comum são
4
Elasticidade é a capacidade do ambiente computacional de nuvem aumentar ou diminuir de forma automática
os recursos computacionais demandados e provisionados para cada usuário. (CHEDE, 2009)
15
empresas que possuem recursos insuficientes para sua atual demanda, ou possuem recursos
demasiados para sua demanda, recursos que são desperdiçados, gerando custos para a
empresa. (VERAS, 2013)
Dado o cenário acima, muitas das consolidadas práticas de arquitetura de
aplicações não levam em consideração a arquitetura de recursos dos provedores de nuvem
como elasticidade, balanceamento de carga e uma arquitetura voltada a serviços. (VARIA,
2010)
A maioria das aplicações são criadas sem a arquitetura necessária para a
elasticidade e extensibilidade das mesmas, o que ocasiona um mal aproveitamento dos
recursos de infraestrutura quando a aplicação é portada para a nuvem. (VARIA, 2010)
Hoje em dia a nuvem surge como uma solução para utilizar grandes recursos
computacionais e de infraestrutura, sem a necessidade de um grande investimento inicial.
Além disso, utilizando os serviços de infraestrutura de um provedor de nuvem, é possível
aumentar a capacidade de recursos para uma aplicação de maneira simples, rápida e com
baixo custo, diminuindo muito o risco de investimentos em infraestrutura. (VARIA, 2010)
Para adequar as aplicações a essa nova realidade, é necessário um projeto de
arquitetura que saiba utilizar da melhor maneira possível esses recursos disponibilizados pelo
provedor de nuvem. (VARIA, 2010)
Este trabalho possui a intenção de mostrar algumas boas práticas de arquitetura de
aplicações que auxiliam no melhor uso possível dos recursos da nuvem. Por melhor uso se
entende alta performance, baixo custo, alta escalabilidade, alta disponibilidade de dados e alta
segurança. Além disso, pretende fazer um comparativo prático entre a atual arquitetura de
uma aplicação legada e o que a mesma deve alterar na sua arquitetura para se ajustar aos
novos conceitos da nuvem.
1.2
OBJETIVOS
Para facilitar o entendimento, os objetivos foram divididos em duas partes:
objetivo geral e objetivo específico.
16
1.2.1
Objetivo Geral
O objetivo geral do trabalho é propor soluções arquiteturais para que novas aplicações
possam utilizar os recursos dos provedores de nuvem da melhor maneira possível, de acordo
com objetivos predefinidos como: baixo custo, alta performance, alta disponibilidade, alta
segurança, entre outros, além de realizar um comparativo entre a arquitetura atual de uma
aplicação legada, que não é utilizada com os recursos da nuvem, e o que deveria ser alterado
para que a mesma suportasse da melhor maneira possível os recursos da nuvem.
1.2.2
Objetivo Específico
Os objetivos específicos são:






1.3
Definir os conceitos envolvidos em Computação na Nuvem;
Apresentar os serviços que são disponibilizados nos principais provedores de Nuvem;
Apresentar como esses serviços devem ser utilizados;
Propor boas práticas de desenvolvimento de aplicações para a nuvem;
Propor arquiteturas de aplicações para objetivos específicos;
Fazer um estudo sobre uma aplicação legada não projetada para nuvem e o que
deveria ser alterado para a mesma utilizar corretamente todos os recursos de nuvem.
METODOLOGIA
A metodologia do trabalho será conceitual e teórica, sendo fundamentada em pesquisa
bibliográfica.
O trabalho será baseado em estudos teóricos sobre os serviços disponíveis nos
provedores de nuvem e as boas práticas de arquiteturas disponíveis no mercado, culminando
em diversas propostas de arquitetura de aplicações específicas para a nuvem que caminhem de
acordo com o objetivo do cliente.
17
1.4
ESTRUTURA DO TRABALHO
O trabalho está dividido em cinco partes:

A introdução apresenta os objetivos, a justificativa e a motivação do trabalho, além de
explicar, brevemente, alguns conceitos importantes de computação em nuvem para
auxiliar no entendimento do trabalho;

A segunda parte fará a revisão bibliográfica dos conceitos que serão necessários para o
entendimento da proposta desse trabalho, como Computação em Nuvem, Cache,
Amazon Web Services (AWS), Representational State Transfer (REST), Serviceoriented Architecture (SOA), Elasticidade, Balanceamento de Carga, Paralelização,
Redundância, Multi-tenant, entre outros;

A terceira parte apresentará as propostas de arquiteturas de aplicações que melhor se
adéquam aos conceitos citados acima para que possa servir de base para entidades que
queiram criar aplicações totalmente adequadas ao ambiente de nuvem;

A quarta parte apresenta um caso de uso das alterações necessárias em uma aplicação
legada para que a mesma utilize da melhor maneira possível os recursos do ambiente
de nuvem;

A quinta, e última, parte apresenta a conclusão do trabalho e sugestões para futuros
trabalhos.
18
2
REVISÃO BIBLIOGRÁFICA
Este capítulo é responsável por dar o embasamento teórico necessário para o
correto entendimento da proposta deste trabalho. Conceitos como Computação em Nuvem,
Cache, AWS, REST, SOA, Elasticidade, Balanceamento de Carga, Paralelização,
Redundância, Multi-tenant, entre outros, serão vistos.
2.1
VISÃO GERAL SOBRE A NUVEM
Existem diversos modelos que propõe uma arquitetura de referência para explicar
a computação em nuvem. Segundo Veras (2013, p. 16), existem quatro arquiteturas de
referência que se destacam:

NIST Cloud Computing Reference Architecture

IBM Cloud Reference Architecture

Cisco Cloud Reference Architecture

Cloud Reference Model da CSA
Ainda segundo Veras (2013, p. 16), o modelo NIST é o mais aceito atualmente.
Por isso, utilizaremos o NIST como base para explicar os conceitos mais básicos da
computação em nuvem.
Segundo Coutinho (2013, p. 216):
“A Computação em Nuvem propõe a integração de diversos modelos tecnológicos
para o provimento de infraestrutura de hardware, plataformas de desenvolvimento e
aplicações na forma de serviços sob demanda com pagamento baseado em uso [Sá et
al. 2011]. Neste novo paradigma de utilização de recursos computacionais, clientes
abrem mão da administração de uma infraestrutura própria e dispõem de serviços
oferecidos por terceiros, delegando responsabilidades e assumindo custos
estritamente proporcionais à quantidade de recursos que utilizam.”
A título de melhor entendimento, os modelos tecnológicos aos quais Coutinho
(2013) se refere podem ser ligados com os modelos de serviços citados pelo NIST.
Infraestrutura de Hardware seria o IaaS, Plataformas de Desenvolvimento seriam o PaaS e as
19
Aplicações seriam o SaaS. Esses três modelos de serviços serão explicados no texto sobre
“Modelos de Serviço”.
Para explicar em definitivo os principais conceitos da nuvem, será seguido a mesma
estrutura proposta pelo NIST (MELL, 2011) que é dividida em três partes:
2.1.1

Características essenciais da Computação em Nuvem;

Modelos de serviços;

Modelos de deployment.
Características essenciais da Computação em Nuvem:
Autosserviço sob demanda: Um cliente de um serviço de computação em nuvem
pode requisitar recursos computacionais em tempo real sem precisar interagir com o provedor
de serviço. (MELL, 2011, p. 2)
Amplo acesso à rede: Os recursos computacionais estão disponíveis através da
rede e são acessados através de mecanismos padrão que possibilitam o acesso através de
diversos tipos de dispositivos, como smartphones, tablets e computadores pessoais. (MELL,
2011, p. 2)
Pool de recursos: Os recursos de computação do provedor são agrupados para
atender vários clientes através de um modelo multi-tenant 5, com diferentes recursos físicos e
virtuais atribuídos e realocados dinamicamente de acordo com a demanda do cliente. A
localização dos recursos é transparente para o usuário, normalmente se restringindo ao país,
estado ou datacenter6. Exemplos de recursos incluem armazenamento, processamento,
memória e largura de banda da rede. (MELL, 2011, p. 2)
5
6
Multi-tenant é uma aplicação do lado servidor que suporta diversos clientes em uma única instância da
aplicação. (REESE, 2011, p. 3)
Datacenter (centro de dados) é o departamento em uma empresa que abriga e mantém a infraestrutura dos
sistemas de tecnologia da informação e armazenamento de dados (seus mainframes, servidores e bancos de
dados). Este departamento e todos os sistemas residem em um lugar físico, portanto, o nome Datacenter.
(Fonte: <http://www.gartner.com/it-glossary/data-center/ >, Acesso em: 20 jan. 2014)
20
Elasticidade rápida: Os recursos computacionais podem ser elasticamente usados
e liberados, algumas vezes até de maneira automática, para aumentar ou diminuir os recursos
computacionais de acordo com a demanda. Para o cliente, os recursos computacionais
parecem ilimitados e podem ser apropriados para qualquer quantidade a qualquer tempo.
(MELL, 2011, p. 2)
Serviço mensurado: Os sistemas Cloud automaticamente controlam e otimizam o
uso dos recursos, medindo, de maneira abstrata para o usuário, todos os tipos de serviço como
armazenamento, processamento, largura de banda e contas de usuários ativos. (MELL, 2011,
p. 2)
2.1.2
Modelos de serviços:
IaaS:
É
a
capacidade
fornecida
ao
consumidor
para
processamento,
armazenamento, redes e outros recursos de computação fundamentais onde o consumidor é
capaz de implementar e executar software arbitrário, que pode incluir sistemas operacionais e
aplicativos. O consumidor não gerencia nem controla a infraestrutura de nuvem subjacente,
mas tem controle sobre sistemas operacionais, armazenamento e aplicativos implementados e
possivelmente controle limitado de componentes de rede (por exemplo, firewalls do host).
(MELL, 2011, p. 3)
PaaS: É a capacidade fornecida ao consumidor para implantar suas aplicações
consumindo a infraestrutura de nuvem criada usando linguagens de programação, bibliotecas,
serviços e ferramentas suportadas pelo provedor. O consumidor não gerencia nem controla a
infraestrutura de nuvem subjacente, incluindo rede, servidores, sistemas operacionais ou
armazenamento, mas tem controle sobre os aplicativos implementados e possivelmente
definições de configuração para o ambiente de hospedagem de aplicativos. (MELL, 2011, p.
2)
21
SaaS: É a capacidade fornecida ao consumidor de utilização de aplicativos
rodando em uma infraestrutura de nuvem. As aplicações são acessíveis a partir de vários
dispositivos clientes, quer através de uma interface de cliente, como um navegador web (por
exemplo, e-mail baseado na web), ou uma interface desktop nativa. O consumidor não
gerencia nem controla a infraestrutura de nuvem subjacente, incluindo rede, servidores,
sistemas operacionais, armazenamento, ou mesmo capacidades de aplicativos individuais,
com a possível exceção de configurações limitadas de configuração de aplicativos específicos
do usuário. (MELL, 2011, p. 2)
2.1.3
Modelos de deployment:
Nuvem privada: a infraestrutura de nuvem privada é provisionada para uso
exclusivo para uma única organização, sendo que essa organização pode agrupar vários
consumidores. A infraestrutura pode, ou não, ser de propriedade da própria organização, além
de ser gerenciada e operada pela mesma, um terceiro, ou alguma combinação deles, e pode
existir dentro ou fora das instalações da organização. (MELL, 2011, p. 3)
Nuvem comunitária: a infraestrutura de nuvem comunitária é provisionada para
uso exclusivo por uma comunidade específica de organizações que possuem objetivos
similares. A infraestrutura pode, ou não, ser de propriedade de uma ou mais organizações,
além de ser gerenciada e operada por uma ou mais organizações na comunidade, um terceiro,
ou uma combinação deles, além de poder existir dentro ou fora das instalações das
organizações responsáveis. (MELL, 2011, p. 3)
Nuvem pública: a infraestrutura de nuvem pública é provisionada para uso aberto
ao público em geral. A infraestrutura pode, ou não, ser de propriedade, gerenciada e operada
por uma empresa, centro acadêmico ou organização governamental, ou alguma combinação
das mesmas. Ela existe nas instalações do provedor de nuvem. (MELL, 2011, p. 3)
22
Nuvem híbrida: a infraestrutura de nuvem híbrida é uma composição de duas ou
mais infraestruturas de nuvem distintas (privada, comunitária, ou pública) que permanecem
entidades únicas, mas são unidas por tecnologia padronizada ou proprietária que permitem
portabilidade de dados e aplicações. (MELL, 2011, p. 3)
2.2
2.2.1
AMAZON WEB SERVICES
Introdução a AWS
A Amazon começou como uma loja online, no final de 1990. Logo de início, seu
faturamento cresceu exponencialmente, batendo 1.6 bilhões de dólares em 1999. Mesmo
assim, seu volume de vendas era apenas 0.5% do Walmart, forçando a Amazon a expandir
seus negócios. (VLIET, 2011, p. 1)
Após esse crescimento exponencial, a Amazon estava sofrendo com o
gerenciamento da sua infraestrutura. Era um sistema monolítico, difícil de escalar. (VLIET,
2011, p. 1)
O primeiro passo da Amazon para melhorar sua infraestrutura foi criar uma API
para acessar os recursos do site atual. Era dado os primeiros passos para a criação da AWS.
(VLIET, 2011, p. 1)
Apesar de existir uma API para desenvolvedores terceiros acessarem recursos da
loja online da Amazon, a mesma ainda sofria com os problemas da sua infraestrutura. O
problema foi resolvido em 2004, quando a Amazon deixou de ser apenas uma loja online com
uma API para acesso de terceiros aos seus recursos e tornou-se, também, uma completa
infraestrutura de nuvem. (VLIET, 2011, p. 1)
Em 2006 a Amazon começou a oferecer acesso à sua infraestrutura através de
serviços web, o que caracteriza o modelo de serviço de infraestrutura como serviço da
computação em nuvem. (AMAZON WEB SERVICES, 1, 2013)
A partir desse novo direcionamento nos negócios, a Amazon não só resolveu seu
problema com infraestrutura, como foi pioneira em um novo modelo de negócios. (VLIET,
2011, p. 1)
23
2.2.2
Serviços AWS
Segundo Veras (2013, p. 17) a estrutura de serviços da AWS é dividida em três
grandes partes:
Infraestrutura global de suporte para a plataforma. Aqui se incluem as regiões, zonas
de disponibilidade, localizações de conteúdo e DNS. (VERAS, 2013, p. 17)
Segundo Veras (2013, p. 17, 18):
“Serviços de infraestrutura que são os serviços de processamento,
armazenamento, rede, banco de dados e gerenciamento. Serviços de infraestrutura
de TI, mas com outro nível de abstração, acesso baseado em web services e
fornecidos sob demanda. No modelo AWS pode-se contratar estes serviços de
acordo com a necessidade. Um servidor virtual, uma instância virtual, por exemplo,
pode ser contratado com diferentes níveis de processamento e diferentes tipos de
armazenamento local. Os serviços de armazenamento na AWS podem ser utilizados
mediante a necessidade, sem precisar antecipar a capacidade.”
Serviços básicos de plataforma que estão no limite do serviço IaaS e acabam por
completar a oferta de serviços incluindo mensageria, workflow e gerenciamento dos
aplicativos. (VERAS, 2013, p. 17)
Figura 2: Console de gerenciamento dos serviços disponibilizados pela AWS
Fonte: https://console.aws.amazon.com/console/home, acesso em 13 jan. 2014
Atualmente a AWS conta com os seguintes serviços (AMAZON WEB
SERVICES, 2, 2014):

Computação
◦ Amazon Elastic Compute Cloud (EC2): Oferece capacidade computacional em
nuvem, escalável e paga conforme o uso.
24
◦ Elastic Load Balancing: Distribui automaticamente o tráfego de entrada dos
aplicativos em várias instâncias do Amazon EC2.
◦ Auto Scaling: Permite expandir ou reduzir a capacidade do Amazon EC2
automaticamente, de acordo com condições pré-definidas.
◦ Amazon WorkSpaces: É um serviço computacional de desktop totalmente
gerenciado na nuvem.

Analytcs
◦ Amazon Elastic MapReduce: É um serviço web que permite que empresas,
pesquisadores, analista de dados e desenvolvedores processem grandes
quantidades de dados com facilidade e economia.
◦ AWS Data Pipeline: É um serviço que ajuda a processar e mover dados entre
diferentes serviços de armazenamento e computação da AWS, além de fontes de
dados locais, com segurança e em intervalos especificados.
◦ Amazon Kinesis: É um serviço gerenciado para processamento em tempo real para
streaming7 de dados em alta escala.

Implementação e gerenciamento
◦ AWS Identity and Access Management (IAM): Permite que você controle com
segurança o acesso aos serviços e recursos da AWS para seus usuários. A IAM
permite que você crie e gerencie usuários na AWS, e também possibilita a
concessão de acesso a recursos da AWS para usuários gerenciados fora da AWS
no seu diretório corporativo.
◦ AWS Elastic Beanstalk: É uma maneira ainda mais fácil de implementar e
gerenciar aplicativos na nuvem da AWS. Para gerenciar uma aplicação online, é
necessário fazer o upload da mesma e o Elastic Beanstalk automaticamente
gerencia os detalhes de implantação, fornecimento de capacidade, balanceamento
de carga, escalonamento automático e monitoramento do status do aplicativo.
◦ AWS CloudWatch: É um serviço web que fornece monitoramento para recursos da
nuvem da AWS, começando com o Amazon EC2.
◦ AWS CloudTrail: É um serviço da web que registra chamadas de API da AWS de
uma conta específica e entrega arquivos de registro para o usuário dessa mesma
conta.
7
Streaming é a técnica que suporta a, transmissão contínua de áudio e / ou vídeo através da Internet e, mais
recentemente, através de uma rede móvel. (Fonte: <http://www.gartner.com/it-glossary/streaming/>, Acesso
em: 12 jan. 2014)
25
◦ Amazon CloudFormation: é um serviço que fornece aos desenvolvedores e
empresas uma forma rápida de criar um conjunto de recursos relacionados da
AWS e os oferece de maneira organizada e previsível.
◦ AWS OpsWorks: É uma plataforma de operações de desenvolvimento para o
gerenciamento de qualquer escala ou complexidade na nuvem da AWS.
◦ AWS CloudHSM: É um serviço que ajuda a atender requisitos de conformidade
corporativos, contratuais e normativos para a segurança de dados utilizando
dispositivos Hardware Security Module (HSM – Módulo de segurança de
hardware) dedicados dentro da nuvem da AWS. Com o AWS CloudHSM, o
usuário que gerencia a conta AWS que mantém toda a propriedade, o controle e o
acesso a chaves e dados confidenciais, enquanto a Amazon gerencia os
dispositivos HSM localizados perto dos seus aplicativos e dados para obter o
desempenho máximo.

Serviços de aplicativos
◦ Amazon AppStream: É um serviço flexível, de baixa latência, que permite o
streaming de aplicativos com uso intenso de recursos e jogos na nuvem.
◦ Amazon CloudSearch: É um serviço de pesquisa totalmente gerenciado na nuvem
que permite aos clientes integrar facilmente funcionalidades de pesquisa altamente
escaláveis e rápidas a seus aplicativos
◦ Amazon Simple Workflow Service (Amazon SWF): Ajuda a coordenar as etapas
do processo nos seus aplicativos e a gerenciar estados de execução distribuída.
◦ Amazon Simple Queue Service (Amazon SQS): Fornece uma fila hospedada para
armazenar mensagens à medida que elas são transferidas entre computadores,
facilitando a criação de um fluxo de trabalho automatizado entre os serviços web.
◦ Amazon Simple Notification Service (Amazon SNS): É um serviço web que
facilita a configuração, a operação e o envio de notificações com base na nuvem.
◦ Amazon Simple Email Service (Amazon SES): É um serviço de envio de e-mails
em massa e transacional altamente escalável e econômico para a nuvem.
◦ Amazon Elastic Transcoder: É um serviço totalmente gerenciado que facilita a
conversão de arquivos de mídia na nuvem, com escalabilidade e economia.

Pagamentos e faturamento
◦ Amazon Flexible Payments Service (FPS): Facilita a transferência digital
monetária entre duas entidades, pessoas ou computadores quaisquer.
26
◦ Amazon DevPay: É um serviço de faturamento e de gerenciamento de contas que
permite que os desenvolvedores cobrem o pagamento pelos seus aplicativos da
AWS.

Software
◦ AWS Marketplace: É uma loja on-line que ajuda os clientes a encontrar, comprar e
começar a usar imediatamente software executado na nuvem da AWS. Ele inclui
software de fornecedores confiáveis, como SAP8, Zend9, Microsoft10, IBM11,
Canonical12 e 10gen13, bem como muitas ofertas de software livre amplamente
usadas, como Wordpress14, Drupal15 e MediaWiki16.

Redes
◦ Amazon Route 53: É um serviço web de Domain Name System 17 (DNS) altamente
disponível e escalável.
◦ AWS Direct Connect: Facilita o estabelecimento de uma conexão de rede dedicada
do seu local para a AWS, o que normalmente reduz os custos da rede, aumenta a
taxa de transferência da largura de banda e fornece uma experiência de rede mais
consistente que as conexões baseadas em Internet.
◦ Amazon Virtual Private Cloud (VPC): Permite aproveitar uma seção privada e
isolada na nuvem da AWS onde é possível executar recursos em uma rede virtual
própria. Lembra muito uma rede tradicional que você poderá operar no seu próprio
Datacenter.

Entrega de conteúdo
◦ Amazon CloudFront: É um serviço web que facilita a distribuição de conteúdo
com baixa latência por meio de uma rede global de pontos de presença.
8
9
10
11
12
13
14
15
16
17
http://www.sap.com/index.html
http://www.zend.com/en/
http://www.microsoft.com/pt-br/default.aspx
http://www.ibm.com/us/en/
http://www.canonical.com/
http://www.mongodb.com/
http://wordpress.com/
https://drupal.org/
http://www.mediawiki.org/wiki/MediaWiki
DNS é a abreviação de Domain Name System, um sistema para nomear computadores e serviços de rede que
é organizado em uma hierarquia de domínios. O Servidor DNS é usado em redes como a Internet, para
localizar computadores e serviços através de nomes amigáveis. Quando um usuário insere um nome DNS em
um aplicativo, serviços de DNS podem traduzir o nome para outras informações associadas com o nome,
como um endereço IP. (Fonte: <http://technet.microsoft.com/en-us/library/cc787920(v=ws.10).aspx>,
Acesso em: 14 jan. 2014)
27

Banco de dados
◦ Amazon Relational Database Service (Amazon RDS): É um serviço web que
facilita a configuração, a operação e a escalabilidade de um banco de dados
relacional na nuvem.
◦ Amazon DynamoDB: É um serviço de banco de dados NoSQL de alto
desempenho que é fácil de configurar, operar e escalar.
◦ Amazon Redshift: É um serviço de armazenamento de dados rápido, potente e
totalmente gerenciável para fazer data warehouse em larga escala (petabytes) na
nuvem. Oferece consultas rápidas para analisar virtualmente qualquer tamanho de
dados utilizando o mesmo estilo de uma ferramenta de SQL comum.
◦ Amazon ElastiCache: É um serviço web que torna fácil implementar, operar e
escalar um cache em memória na nuvem.
◦ Amazon SimpleDB: É um serviço de armazenamento de dados não relacional,
altamente disponível e flexível.

Storage
◦ Amazon Simple Storage Service (Amazon S3): Fornece uma infraestrutura de
armazenamento de dados totalmente redundante para armazenar e recuperar
qualquer quantidade de dados, a qualquer momento, de qualquer local na web.
◦ Amazon Glacier: É um serviço de armazenamento de custo extremamente baixo,
que fornece armazenamento seguro e durável para backup e arquivamento de
dados.
◦ AWS Storage Gateway: É um serviço que conecta um dispositivo de software
local ao armazenamento baseado na nuvem para fornecer a integração perfeita e
segura entre o ambiente de TI local de uma organização e a infraestrutura de
armazenamento da AWS.
◦ Amazon Elastic Block Store (Amazon EBS): Fornece volumes de armazenamento
em bloco para uso com instâncias do Amazon EC2. Os volumes Amazon EBS são
armazenamentos independentes da instância EC2.
◦ AWS Import/Export: Acelera a movimentação de grandes volumes de dados para
dentro e para fora da AWS usando dispositivos de armazenamento portáteis para
transporte.

Suporte
28
◦ AWS Support: É um canal de suporte de resposta rápida e individualizada para
ajudar na criação e na execução de aplicativos nos serviços de infraestrutura da
AWS.

Tráfego da Web
◦ Alexa Web Information Service: Disponibiliza para os desenvolvedores o enorme
repositório de dados do Alexa18 com relação aos padrões de tráfego e de estrutura
na Web.
◦ Alexa Top Sites: Expõe dados de tráfego de sites globais à medida que eles são
continuamente coletados e atualizados pelo Alexa Traffic Rank.

Força de trabalho
◦ Amazon Mechanical Turk: Permite que as empresas tenham acesso a milhares de
trabalhadores globais sob demanda e integrem, de forma programática, seu
trabalho em vários processos de negócios.
2.2.3
Infraestrutura
Segundo Veras (2013, p. 36), “a infraestrutura da AWS é baseada nos conceitos
de zonas de disponibilidade e de região. As zonas de disponibilidade refletem os datacenters
da AWS, e as regiões consistem de uma ou mais zonas de disponibilidade que são separadas
em áreas geográficas ou países.”
Existem também os pontos de presença, onde a AWS permite o armazenamento
de conteúdos estáticos dos clientes. Esses conteúdos estáticos podem ser os componentes mais
acessados do website do cliente, podem ser para distribuição de software, publicação de
arquivos de mídia popular e até mesmo para distribuições por streaming. (VERAS, 2013, p.
36, 52 e 53)
Devido a sua infraestrutura estar localizada em países, e até continentes, distintos,
a AWS pode ser considerada um serviço global de IaaS. (VERAS, 2013, p. 37)
18
Alexa é o principal fornecedor de métricas web globais e livres. (Fonte: <http://www.alexa.com/>, Acesso
em: 12 jan. 2014).
29
2.2.4
Regiões
As regiões da AWS são conjuntos isolados de datacenters em uma determinada
geografia. (VERAS, 2013, p. 39)
No momento do desenvolvimento deste trabalho, a AWS conta com oito regiões,
conforme a Figura 3.
Figura 3: Screenshot da área de
seleção de região do console da
AWS, mostrando as atuais opções
de regiões.
Fonte: <https://console.aws.amazon.com/console/home>. Acesso em: 21 dez. 2013
Segundo Veras (2013, p. 39), “quando se utiliza a AWS, pode-se definir onde os
dados devem ficar armazenados, onde devem rodar as instâncias, onde as filas de mensagens
são inicializadas e os bancos de dados devem ser instanciados.”
2.2.5
Zonas de Disponibilidade
Segundo o próprio site da AWS, (AMAZON WEB SERVICES, 3, 2014):
“As Zonas de disponibilidade são as posições distintas que são projetadas para
serem isoladas das falhas em outras Zonas da disponibilidade e fornecem rede de
conectividade acessível e de baixa latência para outras Zonas de disponibilidade da
mesma região.”
30
Veras (2013, p. 41, 42 e 43) explicou bem através de figuras como funciona a
interação entre as regiões e as zonas de disponibilidade. Na figura 4 é possível visualizar
como as zonas de disponibilidades dentro de uma determinada região (no caso da figura, a
região US East, Virginia) possuem uma rede de alto desempenho e baixa latência. As zonas
de disponibilidade (abreviadas para “AZ”, na figura 4), a título de exemplificação, foram
nomeadas de “AZA”, “AZB”, “AZC” e “AZD”.
Figura 4: Zonas de disponibilidades (VERAS, 2013, p. 41)
Através da figura 5, é possível verificar que cada zona de disponibilidade possui
seu próprio datacenter, com infraestrutura independente.
31
Figura 5: Detalhe da zona de disponibilidade (VERAS, 2013, p. 43)
Na figura 6 é possível vislumbrar a interação entre as diversas regiões da AWS e
suas zonas de disponibilidade.
Figura 6: Regiões e zonas de disponibilidade (VERAS, 2013, p. 43)
32
2.2.6
REST e SOAP
Como se pode constatar ao longo deste trabalho, muitas das APIs para acesso aos
serviços da AWS são acessadas através de REST e SOAP (VERAS, 2013). Abaixo será feita
uma rápida revisão bibliográfica sobre a arquitetura SOA e suas implementações (REST e
SOAP).
2.2.6.1 Arquitetura SOA
Service Oriented Architecture é uma arquitetura de referência que é baseada em
serviços. Se a arquitetura é definida pela perspectiva de serviços, a mesma é chamada de
“orientada a serviços” ou SOA. (DIKMANS, 2012, p. 46)
A arquitetura orientada a serviços é centrada em torno de serviços. Os serviços
são pequenos blocos de construção que oferecem acesso claro para um conjunto limitado de
recursos. O mesmo serviço é responsável pela lógica de negócios e consistência dos dados de
um determinado conjunto de capacidades. Se os dados que pertencem a um serviço precisam
ser alterados, isso é feito exclusivamente através desse serviço, reforçando, assim, um único
ponto de acesso para essa funcionalidade e/ou dados particulares. A arquitetura orientada a
serviços promove isso, dados e lógica que não pertencem um ao outro são dissociados (ou
fracamente acoplado), através do conjunto de serviços. Este fraco acoplamento ocorre em
nível de propriedade, lógica de negócios, dados e implantação. (DIKMANS, 2012, p. 47)
2.2.6.1.1 SOAP
Web services baseados em SOAP são serviços formalmente descritos, criados e
consumidos baseados em uma série de padrões web services e protocolos. Juntos, esses
padrões são denotados como “WS-*” e são mantidos por comitês de padronização como a
33
World Wide Web Consortion (W3C) e OASIS. Alguns exemplos de padrões web service são
“WS-Security”, “Web Service Description Language” (WSDL), “WS-RM” (Reliable
Messaging) e “Simple Object Access Protocol” (SOAP). (BAKKER, 2013, p. 116)
Serviços baseados em SOAP possuem interfaces que mostram as operações
disponíveis, as entradas e saídas dessas operações e a tecnologia de ligação por meio do qual
as operações são disponibilizados. Essas interfaces são documentadas utilizando documentos
WSDL e XSD. Uma WSDL define as operações de um serviço e pode definir as mensagens
de entrada e saída ou referenciar um arquivo XSD externo para isso. (BAKKER, 2013, p.
116)
É uma boa prática definir as operações em um WSDL, referenciar um XSD
externo que define as mensagens de solicitação e resposta, e referem-se a partir daí a outros
XSDs que definem as entidades de negócio, como cliente, e entidades de ordem que fazem
parte das mensagens de solicitação e resposta. (BAKKER, 2013, p. 116)
2.2.6.1.2 REST
REST,
ou
Representational
State
Transfer
(Transferência
de
Estado
Representativo) é um estilo arquitetural para construção de aplicações web que descreve um
conjunto de princípios utilizando os padrões Web, como o protocolo HTTP e um Identificador
Uniforme de Recursos (URI, Uniform Resource Identifier), de uma maneira natural. O estilo
de arquitetura REST encaixou-se muito bem com as aplicações em nuvem, porque permite a
interação com clientes diversos como telefones móveis, browsers e outros websites com o
mínimo de processamento. (BAKKER, 2013, p. 114)
Serviços Representational State Transfer (REST) são baseados em um modelo
muito diferente do que os serviços baseados em SOAP. REST é um modelo formal baseado
em recursos. A ideia é que se envia uma solicitação para um recurso. O recurso que é
retornado mostra as opções para a próxima etapa. Por exemplo, pode-se requisitar uma lista
de clientes. A lista resultante irá mostrar-lhe a localização dos dados individuais de cada
cliente, por exemplo, em uma URL. Este modelo é muito flexível e não requer que o cliente
34
saiba de antemão quais os serviços e chamadas de serviço estão disponíveis. A World Wide
Web é um exemplo de uma implementação de arquitetura REST. Serviços RESTful
dependem do protocolo HTTP em que métodos HTTP, como GET, PUT, POST e DELETE
são usados para representar operações do tipo CRUD (Create, Read , Update, Delete). As
mensagens são trocadas usando XML. (DIKMANS, 2012, p. 117)
A linha a seguir mostra como os mesmos detalhes dos clientes que foram
recuperados usando SOAP podem ser recuperadas usando REST (DIKMANS, 2012, p. 117).
Basicamente, um serviço RESTful é invocado usando uma URL, por exemplo:
http://www.foo.org/resource/customer/56080086
Em ambos os exemplos de clientes, o servidor que hospeda o serviço que retorna
a lista de clientes receberá o pedido, processar o pedido e retornar uma resposta contendo os
dados do cliente. Embora os serviços baseados em SOAP sempre utilizam XML, os serviços
RESTful não impõem restrições sobre o formato dos dados trocados. Os dados podem ser
formatados como HTML, XML ou JavaScript Object Notation (JSON), e assim por diante.
(DIKMANS, 2012, p. 117)
Segundo Veras (2013, p. 11):
“A API REST é uma interface HTTP. Para usar a API REST pode-se utilizar
qualquer kit de ferramentas que ofereça suporte a HTTP. Pode-ser usar um
navegador para buscar objetos, contanto que eles sejam anonimamente legíveis.
Deve-se utilizar a API REST para os cabeçalhos HTTP padrão e códigos de status,
para que os toolkits e navegadores funcionem conforme o esperado.”
2.2.7
Elasticidade
Segundo Coutinho (2013, p. 216 e 217):
“A elasticidade é ponto chave para implementar serviços com qualidade de serviço
para nuvem, pois permite adicionar ou remover recursos, sem interrupções e em
tempo de execução para lidar com a variação da carga. De acordo com
(COUTINHO, 2013 apud Mell and Grance 2009), estes recursos podem ser
adquiridos de forma rápida, em alguns casos automaticamente, caso haja a
necessidade de escalar com o aumento da demanda, e liberados, na retração dessa
35
demanda. Para os usuários, os recursos disponíveis para uso parecem ser ilimitados e
podem ser adquiridos em qualquer quantidade e a qualquer momento.”
2.2.8
Balanceamento de Carga
Se o sistema for escalado verticalmente (elasticidade vertical), não precisa se
preocupar muito com as requisições dos usuários. As requisições chegam ao nosso servidor
monolítico, são atendidas, e uma resposta é enviada de volta para o usuário. Dividir a carga
entre os vários processadores é um trabalho do sistema operacional. Como a maioria dos
softwares servidores de aplicação web suportam multi-processadores, podemos manter uma
instância em cada processador e executar muitos pedidos em paralelo. (HENDERSON, 2006,
p. 214)
Quando o servidor começa a escalar horizontalmente (elasticidade horizontal), um
novo problema aparece. Existem vários processadores, provenientes de diversos
computadores, mas não existe nenhum sistema operacional para espalhar pedidos entre eles.
Diversas solicitações entram para o mesmo IP, que deveria dividir o processamento entre
várias máquinas. A solução pode vir de uma série de métodos, mas todos eles são agrupados
sob o termo “balanceamento de carga”. (HENDERSON, 2006, p. 214)
2.2.9
Multitenancy
Singletenancy é quando uma aplicação suporta apenas um cliente. Se um novo
cliente resolver ter acesso a essa mesma aplicação, ele precisa instalar essa aplicação em uma
nova infraestrutura, totalmente independente da primeira, para que as informações dos dois
clientes não se misturem. Multitenancy é um conceito que é o oposto do Singletenancy. No
jargão da computação em nuvem, um cliente ou uma organização é referido como tenant
(inquilino). As várias desvantagens e ineficiências de custo de modelos single-tenant são
superadas pelo modelo multi-tenant. A aplicação multi-tenant atende a várias organizações,
cada uma trabalhando em seu próprio ambiente virtual isolado e compartilham uma única
36
instância física e versão do aplicativo hospedado na infraestrutura da nuvem. É isolado
porque, embora a infraestrutura seja compartilhada, os dados de cada cliente, customizações e
código permanecem seguros e isolados de outros clientes. (ARORA, 2013, p. 32)
Aplicações multi-tenant executam em uma única instância física e possuem a
mesma versão da aplicação, fornecendo a mesma infraestrutura robusta para todos os seus
clientes. Isso também significa liberdade de custos iniciais, de atualizações contínuas, e de
custos de manutenção. (ARORA, 2013, p. 33)
Segundo Chate (2010, p. 4), Multi-tenancy é a chave determinante para eficiência
de uma aplicação SaaS. Normalmente, um aplicativo suporta múltiplos usuários, mas com a
presunção de que todos os usuários são de uma mesma organização. Esse modelo é bom para
as aplicações tradicionais, não-SaaS, no qual uma organização compraria um aplicativo para
uso dos seus funcionários. Mas no mundo do SaaS e na nuvem, muitas organizações usarão o
mesmo aplicativo, todas essas organizações devem ser capazes de permitir o acesso de todos
seus usuários, mas a aplicação deve permitir que os funcionários de cada organização possam
acessar os dados somente da sua organização, e não de qualquer outra. Esta capacidade de ter
várias organizações (chamadas de tenant na nomenclatura SaaS), coexistindo na mesma
aplicação, sem comprometer a segurança dos dados para as organizações, define o aplicativo
como multi-tenant. Existem vários níveis de multi-tenant:
1. Virtualização simples na nuvem, onde apenas o hardware é compartilhado.
2. Aplicação única com bancos de dados separados por inquilino.
3. Aplicação única e banco de dados compartilhado (maior eficiência, verdadeiro multitenancy).
Figura 7: Níveis de Multitenancy (CHATE, 2010, p. 5)
37
2.2.10 Serviços assíncronos
Quando se fragmenta uma aplicação em serviços, é normal que alguns deles
demorem mais para responder do que outros. Quando um usuário realiza uma requisição,
alguns dos serviços que são acessados por aquela requisição podem demorar alguns segundos
para responder. Isso é definido como uma má experiência para o usuário, já que o mesmo não
sabe quais serviços estão sendo chamados e porque demoram. Isso pode levá-lo a pensar que
o sistema caiu ou a infraestrutura está saturada. (HENDERSON, 2006)
A solução é mover esses serviços para um modelo assíncrono. Assim, otimiza-se a
fase de requisição (request) para responder imediatamente e guardar a requisição. A fase de
resposta (response), se for preciso uma, pode vir depois, fora da solicitação da página.
Quando se fala de serviços assíncronos, normalmente, significa requisições síncronas e
respostas assíncronas. (HENDERSON, 2006)
Como regra, usa-se a comunicação assíncrona sempre que possível. Essa prática
não é apenas para criar alguns serviços que se comunicam de maneira assíncrona, mas sim
desenvolver o aplicativo para possuir um comportamento assíncrono. Isto significa, em
grande parte, o afastamento de protocolos de request/response, ou, pelo menos, aqueles com
restrições temporais sobre as respostas (responses). (ABBOTT, 2011)
Utiliza-se serviços assíncronos para garantir que cada serviço e camada seja o
máximo independente possível. Isso permite que o sistema seja muito mais escalável do que
se todos os componentes forem fortemente acoplados. (ABBOTT, 2011)
2.2.11 EC2
O Amazon EC2 é um web service que provê um processamento computacional na
nuvem, totalmente redimensionável e o cliente paga apenas pelo seu uso. (AMAZON WEB
38
SERVICES, 5, 2014) Através do console de gerenciamento do EC2, o cliente pode selecionar
o sistema operacional que deseja utilizar e instalar todos os recursos de que necessita. Para
isso, o cliente cria uma instância EC2 através do console, dizendo quais os recursos de que
precisa, como quantidade de memória, quantidade de processadores, entre outros, podendo
alterar esses recursos posteriormente. Além dessa elasticidade vertical, onde você aumenta os
recursos da máquina que está rodando os serviços, você pode ter uma elasticidade horizontal,
adicionando mais máquinas e distribuindo o processamento entre elas através do
Balanceamento de Carga. (VERAS, 2013, p. 119 e 120)
Para permitir a economia utilizando as instâncias do EC2, você optar entre três
modalidades de uso:
Instâncias On-Demand:
“As instâncias On-Demand permitem que você pague pela capacidade
computacional por hora, sem compromissos a longo prazo. Isso exime você dos
custos e das complexidades de planejamento, aquisição e manutenção de hardware e
transforma o que normalmente são grandes custos fixos em custos variáveis muito
menores. As Instâncias On-Demand também eliminam a necessidade de se comprar
uma “rede de segurança” com capacidade de lidar com repiques de tráfego
periódicos.” (AMAZON WEB SERVICES, 5, 2014)
Instâncias reservadas:
“As Instâncias reservadas lhe dão a opção de fazer um pagamento único e acessível
para cada instância que você deseja reservar e, por sua vez, você recebe um desconto
significativo sobre a taxa por hora para essa instância. Existem três tipos de instância
reservada (utilização leve, média e pesada) que permitem equilibrar o valor inicial
pago e o preço efetivo da hora. Se suas necessidades mudarem, você pode solicitar
mover sua instância reservada para outra Zona de disponibilidade dentro da mesma
região, pode mudar sua plataforma de rede ou, para RIs Linux/UNIX e Windows,
pode modificar o tipo de instância de sua reserva para outro tipo na mesma família
de instâncias sem custo adicional. Você também pode vender suas instâncias
reservadas para outros clientes através do Reserved Instance Marketplace se tiver
uma conta nos Estados Unidos.” (AMAZON WEB SERVICES, 5, 2014)
Instância Spot:
“As Instâncias Spot permitem aos clientes negociarem a capacidade não utilizada do
Amazon EC2 e executarem essas instâncias durante o período em que sua oferta
exceder o Preço Spot atual. O Preço Spot muda periodicamente com base no
fornecimento e na demanda, e os clientes cuja proposta atende-o ou ultrapassa-o
ganham acesso às Instâncias Spot disponíveis. Se você tem flexibilidade sobre
quando os seus aplicativos podem ser executados, as Instâncias Spot podem reduzir
significativamente seus custos no Amazon EC2.” (AMAZON WEB SERVICES, 5,
2014)
39
2.2.12 S3
Amazon Simple Storage Service (S3) é um armazenamento persistente baseado
em nuvem. Ele opera independentemente de outros serviços da Amazon. As aplicações que
você escreve para hospedar em seu próprio servidor podem utilizar o serviço da Amazon S3,
sem necessidade estar na nuvem. (REESE, 2009, p. 25)
Segundo a própria AWS (AMAZON WEB SERVICES, 4, 2014), “o Amazon S3
fornece uma interface simples de serviço web que pode ser usada para armazenar e recuperar
qualquer quantidade de dados, a qualquer momento, de qualquer lugar na web.”
Veras (2013, p. 164) diz que:
“O S3 fornece uma interface web service que pode ser usada para armazenar e
recuperar qualquer quantidade de dados, a qualquer momento, de qualquer lugar na
web. Pode-se gravar, ler e deletar objetos contendo de um byte até cinco terabytes de
dados cada, e o número de objetos que você pode armazenar em um bucket19 do S3 é
ilimitado. O S3 também é altamente escalável, permitindo o acesso simultâneo à
leitura e à gravação dos dados por diferentes clientes ou threads de aplicativo.”
Para acessar as APIs fornecidas pelo S3, o cliente pode utilizar qualquer
linguagem de programação, já que o acesso é feito via SOAP ou REST. (VERAS, 2013, p.
164)
As funcionalidades do S3, segundo o site da AWS (AMAZON WEB SERVICES,
4, 2014), são as seguintes:

Grave, leia e exclua objetos que contenham entre 1 byte e 5 terabytes de dados cada
um. O número de objetos que você pode armazenar é ilimitado.

Cada objeto é armazenado em um bucket e é recuperado através de uma chave
específica que é atribuída a um desenvolvedor.

Um bucket pode ser armazenado em uma das diversas regiões. Escolha a região em
que deseja otimizar a latência, minimizar custos ou atender aos requisitos regulatórios.

Os objetos armazenados em uma região nunca saem dela, exceto se você desejar
transferi-los. Os objetos armazenados na região da UE (Irlanda), por exemplo, nunca
saem da UE.
19
“Buckets são containers para objetos S3. Cada objeto armazenado no S3 está contido em um bucket, e ele
funciona como um diretório em um sistema de arquivos. Uma das principais distinções entre uma pasta de
arquivos e um bucket é que cada bucket e seu conteúdo podem ser acessados usando uma URL”. (VERAS,
2013, p. 167)
40

Os mecanismos de autenticação são fornecidos para garantir que os dados
permaneçam livres de acesso não autorizado. Os objetos podem ser públicos ou
privados, e direitos podem ser atribuídos a usuários específicos.

Existem opções para upload/download seguro de dados e criptografia de dados para
proteção adicional dos dados.

Utilize interfaces REST e SOAP com base padrão projetadas para trabalhar com
qualquer ferramenta de desenvolvimento de Internet.

Projetado para ser flexível para que camadas funcionais ou de protocolo possam ser
facilmente adicionadas. O protocolo padrão de download é HTTP.

Fornece funcionalidade para simplificar a capacidade de gerenciamento de dados
durante sua vida útil. Inclui opções para separação de dados por buckets,
monitoramento e controle de despesas e arquivamento automático de dados para
opções de armazenamento de custo ainda mais baixo.
2.2.13 CloudFront
O Amazon CloudFront é feito para funcionar com outros serviços da AWS, como
o S3, por exemplo. O S3 guarda os recursos estáticos de uma determinada aplicação, enquanto
o CloudFront trata de retornar as requisições dos clientes a esses recursos da maneira mais
rápida possível, com menor latência possível, através de pontos de presença 20 espalhados pelo
mundo todo. As solicitações de seus conteúdos são direcionadas automaticamente para o
ponto de presença mais próximo, para que o conteúdo seja distribuído com o melhor
desempenho possível. (AMAZON WEB SERVICES, 6, 2014)
Se um cliente realizar uma requisição de um conteúdo estático (hospedado no S3)
e o ponto de presença mais próximo não possuir esse conteúdo, o CloudFront obterá uma
cópia no servidor para esse referido ponto de presença, e a próxima requisição não precisará ir
até o servidor novamente, indo apenas até o ponto de presença mais próximo. (VERAS, 2013,
p. 52)
20
Pontos de presença são servidores da AWS espalhados pelo mundo que guardam apenas recursos estáticos
para aumentar a performance na entrega desses recursos, entregando de pontos que estejam mais próximos
do usuário solicitante. (VERAS, 2013, p. 52)
41
2.2.14 Elastic Load Balancing
O Elastic Load Balancing distribui automaticamente o tráfego de entrada dos
aplicativos em várias instâncias do Amazon EC2. Ele permite que você atinja uma maior
tolerância a falhas em seus aplicativos, fornecendo a capacidade de equilíbrio de carga
necessária em resposta ao tráfego de entrada dos aplicativos. O Elastic Load Balancing
detecta instâncias com problemas de integridade dentro de um conjunto e redireciona
automaticamente o tráfego para instâncias íntegras até que as instâncias com problemas sejam
restauradas. Você pode habilitar o Elastic Load Balancing dentro de uma única zona de
disponibilidade ou em várias zonas para alcançar um desempenho de aplicativo ainda mais
consistente. (AMAZON WEB SERVICES, 5, 2014)
2.2.15 Amazon EBS
O Amazon Elastic Block Store (EBS) oferece armazenamento para as instâncias
do Amazon EC2. Os volumes do Amazon EBS são vinculados à rede e são armazenados
independentemente da vida de uma instância. Os volumes do Amazon EBS são altamente
disponíveis e extremamente confiáveis podendo ser aproveitados como um exemplo de
partição de inicialização do Amazon EC2 ou ligados a uma instância em execução do
Amazon EC2 como um dispositivo de bloco padrão. Quando utilizadas como uma partição de
inicialização, as instâncias Amazon EC2 podem ser interrompidas e posteriormente
reiniciadas, permitindo que você pague apenas pelos recursos de armazenamento utilizados,
mantendo o estado de sua instância. Os volumes do Amazon EBS oferecem melhor
durabilidade em comparação aos armazenamentos locais de instância do Amazon EC2,
porque os volumes do Amazon EBS são automaticamente replicados no back-end (em uma
única zona de disponibilidade). Para aqueles que desejam ainda maior durabilidade, o
Amazon EBS fornece a capacidade de criar snapshots de momentos específicos de seus
volumes, sendo armazenados no Amazon S3 e automaticamente duplicados através de várias
zonas de disponibilidade. Esses snapshots podem ser usados como ponto inicial para novos
volumes Amazon EBS e podem proteger seus dados para uma durabilidade a longo prazo.
42
Você pode também, facilmente, compartilhar esses snapshots com os colegas de trabalho e
com outros colaboradores da AWS. O Amazon EBS fornece dois tipos de volumes: volumes
padrão e de IOPS provisionadas. Os volumes padrão oferecem armazenamento econômico,
que é ideal para aplicativos com requisitos moderados ou intermitentes de entrada/saída. Os
volumes de IOPS provisionadas são desenvolvidos para fornecer alto desempenho previsível
para aplicativos com uso intensivo de entrada/saída, como bancos de dados. (AMAZON WEB
SERVICES, 5, 2014)
2.2.16 Amazon Route 53
Como descreve a própria Amazon Web Services (AMAZON WEB SERVICES,
7, 2014) descreve o serviço:
“O Amazon Route 53 é um serviço web de Domain Name System (DNS) altamente
disponível e escalável. Ele é projetado para oferecer aos desenvolvedores e empresas
uma maneira extremamente confiável e de baixo custo de direcionar os usuários
finais para aplicativos de Internet ao traduzir nomes legíveis como
www.example.com para os endereços IP numéricos como 192.0.2.1 que os
computadores usam para se conectarem uns aos outros.”
As principais características do Amazon Route 53 são as seguintes:

Altamente disponível e confiável: O Route 53 foi criado usando a infraestrutura
altamente disponível e confiável da AWS. A natureza distribuída dos servidores DNS
da AWS ajuda a assegurar uma capacidade consistente de direcionar os usuários finais
para seu aplicativo. O Route 53 foi criado para fornecer o nível de confiabilidade
exigido por aplicativos importantes. (AMAZON WEB SERVICES, 7, 2014)

Escalável: O Route 53 foi criado para ser escalonado automaticamente para lidar com
volumes de consulta muito grandes sem a intervenção do cliente da AWS. (AMAZON
WEB SERVICES, 7, 2014)

Projetado para uso com outras Amazon Web Services: O Route 53 foi projetado
para funcionar bem com outros serviços da AWS. É possível usar o Route 53 para
mapear nomes de domínio para instâncias do Amazon EC2, buckets do Amazon S3,
distribuições do Amazon CloudFront e outros recursos da AWS. (AMAZON WEB
SERVICES, 7, 2014)
43

Simples: Com possibilidade de inscrição pelo autoatendimento, o Route 53 pode
começar a responder as consultas DNS em poucos minutos. É possível configurar as
definições de DNS com o Console da AWS ou uma API de fácil utilização. Também é
possível integrar programaticamente a API do Route 53 em todo o aplicativo da Web.
Por exemplo, você pode usar a API do Route 53 para criar um registro de DNS sempre
que uma nova instância do EC2 for criada. (AMAZON WEB SERVICES, 7, 2014)

Rápido: Usando uma rede anycast 21 global de servidores DNS no mundo todo, o
Route 53 foi projetado para direcionar automaticamente seus usuários para a
localização ideal dependendo das condições da rede. Como resultado, o serviço
oferece baixa latência de consulta para os usuários finais, assim como baixa latência
de atualização para as necessidades de gerenciamento de registros do DNS.
(AMAZON WEB SERVICES, 7, 2014)

Econômico: Paga-se somente pela gestão dos domínios por meio do serviço e do
número de consultas às quais o serviço responde para cada um dos domínios, por um
custo baixo e sem compromissos de uso mínimo ou quaisquer taxas prévias.
(AMAZON WEB SERVICES, 7, 2014)

Seguro: Ao integrar o Route 53 ao AWS Identity and Access Management (IAM), é
possível conceder credenciais exclusivas e gerenciar permissões para todo usuário
dentro da conta da AWS e especificar quem tem acesso a quais partes do serviço
Route 53. (AMAZON WEB SERVICES, 7, 2014)

Flexível: O Route 53 oferece balanceamento de carga do DNS. Isso permite designar
“pesos” aos registros do DNS que especificam qual parte do seu tráfego é direcionada
a vários pontos finais. (AMAZON WEB SERVICES, 7, 2014)
21
Anycast trabalha com a topologia de roteamento de dados para encaminhar os dados para o destino mais
próximo. Resumidamente, ela encaminha as requisições feita por um ponto para o servidor mais próximo que
possa
responder
por
aquela
requisição.
(Fonte:
<http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/gss4400series/v3.1.1/admi
nistration/guide/Anycast.html>, acesso em: 12 jan. 2014)
44
2.2.17 Amazon RDS
O Amazon RDS é um banco de dados relacional na nuvem. Dentro dele é possível
instanciar os seguintes sistemas gerenciadores de banco de dados: MySQL, Oracle, Microsoft
SQL Server ou PostgreSQL. O Amazon RDS facilita a configuração, a operação e
escalabilidade de um banco de dados relacional na nuvem. (AMAZON WEB SERVICES, 8,
2014)
O Amazon RDS é integrado ao IAM (Identity Access and Management) da AWS,
o que facilita a gestão de segurança do banco de dados. (VERAS, 2013, p. 223)
O Amazon RDS faz o backup do banco de dados automaticamente e mantém o
backup por um tempo configurado pelo usuário do serviço, permitindo a recuperação do
estado do banco em uma data específica. (AMAZON WEB SERVICES, 8, 2014)
É possível instanciar um banco de dados com o armazenamento padrão ou o
armazenamento de IOPS (Input/Output Operations per Second, Operações de Entrada/Saída
por segundo). As IOPS provisionadas do Amazon RDS permitem desempenho rápido,
previsível e consistente de entrada e saída de dados. (AMAZON WEB SERVICES, 8, 2014)
O Amazon RDS permite a sua replicação em múltiplas zonas de disponibilidade
(chamado de Multi-AZ) facilitando o uso da replicação para aumentar a disponibilidade e
confiabilidade de cargas de trabalho de produção.
Segundo a documentação do Amazon RDS (AMAZON WEB SERVICES, 8,
2014):
“Quando você provisiona uma instância de banco de dados Multi-AZ, o Amazon
RDS cria automaticamente uma instância de banco de dados primária e replica
sincronicamente os dados para uma instância de espera em uma zona de
disponibilidade (AZ) diferente. Cada AZ opera em sua própria infraestrutura
fisicamente distinta e independente e é projetada para ser altamente confiável.”
2.2.18 Amazon ElastiCache
A AWS oferece um serviço elástico de cache em memória na nuvem que auxilia a
implementação, operação e dimensionamento do mesmo. O cache em memória pode ser
utilizado para aumentar o desempenho das aplicações web, permitindo que se recupere
45
informações de caches na memória em vez de recuperar essas mesmas informações no banco
de dados, que são mais lentos. (AMAZON WEB SERVICES, 9, 2014)
A Amazon ElastiCache fornece suporte para dois mecanismos de armazenamento
em cache, de código aberto (AMAZON WEB SERVICES, 9, 2014):

Memcached: um sistema de armazenamento em cache de objetos na memória
largamente adotado. (AMAZON WEB SERVICES, 9, 2014)

Redis: um popular armazenamento de chaves e seus respectivos valores na memória,
que fornece suporte para estruturas de dados como listas e conjuntos classificados. O
ElastiCache fornece suporte para a replicação mestre/escravo (master/slave) do Redis,
que pode ser usada para se obter redundância cruzada de zonas de disponibilidade.
(AMAZON WEB SERVICES, 9, 2014)
2.2.19 Modelos de precificação
Os modelo de precificação da AWS são baseados nos seguintes aspectos
(VERAS, 2013, p. 89):

Pay as you go: Não há compromissos mínimos necessários, nem contratos de longo
prazo. Essa flexibilidade reduz a necessidade de realizar um planejamento de uso dos
recursos de forma detalhada. (VERAS, 2013, p. 89)

Pague pelo uso: Não há necessidade de pagar adiantado para o excesso de capacidade
ou ser penalizado por problemas de falta de planejamento. (VERAS, 2013, p. 89)

Pague menos usando mais: Para transferência de armazenamento de dados, o preço é
definido em camadas. Quanto mais usa, menos paga. Quando o recurso desejado é
reservado mensalmente, o custo é ainda menor. (VERAS, 2013, p. 89)

Preço personalizado: Existem preços personalizados para projetos de alto volume com
necessidades específicas. (VERAS, 2013, p. 89)
Características fundamentais da precificação (VERAS, 2013, p. 90):

Computação (processamento)

Armazenamento

Transferência de dados para fora da nuvem
46
Apesar de existir um custo para transferência de dados para fora da nuvem, não
existe custo para transferências dentro de uma mesma região. (VERAS, 2013, p. 90)
O problema de comparar custos tradicionais com custos na AWS é que poucas
empresas sabem exatamente o quanto gastam com infraestrutura. Além disso, o gasto não
pode ser só dimensionado em recursos computacionais, deve-se considerar o gasto com
espaço físico, energia elétrica, ar-condicionado, manutenção e pessoas capacitadas para
garantir toda a estrutura e segurança necessárias para os recursos computacionais operarem
corretamente. (VERAS, 2013, p. 89)
Os preços podem variar de acordo com a região utilizada (VERAS, 2013, p. 90).
Os
valores
exatos
de
cada
serviço
da
AWS
estão
disponíveis
no
site:
http://aws.amazon.com/pricing/
3
PROPOSTA DE ARQUITETURAS PARA A NUVEM
Neste capítulo serão apresentadas algumas propostas de arquitetura de aplicações
utilizando os serviços da AWS. Essas arquiteturas são propostas na documentação da própria
AWS, para que os seus clientes possam ter uma aplicação com um baixo custo de
hospedagem, grande elasticidade, suporte a balanceamento de carga, alta disponibilidade e
tolerância a falhas.
3.1
ARQUITETURA PARA HOSPEDAGEM DE APLICAÇÕES WEB
Para utilizar a arquitetura de serviços AWS ideal para aplicações Web,
recomendada pela própria AWS (AMAZON WEB SERVICES, 10, 2014), é necessário o uso
dos seguintes serviços:

Amazon Route 53

Amazon CloudFront

Amazon S3
47

Elastic Load Balancing

Amazon EC2

Auto Scaling

Amazon RDS
Figura 8: Arquitetura para hosting de uma aplicação Web.
Fonte:
AWS
Reference
Architetures:
Web
Hosting
Application.
Disponível
em:
<http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_web_01.pdf>. Acesso em: 4 jan. 2014.
Visão geral da arquitetura
1. Através do Route 53, o DNS requisitado pelo browser do cliente é traduzido e o
tráfego é roteado para os servidores da AWS. (AMAZON WEB SERVICES, 10,
2014)
2. Todo o conteúdo estático, de streaming ou dinâmico deve ser entregue pelo Amazon
CloudFront. Sendo assim, as requisições são automaticamente roteadas para o servidor
mais próximo do usuário, aumentando a performance da aplicação. (AMAZON WEB
SERVICES, 10, 2014)
3. Recursos e conteúdos estáticos usados pela aplicação web devem ser armazenados no
Amazon S3. (AMAZON WEB SERVICES, 10, 2014)
4. As requisições HTTP devem ser primeiramente gerenciadas pelo Elastic Load
Balancing, no qual automaticamente distribui o tráfego de entrada da aplicação através
de múltiplas instâncias EC2, dispersas entre várias Zonas de Disponibilidade (AZs).
48
Essa prática permite ainda maior tolerância a falhas nas aplicações fornecendo a
capacidade de balanceamento de carga necessária em resposta ao tráfego de entrada da
aplicação. (AMAZON WEB SERVICES, 10, 2014)
5. Os servidores web e de aplicação devem ser implantados nas instâncias EC2.
(AMAZON WEB SERVICES, 10, 2014)
6. Os servidores web e de aplicação devem ser implantados em um grupo de “Auto
Scaling”. O “Auto Scaling” da AWS automaticamente ajusta a capacidade
computacional da aplicação de acordo com condições pré-definidas. O serviço de
“Auto Scaling” da AWS possibilita que a capacidade computacional das instâncias
EC2 aumente ou diminua automaticamente de acordo com a demanda requerida.
(AMAZON WEB SERVICES, 10, 2014)
7. Para prover alta disponibilidade, o banco de dados relacional que contém os dados da
aplicação deve possuir uma redundância em múltiplas zonas de disponibilidade.
(AMAZON WEB SERVICES, 10, 2014)
3.2
ARQUITETURA PARA TOLERÂNCIA A FALHAS E ALTA DISPONIBILIDADE
Para utilizar a arquitetura de serviços AWS ideal para aplicações com alta
tolerância a falhas e alta disponibilidade, recomendada pela própria AWS (AMAZON WEB
SERVICES, 10, 2014), é necessário o uso dos seguintes serviços:

Amazon EC2

Amazon EBS

Elastic Load Balancing

Amazon S3
A maioria dos serviços da AWS, como Amazon S3, Amazon SimpleDB, Amazon
SQS e Amazon ELB, foram construídos com tolerância a falhas e alta disponibilidade em
mente. Serviços que provem infraestrutura básica, como o EC2 e o EBS, provem recursos
específicos, como as zonas de disponibilidade, endereços de IP elásticos e snapshots, que um
sistema com tolerância a falhas e alta disponibilidade devem usar corretamente. Apenas
49
mover um sistema para a nuvem não o torna tolerante a falhas ou altamente disponível.
(AMAZON WEB SERVICES, 10, 2014)
Abaixo seguem os passos necessários para uma arquitetura tolerante a falhas e
com alta disponibilidade, primeiro através do serviço Elastic Load Balancing (Figura 8),
depois, através do serviço Elastic IP (Figura 9)
1. Balanceamento de carga é uma maneira efetiva de aumentar a disponibilidade de um
sistema. Instâncias que falham podem ser substituídas facilmente pelo balanceador de
carga, enquanto as outras instâncias continuam funcionando. (AMAZON WEB
SERVICES, 10, 2014)
2. As zonas de disponibilidade são em locais geograficamente distintos, projetados para
ser isolados de falhas em outras zonas de disponibilidade. Colocando as instâncias
EC2 em múltiplas zonas de disponibilidade, uma aplicação fica protegida caso haja
uma falha em alguma localidade específica. É importante rodar as aplicações de
maneira independente em diversas zonas de disponibilidade, sendo em uma mesma
região ou em regiões diferentes, para que, caso alguma das zonas falhe, a aplicação em
outra zona continue rodando. Quando se projeta um sistema desse tipo, é importante
possuir um bom conhecimento das zonas de disponibilidade e regiões. (AMAZON
WEB SERVICES, 10, 2014)
3. Endereços Elastic IP são IPs públicos que podem ser programaticamente mapeados
entre instâncias de uma determinada região. Endereços Elastic IP são associados com
uma conta AWS e não com uma instância específica. Endereços Elastic IP podem ser
utilizados para contornar falhas de instância EC2 ou zona de disponibilidade
remapeando rapidamente o endereço para outra instância em execução ou uma
instância de substituta que pode ser iniciada. Instâncias Reservadas podem ajudar a
garantir que essa capacidade está disponível em outra zona. (AMAZON WEB
SERVICES, 10, 2014)
4. Dados importantes nunca devem ser armazenados apenas no armazenamento da
instância sem backups adequados, replicações, ou uma maneira de recriar os dados. O
Amazon EBS oferece volumes para armazenamentos independentes de instâncias
específicas que são mais duráveis do que no armazenamento da instância. Volumes
EBS são automaticamente replicadas dentro de uma única zona de disponibilidade.
Para aumentar a durabilidade ainda mais, snapshots de um período específico podem
ser criados para armazenar dados em volumes no Amazon S3, que são então
replicados para várias zonas de disponibilidade. Embora os volumes EBS estão
50
vinculados a uma zona de disponibilidade específica, snapshots são vinculados a uma
região. Usando um snapshot, você pode criar volumes EBS em qualquer zona de
disponibilidade da mesma região. Esta é uma maneira eficaz de lidar com falhas de
disco ou outras questões de servidor, bem como com os problemas que afetam uma
zona de disponibilidade específica. Os snapshots são incrementais, por isso é
aconselhável armazenar somente snapshots recentes. (AMAZON WEB SERVICES,
10, 2014)
Figura 9: Arquitetura para alta tolerância a falhas e alta disponibilidade utilizando o Elastic Load Balancing.
Fonte: AWS Reference Architetures: FAULT TOLERANCE & HIGH AVAILABILITY. Disponível em:
<http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf>. Acesso em 4 jan. 2014.
51
Figura 10: Arquitetura para alta tolerância a falhas e alta disponibilidade utilizando o Elastic IP.
Fonte: AWS Reference Architetures: FAULT TOLERANCE & HIGH AVAILABILITY. Disponível em:
<http://media.amazonwebservices.com/architecturecenter/AWS_ac_ra_ftha_04.pdf>. Acesso em: 4 jan. 2014
52
4
CASO DE USO: APLICAÇÃO LEGADA
Neste capítulo será visto a atual arquitetura das aplicações de uma empresa
hipotética e a infraestrutura na qual essa arquitetura costuma rodar. Além disso, serão
propostas alterações na arquitetura atual das aplicações dessa empresa para que a mesma
possa rodar de acordo com as arquiteturas propostas no capítulo 3 (Proposta de arquiteturas
para a nuvem).
4.1
INFRAESTRUTURA ATUAL
Figura 11: Diagrama de deployment mostrando a atual infraestrutura que roda as aplicações da empresa
hipotética
Na figura 11 é possível visualizar a atual infraestrutura que roda as aplicações da
empresa hipotética.
53
4.2
ARQUITETURA ATUAL
A arquitetura atual segue o modelo Model-view-controller (MVC), que é
estruturado em três camadas. Na tabela 1, é possível visualizar quais frameworks são
utilizados em cada camada.
Tabela 1: Frameworks utilizados para suportar o modelo MVC nas aplicações da empresa hipotética
Model
Controller
View
Java Persistence API (JPA)
Java Server Faces (JSF)
Java Server Faces
(JSF)
Hibernate
Contexts and Dependency Injection
(CDI)
JavaScript
Java Database
(JDBC)
Connectivity
Enterprise JavaBeans (EJB)
4.3
HyperText
Markup Language
(HTML)
JSF
Segundo Burns (2009, p. 37):
“A capacidade de processamento do ciclo de vida do request JSF de sincronizar
automaticamente do lado do servidor propriedades Java Bean para um conjunto
hierárquico de componentes que são baseados na interface apresentada ao usuário é
uma grande vantagem sobre as outras tecnologias web. Esse recurso é conhecido
como “gerenciamento de estado” e é uma pedra angular do valor fornecido pelo
JSF”.
A afirmação de Burns pode ser vista melhor na figura 12, logo abaixo.
54
Figura 12: Uma representação do lado do servidor da interface com o usuário. (BURNS, 2009, p. 37)
Isso significa que todo o usuário da aplicação possui na sua sessão uma árvore de
componentes que representa aquilo que o mesmo está vendo renderizado na tela. (BURNS,
2009, p. 38)
Devido a essa replicação da árvore de componentes, tanto no servidor quanto no
cliente, o balanceamento de carga é dificultado, pois o mesmo, no seu modo padrão,
pressupõe que os servidores não guardam sessão do usuário. (AMAZON WEB SERVICES,
11, 2012)
Uma das maneiras de resolver esse problema é utilizar o conceito de Sticky
Sessions, no qual relaciona uma sessão de usuário a um servidor específico. Isso garante que
todas as requisições provenientes de um usuário durante a sua sessão será enviado para a
mesma instância do aplicativo. (AMAZON WEB SERVICES, 11, 2012)
55
4.4
SESSÕES DE USUÁRIO
Atualmente todas as sessões do usuário nas aplicações dessa empresa hipotética
são armazenadas no próprio servidor de aplicação. Isso dificulta o balanceamento de carga,
pois, no cenário de balanceamento de carga, não se sabe em qual dos servidores disponíveis
cairá a requisição do usuário. Sendo assim, ou o a sessão do usuário deve ser replicada em
todos os servidores, ou deve-se utilizar o recurso Sticky Sessions, no qual um usuário
específico é endereçado a somente um dos servidores do balanceamento de carga. (AMAZON
WEB SERVICES, 11, 2012)
O uso de um servidor de cache é recomendado para evitar manter a sessão do
usuário no servidor web, que pode ocasionar a perda da sessão com a quebra do servidor.
(VERAS, 2013, p. 247)
4.5
CACHE DE CONSULTAS DE BANCO
A utilização de um cache para as consultas no banco de dados são importantes
para a redução da carga sobre o banco de dados (chamado de cache de query), melhorando o
desempenho da aplicação. (VERAS, 2013, p. 248)
O atual framework da empresa hipotética não possui nenhuma extensão para
auxiliar que determinadas consultas possam usufruir de uma estrutura pré-definida de cache.
4.6
MULTITENANCY
As aplicações da empresa hipotética não cobrem todos os cenários Multi-tenant,
apenas o cenário 1 e 2, mostrados no capítulo 2.2.9, no entanto, o cenário 3 é o melhor uso do
multitenancy, e ideal para aplicações SaaS. Deve ser implementado os identificadores de
tenant (tenant id) nas entidades que representam o modelo de dados da aplicação.
56
4.7
CHAMADAS ASSÍNCRONAS
Para o correto escalonamento dos serviços da aplicação, os EJBs devem ser
apenas stateless (sem estado), para que a elasticidade possa funcionar corretamente sem haver
problemas com o estado dos objetos.
Apesar da arquitetura da empresa hipotética permitir serviços stateless, através
dos EJB's, ela não prega o uso de serviços assíncronos. Como visto no capítulo 2.2.10, o uso
de serviços assíncronos é importante para dar uma melhor experiência de uso da aplicação ao
usuário. Alguns serviços, que são demorados por natureza, podem continuar rodando
enquanto o usuário navega em outras partes do sistema. O uso de sistemas sincronizados
deixará o usuário esperando até o serviço ser executado, o que causaria uma experiência de
uso ruim para o usuário.
4.8
ARQUITETURA DE SERVIÇOS
Conforme disse Veras (2003, p. 286), “A nuvem reforça o princípio SOA de
design de que quanto mais separados estiverem os componentes do sistema, muito mais e de
melhor maneira eles se dimensionarão e facilitarão a elasticidade.”
A arquitetura atual da empresa hipotética utiliza EJBs para encapsular os serviços.
Isso já é suficiente para implementar a elasticidade, mas não é o suficiente para disponibilizar
esses mesmos serviços para acesso de outras linguagens.
Para resolver esse problema, recomenda-se o uso de serviços REST, já explicados
no capítulo 2.2.6.1.2, possibilitando a criação de clientes em diversas linguagens e interfaces
diferentes que acessem os mesmos serviços.
57
5
CONCLUSÃO
O estudo sobre os serviços disponibilizados na nuvem foi muito importante para
saber como projetar uma aplicação para utilizar os mesmos da melhor maneira. Conhecendo
profundamente todos os serviços, é possível conseguir alta performance, tolerância a falhas e
alta disponibilidade com relativo baixo custo. Uma arquitetura mal projetada, utilizando
apenas serviços básicos pode gerar insatisfação, desapontamento e altos custos com a
infraestrutura na nuvem.
Pesquisando também sobre arquiteturas, concluiu-se que nenhum dos conceitos
levantados são exclusivos da infraestrutura em nuvem. A maioria deles sempre existiu, mas
era extremamente complexos de serem implementados. Conceitos como elasticidade,
balanceamento de carga e auto-escalonamento já existiam antes mesmo da nuvem. Apesar
desses conceitos serem pouco aplicados na prática da maioria das empresas, eles foram
cruciais para o crescimento exponencial dos provedores de infraestrutura na nuvem, ainda
mais pela facilidade e possibilidades que se tem na hora utilizá-los.
Com esses conceitos novamente em alta, resta às aplicações projetarem suas
arquiteturas para utilizá-los da melhor maneira possível sendo esse o principal estudo deste
trabalho: saber quais são as arquiteturas de hardware ideais e o que deve ser projetado na
aplicação para a mesma utilizar bem esses recursos.
O comparativo entre a aplicação legada, que roda em um servidor próprio, foi
muito importante para entender melhor e na prática como projetar adequadamente uma
aplicação para a nuvem.
Por fim, espero que esses estudos possam ser aplicados de fato para que as
empresas que o apliquem possam estar preparadas para essa mudança de responsabilidade
sobre a infraestrutura de hardware e de redes, que já é uma realidade, e, com isso, possam
estar a frente no mercado.
58
REFERÊNCIAS
ABBOTT, Martin L.; FISHER, Michael T.. Scalability Rules: 50 Principles for Scaling Web
Sites. Boston: Addison-wesley Professional, 2011.
ALBERTONI, Fabio. et al. WebSphere Application Server V7 Administration and
Configuration Guide. United States of America: IBM, 2010.
AMAZON WEB SERVICES, 1 (Org.). About AWS. Disponível em:
<http://aws.amazon.com/about-aws/>. Acesso em: 20 dez. 2013.
AMAZON WEB SERVICES, 2 (Org.). Products & Services. Disponível em:
<http://aws.amazon.com/products/>. Acesso em: 13 jan. 2014.
AMAZON WEB SERVICES, 3 (Org.). Amazon Elastic Compute Cloud: Amazon EC2.
Disponível em: <http://aws.amazon.com/ec2/>. Acesso em: 13 jan. 2014.
AMAZON WEB SERVICES, 4 (Org.). Amazon Simple Storage Service: Amazon S3.
Disponível em: <http://aws.amazon.com/s3/>. Acesso em: 12 jan. 2014.
AMAZON WEB SERVICES, 5 (Org.). Amazon Elastic Compute Cloud: Amazon EC2.
Disponível em: <http://aws.amazon.com/ec2/>. Acesso em: 12 jan. 2014.
AMAZON WEB SERVICES, 6 (Org.). Amazon CloudFront. Disponível em:
<http://aws.amazon.com/cloudfront/>. Acesso em: 6 jan. 2014.
AMAZON WEB SERVICES, 7 (Org.). Amazon Route 53. Disponível em:
<http://aws.amazon.com/route53/>. Acesso em: 7 jan. 2014.
AMAZON WEB SERVICES, 8 (Org.). Amazon Relational Database Service: Amazon
RDS. Disponível em: <http://aws.amazon.com/rds/>. Acesso em: 5 jan. 2014.
AMAZON WEB SERVICES, 9 (Org.). Amazon ElastiCache. Disponível em:
<http://aws.amazon.com/elasticache/>. Acesso em: 8 jan. 2014.
AMAZON WEB SERVICES, 10 (Org.). AWS Architecture Center. Disponível em:
<http://aws.amazon.com/architecture/>. Acesso em: 18 jan. 2014.
AMAZON WEB SERVICES, 11 (Org.). Create Sticky Sessions. 2012. Disponível em:
<http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/US_StickySessio
ns.html>. Acesso em: 3 fev. 2014.
ARORA, Ankit; GUPTA, Abhinav. Force.com Tips and Tricks: A quick reference guide for
administrators and developers to get more productive with Force.com. Birmingham: Packt
Publishing Ltd., 2013.
BAKKER, Paul; Ertman, Bert. Building Modular Cloud Apps with OSGi. 1. ed United
States of America: O'Reilly, 2013.
BURNS, Ed; SCHALK, Chris; GRIFFIN, Neil. JavaServer Faces 2.0: The Complete
Reference. United States Of America: Mcgraw-hill Osborne Media, 2009.
59
CHATE, Scott. Convert your web application to a multi-tenant SaaS solution: A checklist
of considerations and steps to quickly turn your web app into a cloud application. 2010.
Disponível em: <http://www.ibm.com/developerworks/cloud/library/cl-multitenantsaas/>.
Acesso em: 10 jan. 2014.
CHEDE, Cezar. O que é Elasticidade em Cloud Computing, dez. 2009. Disponível em:
<https://www.ibm.com/developerworks/community/blogs/ctaurion/entry/o_que__c3_a9_elast
icidade_em_cloud_computing?lang=en>. Acesso em: 02 de dez. 2013.
COUTINHO, Emanuel F.; Sousa, Flávio R. C.; Gomes, Danielo G.; Souza, José N. de.
Elasticidade em Computação na Nuvem: Uma Abordagem Sistemática. 2013. Disponível
em: <http://sbrc2013.unb.br/files/anais/minicursos/minicurso-5.pdf >. Acesso em: 09 de dez.
2013.
DIKMANS, Lonneke; Luttikhuizen, Ronald v. SOA Made Simple: Discover the true
meaning behind the buzzword that is 'Service Oriented Architecture'. 1. ed. United Kingdom:
Packt Publishing, 2012.
HENDERSON, Cal. Building Scalable Web Sites. 1. ed United States of America: O'Reilly,
2006.
HOWARD, Chris; Plummer, Daryl C.; Genovese, Yvonne; Mann, Jeffrey; Willis, David A.;
Smith, Mitchell Smith. The Nexus of Forces: Social, Mobile, Cloud and Information, jun.
2010. Disponível em: <https://www.gartner.com/doc/2049315 >. Acesso em: 11 de dez. 2013.
JACOBSON, Daniel; Brail, Greg; Woods, Dan. APIs: A Strategy Guide. United States of
America: O'Reilly, 2012.
MELL, Peter; Grance, Timothy. The NIST Definition of Cloud Computing:
Recommendations of the National Institute of Standards and Technology, set 2011.
Disponível em: <http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf >. Acesso
em: 18 nov. 2013.
OTTINGER, Joseph. What is an App Server? Set. 2008. Disponível em:
<http://www.theserverside.com/news/1363671/What-is-an-App-Server > Acesso em: 10 de
dez. 2013
REESE, George. Cloud Application Architectures: Building Applications and Infrastructure
in the Cloud. United States of America: O'Reilly, 2009.
ROSNER, Todd. Learning AWS OpsWorks: Learn how to exploit advanced technologies to
deploy and auto-scale web stacks. 1. ed. United Kingdom: Packt Publishing, 2013.
VARIA, Jinesh. Projetando para a nuvem: práticas recomendadas, jan. 2010. Disponível
em: <http://d36cz9buwru1tt.cloudfront.net/pt/wp/AWS_Cloud_Best_Practices_05252010.pdf
>. Acesso em: 20 nov. 2013.
VERAS, Manoel. Arquitatura de Nuvem: Amazon Web Services (AWS). 1. ed. Rio de
Janeiro: Brasport, 2013.
VLIET, Jurg v.; Paganelli, Flavia. Programming Amazon EC2. 1. ed. United States of
America: O'Reilly, 2011.
60
WALSH, Bob. The Web Startup Success Guide. United States of America: APRESS, 2009.
WILDER, Bill. Cloud Architecture Patters. United States of America: O'Reilly, 2012.