Uma Arquitetura de Cloud Storage para Backup de Arquivos

Thiago Jamir e Silva
UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE

ARQUIVOS
Dissertao de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE
AGO/2014
Universidade Federal de Pernambuco

Centro de Informtica
Ps-graduao em Cincia da Computao
Thiago Jamir e Silva
UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE

ARQUIVOS
Trabalho apresentado ao Programa de Ps-graduao em

Cincia da Computao do Centro de Informtica da Universidade Federal de Pernambuco como requisito parcial para
obteno do grau de Mestre em Cincia da Computao.
Orientador: Silvio Romero de Lemos Meira

Co-Orientador: Rodrigo Elia Assad
RECIFE
AGO/2014
Dedico este trabalho minha famlia e meus amigos. Pois

sem eles, este trabalho no seria possvel.
Agradecimentos
Antes de mais nada, gostaria de agradecer toda minha famlia por todo o apoio.
Principalmente minha esposa, Eduarda, por ter acreditado na minha capacidade, quando eu
mesmo duvidei. Meus pais, e meu irmo pelo apoio constante, e pelos exemplos que me
deixaram para seguir.
Aos meus amigos cujo apoio foi fundamental para o trmino deste trabalho. Fica aqui o meu
obrigado a todos.
Aos professores Professores Silvio Meira (orientador), Rodrigo Assad (co orientador) e Vincius
Garcia, pela oportunidade dada, pelas trocas de idia, pela cobrana e pelos caminhos que foram
indicados.
Ao professor Ccero Garrozi, por se disponibilizar a fazer parte da banca deste trabalho.
Ao Centro de Informtica da UFPE e todos que o fazem, pelo ensino e suporte dado para que
este possa ter concludo.
Aos colegas do ASSERT Lab por todos os feedbacks dados durante a evoluo desse projeto.
Tenho certeza que essas discusses foram proveitosas para todos ns.
A todos os colegas da Ustore, pela pacincia e colaborao de todos , que para mim, uma
segunda casa.
Finalmente, gostaria de agradecer a todos que contriburam diretamente e indiretamente
realizao de mais etapa na minha vida.
Obrigado a todos!
Resumo
Nos ltimos anos, o volume de dados gerados por indivduos e organizaes tem crescido
exponencialmente. Estima-se que globalmente existia 2.7 zetabytes em 2012 e esse nmero tem
dobrado a cada dois anos. Alm disso, com a popularizao de dispositivos mveis conectados,
cresceu-se a necessidade de que usurios tenham acesso a arquivos de forma ubqua. As
solues tradicionais de backup e armazenamento de arquivos online j no conseguem suprir as
necessidades atuais dos usurios.
A utilizao de Cloud Storage para backup e sincronizao de arquivos vem a ser uma ferramenta
de grande valia para esse tipo de problema. Porm, implementar um sistema deste tipo vem a ser
um desafio tecnolgico relevante.
Nesse sentido, este trabalho se prope a resolver o problema de armazenamento de arquivos,
propondo uma arquitetura de Cloud Storage para armazenamento de arquivos.
Ao longo trabalho, feita uma anlise dos principais direcionadores de negcio para Cloud
Storage e armazenamento de arquivos, levantando insumos para se projetar uma arquitetura. Tal
arquitetura descrita em nvel de detalhe para que se possa ser implementada.
Finalmente, o trabalho validado atravs de uma avaliao de arquitetura cuja metodologia foi
adaptada de acordo com as caractersticas da equipe de avaliao.
Palavras-chave:
cronizao.
Arquitetura de software, Cloud computing, Cloud storage, Backup, Sin-
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 users 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, Synchronization.
Summary
Lista de Figuras
Lista de Tabelas
xi
Lista de Acrnimos
xii
Introduo
1.1 Definio do problema
1.2 Metodologia . . . . . .
1.3 Fora do escopo . . . .
1.4 Estrutura da dissertao
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Contextualizao e Trabalhos Relacionados

2.1 Cloud Computing . . . . . . . . . . . . . .
2.1.1 Histria de cloud computing . . . .
2.1.2 Definio de Cloud Computing . .
2.2 Cloud Storage . . . . . . . . . . . . . . . .
2.2.1 Histria do armazenamento em rede
2.2.2 Definindo cloud storage . . . . . .
2.2.3 Aplicaes de cloud storage . . . .
2.3 Trabalhos Relacionados . . . . . . . . . . .
2.3.1 Oceanstore . . . . . . . . . . . . .
2.3.2 Windows Azure Storage . . . . . .
2.3.3 Google File System . . . . . . . . .
2.3.4 Ustore . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Cloud Storage Business Drivers

3.1 Definio do Negcio . . . . . . . . . . . . . . .
3.1.1 Principais Vantagens . . . . . . . . . . .
3.1.2 Principais Desvantagens e Ameaas . . .
3.1.3 Identificao dos Principais Stakeholders
3.1.4 Restries do negcio . . . . . . . . . .
3.1.5 Restries tcnicas . . . . . . . . . . . .
3.2 Atributos de Qualidade . . . . . . . . . . . . . .
3.2.1 Metodologia . . . . . . . . . . . . . . .
3.2.2 Resultados . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
2
2
3
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
5
8
8
9
10
10
11
11
12
13
.
.
.
.
.
.
.
.
.
14
14
15
15
16
17
17
18
19
19
3.3
3.4
4
Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Definio da Arquitetura
4.1 Decises arquiteturais . . . . . . . . . . . . . .
4.1.1 Orientao a Servios atravs de REST
4.1.2 Persistncia . . . . . . . . . . . . . . .
4.1.3 Utilizao de DHT . . . . . . . . . . .
4.1.4 Controle de Acesso . . . . . . . . . . .
4.2 Orientao a Servios . . . . . . . . . . . . . .
4.2.1 Camadas de Servios . . . . . . . . . .
4.2.2 Descrio dos servios . . . . . . . . .
4.3 Viso Geral da arquitetura . . . . . . . . . . .
4.4 Camada de Servios Bsicos . . . . . . . . . .
4.5 Camada de Servios Importantes . . . . . . . .
4.6 Modelo de Dados . . . . . . . . . . . . . . . .
4.7 Segurana . . . . . . . . . . . . . . . . . . . .
4.8 Concluso . . . . . . . . . . . . . . . . . . . .
20
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
25
27
28
29
30
30
31
34
37
40
43
44
46
.
.
.
.
.
.
.
.
47
47
48
48
49
50
51
53
54
Concluso
6.1 Principais Concluses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
55
56
56
Avaliacao da Arquitetura
5.1 Processo de avaliao de arquitetura de software
5.2 Equipe de Avaliao da arquitetura . . . . . . .
5.3 Ameaas validao . . . . . . . . . . . . . .
5.4 Metodologia de avaliao . . . . . . . . . . . .
5.5 Execuo do processo de avaliao . . . . . . .
5.6 Cenrios propostos e resultados da avaliao . .
5.7 Consolidao dos Resultados . . . . . . . . . .
5.8 Concluso . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Referncias Bibliogrficas
57
Apndice
62
A Matriz Vantagens e Desvantagens x QAs
63
List of Figures
2.1
Modelos de Servios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
Atributos de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
Diviso em camadas de servio . . . . . . . . . .

Listagem dos Servios . . . . . . . . . . . . . .
Viso da estrutura interna . . . . . . . . . . . . .
Viso de Implantao . . . . . . . . . . . . . . .
Viso de implantao do basic storage . . . . . .
Viso de componentes do basic storage . . . . . .
Insero de dados na DHT . . . . . . . . . . . .
Diagrama de classes do n de armazenamento . .
Estrutura de um servio . . . . . . . . . . . . .
Diagrama de classes do file storage . . . . . . .
Diagrama de sequncia de um backup de arquivo
Modelo de dados para o banco de dados . . . . .
31
32
35
36
38
38
40
41
42
43
44
45
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
List of Tables
3.1
Atributos de Qualidade escolhidos . . . . . . . . . . . . . . . . . . . . . . . .
20
5.1
Consolidao dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
A.1 Matriz Vantagens x QAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.2 Matriz Desvantagens x QAs . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
65
Lista de Acrnimos
11
1
Introduo
Atualmente, tem-se observado um crescimento alarmante no volume de dados mundial.
De acordo com Gantz and Reinsel (2011), esse volume global superou 1 zettabyte em 2010 e
tem previso de alcanar 8 zettabytes em 2015.
Este fato tem ocorrido devido crescente quantidade de aplicativos e dispositivos que geram
contedos para armazenar. Desde textos, e-mails at vdeos em alta resoluo. Alm disso, com
o advento dos dispositivos portteis e a internet mvel, surgiu a necessidade dos usurios de
acessar seus contedos de forma ubqua.
As solues de de backups e sincronizao de arquivos tradicionais j no tm suprido a demanda
crescente dos usurios. Pois, podemos encontrar alguns problemas nessas soluo, tais como:
No permitem acesso de qualquer dispositivo;
Requerem que o usurio esteja conectado a uma rede;
Tem um custo elevado de hardware para serem implantados;
No escalam para o volume crescente de dados.
A utilizao de sistemas de cloud computing e Cloud Storage(Mell and Grance, 2011)

pode suprir essa demanda. Pois esses sistemas trazem benefcios como acesso amplo, escalabilidade e baixo custo de implantao.
Desenvolver uma arquitetura de Cloud Storage para armazenar arquivos nessa escala, pode se
tornar um grande desafio. Pois, alm do desafio tecnolgico inerente a natureza desses sistemas,
tambm existe uma grande necessidade de se entender seu contexto de negcio.
Este trabalho visa analisar o negcio de armazenamento de arquivos atravs de cloud storage,
para obter insumos e projetar uma arquitetura escalvel e segura para armazenar arquivos.
1.1
Definio do problema
O problema que se pretende resolver neste trabalho projetar uma arquitetura para
armazenamento de arquivos de forma elstica, escalvel e segura. Para apoiar esse desenvolvi-
12
1.2. METODOLOGIA
mento, pretende-se responder duas perguntas:
1.2
Quais so os direcionadores de negcio para o uso de Cloud Storage?
Como projetar uma arquitetura que atenda esses contexto?
Metodologia
Para desenvolver este trabalho, a seguinte metodologia foi utilizada:
1.3
Foi feita uma reviso exploratria da literatura, com o objetivo de encontrar os

direcionares de negcio de cloud storage, assim como tcnicas que poderiam ser
utilizadas para projetar a arquitetura;
Das informaes obtidas sobre o contexto de negcio, foram levantados os atributos
de qualidades assim como os requisitos para o sistema;
Com as tcnicas encontradas na reviso, foi projetada uma arquitetura para atender
os requisitos e atributos de qualidade.
Com a ajuda de uma metodologia de avaliao de arquitetura, esse trabalho foi
validado;
Fora do escopo
Os seguintes tpicos foram excludos do escopo para esse trabalho:
1.4
Requisitos e necessidades relativas ao cloud broker (Bohn et al., 2011)

Servios e features na arquitetura que no esto diretamente ligadas com o armazenamento, tais como indexao e busca, APIs externas, entre outros.
Implementao da arquitetura.
Questes de tarifao (billing).
Planos de negcio para sistema de Cloud Storage.
Estrutura da dissertao
O restante da dissertao estar organizada da seguinte forma:
No Captulo 2 feita uma contextualizao sobre Cloud Storage e trabalhos relacionados.
13
1.4. ESTRUTURA DA DISSERTAO

No Captulo 3 so levantados os direcionadores de negcio de cloud storage.
No Captulo 4 apresentada a arquitetura projetada.
No Captulo 5, a avaliao da arquitetura executada.
No Captulo 6 so apresentadas as concluses do trabalho e so levantadas possibilidades para trabalhos futuros.

Finalmente no Apndice A mostrada as tabelas que apoiaram as decises dos
principais atributos de qualidade do Captulo 3.
14
2
Contextualizao e Trabalhos Relacionados
Este captulo visa apresentar uma viso geral de cloud storage, com o objetivo de definir
o conceito de cloud computing, cloud storage e backup online, bem como fazer um levantamento
histrico de sua origem at o estado atual da arte. Alm 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 viso geral dos conceitos de
cloud computing, ou computao em nuvem. Uma breve viso histrica e contextual de cloud
computing ser feita nesta seo.
2.1.1
Histria de cloud computing
Apesar de ter ganhado destaque nos ltimos anos, o conceito de cloud computing no
pode ser considerado recente. Em 1950, o cientista da computao 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 compartilhamento de processamento levaria a um futuro cujo poder computacional ou at aplicaes
poderiam ser vendidas como um servio, tal como energia ou eletricidade. Em 1962, J.C.R Licklider (Dalakovi, 2014a) descreveu um conceito de uma Rede Intergalctica de Computadores,
antes de fazer parte da Agncia de Projetos de Pesquisa Avanada ( Advanced Research Project
Agency - ARPA), que pode ser considerada como a origem da internet. Nesta rede, usurios
poderiam rapidamente localizar e acessar dados e softwares dentro dela e poderiam migr-las
caso necessrio. Este conceito descreve no s a Internet como conhecemos hoje, mas tambm
um dos princpios 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 elstica e infinita. Apesar
da ideia de cloud computing ter surgido h mais de 50 anos atrs, o termo s veio surgir no ano
15
2.1. CLOUD COMPUTING
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 aplicao entregue ao usurio usando o conceito de
software como um servio de forma escalvel e de rpido provisionamento (Salesforce, 2000).
Em 2002, a Amazon lana a plataforma Amazon Web Service (Amazon, 2014b), que disponibiliza
servios como computao e armazenamento em larga escala como um servio. Posteriormente,
em 2006, seria lanado o Amazon Elastic Cloud Computing (Amazon, 2014a), um marco para
cloud computing, sendo o primeiro servio 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 evoluo e a Google, assim como outras organizaes, comeou a oferecer
aplicaes baseadas em browser atravs de servios 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
Definio de Cloud Computing
De acordo com o NIST (Mell and Grance, 2011), Cloud Computing pode ser introduzido
com a seguinte definio que foi traduzida livremente:
Computao em Nuvem um modelo que proporciona um acesso de rede ubquo,
conveniente e sob demanda, para uma reserva compartilhada de recursos computacionais (ex: rede, servidores, armazenamento, aplicaes e servios) que pode
ser rapidamente providas e liberadas com um esforo mnimo de configurao ou
mnima interao com o provedor de servios. Este modelo composto por cinco
caractersticas essenciais, trs modelos de servios e quatro modelos de implantao.
Dentro da definio apresentada acima, importante destacar alguns elementos. O compartilhamento de recursos viabiliza que um recurso computacional ocioso para um usurio seja
utilizado por outros, conforme necessidade. Tambm importante frisar que a expanso ou
encolhimento da nuvem, dever ser feita conforme a necessidade e com o mnimo possvel de
esforo do administrador. Isso viabiliza aplicativos e servios que outrora dependeriam de toda
uma infraestrutura para operar.
Ainda de acordo com o NIST, a Cloud Computing tem cinco caractersticas essenciais. So elas:
Auto servio sob demanda: Um cliente pode prover unilateralmente capacidade

computacional sem necessidade de interao humana com cada servio.
1 https://www.heroku.com/
2 http://azure.microsoft.com
3 https://www.digitalocean.com/
4 http://cloudfoundry.org/index.html
16

Acesso de rede amplo: Capacidades so disponibilizadas sobre a rede e acessadas

por mecanismos padres que promovem o uso por uma plataforma heterogneas de
clientes. Elas podem variar desde de telefones celulares a estaes de trabalho.
Reserva de recursos: Os recursos computacionais do servio so agrupados para
servir mltiplos consumidores, sendo dinamicamente realocadas de acordo com a
demanda. Geralmente o cliente no tem controle ou informaes sobre a localizao
exata do recurso computacional em uso. Porm, pode haver a possibilidade de
especificar esse tipo de informao dentro de uma macro regio.
Elasticidade rpida: Capacidade computacional pode ser provida e liberada, em
alguns casos, automaticamente, para rapidamente escalar dependendo da demanda.
Para o consumidor, a capacidade disponvel frequentemente parece ser ilimitada e
pode ser adquirida em qualquer quantidade e a qualquer hora.
Servio instrumentado: Sistemas em nuvem automaticamente controlam e otimizam
o uso de recursos atravs de instrumentao da capacidade computacional. O uso de
recursos pode ser controlado, monitorado e reportado, provendo transparncia tanto
para o usurio quanto para o provedor.
O termo computao pode ter diversos significados, desde utilizao de hardware a execuo de
um aplicativo especfico. Por esse motivo, foram criados os distintos modelos de servios, que
agrupam o que pode ser entregue como servio. O modelo SPI, que significa Software, Platform,
Infrastructure, utilizado para classificar os sistemas de cloud computing de acordo com o tipo
de servio, como se segue:
Software as a Service (SaaS): O provedor disponibiliza aplicaes que so executadas em uma infraestrutura de cloud computing. Geralmente, essas aplicaes so
utilizadas em um modelo de pagamento por uso e so acessveis a vrios clientes
tanto atravs de um terminal burro, como um browser ou por meio de um software
cliente. O cliente no tem controle sobre a infraestrutura usada pela aplicao.
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 programao, bibliotecas, servios e ferramentas suportadas
pelo provedor. O cliente no tem controle sobre a infra-estrutura utilzada pela
aplicao.
Infrastructure as a Services(IaaS): O provedor disponibiliza para o cliente processamento, armazenamento, rede e outros recursos computacionais bsicos, nos quais
o cliente pode implantar e executar qualquer tipo de software, que inclui sistemas
operacionais e aplicaes. O cliente no tem controle total sobre a infraestrutura
17

que utilizada, mas gerencia recursos como armazenamento, sistema operacionais e
aplicaes em execuo.
A Figura 2.1, extraida de Shivakumar (2014) ilustra os diferentes nveis dos modelos de servios,
com alguns exemplos de ferramentas em cada nvel de servio. Quanto maior o nvel de abstrao,
maior o julgamento de valor sobre o servio que est sendo adquirido e tambm menor o controle
sobre a infraestrutura em uso.
Figure 2.1: Modelos de Servios
Ainda de acordo com o NIST, podemos classificar os sistemas de cloud computing de

acordo com o modelo de implantao. Como se segue:
Nuvem privada: A infraestrutura fornecida para uso exclusivo de uma nica

organizao composta de mltiplos consumidores. Pode pertencer, ser gerenciada e
operada pela prpria entidade, por um terceiro ou alguma combinao entre eles.
Nuvem comunitria: A infraestrutura fornecida para uso exclusivo de uma comunidade de consumidores que tem preocupaes semelhantes (por exemplo, misso,
restries de seguranas, entre outros). Pode pertencer, ser gerenciada e operada
por uma ou mais das organizaes que fazem parte da comunidade, um terceiro ou
alguma combinao entre eles.
Nuvem pblica: A infraestrutura fornecida para uso aberto do pblico em geral.
Pode pertencer, ser gerenciada e operada por uma organizao de negcios, acadmica
ou governamental, ou alguma combinao entre eles.
Nuvem hbrida: A infraestrutura composta por duas ou mais nuvens, que continuam nicas mas so interligadas de forma que se permita a portabilidade de dados e
aplicaes.
18
2.2
2.2. CLOUD STORAGE
Cloud Storage
Uma vez que foi entendida a idia de cloud computing e suas principais caractersticas,
vamos introduzir e analisar conceitos, requisitos e tcnicas envolvidas com cloud storage.
2.2.1
Histria do armazenamento em rede
At o incio da dcada de 1980, os computadores armazenavam dados apenas em sistemas

de arquivos locais, diretamente conectados quelas mquinas. Porm, em 1982, Brownbridge
conseguiu demonstrar o acesso remoto atravs de vrias estaes Linux (Brownbridge et al.,
1982), introduzindo assim o conceito da chamada Network Attached Storage (NAS).
Em 1983, lanado o sistema operacional NetWare Server com o protocolo NCP (Novell, 2014),
que permitia servidores compartilharem arquivos, impressoras, diretrios, comandos remotos,
entre outros recursos computacionais.
Em 1984, a Sun desenvolve o NFS (Sandberg, 1986), que permitiria que servidores compartilhassem seu espao de armazenamento com terminais clientes.
Em 1985, a 3Com lana o 3Server, o primeiro servidor direcionado para armazenamento, que
inclua software e hardware proprietrios, e discos mltiplos.
Em 1988, publicado o artigo A Case of redundant arrays of inexpensive disks (RAID)
(Patterson et al., 1988), que sugeria combinar vrios 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 incio dos anos 90, impulsionados pelo sucesso dos servidores de arquivos de empresas como
Novell, IBM e Sun, vrias empresas passaram a construir servidores de arquivos dedicados.
Ainda nessa poca, a Microsoft lana 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 agncias do governo dos EUA comeam a desenvolver sistemas de computao em
grid de forma que permitam usurios compartilhar recursos sem necessidade de um controle
central.
No incio da dcada de 2000, algumas companhias comearam a oferecer solues 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 lana o Dropbox (Dropbox, 2014). Servio
que passaria a vender backup e cloud storage como uma mercadoria, num modelo utilizado at
os dias atuais.
19
2.2.2
2.2. CLOUD STORAGE
Definindo cloud storage
Cloud storage nada mais que um caso especial de Cloud Computing com um propsito
especfico de armazenar dados.
Dessa forma, baseado na definio dada pelo NIST, podemos definir Cloud storage como
"um modelo que proporciona o armazenamento de dados de forma ubqua, conveniente e sob
demanda a partir de uma reserva de armazenamento compartilhada que pode ser rapidamente
disponibilizada com o mnimo de esforo de configurao ou interao com o provedor de
servios."
Assim como nos sistemas de cloud computing, as cinco caractersticas so aplicveis ao cloud
storage (auto-servio sob demanda, acesso de rede amplo, reserva de recursos, elasticidade
rpida e servio instrumentado).
Alm disso, os trs modelos de servios tambm se aplicam ao cloud storage. possvel
a um cliente adquirir armazenamento como um software, como uma aplicao de backup e
sincronizao; como uma plataforma, no caso em que o provedor oferece, por exemplo, um
banco de dados relacional ou no; ou mesmo como infraestrutura, quando o provedor oferece
armazenamento bruto, que seria um disco virtual para que o usurio armazene documentos,
dados de aplicativos ou qualquer outro tipo de dados.
2.2.3
Aplicaes de cloud storage
De acordo com SNIA (2013), os sistemas de Cloud Storage podem ter vrias aplicaes
dependendo dos objetivos das organizaes que as utilizam. Seguem alguns dos principais
cenrios:
Backup - Em qualquer organizao dados crticos tm que estar seguros, disponveis

e recuperveis para uma verso prvia. Um sistema de cloud storage pode substituir
as solues tradicionais de backup, como por exemplo, fitas magnticas, sendo uma
forma mais segura, barata e prtica de armazenamento de backups.
Arquivamento - As organizaes esto cada vez sendo mais foradas a reter volumes
maiores de dados por longos perodos. Assim como no backup, os sistemas de Cloud
Storage podem substituir as formas tradicionais de arquivamento reduzindo custos e
aumentando a agilidade da recuperao de informao.
Armazenamento de dados de aplicativos - Aplicaes de negcios requerem armazenamento temporrio e permanente, que geralmente disponibilizado por discos
ou solues de armazenamento em rede como NAS ou SAN. Dados de aplicativos
tm requisitos mais crticos de acesso e latncia. Uma soluo de cloud storage pode
trazer vantagem em relao a essas solues tradicionais, tais como facilidade de
backup de aplicativos, reduo de custos, entre outros.
20
2.3
2.3. TRABALHOS RELACIONADOS
Trabalhos Relacionados
Nesta seo, sero apresentados alguns trabalhos que se relacionam com este trabalho,
pois se tratam de sistemas de cloud storage, que foram ou esto sendo utilizados tanto na
academia quanto na indstria. Os trabalhos foram apresentados por ordem de publicao.
2.3.1
Oceanstore
Oceanstore (Kubiatowicz et al., 2000) um projeto concebido na Universidade de

Berkley, que visa fornecer uma plataforma aberta e global para armazenamento de dados.
Em sua concepo, foi idealizada para objetivos como servir de plataforma para aplicaes
groupware (e-mail, calendrio, lista de contatos), repositrio de dados de grande volume para
grupos cientficos ou como servidor para streaming.
A plataforma Oceanstore tem duas premissas: ser construda a partir de um grande grupo de
servidores no confiveis, pois equipamentos quebram sem advertncia e no se pode confiar a
durabilidade de um dado aos mesmos; a segunda premissa que os dados so nmades, pois em
um sistema de grandes propores a localidade dos dados muito importante. O Oceanstore faz
cache dos dados em vrias localidades para manter a escalabilidade do sistema, abrindo mo da
consistncia dos dados.
Cada objeto no OceanStore armazenado com um nome nico gerado pseudo-aleatoriamente,
chamado GUID (Global Unique Identifier). Alguns GUID funcionam como um diretrio,
contendo uma lista de GUIDs, dando a possibilidade da criao de uma estrutura semelhante a
uma rvore.
O controle de acesso feito em basicamente duas operaes: restrio de leitura e restrio de
escrita.
Cada objeto que no pblico, encriptado com uma chave nica. Cada usurio que tem
permisso de leitura, recebe essa chave para desencriptar. Para revogar o acesso em dado objeto,
as replicas so reencriptados com uma nova chave.
Para prevenir escritas no autorizadas, cada escrita assinada digitalmente e cada objeto tem
uma lista de controle de acesso indicando quem pode alterar aquele objeto. A restrio de escrita
feita pelo server que verifica se o usurio que tenta escrever naquele objeto tem acesso ao
mesmo.
Cada objeto armazenado no OceanStore pode ter uma rplica em qualquer servidor. Para localizar
esses objetos, conta com dois algoritmos. O primeiro, um algoritmo probabilstico e rpido,
que toma a premissa que existe uma grande probabilidade de um dado acessado frequentemente
residir em um servidor prximo. O segundo um algoritmo hierrquico mais lento, porm mais
confivel.
21
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 produo desde o final de 2008.
O WAS armazena dados em trs formatos: BLOBs, tabelas ou filas para entrega de mensagens.
O projeto do WAS, levou em considerao pedidos de vrios clientes, que direcionou algumas
decises de projeto. Entre elas esto consistncia forte, armazenamento global e escalvel,
recuperao de desastres, armazenamento multi-tenant.
O WAS roda em mltiplos servidores espalhados ao redor do mundo. Ele possui uma camada
que prov gerenciamento de ns, monitoramento da status, e implantao do servio para o
sistema. Essa camada chamada de Fabric Controller.
Os ns de armazenamento do Windows Azure esto organizados em clusters, denomidados
Storage Stamp, que so gerenciados pelos Location Service, que um servidor localizado em
uma dada localizao, como Europa, Amrica do Norte e sia.
Existem dois engenhos de replicao dentro do WAS, o chamado Intra-Stamp, que responsvel
pela replicao dentro do cluster de armazenamento, e o Inter-Stamp, que armazena dados de
um Stamp para outro, para uma recuperao em caso de desastre.
2.3.3
Google File System
O Google File System (Ghemawat et al., 2003), ou GFS um sistema de arquivos

distribudo 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 no so confiveis.
O sistema de arquivo formado por uma grande quantidade de hardware barato. Alm disso,
assume-se que arquivos so naturalmente grandes. Toda a otimizao existente no GFS foi feita
para arquivos grandes. O GFS tambm assume que arquivos so modificados anexando-se dados
no fim dos mesmos.
O GFS suporta as operaes usuais em sistemas de arquivos, tais como criao, deleo, abertura,
fechamento, leitura e escrita de arquivos. Contudo, ele ainda introduz duas novas operaes:
insero, em que se escreve no fim do arquivo, e snapshot, operao que cria uma cpia do
arquivo com um custo muito baixo.
No GFS, ao contrrio do OceanStore, existe um servidor central, denominado servidor mestre
e vrios outros servidores de chunks5 . O servidor mestre sabe da existncia de todos os outros
servidores e responsvel pelo armazenamento de metadados, que so os arquivos, os chunks
que compem cada arquivo e a localizao de cada chunk. O servidor mestre armazena todos os
metadados em memria.
Cada arquivo composto por chunks de 64MB, e eles so armazenados no sistema de arquivo
5 Chunks
mento
so pequenos pedaos dos quais se compes um arquivo, registro, ou qualquer unidade de armazena-
22
local dos chunk servers.

Os chunks so replicados de acordo com a necessidade. Existe um controle para que chunks
novos no criem muitas rplicas, para evitar sobrecarga na escrita de novos arquivos. O controle
da replicao do GFS feito atravs do mestre.
2.3.4
Ustore
Ustore (Duro et al., 2013) uma plataforma de Cloud Storage em nuvem privada
desenvolvido para armazenar arquivos, fazendo backup e sincronizao deles.
Uma diferena marcante na plataforma Ustore que ele pode utilizar discos ociosos das mquinas
de uma corporao, formando uma nuvem privada com as estaes de trabalho.
Para que as estaes se comuniquem, utilizado uma rede overlay peer to peer (P2P), que
implementa o protocolo conhecido como JXTA6 .
A arquitetura do Ustore leva em considerao quatro atributos de qualidade como pilares de
suas decises arquiteturais, que so: escalabilidade, otimizao das interaes, disponibilidade e
segurana.
Na rede overlay existe um tipo de peer especial que tem a responsabilidade de configurar a rede e
manter rotas entre estaes diferentes. Esse peer chamado de Super Peer, e precisa ser mantido
em um servidor conhecido por todos os peers, como uma espcie de servidor central. Porm, sua
ncia funo manter a conectividade entre os peers.
Alm da existncia do superpeer, existem os chamados peers servidores, que implementam uma
gama de servios e so localizados pelos peers clientes, atravs do anncio de seus servios na
rede JXTA.
Finalmente os simple peers, ou apenas clientes, que so peers que so utilizados para enviar ou
recuperar arquivos da nuvem, assim como utilizar o espao ocioso na mquina do usurio para
salvar arquivos de outros usurios.
A replicao no Ustore se d atravs de um algoritmo estatstico, em que se registra o histrico
de conexo de cada cliente, traando assim um perfil do mesmo. As replicados dos backups
so enviados a outros clientes que tm perfil semelhante ao do usurio, otimizando assim a
disponibilidade do arquivo, mantendo um nmero mnimo de rplicas.
6 https://jxta.kenai.com/
23
3
Cloud Storage Business Drivers
Neste captulo ser feita uma anlise nos direcionadores de negcio de Cloud Storage, e
a partir da sero desenvolvidos os business drivers. A partir dos business drivers, possvel
obter insumos para pautar as decises arquiteturais, tais como os Requisitos do sistema, assim
como os principais atributos de qualidade.
Esses insumos tambm sero teis para, durante a avaliao da arquitetura, verificar a conformidade dessa com as necessidades de negcio.
3.1
Definio do Negcio
Embora cloud storage ja tenha sido definido anteriormente, necessrio ressaltar que o
conceito de armazenamento em nuvem bastante abstrato. Neste trabalho, os esforos sero
concentrados em sistemas de armazenamento de arquivos.
Deseja-se utilizar a elasticidade da nuvem para armazenar arquivos, garantindo fatores como a
disponibilidade, segurana, escalabilidade e acesso ubquo aos dados armazenados pelos usurios,
para uso de backup, sincronizao de arquivos ou arquivamento.
Esta soluo ir representar duas das maiores tendncias na Tecnologia da Informao (Marston
et al., 2011) a eficincia tecnolgica, pois o poder computacional melhor utilizado atravs
de recursos de hardware e software escalveis e agilidade de negcio, que possibilita empresas
pequenas ou em estgio inicial, ter acesso a um elevado poder computacional.
Em Grossman (2009), ENISA (2009) e Aljabre (2012) possvel observar algumas das principais
vantagens e desvantagens da adoo de Cloud Computing por empresas. A partir delas, foi
possvel observar tambm sua aplicabilidade para Cloud Storage.
3.1.1
Principais Vantagens
Acesso ubquo - Provedores de servios de armazenamento em nuvem podem

disponibilizar vrias interfaces de acesso diferentes para seu servio, possibilitando,
assim, aos usurios, acesso aos dados atravs de formas e dispositivos distintos.
24
3.1. DEFINIO DO NEGCIO

3.1.2
Reduo de custos - Organizaes podem ter acesso a recursos computacionais

com custo reduzido, uma vez que essas aplicaes usufruem dos recursos que est
na nuvem do provedor do servio. Essa reduo de custos engloba aquisio e
manuteno tanto de hardware como de software.
Habilidade de crescimento sob demanda - possvel para um pequeno negcio
usar Cloud Computing, com um pequeno custo, e com o crescimento do negcio,
aumentar a capacidade computacional sob demanda.
Efetividade computacional - possvel prover servios, continuidade e segurana
mais efetivamente do que solues tradicionais de TI.
Escalabilidade - Arquiteturas em Cloud Computing mostram-se amplamente escalveis Grossman (2009).
Concentrao de recursos -O compartilhamento de hardware fsico proporciona
uma perimetrizao mais barata assim como um controle de acesso fsico mais
eficiente.
Principais Desvantagens e Ameaas
A adoo de cloud storage pode apresentar um conjunto de benefcios, conforme apresentado anteriormente. Entretanto, relevante se considerar os pontos fracos, ameaas e
preocupaes relativas ao uso de cloud storage. A lista abaixo apresenta algumas das principais
desvantagens de utilizar um servio de nuvem para armazenamento.
Perda de governana das informaes - Em se utilizando do servio da nuvem

para armazenamento, o cliente est cedendo ao provedor de servio controle sobre
informaes de sua empresa. Alguns sistemas de Cloud Storage, como o Mega
(Security, 2013), armazenam de forma que somente o proprietrio do contedo, ou
algum com sua permisso, possa acessar aquele contedo.
Vnculo com o servio - Uma vez que um usurio adota um servio de armazenamento em nuvem, mudar para outro provedor de servio, ou voltar para abordagens
tradicionais de armazenamento pode tornar-se invivel devido ao grande nmero de
dados armazenados.
Segurana - Apesar de armazenamento em nuvem ter um nvel de segurana satisfatrio, sempre existe um risco permanente da mesma ser exposta, e dados de uma
organizao sejam acessados por pessoas no autorizadas.
Dependncia de conectividade - Para se acessar um servio de armazenamento em
nuvem, necessrio uma conexo de rede com o provedor do servio. A perda dessa
25

conexo, implicar na impossibilidade temporria de acesso a dados, que podem ser
crticos.
3.1.3
Indisponibilidade dos servios - Apesar dos sistemas de cloud storage terem um

nvel 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 benefcio, por trazer reduo de custos, tambm pode ser uma preocupao em
relao a confidencialidade e segurana. Principalmente em um ambiente de nuvem
pblica, onde vrias organizaes compartilham o mesmo recurso.
Identificao dos Principais Stakeholders
Para desenvolver uma arquitetura para um sistema precisamos identificar o principais

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 - So pessoas ou organizaes que mantm um relacionamento

e usam os servios de um Cloud Provider. No nosso caso, so os indivduos ou
corporaes que utilizam o sistema de Cloud Storage para armazenar arquivos. Eles
necessitam de uma ferramenta para fazer backup e sincronizao de arquivos online.
Coud Provider - Uma pessoa, grupo ou entidade responsvel por manter o servio
disponvel para as partes interessadas. No caso do sistema de Cloud Storage, que
hospedaria e manteria o sistema de cloud storage. Alm do servio em si, tambm
precisa de um mdulo em que possa administrar, mensurar e manter o servio.
Cloud Auditor - Uma organizao que pode conduzir uma auditoria independente
dos servios de cloud, das operaes, performance e segurana da implementao da
cloud. Devem possuir ferramentas que se possa mensurar um grupo de mtricas para
se realizar essas auditorias.
Cloud Broker - Uma entidade que gerencia o uso, performance e entrega dos servios
de cloud, e negocia a relao entre Cloud Provider e Cloud Consumer. Tm a
necessidade de um mdulo que possa gerenciar a nuvem, mensurar o uso e taxar os
usurios.
Cloud Carrier - Uma organizao intermediria que prov conectividade e transporte
de servio de Cloud Providers para Cloud Consumers. Tipicamente so os provedores
de internet.
26
Para o escopo desse trabalho, sero focadas as necessidades relacionadas aos grupos de Cloud
Consumers, que sero chamados de usurios finais, ou apenas usurios, e os Cloud Providers,
que sero denominados de provedores de servios.
3.1.4
Restries do negcio
Adicionalmente, para o desenvolvimento de qualquer arquitetura, imperativo se observar as restries que o negcio impe ao software. Em Khajeh-Hosseini et al. (2012) so
apresentadas algumas dessas restries que pode afetar um sistema de cloud computing. Dentre
elas, destacamos algumas:
3.1.5
Custos - O custo de utilizao ou implantao de um sistema de cloud storage no

pode ter um impacto financeiro considervel, seja relativo ao custo de implantao
de uma nuvem privada interna, ou aquisio do servio atravs de um provedor.
Mudanas organizacionais - O processo de mudana para utilizao de solues
em nuvem ocasionar em um impacto organizacional. O tipo de mudana varia de
organizao para organizao. Alguns tipos de mudanas que podem ocorrer so em
relao contabilidade, segurana, geografia, suporte e at ao trabalho dos usurios
finais.
Restries tcnicas
Assim como no caso das restries de negcio, relevante listar as restries tcnicas
para evitar surpresas no desenvolvimento de uma arquitetura. Algumas delas so encontradas
em sistemas de cloud storage:
Teorema de Brewer - Conhecido tambm como teorema do CAP, foi demonstrado

em Gilbert and Lynch (2002) e prova que no possvel em um sistema computacional
manter a consistncia, disponibilidade e a tolerncia partio simultaneamente. Isso
de grande relevncia para sistemas de cloud storage, dado que a disponibilidade
essencial, e geralmente se opta entre a consistncia e a tolerncia partio.
Limitao do hardware - Apesar de elstico, o volume armazenado por um sistema
de cloud storage limitado pelo armazenamento do hardware (fsico ou virtual) que o
hospeda. Assim como sua largura de banda ser limitada pela banda da comunicao
entre o usurio e o provedor do servio.
Acordo de nvel de servio (Service Level Agreement - SLA) - uma parte do
contrato entre o provedor de servio e o usurio que estabelece mtricas mnimas
para o funcionamento do servio. So exemplos de mtricas comuns de SLA para
servio de armazenamento em nuvem a disponibilidade, o tempo de resposta, taxa de
erros, entre outras.
27
3.2
3.2. ATRIBUTOS DE QUALIDADE
Atributos de Qualidade
Em um sistema computacional, as funcionalidades so fundamentais. Pois a partir das

necessidades dos usurios, surge a demanda para o software. Contudo, os atributos de qualidade
tambm so relevantes para guiar as decises arquiteturais.
A qualidade de software pode ser avaliada pelo grau em que o software possui de combinao
dos atributos de qualidade, que so caractersticas importantes e devem ser priorizadas no desenvolvimento do software. Existem vrias formas de se expressar atributos de qualidade, tais como
funcionalidade, negcio, segurana, entre outras.
A norma ISO/IEC 25010.2 ISO/IEC (2010) define um modelo de qualidade de produto que
composto por oito caractersticas que relatam tanto propriedades estticas, quanto dinmicas de
um sistema de computao.
A Figura 3.1 mostra o modelo de qualidade de software apresentado na norma. Ela divide a qualidade de software em oito caractersticas que so adequao de funcionalidade, confiabilidade,
eficincia de performance, operacionalidade, segurana, compatibilidade, manutenibilidade e
transmissibilidade. Essas caractersticas so subdivididas em trinta e oito sub-caractersticas que
auxiliam na descrio da qualidade de um software.
Figure 3.1: Atributos de Qualidade
3.2.1
Metodologia
Para definir os atributos de qualidade, a seguinte metodologia foi utilizada: Por meio de
reviso bibliogrfica foram levantadas as principais vantagens da utilizao de cloud storage as
desvantagens, preocupaes e ameaas. Alm disso, tambm foram listados segundo a norma
28
3.3. REQUISITOS
ISO/IEC 25010, os principais atributos de qualidade de um produto de software.

Em seguida, foi feita uma matriz, onde as colunas representam as vantagens e desvantagens
enquanto as linhas representam os atributos de qualidade. Essa matriz foi preenchida com o
valor 1, caso a presena do atributo de qualidade contribua para uma das vantagens ou amenize
uma desvantagem, ou zero caso contrrio. Dessa forma, foi possvel selecionar os atributos de
qualidade de forma que se possa maximizar os benefcios e atenuar as perdas, selecionando os
atributos de qualidade com maior nmero de 1s seriam considerados os prioritrios.
3.2.2
Resultados
Os atributos de qualidade foram enumerados de acordo com as Tabelas A.1 e A.2

disponveis no Apndice A. Como se pode observar, os principais atributos de qualidade eleitos
esto de acordo com a Tabela 3.1.
ID
Q1
Q2
Q3
Q4
Q5
Q6
Q7
Nome
Disponibilidade
Utilizao de recursos
Confidencialidade
No-repdio
Autenticidade
Portabilidade
Adaptabilidade
Table 3.1: Atributos de Qualidade escolhidos
A ordem dos atributos no necessariamente representa a ordem de prioridade nas

definies arquiteturais.
Se analisarmos a lista de atributos, podemos observar que precisamos de um sistema que
mantenha-se o maior tempo possvel online (Q1), que tenha o menor custo possvel (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, alm dos atributos de qualidade, os requisitos tambm

guiam as decises arquiteturais. De acordo com Sommerville (2007), o verdadeiro teste de uma
arquitetura recai sobre quo bem ela atende os requisitos funcionais e no-funcionais depois de
implantada.
Para a definio de requisitos funcionais e no-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 (Microsoft, 2014), entre outros.
Alm disso, tais requisitos foram revistos por analistas com experincia na indstria nesse
segmento. A partir da, foi possvel listar os seguintes requisitos funcionais e no-funcionais:
29
3.3. REQUISITOS
R1 - Upload (backup) de arquivos

O usurio final pode enviar arquivo para seu drive virtual na nuvem. Uma vez que
esse arquivo enviado para nuvem, dever permanecer at que o usurio decida
excluir ou modificar aquele arquivo. O usurio poder enviar arquivos para nuvem
de mltiplos dispositivos de forma ubqua.
R2 - Download (restore) de arquivos
Uma vez que um usurio 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 - Excluso de arquivos
O usurio pode excluir arquivos que tenham sido previamente salvos na nuvem. No
se pode fazer download de arquivos excludos. Uma vez que o arquivo tenha sido
deletado, o usurio pode recuper-lo dentro de um perodo definido pelo provedor do
servio.
R4 - Compartilhamento de arquivos
O usurio pode compartilhar qualquer arquivo ou diretrio 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 tambm o ser. A qualquer
momento o proprietrio do arquivo poder revogar o acesso quele arquivo ou pasta.
R5 - Publicao de arquivos
Assim como um usurio pode compartilhar arquivos, ele tambm pode public-los,
garantindo acesso aos arquivos compartilhados para todos os usurios da nuvem.
Assim como no compartilhamento, a qualquer momento o proprietrio pode revogar
acesso aos arquivos.
R6 - Pesquisa de arquivos
O usurio pode pesquisar arquivos dentro de seu disco, seja por nome de arquivos,
seja pelo contedo dos arquivos.
R7 - Cadastro de usurios
O provedor de servios ter acesso a um cadastro de usurios, que permitir incluir,
modificar ou remover usurios. Tambm ser possvel habilitar uma funcionalidade
para que o prprio usurio efetue seu cadastro.
R8 - Tarifao de usurios
O provedor de servios ter ferramentas que possa mensurar a utilizao da nuvem,
para que possa taxar o usurio de acordo com os termos de servios estabelecidos
entre as partes.
30
3.3. REQUISITOS
R9 - Expanso ou encolhimento da nuvem

O provedor de servios dever ser capaz de aumentar ou diminuir a capacidade da
nuvem, seja atravs de software, ou mesmo atravs da adio 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 usurio. No podemos estipular um valor exato, uma vez que, esse
valor depende do valor contrato entre usurio e provedor.
R11 - Disponibilidade
O sistema deve manter-se disponvel por um perodo igual ou superior quele firmado
no SLA entre usurio e provedor. importante observar que alguns contratos estipulam um downtime mnimo para que o servio possa ser considerado indisponvel.
R12 - Resilincia 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 excees para este requisito,
especificando uma taxa mxima de falhas irrecuperveis que podem ocorrer.
R13 - Integridade dos dados
Os dados armazenados no sistema no devem sofrer modificaes indesejadas, que
venham a corromper os dados armazenados. O SLA poder especificar uma taxa
mxima de dados corrompidos.
R14 - Consistncia de dados
Mesmo se tratando de um sistema distribudo, o sistema deve manter a consistncia
das informaes nele armazenadas, havendo apenas uma nica verso de um dado
qualquer. Ento, se por exemplo, um cliente escreve um arquivo em um n, ele deve
acessar o mesmo contedo em outro n do sistema.
R15 - Durabilidade
Uma vez armazenados, os dados contidos no sistema estaro em definitivo, no sendo
excludos pelo prprio sistema ou fatores externos, salvo se excludo pelo proprietrio
do arquivo.
R16 - Autenticao
Para garantir a segurana do sistema, para toda ao executada pelo sistema, o autor
daquela ao dever estar devidamente identificado atravs de credenciais seguras.
R17 - Autorizao
Em adio Autenticao, para cada ao realizada pelo usurio, dever se verificar
31
3.4. CONCLUSO
se ele tem a permisso para execut-la, impedindo assim, ao usurio executar aes
que o mesmo no tem direitos.
3.4
R18 - Auditoria
Cada ao de um usurio, alm do mesmo estar devidamente identificado e autorizado,
o sistema tambm manter um registro de todas as aes crticas executadas pelo
mesmo. Os requisitos Autenticao, Autorizao e Auditoria completam a segurana
do sistema.
R19 - Interface externa
O sistema dever prover interfaces para o desenvolvimento de aplicaes de terceiros,
que possam usar o armazenamento em nuvem como plataforma, respeitando todos os
requisitos listados anteriormente.
Concluso
A partir de uma anlise do negcio de cloud storage e backup online, foi possvel
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, possvel tomar decises arquiteturais de forma
que os satisfazem, priorizando os principais atributos de qualidade.
Alm disso, deveremos utilizar os atributos de qualidade na avaliao da arquitetura proposta,
validando assim este trabalho
32
4
Definio da Arquitetura
Neste captulo, ser apresentada a arquitetura de software para resolver o problema
proposto. A partir da anlise de negcios, temos os requisitos e atributes de qualidade que
devero ser satisfeitos.
Inicialmente foram documentadas todas as principais decises arquiteturais para o sistema, e,
tomando essas decises como diretrizes, a arquitetura foi projetada.
4.1
Decises arquiteturais
Um conhecido problema em projetos de arquitetura de software a falta de clareza

nas justificativas sobre o seu projeto. As decises arquiteturais esto embutidas no projeto da
arquitetura. Desta forma, o conhecimento sobre as decises arquiteturais perdido durante a
execuo do projeto. Com base nessas informaes, Jansen and Bosch (2005) prope documentar
a arquitetura como um conjunto de decises arquiteturais.
Decises arquiteturais podem ser definidas como uma descrio de um conjunto de adies, subtraes e modificaes da arquitetura de software, da linha de raciocnio, das regras e restries
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 decises arquiteturais.
4.1.1
Orientao a Servios atravs de REST
Arquitetura Orientada a Servios (Josuttis, 2007) ou SOA (do ingls Software Oriented
Architecture) um paradigma de pensamento que leva a uma arquitetura concreta. SOA tem
como objetivo aumentar a flexibilidade do negcio.
SOA possui alguns direcionadores, tais como sistemas distribudos, diferentes provedores e
heterogeneidade. Esses so conceitos que combinam com os drivers de negcio de um sistema
33
4.1. DECISES ARQUITETURAIS
de cloud storage. Alm disso, os direcionadores do SOA esto de acordo com os atributos de
qualidades indicados no Captulo ch:business.
Em uma arquitetura orientada a servios, o software decomposto em servios, unidades lgicas
que representam um grupo de funcionalidade de negcios. Os servios so projetados de forma
a abstrair todo o seu funcionamento interno, de forma que pessoas no tcnicas possam entender
o papel do servio dentro do ecossistema do negcio. Esses servios podem ser heterogneos,
sendo implementados em diferentes tecnologias, em hardwares diferentes, ou at mesmo em
provedores diferentes.
Dados que estes servios so heterogneos, importante que eles se comuniquem facilmente.
Este conceito chamado de interoperabilidade, e o segundo conceito de SOA, sendo o
primeiro os servios.
O ltimo conceito de SOA o baixo acoplamento, que significa minimizar a dependncia
entre os servios. Assim, modificaes tm efeitos mnimos e o sistema continua parcialmente
funcional ainda que uma parte do sistema esteja quebrada.
A opo da abordagem SOA ocorreu, entre outros motivos, pelas suas vantagens apresentadas
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 no disponibilidade de algum servio, alm de diminuir o impacto em
modificaes nos servios;
Reuso, servios podem ser reutilizados para funes comuns dentro do sistema de
cloud storage. Alm disso, servios existentes podem ser reutilizados em desenvolvimento de novos sistemas de software;
Manutenibilidade, como consequncia do baixo acoplamento, a manuteno do
sistema feito apenas no servio que est sofrendo alteraes, no havendo modificaes de grande impacto nos demais, agilizando o processo de melhoramento
contnuo do software;
Interoperabilidade, dado que cada servio independente de hardware ou mesmo
de tecnologia de desenvolvimento, mantendo-se uma interface de comunicao bem
definida.
Entretanto, essa opo trar pontos adversos, que devero ser considerados no restante do projeto
do sistema de software. So elas:
Aumento da complexidade, visto que cada servio executado de forma independente, a interoperabilidade ter um custo: o maior nmero de camadas de software
34

para comunicao entre os servios; perda de performance, que tambm consequncia da complexidade da abordagem SOA. Isso poder afetar o tempo de resposta do
sistema, que apesar de importante, no um dos principais atributos de qualidade do
sistema;
Perda de robustez, pelo fato de que transaes podem envolver vrios servios,
nesse caso, no possvel garantir a atomicidade das mesmas. Esse ponto dever ser
observado nas demais decises e design da soluo;
Segurana, pode ser um problema relevante, dado que como os servios executam de
forma distribuda e independente, ento um agente malicioso pode se passar por um
servio e conseguir acesso a informaes no autorizadas.
Outro aspecto entre o casamento entre SOA e Cloud Computing pode ser justificado de acordo
com e HuiMin Zhang (2012) que declara as seguintes afirmaes:
SOA pode ajudar a construir o ambiente de Cloud Computing;
SOA e Cloud Computing so complementares;
Cloud Computing fornece uma realizao de SOA;
SOA e Cloud Computing podem se misturar.
Finalmente, na abordagem SOA para o sistema de Cloud Storage, dever ser implementado utilizando o padro de projeto SOA chamado camada de servios (Erl, 2009), que
consiste em vrias camadas de inventrios de servios, que so servios agrupados por afinidade.
Funciona como o estilo arquitetural em camadas em softwares tradicionais. As camadas sero
apresentadas mais adiante neste mesmo Captulo.
4.1.2
Persistncia
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 no, para armazen-los. Porm, um sistema de cloud storage, por definio, utilizado para
guardar dados de forma segura e escalvel, assim como os sistemas de gerenciamento de banco
de dados.
Logo, optou-se por no 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 prprio ambiente de cloud storage para se guardar tanto os contedos dos arquivos, que sero denominados de
dados, como as metainformaes sobre o sistema de arquivo, que sero chamados de metadados.
comum em sistemas de arquivos distribudos (DFS) (Boch, 2012) subdividir o armazenamento
35
em duas unidades, sendo uma para contedo dos arquivos (dados) e outra para metadados.
Em Subashini (2011) podemos observar um exemplo de utilizao de cloud storage para armazenar metadados de forma eficiente e segura. Nesse trabalho, a segurana obtida atravs da
fragmentao de dados sensveis.
Em Jiang et al. (2012) podemos observar que possvel utilizar um ambiente de cloud para
implementar uma arquitetura de cloud flexvel e escalvel, abrindo mo da consistncia imediata.
Nesses trabalhos, a consistncia atingida atravs da chamada consistncia eventual, em que os
dados salvos no ns distribudos em um certo intervalo de tempo aps sua incluso.
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 distribudo, por isso elimina pontos nicos de falha. Tambm
importante considerar a portabilidade e adaptabilidade, visto que devido no necessidade de
um software externo para armazenar metadados, no h dependncia de sistema operacional,
ambiente ou qualquer situao que restrinja o uso de um software. Ou seja, na fase de implantao do software, ele elimina o pr-requisito de um software de um sistema de gerenciamento
de banco de dados, e no requer a manuteno do mesmo na fase de produo.
Contudo, uma consequncia dessa deciso arquitetural ser o maior esforo de implementao,
visto que utilizar um sistema de gerenciamento de banco de dados seria mais rpido. Um aspecto
importante nesse sentido, seria manter o baixo acoplamento, para flexibilizar a utilizao 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 memria, bancos de dados externos entre outros. Porm, nesse
trabalho, utilizaremos apenas o cloud storage como armazenamento de metadados. Assim como
na implementao, a manutenibilidade outro ponto a se considerar, pois da mesma forma que a
implementao, utilizar um banco de dados externo tornaria mais fcil a manuteno do sistema.
Finalmente, a falta de segurana uma ameaa importante, pois esses metadados no podero
ser acessados por pessoas no autorizadas.
4.1.3
Utilizao de DHT
Em um sistema de cloud storage, os dados so armazenados em diversos ns. Assim, um

problema que ocorre, a localizao desses dados. Deve-se haver uma estratgia para se definir
tanto para em qual n um certo dado ser armazenado, assim como, de qual local ser possvel
recuperar esse dado rapidamente, sem tornar a busca custosa ou lenta.
A soluo adotada para este problema a utilizao de uma distributed hash table (DHT)
(Balakrishnan et al., 2003). Como o prprio nome diz, uma DHT no nada mais que uma
estrutura de tabela de hash distribuda em vrios ns. Uma DHT tipicamente contm duas
operaes bsicas: insero de objetos (put), no qual se associa uma chave a um dado objeto e
esse objeto armazenado na tabela; e recuperao (get) na qual, a partir da chave de um objeto,
36
que conhecida, pode-se recuperar aquele objeto na DHT.

Em geral, os algoritmos de DHT lidam com trs problemas bsicos:
Mapear chaves com ns de forma balanceada: Cada n deve conter aproximadamente a mesma quantidade de dados para evitar problemas de sobrecarga de um dado
n. Geralmente esse problema resolvido utilizando uma funo de hash tanto para
a identificao do ns (ex: o endereo IP do n) quanto para a chave em questo, e
feita uma correlao entre eles;
Redirecionar uma requisio para o n correto: Qualquer n que recebe uma
requisio para um dado n, deve ter a capacidade de redirecionar a requisio para
o n correto. Esse redirecionamento pode conter vrios saltos at se alcanar o n
em questo; e
Construir tabelas de rotas: Para redirecionar as requisies, cada n deve conhecer
os seus ns mais prximos. Um exemplo para esse caso a disposio de ns em
anis, onde cada n conhece o prximo, e pode redirecionar mensagens at que a
mesma alcance seu destinatrio.
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 so distribudos em vrios ns, e cada n
responsvel pelo subconjunto de hashes. Suas responsabilidades incluem armazenamento,
replicao e busca. Essa abordagem ser descrita em maiores detalhes na seo 4.3.
As principais vantagens dessa deciso arquitetural so a escalabilidade, j que os dados so
armazenados de forma distribuda e no h um n central para receber as requisies, e a tolerncia a falhas, visto que no h um ponto nico de falha. Alm disso os sistemas de DHT tratam
problema como a entradas e falhas de ns, nos quais as tuplas devem ser realocadas para novos
ns em caso de desconexo de algum n ou a entrada de novos ns 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 preocupao em relao a essa deciso seria em relao segurana, uma vez que um
agente mal intencionado poderia se passar por um n para receber ou obter dados confidenciais.
Alm disso, de acordo com o teorema de Brewer (Gilbert and Lynch, 2002) impossvel manter
a consistncia dos dados e simultaneamente manter a sua distribuio e a disponibilidade.
4.1.4
Controle de Acesso
Uma preocupao constante em Cloud Storage, a segurana dos dados. Um sistema

de controle de acesso necessrio tanto para proteger a confidencialidade dos arquivos nele
armazenados, como evitar que um agente malicioso remova arquivos de grande valia.
37
4.2. ORIENTAO A SERVIOS
Alm disso, uma funcionalidade importante para esse sistema o compartilhamento de arquivos,
que permite que um usurio conceda ou revogue acesso a outros usurios.
Finalmente, os metadados do sistema tambm precisam ser mantidos em segurana, pois atravs
deles possvel remontar o sistema de arquivo dos usurios do sistema.
Uma possvel soluo para acesso a arquivos e compartilhamento, implementar um sistema
de controle de acesso discricionrio (Sandhu and Samarati, 1994). Em um sistema de acesso
discricionrio, cada usurio tem um conjunto de autorizaes sobre cada objeto, que, no caso do
sistema proposto, seriam os arquivos, e os modos de acesso que aquele usurio tem acesso, tais
como escrita ou leitura. Para cada acesso determinado objeto, verificado se existe alguma
autorizao para aquele tipo de acesso ao objeto pelo usurio. Se existe, o acesso permitido,
caso contrrio, negado.
Alm disso cada proprietrio de um recurso, tem o direito de modificar as autorizaes para cada
usurio, garantindo acesso ou revogando caso necessrio.
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 algum autorizado a esses dados tenham
acesso aos mesmos.
Uma vantagem clara dessa deciso o aumento da segurana do sistema, que no havia sido
priorizada em nenhuma das decises anteriores. Porm, o custo desse controle de acesso, somado
com a encriptao e decriptao de dados, consumir mais recursos do sistema, impactando
negativamente no tempo de resposta, na escalabilidade e na utilizao de recursos.
4.2
Orientao a Servios
Como foi demonstrado na seo anterior, a arquitetura em concepo dever utilizar o

paradigma de orientao a servios. Portanto, deve-se listar todos os servios que faro parte da
arquitetura e como eles iro se relacionar entre si. Tambm foi decidido utilizar uma abordagem
com o padro de projeto de camada de servios para que o sistema tenha uma organizao
de negcio mais clara, alm de ser uma forma de encapsular a lgica de toda uma camada de
servios, contribuindo ainda mais para o baixo acoplamento do sistema.
4.2.1
Camadas de Servios
A Figura 4.1 mostra a diviso lgica dos servios do sistema. A camada fundamental
do sistema a camada de servios bsicos. Essa camada responsvel pelo armazenamento,
recuperao e resilincia de dados e metadados do sistema. Ela ter a funo de camada de
persistncia para as demais camadas, sendo uma plataforma para as outras camadas armazenarem
dados e metadados. Os dados armazenados na camada de servios bsico so tuplas chave-valor.
Os valores so salvos de forma bruta, como um stream de bytes, sem haver qualquer anlise ou
semntica associada. Acima da camada de servios bsicos, encontra-se a camada de servios
38
Figure 4.1: Diviso em camada de servios
importantes, ou de armazenamento de arquivos. Por meio dessa camada possvel se manter um

sistema de arquivos de nuvem, com todas as operaes bsicas sobre arquivos virtuais, tais como
enviar arquivos, recuperar arquivos, compartilhar arquivos, renomear arquivos, etc. A camada
de servios importantes utiliza os servios bsicos como plataforma para salvar os arquivos,
dividindo-os em chunks, assim como em um sistema de arquivos distribudos (Boch, 2012).
Por fim, existe a camada de servios desejveis, que utiliza as camadas de servios bsicos e
importantes para executar operaes adicionais para um sistema de cloud, que podem agregar
funcionalidades, oferecendo alguns diferenciais para os usurios. Exemplos de servios desejveis so: indexao de contedo, deduplicao, recomendao de contedo, ferramentas
administrativas, entre outros.
A camada de servios desejveis est fora do escopo, e no ser aborda em detalhes neste
trabalho.
Finalmente, para que o cliente e as camadas se comuniquem utilizamos um barramento de
servio (Enterprise Server B us - ESB), que visa remover o acoplamento entre os servios e os
meio de transporte, tornando a aplicao mais flexvel para uma eventual troca de tecnologia de
comunicao.
Com a definio das camadas de servios, possvel estabelecer a composio das mesmas em
um nvel maior de granularidade, que so os servios em si.
4.2.2
Descrio dos servios
Anteriormente, foram apresentadas as camadas de servios que compem a arquitetura.

Agora, sero apresentados os servios que compem cada camada.
A Figura 4.2 mostra todos os servios que compem as camadas na arquitetura do sistema.
Na camada de servios bsicos podemos observar quatro servios, listados:
39
Figure 4.2: Listagem dos Servios
Armazenamento de dados: Neste servio so armazenado o contedo dos arquivos.

Os contedos nele inseridos so armazenados atravs 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 so considerados imutveis, uma vez que
ao se alterar o contedo do arquivo, seu hash ser modificado.
Armazenamento de metadados: Neste servio so armazenados metadados sobre
o arquivo e o sistema em si. Ele implementa um banco de dados chave-valor. Tipicamente ser armazenado como chave um identificador nico para aquele objeto (como
por exemplo, o login para o caso de armazenamento de um usurio), juntamente
com o objeto como valor. Cada objeto, ter suporte a versionamento, portanto ser
possvel se obter um histrico de todas as alteraes de cada objeto, e tambm
possvel evitar inconsistncias devido a escritas repetidas.
Procura de recursos: Neste servio feito o lookup de objetos ou chunks armazenados no sistema, utilizando a DHT, ou qualquer outra implementao de armazenamento de objetos que possa se utilizar posteriormente. Os servios de armazenamento
de dados e de metadados necessitam da procura de recursos para localizar objetos.
Resilincia de dados: Esse servio tem o objetivo de garantir que no haja inconsistncia ou indisponibilidade de chunks ou objetos armazenados na camada de
servios bsicos. Ela responsvel pela tolerncia a falhas de todo o sistema.
J a camada de servios importantes, composta pelos servios que juntos compem um

sistema de arquivos distribudos. So eles:
Gerenciamento de usurios: Responsvel pelo cadastro e controle de usurios.

Operaes como incluir usurios, alterar suas informaes e excluso de usurios
dependem desse mdulo.
40

Chunk: Responsvel pelo armazenamento do contedo dos arquivos quebrados em

pedaos (chunks) bem como os metadados desses chunks, tais como posio, tamanho
e hash.
Autenticao: Responsvel pela verificao de identidades dos usurios ao acessar
o sistema. Por meio dele, o usurio pode se identificar atravs, por exemplo, de um
nome de usurio e senha.
Controle de acesso: Responsvel pela autorizao e auditoria do sistema. Objetiva
impedir que no ocorra acesso no autorizado a arquivos, assim como registrar todas
as operaes de seguranas crticas no sistema.
Arquivos: Responsvel pelo cadastro de arquivos atravs de metadados tais como
nome, tamanho, data de modificao, assim como pelo compartilhamento de arquivos
entre usurios.
A representao da camada de servios desejveis no est completa, os servios representados so apenas algumas das possibilidades de novos servios que se pode implementar na
plataforma de cloud storage. Cada servio representado pode vir a ser um sistema completo que
pode ser integrado com o ecossistema da nuvem de armazenamento. Eis alguns exemplos de
servios desejveis:
Busca e indexao: Em um sistema de cloud storage, ao se enviar arquivos para

a nuvem, possvel executar a extrao de ndices sobre os arquivos e armazenlos para futuramente recuper-los pesquisando, por exemplo, por palavras chave
(Machado, 2013).
Recomendao: Baseado nos ndices de arquivos, e nas preferncias dos usurios,
este servio pode recomendar opes de arquivos para o usurio (Rodrigues, 2014).
Deduplicao: Atravs desse servio, possvel evitar o armazenamento de arquivos
ou pedaos de arquivos repetidos, economizando assim o armazenamento e trfego
de dados (Soares, 2013).
Tarifao: Esse servio utilizado pelo cloud provider ou cloud broker para tarifar
os cloud consumer em base na utilizao do servio (Silva, 2013).
Instrumentao: Esse servio pode ser utilizado juntamente com a tarifao para se
mensurar a quantidade de armazenamento, trfego e utilizao de recursos em geral
pelo cloud consumer.
Como especificado anteriormente, essa lista no exaustiva, nem tem esse objetivo. As possibilidades de se implementar novos servios so ilimitadas.
41
4.3
4.3. VISO GERAL DA ARQUITETURA
Viso Geral da arquitetura
Uma vez que foi exposto como os servios esto organizados e e relacionados entre si,
sero mostradas as vises arquiteturais do sistema, iniciando por uma viso geral da arquitetura,
para posteriormente, se apresentar cada componente da arquitetura com maior riqueza de
detalhes.
A Figura 4.3 mostra o diagrama de estrutura composta da arquitetura. Ela dividida em dois
mdulos. O primeiro o mdulo de armazenamento bsico, que foi apresentado com a primeira
camada de servios 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,
Figure 4.3: Viso da estrutura interna
encontra-se a camada de armazenamento de arquivos. Ela composta pelos cinco componentes

que formam o sistema de arquivos em nuvem: Autenticao, Chunk, Controle de Acesso,
42
4.3. VISO GERAL DA ARQUITETURA
Gerenciamento de arquivos e gerenciamento de usurios. A funo de cada componente dessa

lista anloga aos servios de mesmo nome apresentadas no item anterior. O mdulo requer
as interfaces de armazenamento de dados e armazenamento de metadados, porm, apenas o
componente do Chunk de fato utiliza a interface de armazenamento de dados.
Na Figura 4.4 apresentada a viso de implantao da arquitetura. Entre o cliente do cloud
storage e a camada de servios podem se implantar balanceadores de carga, que tm o objetivo
de controlar a quantidade de requisies que cada n recebe, diminuindo assim a sobrecarga de
servidores e melhorando o tempo de resposta. Na camada de armazenamento de arquivos, os
Figure 4.4: Viso de Implantao
servios que exigirem mais recursos podem ser replicados. Este um benefcio da utilizao
43
4.4. CAMADA DE SERVIOS BSICOS
do paradigma SOA. Sendo cada servio stateless1 , possvel replic-los para ter uma melhor
escalabilidade.
4.4
Camada de Servios Bsicos
A partir desta seo, sero detalhadas as subdivises da arquitetura, comeando pela

camada de servios bsicos. Conforme apresentado anteriormente, a camada de armazenamento
bsico tem o objetivo de armazenar tuplas compostas por uma chave associada a um valor.
Este valor composto por uma poro de dados binrias sem qualquer anlise semntica sobre
elas. Esta responsabilidade de serializao e desserializao de objetos inteiramente das
camadas de cima. Devido a esse comportamento, essa camada pode ser denominada tambm de
Armazenamento Bsico.
Os valores ainda contam com um nmero de verso. Este nmero de verso um nmero
sequencial que incrementado a cada modificao da tupla. Ele visa tanto recuperar verses
anteriores para fins de auditoria, como evitar inconsistncia em caso de acessos concorrentes
para escrita.
A Figura 4.5 mostra um exemplo de implantao do servio de armazenamento bsico. Ela
composta essencialmente por tabela de hash distribuda (DHT) composta por vrios ns de
armazenamento, sendo que cada n est dentro de um ambiente de execuo diferente, tanto em
mquinas virtuais como em hardwares distintos. Com a utilizao de hardware distinto, pode-se
manter uma segurana maior nas cpias dos dados. At mesmo, sendo um hardware modesto,
como mostrado no GFS (Ghemawat et al., 2003).
A Figura 4.6 mostra a viso de componentes do armazenamento bsico, que prov duas interfaces
para as camadas acima: ArmazenamentoMetadados e ArmazenamentoDados. Apesar de terem
operaes anlogas (armazenamento e recuperao de chave-valor) eles tm algumas diferenas.
O armazenamento de metadados conserva um histrico de reviso de cada chave, enquanto
no armazenamento de dados, pelo fato dos chunks serem imutveis, no h a necessidade de
versionamento. Alm disso, existe uma diferena nas estratgia em que os dados e os metadados
so armazenados. Essa diferena ser demonstrada mais adiante.
Os componentes de armazenamento de dados e de metadados requerem a interface da DHT,
que possuem as operaes tpicas de uma hash table, que so basicamente insero de valor e
recuperao a partir da chave.
O componente da DHT uma composio de vrios ns de armazenamento, que se organizam
numa formao 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
1 Servios
stateless so aqueles que no guardam qualquer informao sobre o cliente conectado. Geralmente
seu fluxo composto por uma requisio oriunda do cliente acompanhada de uma resposta do servidor, sem que o
servidor guarde em memria qualquer informao sobre o cliente.
44
Figure 4.5: Viso de implantao da camada de servios bsicos
Figure 4.6: Viso de componentes da camada de servios bsicos
45
mquina em que o n de armazenamento est em execuo. Porm, essa abordagem flexvel

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 memria
(Garcia-Molina and Salem, 1992) melhorando assim o tempo de resposta do n.
Os ns esto organizados em anel, de forma a balancear a carga em cada n e manter o nvel de
replicao. Como apresentado nas decises arquiteturais, esta estratgia foi baseada no algoritmo
descrito pelo DynamoDB (DeCandia et al., 2007).
O espao amostral de todos os hashes possveis para um dado qualquer dividido igualmente
por cada n de armazenamento. A informao de quais hashes pertencem a cada n distribuda
pela rede.
Ao armazenar um par chave-valor, conhecido o n a que aquele hash pertence. Ento, o
par enviado quele n. A partir da, o n responsvel por manter N rplicas daquele dado,
replicando para os N-1 ns adjacentes no anel, sendo que N um nmero arbitrrio escolhido
ao se implantar um sistema. Porm importante ressaltar que quanto maior N, maior ser a
confiabilidade e maior ser o tempo de resposta.
Periodicamente, cada n checa os ns adjacentes com o objetivo de verificar se as rplicas
existem e se h eventuais inconsistncias entre os ns. Em um desses casos, o problema deve ser
corrigido fazendo novas rplicas das tuplas ou ainda sobrescrevendo eventuais inconsistncias.
J na leitura, a requisio feita pelo n responsvel pelo hash da chave cujo dado se quer obter.
Esse n ir comparar o dado armazenado nele prprio com os N-1 adjacentes antes de retornar o
valor. Uma escrita bem sucedida, se o dado foi escrito em W ns, e uma leitura bem sucedida,
se o mesmo valor foi lido em R ns. Onde W e R tambm so nmero arbitrrios que satisfazem
a condio: R+W>N
Como foi demonstrado atravs de experimentos em (DeCandia et al., 2007), no DynamoDB,
esses valores de R, W e N so respectivamente 2, 2 e 3, o que garante bons resultados em relao
disponibilidade, performance, consistncia e durabilidade. Portanto, para o armazenamento de
metadados, esses mesmos valores sero usados.
J para o armazenamento de dados no h a necessidade de se fazer a leitura de mais de um chunk
igual, pois como declarado antes, chunks so imutveis. Nesse caso, uma leitura suficiente.
Portanto para satisfazer as condies especificadas, os valores de R,W e N seriam 1, 3 e 3
respectivamente.
Na Figura 4.7, podemos observar um diagrama de sequncia para a operao de armazenamento
de um par chave-valor na DHT. O servio de armazenamento de dados ou metadados seleciona o
n principal para aquele dado, e este armazena no prprio engenho de armazenamento, e envia o
chunk para os N-1 ns adjacentes.
O diagrama da Figura 4.8 mostra as classes mais importantes em um n de armazenamento. O
n prov uma interface que permite armazenar ou recuperar dados, e contm uma viso da DHT
como um todo, pois no momento em que um n entra ou deixa a DHT, a estrutura do anel pode
46
4.5. CAMADA DE SERVIOS IMPORTANTES
Figure 4.7: Insero de dados na DHT
ser diferente em dois ns, at que as informaes sejam sincronizadas.

Vale tambm destacar que a a nica interface provida para o engenho de armazenamento via
sistema de arquivos, porm est aberta a possibilidade de novas implementaes.
4.5
Camada de Servios Importantes
Como foi mostrado na seo anterior, no armazenamento de dados, eles so armazenados

de forma bruta, sem qualquer conhecimento da lgica do mesmo. A lgica em que se transforma
o armazenamento de metadados e dados em um sistema de arquivos virtual est na camada
dos Servios Importantes. Portanto essa camada tambm pode ser denominada de camada de
Armazenamento de Arquivos.
Essa camada utiliza o armazenamento bsico como plataforma, sendo esta a camada de acesso
a dados. Todos os mdulos dessa camada tm uma estrutura similar. No nvel mais acima, se
encontra a fachada do servio. Ela tem o objetivo de simplificar a interface do servio, reduzindo
o acoplamento com a forma de transporte das requisies. Cada servio tem sua prpria fachada
que prov as operaes daquele servio para as aplicaes clientes. A Figura 4.9 mostra a viso
geral de um servio.
47
Figure 4.8: Diagrama de classes do n de armazenamento
Figure 4.9: Estrutura de um servio
48
Na camada abaixo da fachada, est o controller. O controller responsvel por toda a lgica do
servio, incluindo as regras de negcio. Essa a parte mais complexa da implementao de um
servio.
Mais abaixo, est a camada de acesso a dados, o DAO (Data Access Object). No nosso caso, o
DAO utiliza tanto o servio de armazenamento de dados para incluir, modificar e excluir objetos,
como o servio de controle de acesso para decriptar objetos protegidos pelo sistema atravs da
chave do usurio.
A incluso de um objeto no sistema feito por meio das seguintes etapas: o objeto serializado
e transformado num stream de bytes ou caracteres, caso necessrio, o servio de controle de
acesso encripta esses dados. Finalmente esses dados so associados com um identificador nico
e inserido no armazenamento bsico.
A Figura 4.10 mostra a viso de diagrama de classes da camada de Servios Importantes,
mostrando as principais operaes de cada controller. Tambm possvel observar que todos
os controllers tm acesso ao armazenamento de metadados. Alm disso, o chunk controller o
nico controller que utiliza o servio de armazenamento de dados.
Figure 4.10: Diagrama de classes do file storage
Para exemplificar, podemos observar a operao de armazenamento de arquivos mostrada no

diagrama de sequncia da Figura 4.11. O cliente envia os chunks para o chunk controller um a
um. Para cada chunk, o controller salva os dados do chunk (parte do contedo do arquivo) e os
metadados do mesmo. Aps o envio do ltimo chunk, o cliente finaliza o backup enviando os
metadados referentes ao arquivo e aos chunks para o servio de gerenciamento de arquivos, que,
por sua vez, salvar metadados no armazenamento de metadados.
49
4.6. MODELO DE DADOS
Figure 4.11: Diagrama de sequncia de um backup de arquivo
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 tcnicas demonstradas em Katsov (2012). A
Figura 4.12 mostra a modelagem do banco. Percebe-se que h uma estrutura de rvore onde um
usurio possui um diretrio inicial, cada diretrio possui uma lista de diretrios e de arquivos.
Cada arquivo, por sua vez, composto por um conjunto de chunks. Por outro lado, cada usurio
tambm possui uma lista de compartilhamentos, que lista as referncias dos arquivos que foram
compartilhados por ele e com ele. Alm disso, no banco de dados tambm consta uma lista de
usurios autenticados com seu devido token, e uma lista de chaves de segurana, que ser melhor
explicada adiante.
Os valores das chaves esto guardados como strings no formato JSON (JSON, 2014) que um
formato extensvel, legvel por humanos e mais eficiente que o XML.
Com exceo dos valores relativos a usurios autenticados e chaves de segurana, todos os dados
so criptografados com a chave do usurio, com o objetivo de assegurar a confidencialidade de
seus dados.
4.7
Segurana
Como especificado antes, os metadados relativos ao usurio so encriptados. Nesta seo,

ser detalhado o projeto da segurana da arquitetura.
50
4.7. SEGURANA
Figure 4.12: Modelo de dados para o banco de dados
51
4.8. CONCLUSO
Quando um novo usurio se registra, a partir da senha fornecida pelo usurio, gerada uma
chave para o usurio que s pode ser recuperada a partir dessa senha do usurio.
Opcionalmente, o usurio ou administrador do sistema pode optar, que essa senha seja armazenada para o caso de posterior recuperao de senha. Nesse caso, a senha cifrada com uma
chave baseada na senha do administrador do sistema.
Ao incluir os metadados do usurio no sistema, eles so cifrados utilizando a chave do usurio,
logo, s podero ser reabertos atravs da senha do mesmo.
A partir da, para cada arquivo ou diretrio enviado para o sistema, gerada uma chave para
aquele arquivo. Os metadados desse arquivo ento so cifrados de modo que eles possam ser
abertos a partir de uma dessas trs chaves: a chave do usurio, a chave do prprio arquivo ou
pela chave do diretrio que contm aquele arquivo ou diretrio. Esse recurso ser utilizado mais
frente para o compartilhamento.
Quando o usurio troca de senha, seus arquivos devero ser encriptados novamente com a chave
gerada pela nova senha. Este processo dever ser feito em batch, podendo o usurio ter alguns
arquivos indisponveis nesse intervalo.
No compartilhamento, o usurio utiliza a chave pblica do usurio que receber o compartilhamento, e gera o compartilhamento daquele arquivo. Uma vez que um usurio que recebeu o
compartilhamento de um diretrio, possvel navegar nele, pois a partir da chave de um diretrio,
possvel acessar todos os arquivos ou diretrios nele contidos.
Quando o usurio revoga o acesso ao arquivo ou diretrio, aquele compartilhamento removido,
e o usurio no ter meios mais para desencriptar aquele arquivo.
Somado ao esquema de criptografia que foi descrito acima, tambm importante registrar
todas as aes dos usurios. Ao requisitar um arquivo ou fazer qualquer modificao nos seus
metadados, as aes do usurio so registradas pelo servio de controle de acesso.
4.8
Concluso
Neste captulo, foi mostrada toda a arquitetura para um sistema de backup e sincronizao
de arquivos em nuvem. Daqui em diante, esse trabalho ser validado a partir de uma avaliao
de arquitetura cuja metodologia e resultados sero apresentados no prximo captulo.
52
5
Avaliacao da Arquitetura
No captulo anterior, foi descrita a arquitetura desenvolvida a partir dos direcionadores
de negcios apresentado no captulo 3. Neste captulo, ser feito uma validao dessa arquitetura
utilizando uma metodologia de avaliao que foi desenvolvida para resolver o problema de
avaliao em uma equipe distribuda geograficamente e com horrios diferentes.
5.1
Processo de avaliao de arquitetura de software
O projeto da arquitetura um processo crtico no ciclo de desenvolvimento de qualquer

software. Erros de projeto em um software podem levar a custos de grandes propores se
detectados em um estgio avanado do projeto. Por isso, fundamental se encontrar esses erros
logo no incio do desenvolvimento da arquitetura.
A disciplina de Avaliao da Arquitetura de Software tem por objetivo evitar que esses erros
sejam detectados tarde demais, poupando custos e tempo da equipe desenvolvimento. Alm
disso, a constante avaliao de arquiteturas dentro de uma organizao, ajuda a identificar e
difundir as boas prticas de arquitetura na mesma (Maranzano et al., 2005).
Em Babar and Gorton (2009) so levantados as principais vantagens de se manter dentro de
uma organizao um processo de avaliao arquitetural. Entre eles, so destacadas as seguintes
vantagens:
Identificao de riscos potenciais na arquitetura proposta
Avaliao dos atributos de qualidade
Identificao de oportunidade de reuso de artefatos arquiteturais e componentes
Promover boas prticas de arquitetura e avaliao
Reduzir custos do projeto causado por problemas no detectados
Capturar a razo de decises de projetos importantes
53
5.2. EQUIPE DE AVALIAO DA ARQUITETURA

Descobrir problema e conflitos nos requisitos
Alinhar com o processo de garantia de qualidade da organizao
Ajudar os stakeholders na negociao dos requisitos conflitantes
Identificar habilidades necessrias para implementar a arquitetura proposta
Melhorar o qualidade da documentao da arquitetura
Facilitar uma articulao clara dos requisitos no funcionais
Abrir novos canais de comunicao entre stakeholders
Portanto, fica claro que o processo de avaliao da arquitetura to importante quanto

definir arquitetura, e esse processo pode ser utilizado para validar este trabalho. Neste projeto,
utilizou-se uma avaliao de arquitetura para alm de validar a arquitetura, obter as vantagens
em destaque na listagem anterior.
5.2
Equipe de Avaliao 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 Informtica da UFPE, e engenheiros de softwares ou arquitetos provenientes da Ustore, empresa que tem expertise em
desenvolvimento de sistema em Cloud Storage.
A composio do time de avaliao foi de suma importncia porque uma tecnologia que no
amplamente difundida e so raros os profissionais que tenham o conhecimento necessrio para
executar a avaliao dessa arquitetura.
5.3
Ameaas validao
Algumas caractersticas na equipe de avaliao poderiam representar uma ameaa ao

processo de validao da arquitetura. Uma adaptao foi feita metodologia para que se possa
conduzir este processo.
Havia algumas restries com a composio da equipe, entre elas destacam-se os seguintes
problemas: falta de um analista de negcio, equipe relativamente pequena (cinco membros),
equipe distribuda geograficamente e falta de uma agenda compatvel entre os diversos membros
da equipe.
O problema da falta de um analista de negcio j havia sido previsto antes do processo de
avaliao. Para conter esse problema foi feito todo o estudo apresentado no Captulo 3.
As duas ltimas restries, descartariam a maioria das metodologias tradicionais para avaliao
de software, pois a maioria delas exige reunies presenciais que podem se tornar longas. Para
54
5.4. METODOLOGIA DE AVALIAO
contornar esse problema, foi necessrio a utilizao de uma metodologia de avaliao no

convencional, que ser apresentada na prxima seo.
5.4
Metodologia de avaliao
A metodologia utilizada foi encontrada em Tomas (2014). Essa metodologia foi baseada
nas metodologias SAAM e ATAM, adaptando-se s necessidades de uma equipe remotamente
distribuda. Nessa metodologia, tambm foram combinadas algumas etapas das metodologias
SAAM e ATAM.
A primeira etapa do mtodo, contextualizar toda equipe de como ser conduzido o processo de
avaliao arquitetural. Toda a metodologia deve ser apresentada, principalmente no que se refere
aos artefatos gerados em cada etapa.
Aps isso, so apresentados os business drivers para nivelar o conhecimento da equipe no tocante
as regras de negcio e atributos de qualidades relevantes para o domnio do mesmo.
A prxima etapa a apresentao da arquitetura propriamente dita. O arquiteto deve apresentar a
arquitetura de forma que todos os participantes a entendam, principalmente as regras de negcio,
como tambm interao entre os mdulos e o ciclo de vida dos componentes.
Uma vez apresentada a arquitetura, deve-se priorizar os atributos de qualidade para o negcio
cujo problema a arquitetura se prope 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.
Em seguida, deve-se contextualizar a equipe do conceito de cenrios. Um cenrio uma situao
em que a arquitetura deve suportar. Cenrios podem ser de casos de uso, cujo cenrio baseado
em uma situao que pode ocorrer devido interao do usurio com o sistema, ou exploratrio,
quando fatores ou mudanas externas causam algum impacto sobre a arquitetura.
Aps isso, a equipe dever propor os cenrios que podero ser utilizado na arquitetura. Em
uma situao remota, como a dessa avaliao, isso pode ser feito com o compartilhamento de
documentos.
Finalmente, os cenrios mais relevantes so selecionados e analisada a interao dos cenrios
com os atributos de qualidade para que se tenha os resultados da avaliao
5.5
Execuo do processo de avaliao
Devido restrio da incompatibilidade de agendas de toda a equipe, no seria possvel

apresentar a metodologia, atributos de qualidade ou a arquitetura em reunies presenciais ou
mesmo por conferncias.
Portanto, para contornar essas dificuldades, o arquiteto gravou vdeos nos quais a metodologia,
o contexto de negcio, o conceito de cenrios e a arquitetura foram apresentados para os
participantes da avaliao.
55
5.6. CENRIOS PROPOSTOS E RESULTADOS DA AVALIAO
No primeiro vdeo foi explicada a metodologia que seria conduzida a partir dali. Tambm
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 vdeo, foi feita uma anlise dos drivers de negcio de cloud storage e backup de
arquivos, mostrando as principais vantagens e desvantagens, restries e requisitos.
Foi feita uma anlise dos atributos de qualidades que poderiam contribuir para as vantagens ou
amenizar as desvantagens. Com a ajuda da equipe de avaliao, foram definidos os principais
atributos de qualidade, que foram apresentados no Captulo 3.
Finalmente, foi feito um vdeo apresentando a arquitetura proposta no Captulo 4. Mostrando as
principais vises das duas camadas.
Aps isso, cada participante, em seu tempo disponvel, assistiu a cada um dos vdeos e numa
planilha compartilhada com o arquiteto, colocou cenrios possveis que poderiam ser utilizados
para avaliar a arquitetura proposta. Os participantes foram incentivados a escrever qualquer ideia,
mesmo que o mesmo no a entendesse como relevante.
Finalmente, foi feita uma anlise de como seria a interao entre os cenrios e as arquiteturas, e
suas consequncias com os atributos de qualidade.
5.6
Cenrios propostos e resultados da avaliao
Nesta seo, mostraremos os cenrios que foram priorizados, assim como o resultado
terico para cada interao entre cenrio e a arquitetura proposta. Dos cenrios propostos, alguns
foram removidos por se tratar de cenrios que envolvem servios que no esto no escopo deste
trabalho (por exemplo, busca e deduplicao). Segue a lista de cenrios com sua respectiva
avaliao:
1. Troca de senha
Descrio: Imaginando um usurio X trocando sua senha, todos seus arquivos sero
reencriptados em batch, o que acarretar na reencriptao de todos os chunks e na
re-replicao desses chunks, causando um overhead na rede ou de processador
Atributos de qualidade: Utilizao de recursos, comportamento temporal
Resultado: Nesta situao a arquitetura responde mal. Se o usurio tiver um nmero
muito grande de arquivos ou um nmero grande de usurios trocar de senha, o sistema
ir consumir uma grande quantidade de recursos de cpu e banda.
2. Cache de memria
Descrio: Devido a constante replicao e pedidos de restore, os peer de dados
poderiam manter um cache em memria dos chunks mais acessados, ou at mesmo
fazer um cache de escrita
Atributos de qualidade: Utilizao de recursos, comportamento temporal
Resultado: Como especificado anteriormente, cada n de armazenamento possui
56
5.6. CENRIOS PROPOSTOS E RESULTADOS DA AVALIAO

um engenho de armazenamento. Esse cenrio poderia ser facilmente implementado
utilizando um banco de dados em memria em cada n de armazenamento, que
otimizaria esse tipo de acesso.
3. Inconsistncia entre os Peers

Descrio: Usurio deleta arquivo enquanto algum dos ns de armazenamento com
rplica est offline
Atributos de qualidade: Consistncia, tolerncia a falhas
Resultado: Durante a verificao de consistncia entre os peers, eventuais diferena
entre ns por conta da indisponibilidade temporria de algum n corrigida. Portanto,
a arquitetura responderia bem a esse cenrio.
4. Duplicidade de dados
Descrio: Dois usurios fazem backup do mesmo arquivo
Atributos de qualidade: Utilizao de recursos
Resultado: Apesar, da operao ocorrer sem problemas, no acontecer de forma
otimizada. Em um ambiente ideal, os dois arquivos, que contm rigorosamente os
mesmos chunks, poderiam referenciar um ao outro. Porm, como cada arquivo
encriptado por uma chave diferente, isso no ocorrer, pois com a encriptao do
arquivo, os dois contedos sero distintos. Neste cenrio houve um tradeoff entre
segurana e utilizao de recursos, no qual a segurana foi favorecida.
5. Crescimento do negcio
Descrio: Devido mudanas no modelo de negcio a empresa que detm o sistema
de armazenamento "abre"o servio para Web. Deste modo, a quantidade de usurios
que totalizava 400 usurios, aps 1 ano, tornou-se em 4000.
Atributo de qualidade: Escalabilidade
Resultado: Pelas caractersticas da implementao dos servios (baixo acoplamento,
sesses sem estado) alm da utilizao da DHT, o sistema amplamente escalvel,
desde que exista o hardware necessrio para comportar a quantidade de servios e
ns de armazenamento.
6. Migrao
Descrio: Migrao do servio de armazenamento para um outro servio de armazenamento
Atributo de qualidade: adaptabilidade
Resultado: Como especificado nos Business Drivers, esta uma das limitaes de
cloud storage. Porm, atravs da utilizao dos servios, possvel desenvolver uma
aplicao que recupere os arquivos e envie-as para o novo servio. Portanto esse
cenrio parcialmente atendido.
57
5.7. CONSOLIDAO DOS RESULTADOS

5.7
7. Falha em discos
Descrio: Mquina que contem a base de metadados tem o contedo do disco
corrompido.
Atributo de qualidade: Tolerncia a falhas
Resultado: Na arquitetura no existe um servidor central de metadados. Todos os
dados so armazenado numa DHT. Se um n da DHT falha, existem rplicas que nos
ajudam a recuperar esses dados. Logo, esse cenrio totalmente atendido.
8. Mudanas na camada de comunicao
Descrio: Existe uma necessidade de se utilizar um novo prococolo ou framework
de comunicao
Atributos de qualidade: Adaptabilidade, modificabilidade
Resultado: O paradigma SOA independente da camada de comunicao. Ser
necessrio implementar um novo barramento de servios utilizando o novo protocolo
e esse cenrio ser atendido.
9. Mudana no servio de autenticao
Descrio: Exigncia de um novo modelo de autenticao (por exemplo: um Active
Directory)
Resultado: Ser necessrio modificar o servio de autenticao para se comunicar
com esse servio ao invs de utilizar os metadados do sistema. Uma vez que o usurio
seja autenticado pelo sistema externo, o funcionamento do sistema mantido.
10. Mudana na forma de armazenamento
Descrio: Exigncia de um SGBD especfico para se armazenar os dados e/ou
metadados.
Resultado: Uma limitao tcnica desse tipo de exigncia que ao se optar por um
banco relacional no ser possvel manter a disponibilidade e tolerncia a partio
por conta do que foi declarado no teorema de Brewer. Porm, possvel substituir
ou modificar o componente de armazenamento de dados ou metadados para que se
possa utilizar o SGBD fornecido.
Consolidao dos Resultados
Observando os resultados obtidos, os mesmos foram classificados em trs categorias:

Atende totalmente, nos casos em que a arquitetura atende ao cenrios sem a nescidade de
modificao, atende parcialmente, caso o cenrio possa ser atendido com pequenas modificaes
e no atende, se a arquitetura necessitaria de uma mudana de grande impacto, ou no atenderia
58
5.8. CONCLUSO
Table 5.1: Consolidao dos Resultados
de forma alguma.
Como pode-se observar na Tabela 5.1, que mostra os resultados consolidados, trs cenrios foram
atendidos totalmente. Enquanto seis desses foram atendidos parcialmente, ou seja, necessitam de
pequenas modificaes na arquitetura, nas quais a maioria delas, pode ser feita, aps a arquitetura
implementada. E finalmente, um cenrio no foi atendido.
Como recomendao da avaliao, necessrio se pensar um esquema criptogrfico mais
eficiente, que mantenha a segurana e no torne arquivos indisponveis.
Finalmente, podemos considerar que a arquitetura respondeu bem avaliao, com uma ressalva,
que foi em relao ao esquema de criptografia. Atributos de qualidade como escalabilidade,
adaptabilidade, utilizao de recursos e segurana responderam bem aos estmulos da avaliao.
5.8
Concluso
Como podemos observar, a avaliao antecipou um problema que poderia ocorrer em

tempo de execuo 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 usurios.
Na indstria, uma situao 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
limitao do sistema.
59
6
Concluso
Apesar de um item falho, ao longo de todo o trabalho, foi possvel projetar uma arquitetura elstica, escalvel e segura para um sistema de Cloud Storage.
Neste captulo, sero apresentadas as concluses que puderam ser tiradas ao longo de todo o
desenvolvimento desse trabalho.
6.1
Principais Concluses
Ao longo deste trabalho, foi possvel, estudar as tecnologias envolvidas com Cloud
Computing e Cloud Storage, para atravs 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 prope a resolver o problema de armazenamento de arquivos em nuvem. Esta arquitetura
foi guiada por decises arquiteturais, que foram justificadas e serviram como base para todo o
projeto arquitetural.
Finalmente, foi executada uma avaliao de arquitetura, que utilizou uma metodologia baseada
em SAAM e ATAM, adaptada para as peculiaridades da equipe de avaliao. Apesar, de ter sido
apontado um problema no projeto, podemos dizer que a arquitetura respondeu bem avaliao.
Aps o trmino deste trabalho, as principais concluses foram observados:
Ao projetar um sistema de Cloud Storage, o arquiteto deve priorizar as decises que

venham a manter um sistema com baixo custo, escalvel e seguro.
Com as interaes entre os Cenrios e a arquitetura do sistema, observou-se que de
fato SOA com REST pode ser uma prtica interessante para sistemas em nuvem.
Em um desenvolvimento de uma arquitetura de software, uma avaliao da arquitetura
to importante quanto o projeto da mesma. Uma avaliao pode salvar custos do
projeto.
60
6.2. CONTRIBUIES
6.2
A abordagem de descrever as principais decises arquiteturais no incio do projeto

contribuiu para que se houvesse um guia para o projeto da arquitetura.
Contribuies
As principais contribuies deixadas por esse trabalho foram:
6.3
Uma analise dos direcionadores do negcio 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 avaliao para ser utilizada por equipes geograficamente distribudas e com disponibilidade de tempo incompaties.
Trabalhos Futuros
Algumas possibilidades para novos trabalhos a partir deste:
Resolver o problema da indisponibilidade temporrio dos arquivos enquanto o usurio

troca a senha.
Implementar a arquitetura.
Projetar um servio de administrao que possa prover um controle da nuvem com
um mnimo de configuraes.
61
References
Aljabre, A. (2012). Cloud computing for increased business value. International Journal of
Business and Social Science.
Amazon (2014a). Amazon elastic computing cloud - hospedagem escalonvel em nuvem.
http://aws.amazon.com/pt/ec2/. Acesso em: 15 jun. 2014.
Amazon (2014b). Amazon web services (aws) - servios de computao em nuvem.
http://aws.amazon.com/pt/. Acesso em: 15 jun. 2014.
Babar, M. and Gorton, I. (2009). Software architecture review: The state of practice. Computer,
42(7), 2632.
Balakrishnan, H., Kaashoek, M. F., Karger, D., Morris, R., and Stoica, I. (2003). Looking up
data in p2p systems. Commun. ACM, 46(2), 4348.
Bohn, R. B., Messina, J., Liu, F., Tong, J., and Mao, J. (2011). Nist cloud computing reference
architecture. In Proceedings of the 2011 IEEE World Congress on Services, SERVICES 11,
pages 594596, Washington, DC, USA. IEEE Computer Society.
Brownbridge, D. R., Marshall, L. F., and Randell, B. (1982). The newcastle connection or
unixes of the world unite! Softw., Pract. Exper., 12(12), 11471162.
Boch, P. (2012). Distributed file systems: The state of the art and concept of ph.d. thesis.
Technical report, Universisy of West Bohemia.
Calder, B., Wang, J., Ogus, A., Nilakantan, N., Skjolsvold, A., McKelvie, S., Xu, Y., Srivastav,
S., Wu, J., Simitci, H., Haridas, J., Uddaraju, C., Khatri, H., Edwards, A., Bedekar, V., Mainali,
S., Abbasi, R., Agarwal, A., Haq, M. F. u., Haq, M. I. u., Bhardwaj, D., Dayanand, S.,
Adusumilli, A., McNett, M., Sankaran, S., Manivannan, K., and Rigas, L. (2011). Windows
azure storage: A highly available cloud storage service with strong consistency. In Proceedings
of the Twenty-Third ACM Symposium on Operating Systems Principles, SOSP 11, pages
143157, New York, NY, USA. ACM.
Chellappa, R. (1997). Intermediaries in Cloud-Computing: A New Computing Paradigm.
INFORMS.
Cruz, F. d. (2004). Herb grosch.
http://www.columbia.edu/cu/computinghistory/grosch.html. Acesso
em: 14 jun. 2014.
Dalakovi, G. (2014a). Joseph licklider.
http://history-computer.com/Internet/Birth/Licklider.html. Acesso
em: 15 jun. 2014.
Dalakovi, G. (2014b). Lisp of josh mccarthy.
http://history-computer.com/ModernComputer/Software/LISP.html.
Acesso em: 15 jun. 2014.
62
REFERENCES
DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A.,
Sivasubramanian, S., Vosshall, P., and Vogels, W. (2007). Dynamo: Amazons highly available
key-value store. In Proceedings of Twenty-first ACM SIGOPS Symposium on Operating Systems
Principles, SOSP 07, pages 205220, New York, NY, USA. ACM.
Dropbox (2014). Dropbox. http://www.dropbox.com. Acesso em: 15 jun. 2014.
Duro, F., Assad, R., Fonseca, A., Fernando, J., Garcia, V., and Trinta, F. (2013). Usto.re: A
private cloud storage software system. In Proceedings of the 13th International Conference on
Web Engineering, ICWE13, pages 452466, Berlin, Heidelberg. Springer-Verlag.
e HuiMin Zhang, X. Y. (2012). Cloud computing and soa convergence research. In
Computational Intelligence and Design (ISCID), 2012 Fifth International Symposium on,
volume 1, pages 330335.
ENISA (2009). Cloud computing: benefits, risks and recommendadtions for information
security. https://www.enisa.europa.eu/activities/risk-management/
files/deliverables/cloud-computing-risk-assessment/at_download/
fullReport. Acesso em: 2 jul. 2014.
Erl, T. (2009). SOA Design Patterns. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1st
edition.
Gantz, J. and Reinsel, D. (2011). Extracting value from chaos state of the universe : An
executive summary. Technical report, EMC.
Garcia-Molina, H. and Salem, K. (1992). Main memory database systems: An overview. IEEE
Trans. on Knowl. and Data Eng., 4(6), 509516.
Ghemawat, S., Gobioff, H., and Leung, S.-T. (2003). The google file system. In Proceedings of
the Nineteenth ACM Symposium on Operating Systems Principles, SOSP 03, pages 2943, New
York, NY, USA. ACM.
Gilbert, S. and Lynch, N. (2002). Brewers conjecture and the feasibility of consistent, available,
partition-tolerant web services. SIGACT News, 33(2), 5159.
Google (2014). Google drive.
http://www.google.com/intl/pt-BR/drive/index.html. Acesso em: 13 jul.
2014.
Grossman, R. (2009). The case for cloud computing. IT Professional, 11(2), 2327.
ISO/IEC (2010). ISO/IEC 25010 - Systems and software engineering - Systems and software
Quality Requirements and Evaluation (SQuaRE) - System and software quality models.
Technical report.
Jansen, A. and Bosch, J. (2005). Software architecture as a set of architectural design decisions.
In Software Architecture, 2005. WICSA 2005. 5th Working IEEE/IFIP Conference on, pages
109120.
Jiang, W., Zhang, L., Qiang, W., Jin, H., and Peng, Y. (2012). Mystore: A high available
distributed storage system for unstructured data. In High Performance Computing and
Communication 2012 IEEE 9th International Conference on Embedded Software and Systems
(HPCC-ICESS), 2012 IEEE 14th International Conference on, pages 233240.
63
REFERENCES
Josuttis, N. (2007). Soa in Practice: The Art of Distributed System Design. OReilly Media, Inc.
JSON (2014). Introducing json. http://json.org. Acesso em: 7 ago. 2014.
Katsov, I. (2012). Nosql data modeling techiniques. http://highlyscalable.
wordpress.com/2012/03/01/nosql-data-modeling-techniques/. Acesso
em: 7 ago. 2014.
Khajeh-Hosseini, A., Greenwood, D., Smith, J. W., and Sommerville, I. (2012). The cloud
adoption toolkit: Supporting cloud adoption decisions in the enterprise. Softw. Pract. Exper.,
42(4), 447465.
Kubiatowicz, J., Bindel, D., Chen, Y., Czerwinski, S., Eaton, P., Geels, D., Gummadi, R., Rhea,
S., Weatherspoon, H., Weimer, W., Wells, C., and Zhao, B. (2000). Oceanstore: An architecture
for global-scale persistent storage. SIGPLAN Not., 35(11), 190201.
Machado, M. A. S. (2013). Uma Abordagem para Indexao e Buscas Full-Text Baseadas em
Contedo em Sistemas de Armazenamento em Nuvem. Masters thesis, Universidade Federal de
Pernambuco.
Maranzano, J., Rozsypal, S., Zimmerman, G., Warnken, G., Wirth, P., and Weiss, D. M. (2005).
Architecture reviews: practice and experience. Software, IEEE, 22(2), 3443.
Marston, S., Li, Z., Bandyopadhyay, S., and Ghalsasi, A. (2011). Cloud computing - the
business perspective. In System Sciences (HICSS), 2011 44th Hawaii International Conference
on, pages 111.
Mell, P. and Grance, T. (2011). The nist definition of cloud computing. Technical Report
800-145, National Institute of Standards and Technology (NIST), Gaithersburg, MD.
Microsoft (2014). Microsoft one drive. http://onedrive.live.com. Acesso em: 13 jul.
2014.
Novell (2014). Netware core protocols.
http://www.novell.com/developer/ndk/netware_core_protocols.html.
Oliveira, E. M. (2014). Vantagens e desvantagens de soa. http:
//www.devmedia.com.br/vantagens-e-desvantagens-de-soa/27437#.
Acesso em: 27 jul. 2014.
Parkhill, D. F. (1966). The challenge of the computer utility. Addison-Wesley Professional,
USA.
Patterson, D. A., Gibson, G., and Katz, R. H. (1988). A case for redundant arrays of inexpensive
disks (raid). In Proceedings of the 1988 ACM SIGMOD International Conference on
Management of Data, SIGMOD 88, pages 109116, New York, NY, USA. ACM.
Rodrigues, R. B. (2014). RecCloud: Um Modelo de Recomendao para Sistemas de
Armazenamento em Nuvem. Masters thesis, Universidade Federal de Pernambuco.
Salesforce (2000). Crm e cloud computing para crescer seu negcio - salesforce.com brasil.
http://www.salesforce.com/br. Acesso em: 15 jun. 2014.
64
REFERENCES
Sandberg, R. (1986). The sun network file system: Design, implementation and experience.
Technical report, in Proceedings of the Summer 1986 USENIX Technical Conference and
Exhibition.
Sandhu, R. and Samarati, P. (1994). Access control: principle and practice. Communications
Magazine, IEEE, 32(9), 4048.
Security, H. N. (2013). A closer look at mega cloud storage.
http://www.net-security.org/secworld.php?id=14938. Acesso em: 5 jul.
2014.
Shivakumar, S. (2014). Thought floor: A walk in the clouds (pt 1).
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. (2013). Monext: An Accounting Framework for Federated Clouds. Masters
thesis, Universidade Federal de Pernambuco.
SNIA (2013). Implementing, serving, and using cloud storage.
http://snia.org/sites/default/files/Implementing_Serving_and_
Using_The_Cloud-Nov_2013.pdf. Acesso em: 15 jun. 2014.
SNIA (2014). What is a storage area network. http:
//www.snia.org/education/storage_networking_primer/san/what_san.
Soares, P. F. A. S. (2013). Dedupeer: Deduplicao de Arquivos Atravs de um Algoritmo de
Processamento Particionado. Masters thesis, Universidade Federal de Pernambuco.
Sommerville, I. (2007). Software Engineering. Addison Wesley, 8 edition.
Subashini, S. e Kavitha, V. (2011). A metadata based storage model for securing data in cloud
environment. In Cyber-Enabled Distributed Computing and Knowledge Discovery (CyberC),
2011 International Conference on, pages 429434.
Sugarsync (2014). File sharing, online backup and cloud storage from any device - sugar sync.
http://www.sugarsync.com. Acesso em: 13 jul. 2014.
Tomas, G. H. R. P. (2014). Uma arquitetura para Cidades Inteligentes Baseada na Internet das
Coisas. Masters thesis, Universidade Federal de Pernambuco, Recife.
65
Apndice
66
A
Matriz Vantagens e Desvantagens x QAs
67
Acesso
ubquo
Adequao
Preciso
Disponibilidade
1
Tolerncia a falhas
Recuperabilidade
Comportamento
temporal
Reconhecimento
de adequao
Apreensibilidade
Facilidade de uso
Prestatividade
Atratividade
Acessibilidade
tcnica
Confidencialidade
Integridade
No-repdio
Responsabilidade
Autenticidade
Susbtituidade
Coexistncia
Interoperabilidade 1
Modularidade
Reusabilidade
Analisabilidade
Modificabilidade
Estabilidade de
modifcao
Testabilidade
Portabilidade
Adaptabilidade
Instalabilidade
Reduo
de
custos
Habilidade Efetet.
de
comcresciputamento
cional
sob demanda
Escalab.
Conc. de
recursos
1
1
0
0
2
1
0
1
3
0
0
0
0
0
2
0
0
0
0
0
1
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Table A.1: Matriz Vantagens x QAs
1
1
1
1
1
1
1
3
3
2
68
Perda
govern.
Adequao
Preciso
Disponibilidade
Tolerncia a falhas
Recuperabilidade
Comportamento
temporal
Reconhecimento
de adequao
Apreensibilidade
Facilidade de uso
Prestatividade
Atratividade
Acessibilidade
tcnica
Confidencialidade
Integridade
No-repdio
Responsabilidade
Autenticidade
Susbtituidade
Coexistncia
Interoperabilidade
Modularidade
Reusabilidade
Analisabilidade
Modificabilidade
Estabilidade de
modifcao
Testabilidade
Portabilidade
Adaptabilidade
Instalabilidade
Vinc.
Servio
Segurana Dep.
conect.
Indis.
servios
Comp.
de
recursos
1
1
0
0
1
1
1
1
1
1
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
1
1
3
1
3
3
3
1
1
1
0
0
1
0
0
0
0
0
0
Table A.2: Matriz Desvantagens x QAs

Uma Arquitetura de Cloud Storage para Backup de Arquivos

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

Uma Arquitetura de Cloud Storage para Backup de Arquivos

Enviado por

Direitos autorais:

Formatos disponíveis

Thiago Jamir e Silva

UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE

Universidade Federal de Pernambuco

Universidade Federal de Pernambuco

Thiago Jamir e Silva

UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE

Trabalho apresentado ao Programa de Ps-graduao em

Orientador: Silvio Romero de Lemos Meira

Dedico este trabalho minha famlia e meus amigos. Pois

Arquitetura de software, Cloud computing, Cloud storage, Backup, Sin-

Contextualizao e Trabalhos Relacionados

Cloud Storage Business Drivers

A Matriz Vantagens e Desvantagens x QAs

Diviso em camadas de servio . . . . . . . . . .

Atributos de Qualidade escolhidos . . . . . . . . . . . . . . . . . . . . . . . .

Consolidao dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . .

A.1 Matriz Vantagens x QAs . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

No permitem acesso de qualquer dispositivo;

Requerem que o usurio esteja conectado a uma rede;

Tem um custo elevado de hardware para serem implantados;

No escalam para o volume crescente de dados.

A utilizao de sistemas de cloud computing e Cloud Storage(Mell and Grance, 2011)

mento, pretende-se responder duas perguntas:

Quais so os direcionadores de negcio para o uso de Cloud Storage?

Como projetar uma arquitetura que atenda esses contexto?

Foi feita uma reviso exploratria da literatura, com o objetivo de encontrar os

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

Questes de tarifao (billing).

Planos de negcio para sistema de Cloud Storage.

No Captulo 2 feita uma contextualizao sobre Cloud Storage e trabalhos relacionados.

1.4. ESTRUTURA DA DISSERTAO

No Captulo 3 so levantados os direcionadores de negcio de cloud storage.

No Captulo 4 apresentada a arquitetura projetada.

No Captulo 5, a avaliao da arquitetura executada.

No Captulo 6 so apresentadas as concluses do trabalho e so levantadas possibilidades para trabalhos futuros.

Histria de cloud computing

2.1. CLOUD COMPUTING

de 1997 quando Ramnath Chellappa publicou o trabalho chamado Intermediaries in Cloud

Definio de Cloud Computing

Auto servio sob demanda: Um cliente pode prover unilateralmente capacidade

2.1. CLOUD COMPUTING

Acesso de rede amplo: Capacidades so disponibilizadas sobre a rede e acessadas

2.1. CLOUD COMPUTING

Figure 2.1: Modelos de Servios

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

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

2.2. CLOUD STORAGE

Histria do armazenamento em rede

At o incio da dcada de 1980, os computadores armazenavam dados apenas em sistemas

2.2. CLOUD STORAGE

Definindo cloud storage

Aplicaes de cloud storage

Backup - Em qualquer organizao dados crticos tm que estar seguros, disponveis

2.3. TRABALHOS RELACIONADOS

Oceanstore (Kubiatowicz et al., 2000) um projeto concebido na Universidade de

2.3. TRABALHOS RELACIONADOS

Windows Azure Storage

Google File System

O Google File System (Ghemawat et al., 2003), ou GFS um sistema de arquivos

2.3. TRABALHOS RELACIONADOS

local dos chunk servers.

Acesso ubquo - Provedores de servios de armazenamento em nuvem podem

3.1. DEFINIO DO NEGCIO

Reduo de custos - Organizaes podem ter acesso a recursos computacionais