Mestrado Thiago Jamir

THIAGO JAMIR E SILVA
UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE ARQUIVOS
Dissertação de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE/2014
Thiago Jamir e Silva
UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE

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

Ciência da Computação do Centro de Informática da Univer-
sidade Federal de Pernambuco como requisito parcial para
obtenção do grau de Mestre em Ciência da Computação.
Orientador: Silvio Romero de Lemos Meira

Co-Orientador: Rodrigo Elia Assad
RECIFE
2014
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S586a Silva, Thiago Jamir e

Uma arquitetura de cloud storage para backup de arquivos / Thiago Jamir e
Silva. – 2014.
72 f.: il., fig., tab.
Orientador: Sílvio Romero de Lemos Meira.

Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,
Ciência da Computação, Recife, 2014.
Inclui referências e apêndice.
1. Engenharia de software. 2. Computação em nuvem. 3. Arquitetura de

software. 4. Sistemas distribuídos. I. Meira, Sílvio Romero de Lemos
(orientador). II. Título.
005.1 CDD (23. ed.) UFPE- MEI 2016-132

Dedico este trabalho à minha família e meus amigos. Pois sem eles, este trabalho não
seria possível.
Agradecimentos
Antes de mais nada, gostaria de agradecer à toda minha família por todo o apoio.
Principalmente minha esposa, Eduarda, por ter acreditado na minha capacidade, quando
eu mesmo duvidei. Meus pais, e meu irmão pelo apoio constante, e pelos exemplos que me
deixaram para seguir.
Aos meus amigos cujo apoio foi fundamental para o término deste trabalho. Fica aqui o
meu obrigado a todos.
Aos professores Professores Silvio Meira (orientador), Rodrigo Assad (co orientador) e
Vinícius Garcia, pela oportunidade dada, pelas trocas de idéia, pela cobrança e pelos
caminhos que foram indicados.
Ao professor Cícero Garrozi, por se disponibilizar a fazer parte da banca deste trabalho.
Ao Centro de Informática da UFPE e todos que o fazem, pelo ensino e suporte dado para
que este possa ter concluído.
Aos colegas do ASSERT Lab por todos os feedbacks dados durante a evolução desse
projeto. Tenho certeza que essas discussões foram proveitosas para todos nós.
A todos os colegas da Ustore, pela paciência e colaboração de todos , que para mim, é
uma segunda casa.
Finalmente, gostaria de agradecer a todos que contribuíram diretamente e indiretamente
à realização de mais etapa na minha vida.
Obrigado a todos!
Resumo
Nos últimos anos, o volume de dados gerados por indivíduos e organizações tem crescido
exponencialmente. Estima-se que globalmente existia 2.7 zetabytes em 2012 e esse número
tem dobrado a cada dois anos. Além disso, com a popularização de dispositivos móveis
conectados, cresceu-se a necessidade de que usuários tenham acesso a arquivos de forma
ubíqua. As soluções tradicionais de backup e armazenamento de arquivos online já não
conseguem suprir as necessidades atuais dos usuários.
A utilização de Cloud Storage para backup e sincronização de arquivos vem a ser uma
ferramenta de grande valia para esse tipo de problema. Porém, implementar um sistema
deste tipo vem a ser um desafio tecnológico relevante.
Nesse sentido, este trabalho se propõe a resolver o problema de armazenamento de arquivos,
propondo uma arquitetura de Cloud Storage para armazenamento de arquivos.
Ao longo trabalho, é feita uma análise dos principais direcionadores de negócio para Cloud
Storage e armazenamento de arquivos, levantando insumos para se projetar uma arquitetura.
Tal arquitetura é descrita em nível de detalhe para que se possa ser implementada.
Finalmente, o trabalho é validado através de uma avaliação de arquitetura cuja metodologia
foi adaptada de acordo com as características da equipe de avaliação.
Palavras-chave: Arquitetura de software. Cloud computing. Cloud storage. Backup.

Sincronização.
Abstract
In the last years, the amount of data generated by individuals and organizations has grown
exponentially. It is estimated that there were 2.7 zettabytes of global data in 2012, and
this number has doubled each two years. In addition to this, with the popularization of
mobile connected devices, the user’s need to have ubiquous access has grown. Traditional
solutions for backup and online file storage can no longer meet the current needs.
The use of cloud storage for backup and file synchronization becomes a tool of great
value to this kind of problem. However, implementing such a system becomes a significant
technological challenge.
Thus, this works proposes to solve the problem of storing files, designing a Cloud Storage
architecture for storing archives.
Throughout work, an analysis of the key business drivers for Cloud Storage and File storage
is done by lifting inputs for designing an architecture. This architecture is described in
detail for level that can be implemented.
Finally, the work is validated through an evaluation of architecture whose methodology
was adapted according to the characteristics of the evaluation team.
Keywords: Software Architecture. Cloud Computing. Cloud storage. Backup. Synchro-

nization.
Lista de ilustrações
Figura 1 – Modelos de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figura 2 – Atributos de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Figura 3 – Divisão em camadas de serviço . . . . . . . . . . . . . . . . . . . . . . 40
Figura 4 – Listagem dos Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figura 5 – Visão da estrutura interna . . . . . . . . . . . . . . . . . . . . . . . . . 44
Figura 6 – Visão de Implantação . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figura 7 – Visão de implantação do basic storage . . . . . . . . . . . . . . . . . . 46
Figura 8 – Visão de componentes do basic storage . . . . . . . . . . . . . . . . . . 47
Figura 9 – Inserção de dados na DHT . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 10 – Diagrama de classes do nó de armazenamento . . . . . . . . . . . . . . 50
Figura 11 – Estrutura de um serviço . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 12 – Diagrama de classes do file storage . . . . . . . . . . . . . . . . . . . . 51
Figura 13 – Diagrama de sequência de um backup de arquivo . . . . . . . . . . . . 52
Figura 14 – Modelo de dados para o banco de dados . . . . . . . . . . . . . . . . . 53
Lista de tabelas
Tabela 1 – Atributos de Qualidade escolhidos . . . . . . . . . . . . . . . . . . . . 30

Tabela 2 – Consolidação dos Resultados . . . . . . . . . . . . . . . . . . . . . . . 61
Tabela 3 – Matriz Vantagens x QAs . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Tabela 4 – Matriz Desvantagens x QAs . . . . . . . . . . . . . . . . . . . . . . . . 72
SOA Services Oriented Architecture
ESB Enterprise Service Bus
ATAM Architecture Tradeoff Analisys Method
SAAM Software Architecture Analisys Method
REST Representational state transfer
QA Quality Attribute
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1 Definição do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Fora do escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 CONTEXTUALIZAÇÃO E TRABALHOS RELACIONADOS . . . . 16

2.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.1 História de cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Definição de Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Cloud Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.1 História do armazenamento em rede . . . . . . . . . . . . . . . . . . . . . 20
2.2.2 Definindo cloud storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.3 Aplicações de cloud storage . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Oceanstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.2 Windows Azure Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.3 Google File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.4 Ustore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 CLOUD STORAGE BUSINESS DRIVERS . . . . . . . . . . . . . . 25

3.1 Definição do Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Principais Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Principais Desvantagens e Ameaças . . . . . . . . . . . . . . . . . . . . . 26
3.1.3 Identificação dos Principais Stakeholders . . . . . . . . . . . . . . . . . . . 27
3.1.4 Restrições do negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.5 Restrições técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Atributos de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4 DEFINIÇÃO DA ARQUITETURA . . . . . . . . . . . . . . . . . . . 34
4.1 Decisões arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.1.1 Orientação a Serviços através de Representational state transfer (REST) . . 34
4.1.2 Persistência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.3 Utilização de DHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.4 Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Orientação a Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.1 Camadas de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.2 Descrição dos serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3 Visão Geral da arquitetura . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Camada de Serviços Básicos . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Camada de Serviços Importantes . . . . . . . . . . . . . . . . . . . . 48
4.6 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.8 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5 AVALIACAO DA ARQUITETURA . . . . . . . . . . . . . . . . . . . 55
5.1 Processo de avaliação de arquitetura de software . . . . . . . . . . . 55
5.2 Equipe de Avaliação da arquitetura . . . . . . . . . . . . . . . . . . . 56
5.3 Ameaças á validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.4 Metodologia de avaliação . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.5 Execução do processo de avaliação . . . . . . . . . . . . . . . . . . . 57
5.6 Cenários propostos e resultados da avaliação . . . . . . . . . . . . . . 58
5.7 Consolidação dos Resultados . . . . . . . . . . . . . . . . . . . . . . . 60
5.8 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.1 Principais Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
APÊNDICES 69
APÊNDICE A – MATRIZ VANTAGENS E DESVANTAGENS X

QAS . . . . . . . . . . . . . . . . . . . . . . . . . . 70
13
1 Introdução
Atualmente, tem-se observado um crescimento alarmante no volume de dados

mundial. De acordo com Gantz J. e Reinsel (2011), esse volume global superou 1 zettabyte
em 2010 e tem previsão de alcançar 8 zettabytes em 2015.
Este fato tem ocorrido devido à crescente quantidade de aplicativos e dispositivos que
geram conteúdos para armazenar. Desde textos, e-mails até vídeos em alta resolução. Além
disso, com o advento dos dispositivos portáteis e a internet móvel, surgiu a necessidade
dos usuários de acessar seus conteúdos de forma ubíqua.
As soluções de de backups e sincronização de arquivos tradicionais já não têm suprido a
demanda crescente dos usuários. Pois, podemos encontrar alguns problemas nessas solução,
tais como:
• Não permitem acesso de qualquer dispositivo;
• Requerem que o usuário esteja conectado a uma rede;
• Tem um custo elevado de hardware para serem implantados;
• Não escalam para o volume crescente de dados.
A utilização de sistemas de Cloud Computing e Cloud Storage(MELL; GRANCE,

2011) pode suprir essa demanda. Pois esses sistemas trazem benefícios como acesso amplo,
escalabilidade e baixo custo de implantação.
Desenvolver uma arquitetura de Cloud Storage para armazenar arquivos nessa escala, pode
se tornar um grande desafio. Pois, além do desafio tecnológico inerente a natureza desses
sistemas, também existe uma grande necessidade de se entender seu contexto de negócio.
Este trabalho visa analisar o negócio de armazenamento de arquivos através de cloud
storage, para obter insumos e projetar uma arquitetura escalável e segura para armazenar
arquivos.
1.1 Definição do problema

O problema que se pretende resolver neste trabalho é projetar uma arquitetura
para armazenamento de arquivos de forma elástica, escalável e segura. Para apoiar esse
desenvolvimento, pretende-se responder duas perguntas:
• Quais são os direcionadores de negócio para o uso de Cloud Storage?
• Como projetar uma arquitetura que atenda esses contexto?

Seção 1. Introdução 14
1.2 Metodologia
Para desenvolver este trabalho, a seguinte metodologia foi utilizada:
• Foi feita uma revisão exploratória da literatura, com o objetivo de encontrar os

direcionares de negócio de cloud storage, assim como técnicas que poderiam ser
utilizadas para projetar a arquitetura;
• Das informações obtidas sobre o contexto de negócio, foram levantados os atributos

de qualidades assim como os requisitos para o sistema;
• Com as técnicas encontradas na revisão, foi projetada uma arquitetura para atender
os requisitos e atributos de qualidade.
• Com a ajuda de uma metodologia de avaliação de arquitetura, esse trabalho foi

validado;
1.3 Fora do escopo

Os seguintes tópicos foram excluídos do escopo para esse trabalho:
• Requisitos e necessidades relativas ao cloud broker (BOHN et al., 2011)
• Serviços e features na arquitetura que não estão diretamente ligadas com o armaze-
namento, tais como indexação e busca, APIs externas, entre outros.
• Implementação da arquitetura.
• Questões de tarifação (billing).
• Planos de negócio para sistema de Cloud Storage.
1.4 Estrutura da dissertação

O restante da dissertação estará organizada da seguinte forma:
• Na Seção 2 é feita uma contextualização sobre Cloud Storage e trabalhos relacionados.
• Na Seção 3 são levantados os direcionadores de negócio de cloud storage.
• Na Seção 4 é apresentada a arquitetura projetada.
• Na Seção 5, a avaliação da arquitetura é executada.

Seção 1. Introdução 15
• Na Seção 7 são apresentadas as conclusões do trabalho e são levantadas possibilidades

para trabalhos futuros.
• Finalmente no Apêndice A é mostrada as tabelas que apoiaram as decisões dos

principais atributos de qualidade da Seção 3.
16
2 Contextualização e Trabalhos Relaciona-

dos
Esta seção visa apresentar uma visão geral de cloud storage, com o objetivo de
definir o conceito de cloud computing, cloud storage e backup online, bem como fazer um
levantamento histórico de sua origem até o estado atual da arte. Além disso, tem o objetivo
de discutir e analisar alguns trabalhos que se relacionam com este.
2.1 Cloud Computing

Antes de estudar cloud storage, é importante ter uma visão geral dos conceitos de
cloud computing, ou computação em nuvem. Uma breve visão histórica e contextual de
cloud computing será feita nesta seção.
2.1.1 História de cloud computing

Apesar de ter ganhado destaque nos últimos anos, o conceito de cloud computing
não pode ser considerado recente. Em 1950, o cientista da computação Herb Grosh (CRUZ,
2004) postulou que o mundo inteiro operaria em “terminais burros” que seriam servidos
por aproximadamente 15 clusters de computadores.
Mais tarde, em 1961, Dalakovi (2014b) sugeriu num discurso que a tecnologia de comparti-
lhamento de processamento levaria a um futuro cujo poder computacional ou até aplicações
poderiam ser vendidas como um serviço, tal como energia ou eletricidade. Em 1962, J.C.R
Licklider (DALAKOVI, 2014a) descreveu um conceito de uma “Rede Intergaláctica de
Computadores”, antes de fazer parte da Agência de Projetos de Pesquisa Avançada (
Advanced Research Project Agency - ARPA), que pode ser considerada como a origem da
internet. Nesta rede, usuários poderiam rapidamente localizar e acessar dados e softwares
dentro dela e poderiam migrá-las caso necessário. Este conceito descreve não só a Internet
como conhecemos hoje, mas também um dos princípios de cloud computing.
Em 1966, Douglas Parkhill, em seu livro “The Challenge of the Computer Utility”
(PARKHILL, 1966) descreveu o provisionamento de poder computacional de forma elástica
e infinita. Apesar da ideia de cloud computing ter surgido há mais de 50 anos atrás, o termo
só veio surgir no ano de 1997 quando Ramnath Chellappa publicou o trabalho chamado
“Intermediaries in Cloud Computing: A New Computing Paradigm” (CHELLAPPA, 1997).
Em 1999 surgiu o SalesForce, a primeira aplicação entregue ao usuário usando o conceito de
software como um serviço de forma escalável e de rápido provisionamento (SALESFORCE,
2000).
Seção 2. Contextualização e Trabalhos Relacionados 17
Em 2002, a Amazon lança a plataforma Amazon Web Service (AMAZON, 2014b), que
disponibiliza serviços como computação e armazenamento em larga escala como um serviço.
Posteriormente, em 2006, seria lançado o Amazon Elastic Cloud Computing (AMAZON,
2014a), um marco para cloud computing, sendo o primeiro serviço no modelo Infrastructure
as a Service (IaaS).
Outro grande aspecto relevante do cloud computing foi em 2009, quando a chamada Web
2.0 apresentou uma grande evolução e a Google, assim como outras organizações, começou
a oferecer aplicações baseadas em browser através de serviços como o Google Apps.
Posteriormente, ainda surgiram novas ferramentas baseadas em cloud computing das quais
podemos destacar Heroku1 , Azure2 , Digital Ocean3 , Cloud Foundry4 , entre outros.
2.1.2 Definição de Cloud Computing

De acordo com o NIST citeMell2011, Cloud Computing pode ser introduzido com
a seguinte definição que foi traduzida livremente:
“Computação em Nuvem é um modelo que proporciona um acesso de rede

ubíquo, conveniente e sob demanda, para uma reserva compartilhada de
recursos computacionais (ex: rede, servidores, armazenamento, aplicações
e serviços) que pode ser rapidamente providas e liberadas com um esforço
mínimo de configuração ou mínima interação com o provedor de serviços.
Este modelo é composto por cinco características essenciais, três modelos de
serviços e quatro modelos de implantação.”
Dentro da definição apresentada acima, é importante destacar alguns elementos. O compar-

tilhamento de recursos viabiliza que um recurso computacional ocioso para um usuário seja
utilizado por outros, conforme necessidade. Também é importante frisar que a expansão ou
encolhimento da nuvem, deverá ser feita conforme a necessidade e com o mínimo possível
de esforço do administrador. Isso viabiliza aplicativos e serviços que outrora dependeriam
de toda uma infraestrutura para operar.
Ainda de acordo com o NIST, a Cloud Computing tem cinco características essenciais. São
elas:
• Auto serviço sob demanda: Um cliente pode prover unilateralmente capacidade

computacional sem necessidade de interação humana com cada serviço.
1 https://www.heroku.com/
2 http://azure.microsoft.com
3 https://www.digitalocean.com/
4 http://cloudfoundry.org/index.html
• Acesso de rede amplo: Capacidades são disponibilizadas sobre a rede e acessadas

por mecanismos padrões que promovem o uso por uma plataforma heterogêneas de
clientes. Elas podem variar desde de telefones celulares a estações de trabalho.
• Reserva de recursos: Os recursos computacionais do serviço são agrupados para

servir múltiplos consumidores, sendo dinamicamente realocadas de acordo com a
demanda. Geralmente o cliente não tem controle ou informações sobre a localização
exata do recurso computacional em uso. Porém, pode haver a possibilidade de
especificar esse tipo de informação dentro de uma macro região.
• Elasticidade rápida: Capacidade computacional pode ser provida e liberada, em

alguns casos, automaticamente, para rapidamente escalar dependendo da demanda.
Para o consumidor, a capacidade disponível frequentemente parece ser ilimitada e
pode ser adquirida em qualquer quantidade e a qualquer hora.
• Serviço instrumentado: Sistemas em nuvem automaticamente controlam e otimi-

zam o uso de recursos através de instrumentação da capacidade computacional. O
uso de recursos pode ser controlado, monitorado e reportado, provendo transparência
tanto para o usuário quanto para o provedor.
O termo computação pode ter diversos significados, desde utilização de hardware a execução
de um aplicativo específico. Por esse motivo, foram criados os distintos modelos de serviços,
que agrupam o que pode ser entregue como serviço. O modelo SPI, que significa Software,
Platform, Infrastructure, é utilizado para classificar os sistemas de cloud computing de
acordo com o tipo de serviço, como se segue:
• Software as a Service (SaaS): O provedor disponibiliza aplicações que são

executadas em uma infraestrutura de cloud computing. Geralmente, essas aplicações
são utilizadas em um modelo de pagamento por uso e são acessíveis a vários clientes
tanto através de um “terminal burro”, como um browser ou por meio de um software
cliente. O cliente não tem controle sobre a infraestrutura usada pela aplicação.
• Platform as a Service (PaaS): O provedor disponibiliza uma plataforma capaz

de executar programas desenvolvidos ou adquiridos pelo cliente, que foram criados
utilizando linguagens de programação, bibliotecas, serviços e ferramentas suportadas
pelo provedor. O cliente não tem controle sobre a infra-estrutura utilzada pela
aplicação.
• Infrastructure as a Services(IaaS): O provedor disponibiliza para o cliente

processamento, armazenamento, rede e outros recursos computacionais básicos, nos
quais o cliente pode implantar e executar qualquer tipo de software, que inclui sistemas
operacionais e aplicações. O cliente não tem controle total sobre a infraestrutura
que é utilizada, mas gerencia recursos como armazenamento, sistema operacionais e

aplicações em execução.
A Figura 1, extraida de Shivakumar (2014) ilustra os diferentes níveis dos modelos de

serviços, com alguns exemplos de ferramentas em cada nível de serviço. Quanto maior o
nível de abstração, maior o julgamento de valor sobre o serviço que está sendo adquirido e
também menor o controle sobre a infraestrutura em uso.
Figura 1 – Modelos de Serviços
Fonte: Infosys Blogs
Ainda de acordo com o NIST, podemos classificar os sistemas de cloud computing

de acordo com o modelo de implantação. Como se segue:
• Nuvem privada: A infraestrutura é fornecida para uso exclusivo de uma única

organização composta de múltiplos consumidores. Pode pertencer, ser gerenciada e
operada pela própria entidade, por um terceiro ou alguma combinação entre eles.
• Nuvem comunitária: A infraestrutura é fornecida para uso exclusivo de uma

comunidade de consumidores que tem preocupações semelhantes (por exemplo,
missão, restrições de seguranças, entre outros). Pode pertencer, ser gerenciada e
operada por uma ou mais das organizações que fazem parte da comunidade, um
terceiro ou alguma combinação entre eles.
• Nuvem pública: A infraestrutura é fornecida para uso aberto do público em geral.

Pode pertencer, ser gerenciada e operada por uma organização de negócios, acadêmica
ou governamental, ou alguma combinação entre eles.
• Nuvem híbrida: A infraestrutura é composta por duas ou mais nuvens, que conti-
nuam únicas mas são interligadas de forma que se permita a portabilidade de dados
e aplicações.
2.2 Cloud Storage

Uma vez que foi entendida a idéia de cloud computing e suas principais caracte-
rísticas, vamos introduzir e analisar conceitos, requisitos e técnicas envolvidas com cloud
storage.
2.2.1 História do armazenamento em rede

Até o início da década de 1980, os computadores armazenavam dados apenas
em sistemas de arquivos locais, diretamente conectados àquelas máquinas. Porém, em
1982, Brownbridge conseguiu demonstrar o acesso remoto através de várias estações Linux
(BROWNBRIDGE; MARSHALL; RANDELL, 1982), introduzindo assim o conceito da
chamada Network Attached Storage (NAS).
Em 1983, é lançado o sistema operacional NetWare Server com o protocolo NCP (NO-
VELL, 2014), que permitia servidores compartilharem arquivos, impressoras, diretórios,
comandos remotos, entre outros recursos computacionais.
Em 1984, a Sun desenvolve o NFS (SANDBERG, 1986), que permitiria que servidores
compartilhassem seu espaço de armazenamento com terminais clientes.
Em 1985, a 3Com lança o 3Server, o primeiro servidor direcionado para armazenamento,
que incluía software e hardware proprietários, e discos múltiplos.
Em 1988, é publicado o artigo “A Case of redundant arrays of inexpensive disks (RAID)”
(PATTERSON; GIBSON; KATZ, 1988), que sugeria combinar vários discos baratos, com
capacidade limitada, em uma matriz de forma a aumentar a performance e a confiabilidade
dos discos. Este trabalho, juntamente com o Fibre Channel viabilizou as chamadas Storage
Area Network (SAN) (SNIA, 2014).
No início dos anos 90, impulsionados pelo sucesso dos servidores de arquivos de empresas
como Novell, IBM e Sun, várias empresas passaram a construir servidores de arquivos
dedicados. Ainda nessa época, a Microsoft lança o New Technology File System (NTFS)
que permite a um computador acessar uma unidade de armazenamento remota, da mesma
forma que um armazenamento local.
Em 2000, as agências do governo dos EUA começam a desenvolver sistemas de computação
em grid de forma que permitam usuários compartilhar recursos sem necessidade de um
controle central.
No início da década de 2000, algumas companhias começaram a oferecer soluções de NAS
em forma de cluster, aumentando ainda mais a confiabilidade e performance dos sistemas de
backup online. Em 2007, um aluno do MIT, Drew Houston lança o Dropbox (DROPBOX,
2014). Serviço que passaria a vender backup e cloud storage como uma mercadoria, num
modelo utilizado até os dias atuais.
2.2.2 Definindo cloud storage

Cloud storage nada mais é que um caso especial de Cloud Computing com um
propósito específico de armazenar dados.
Dessa forma, baseado na definição dada pelo NIST, podemos definir Cloud storage como
"um modelo que proporciona o armazenamento de dados de forma ubíqua, conveniente
e sob demanda a partir de uma reserva de armazenamento compartilhada que pode ser
rapidamente disponibilizada com o mínimo de esforço de configuração ou interação com o
provedor de serviços."
Assim como nos sistemas de cloud computing, as cinco características são aplicáveis ao cloud
storage (auto-serviço sob demanda, acesso de rede amplo, reserva de recursos, elasticidade
rápida e serviço instrumentado).
Além disso, os três modelos de serviços também se aplicam ao cloud storage. É possível a
um cliente adquirir armazenamento como um software, como uma aplicação de backup e
sincronização; como uma plataforma, no caso em que o provedor oferece, por exemplo,
um banco de dados relacional ou não; ou mesmo como infraestrutura, quando o provedor
oferece armazenamento bruto, que seria um disco virtual para que o usuário armazene
documentos, dados de aplicativos ou qualquer outro tipo de dados.
2.2.3 Aplicações de cloud storage

De acordo com SNIA (2013), os sistemas de Cloud Storage podem ter várias
aplicações dependendo dos objetivos das organizações que as utilizam. Seguem alguns dos
principais cenários:
• Backup - Em qualquer organização dados críticos têm que estar seguros, disponíveis
e recuperáveis para uma versão prévia. Um sistema de cloud storage pode substituir
as soluções tradicionais de backup, como por exemplo, fitas magnéticas, sendo uma
forma mais segura, barata e prática de armazenamento de backups.
• Arquivamento - As organizações estão cada vez sendo mais forçadas a reter volumes
maiores de dados por longos períodos. Assim como no backup, os sistemas de Cloud
Storage podem substituir as formas tradicionais de arquivamento reduzindo custos e
aumentando a agilidade da recuperação de informação.
• Armazenamento de dados de aplicativos - Aplicações de negócios requerem

armazenamento temporário e permanente, que geralmente é disponibilizado por discos
ou soluções de armazenamento em rede como NAS ou SAN. Dados de aplicativos

têm requisitos mais críticos de acesso e latência. Uma solução de cloud storage pode
trazer vantagem em relação a essas soluções tradicionais, tais como facilidade de
backup de aplicativos, redução de custos, entre outros.
2.3 Trabalhos Relacionados

Nesta seção, serão apresentados alguns trabalhos que se relacionam com este
trabalho, pois se tratam de sistemas de cloud storage, que foram ou estão sendo utilizados
tanto na academia quanto na indústria. Os trabalhos foram apresentados por ordem de
publicação.
2.3.1 Oceanstore
Oceanstore (KUBIATOWICZ, 2000) é um projeto concebido na Universidade de
Berkley, que visa fornecer uma plataforma aberta e global para armazenamento de dados.
Em sua concepção, foi idealizada para objetivos como servir de plataforma para aplicações
groupware (e-mail, calendário, lista de contatos), repositório de dados de grande volume
para grupos científicos ou como servidor para streaming.
A plataforma Oceanstore tem duas premissas: ser construída a partir de um grande
grupo de servidores não confiáveis, pois equipamentos quebram sem advertência e não
se pode confiar a durabilidade de um dado aos mesmos; a segunda premissa é que os
dados são nômades, pois em um sistema de grandes proporções a localidade dos dados é
muito importante. O Oceanstore faz cache dos dados em várias localidades para manter a
escalabilidade do sistema, abrindo mão da consistência dos dados.
Cada objeto no OceanStore é armazenado com um nome único gerado pseudo-aleatoriamente,
chamado GUID (Global Unique Identifier). Alguns GUID funcionam como um diretório,
contendo uma lista de GUID’s, dando a possibilidade da criação de uma estrutura seme-
lhante a uma árvore.
O controle de acesso é feito em basicamente duas operações: restrição de leitura e restrição
de escrita.
Cada objeto que não é público, é encriptado com uma chave única. Cada usuário que tem
permissão de leitura, recebe essa chave para desencriptar. Para revogar o acesso em dado
objeto, as replicas são reencriptados com uma nova chave.
Para prevenir escritas não autorizadas, cada escrita é assinada digitalmente e cada objeto
tem uma lista de controle de acesso indicando quem pode alterar aquele objeto. A restrição
de escrita é feita pelo server que verifica se o usuário que tenta escrever naquele objeto
tem acesso ao mesmo.
Cada objeto armazenado no OceanStore pode ter uma réplica em qualquer servidor. Para
localizar esses objetos, conta com dois algoritmos. O primeiro, é um algoritmo probabilístico
e rápido, que toma a premissa que existe uma grande probabilidade de um dado acessado
frequentemente residir em um servidor próximo. O segundo é um algoritmo hierárquico
mais lento, porém mais confiável.
2.3.2 Windows Azure Storage

Windows Azure Storage (CALDER et al., 2011), ou WAS é o sistema de Cloud
Storage da Microsoft, que está em produção desde o final de 2008.
O WAS armazena dados em três formatos: BLOBs, tabelas ou filas para entrega de
mensagens. O projeto do WAS, levou em consideração pedidos de vários clientes, que
direcionou algumas decisões de projeto. Entre elas estão consistência forte, armazenamento
global e escalável, recuperação de desastres, armazenamento multi-tenant.
O WAS roda em múltiplos servidores espalhados ao redor do mundo. Ele possui uma
camada que provê gerenciamento de nós, monitoramento da status, e implantação do
serviço para o sistema. Essa camada é chamada de Fabric Controller.
Os nós de armazenamento do Windows Azure estão organizados em clusters, denomidados
Storage Stamp, que são gerenciados pelos Location Service, que é um servidor localizado
em uma dada localização, como Europa, América do Norte e Ásia.
Existem dois engenhos de replicação dentro do WAS, o chamado Intra-Stamp, que é
responsável pela replicação dentro do cluster de armazenamento, e o Inter-Stamp, que
armazena dados de um Stamp para outro, para uma recuperação em caso de desastre.
2.3.3 Google File System

O Google File System (GHEMAWAT; GOBIOFF; LEUNG, 2003), ou GFS é
um sistema de arquivos distribuído que foi desenvolvido para satisfazer a demanda de
armazenamento e processamento de dados do Google.
Assim como no OceanStore, a arquitetura do GFS assume que servidores não são confiáveis.
O sistema de arquivo é formado por uma grande quantidade de hardware barato. Além
disso, assume-se que arquivos são naturalmente grandes. Toda a otimização existente no
GFS foi feita para arquivos grandes. O GFS também assume que arquivos são modificados
anexando-se dados no fim dos mesmos.
O GFS suporta as operações usuais em sistemas de arquivos, tais como criação, deleção,
abertura, fechamento, leitura e escrita de arquivos. Contudo, ele ainda introduz duas novas
operações: inserção, em que se escreve no fim do arquivo, e snapshot, operação que cria
uma cópia do arquivo com um custo muito baixo.
No GFS, ao contrário do OceanStore, existe um servidor central, denominado servidor
mestre e vários outros servidores de chunks 5 . O servidor mestre sabe da existência de
todos os outros servidores e é responsável pelo armazenamento de metadados, que são os
5 Chunks são pequenos pedaços dos quais se compões um arquivo, registro, ou qualquer unidade de armazenamento
arquivos, os chunks que compõem cada arquivo e a localização de cada chunk. O servidor
mestre armazena todos os metadados em memória.
Cada arquivo é composto por chunks de 64MB, e eles são armazenados no sistema de
arquivo local dos chunk servers.
Os chunks são replicados de acordo com a necessidade. Existe um controle para que chunks
novos não criem muitas réplicas, para evitar sobrecarga na escrita de novos arquivos. O
controle da replicação do GFS é feito através do mestre.
2.3.4 Ustore
Ustore (DURãO et al., 2013) é uma plataforma de Cloud Storage em nuvem privada
desenvolvido para armazenar arquivos, fazendo backup e sincronização deles.
Uma diferença marcante na plataforma Ustore é que ele pode utilizar discos ociosos das
máquinas de uma corporação, formando uma nuvem privada com as estações de trabalho.
Para que as estações se comuniquem, é utilizado uma rede overlay peer to peer (P2P), que
implementa o protocolo conhecido como JXTA6 .
A arquitetura do Ustore leva em consideração quatro atributos de qualidade como pilares
de suas decisões arquiteturais, que são: escalabilidade, otimização das interações, disponi-
bilidade e segurança.
Na rede overlay existe um tipo de peer especial que tem a responsabilidade de configurar
a rede e manter rotas entre estações diferentes. Esse peer é chamado de Super Peer, e
precisa ser mantido em um servidor conhecido por todos os peers, como uma espécie de
servidor central. Porém, sua úncia função é manter a conectividade entre os peers.
Além da existência do superpeer, existem os chamados peers servidores, que implementam
uma gama de serviços e são localizados pelos peers clientes, através do anúncio de seus
serviços na rede JXTA.
Finalmente os simple peers, ou apenas clientes, que são peers que são utilizados para
enviar ou recuperar arquivos da nuvem, assim como utilizar o espaço ocioso na máquina
do usuário para salvar arquivos de outros usuários.
A replicação no Ustore se dá através de um algoritmo estatístico, em que se registra o
histórico de conexão de cada cliente, traçando assim um perfil do mesmo. As replicados dos
backups são enviados a outros clientes que têm perfil semelhante ao do usuário, otimizando
assim a disponibilidade do arquivo, mantendo um número mínimo de réplicas.
6 https://jxta.kenai.com/
25
3 Cloud Storage Business Drivers
Nesta seção será feita uma análise nos direcionadores de negócio de Cloud Storage,
e a partir daí serão desenvolvidos os business drivers. A partir dos business drivers, é
possível obter insumos para pautar as decisões arquiteturais, tais como os Requisitos do
sistema, assim como os principais atributos de qualidade.
Esses insumos também serão úteis para, durante a avaliação da arquitetura, verificar a
conformidade dessa com as necessidades de negócio.
3.1 Definição do Negócio

Embora cloud storage ja tenha sido definido anteriormente, é necessário ressaltar
que o conceito de armazenamento em nuvem é bastante abstrato. Neste trabalho, os
esforços serão concentrados em sistemas de armazenamento de arquivos.
Deseja-se utilizar a elasticidade da nuvem para armazenar arquivos, garantindo fatores
como a disponibilidade, segurança, escalabilidade e acesso ubíquo aos dados armazenados
pelos usuários, para uso de backup, sincronização de arquivos ou arquivamento.
Esta solução irá representar duas das maiores tendências na Tecnologia da Informação
(MARSTON et al., 2011) a eficiência tecnológica, pois o poder computacional é melhor
utilizado através de recursos de hardware e software escaláveis e agilidade de negócio,
que possibilita empresas pequenas ou em estágio inicial, ter acesso a um elevado poder
computacional.
Em Grossman (2009), ENISA (2009) e Aljabre (2012) é possível observar algumas das
principais vantagens e desvantagens da adoção de Cloud Computing por empresas. A partir
delas, foi possível observar também sua aplicabilidade para Cloud Storage.
3.1.1 Principais Vantagens
• Acesso ubíquo - Provedores de serviços de armazenamento em nuvem podem

disponibilizar várias interfaces de acesso diferentes para seu serviço, possibilitando,
assim, aos usuários, acesso aos dados através de formas e dispositivos distintos.
• Redução de custos - Organizações podem ter acesso a recursos computacionais

com custo reduzido, uma vez que essas aplicações usufruem dos recursos que está
na nuvem do provedor do serviço. Essa redução de custos engloba aquisição e
manutenção tanto de hardware como de software.
Seção 3. Cloud Storage Business Drivers 26
• Habilidade de crescimento sob demanda - É possível para um pequeno negócio

usar Cloud Computing, com um pequeno custo, e com o crescimento do negócio,
aumentar a capacidade computacional sob demanda.
• Efetividade computacional - É possível prover serviços, continuidade e segurança

mais efetivamente do que soluções tradicionais de TI.
• Escalabilidade - Arquiteturas em Cloud Computing mostram-se amplamente esca-

láveis (GROSSMAN, 2009).
• Concentração de recursos -O compartilhamento de hardware físico proporciona

uma perimetrização mais barata assim como um controle de acesso físico mais
eficiente.
3.1.2 Principais Desvantagens e Ameaças

A adoção de cloud storage pode apresentar um conjunto de benefícios, conforme
apresentado anteriormente. Entretanto, é relevante se considerar os pontos fracos, ameaças
e preocupações relativas ao uso de cloud storage. A lista abaixo apresenta algumas das
principais desvantagens de utilizar um serviço de nuvem para armazenamento.
• Perda de governança das informações - Em se utilizando do serviço da nuvem

para armazenamento, o cliente está cedendo ao provedor de serviço controle sobre
informações de sua empresa. Alguns sistemas de Cloud Storage, como o Mega
(SECURITY, 2013), armazenam de forma que somente o proprietário do conteúdo,
ou alguém com sua permissão, possa acessar aquele conteúdo.
• Vínculo com o serviço - Uma vez que um usuário adota um serviço de armazena-
mento em nuvem, mudar para outro provedor de serviço, ou voltar para abordagens
tradicionais de armazenamento pode tornar-se inviável devido ao grande número de
dados armazenados.
• Segurança - Apesar de armazenamento em nuvem ter um nível de segurança

satisfatório, sempre existe um risco permanente da mesma ser exposta, e dados de
uma organização sejam acessados por pessoas não autorizadas.
• Dependência de conectividade - Para se acessar um serviço de armazenamento

em nuvem, é necessário uma conexão de rede com o provedor do serviço. A perda
dessa conexão, implicará na impossibilidade temporária de acesso a dados, que
podem ser críticos.
• Indisponibilidade dos serviços - Apesar dos sistemas de cloud storage terem

um nível de disponibilidade bem alto, uma eventual disponibilidade do sistema,
pode impedir temporariamente dados cruciais. Assim como em qualquer sistema de

armazenamento de dados.
• Compartilhamento de recursos - Apesar do compartilhamento de recursos ser

um benefício, por trazer redução de custos, também pode ser uma preocupação em
relação a confidencialidade e segurança. Principalmente em um ambiente de nuvem
pública, onde várias organizações compartilham o mesmo recurso.
3.1.3 Identificação dos Principais Stakeholders

Para desenvolver uma arquitetura para um sistema precisamos identificar o prin-
cipais envolvidos com o mesmo e suas devidas necessidades. De acordo com Bohn et al.
(2011), podemos listar os seguintes stakeholders para qualquer sistema de Cloud Computing:
• Cloud Consumer - São pessoas ou organizações que mantêm um relacionamento

e usam os serviços de um Cloud Provider. No nosso caso, são os indivíduos ou
corporações que utilizam o sistema de Cloud Storage para armazenar arquivos. Eles
necessitam de uma ferramenta para fazer backup e sincronização de arquivos online.
• Coud Provider - Uma pessoa, grupo ou entidade responsável por manter o serviço
disponível para as partes interessadas. No caso do sistema de Cloud Storage, que
hospedaria e manteria o sistema de cloud storage. Além do serviço em si, também
precisa de um módulo em que possa administrar, mensurar e manter o serviço.
• Cloud Auditor - Uma organização que pode conduzir uma auditoria independente
dos serviços de cloud, das operações, performance e segurança da implementação da
cloud. Devem possuir ferramentas que se possa mensurar um grupo de métricas para
se realizar essas auditorias.
• Cloud Broker - Uma entidade que gerencia o uso, performance e entrega dos
serviços de cloud, e negocia a relação entre Cloud Provider e Cloud Consumer. Têm
a necessidade de um módulo que possa gerenciar a nuvem, mensurar o uso e taxar
os usuários.
• Cloud Carrier - Uma organização intermediária que provê conectividade e trans-

porte de serviço de Cloud Providers para Cloud Consumers. Tipicamente são os
provedores de internet.
Para o escopo desse trabalho, serão focadas as necessidades relacionadas aos grupos de
Cloud Consumers, que serão chamados de usuários finais, ou apenas usuários, e os Cloud
Providers, que serão denominados de provedores de serviços.
3.1.4 Restrições do negócio

Adicionalmente, para o desenvolvimento de qualquer arquitetura, é imperativo se
observar as restrições que o negócio impõe ao software. Em Khajeh-Hosseini et al. (2012)
são apresentadas algumas dessas restrições que pode afetar um sistema de cloud computing.
Dentre elas, destacamos algumas:
• Custos - O custo de utilização ou implantação de um sistema de cloud storage não

pode ter um impacto financeiro considerável, seja relativo ao custo de implantação
de uma nuvem privada interna, ou à aquisição do serviço através de um provedor.
• Mudanças organizacionais - O processo de mudança para utilização de soluções

em nuvem ocasionará em um impacto organizacional. O tipo de mudança varia de
organização para organização. Alguns tipos de mudanças que podem ocorrer são em
relação à contabilidade, segurança, geografia, suporte e até ao trabalho dos usuários
finais.
3.1.5 Restrições técnicas

Assim como no caso das restrições de negócio, é relevante listar as restrições
técnicas para evitar surpresas no desenvolvimento de uma arquitetura. Algumas delas são
encontradas em sistemas de cloud storage:
• Teorema de Brewer - Conhecido também como teorema do CAP, foi demonstrado

em Gilbert e Lynch (2002) e prova que não é possível em um sistema computacional
manter a consistência, disponibilidade e a tolerância à partição simultaneamente.
Isso é de grande relevância para sistemas de cloud storage, dado que a disponibilidade
é essencial, e geralmente se opta entre a consistência e a tolerância à partição.
• Limitação do hardware - Apesar de elástico, o volume armazenado por um

sistema de cloud storage é limitado pelo armazenamento do hardware (físico ou
virtual) que o hospeda. Assim como sua largura de banda será limitada pela banda
da comunicação entre o usuário e o provedor do serviço.
• Acordo de nível de serviço (Service Level Agreement - SLA) - É uma

parte do contrato entre o provedor de serviço e o usuário que estabelece métricas
mínimas para o funcionamento do serviço. São exemplos de métricas comuns de SLA
para serviço de armazenamento em nuvem a disponibilidade, o tempo de resposta,
taxa de erros, entre outras.
3.2 Atributos de Qualidade

Em um sistema computacional, as funcionalidades são fundamentais. Pois a partir
das necessidades dos usuários, surge a demanda para o software. Contudo, os atributos de
qualidade também são relevantes para guiar as decisões arquiteturais.
A qualidade de software pode ser avaliada pelo grau em que o software possui de combinação
dos atributos de qualidade, que são características importantes e devem ser priorizadas no
desenvolvimento do software. Existem várias formas de se expressar atributos de qualidade,
tais como funcionalidade, negócio, segurança, entre outras.
A norma ISO/IEC 25010.2 (ISO/IEC, 2010) define um modelo de qualidade de produto
que é composto por oito características que relatam tanto propriedades estáticas, quanto
dinâmicas de um sistema de computação.
A Figura 2 mostra o modelo de qualidade de software apresentado na norma. Ela divide
a qualidade de software em oito características que são adequação de funcionalidade,
confiabilidade, eficiência de performance, operacionalidade, segurança, compatibilidade,
manutenibilidade e transmissibilidade. Essas características são subdivididas em trinta e
oito sub-características que auxiliam na descrição da qualidade de um software.
Figura 2 – Atributos de Qualidade
Fonte: ISO/IEC 25010.2
3.2.1 Metodologia
Para definir os atributos de qualidade, a seguinte metodologia foi utilizada: Por
meio de revisão bibliográfica foram levantadas as principais vantagens da utilização de
cloud storage as desvantagens, preocupações e ameaças. Além disso, também foram listados
segundo a norma ISO/IEC 25010, os principais atributos de qualidade de um produto de
software.
Em seguida, foi feita uma matriz, cujas colunas representam as vantagens e desvantagens,
enquanto as linhas representam os atributos de qualidade. Essa matriz foi preenchida com
o valor um, caso a presença do atributo de qualidade contribua para uma das vantagens ou
amenize uma desvantagem, ou zero caso contrário. Dessa forma, foi possível selecionar os
atributos de qualidade de forma que se possa maximizar os benefícios e atenuar as perdas,
selecionando os atributos de qualidade com maior número de 1s seriam considerados os
prioritários.
3.2.2 Resultados
Os atributos de qualidade foram enumerados de acordo com as Tabelas 3 e 4
disponíveis no Apêndice A. Como se pode observar, os principais atributos de qualidade
eleitos estão de acordo com a Tabela 1.
Tabela 1 – Atributos de Qualidade escolhidos
ID Nome
Q1 Disponibilidade
Q2 Utilização de recursos
Q3 Confidencialidade
Q4 Não-repúdio
Q5 Autenticidade
Q6 Portabilidade
Q7 Adaptabilidade
A ordem dos atributos não necessariamente representa a ordem de prioridade nas

definições arquiteturais.
Se analisarmos a lista de atributos, podemos observar que precisamos de um sistema que
mantenha-se o maior tempo possível online (Q1), que tenha o menor custo possível (Q2),
que seja seguro (Q3, Q4 e Q5) e possa ser facilmente instalado em qualquer ambiente (Q6
e Q7).
3.3 Requisitos
Em um sistema de software, além dos atributos de qualidade, os requisitos também
guiam as decisões arquiteturais. De acordo com Sommerville (2007), o verdadeiro teste de
uma arquitetura recai sobre quão bem ela atende os requisitos funcionais e não-funcionais
depois de implantada.
Para a definição de requisitos funcionais e não-funcionais neste trabalho, foram observadas
as principais ferramentas de backup em nuvem, tais como o Dropbox (DROPBOX, 2014),
SugarSync (SUGARSYNC, 2014), Google Drive (GOOGLE, 2014), Onedrive (MICRO-
SOFT, 2014), entre outros. Além disso, tais requisitos foram revistos por analistas com
experiência na indústria nesse segmento. A partir daí, foi possível listar os seguintes
requisitos funcionais e não-funcionais:
• R1 - Upload (backup) de arquivos

O usuário final pode enviar arquivo para seu drive virtual na nuvem. Uma vez que
esse arquivo é enviado para nuvem, deverá permanecer até que o usuário decida
excluir ou modificar aquele arquivo. O usuário poderá enviar arquivos para nuvem
de múltiplos dispositivos de forma ubíqua.
• R2 - Download (restore) de arquivos

Uma vez que um usuário tenha enviado um arquivo para o seu drive virtual, a
qualquer momento, desde que tenha conectividade com o sistema, ele pode recuperar
e baixar aquele arquivo, de qualquer dispositivo que ele tenha acesso ao sistema.
• R3 - Exclusão de arquivos
O usuário pode excluir arquivos que tenham sido previamente salvos na nuvem. Não
se pode fazer download de arquivos excluídos. Uma vez que o arquivo tenha sido
deletado, o usuário pode recuperá-lo dentro de um período definido pelo provedor
do serviço.
• R4 - Compartilhamento de arquivos
O usuário pode compartilhar qualquer arquivo ou diretório dentro de seu disco
virtual. Este processo em uma pasta será recursivo. Ou seja, uma vez que uma pasta
tenha sido compartilhada, qualquer arquivo ou subpasta também o será. A qualquer
momento o proprietário do arquivo poderá revogar o acesso àquele arquivo ou pasta.
• R5 - Publicação de arquivos
Assim como um usuário pode compartilhar arquivos, ele também pode publicá-los,
garantindo acesso aos arquivos compartilhados para todos os usuários da nuvem.
Assim como no compartilhamento, a qualquer momento o proprietário pode revogar
acesso aos arquivos.
• R6 - Pesquisa de arquivos
O usuário pode pesquisar arquivos dentro de seu disco, seja por nome de arquivos,
seja pelo conteúdo dos arquivos.
• R7 - Cadastro de usuários
O provedor de serviços terá acesso a um cadastro de usuários, que permitirá incluir,
modificar ou remover usuários. Também será possível habilitar uma funcionalidade
para que o próprio usuário efetue seu cadastro.
• R8 - Tarifação de usuários
O provedor de serviços terá ferramentas que possa mensurar a utilização da nuvem,
para que possa taxar o usuário de acordo com os termos de serviços estabelecidos
entre as partes.
• R9 - Expansão ou encolhimento da nuvem

O provedor de serviços deverá ser capaz de aumentar ou diminuir a capacidade da
nuvem, seja através de software, ou mesmo através da adição de mais hardware para
sua nuvem.
• R10 - Tempo de resposta

O sistema deve manter um tempo de resposta de acordo com o SLA firmado no
contrato com usuário. Não podemos estipular um valor exato, uma vez que, esse
valor depende do valor contrato entre usuário e provedor.
• R11 - Disponibilidade
O sistema deve manter-se disponível por um período igual ou superior àquele firmado
no SLA entre usuário e provedor. É importante observar que alguns contratos
estipulam um downtime mínimo para que o serviço possa ser considerado indisponível.
• R12 - Resiliência dos arquivos

O sistema deve se recuperar de eventuais falhas de hardware sem perder os dados
nele armazenados. Mais uma vez, o SLA pode prever exceções para este requisito,
especificando uma taxa máxima de falhas irrecuperáveis que podem ocorrer.
• R13 - Integridade dos dados

Os dados armazenados no sistema não devem sofrer modificações indesejadas, que
venham a corromper os dados armazenados. O SLA poderá especificar uma taxa
máxima de dados corrompidos.
• R14 - Consistência de dados

Mesmo se tratando de um sistema distribuído, o sistema deve manter a consistência
das informações nele armazenadas, havendo apenas uma única versão de um dado
qualquer. Então, se por exemplo, um cliente escreve um arquivo em um nó, ele deve
acessar o mesmo conteúdo em outro nó do sistema.
• R15 - Durabilidade
Uma vez armazenados, os dados contidos no sistema estarão em definitivo, não sendo
excluídos pelo próprio sistema ou fatores externos, salvo se excluído pelo proprietário
do arquivo.
• R16 - Autenticação
Para garantir a segurança do sistema, para toda ação executada pelo sistema, o autor
daquela ação deverá estar devidamente identificado através de credenciais seguras.
• R17 - Autorização
Em adição à Autenticação, para cada ação realizada pelo usuário, deverá se verificar
se ele tem a permissão para executá-la, impedindo assim, ao usuário executar ações
que o mesmo não tem direitos.
• R18 - Auditoria
Cada ação de um usuário, além do mesmo estar devidamente identificado e autorizado,
o sistema também manterá um registro de todas as ações críticas executadas pelo
mesmo. Os requisitos Autenticação, Autorização e Auditoria completam a segurança
do sistema.
• R19 - Interface externa

O sistema deverá prover interfaces para o desenvolvimento de aplicações de terceiros,
que possam usar o armazenamento em nuvem como plataforma, respeitando todos
os requisitos listados anteriormente.
3.4 Conclusão
A partir de uma análise do negócio de cloud storage e backup online, foi possível
estabelecer diretrizes para o desenvolvimento de uma arquitetura de cloud storage para
backup e armazenamento de arquivos.
A partir dos requisitos e atributos de qualidade, é possível tomar decisões arquiteturais de
forma que os satisfazem, priorizando os principais atributos de qualidade.
Além disso, deveremos utilizar os atributos de qualidade na avaliação da arquitetura
proposta, validando assim este trabalho
34
4 Definição da Arquitetura
Nesta seção, será apresentada a arquitetura de software para resolver o problema

proposto. A partir da análise de negócios, temos os requisitos e atributes de qualidade que
deverão ser satisfeitos.
Inicialmente foram documentadas todas as principais decisões arquiteturais para o sistema,
e, tomando essas decisões como diretrizes, a arquitetura foi projetada.
4.1 Decisões arquiteturais

Um conhecido problema em projetos de arquitetura de software é a falta de clareza
nas justificativas sobre o seu projeto. As decisões arquiteturais estão embutidas no projeto
da arquitetura. Desta forma, o conhecimento sobre as decisões arquiteturais é perdido
durante a execução do projeto. Com base nessas informações, Jansen e Bosch (2005)
propõe documentar a arquitetura como um conjunto de decisões arquiteturais.
Decisões arquiteturais podem ser definidas como uma descrição de um conjunto de adições,
subtrações e modificações da arquitetura de software, da linha de raciocínio, das regras e
restrições do projeto e requisitos adicionais que realizam completamente ou parcialmente
um ou mais requisitos do software.
Desta forma, como primeiro passo para projetar a arquitetura proposta, iremos destacar e
justificar as principais decisões arquiteturais.
4.1.1 Orientação a Serviços através de REST

Arquitetura Orientada a Serviços (JOSUTTIS, 2007) ou Services Oriented Archi-
tecture (SOA) (do inglês Software Oriented Architecture) é um paradigma de pensamento
que leva a uma arquitetura concreta. SOA tem como objetivo aumentar a flexibilidade do
negócio.
SOA possui alguns direcionadores, tais como sistemas distribuídos, diferentes provedores
e heterogeneidade. Esses são conceitos que combinam com os drivers de negócio de um
sistema de cloud storage. Além disso, os direcionadores do SOA estão de acordo com os
atributos de qualidades indicados na Seção 3.
Em uma arquitetura orientada a serviços, o software é decomposto em serviços, unidades
lógicas que representam um grupo de funcionalidade de negócios. Os serviços são projetados
de forma a abstrair todo o seu funcionamento interno, de forma que pessoas não técnicas
possam entender o papel do serviço dentro do ecossistema do negócio. Esses serviços
Seção 4. Definição da Arquitetura 35
podem ser heterogêneos, sendo implementados em diferentes tecnologias, em hardwares

diferentes, ou até mesmo em provedores diferentes.
Dados que estes serviços são heterogêneos, é importante que eles se comuniquem facilmente.
Este conceito é chamado de interoperabilidade, e é o segundo conceito de SOA, sendo
o primeiro os serviços.
O último conceito de SOA é o baixo acoplamento, que significa minimizar a depen-
dência entre os serviços. Assim, modificações têm efeitos mínimos e o sistema continua
parcialmente funcional ainda que uma parte do sistema esteja quebrada.
A opção da abordagem SOA ocorreu, entre outros motivos, pelas suas vantagens apre-
sentadas em Oliveira (2014). Dentre elas, as seguintes vantagens podem ser consideradas
relevantes para um sistema cloud storage:
• Baixo acoplamento, que possibilita o funcionamento parcial do sistema, mesmo

em caso da não disponibilidade de algum serviço, além de diminuir o impacto em
modificações nos serviços;
• Reuso, serviços podem ser reutilizados para funções comuns dentro do sistema de
cloud storage. Além disso, serviços existentes podem ser reutilizados em desenvolvi-
mento de novos sistemas de software;
• Manutenibilidade, como consequência do baixo acoplamento, a manutenção do

sistema é feito apenas no serviço que está sofrendo alterações, não havendo modifica-
ções de grande impacto nos demais, agilizando o processo de melhoramento contínuo
do software;
• Interoperabilidade, dado que cada serviço é independente de hardware ou mesmo

de tecnologia de desenvolvimento, mantendo-se uma interface de comunicação bem
definida.
Entretanto, essa opção trará pontos adversos, que deverão ser considerados no restante do
projeto do sistema de software. São elas:
• Aumento da complexidade, visto que cada serviço é executado de forma in-

dependente, a interoperabilidade terá um custo: o maior número de camadas de
software para comunicação entre os serviços; perda de performance, que também é
consequência da complexidade da abordagem SOA. Isso poderá afetar o tempo de
resposta do sistema, que apesar de importante, não é um dos principais atributos de
qualidade do sistema;
• Perda de robustez, pelo fato de que transações podem envolver vários serviços,
nesse caso, não é possível garantir a atomicidade das mesmas. Esse ponto deverá ser
observado nas demais decisões e design da solução;
• Segurança, pode ser um problema relevante, dado que como os serviços executam de
forma distribuída e independente, então um agente malicioso pode se passar por um
serviço e conseguir acesso a informações não autorizadas.
Outro aspecto entre o casamento entre SOA e Cloud Computing pode ser justificado de
acordo com Yang e Zhang (2012) que declara as seguintes afirmações:
• SOA pode ajudar a construir o ambiente de Cloud Computing;
• SOA e Cloud Computing são complementares;
• Cloud Computing fornece uma realização de SOA;
• SOA e Cloud Computing podem se misturar.
Finalmente, na abordagem SOA para o sistema de Cloud Storage, deverá ser imple-
mentado utilizando o padrão de projeto SOA chamado camada de serviços (ERL, 2009),
que consiste em várias camadas de inventários de serviços, que são serviços agrupados por
afinidade. Funciona como o estilo arquitetural em camadas em softwares tradicionais. As
camadas serão apresentadas mais adiante neste mesma Seção.
4.1.2 Persistência
Assim como qualquer sistema, o Cloud Storage precisa persistir dados de forma
organizada. Em um sistema de grande porte, tipicamente se utiliza um banco de dados,
relacional ou não, para armazená-los. Porém, um sistema de cloud storage, por definição,
é utilizado para guardar dados de forma segura e escalável, assim como os sistemas de
gerenciamento de banco de dados.
Logo, optou-se por não utilizar um banco de dados externo para armazenar metadados do
sistema, de forma a reduzir custos e aumentar a portabilidade do sistema. Será utilizado o
próprio ambiente de cloud storage para se guardar tanto os conteúdos dos arquivos, que
serão denominados de dados, como as metainformações sobre o sistema de arquivo, que
serão chamados de metadados.
É comum em sistemas de arquivos distribuídos (DFS) (BžOCH, 2012) subdividir o arma-
zenamento em duas unidades, sendo uma para conteúdo dos arquivos (dados) e outra para
metadados.
Em Subashini S. e Kavitha (2011>) podemos observar um exemplo de utilização de cloud
storage para armazenar metadados de forma eficiente e segura. Nesse trabalho, a segurança
é obtida através da fragmentação de dados sensíveis.
Em Jiang et al. (2012) podemos observar que é possível utilizar um ambiente de cloud para
implementar uma arquitetura de cloud flexível e escalável, abrindo mão da consistência
imediata. Nesses trabalhos, a consistência é atingida através da chamada consistência
eventual, em que os dados salvos no nós distribuídos em um certo intervalo de tempo após
sua inclusão.
Podemos listar as vantagens dessa abordagem. Primeiramente seria a escalabilidade já que
o armazenamento de metadados deverá crescer de acordo com o crescimento do sistema.
Ademais, trata-se de um armazenamento distribuído, por isso elimina pontos únicos de
falha. Também é importante considerar a portabilidade e adaptabilidade, visto que devido
à não necessidade de um software externo para armazenar metadados, não há dependência
de sistema operacional, ambiente ou qualquer situação que restrinja o uso de um software.
Ou seja, na fase de implantação do software, ele elimina o pré-requisito de um software de
um sistema de gerenciamento de banco de dados, e não requer a manutenção do mesmo
na fase de produção.
Contudo, uma consequência dessa decisão arquitetural será o maior esforço de imple-
mentação, visto que utilizar um sistema de gerenciamento de banco de dados seria mais
rápido. Um aspecto importante nesse sentido, seria manter o baixo acoplamento, para
flexibilizar a utilização de diferentes formas de armazenamento de metadados no futuro. É
importante deixar em aberto na arquitetura, interface para que se acople formas diferente
de armazenamento tais como sistemas de arquivos, banco de dados em memória, bancos
de dados externos entre outros. Porém, nesse trabalho, utilizaremos apenas o cloud storage
como armazenamento de metadados. Assim como na implementação, a manutenibilidade
é outro ponto a se considerar, pois da mesma forma que a implementação, utilizar um
banco de dados externo tornaria mais fácil a manutenção do sistema. Finalmente, a falta
de segurança é uma ameaça importante, pois esses metadados não poderão ser acessados
por pessoas não autorizadas.
4.1.3 Utilização de DHT

Em um sistema de cloud storage, os dados são armazenados em diversos nós. Assim,
um problema que ocorre, é a localização desses dados. Deve-se haver uma estratégia para
se definir tanto para em qual nó um certo dado será armazenado, assim como, de qual
local será possível recuperar esse dado rapidamente, sem tornar a busca custosa ou lenta.
A solução adotada para este problema é a utilização de uma distributed hash table (DHT)
(BALAKRISHNAN et al., 2003). Como o próprio nome diz, uma DHT não é nada mais
que uma estrutura de tabela de hash distribuída em vários nós. Uma DHT tipicamente
contém duas operações básicas: inserção de objetos (put), no qual se associa uma chave
a um dado objeto e esse objeto é armazenado na tabela; e recuperação (get) na qual, a
partir da chave de um objeto, que é conhecida, pode-se recuperar aquele objeto na DHT.
Em geral, os algoritmos de DHT lidam com três problemas básicos:
• Mapear chaves com nós de forma balanceada: Cada nó deve conter aproxi-
madamente a mesma quantidade de dados para evitar problemas de sobrecarga de
um dado nó. Geralmente esse problema é resolvido utilizando uma função de hash
tanto para a identificação do nós (ex: o endereço IP do nó) quanto para a chave em
questão, e feita uma correlação entre eles;
• Redirecionar uma requisição para o nó correto: Qualquer nó que recebe uma

requisição para um dado nó, deve ter a capacidade de redirecionar a requisição para
o nó correto. Esse redirecionamento pode conter vários saltos até se alcançar o nó
em questão; e
• Construir tabelas de rotas: Para redirecionar as requisições, cada nó deve conhe-

cer os seus nós mais próximos. Um exemplo para esse caso é a disposição de nós em
anéis, onde cada nó conhece o próximo, e pode redirecionar mensagens até que a
mesma alcance seu destinatário.
Para a arquitetura proposta optou-se por utilizar um esquema similar ao Amazon

DynamoDB (DECANDIA et al., 2007) que é utilizado para um sistema de armazenamento
de dados em cloud. Nesse esquema, os dados e metadados são distribuídos em vários
nós, e cada nó é responsável pelo subconjunto de hashes. Suas responsabilidades incluem
armazenamento, replicação e busca. Essa abordagem será descrita em maiores detalhes na
seção 4.3.
As principais vantagens dessa decisão arquitetural são a escalabilidade, já que os dados
são armazenados de forma distribuída e não há um nó central para receber as requisições,
e a tolerância a falhas, visto que não há um ponto único de falha. Além disso os sistemas
de DHT tratam problema como a entradas e falhas de nós, nos quais as tuplas devem
ser realocadas para novos nós em caso de desconexão de algum nó ou a entrada de novos
nós na rede; e por fim, tempo de resposta, considerando que algoritmos de pesquisa de
recursos numa DHT otimizam o tempo de busca de recursos.
Uma preocupação em relação a essa decisão seria em relação à segurança, uma vez que
um agente mal intencionado poderia se passar por um nó para receber ou obter dados
confidenciais. Além disso, de acordo com o teorema de Brewer (GILBERT; LYNCH, 2002)
é impossível manter a consistência dos dados e simultaneamente manter a sua distribuição
e a disponibilidade.
4.1.4 Controle de Acesso

Uma preocupação constante em Cloud Storage, é a segurança dos dados. Um
sistema de controle de acesso é necessário tanto para proteger a confidencialidade dos
arquivos nele armazenados, como evitar que um agente malicioso remova arquivos de
grande valia.
Além disso, uma funcionalidade importante para esse sistema é o compartilhamento de
arquivos, que permite que um usuário conceda ou revogue acesso a outros usuários.
Finalmente, os metadados do sistema também precisam ser mantidos em segurança, pois
através deles é possível remontar o sistema de arquivo dos usuários do sistema.
Uma possível solução para acesso a arquivos e compartilhamento, é implementar um
sistema de controle de acesso discricionário (SANDHU; SAMARATI, 1994). Em um
sistema de acesso discricionário, cada usuário tem um conjunto de autorizações sobre cada
objeto, que, no caso do sistema proposto, seriam os arquivos, e os modos de acesso que
aquele usuário tem acesso, tais como escrita ou leitura. Para cada acesso à determinado
objeto, é verificado se existe alguma autorização para aquele tipo de acesso ao objeto pelo
usuário. Se existe, o acesso é permitido, caso contrário, negado.
Além disso cada proprietário de um recurso, tem o direito de modificar as autorizações
para cada usuário, garantindo acesso ou revogando caso necessário.
Para se implementar esse controle de acesso deve-se utilizar criptografia de dados. Esses
dados devem ser encriptados de forma que apenas o dono ou alguém autorizado a esses
dados tenham acesso aos mesmos.
Uma vantagem clara dessa decisão é o aumento da segurança do sistema, que não havia
sido priorizada em nenhuma das decisões anteriores. Porém, o custo desse controle de
acesso, somado com a encriptação e decriptação de dados, consumirá mais recursos do
sistema, impactando negativamente no tempo de resposta, na escalabilidade e na utilização
de recursos.
4.2 Orientação a Serviços

Como foi demonstrado na seção anterior, a arquitetura em concepção deverá utilizar
o paradigma de orientação a serviços. Portanto, deve-se listar todos os serviços que farão
parte da arquitetura e como eles irão se relacionar entre si. Também foi decidido utilizar
uma abordagem com o padrão de projeto de camada de serviços para que o sistema tenha
uma organização de negócio mais clara, além de ser uma forma de encapsular a lógica
de toda uma camada de serviços, contribuindo ainda mais para o baixo acoplamento do
sistema.
4.2.1 Camadas de Serviços

A Figura 3 mostra a divisão lógica dos serviços do sistema. A camada fundamental
do sistema é a camada de serviços básicos. Essa camada é responsável pelo armazena-
mento, recuperação e resiliência de dados e metadados do sistema. Ela terá a função de
camada de persistência para as demais camadas, sendo uma plataforma para as outras
camadas armazenarem dados e metadados. Os dados armazenados na camada de serviços
básico são tuplas chave-valor. Os valores são salvos de forma bruta, como um stream de
bytes, sem haver qualquer análise ou semântica associada. Acima da camada de serviços
Figura 3 – Divisão em camada de serviços
básicos, encontra-se a camada de serviços importantes, ou de armazenamento de arquivos.

Por meio dessa camada é possível se manter um sistema de arquivos de nuvem, com todas
as operações básicas sobre arquivos virtuais, tais como enviar arquivos, recuperar arquivos,
compartilhar arquivos, renomear arquivos, etc. A camada de serviços importantes utiliza
os serviços básicos como plataforma para salvar os arquivos, dividindo-os em chunks, assim
como em um sistema de arquivos distribuídos (BžOCH, 2012).
Por fim, existe a camada de serviços desejáveis, que utiliza as camadas de serviços básicos
e importantes para executar operações adicionais para um sistema de cloud, que podem
agregar funcionalidades, oferecendo alguns diferenciais para os usuários. Exemplos de
serviços desejáveis são: indexação de conteúdo, deduplicação, recomendação de conteúdo,
ferramentas administrativas, entre outros.
A camada de serviços desejáveis está fora do escopo, e não será aborda em detalhes neste
trabalho.
Finalmente, para que o cliente e as camadas se comuniquem utilizamos um barramento
de serviço (Enterprise Service Bus - Enterprise Service Bus (ESB)), que visa remover o
acoplamento entre os serviços e os meio de transporte, tornando a aplicação mais flexível
para uma eventual troca de tecnologia de comunicação.

Com a definição das camadas de serviços, é possível estabelecer a composição das mesmas
em um nível maior de granularidade, que são os serviços em si.
4.2.2 Descrição dos serviços

Anteriormente, foram apresentadas as camadas de serviços que compõem a arqui-
tetura. Agora, serão apresentados os serviços que compõem cada camada.
A Figura 4 mostra todos os serviços que compõem as camadas na arquitetura do sistema.
Figura 4 – Listagem dos Serviços
Na camada de serviços básicos podemos observar quatro serviços, listados:
• Armazenamento de dados: Neste serviço são armazenado o conteúdo dos arquivos.

Os conteúdos nele inseridos são armazenados através de uma tupla chave-valor, cuja
chave é um hash calculado por qualquer algoritmo conhecido, como por exemplo, o
md5 ou o sha-1. Os dados neles inseridos são considerados imutáveis, uma vez que
ao se alterar o conteúdo do arquivo, seu hash será modificado.
• Armazenamento de metadados: Neste serviço são armazenados metadados sobre

o arquivo e o sistema em si. Ele implementa um banco de dados chave-valor. Tipica-
mente será armazenado como chave um identificador único para aquele objeto (como
por exemplo, o login para o caso de armazenamento de um usuário), juntamente
com o objeto como valor. Cada objeto, terá suporte a versionamento, portanto será
possível se obter um histórico de todas as alterações de cada objeto, e também é
possível evitar inconsistências devido a escritas repetidas.
• Procura de recursos: Neste serviço é feito o lookup de objetos ou chunks ar-

mazenados no sistema, utilizando a DHT, ou qualquer outra implementação de
armazenamento de objetos que possa se utilizar posteriormente. Os serviços de

armazenamento de dados e de metadados necessitam da procura de recursos para
localizar objetos.
• Resiliência de dados: Esse serviço tem o objetivo de garantir que não haja
inconsistência ou indisponibilidade de chunks ou objetos armazenados na camada de
serviços básicos. Ela é responsável pela tolerância a falhas de todo o sistema.
Já a camada de serviços importantes, é composta pelos serviços que juntos compõem

um sistema de arquivos distribuídos. São eles:
• Gerenciamento de usuários: Responsável pelo cadastro e controle de usuários.

Operações como incluir usuários, alterar suas informações e exclusão de usuários
dependem desse módulo.
• Chunk: Responsável pelo armazenamento do conteúdo dos arquivos quebrados em

pedaços (chunks) bem como os metadados desses chunks, tais como posição, tamanho
e hash.
• Autenticação: Responsável pela verificação de identidades dos usuários ao acessar

o sistema. Por meio dele, o usuário pode se identificar através, por exemplo, de um
nome de usuário e senha.
• Controle de acesso: Responsável pela autorização e auditoria do sistema. Objetiva

impedir que não ocorra acesso não autorizado a arquivos, assim como registrar todas
as operações de seguranças críticas no sistema.
• Arquivos: Responsável pelo cadastro de arquivos através de metadados tais como

nome, tamanho, data de modificação, assim como pelo compartilhamento de arquivos
entre usuários.
A representação da camada de serviços desejáveis não está completa, os serviços

representados são apenas algumas das possibilidades de novos serviços que se pode
implementar na plataforma de cloud storage. Cada serviço representado pode vir a ser um
sistema completo que pode ser integrado com o ecossistema da nuvem de armazenamento.
Eis alguns exemplos de serviços desejáveis:
• Busca e indexação: Em um sistema de cloud storage, ao se enviar arquivos para

a nuvem, é possível executar a extração de índices sobre os arquivos e armazená-
los para futuramente recuperá-los pesquisando, por exemplo, por palavras chave
(MACHADO, 2013).
• Recomendação: Baseado nos índices de arquivos, e nas preferências dos usuários,

este serviço pode recomendar opções de arquivos para o usuário (RODRIGUES,
2014).
• Deduplicação: Através desse serviço, é possível evitar o armazenamento de arquivos

ou pedaços de arquivos repetidos, economizando assim o armazenamento e tráfego
de dados (SOARES, 2013).
• Tarifação: Esse serviço é utilizado pelo cloud provider ou cloud broker para tarifar
os cloud consumer em base na utilização do serviço (SILVA, 2013).
• Instrumentação: Esse serviço pode ser utilizado juntamente com a tarifação para
se mensurar a quantidade de armazenamento, tráfego e utilização de recursos em
geral pelo cloud consumer.
Como especificado anteriormente, essa lista não é exaustiva, nem tem esse objetivo. As
possibilidades de se implementar novos serviços são ilimitadas.
4.3 Visão Geral da arquitetura

Uma vez que foi exposto como os serviços estão organizados e e relacionados entre
si, serão mostradas as visões arquiteturais do sistema, iniciando por uma visão geral da
arquitetura, para posteriormente, se apresentar cada componente da arquitetura com
maior riqueza de detalhes.
A Figura 5 mostra o diagrama de estrutura composta da arquitetura. Ela é dividida em
dois módulos. O primeiro é o módulo de armazenamento básico, que foi apresentado com
a primeira camada de serviços do sistema. Ela é composta por uma DHT e provê uma
interface para o armazenamento de dados, e outra para o armazenamento de metadados.
Na segunda camada, encontra-se a camada de armazenamento de arquivos. Ela é composta
pelos cinco componentes que formam o sistema de arquivos em nuvem: Autenticação, Chunk,
Controle de Acesso, Gerenciamento de arquivos e gerenciamento de usuários. A função de
cada componente dessa lista é análoga aos serviços de mesmo nome apresentadas no item
anterior. O módulo requer as interfaces de armazenamento de dados e armazenamento
de metadados, porém, apenas o componente do Chunk de fato utiliza a interface de
armazenamento de dados.
Na Figura 6 é apresentada a visão de implantação da arquitetura. Entre o cliente do
cloud storage e a camada de serviços podem se implantar balanceadores de carga, que
têm o objetivo de controlar a quantidade de requisições que cada nó recebe, diminuindo
assim a sobrecarga de servidores e melhorando o tempo de resposta. Na camada de
armazenamento de arquivos, os serviços que exigirem mais recursos podem ser replicados.
Figura 5 – Visão da estrutura interna
Este é um benefício da utilização do paradigma SOA. Sendo cada serviço stateless 1 , é

possível replicá-los para ter uma melhor escalabilidade.
4.4 Camada de Serviços Básicos

A partir desta seção, serão detalhadas as subdivisões da arquitetura, começando
pela camada de serviços básicos. Conforme apresentado anteriormente, a camada de arma-
zenamento básico tem o objetivo de armazenar tuplas compostas por uma chave associada
a um valor. Este valor é composto por uma porção de dados binárias sem qualquer análise
semântica sobre elas. Esta responsabilidade de serialização e desserialização de objetos é
1 Serviços stateless são aqueles que não guardam qualquer informação sobre o cliente conectado. Geralmente seu fluxo é
composto por uma requisição oriunda do cliente acompanhada de uma resposta do servidor, sem que o servidor guarde
em memória qualquer informação sobre o cliente.
Figura 6 – Visão de Implantação

inteiramente das camadas de cima. Devido a esse comportamento, essa camada pode ser
denominada também de Armazenamento Básico.
Os valores ainda contam com um número de versão. Este número de versão é um número
sequencial que é incrementado a cada modificação da tupla. Ele visa tanto recuperar
versões anteriores para fins de auditoria, como evitar inconsistência em caso de acessos
concorrentes para escrita.
A Figura 7 mostra um exemplo de implantação do serviço de armazenamento básico. Ela
é composta essencialmente por tabela de hash distribuída (DHT) composta por vários nós
de armazenamento, sendo que cada nó está dentro de um ambiente de execução diferente,
tanto em máquinas virtuais como em hardwares distintos. Com a utilização de hardware
distinto, pode-se manter uma segurança maior nas cópias dos dados. Até mesmo, sendo um
hardware modesto, como mostrado no GFS (GHEMAWAT; GOBIOFF; LEUNG, 2003).
A Figura 8 mostra a visão de componentes do armazenamento básico, que provê duas
Figura 7 – Visão de implantação da camada de serviços básicos
interfaces para as camadas acima: ArmazenamentoMetadados e ArmazenamentoDados.

Apesar de terem operações análogas (armazenamento e recuperação de chave-valor) eles
têm algumas diferenças. O armazenamento de metadados conserva um histórico de revisão
de cada chave, enquanto no armazenamento de dados, pelo fato dos chunks serem imutáveis,
não há a necessidade de versionamento. Além disso, existe uma diferença nas estratégia
em que os dados e os metadados são armazenados. Essa diferença será demonstrada mais
adiante.
Figura 8 – Visão de componentes da camada de serviços básicos
Os componentes de armazenamento de dados e de metadados requerem a interface da

DHT, que possuem as operações típicas de uma hash table, que são basicamente inserção
de valor e recuperação a partir da chave.
O componente da DHT é uma composição de vários nós de armazenamento, que se
organizam numa formação em anel. Cada nó de armazenamento terá seu engenho de
armazenamento. Inicialmente, esse engenho foi projetado para utilizar apenas o sistema
de arquivo local da máquina em que o nó de armazenamento está em execução. Porém,
essa abordagem é flexível o suficiente para se substituir o engenho de armazenamento por
qualquer outra plataforma que possa armazenar chaves e valores, como, por exemplo, um
banco de dados em memória (GARCIA-MOLINA; SALEM, 1992) melhorando assim o
tempo de resposta do nó.
Os nós estão organizados em anel, de forma a balancear a carga em cada nó e manter
o nível de replicação. Como apresentado nas decisões arquiteturais, esta estratégia foi
baseada no algoritmo descrito pelo DynamoDB (DECANDIA et al., 2007).
O espaço amostral de todos os hashes possíveis para um dado qualquer é dividido igual-
mente por cada nó de armazenamento. A informação de quais hashes pertencem a cada
nó é distribuída pela rede.
Ao armazenar um par chave-valor, é conhecido o nó a que aquele hash pertence. Então, o
par é enviado àquele nó. A partir daí, o nó é responsável por manter N réplicas daquele
dado, replicando para os N-1 nós adjacentes no anel, sendo que N é um número arbitrário
escolhido ao se implantar um sistema. Porém é importante ressaltar que quanto maior N,

maior será a confiabilidade e maior será o tempo de resposta.
Periodicamente, cada nó checa os nós adjacentes com o objetivo de verificar se as réplicas
existem e se há eventuais inconsistências entre os nós. Em um desses casos, o problema
deve ser corrigido fazendo novas réplicas das tuplas ou ainda sobrescrevendo eventuais
inconsistências.
Já na leitura, a requisição é feita pelo nó responsável pelo hash da chave cujo dado se quer
obter. Esse nó irá comparar o dado armazenado nele próprio com os N-1 adjacentes antes
de retornar o valor. Uma escrita é bem sucedida, se o dado foi escrito em W nós, e uma
leitura é bem sucedida, se o mesmo valor foi lido em R nós. Onde W e R também são
número arbitrários que satisfazem a condição: R+W>N
Como foi demonstrado através de experimentos em DeCandia et al. (2007), no DynamoDB,
esses valores de R, W e N são respectivamente 2, 2 e 3, o que garante bons resultados
em relação à disponibilidade, performance, consistência e durabilidade. Portanto, para o
armazenamento de metadados, esses mesmos valores serão usados.
Já para o armazenamento de dados não há a necessidade de se fazer a leitura de mais de
um chunk igual, pois como declarado antes, chunks são imutáveis. Nesse caso, uma leitura
é suficiente. Portanto para satisfazer as condições especificadas, os valores de R,W e N
seriam 1, 3 e 3 respectivamente.
Na Figura 9, podemos observar um diagrama de sequência para a operação de arma-
zenamento de um par chave-valor na DHT. O serviço de armazenamento de dados ou
metadados seleciona o nó principal para aquele dado, e este armazena no próprio engenho
de armazenamento, e envia o chunk para os N-1 nós adjacentes.
O diagrama da Figura 10 mostra as classes mais importantes em um nó de armazenamento.

O nó provê uma interface que permite armazenar ou recuperar dados, e contém uma visão
da DHT como um todo, pois no momento em que um nó entra ou deixa a DHT, a estrutura
do anel pode ser diferente em dois nós, até que as informações sejam sincronizadas.
Vale também destacar que a a única interface provida para o engenho de armazenamento
é via sistema de arquivos, porém está aberta a possibilidade de novas implementações.
4.5 Camada de Serviços Importantes

Como foi mostrado na seção anterior, no armazenamento de dados, eles são arma-
zenados de forma bruta, sem qualquer conhecimento da lógica do mesmo. A lógica em
que se transforma o armazenamento de metadados e dados em um sistema de arquivos
virtual está na camada dos Serviços Importantes. Portanto essa camada também pode ser
denominada de camada de Armazenamento de Arquivos.
Figura 9 – Inserção de dados na DHT
Essa camada utiliza o armazenamento básico como plataforma, sendo esta a camada de
acesso a dados. Todos os módulos dessa camada têm uma estrutura similar. No nível mais
acima, se encontra a fachada do serviço. Ela tem o objetivo de simplificar a interface do
serviço, reduzindo o acoplamento com a forma de transporte das requisições. Cada serviço
tem sua própria fachada que provê as operações daquele serviço para as aplicações clientes.
A Figura 11 mostra a visão geral de um serviço.
Na camada abaixo da fachada, está o controller. O controller é responsável por toda
a lógica do serviço, incluindo as regras de negócio. Essa é a parte mais complexa da
implementação de um serviço.
Mais abaixo, está a camada de acesso a dados, o DAO (Data Access Object). No nosso
caso, o DAO utiliza tanto o serviço de armazenamento de dados para incluir, modificar e
excluir objetos, como o serviço de controle de acesso para decriptar objetos protegidos
pelo sistema através da chave do usuário.
A inclusão de um objeto no sistema é feito por meio das seguintes etapas: o objeto é
serializado e transformado num stream de bytes ou caracteres, caso necessário, o serviço
de controle de acesso encripta esses dados. Finalmente esses dados são associados com um
identificador único e inserido no armazenamento básico.
A Figura 12 mostra a visão de diagrama de classes da camada de Serviços Importantes,
Figura 10 – Diagrama de classes do nó de armazenamento
Figura 11 – Estrutura de um serviço

mostrando as principais operações de cada controller. Também é possível observar que

todos os controllers têm acesso ao armazenamento de metadados. Além disso, o chunk
controller é o único controller que utiliza o serviço de armazenamento de dados.
Figura 12 – Diagrama de classes do file storage
Para exemplificar, podemos observar a operação de armazenamento de arquivos mostrada

no diagrama de sequência da Figura 13. O cliente envia os chunks para o chunk controller
um a um. Para cada chunk, o controller salva os dados do chunk (parte do conteúdo
do arquivo) e os metadados do mesmo. Após o envio do último chunk, o cliente finaliza
o backup enviando os metadados referentes ao arquivo e aos chunks para o serviço de
gerenciamento de arquivos, que, por sua vez, salvará metadados no armazenamento de
metadados.
4.6 Modelo de Dados

Como visto anteriormente, a arquitetura armazena metadados em pares numa DHT,
compondo assim um sistema de gerenciamento de banco de dados do tipo chave-valor. A
modelagem desse banco, foi feita utilizando as técnicas demonstradas em Katsov (2012).
A Figura 14 mostra a modelagem do banco. Percebe-se que há uma estrutura de árvore
onde um usuário possui um diretório inicial, cada diretório possui uma lista de diretórios e
de arquivos. Cada arquivo, por sua vez, é composto por um conjunto de chunks. Por outro
lado, cada usuário também possui uma lista de compartilhamentos, que lista as referências
dos arquivos que foram compartilhados por ele e com ele. Além disso, no banco de dados
também consta uma lista de usuários autenticados com seu devido token, e uma lista de
chaves de segurança, que será melhor explicada adiante.
Figura 13 – Diagrama de sequência de um backup de arquivo
Os valores das chaves estão guardados como strings no formato JSON (JSON, 2014) que é
um formato extensível, legível por humanos e mais eficiente que o XML.
Com exceção dos valores relativos a usuários autenticados e chaves de segurança, todos
os dados são criptografados com a chave do usuário, com o objetivo de assegurar a
confidencialidade de seus dados.
4.7 Segurança
Como especificado antes, os metadados relativos ao usuário são encriptados. Nesta
seção, será detalhado o projeto da segurança da arquitetura.
Quando um novo usuário se registra, a partir da senha fornecida pelo usuário, é gerada
uma chave para o usuário que só pode ser recuperada a partir dessa senha do usuário.
Opcionalmente, o usuário ou administrador do sistema pode optar, que essa senha seja
armazenada para o caso de posterior recuperação de senha. Nesse caso, a senha é cifrada
com uma chave baseada na senha do administrador do sistema.
Ao incluir os metadados do usuário no sistema, eles são cifrados utilizando a chave do
usuário, logo, só poderão ser reabertos através da senha do mesmo.
A partir daí, para cada arquivo ou diretório enviado para o sistema, é gerada uma chave
para aquele arquivo. Os metadados desse arquivo então são cifrados de modo que eles
possam ser abertos a partir de uma dessas três chaves: a chave do usuário, a chave do
próprio arquivo ou pela chave do diretório que contém aquele arquivo ou diretório. Esse
recurso será utilizado mais à frente para o compartilhamento.
Quando o usuário troca de senha, seus arquivos deverão ser encriptados novamente com a
Figura 14 – Modelo de dados para o banco de dados
chave gerada pela nova senha. Este processo deverá ser feito em batch, podendo o usuário
ter alguns arquivos indisponíveis nesse intervalo.
No compartilhamento, o usuário utiliza a chave pública do usuário que receberá o com-
partilhamento, e gera o compartilhamento daquele arquivo. Uma vez que um usuário que
recebeu o compartilhamento de um diretório, é possível navegar nele, pois a partir da
chave de um diretório, é possível acessar todos os arquivos ou diretórios nele contidos.
Quando o usuário revoga o acesso ao arquivo ou diretório, aquele compartilhamento é
removido, e o usuário não terá meios mais para desencriptar aquele arquivo.
Somado ao esquema de criptografia que foi descrito acima, também é importante registrar
todas as ações dos usuários. Ao requisitar um arquivo ou fazer qualquer modificação nos
seus metadados, as ações do usuário são registradas pelo serviço de controle de acesso.
4.8 Conclusão
Nesta seção, foi mostrada toda a arquitetura para um sistema de backup e sincroni-
zação de arquivos em nuvem. Daqui em diante, esse trabalho será validado a partir de
uma avaliação de arquitetura cuja metodologia e resultados serão apresentados no próxima
seção.
55
5 Avaliacao da Arquitetura
Na seção anterior, foi descrita a arquitetura desenvolvida a partir dos direciona-

dores de negócios apresentado na Seção 3. Nesta seção, será feito uma validação dessa
arquitetura utilizando uma metodologia de avaliação que foi desenvolvida para resolver o
problema de avaliação em uma equipe distribuída geograficamente e com horários diferentes.
5.1 Processo de avaliação de arquitetura de software

O projeto da arquitetura é um processo crítico no ciclo de desenvolvimento de
qualquer software. Erros de projeto em um software podem levar a custos de grandes
proporções se detectados em um estágio avançado do projeto. Por isso, é fundamental se
encontrar esses erros logo no início do desenvolvimento da arquitetura.
A disciplina de Avaliação da Arquitetura de Software tem por objetivo evitar que esses
erros sejam detectados tarde demais, poupando custos e tempo da equipe desenvolvimento.
Além disso, a constante avaliação de arquiteturas dentro de uma organização, ajuda a
identificar e difundir as boas práticas de arquitetura na mesma (MARANZANO et al.,
2005).
Em Babar e Gorton (2009) são levantados as principais vantagens de se manter dentro
de uma organização um processo de avaliação arquitetural. Entre eles, são destacadas as
seguintes vantagens:
• Identificação de riscos potenciais na arquitetura proposta
• Avaliação dos atributos de qualidade
• Identificação de oportunidade de reuso de artefatos arquiteturais e componentes
• Promover boas práticas de arquitetura e avaliação
• Reduzir custos do projeto causado por problemas não detectados
• Capturar a razão de decisões de projetos importantes
• Descobrir problema e conflitos nos requisitos
• Alinhar com o processo de garantia de qualidade da organização
• Ajudar os stakeholders na negociação dos requisitos conflitantes
• Identificar habilidades necessárias para implementar a arquitetura proposta

Seção 5. Avaliacao da Arquitetura 56
• Melhorar o qualidade da documentação da arquitetura
• Facilitar uma articulação clara dos requisitos não funcionais
• Abrir novos canais de comunicação entre stakeholders
Portanto, fica claro que o processo de avaliação da arquitetura é tão importante

quanto definir arquitetura, e esse processo pode ser utilizado para validar este trabalho.
Neste projeto, utilizou-se uma avaliação de arquitetura para além de validar a arquitetura,
obter as vantagens em destaque na listagem anterior.
5.2 Equipe de Avaliação da arquitetura

Para avaliar a arquitetura de software, contou-se com a ajuda de consultores
externos. Sendo esses mestres, doutorandos ou doutores pelo Centro de Informática da
UFPE, e engenheiros de softwares ou arquitetos provenientes da Ustore, empresa que tem
expertise em desenvolvimento de sistema em Cloud Storage.
A composição do time de avaliação foi de suma importância porque é uma tecnologia
que não é amplamente difundida e são raros os profissionais que tenham o conhecimento
necessário para executar a avaliação dessa arquitetura.
5.3 Ameaças á validação

Algumas características na equipe de avaliação poderiam representar uma ameaça
ao processo de validação da arquitetura. Uma adaptação foi feita à metodologia para que
se possa conduzir este processo.
Havia algumas restrições com a composição da equipe, entre elas destacam-se os seguintes
problemas: falta de um analista de negócio, equipe relativamente pequena (cinco membros),
equipe distribuída geograficamente e falta de uma agenda compatível entre os diversos
membros da equipe.
O problema da falta de um analista de negócio já havia sido previsto antes do processo de
avaliação. Para conter esse problema foi feito todo o estudo apresentado na Seção 3.
As duas últimas restrições, descartariam a maioria das metodologias tradicionais para
avaliação de software, pois a maioria delas exige reuniões presenciais que podem se tornar
longas. Para contornar esse problema, foi necessário a utilização de uma metodologia de
avaliação não convencional, que será apresentada na próxima seção.
5.4 Metodologia de avaliação

A metodologia utilizada foi encontrada em Tomas (2014). Essa metodologia foi
baseada nas metodologias Software Architecture Analisys Method (SAAM) e Architecture
Tradeoff Analisys Method (ATAM), adaptando-se às necessidades de uma equipe remo-
tamente distribuída. Nessa metodologia, também foram combinadas algumas etapas das
metodologias SAAM e ATAM.
A primeira etapa do método, é contextualizar toda equipe de como será conduzido o pro-
cesso de avaliação arquitetural. Toda a metodologia deve ser apresentada, principalmente
no que se refere aos artefatos gerados em cada etapa.
Após isso, são apresentados os business drivers para nivelar o conhecimento da equipe
no tocante as regras de negócio e atributos de qualidades relevantes para o domínio do
mesmo.
A próxima etapa é a apresentação da arquitetura propriamente dita. O arquiteto deve
apresentar a arquitetura de forma que todos os participantes a entendam, principalmente
as regras de negócio, como também interação entre os módulos e o ciclo de vida dos
componentes.
Uma vez apresentada a arquitetura, deve-se priorizar os atributos de qualidade para o
negócio cujo problema a arquitetura se propõe a resolver. Sugere-se que o arquiteto sugira
uma lista pré-selecionada de atributos que possam ser empregados, e daí se possa eleger
os principais atributos de qualidade (Quality Attribute (QA)).
Em seguida, deve-se contextualizar a equipe do conceito de cenários. Um cenário é uma
situação em que a arquitetura deve suportar. Cenários podem ser de casos de uso, cujo
cenário é baseado em uma situação que pode ocorrer devido à interação do usuário com o
sistema, ou exploratório, quando fatores ou mudanças externas causam algum impacto
sobre a arquitetura.
Após isso, a equipe deverá propor os cenários que poderão ser utilizado na arquitetura. Em
uma situação remota, como a dessa avaliação, isso pode ser feito com o compartilhamento
de documentos.
Finalmente, os cenários mais relevantes são selecionados e é analisada a interação dos
cenários com os atributos de qualidade para que se tenha os resultados da avaliação
5.5 Execução do processo de avaliação

Devido à restrição da incompatibilidade de agendas de toda a equipe, não seria
possível apresentar a metodologia, atributos de qualidade ou a arquitetura em reuniões
presenciais ou mesmo por conferências.
Portanto, para contornar essas dificuldades, o arquiteto gravou vídeos nos quais a metodo-
logia, o contexto de negócio, o conceito de cenários e a arquitetura foram apresentados
para os participantes da avaliação.

No primeiro vídeo foi explicada a metodologia que seria conduzida a partir dali. Também
foi apresentada a norma ISO/IEC 25010.2 (ISO/IEC, 2010) que seria utilizada como lista
dos atributos de qualidade que seriam utilizados.
No segundo vídeo, foi feita uma análise dos drivers de negócio de cloud storage e backup
de arquivos, mostrando as principais vantagens e desvantagens, restrições e requisitos.
Foi feita uma análise dos atributos de qualidades que poderiam contribuir para as vantagens
ou amenizar as desvantagens. Com a ajuda da equipe de avaliação, foram definidos os
principais atributos de qualidade, que foram apresentados na Seção 3.
Finalmente, foi feito um vídeo apresentando a arquitetura proposta na Seção 4. Mostrando
as principais visões das duas camadas.
Após isso, cada participante, em seu tempo disponível, assistiu a cada um dos vídeos e
numa planilha compartilhada com o arquiteto, colocou cenários possíveis que poderiam
ser utilizados para avaliar a arquitetura proposta. Os participantes foram incentivados a
escrever qualquer ideia, mesmo que o mesmo não a entendesse como relevante.
Finalmente, foi feita uma análise de como seria a interação entre os cenários e as arquite-
turas, e suas consequências com os atributos de qualidade.
5.6 Cenários propostos e resultados da avaliação

Nesta seção, mostraremos os cenários que foram priorizados, assim como o resultado
teórico para cada interação entre cenário e a arquitetura proposta. Dos cenários propostos,
alguns foram removidos por se tratar de cenários que envolvem serviços que não estão no
escopo deste trabalho (por exemplo, busca e deduplicação). Segue a lista de cenários com
sua respectiva avaliação:
• 1. Troca de senha
Descrição: Imaginando um usuário X trocando sua senha, todos seus arquivos serão
reencriptados em batch, o que acarretará na reencriptação de todos os chunks e na
re-replicação desses chunks, causando um overhead na rede ou de processador
Atributos de qualidade: Utilização de recursos, comportamento temporal
Resultado: Nesta situação a arquitetura responde mal. Se o usuário tiver um
número muito grande de arquivos ou um número grande de usuários trocar de senha,
o sistema irá consumir uma grande quantidade de recursos de cpu e banda.
• 2. Cache de memória
Descrição: Devido a constante replicação e pedidos de restore, os peer de dados
poderiam manter um cache em memória dos chunks mais acessados, ou até mesmo
fazer um cache de escrita
Atributos de qualidade: Utilização de recursos, comportamento temporal
Resultado: Como especificado anteriormente, cada nó de armazenamento possui

um engenho de armazenamento. Esse cenário poderia ser facilmente implementado
utilizando um banco de dados em memória em cada nó de armazenamento, que
otimizaria esse tipo de acesso.
• 3. Inconsistência entre os Peers

Descrição: Usuário deleta arquivo enquanto algum dos nós de armazenamento com
réplica está offline
Atributos de qualidade: Consistência, tolerância a falhas
Resultado: Durante a verificação de consistência entre os peers, eventuais diferença
entre nós por conta da indisponibilidade temporária de algum nó é corrigida. Portanto,
a arquitetura responderia bem a esse cenário.
• 4. Duplicidade de dados
Descrição: Dois usuários fazem backup do mesmo arquivo
Atributos de qualidade: Utilização de recursos
Resultado: Apesar, da operação ocorrer sem problemas, não acontecerá de forma
otimizada. Em um ambiente ideal, os dois arquivos, que contém rigorosamente os
mesmos chunks, poderiam referenciar um ao outro. Porém, como cada arquivo é
encriptado por uma chave diferente, isso não ocorrerá, pois com a encriptação do
arquivo, os dois conteúdos serão distintos. Neste cenário houve um tradeoff entre
segurança e utilização de recursos, no qual a segurança foi favorecida.
• 5. Crescimento do negócio
Descrição: Devido à mudanças no modelo de negócio a empresa que detém o sistema
de armazenamento "abre"o serviço para Web. Deste modo, a quantidade de usuários
que totalizava 400 usuários, após 1 ano, tornou-se em 4000.
Atributo de qualidade: Escalabilidade
Resultado: Pelas características da implementação dos serviços (baixo acoplamento,
sessões sem estado) além da utilização da DHT, o sistema é amplamente escalável,
desde que exista o hardware necessário para comportar a quantidade de serviços e
nós de armazenamento.
• 6. Migração
Descrição: Migração do serviço de armazenamento para um outro serviço de arma-
zenamento
Atributo de qualidade: adaptabilidade
Resultado: Como especificado nos Business Drivers, esta é uma das limitações de
cloud storage. Porém, através da utilização dos serviços, é possível desenvolver uma
aplicação que recupere os arquivos e envie-as para o novo serviço. Portanto esse
cenário é parcialmente atendido.
• 7. Falha em discos
Descrição: Máquina que contem a base de metadados tem o conteúdo do disco
corrompido.
Atributo de qualidade: Tolerância a falhas
Resultado: Na arquitetura não existe um servidor central de metadados. Todos os
dados são armazenado numa DHT. Se um nó da DHT falha, existem réplicas que
nos ajudam a recuperar esses dados. Logo, esse cenário é totalmente atendido.
• 8. Mudanças na camada de comunicação

Descrição: Existe uma necessidade de se utilizar um novo prococolo ou framework
de comunicação
Atributos de qualidade: Adaptabilidade, modificabilidade
Resultado: O paradigma SOA é independente da camada de comunicação. Será
necessário implementar um novo barramento de serviços utilizando o novo protocolo
e esse cenário será atendido.
• 9. Mudança no serviço de autenticação

Descrição: Exigência de um novo modelo de autenticação (por exemplo: um Active
Directory)
Resultado: Será necessário modificar o serviço de autenticação para se comunicar
com esse serviço ao invés de utilizar os metadados do sistema. Uma vez que o usuário
seja autenticado pelo sistema externo, o funcionamento do sistema é mantido.
• 10. Mudança na forma de armazenamento

Descrição: Exigência de um SGBD específico para se armazenar os dados e/ou
metadados.
Resultado: Uma limitação técnica desse tipo de exigência é que ao se optar por um
banco relacional não será possível manter a disponibilidade e tolerância a partição
por conta do que foi declarado no teorema de Brewer. Porém, é possível substituir
ou modificar o componente de armazenamento de dados ou metadados para que se
possa utilizar o SGBD fornecido.
5.7 Consolidação dos Resultados

Observando os resultados obtidos, os mesmos foram classificados em três categorias:
Atende totalmente, nos casos em que a arquitetura atende ao cenários sem a nescidade
de modificação, atende parcialmente, caso o cenário possa ser atendido com pequenas
modificações e não atende, se a arquitetura necessitaria de uma mudança de grande
impacto, ou não atenderia de forma alguma.
Tabela 2 – Consolidação dos Resultados
Fonte: equipe de avaliação
Como pode-se observar na Tabela 2, que mostra os resultados consolidados, três cenários
foram atendidos totalmente. Enquanto seis desses foram atendidos parcialmente, ou seja,
necessitam de pequenas modificações na arquitetura, nas quais a maioria delas, pode ser
feita, após a arquitetura implementada. E finalmente, um cenário não foi atendido.
Como recomendação da avaliação, é necessário se pensar um esquema criptográfico
mais eficiente, que mantenha a segurança e não torne arquivos indisponíveis.
Finalmente, podemos considerar que a arquitetura respondeu bem à avaliação, com uma
ressalva, que foi em relação ao esquema de criptografia. Atributos de qualidade como
escalabilidade, adaptabilidade, utilização de recursos e segurança responderam bem aos
estímulos da avaliação.
5.8 Conclusão
Como podemos observar, a avaliação antecipou um problema que poderia ocorrer
em tempo de execução da arquitetura, que seria o uso excessivo de recursos, aliado com a
perda de performance do sistema durante o processo de troca de senha para o usuários.
Na indústria, uma situação como essa salvaria um valor significativo de tempo em dinheiro.
Pois os arquitetos poderiam modificar e reavaliar a arquitetura, ou ainda, colocar essa
falha como uma limitação do sistema.
62
6 Conclusão
63
7 Conclusão
Apesar de um item falho, ao longo de todo o trabalho, foi possível projetar uma
arquitetura elástica, escalável e segura para um sistema de Cloud Storage.
Nesta seção, serão apresentadas as conclusões que puderam ser tiradas ao longo de todo o
desenvolvimento desse trabalho.
7.1 Principais Conclusões

Ao longo deste trabalho, foi possível, estudar as tecnologias envolvidas com Cloud
Computing e Cloud Storage, para através desse estudo, conseguirmos fazer um levantamento
dos principais direcionadores de requisitos, incluindo vantagens, desvantagens, atributos
de qualidades e requisitos.
A partir dos requisitos e atributos de qualidade, foi projetada uma arquitetura, rica em
detalhes, que se propõe a resolver o problema de armazenamento de arquivos em nuvem.
Esta arquitetura foi guiada por decisões arquiteturais, que foram justificadas e serviram
como base para todo o projeto arquitetural.
Finalmente, foi executada uma avaliação de arquitetura, que utilizou uma metodologia
baseada em SAAM e ATAM, adaptada para as peculiaridades da equipe de avaliação.
Apesar, de ter sido apontado um problema no projeto, podemos dizer que a arquitetura
respondeu bem à avaliação.
Após o término deste trabalho, as principais conclusões foram observados:
• Ao projetar um sistema de Cloud Storage, o arquiteto deve priorizar as decisões que

venham a manter um sistema com baixo custo, escalável e seguro.
• Com as interações entre os Cenários e a arquitetura do sistema, observou-se que de

fato SOA com REST pode ser uma prática interessante para sistemas em nuvem.
• Em um desenvolvimento de uma arquitetura de software, uma avaliação da arquite-

tura é tão importante quanto o projeto da mesma. Uma avaliação pode salvar custos
do projeto.
• A abordagem de descrever as principais decisões arquiteturais no início do projeto

contribuiu para que se houvesse um guia para o projeto da arquitetura.
7.2 Contribuições
As principais contribuições deixadas por esse trabalho foram:
Seção 7. Conclusão 64
• Uma analise dos direcionadores do negócio de Cloud Storage, que serviu de insumo
para o desenvolvimento da arquitetura proposta.
• Uma arquitetura, que pode ser útil para implementar um sistema de armazenamento
de arquivos, ou mesmo, como fonte para que novas arquiteturas sejam elaboradas.
• Uma metodologia de avaliação para ser utilizada por equipes geograficamente distri-
buídas e com disponibilidade de tempo incompaties.
7.3 Trabalhos Futuros

Algumas possibilidades para novos trabalhos a partir deste:
• Resolver o problema da indisponibilidade temporário dos arquivos enquanto o usuário

troca a senha.
• Implementar a arquitetura.
• Projetar um serviço de administração que possa prover um controle da nuvem com

um mínimo de configurações.
65
Referências
ALJABRE, A. Cloud computing for increased business value. International Journal of

Business and Social Science, 2012.
AMAZON. Amazon Elastic Computing Cloud: hospedagem escalonável em nuvem. 2014.

Disponível em: <http://aws.amazon.com/pt/ec2/>. Acesso em: 15 jun. 2014.
AMAZON. Amazon Web Services (AWS): serviços de computação em nuvem. 2014.

Disponível em: <http://aws.amazon.com/pt/>. Acesso em: 15 jun. 2014.
BABAR, M.; GORTON, I. Software architecture review: The state of practice. Computer,
v. 42, n. 7, p. 26–32, July 2009. ISSN 0018-9162.
BALAKRISHNAN, H. et al. Looking up data in p2p systems. Commun. ACM, ACM,

New York, NY, USA, v. 46, n. 2, p. 43–48, fev. 2003. ISSN 0001-0782. Disponível em:
<http://doi.acm.org/10.1145/606272.606299>.
BOHN, R. B. et al. Nist cloud computing reference architecture. In: IEEE WORLD
CONGRESS ON SERVICES, 2011, Washington. Proceedings... Washington, DC, USA:
IEEE Computer Society, 2011. p. 594–596.
BROWNBRIDGE, D. R.; MARSHALL, L. F.; RANDELL, B. The newcastle connection

or unixes of the world unite! Softw., Pract. Exper., v. 12, n. 12, p. 1147–1162, 1982.
BžOCH, P. Distributed file systems: the state of the art and concept of ph.d. thesis. [S.l.],
2012.
CALDER, B. et al. Windows azure storage: a highly available cloud storage service with
strong consistency. In: ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES,
23., 2011, Cascais. Proceedings... New York: ACM, 2011. p. 143–157.
CHELLAPPA, R. Intermediaries in cloud-computing: a new computing paradigm.

INFORMS, 1997.
CRUZ, F. d. Herb Grosch. 2004. Disponível em: <http://www.columbia.edu/cu/

computinghistory/grosch.html>. Acesso em: 14 jun. 2014.
DALAKOVI, G. Joseph Licklider. 2014. Disponível em: <http://history-computer.com/

Internet/Birth/Licklider.html>. Acesso em: 15 jun. 2014.
DALAKOVI, G. Lisp of Josh McCarthy. 2014. Disponível em: <http://history-computer.

com/ModernComputer/Software/LISP.html>. Acesso em: 15 jun. 2014.
DECANDIA, G. et al. Dynamo: Amazon’s highly available key-value store. In:

SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES (SIGOPS), 21., 2007,
Washington. Proceedings... New York: ACM, 2007. p. 205–220.
DROPBOX. Dropbox. 2014. Disponível em: <http://www.dropbox.com>. Acesso em: 15

jun. 2014.
Referências 66
DURãO, F. et al. Usto.re: a private cloud storage software system. In: INTERNATIONAL
CONFERENCE ON WEB ENGINEERING, 13., 2013, Aalborg. Proceedings... Berlin:
Springer-Verlag, 2013. p. 452–466.
ENISA. Cloud computing: benefits, risks and recommendadtions for information security.
2009. Disponível em: <https://www.enisa.europa.eu/activities/risk-management/files/
deliverables/cloud-computing-risk-assessment/at_download/fullReport>. Acesso em: 2
jul. 2014.
ERL, T. SOA design patterns. 1st. ed. Upper Saddle River, NJ, USA: Prentice Hall PTR,
2009. ISBN 0136135161, 9780136135166.
GANTZ J. E REINSEL, D. Extracting value from chaos state of the universe: an executive
summary. Framingham, MA, USA, 2011.
GARCIA-MOLINA, H.; SALEM, K. Main memory database systems: An overview. IEEE

Trans. on Knowl. and Data Eng., IEEE Educational Activities Department, Piscataway,
NJ, USA, v. 4, n. 6, p. 509–516, dez. 1992. ISSN 1041-4347.
GHEMAWAT, S.; GOBIOFF, H.; LEUNG, S.-T. The google file system. In: ACM
SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES, 19., 2003, Bolton Landing.
Proceedings... New York: ACM, 2003. p. 29–43.
GILBERT, S.; LYNCH, N. Brewer’s conjecture and the feasibility of consistent, available,
partition-tolerant web services. SIGACT News, ACM, New York, NY, USA, v. 33, n. 2, p.
51–59, jun. 2002. ISSN 0163-5700.
GOOGLE. Google Drive. 2014. Disponível em: <http://www.google.com/intl/pt-BR/

drive/index.html>. Acesso em: 13 jul. 2014.
GROSSMAN, R. The case for cloud computing. IT Professional, v. 11, n. 2, p. 23–27,

March 2009. ISSN 1520-9202.
ISO/IEC. ISO/IEC 25010 - systems and software engineering : systems and software
quality requirements and evaluation (square) - system and software quality models. [S.l.],
2010.
JANSEN, A.; BOSCH, J. Software architecture as a set of architectural design decisions.

In: WORKING CONFERENCE ON SOFTWARE ARCHITECTURE (WICSA), 5., 2005,
Pittsburgh. Proceedings... Pittsburgh: IEEE Computer Society, 2005. p. 109–220.
JIANG, W. et al. Mystore: a high vailable distributed storage system for unstructured data.
In: INTERNATIONAL CONFERENCE ON HIGH PERFORMANCE COMPUTING
AND COMMUNICATION, 14, INTERNATIONAL CONFERENCE ON EMBEDDED
SOFTWARE AND SYSTEMS, 9, 2012, Paris. Proceedings... Paris: IEEE Computer
Society, 2012. p. 233–240.
JOSUTTIS, N. Soa in practice: the art of distributed system design. [S.l.]: O’Reilly Media,
Inc., 2007. ISBN 0596529554.
JSON. Introducing JSON. 2014. Disponível em: <http://json.org>. Acesso em: 7 ago.
2014.
Referências 67
KATSOV, I. NoSQL data modeling techiniques. 2012. Disponível em: <http:

//highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/>. Acesso
em: 7 ago. 2014.
KHAJEH-HOSSEINI, A. et al. The cloud adoption toolkit: Supporting cloud adoption

decisions in the enterprise. Softw. Pract. Exper., John Wiley & Sons, Inc., New York, NY,
USA, v. 42, n. 4, p. 447–465, abr. 2012. ISSN 0038-0644.
KUBIATOWICZ, J. e. a. Oceanstore: An architecture for global-scale persistent storage.

SIGPLAN Not., ACM, New York, NY, USA, v. 35, n. 11, p. 190–201, nov. 2000. ISSN
0362-1340.
MACHADO, M. A. S. Uma abordagem para indexação e buscas full-text baseadas

em conteúdo em sistemas de armazenamento em nuvem. Dissertação (Mestrado) —
Universidade Federal de Pernambuco, 2013.
MARANZANO, J. et al. Architecture reviews: practice and experience. Software, IEEE,

v. 22, n. 2, p. 34–43, March 2005. ISSN 0740-7459.
MARSTON, S. et al. Cloud computing: the business perspective. In: INTERNATIONAL

CONFERENCE ON SYSTEM SCIENCES (HICSS), 44., 2011, Hawaii. Proceedings...
Hawaii: IEEE Computer Society, 2011. p. 1–11.
MELL, P.; GRANCE, T. The NIST definition of cloud computing. Gaithersburg, MD,
2011.
MICROSOFT. Microsoft One Drive. 2014. Disponível em: <http://onedrive.live.com>.

Acesso em: 13 jul. 2014.
NOVELL. NetWare core protocols. 2014. Disponível em: <http://www.novell.com/

developer/ndk/netware_core_protocols.html>. Acesso em: 15 jun. 2014.
OLIVEIRA, E. M. Vantagens e desvantagens de SOA. 2014. Disponível em:

<http://www.devmedia.com.br/vantagens-e-desvantagens-de-soa/27437#>. Acesso em:
27 jul. 2014.
PARKHILL, D. F. The challenge of the computer utility. USA: Addison-Wesley

Professional, 1966.
PATTERSON, D. A.; GIBSON, G.; KATZ, R. H. A case for redundant arrays of

inexpensive disks (raid). In: ACM SIGMOD INTERNATIONAL CONFERENCE ON
MANAGEMENT OF DATA, 1988, Chicago. Proceedings... New York: ACM, 1988. p.
109–116.
RODRIGUES, R. B. RecCloud: um modelo de recomendação para sistemas de

armazenamento em nuvem. Dissertação (Mestrado) — Universidade Federal de
Pernambuco, 2014.
SALESFORCE. CRM e cloud computing para crescer seu negócio: Salesforce.com brasil.
2000. Disponível em: <http://www.salesforce.com/br>. Acesso em: 15 jun. 2014.
SANDBERG, R. The sun network files system: Design, implementation and experience.
[S.l.], 1986.
Referências 68
SANDHU, R.; SAMARATI, P. Access control: principle and practice. Communications

Magazine, IEEE, v. 32, n. 9, p. 40–48, Sept 1994. ISSN 0163-6804.
SECURITY, H. N. A closer look at Mega cloud storage. 2013. Disponível em:

<http://www.net-security.org/secworld.php?id=14938>. Acesso em: 5 jul. 2014.
SHIVAKUMAR, S. Thought floor: a walk in the clouds (pt 1). 2014. Disponível em:
<http://www.infosysblogs.com/thought-floor/2012/02/a_walk_in_the_clouds_part_
1.html>. Acesso em: 8 ago. 2014.
SILVA, F. A. P. Monext: an accounting framework for federated clouds. Dissertação

(Mestrado) — Universidade Federal de Pernambuco, 2013.
SNIA. Implementing, serving, and using cloud storage. 2013. Disponível em:
<http://snia.org/sites/default/files/Implementing_Serving_and_Using_The_
Cloud-Nov_2013.pdf>. Acesso em: 15 jun. 2014.
SNIA. What is a storage area network. 2014. Disponível em: <http://www.snia.org/

education/storage_networking_primer/san/what_san>. Acesso em: 15 jun. 2014.
SOARES, P. F. A. S. Dedupeer: deduplicação de arquivos através de um algoritmo

de processamento particionado. Dissertação (Mestrado) — Universidade Federal de
Pernambuco, 2013.
SOMMERVILLE, I. Software engineering. 8. ed. [S.l.]: Addison Wesley, 2007.
SUBASHINI S. E KAVITHA, V. A metadata based storage model for securing data in

cloud environment. In: INTERNATIONAL CONFERENCE ON CYBER-ENABLED
DISTRIBUTED COMPUTING AND KNOWLEDGE DISCOVERY (CYBERC), 2011,
Beijing. Proceedings... Beijing: IEEE Computer Society, 2011>. p. 429–434.
SUGARSYNC. File sharing, online backup and cloud storage from any device: Sugar sync.
2014. Disponível em: <http://www.sugarsync.com>. Acesso em: 13 jul. 2014.
TOMAS, G. H. R. P. Uma arquitetura para cidades inteligentes baseada na internet das

coisas. Dissertação (Mestrado) — Universidade Federal de Pernambuco, Recife, 2014.
YANG, X.; ZHANG, H. Cloud computing and soa convergence research. In:
INTERNATIONAL SYMPOSIUM ON COMPUTATIONAL INTELLIGENCE AND
DESIGN (ISCID), 5., 2012, Hangzhou. Proceedings... Hangzhou: IEEE Computer Society,
2012. p. 330–335.
Apêndices
70
APÊNDICE A – Matriz Vantagens e

Desvantagens x QAs
APÊNDICE A. Matriz Vantagens e Desvantagens x QAs 71
Tabela 3 – Matriz Vantagens x QAs
Acesso Redução Habilid. Efetet. Escalab. Conc.

ubí- de cus- de com- de re-
quo tos cresci- putaci- cursos
mento onal
sob de-
manda
Adequação 0
Precisão 0
Disponibilidade 1 1 2
Tolerância a fa- 1 1
lhas
Recuperabilidade 0
Comportamento 1 1
temporal
Utilização de re- 1 1 1 3
cursos
Reconhecimento 0
de adequação
Apreensibilidade 0
Facilidade de uso 0
Prestatividade 0
Atratividade 0
Acessibilidade 1 1 2
técnica
Confidencialidade 0
Integridade 0
Não-repúdio 0
Responsabilidade 0
Autenticidade 0
Susbtituidade 1 1
Coexistência 0
Interoperabilidade 1 1
Modularidade 1 1
Reusabilidade 1 1
Analisabilidade 1 1
Modificabilidade 1 1
Estabilidade de 1 1
modifcação
Testabilidade 1 1
Portabilidade 1 1 1 3
Adaptabilidade 1 1 1 3
Instalabilidade 1 1 2
APÊNDICE A. Matriz Vantagens e Desvantagens x QAs 72
Tabela 4 – Matriz Desvantagens x QAs
Perda Vinc. Segur. Dep. Indis. Comp.

go- Ser- co- servi- de re-
vern. viço nect. ços cursos
Adequação 0
Precisão 0
Disponibilidade 1 1
Tolerância a fa- 1 1
lhas
Recuperabilidade 1 1
Comportamento 1 1
temporal
Utilização de re- 0
cursos
Reconhecimento 0
de adequação
Apreensibilidade 0
Facilidade de uso 0
Prestatividade 0
Atratividade 0
Acessibilidade 0
técnica
Confidencialidade 1 1 1 3
Integridade 1 1
Não-repúdio 1 1 1 3
Responsabilidade 1 1 1 3
Autenticidade 1 1 1 3
Susbtituidade 1 1
Coexistência 1 1
Interoperabilidade 1 1
Modularidade 0
Reusabilidade 0
Analisabilidade 1 1
Modificabilidade 0
Estabilidade de 0
modifcação
Testabilidade 0
Portabilidade 0
Adaptabilidade 0
Instalabilidade 0

Mestrado Thiago Jamir

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Mestrado Thiago Jamir

Enviado por

Direitos autorais:

Formatos disponíveis

THIAGO JAMIR E SILVA

UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE ARQUIVOS

Universidade Federal de Pernambuco

UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE

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

Orientador: Silvio Romero de Lemos Meira

S586a Silva, Thiago Jamir e

Orientador: Sílvio Romero de Lemos Meira.

1. Engenharia de software. 2. Computação em nuvem. 3. Arquitetura de

005.1 CDD (23. ed.) UFPE- MEI 2016-132

Palavras-chave: Arquitetura de software. Cloud computing. Cloud storage. Backup.

Keywords: Software Architecture. Cloud Computing. Cloud storage. Backup. Synchro-

Figura 1 – Modelos de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Tabela 1 – Atributos de Qualidade escolhidos . . . . . . . . . . . . . . . . . . . . 30

ESB Enterprise Service Bus

ATAM Architecture Tradeoff Analisys Method

SAAM Software Architecture Analisys Method

REST Representational state transfer

2 CONTEXTUALIZAÇÃO E TRABALHOS RELACIONADOS . . . . 16

3 CLOUD STORAGE BUSINESS DRIVERS . . . . . . . . . . . . . . 25

APÊNDICE A – MATRIZ VANTAGENS E DESVANTAGENS X

Atualmente, tem-se observado um crescimento alarmante no volume de dados

• Não permitem acesso de qualquer dispositivo;

• Requerem que o usuário esteja conectado a uma rede;

• Tem um custo elevado de hardware para serem implantados;

• Não escalam para o volume crescente de dados.

A utilização de sistemas de Cloud Computing e Cloud Storage(MELL; GRANCE,

1.1 Definição do problema

• Quais são os direcionadores de negócio para o uso de Cloud Storage?

• Como projetar uma arquitetura que atenda esses contexto?

• Foi feita uma revisão exploratória da literatura, com o objetivo de encontrar os

• Das informações obtidas sobre o contexto de negócio, foram levantados os atributos

• Com a ajuda de uma metodologia de avaliação de arquitetura, esse trabalho foi

1.3 Fora do escopo

• Requisitos e necessidades relativas ao cloud broker (BOHN et al., 2011)

• Questões de tarifação (billing).

• Planos de negócio para sistema de Cloud Storage.

1.4 Estrutura da dissertação

• Na Seção 2 é feita uma contextualização sobre Cloud Storage e trabalhos relacionados.

• Na Seção 3 são levantados os direcionadores de negócio de cloud storage.

• Na Seção 4 é apresentada a arquitetura projetada.

• Na Seção 5, a avaliação da arquitetura é executada.

• Na Seção 7 são apresentadas as conclusões do trabalho e são levantadas possibilidades

• Finalmente no Apêndice A é mostrada as tabelas que apoiaram as decisões dos

2 Contextualização e Trabalhos Relaciona-

2.1 Cloud Computing

2.1.1 História de cloud computing

2.1.2 Definição de Cloud Computing

“Computação em Nuvem é um modelo que proporciona um acesso de rede

Dentro da definição apresentada acima, é importante destacar alguns elementos. O compar-

• Auto serviço sob demanda: Um cliente pode prover unilateralmente capacidade

• Acesso de rede amplo: Capacidades são disponibilizadas sobre a rede e acessadas

• Reserva de recursos: Os recursos computacionais do serviço são agrupados para

• Elasticidade rápida: Capacidade computacional pode ser provida e liberada, em

• Serviço instrumentado: Sistemas em nuvem automaticamente controlam e otimi-

• Software as a Service (SaaS): O provedor disponibiliza aplicações que são

• Platform as a Service (PaaS): O provedor disponibiliza uma plataforma capaz

• Infrastructure as a Services(IaaS): O provedor disponibiliza para o cliente

que é utilizada, mas gerencia recursos como armazenamento, sistema operacionais e

A Figura 1, extraida de Shivakumar (2014) ilustra os diferentes níveis dos modelos de

Figura 1 – Modelos de Serviços

Fonte: Infosys Blogs

Ainda de acordo com o NIST, podemos classificar os sistemas de cloud computing

• Nuvem privada: A infraestrutura é fornecida para uso exclusivo de uma única