Uma Arquitetura de Cloud Storage para Backup de Arquivos...S586a Silva, Thiago Jamir e Uma...

THIAGO JAMIR E SILVA

UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE ARQUIVOS

Dissertação de Mestrado

Universidade Federal de [email protected]

www.cin.ufpe.br/~posgraduacao

RECIFE/2014

Thiago Jamir e Silva

UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DEARQUIVOS

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

Ciência da Computação do Centro de Informática da Univer-

sidade Federal de Pernambuco como requisito parcial para

obtenção do grau de Mestre em Ciência da Computação.

Orientador: Silvio Romero de Lemos MeiraCo-Orientador: Rodrigo Elia Assad

RECIFE2014

Catalogação na fonte

Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217

S586a Silva, Thiago Jamir e

Uma arquitetura de cloud storage para backup de arquivos / Thiago Jamir e Silva. – 2014.

72 f.: il., fig., tab. Orientador: Sílvio Romero de Lemos Meira. Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn,

Ciência da Computação, Recife, 2014. Inclui referências e apêndice.

1. Engenharia de software. 2. Computação em nuvem. 3. Arquitetura de software. 4. Sistemas distribuídos. I. Meira, Sílvio Romero de Lemos (orientador). II. Título. 005.1 CDD (23. ed.) UFPE- MEI 2016-132

Dedico este trabalho à minha família e meus amigos. Pois sem eles, este trabalho nãoseria possível.

Agradecimentos

Antes de mais nada, gostaria de agradecer à toda minha família por todo o apoio.Principalmente minha esposa, Eduarda, por ter acreditado na minha capacidade, quandoeu mesmo duvidei. Meus pais, e meu irmão pelo apoio constante, e pelos exemplos que medeixaram para seguir.Aos meus amigos cujo apoio foi fundamental para o término deste trabalho. Fica aqui omeu obrigado a todos.Aos professores Professores Silvio Meira (orientador), Rodrigo Assad (co orientador) eVinícius Garcia, pela oportunidade dada, pelas trocas de idéia, pela cobrança e peloscaminhos que foram indicados.Ao professor Cícero Garrozi, por se disponibilizar a fazer parte da banca deste trabalho.Ao Centro de Informática da UFPE e todos que o fazem, pelo ensino e suporte dado paraque este possa ter concluído.Aos colegas do ASSERT Lab por todos os feedbacks dados durante a evolução desseprojeto. Tenho certeza que essas discussões foram proveitosas para todos nós.A todos os colegas da Ustore, pela paciência e colaboração de todos , que para mim, éuma segunda casa.Finalmente, gostaria de agradecer a todos que contribuíram diretamente e indiretamenteà realização de mais etapa na minha vida.Obrigado a todos!

ResumoNos últimos anos, o volume de dados gerados por indivíduos e organizações tem crescidoexponencialmente. Estima-se que globalmente existia 2.7 zetabytes em 2012 e esse númerotem dobrado a cada dois anos. Além disso, com a popularização de dispositivos móveisconectados, cresceu-se a necessidade de que usuários tenham acesso a arquivos de formaubíqua. As soluções tradicionais de backup e armazenamento de arquivos online já nãoconseguem suprir as necessidades atuais dos usuários.A utilização de Cloud Storage para backup e sincronização de arquivos vem a ser umaferramenta de grande valia para esse tipo de problema. Porém, implementar um sistemadeste tipo vem a ser um desafio tecnológico relevante.Nesse sentido, este trabalho se propõe a resolver o problema de armazenamento de arquivos,propondo uma arquitetura de Cloud Storage para armazenamento de arquivos.Ao longo trabalho, é feita uma análise dos principais direcionadores de negócio para CloudStorage e armazenamento de arquivos, levantando insumos para se projetar uma arquitetura.Tal arquitetura é descrita em nível de detalhe para que se possa ser implementada.Finalmente, o trabalho é validado através de uma avaliação de arquitetura cuja metodologiafoi adaptada de acordo com as características da equipe de avaliação.

Palavras-chave: Arquitetura de software. Cloud computing. Cloud storage. Backup.Sincronização.

AbstractIn the last years, the amount of data generated by individuals and organizations has grownexponentially. It is estimated that there were 2.7 zettabytes of global data in 2012, andthis number has doubled each two years. In addition to this, with the popularization ofmobile connected devices, the user’s need to have ubiquous access has grown. Traditionalsolutions 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 greatvalue to this kind of problem. However, implementing such a system becomes a significanttechnological challenge.Thus, this works proposes to solve the problem of storing files, designing a Cloud Storagearchitecture for storing archives.Throughout work, an analysis of the key business drivers for Cloud Storage and File storageis done by lifting inputs for designing an architecture. This architecture is described indetail for level that can be implemented.Finally, the work is validated through an evaluation of architecture whose methodologywas adapted according to the characteristics of the evaluation team.

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

Lista de ilustrações

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

Lista de tabelas

Tabela 1 – Atributos de Qualidade escolhidos . . . . . . . . . . . . . . . . . . . . 30Tabela 2 – Consolidação dos Resultados . . . . . . . . . . . . . . . . . . . . . . . 61Tabela 3 – Matriz Vantagens x QAs . . . . . . . . . . . . . . . . . . . . . . . . . . 71Tabela 4 – Matriz Desvantagens x QAs . . . . . . . . . . . . . . . . . . . . . . . . 72

SOA Services Oriented Architecture

ESB Enterprise Service Bus

ATAM Architecture Tradeoff Analisys Method

SAAM Software Architecture Analisys Method

REST Representational state transfer

QA Quality Attribute

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1 Definição do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3 Fora do escopo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4 Estrutura da dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 CONTEXTUALIZAÇÃO E TRABALHOS RELACIONADOS . . . . 162.1 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.1 História de cloud computing . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.2 Definição de Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . 172.2 Cloud Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2.1 História do armazenamento em rede . . . . . . . . . . . . . . . . . . . . . 202.2.2 Definindo cloud storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.2.3 Aplicações de cloud storage . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.1 Oceanstore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.2 Windows Azure Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.3 Google File System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.4 Ustore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3 CLOUD STORAGE BUSINESS DRIVERS . . . . . . . . . . . . . . 253.1 Definição do Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.1 Principais Vantagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1.2 Principais Desvantagens e Ameaças . . . . . . . . . . . . . . . . . . . . . 263.1.3 Identificação dos Principais Stakeholders . . . . . . . . . . . . . . . . . . . 273.1.4 Restrições do negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.1.5 Restrições técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.2 Atributos de Qualidade . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4 DEFINIÇÃO DA ARQUITETURA . . . . . . . . . . . . . . . . . . . 34

4.1 Decisões arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.1 Orientação a Serviços através de Representational state transfer (REST) . . 344.1.2 Persistência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.3 Utilização de DHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.4 Controle de Acesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2 Orientação a Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.1 Camadas de Serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 Descrição dos serviços . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3 Visão Geral da arquitetura . . . . . . . . . . . . . . . . . . . . . . . . 434.4 Camada de Serviços Básicos . . . . . . . . . . . . . . . . . . . . . . . 444.5 Camada de Serviços Importantes . . . . . . . . . . . . . . . . . . . . 484.6 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.7 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.8 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5 AVALIACAO DA ARQUITETURA . . . . . . . . . . . . . . . . . . . 555.1 Processo de avaliação de arquitetura de software . . . . . . . . . . . 555.2 Equipe de Avaliação da arquitetura . . . . . . . . . . . . . . . . . . . 565.3 Ameaças á validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.4 Metodologia de avaliação . . . . . . . . . . . . . . . . . . . . . . . . . 575.5 Execução do processo de avaliação . . . . . . . . . . . . . . . . . . . 575.6 Cenários propostos e resultados da avaliação . . . . . . . . . . . . . . 585.7 Consolidação dos Resultados . . . . . . . . . . . . . . . . . . . . . . . 605.8 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.1 Principais Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.2 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 637.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

APÊNDICES 69

APÊNDICE A – MATRIZ VANTAGENS E DESVANTAGENS XQAS . . . . . . . . . . . . . . . . . . . . . . . . . . 70

13

1 Introdução

Atualmente, tem-se observado um crescimento alarmante no volume de dadosmundial. De acordo com Gantz J. e Reinsel (2011), esse volume global superou 1 zettabyteem 2010 e tem previsão de alcançar 8 zettabytes em 2015.Este fato tem ocorrido devido à crescente quantidade de aplicativos e dispositivos quegeram conteúdos para armazenar. Desde textos, e-mails até vídeos em alta resolução. Alémdisso, com o advento dos dispositivos portáteis e a internet móvel, surgiu a necessidadedos usuários de acessar seus conteúdos de forma ubíqua.As soluções de de backups e sincronização de arquivos tradicionais já não têm suprido ademanda crescente dos usuários. Pois, podemos encontrar alguns problemas nessas solução,tais como:

• Não permitem acesso de qualquer dispositivo;

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

• Tem um custo elevado de hardware para serem implantados;

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

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

1.1 Definição do problemaO problema que se pretende resolver neste trabalho é projetar uma arquitetura

para armazenamento de arquivos de forma elástica, escalável e segura. Para apoiar essedesenvolvimento, pretende-se responder duas perguntas:

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

• Como projetar uma arquitetura que atenda esses contexto?

Seção 1. Introdução 14

1.2 MetodologiaPara desenvolver este trabalho, a seguinte metodologia foi utilizada:

• Foi feita uma revisão exploratória da literatura, com o objetivo de encontrar osdirecionares de negócio de cloud storage, assim como técnicas que poderiam serutilizadas para projetar a arquitetura;

• Das informações obtidas sobre o contexto de negócio, foram levantados os atributosde qualidades assim como os requisitos para o sistema;

• Com as técnicas encontradas na revisão, foi projetada uma arquitetura para atenderos requisitos e atributos de qualidade.

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

1.3 Fora do escopoOs seguintes tópicos foram excluídos do escopo para esse trabalho:

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

• Serviços e features na arquitetura que não estão diretamente ligadas com o armaze-namento, tais como indexação e busca, APIs externas, entre outros.

• Implementação da arquitetura.

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

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

1.4 Estrutura da dissertaçãoO restante da dissertação estará organizada da seguinte forma:

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

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

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

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

Seção 1. Introdução 15

• Na Seção 7 são apresentadas as conclusões do trabalho e são levantadas possibilidadespara trabalhos futuros.

• Finalmente no Apêndice A é mostrada as tabelas que apoiaram as decisões dosprincipais atributos de qualidade da Seção 3.

16

2 Contextualização e Trabalhos Relaciona-dos

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

2.1 Cloud ComputingAntes de estudar cloud storage, é importante ter uma visão geral dos conceitos de

cloud computing, ou computação em nuvem. Uma breve visão histórica e contextual decloud computing será feita nesta seção.

2.1.1 História de cloud computing

Apesar de ter ganhado destaque nos últimos anos, o conceito de cloud computingnão pode ser considerado recente. Em 1950, o cientista da computação Herb Grosh (CRUZ,2004) postulou que o mundo inteiro operaria em “terminais burros” que seriam servidospor aproximadamente 15 clusters de computadores.Mais tarde, em 1961, Dalakovi (2014b) sugeriu num discurso que a tecnologia de comparti-lhamento de processamento levaria a um futuro cujo poder computacional ou até aplicaçõespoderiam ser vendidas como um serviço, tal como energia ou eletricidade. Em 1962, J.C.RLicklider (DALAKOVI, 2014a) descreveu um conceito de uma “Rede Intergaláctica deComputadores”, antes de fazer parte da Agência de Projetos de Pesquisa Avançada (Advanced Research Project Agency - ARPA), que pode ser considerada como a origem dainternet. Nesta rede, usuários poderiam rapidamente localizar e acessar dados e softwaresdentro dela e poderiam migrá-las caso necessário. Este conceito descreve não só a Internetcomo conhecemos hoje, mas também um dos princípios de cloud computing.Em 1966, Douglas Parkhill, em seu livro “The Challenge of the Computer Utility”(PARKHILL, 1966) descreveu o provisionamento de poder computacional de forma elásticae infinita. Apesar da ideia de cloud computing ter surgido há mais de 50 anos atrás, o termosó veio surgir no ano de 1997 quando Ramnath Chellappa publicou o trabalho chamado“Intermediaries in Cloud Computing: A New Computing Paradigm” (CHELLAPPA, 1997).Em 1999 surgiu o SalesForce, a primeira aplicação entregue ao usuário usando o conceito desoftware como um serviço de forma escalável e de rápido provisionamento (SALESFORCE,2000).

Seção 2. Contextualização e Trabalhos Relacionados 17

Em 2002, a Amazon lança a plataforma Amazon Web Service (AMAZON, 2014b), quedisponibiliza serviços como computação e armazenamento em larga escala como um serviço.Posteriormente, em 2006, seria lançado o Amazon Elastic Cloud Computing (AMAZON,2014a), um marco para cloud computing, sendo o primeiro serviço no modelo Infrastructureas a Service (IaaS).Outro grande aspecto relevante do cloud computing foi em 2009, quando a chamada Web2.0 apresentou uma grande evolução e a Google, assim como outras organizações, começoua oferecer aplicações baseadas em browser através de serviços como o Google Apps.Posteriormente, ainda surgiram novas ferramentas baseadas em cloud computing das quaispodemos destacar Heroku1, Azure2, Digital Ocean3, Cloud Foundry4, entre outros.

2.1.2 Definição de Cloud Computing

De acordo com o NIST citeMell2011, Cloud Computing pode ser introduzido coma seguinte definição que foi traduzida livremente:

“Computação em Nuvem é um modelo que proporciona um acesso de redeubíquo, conveniente e sob demanda, para uma reserva compartilhada derecursos computacionais (ex: rede, servidores, armazenamento, aplicaçõese serviços) que pode ser rapidamente providas e liberadas com um esforçomínimo de configuração ou mínima interação com o provedor de serviços.Este modelo é composto por cinco características essenciais, três modelos deserviços e quatro modelos de implantação.”

Dentro da definição apresentada acima, é importante destacar alguns elementos. O compar-tilhamento de recursos viabiliza que um recurso computacional ocioso para um usuário sejautilizado por outros, conforme necessidade. Também é importante frisar que a expansão ouencolhimento da nuvem, deverá ser feita conforme a necessidade e com o mínimo possívelde esforço do administrador. Isso viabiliza aplicativos e serviços que outrora dependeriamde toda uma infraestrutura para operar.Ainda de acordo com o NIST, a Cloud Computing tem cinco características essenciais. Sãoelas:

• Auto serviço sob demanda: Um cliente pode prover unilateralmente capacidadecomputacional sem necessidade de interação humana com cada serviço.

1 https://www.heroku.com/2 http://azure.microsoft.com3 https://www.digitalocean.com/4 http://cloudfoundry.org/index.html


• Acesso de rede amplo: Capacidades são disponibilizadas sobre a rede e acessadaspor mecanismos padrões que promovem o uso por uma plataforma heterogêneas declientes. Elas podem variar desde de telefones celulares a estações de trabalho.

• Reserva de recursos: Os recursos computacionais do serviço são agrupados paraservir múltiplos consumidores, sendo dinamicamente realocadas de acordo com ademanda. Geralmente o cliente não tem controle ou informações sobre a localizaçãoexata do recurso computacional em uso. Porém, pode haver a possibilidade deespecificar esse tipo de informação dentro de uma macro região.

• Elasticidade rápida: Capacidade computacional pode ser provida e liberada, emalguns casos, automaticamente, para rapidamente escalar dependendo da demanda.Para o consumidor, a capacidade disponível frequentemente parece ser ilimitada epode ser adquirida em qualquer quantidade e a qualquer hora.

• Serviço instrumentado: Sistemas em nuvem automaticamente controlam e otimi-zam o uso de recursos através de instrumentação da capacidade computacional. Ouso de recursos pode ser controlado, monitorado e reportado, provendo transparênciatanto para o usuário quanto para o provedor.

O termo computação pode ter diversos significados, desde utilização de hardware a execuçãode um aplicativo específico. Por esse motivo, foram criados os distintos modelos de serviços,que agrupam o que pode ser entregue como serviço. O modelo SPI, que significa Software,Platform, Infrastructure, é utilizado para classificar os sistemas de cloud computing deacordo com o tipo de serviço, como se segue:

• Software as a Service (SaaS): O provedor disponibiliza aplicações que sãoexecutadas em uma infraestrutura de cloud computing. Geralmente, essas aplicaçõessão utilizadas em um modelo de pagamento por uso e são acessíveis a vários clientestanto através de um “terminal burro”, como um browser ou por meio de um softwarecliente. O cliente não tem controle sobre a infraestrutura usada pela aplicação.

• Platform as a Service (PaaS): O provedor disponibiliza uma plataforma capazde executar programas desenvolvidos ou adquiridos pelo cliente, que foram criadosutilizando linguagens de programação, bibliotecas, serviços e ferramentas suportadaspelo provedor. O cliente não tem controle sobre a infra-estrutura utilzada pelaaplicação.

• Infrastructure as a Services(IaaS): O provedor disponibiliza para o clienteprocessamento, armazenamento, rede e outros recursos computacionais básicos, nosquais o cliente pode implantar e executar qualquer tipo de software, que inclui sistemasoperacionais e aplicações. O cliente não tem controle total sobre a infraestrutura


que é utilizada, mas gerencia recursos como armazenamento, sistema operacionais eaplicações em execução.

A Figura 1, extraida de Shivakumar (2014) ilustra os diferentes níveis dos modelos deserviços, com alguns exemplos de ferramentas em cada nível de serviço. Quanto maior onível de abstração, maior o julgamento de valor sobre o serviço que está sendo adquirido etambém menor o controle sobre a infraestrutura em uso.

Figura 1 – Modelos de Serviços

Fonte: Infosys Blogs

Ainda de acordo com o NIST, podemos classificar os sistemas de cloud computingde acordo com o modelo de implantação. Como se segue:

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

• Nuvem comunitária: A infraestrutura é fornecida para uso exclusivo de umacomunidade de consumidores que tem preocupações semelhantes (por exemplo,missão, restrições de seguranças, entre outros). Pode pertencer, ser gerenciada eoperada por uma ou mais das organizações que fazem parte da comunidade, umterceiro ou alguma combinação entre eles.

• Nuvem pública: A infraestrutura é fornecida para uso aberto do público em geral.Pode pertencer, ser gerenciada e operada por uma organização de negócios, acadêmicaou governamental, ou alguma combinação entre eles.


• Nuvem híbrida: A infraestrutura é composta por duas ou mais nuvens, que conti-nuam únicas mas são interligadas de forma que se permita a portabilidade de dadose aplicações.

2.2 Cloud StorageUma vez que foi entendida a idéia de cloud computing e suas principais caracte-

rísticas, vamos introduzir e analisar conceitos, requisitos e técnicas envolvidas com cloudstorage.

2.2.1 História do armazenamento em rede

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


2014). Serviço que passaria a vender backup e cloud storage como uma mercadoria, nummodelo utilizado até os dias atuais.

2.2.2 Definindo cloud storage

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

2.2.3 Aplicações de cloud storage

De acordo com SNIA (2013), os sistemas de Cloud Storage podem ter váriasaplicações dependendo dos objetivos das organizações que as utilizam. Seguem alguns dosprincipais cenários:

• Backup - Em qualquer organização dados críticos têm que estar seguros, disponíveise recuperáveis para uma versão prévia. Um sistema de cloud storage pode substituiras soluções tradicionais de backup, como por exemplo, fitas magnéticas, sendo umaforma mais segura, barata e prática de armazenamento de backups.

• Arquivamento - As organizações estão cada vez sendo mais forçadas a reter volumesmaiores de dados por longos períodos. Assim como no backup, os sistemas de CloudStorage podem substituir as formas tradicionais de arquivamento reduzindo custos eaumentando a agilidade da recuperação de informação.

• Armazenamento de dados de aplicativos - Aplicações de negócios requeremarmazenamento temporário e permanente, que geralmente é disponibilizado por discos


ou soluções de armazenamento em rede como NAS ou SAN. Dados de aplicativostêm requisitos mais críticos de acesso e latência. Uma solução de cloud storage podetrazer vantagem em relação a essas soluções tradicionais, tais como facilidade debackup de aplicativos, redução de custos, entre outros.

2.3 Trabalhos RelacionadosNesta seção, serão apresentados alguns trabalhos que se relacionam com este

trabalho, pois se tratam de sistemas de cloud storage, que foram ou estão sendo utilizadostanto na academia quanto na indústria. Os trabalhos foram apresentados por ordem depublicação.

2.3.1 Oceanstore

Oceanstore (KUBIATOWICZ, 2000) é um projeto concebido na Universidade deBerkley, que visa fornecer uma plataforma aberta e global para armazenamento de dados.Em sua concepção, foi idealizada para objetivos como servir de plataforma para aplicaçõesgroupware (e-mail, calendário, lista de contatos), repositório de dados de grande volumepara grupos científicos ou como servidor para streaming.A plataforma Oceanstore tem duas premissas: ser construída a partir de um grandegrupo de servidores não confiáveis, pois equipamentos quebram sem advertência e nãose pode confiar a durabilidade de um dado aos mesmos; a segunda premissa é que osdados são nômades, pois em um sistema de grandes proporções a localidade dos dados émuito importante. O Oceanstore faz cache dos dados em várias localidades para manter aescalabilidade do sistema, abrindo mão da consistência dos dados.Cada objeto no OceanStore é armazenado com um nome único gerado pseudo-aleatoriamente,chamado GUID (Global Unique Identifier). Alguns GUID funcionam como um diretório,contendo uma lista de GUID’s, dando a possibilidade da criação de uma estrutura seme-lhante a uma árvore.O controle de acesso é feito em basicamente duas operações: restrição de leitura e restriçãode escrita.Cada objeto que não é público, é encriptado com uma chave única. Cada usuário que tempermissão de leitura, recebe essa chave para desencriptar. Para revogar o acesso em dadoobjeto, as replicas são reencriptados com uma nova chave.Para prevenir escritas não autorizadas, cada escrita é assinada digitalmente e cada objetotem uma lista de controle de acesso indicando quem pode alterar aquele objeto. A restriçãode escrita é feita pelo server que verifica se o usuário que tenta escrever naquele objetotem acesso ao mesmo.Cada objeto armazenado no OceanStore pode ter uma réplica em qualquer servidor. Paralocalizar esses objetos, conta com dois algoritmos. O primeiro, é um algoritmo probabilístico


e rápido, que toma a premissa que existe uma grande probabilidade de um dado acessadofrequentemente residir em um servidor próximo. O segundo é um algoritmo hierárquicomais lento, porém mais confiável.

2.3.2 Windows Azure Storage

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

2.3.3 Google File System

O Google File System (GHEMAWAT; GOBIOFF; LEUNG, 2003), ou GFS éum sistema de arquivos distribuído que foi desenvolvido para satisfazer a demanda dearmazenamento e processamento de dados do Google.Assim como no OceanStore, a arquitetura do GFS assume que servidores não são confiáveis.O sistema de arquivo é formado por uma grande quantidade de hardware barato. Alémdisso, assume-se que arquivos são naturalmente grandes. Toda a otimização existente noGFS foi feita para arquivos grandes. O GFS também assume que arquivos são modificadosanexando-se dados no fim dos mesmos.O GFS suporta as operações usuais em sistemas de arquivos, tais como criação, deleção,abertura, fechamento, leitura e escrita de arquivos. Contudo, ele ainda introduz duas novasoperações: inserção, em que se escreve no fim do arquivo, e snapshot, operação que criauma cópia do arquivo com um custo muito baixo.No GFS, ao contrário do OceanStore, existe um servidor central, denominado servidormestre e vários outros servidores de chunks5. O servidor mestre sabe da existência detodos os outros servidores e é responsável pelo armazenamento de metadados, que são os5 Chunks são pequenos pedaços dos quais se compões um arquivo, registro, ou qualquer unidade de armazenamento


arquivos, os chunks que compõem cada arquivo e a localização de cada chunk. O servidormestre armazena todos os metadados em memória.Cada arquivo é composto por chunks de 64MB, e eles são armazenados no sistema dearquivo local dos chunk servers.Os chunks são replicados de acordo com a necessidade. Existe um controle para que chunksnovos não criem muitas réplicas, para evitar sobrecarga na escrita de novos arquivos. Ocontrole da replicação do GFS é feito através do mestre.

2.3.4 Ustore

Ustore (DURãO et al., 2013) é uma plataforma de Cloud Storage em nuvem privadadesenvolvido para armazenar arquivos, fazendo backup e sincronização deles.Uma diferença marcante na plataforma Ustore é que ele pode utilizar discos ociosos dasmáquinas de uma corporação, formando uma nuvem privada com as estações de trabalho.Para que as estações se comuniquem, é utilizado uma rede overlay peer to peer (P2P), queimplementa o protocolo conhecido como JXTA6.A arquitetura do Ustore leva em consideração quatro atributos de qualidade como pilaresde suas decisões arquiteturais, que são: escalabilidade, otimização das interações, disponi-bilidade e segurança.Na rede overlay existe um tipo de peer especial que tem a responsabilidade de configurara rede e manter rotas entre estações diferentes. Esse peer é chamado de Super Peer, eprecisa ser mantido em um servidor conhecido por todos os peers, como uma espécie deservidor central. Porém, sua úncia função é manter a conectividade entre os peers.Além da existência do superpeer, existem os chamados peers servidores, que implementamuma gama de serviços e são localizados pelos peers clientes, através do anúncio de seusserviços na rede JXTA.Finalmente os simple peers, ou apenas clientes, que são peers que são utilizados paraenviar ou recuperar arquivos da nuvem, assim como utilizar o espaço ocioso na máquinado usuário para salvar arquivos de outros usuários.A replicação no Ustore se dá através de um algoritmo estatístico, em que se registra ohistórico de conexão de cada cliente, traçando assim um perfil do mesmo. As replicados dosbackups são enviados a outros clientes que têm perfil semelhante ao do usuário, otimizandoassim a disponibilidade do arquivo, mantendo um número mínimo de réplicas.

6 https://jxta.kenai.com/

25

3 Cloud Storage Business Drivers

Nesta seção será feita uma análise nos direcionadores de negócio de Cloud Storage,e a partir daí serão desenvolvidos os business drivers. A partir dos business drivers, épossível obter insumos para pautar as decisões arquiteturais, tais como os Requisitos dosistema, assim como os principais atributos de qualidade.Esses insumos também serão úteis para, durante a avaliação da arquitetura, verificar aconformidade dessa com as necessidades de negócio.

3.1 Definição do NegócioEmbora cloud storage ja tenha sido definido anteriormente, é necessário ressaltar

que o conceito de armazenamento em nuvem é bastante abstrato. Neste trabalho, osesforços serão concentrados em sistemas de armazenamento de arquivos.Deseja-se utilizar a elasticidade da nuvem para armazenar arquivos, garantindo fatorescomo a disponibilidade, segurança, escalabilidade e acesso ubíquo aos dados armazenadospelos usuários, para uso de backup, sincronização de arquivos ou arquivamento.Esta solução irá representar duas das maiores tendências na Tecnologia da Informação(MARSTON et al., 2011) a eficiência tecnológica, pois o poder computacional é melhorutilizado através de recursos de hardware e software escaláveis e agilidade de negócio,que possibilita empresas pequenas ou em estágio inicial, ter acesso a um elevado podercomputacional.Em Grossman (2009), ENISA (2009) e Aljabre (2012) é possível observar algumas dasprincipais vantagens e desvantagens da adoção de Cloud Computing por empresas. A partirdelas, foi possível observar também sua aplicabilidade para Cloud Storage.

3.1.1 Principais Vantagens

• Acesso ubíquo - Provedores de serviços de armazenamento em nuvem podemdisponibilizar várias interfaces de acesso diferentes para seu serviço, possibilitando,assim, aos usuários, acesso aos dados através de formas e dispositivos distintos.

• Redução de custos - Organizações podem ter acesso a recursos computacionaiscom custo reduzido, uma vez que essas aplicações usufruem dos recursos que estána nuvem do provedor do serviço. Essa redução de custos engloba aquisição emanutenção tanto de hardware como de software.

Seção 3. Cloud Storage Business Drivers 26

• Habilidade de crescimento sob demanda - É possível para um pequeno negóciousar Cloud Computing, com um pequeno custo, e com o crescimento do negócio,aumentar a capacidade computacional sob demanda.

• Efetividade computacional - É possível prover serviços, continuidade e segurançamais efetivamente do que soluções tradicionais de TI.

• Escalabilidade - Arquiteturas em Cloud Computing mostram-se amplamente esca-láveis (GROSSMAN, 2009).

• Concentração de recursos -O compartilhamento de hardware físico proporcionauma perimetrização mais barata assim como um controle de acesso físico maiseficiente.

3.1.2 Principais Desvantagens e Ameaças

A adoção de cloud storage pode apresentar um conjunto de benefícios, conformeapresentado anteriormente. Entretanto, é relevante se considerar os pontos fracos, ameaçase preocupações relativas ao uso de cloud storage. A lista abaixo apresenta algumas dasprincipais desvantagens de utilizar um serviço de nuvem para armazenamento.

• Perda de governança das informações - Em se utilizando do serviço da nuvempara armazenamento, o cliente está cedendo ao provedor de serviço controle sobreinformações de sua empresa. Alguns sistemas de Cloud Storage, como o Mega(SECURITY, 2013), armazenam de forma que somente o proprietário do conteúdo,ou alguém com sua permissão, possa acessar aquele conteúdo.

• Vínculo com o serviço - Uma vez que um usuário adota um serviço de armazena-mento em nuvem, mudar para outro provedor de serviço, ou voltar para abordagenstradicionais de armazenamento pode tornar-se inviável devido ao grande número dedados armazenados.

• Segurança - Apesar de armazenamento em nuvem ter um nível de segurançasatisfatório, sempre existe um risco permanente da mesma ser exposta, e dados deuma organização sejam acessados por pessoas não autorizadas.

• Dependência de conectividade - Para se acessar um serviço de armazenamentoem nuvem, é necessário uma conexão de rede com o provedor do serviço. A perdadessa conexão, implicará na impossibilidade temporária de acesso a dados, quepodem ser críticos.

• Indisponibilidade dos serviços - Apesar dos sistemas de cloud storage teremum nível de disponibilidade bem alto, uma eventual disponibilidade do sistema,


pode impedir temporariamente dados cruciais. Assim como em qualquer sistema dearmazenamento de dados.

• Compartilhamento de recursos - Apesar do compartilhamento de recursos serum benefício, por trazer redução de custos, também pode ser uma preocupação emrelação a confidencialidade e segurança. Principalmente em um ambiente de nuvempública, onde várias organizações compartilham o mesmo recurso.

3.1.3 Identificação dos Principais Stakeholders

Para desenvolver uma arquitetura para um sistema precisamos identificar o prin-cipais envolvidos com o mesmo e suas devidas necessidades. De acordo com Bohn et al.(2011), podemos listar os seguintes stakeholders para qualquer sistema de Cloud Computing:

• Cloud Consumer - São pessoas ou organizações que mantêm um relacionamentoe usam os serviços de um Cloud Provider. No nosso caso, são os indivíduos oucorporações que utilizam o sistema de Cloud Storage para armazenar arquivos. Elesnecessitam de uma ferramenta para fazer backup e sincronização de arquivos online.

• Coud Provider - Uma pessoa, grupo ou entidade responsável por manter o serviçodisponível para as partes interessadas. No caso do sistema de Cloud Storage, quehospedaria e manteria o sistema de cloud storage. Além do serviço em si, tambémprecisa de um módulo em que possa administrar, mensurar e manter o serviço.

• Cloud Auditor - Uma organização que pode conduzir uma auditoria independentedos serviços de cloud, das operações, performance e segurança da implementação dacloud. Devem possuir ferramentas que se possa mensurar um grupo de métricas parase realizar essas auditorias.

• Cloud Broker - Uma entidade que gerencia o uso, performance e entrega dosserviços de cloud, e negocia a relação entre Cloud Provider e Cloud Consumer. Têma necessidade de um módulo que possa gerenciar a nuvem, mensurar o uso e taxaros usuários.

• Cloud Carrier - Uma organização intermediária que provê conectividade e trans-porte de serviço de Cloud Providers para Cloud Consumers. Tipicamente são osprovedores de internet.

Para o escopo desse trabalho, serão focadas as necessidades relacionadas aos grupos deCloud Consumers, que serão chamados de usuários finais, ou apenas usuários, e os CloudProviders, que serão denominados de provedores de serviços.


3.1.4 Restrições do negócio

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

• Custos - O custo de utilização ou implantação de um sistema de cloud storage nãopode ter um impacto financeiro considerável, seja relativo ao custo de implantaçãode uma nuvem privada interna, ou à aquisição do serviço através de um provedor.

• Mudanças organizacionais - O processo de mudança para utilização de soluçõesem nuvem ocasionará em um impacto organizacional. O tipo de mudança varia deorganização para organização. Alguns tipos de mudanças que podem ocorrer são emrelação à contabilidade, segurança, geografia, suporte e até ao trabalho dos usuáriosfinais.

3.1.5 Restrições técnicas

Assim como no caso das restrições de negócio, é relevante listar as restriçõestécnicas para evitar surpresas no desenvolvimento de uma arquitetura. Algumas delas sãoencontradas em sistemas de cloud storage:

• Teorema de Brewer - Conhecido também como teorema do CAP, foi demonstradoem Gilbert e Lynch (2002) e prova que não é possível em um sistema computacionalmanter a consistência, disponibilidade e a tolerância à partição simultaneamente.Isso é de grande relevância para sistemas de cloud storage, dado que a disponibilidadeé essencial, e geralmente se opta entre a consistência e a tolerância à partição.

• Limitação do hardware - Apesar de elástico, o volume armazenado por umsistema de cloud storage é limitado pelo armazenamento do hardware (físico ouvirtual) que o hospeda. Assim como sua largura de banda será limitada pela bandada comunicação entre o usuário e o provedor do serviço.

• Acordo de nível de serviço (Service Level Agreement - SLA) - É umaparte do contrato entre o provedor de serviço e o usuário que estabelece métricasmínimas para o funcionamento do serviço. São exemplos de métricas comuns de SLApara serviço de armazenamento em nuvem a disponibilidade, o tempo de resposta,taxa de erros, entre outras.


3.2 Atributos de QualidadeEm um sistema computacional, as funcionalidades são fundamentais. Pois a partir

das necessidades dos usuários, surge a demanda para o software. Contudo, os atributos dequalidade também são relevantes para guiar as decisões arquiteturais.A qualidade de software pode ser avaliada pelo grau em que o software possui de combinaçãodos atributos de qualidade, que são características importantes e devem ser priorizadas nodesenvolvimento do software. Existem várias formas de se expressar atributos de qualidade,tais como funcionalidade, negócio, segurança, entre outras.A norma ISO/IEC 25010.2 (ISO/IEC, 2010) define um modelo de qualidade de produtoque é composto por oito características que relatam tanto propriedades estáticas, quantodinâmicas de um sistema de computação.A Figura 2 mostra o modelo de qualidade de software apresentado na norma. Ela dividea qualidade de software em oito características que são adequação de funcionalidade,confiabilidade, eficiência de performance, operacionalidade, segurança, compatibilidade,manutenibilidade e transmissibilidade. Essas características são subdivididas em trinta eoito sub-características que auxiliam na descrição da qualidade de um software.

Figura 2 – Atributos de Qualidade

Fonte: ISO/IEC 25010.2

3.2.1 Metodologia

Para definir os atributos de qualidade, a seguinte metodologia foi utilizada: Pormeio de revisão bibliográfica foram levantadas as principais vantagens da utilização decloud storage as desvantagens, preocupações e ameaças. Além disso, também foram listadossegundo a norma ISO/IEC 25010, os principais atributos de qualidade de um produto de


software.Em seguida, foi feita uma matriz, cujas colunas representam as vantagens e desvantagens,enquanto as linhas representam os atributos de qualidade. Essa matriz foi preenchida como valor um, caso a presença do atributo de qualidade contribua para uma das vantagens ouamenize uma desvantagem, ou zero caso contrário. Dessa forma, foi possível selecionar osatributos de qualidade de forma que se possa maximizar os benefícios e atenuar as perdas,selecionando os atributos de qualidade com maior número de 1s seriam considerados osprioritários.

3.2.2 Resultados

Os atributos de qualidade foram enumerados de acordo com as Tabelas 3 e 4disponíveis no Apêndice A. Como se pode observar, os principais atributos de qualidadeeleitos estão de acordo com a Tabela 1.

Tabela 1 – Atributos de Qualidade escolhidos

ID NomeQ1 DisponibilidadeQ2 Utilização de recursosQ3 ConfidencialidadeQ4 Não-repúdioQ5 AutenticidadeQ6 PortabilidadeQ7 Adaptabilidade

A ordem dos atributos não necessariamente representa a ordem de prioridade nasdefinições arquiteturais.Se analisarmos a lista de atributos, podemos observar que precisamos de um sistema quemantenha-se o maior tempo possível online (Q1), que tenha o menor custo possível (Q2),que seja seguro (Q3, Q4 e Q5) e possa ser facilmente instalado em qualquer ambiente (Q6e Q7).

3.3 RequisitosEm um sistema de software, além dos atributos de qualidade, os requisitos também

guiam as decisões arquiteturais. De acordo com Sommerville (2007), o verdadeiro teste deuma arquitetura recai sobre quão bem ela atende os requisitos funcionais e não-funcionaisdepois de implantada.Para a definição de requisitos funcionais e não-funcionais neste trabalho, foram observadasas principais ferramentas de backup em nuvem, tais como o Dropbox (DROPBOX, 2014),SugarSync (SUGARSYNC, 2014), Google Drive (GOOGLE, 2014), Onedrive (MICRO-SOFT, 2014), entre outros. Além disso, tais requisitos foram revistos por analistas com


experiência na indústria nesse segmento. A partir daí, foi possível listar os seguintesrequisitos funcionais e não-funcionais:

• R1 - Upload (backup) de arquivosO usuário final pode enviar arquivo para seu drive virtual na nuvem. Uma vez queesse arquivo é enviado para nuvem, deverá permanecer até que o usuário decidaexcluir ou modificar aquele arquivo. O usuário poderá enviar arquivos para nuvemde múltiplos dispositivos de forma ubíqua.

• R2 - Download (restore) de arquivosUma vez que um usuário tenha enviado um arquivo para o seu drive virtual, aqualquer momento, desde que tenha conectividade com o sistema, ele pode recuperare baixar aquele arquivo, de qualquer dispositivo que ele tenha acesso ao sistema.

• R3 - Exclusão de arquivosO usuário pode excluir arquivos que tenham sido previamente salvos na nuvem. Nãose pode fazer download de arquivos excluídos. Uma vez que o arquivo tenha sidodeletado, o usuário pode recuperá-lo dentro de um período definido pelo provedordo serviço.

• R4 - Compartilhamento de arquivosO usuário pode compartilhar qualquer arquivo ou diretório dentro de seu discovirtual. Este processo em uma pasta será recursivo. Ou seja, uma vez que uma pastatenha sido compartilhada, qualquer arquivo ou subpasta também o será. A qualquermomento o proprietário do arquivo poderá revogar o acesso àquele arquivo ou pasta.

• R5 - Publicação de arquivosAssim como um usuário pode compartilhar arquivos, ele também pode publicá-los,garantindo acesso aos arquivos compartilhados para todos os usuários da nuvem.Assim como no compartilhamento, a qualquer momento o proprietário pode revogaracesso aos arquivos.

• R6 - Pesquisa de arquivosO usuário pode pesquisar arquivos dentro de seu disco, seja por nome de arquivos,seja pelo conteúdo dos arquivos.

• R7 - Cadastro de usuáriosO provedor de serviços terá acesso a um cadastro de usuários, que permitirá incluir,modificar ou remover usuários. Também será possível habilitar uma funcionalidadepara que o próprio usuário efetue seu cadastro.

• R8 - Tarifação de usuáriosO provedor de serviços terá ferramentas que possa mensurar a utilização da nuvem,


para que possa taxar o usuário de acordo com os termos de serviços estabelecidosentre as partes.

• R9 - Expansão ou encolhimento da nuvemO provedor de serviços deverá ser capaz de aumentar ou diminuir a capacidade danuvem, seja através de software, ou mesmo através da adição de mais hardware parasua nuvem.

• R10 - Tempo de respostaO sistema deve manter um tempo de resposta de acordo com o SLA firmado nocontrato com usuário. Não podemos estipular um valor exato, uma vez que, essevalor depende do valor contrato entre usuário e provedor.

• R11 - DisponibilidadeO sistema deve manter-se disponível por um período igual ou superior àquele firmadono SLA entre usuário e provedor. É importante observar que alguns contratosestipulam um downtime mínimo para que o serviço possa ser considerado indisponível.

• R12 - Resiliência dos arquivosO sistema deve se recuperar de eventuais falhas de hardware sem perder os dadosnele armazenados. Mais uma vez, o SLA pode prever exceções para este requisito,especificando uma taxa máxima de falhas irrecuperáveis que podem ocorrer.

• R13 - Integridade dos dadosOs dados armazenados no sistema não devem sofrer modificações indesejadas, quevenham a corromper os dados armazenados. O SLA poderá especificar uma taxamáxima de dados corrompidos.

• R14 - Consistência de dadosMesmo se tratando de um sistema distribuído, o sistema deve manter a consistênciadas informações nele armazenadas, havendo apenas uma única versão de um dadoqualquer. Então, se por exemplo, um cliente escreve um arquivo em um nó, ele deveacessar o mesmo conteúdo em outro nó do sistema.

• R15 - DurabilidadeUma vez armazenados, os dados contidos no sistema estarão em definitivo, não sendoexcluídos pelo próprio sistema ou fatores externos, salvo se excluído pelo proprietáriodo arquivo.

• R16 - AutenticaçãoPara garantir a segurança do sistema, para toda ação executada pelo sistema, o autordaquela ação deverá estar devidamente identificado através de credenciais seguras.


• R17 - AutorizaçãoEm adição à Autenticação, para cada ação realizada pelo usuário, deverá se verificarse ele tem a permissão para executá-la, impedindo assim, ao usuário executar açõesque o mesmo não tem direitos.

• R18 - AuditoriaCada ação de um usuário, além do mesmo estar devidamente identificado e autorizado,o sistema também manterá um registro de todas as ações críticas executadas pelomesmo. Os requisitos Autenticação, Autorização e Auditoria completam a segurançado sistema.

• R19 - Interface externaO sistema deverá prover interfaces para o desenvolvimento de aplicações de terceiros,que possam usar o armazenamento em nuvem como plataforma, respeitando todosos requisitos listados anteriormente.

3.4 ConclusãoA partir de uma análise do negócio de cloud storage e backup online, foi possível

estabelecer diretrizes para o desenvolvimento de uma arquitetura de cloud storage parabackup e armazenamento de arquivos.A partir dos requisitos e atributos de qualidade, é possível tomar decisões arquiteturais deforma que os satisfazem, priorizando os principais atributos de qualidade.Além disso, deveremos utilizar os atributos de qualidade na avaliação da arquiteturaproposta, validando assim este trabalho

34

4 Definição da Arquitetura

Nesta seção, será apresentada a arquitetura de software para resolver o problemaproposto. A partir da análise de negócios, temos os requisitos e atributes de qualidade quedeverão ser satisfeitos.Inicialmente foram documentadas todas as principais decisões arquiteturais para o sistema,e, tomando essas decisões como diretrizes, a arquitetura foi projetada.

4.1 Decisões arquiteturaisUm conhecido problema em projetos de arquitetura de software é a falta de clareza

nas justificativas sobre o seu projeto. As decisões arquiteturais estão embutidas no projetoda arquitetura. Desta forma, o conhecimento sobre as decisões arquiteturais é perdidodurante a execução do projeto. Com base nessas informações, Jansen e Bosch (2005)propõe documentar a arquitetura como um conjunto de decisões arquiteturais.Decisões arquiteturais podem ser definidas como uma descrição de um conjunto de adições,subtrações e modificações da arquitetura de software, da linha de raciocínio, das regras erestrições do projeto e requisitos adicionais que realizam completamente ou parcialmenteum ou mais requisitos do software.Desta forma, como primeiro passo para projetar a arquitetura proposta, iremos destacar ejustificar as principais decisões arquiteturais.

4.1.1 Orientação a Serviços através de REST

Arquitetura Orientada a Serviços (JOSUTTIS, 2007) ou Services Oriented Archi-tecture (SOA) (do inglês Software Oriented Architecture) é um paradigma de pensamentoque leva a uma arquitetura concreta. SOA tem como objetivo aumentar a flexibilidade donegócio.SOA possui alguns direcionadores, tais como sistemas distribuídos, diferentes provedorese heterogeneidade. Esses são conceitos que combinam com os drivers de negócio de umsistema de cloud storage. Além disso, os direcionadores do SOA estão de acordo com osatributos de qualidades indicados na Seção 3.Em uma arquitetura orientada a serviços, o software é decomposto em serviços, unidadeslógicas que representam um grupo de funcionalidade de negócios. Os serviços são projetadosde forma a abstrair todo o seu funcionamento interno, de forma que pessoas não técnicaspossam entender o papel do serviço dentro do ecossistema do negócio. Esses serviços

Seção 4. Definição da Arquitetura 35

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

• Baixo acoplamento, que possibilita o funcionamento parcial do sistema, mesmoem caso da não disponibilidade de algum serviço, além de diminuir o impacto emmodificações nos serviços;

• Reuso, serviços podem ser reutilizados para funções comuns dentro do sistema decloud storage. Além disso, serviços existentes podem ser reutilizados em desenvolvi-mento de novos sistemas de software;

• Manutenibilidade, como consequência do baixo acoplamento, a manutenção dosistema é feito apenas no serviço que está sofrendo alterações, não havendo modifica-ções de grande impacto nos demais, agilizando o processo de melhoramento contínuodo software;

• Interoperabilidade, dado que cada serviço é independente de hardware ou mesmode tecnologia de desenvolvimento, mantendo-se uma interface de comunicação bemdefinida.

Entretanto, essa opção trará pontos adversos, que deverão ser considerados no restante doprojeto do sistema de software. São elas:

• Aumento da complexidade, visto que cada serviço é executado de forma in-dependente, a interoperabilidade terá um custo: o maior número de camadas desoftware para comunicação entre os serviços; perda de performance, que também éconsequência da complexidade da abordagem SOA. Isso poderá afetar o tempo deresposta do sistema, que apesar de importante, não é um dos principais atributos dequalidade do sistema;


• Perda de robustez, pelo fato de que transações podem envolver vários serviços,nesse caso, não é possível garantir a atomicidade das mesmas. Esse ponto deverá serobservado nas demais decisões e design da solução;

• Segurança, pode ser um problema relevante, dado que como os serviços executam deforma distribuída e independente, então um agente malicioso pode se passar por umserviço e conseguir acesso a informações não autorizadas.

Outro aspecto entre o casamento entre SOA e Cloud Computing pode ser justificado deacordo com Yang e Zhang (2012) que declara as seguintes afirmações:

• SOA pode ajudar a construir o ambiente de Cloud Computing;

• SOA e Cloud Computing são complementares;

• Cloud Computing fornece uma realização de SOA;

• SOA e Cloud Computing podem se misturar.

Finalmente, na abordagem SOA para o sistema de Cloud Storage, deverá ser imple-mentado utilizando o padrão de projeto SOA chamado camada de serviços (ERL, 2009),que consiste em várias camadas de inventários de serviços, que são serviços agrupados porafinidade. Funciona como o estilo arquitetural em camadas em softwares tradicionais. Ascamadas serão apresentadas mais adiante neste mesma Seção.

4.1.2 Persistência

Assim como qualquer sistema, o Cloud Storage precisa persistir dados de formaorganizada. Em um sistema de grande porte, tipicamente se utiliza um banco de dados,relacional ou não, para armazená-los. Porém, um sistema de cloud storage, por definição,é utilizado para guardar dados de forma segura e escalável, assim como os sistemas degerenciamento de banco de dados.Logo, optou-se por não utilizar um banco de dados externo para armazenar metadados dosistema, de forma a reduzir custos e aumentar a portabilidade do sistema. Será utilizado opróprio ambiente de cloud storage para se guardar tanto os conteúdos dos arquivos, queserão denominados de dados, como as metainformações sobre o sistema de arquivo, queserão chamados de metadados.É comum em sistemas de arquivos distribuídos (DFS) (BžOCH, 2012) subdividir o arma-zenamento em duas unidades, sendo uma para conteúdo dos arquivos (dados) e outra parametadados.Em Subashini S. e Kavitha (2011>) podemos observar um exemplo de utilização de cloud


storage para armazenar metadados de forma eficiente e segura. Nesse trabalho, a segurançaé obtida através da fragmentação de dados sensíveis.Em Jiang et al. (2012) podemos observar que é possível utilizar um ambiente de cloud paraimplementar uma arquitetura de cloud flexível e escalável, abrindo mão da consistênciaimediata. Nesses trabalhos, a consistência é atingida através da chamada consistênciaeventual, em que os dados salvos no nós distribuídos em um certo intervalo de tempo apóssua inclusão.Podemos listar as vantagens dessa abordagem. Primeiramente seria a escalabilidade já queo armazenamento de metadados deverá crescer de acordo com o crescimento do sistema.Ademais, trata-se de um armazenamento distribuído, por isso elimina pontos únicos defalha. Também é importante considerar a portabilidade e adaptabilidade, visto que devidoà não necessidade de um software externo para armazenar metadados, não há dependênciade sistema operacional, ambiente ou qualquer situação que restrinja o uso de um software.Ou seja, na fase de implantação do software, ele elimina o pré-requisito de um software deum sistema de gerenciamento de banco de dados, e não requer a manutenção do mesmona fase de produção.Contudo, uma consequência dessa decisão arquitetural será o maior esforço de imple-mentação, visto que utilizar um sistema de gerenciamento de banco de dados seria maisrápido. Um aspecto importante nesse sentido, seria manter o baixo acoplamento, paraflexibilizar a utilização de diferentes formas de armazenamento de metadados no futuro. Éimportante deixar em aberto na arquitetura, interface para que se acople formas diferentede armazenamento tais como sistemas de arquivos, banco de dados em memória, bancosde dados externos entre outros. Porém, nesse trabalho, utilizaremos apenas o cloud storagecomo armazenamento de metadados. Assim como na implementação, a manutenibilidadeé outro ponto a se considerar, pois da mesma forma que a implementação, utilizar umbanco de dados externo tornaria mais fácil a manutenção do sistema. Finalmente, a faltade segurança é uma ameaça importante, pois esses metadados não poderão ser acessadospor pessoas não autorizadas.

4.1.3 Utilização de DHT

Em um sistema de cloud storage, os dados são armazenados em diversos nós. Assim,um problema que ocorre, é a localização desses dados. Deve-se haver uma estratégia parase definir tanto para em qual nó um certo dado será armazenado, assim como, de quallocal será possível recuperar esse dado rapidamente, sem tornar a busca custosa ou lenta.A solução adotada para este problema é a utilização de uma distributed hash table (DHT)(BALAKRISHNAN et al., 2003). Como o próprio nome diz, uma DHT não é nada maisque uma estrutura de tabela de hash distribuída em vários nós. Uma DHT tipicamentecontém duas operações básicas: inserção de objetos (put), no qual se associa uma chavea um dado objeto e esse objeto é armazenado na tabela; e recuperação (get) na qual, a


partir da chave de um objeto, que é conhecida, pode-se recuperar aquele objeto na DHT.Em geral, os algoritmos de DHT lidam com três problemas básicos:

• Mapear chaves com nós de forma balanceada: Cada nó deve conter aproxi-madamente a mesma quantidade de dados para evitar problemas de sobrecarga deum dado nó. Geralmente esse problema é resolvido utilizando uma função de hashtanto para a identificação do nós (ex: o endereço IP do nó) quanto para a chave emquestão, e feita uma correlação entre eles;

• Redirecionar uma requisição para o nó correto: Qualquer nó que recebe umarequisição para um dado nó, deve ter a capacidade de redirecionar a requisição parao nó correto. Esse redirecionamento pode conter vários saltos até se alcançar o nóem questão; e

• Construir tabelas de rotas: Para redirecionar as requisições, cada nó deve conhe-cer os seus nós mais próximos. Um exemplo para esse caso é a disposição de nós emanéis, onde cada nó conhece o próximo, e pode redirecionar mensagens até que amesma alcance seu destinatário.

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


4.1.4 Controle de Acesso

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

4.2 Orientação a ServiçosComo foi demonstrado na seção anterior, a arquitetura em concepção deverá utilizar

o paradigma de orientação a serviços. Portanto, deve-se listar todos os serviços que farãoparte da arquitetura e como eles irão se relacionar entre si. Também foi decidido utilizaruma abordagem com o padrão de projeto de camada de serviços para que o sistema tenhauma organização de negócio mais clara, além de ser uma forma de encapsular a lógicade toda uma camada de serviços, contribuindo ainda mais para o baixo acoplamento dosistema.


4.2.1 Camadas de Serviços

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

Figura 3 – Divisão em camada de serviços

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


para uma eventual troca de tecnologia de comunicação.Com a definição das camadas de serviços, é possível estabelecer a composição das mesmasem um nível maior de granularidade, que são os serviços em si.

4.2.2 Descrição dos serviços

Anteriormente, foram apresentadas as camadas de serviços que compõem a arqui-tetura. Agora, serão apresentados os serviços que compõem cada camada.A Figura 4 mostra todos os serviços que compõem as camadas na arquitetura do sistema.

Figura 4 – Listagem dos Serviços

Na camada de serviços básicos podemos observar quatro serviços, listados:

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

• Armazenamento de metadados: Neste serviço são armazenados metadados sobreo arquivo e o sistema em si. Ele implementa um banco de dados chave-valor. Tipica-mente será armazenado como chave um identificador único para aquele objeto (comopor exemplo, o login para o caso de armazenamento de um usuário), juntamentecom o objeto como valor. Cada objeto, terá suporte a versionamento, portanto serápossível se obter um histórico de todas as alterações de cada objeto, e também épossível evitar inconsistências devido a escritas repetidas.

• Procura de recursos: Neste serviço é feito o lookup de objetos ou chunks ar-mazenados no sistema, utilizando a DHT, ou qualquer outra implementação de


armazenamento de objetos que possa se utilizar posteriormente. Os serviços dearmazenamento de dados e de metadados necessitam da procura de recursos paralocalizar objetos.

• Resiliência de dados: Esse serviço tem o objetivo de garantir que não hajainconsistência ou indisponibilidade de chunks ou objetos armazenados na camada deserviços básicos. Ela é responsável pela tolerância a falhas de todo o sistema.

Já a camada de serviços importantes, é composta pelos serviços que juntos compõemum sistema de arquivos distribuídos. São eles:

• Gerenciamento de usuários: Responsável pelo cadastro e controle de usuários.Operações como incluir usuários, alterar suas informações e exclusão de usuáriosdependem desse módulo.

• Chunk: Responsável pelo armazenamento do conteúdo dos arquivos quebrados empedaços (chunks) bem como os metadados desses chunks, tais como posição, tamanhoe hash.

• Autenticação: Responsável pela verificação de identidades dos usuários ao acessaro sistema. Por meio dele, o usuário pode se identificar através, por exemplo, de umnome de usuário e senha.

• Controle de acesso: Responsável pela autorização e auditoria do sistema. Objetivaimpedir que não ocorra acesso não autorizado a arquivos, assim como registrar todasas operações de seguranças críticas no sistema.

• Arquivos: Responsável pelo cadastro de arquivos através de metadados tais comonome, tamanho, data de modificação, assim como pelo compartilhamento de arquivosentre usuários.

A representação da camada de serviços desejáveis não está completa, os serviçosrepresentados são apenas algumas das possibilidades de novos serviços que se podeimplementar na plataforma de cloud storage. Cada serviço representado pode vir a ser umsistema completo que pode ser integrado com o ecossistema da nuvem de armazenamento.Eis alguns exemplos de serviços desejáveis:

• Busca e indexação: Em um sistema de cloud storage, ao se enviar arquivos paraa nuvem, é possível executar a extração de índices sobre os arquivos e armazená-los para futuramente recuperá-los pesquisando, por exemplo, por palavras chave(MACHADO, 2013).


• Recomendação: Baseado nos índices de arquivos, e nas preferências dos usuários,este serviço pode recomendar opções de arquivos para o usuário (RODRIGUES,2014).

• Deduplicação: Através desse serviço, é possível evitar o armazenamento de arquivosou pedaços de arquivos repetidos, economizando assim o armazenamento e tráfegode dados (SOARES, 2013).

• Tarifação: Esse serviço é utilizado pelo cloud provider ou cloud broker para tarifaros cloud consumer em base na utilização do serviço (SILVA, 2013).

• Instrumentação: Esse serviço pode ser utilizado juntamente com a tarifação parase mensurar a quantidade de armazenamento, tráfego e utilização de recursos emgeral pelo cloud consumer.

Como especificado anteriormente, essa lista não é exaustiva, nem tem esse objetivo. Aspossibilidades de se implementar novos serviços são ilimitadas.

4.3 Visão Geral da arquiteturaUma vez que foi exposto como os serviços estão organizados e e relacionados entre

si, serão mostradas as visões arquiteturais do sistema, iniciando por uma visão geral daarquitetura, para posteriormente, se apresentar cada componente da arquitetura commaior riqueza de detalhes.A Figura 5 mostra o diagrama de estrutura composta da arquitetura. Ela é dividida emdois módulos. O primeiro é o módulo de armazenamento básico, que foi apresentado coma primeira camada de serviços do sistema. Ela é composta por uma DHT e provê umainterface para o armazenamento de dados, e outra para o armazenamento de metadados.Na segunda camada, encontra-se a camada de armazenamento de arquivos. Ela é compostapelos cinco componentes que formam o sistema de arquivos em nuvem: Autenticação, Chunk,Controle de Acesso, Gerenciamento de arquivos e gerenciamento de usuários. A função decada componente dessa lista é análoga aos serviços de mesmo nome apresentadas no itemanterior. O módulo requer as interfaces de armazenamento de dados e armazenamentode metadados, porém, apenas o componente do Chunk de fato utiliza a interface dearmazenamento de dados.Na Figura 6 é apresentada a visão de implantação da arquitetura. Entre o cliente docloud storage e a camada de serviços podem se implantar balanceadores de carga, quetêm o objetivo de controlar a quantidade de requisições que cada nó recebe, diminuindoassim a sobrecarga de servidores e melhorando o tempo de resposta. Na camada dearmazenamento de arquivos, os serviços que exigirem mais recursos podem ser replicados.


Figura 5 – Visão da estrutura interna

Este é um benefício da utilização do paradigma SOA. Sendo cada serviço stateless1, épossível replicá-los para ter uma melhor escalabilidade.

4.4 Camada de Serviços BásicosA partir desta seção, serão detalhadas as subdivisões da arquitetura, começando

pela camada de serviços básicos. Conforme apresentado anteriormente, a camada de arma-zenamento básico tem o objetivo de armazenar tuplas compostas por uma chave associadaa um valor. Este valor é composto por uma porção de dados binárias sem qualquer análisesemântica sobre elas. Esta responsabilidade de serialização e desserialização de objetos é1 Serviços stateless são aqueles que não guardam qualquer informação sobre o cliente conectado. Geralmente seu fluxo é

composto por uma requisição oriunda do cliente acompanhada de uma resposta do servidor, sem que o servidor guardeem memória qualquer informação sobre o cliente.


Figura 6 – Visão de Implantação


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

Figura 7 – Visão de implantação da camada de serviços básicos

interfaces para as camadas acima: ArmazenamentoMetadados e ArmazenamentoDados.Apesar de terem operações análogas (armazenamento e recuperação de chave-valor) elestêm algumas diferenças. O armazenamento de metadados conserva um histórico de revisãode cada chave, enquanto no armazenamento de dados, pelo fato dos chunks serem imutáveis,não há a necessidade de versionamento. Além disso, existe uma diferença nas estratégiaem que os dados e os metadados são armazenados. Essa diferença será demonstrada mais


adiante.

Figura 8 – Visão de componentes da camada de serviços básicos

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


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

O diagrama da Figura 10 mostra as classes mais importantes em um nó de armazenamento.O nó provê uma interface que permite armazenar ou recuperar dados, e contém uma visãoda DHT como um todo, pois no momento em que um nó entra ou deixa a DHT, a estruturado anel pode ser diferente em dois nós, até que as informações sejam sincronizadas.

Vale também destacar que a a única interface provida para o engenho de armazenamentoé via sistema de arquivos, porém está aberta a possibilidade de novas implementações.

4.5 Camada de Serviços ImportantesComo foi mostrado na seção anterior, no armazenamento de dados, eles são arma-

zenados de forma bruta, sem qualquer conhecimento da lógica do mesmo. A lógica emque se transforma o armazenamento de metadados e dados em um sistema de arquivosvirtual está na camada dos Serviços Importantes. Portanto essa camada também pode serdenominada de camada de Armazenamento de Arquivos.


Figura 9 – Inserção de dados na DHT

Essa camada utiliza o armazenamento básico como plataforma, sendo esta a camada deacesso a dados. Todos os módulos dessa camada têm uma estrutura similar. No nível maisacima, se encontra a fachada do serviço. Ela tem o objetivo de simplificar a interface doserviço, reduzindo o acoplamento com a forma de transporte das requisições. Cada serviçotem sua própria fachada que provê as operações daquele serviço para as aplicações clientes.A Figura 11 mostra a visão geral de um serviço.Na camada abaixo da fachada, está o controller. O controller é responsável por todaa lógica do serviço, incluindo as regras de negócio. Essa é a parte mais complexa daimplementação de um serviço.Mais abaixo, está a camada de acesso a dados, o DAO (Data Access Object). No nossocaso, o DAO utiliza tanto o serviço de armazenamento de dados para incluir, modificar eexcluir objetos, como o serviço de controle de acesso para decriptar objetos protegidospelo sistema através da chave do usuário.A inclusão de um objeto no sistema é feito por meio das seguintes etapas: o objeto éserializado e transformado num stream de bytes ou caracteres, caso necessário, o serviçode controle de acesso encripta esses dados. Finalmente esses dados são associados com umidentificador único e inserido no armazenamento básico.A Figura 12 mostra a visão de diagrama de classes da camada de Serviços Importantes,


Figura 10 – Diagrama de classes do nó de armazenamento

Figura 11 – Estrutura de um serviço


mostrando as principais operações de cada controller. Também é possível observar quetodos os controllers têm acesso ao armazenamento de metadados. Além disso, o chunkcontroller é o único controller que utiliza o serviço de armazenamento de dados.

Figura 12 – Diagrama de classes do file storage

Para exemplificar, podemos observar a operação de armazenamento de arquivos mostradano diagrama de sequência da Figura 13. O cliente envia os chunks para o chunk controllerum a um. Para cada chunk, o controller salva os dados do chunk (parte do conteúdodo arquivo) e os metadados do mesmo. Após o envio do último chunk, o cliente finalizao backup enviando os metadados referentes ao arquivo e aos chunks para o serviço degerenciamento de arquivos, que, por sua vez, salvará metadados no armazenamento demetadados.

4.6 Modelo de DadosComo visto anteriormente, a arquitetura armazena metadados em pares numa DHT,

compondo assim um sistema de gerenciamento de banco de dados do tipo chave-valor. Amodelagem desse banco, foi feita utilizando as técnicas demonstradas em Katsov (2012).A Figura 14 mostra a modelagem do banco. Percebe-se que há uma estrutura de árvoreonde um usuário possui um diretório inicial, cada diretório possui uma lista de diretórios ede arquivos. Cada arquivo, por sua vez, é composto por um conjunto de chunks. Por outrolado, cada usuário também possui uma lista de compartilhamentos, que lista as referênciasdos arquivos que foram compartilhados por ele e com ele. Além disso, no banco de dadostambém consta uma lista de usuários autenticados com seu devido token, e uma lista dechaves de segurança, que será melhor explicada adiante.


Figura 13 – Diagrama de sequência de um backup de arquivo

Os valores das chaves estão guardados como strings no formato JSON (JSON, 2014) que éum formato extensível, legível por humanos e mais eficiente que o XML.Com exceção dos valores relativos a usuários autenticados e chaves de segurança, todosos dados são criptografados com a chave do usuário, com o objetivo de assegurar aconfidencialidade de seus dados.

4.7 SegurançaComo especificado antes, os metadados relativos ao usuário são encriptados. Nesta

seção, será detalhado o projeto da segurança da arquitetura.Quando um novo usuário se registra, a partir da senha fornecida pelo usuário, é geradauma chave para o usuário que só pode ser recuperada a partir dessa senha do usuário.Opcionalmente, o usuário ou administrador do sistema pode optar, que essa senha sejaarmazenada para o caso de posterior recuperação de senha. Nesse caso, a senha é cifradacom uma chave baseada na senha do administrador do sistema.Ao incluir os metadados do usuário no sistema, eles são cifrados utilizando a chave dousuário, logo, só poderão ser reabertos através da senha do mesmo.A partir daí, para cada arquivo ou diretório enviado para o sistema, é gerada uma chavepara aquele arquivo. Os metadados desse arquivo então são cifrados de modo que elespossam ser abertos a partir de uma dessas três chaves: a chave do usuário, a chave dopróprio arquivo ou pela chave do diretório que contém aquele arquivo ou diretório. Esserecurso será utilizado mais à frente para o compartilhamento.Quando o usuário troca de senha, seus arquivos deverão ser encriptados novamente com a


Figura 14 – Modelo de dados para o banco de dados

chave gerada pela nova senha. Este processo deverá ser feito em batch, podendo o usuárioter alguns arquivos indisponíveis nesse intervalo.No compartilhamento, o usuário utiliza a chave pública do usuário que receberá o com-partilhamento, e gera o compartilhamento daquele arquivo. Uma vez que um usuário querecebeu o compartilhamento de um diretório, é possível navegar nele, pois a partir dachave de um diretório, é possível acessar todos os arquivos ou diretórios nele contidos.Quando o usuário revoga o acesso ao arquivo ou diretório, aquele compartilhamento éremovido, e o usuário não terá meios mais para desencriptar aquele arquivo.Somado ao esquema de criptografia que foi descrito acima, também é importante registrartodas as ações dos usuários. Ao requisitar um arquivo ou fazer qualquer modificação nosseus metadados, as ações do usuário são registradas pelo serviço de controle de acesso.


4.8 ConclusãoNesta seção, foi mostrada toda a arquitetura para um sistema de backup e sincroni-

zação de arquivos em nuvem. Daqui em diante, esse trabalho será validado a partir deuma avaliação de arquitetura cuja metodologia e resultados serão apresentados no próximaseção.

55

5 Avaliacao da Arquitetura

Na seção anterior, foi descrita a arquitetura desenvolvida a partir dos direciona-dores de negócios apresentado na Seção 3. Nesta seção, será feito uma validação dessaarquitetura utilizando uma metodologia de avaliação que foi desenvolvida para resolver oproblema de avaliação em uma equipe distribuída geograficamente e com horários diferentes.

5.1 Processo de avaliação de arquitetura de softwareO projeto da arquitetura é um processo crítico no ciclo de desenvolvimento de

qualquer software. Erros de projeto em um software podem levar a custos de grandesproporções se detectados em um estágio avançado do projeto. Por isso, é fundamental seencontrar esses erros logo no início do desenvolvimento da arquitetura.A disciplina de Avaliação da Arquitetura de Software tem por objetivo evitar que esseserros sejam detectados tarde demais, poupando custos e tempo da equipe desenvolvimento.Além disso, a constante avaliação de arquiteturas dentro de uma organização, ajuda aidentificar e difundir as boas práticas de arquitetura na mesma (MARANZANO et al.,2005).Em Babar e Gorton (2009) são levantados as principais vantagens de se manter dentrode uma organização um processo de avaliação arquitetural. Entre eles, são destacadas asseguintes vantagens:

• Identificação de riscos potenciais na arquitetura proposta

• Avaliação dos atributos de qualidade

• Identificação de oportunidade de reuso de artefatos arquiteturais e componentes

• Promover boas práticas de arquitetura e avaliação

• Reduzir custos do projeto causado por problemas não detectados

• Capturar a razão de decisões de projetos importantes

• Descobrir problema e conflitos nos requisitos

• Alinhar com o processo de garantia de qualidade da organização

• Ajudar os stakeholders na negociação dos requisitos conflitantes

• Identificar habilidades necessárias para implementar a arquitetura proposta

Seção 5. Avaliacao da Arquitetura 56

• Melhorar o qualidade da documentação da arquitetura

• Facilitar uma articulação clara dos requisitos não funcionais

• Abrir novos canais de comunicação entre stakeholders

Portanto, fica claro que o processo de avaliação da arquitetura é tão importantequanto definir arquitetura, e esse processo pode ser utilizado para validar este trabalho.Neste projeto, utilizou-se uma avaliação de arquitetura para além de validar a arquitetura,obter as vantagens em destaque na listagem anterior.

5.2 Equipe de Avaliação da arquiteturaPara avaliar a arquitetura de software, contou-se com a ajuda de consultores

externos. Sendo esses mestres, doutorandos ou doutores pelo Centro de Informática daUFPE, e engenheiros de softwares ou arquitetos provenientes da Ustore, empresa que temexpertise em desenvolvimento de sistema em Cloud Storage.A composição do time de avaliação foi de suma importância porque é uma tecnologiaque não é amplamente difundida e são raros os profissionais que tenham o conhecimentonecessário para executar a avaliação dessa arquitetura.

5.3 Ameaças á validaçãoAlgumas características na equipe de avaliação poderiam representar uma ameaça

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


5.4 Metodologia de avaliaçãoA metodologia utilizada foi encontrada em Tomas (2014). Essa metodologia foi

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

5.5 Execução do processo de avaliaçãoDevido à restrição da incompatibilidade de agendas de toda a equipe, não seria

possível apresentar a metodologia, atributos de qualidade ou a arquitetura em reuniõespresenciais ou mesmo por conferências.Portanto, para contornar essas dificuldades, o arquiteto gravou vídeos nos quais a metodo-logia, o contexto de negócio, o conceito de cenários e a arquitetura foram apresentados


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

5.6 Cenários propostos e resultados da avaliaçãoNesta seção, mostraremos os cenários que foram priorizados, assim como o resultado

teórico para cada interação entre cenário e a arquitetura proposta. Dos cenários propostos,alguns foram removidos por se tratar de cenários que envolvem serviços que não estão noescopo deste trabalho (por exemplo, busca e deduplicação). Segue a lista de cenários comsua respectiva avaliação:

• 1. Troca de senhaDescrição: Imaginando um usuário X trocando sua senha, todos seus arquivos serãoreencriptados em batch, o que acarretará na reencriptação de todos os chunks e nare-replicação desses chunks, causando um overhead na rede ou de processadorAtributos de qualidade: Utilização de recursos, comportamento temporalResultado: Nesta situação a arquitetura responde mal. Se o usuário tiver umnúmero muito grande de arquivos ou um número grande de usuários trocar de senha,o sistema irá consumir uma grande quantidade de recursos de cpu e banda.

• 2. Cache de memóriaDescrição: Devido a constante replicação e pedidos de restore, os peer de dadospoderiam manter um cache em memória dos chunks mais acessados, ou até mesmofazer um cache de escritaAtributos de qualidade: Utilização de recursos, comportamento temporal


Resultado: Como especificado anteriormente, cada nó de armazenamento possuium engenho de armazenamento. Esse cenário poderia ser facilmente implementadoutilizando um banco de dados em memória em cada nó de armazenamento, queotimizaria esse tipo de acesso.

• 3. Inconsistência entre os PeersDescrição: Usuário deleta arquivo enquanto algum dos nós de armazenamento comréplica está offlineAtributos de qualidade: Consistência, tolerância a falhasResultado: Durante a verificação de consistência entre os peers, eventuais diferençaentre nós por conta da indisponibilidade temporária de algum nó é corrigida. Portanto,a arquitetura responderia bem a esse cenário.

• 4. Duplicidade de dadosDescrição: Dois usuários fazem backup do mesmo arquivoAtributos de qualidade: Utilização de recursosResultado: Apesar, da operação ocorrer sem problemas, não acontecerá de formaotimizada. Em um ambiente ideal, os dois arquivos, que contém rigorosamente osmesmos chunks, poderiam referenciar um ao outro. Porém, como cada arquivo éencriptado por uma chave diferente, isso não ocorrerá, pois com a encriptação doarquivo, os dois conteúdos serão distintos. Neste cenário houve um tradeoff entresegurança e utilização de recursos, no qual a segurança foi favorecida.

• 5. Crescimento do negócioDescrição: Devido à mudanças no modelo de negócio a empresa que detém o sistemade armazenamento "abre"o serviço para Web. Deste modo, a quantidade de usuáriosque totalizava 400 usuários, após 1 ano, tornou-se em 4000.Atributo de qualidade: EscalabilidadeResultado: Pelas características da implementação dos serviços (baixo acoplamento,sessões sem estado) além da utilização da DHT, o sistema é amplamente escalável,desde que exista o hardware necessário para comportar a quantidade de serviços enós de armazenamento.

• 6. MigraçãoDescrição: Migração do serviço de armazenamento para um outro serviço de arma-zenamentoAtributo de qualidade: adaptabilidadeResultado: Como especificado nos Business Drivers, esta é uma das limitações decloud storage. Porém, através da utilização dos serviços, é possível desenvolver umaaplicação que recupere os arquivos e envie-as para o novo serviço. Portanto essecenário é parcialmente atendido.


• 7. Falha em discosDescrição: Máquina que contem a base de metadados tem o conteúdo do discocorrompido.Atributo de qualidade: Tolerância a falhasResultado: Na arquitetura não existe um servidor central de metadados. Todos osdados são armazenado numa DHT. Se um nó da DHT falha, existem réplicas quenos ajudam a recuperar esses dados. Logo, esse cenário é totalmente atendido.

• 8. Mudanças na camada de comunicaçãoDescrição: Existe uma necessidade de se utilizar um novo prococolo ou frameworkde comunicaçãoAtributos de qualidade: Adaptabilidade, modificabilidadeResultado: O paradigma SOA é independente da camada de comunicação. Seránecessário implementar um novo barramento de serviços utilizando o novo protocoloe esse cenário será atendido.

• 9. Mudança no serviço de autenticaçãoDescrição: Exigência de um novo modelo de autenticação (por exemplo: um ActiveDirectory)Atributos de qualidade: Adaptabilidade, modificabilidadeResultado: Será necessário modificar o serviço de autenticação para se comunicarcom esse serviço ao invés de utilizar os metadados do sistema. Uma vez que o usuárioseja autenticado pelo sistema externo, o funcionamento do sistema é mantido.

• 10. Mudança na forma de armazenamentoDescrição: Exigência de um SGBD específico para se armazenar os dados e/oumetadados.Atributos de qualidade: Adaptabilidade, modificabilidadeResultado: Uma limitação técnica desse tipo de exigência é que ao se optar por umbanco relacional não será possível manter a disponibilidade e tolerância a partiçãopor conta do que foi declarado no teorema de Brewer. Porém, é possível substituirou modificar o componente de armazenamento de dados ou metadados para que sepossa utilizar o SGBD fornecido.

5.7 Consolidação dos ResultadosObservando os resultados obtidos, os mesmos foram classificados em três categorias:

Atende totalmente, nos casos em que a arquitetura atende ao cenários sem a nescidadede modificação, atende parcialmente, caso o cenário possa ser atendido com pequenasmodificações e não atende, se a arquitetura necessitaria de uma mudança de grandeimpacto, ou não atenderia de forma alguma.


Tabela 2 – Consolidação dos Resultados

Fonte: equipe de avaliação

Como pode-se observar na Tabela 2, que mostra os resultados consolidados, três cenáriosforam atendidos totalmente. Enquanto seis desses foram atendidos parcialmente, ou seja,necessitam de pequenas modificações na arquitetura, nas quais a maioria delas, pode serfeita, após a arquitetura implementada. E finalmente, um cenário não foi atendido.

Como recomendação da avaliação, é necessário se pensar um esquema criptográficomais eficiente, que mantenha a segurança e não torne arquivos indisponíveis.Finalmente, podemos considerar que a arquitetura respondeu bem à avaliação, com umaressalva, que foi em relação ao esquema de criptografia. Atributos de qualidade comoescalabilidade, adaptabilidade, utilização de recursos e segurança responderam bem aosestímulos da avaliação.

5.8 ConclusãoComo podemos observar, a avaliação antecipou um problema que poderia ocorrer

em tempo de execução da arquitetura, que seria o uso excessivo de recursos, aliado com aperda de performance do sistema durante o processo de troca de senha para o usuários.Na indústria, uma situação como essa salvaria um valor significativo de tempo em dinheiro.Pois os arquitetos poderiam modificar e reavaliar a arquitetura, ou ainda, colocar essafalha como uma limitação do sistema.

62

6 Conclusão

63

7 Conclusão

Apesar de um item falho, ao longo de todo o trabalho, foi possível projetar umaarquitetura elástica, escalável e segura para um sistema de Cloud Storage.Nesta seção, serão apresentadas as conclusões que puderam ser tiradas ao longo de todo odesenvolvimento desse trabalho.

7.1 Principais ConclusõesAo longo deste trabalho, foi possível, estudar as tecnologias envolvidas com Cloud

Computing e Cloud Storage, para através desse estudo, conseguirmos fazer um levantamentodos principais direcionadores de requisitos, incluindo vantagens, desvantagens, atributosde qualidades e requisitos.A partir dos requisitos e atributos de qualidade, foi projetada uma arquitetura, rica emdetalhes, que se propõe a resolver o problema de armazenamento de arquivos em nuvem.Esta arquitetura foi guiada por decisões arquiteturais, que foram justificadas e serviramcomo base para todo o projeto arquitetural.Finalmente, foi executada uma avaliação de arquitetura, que utilizou uma metodologiabaseada em SAAM e ATAM, adaptada para as peculiaridades da equipe de avaliação.Apesar, de ter sido apontado um problema no projeto, podemos dizer que a arquiteturarespondeu bem à avaliação.

Após o término deste trabalho, as principais conclusões foram observados:

• Ao projetar um sistema de Cloud Storage, o arquiteto deve priorizar as decisões quevenham a manter um sistema com baixo custo, escalável e seguro.

• Com as interações entre os Cenários e a arquitetura do sistema, observou-se que defato SOA com REST pode ser uma prática interessante para sistemas em nuvem.

• Em um desenvolvimento de uma arquitetura de software, uma avaliação da arquite-tura é tão importante quanto o projeto da mesma. Uma avaliação pode salvar custosdo projeto.

• A abordagem de descrever as principais decisões arquiteturais no início do projetocontribuiu para que se houvesse um guia para o projeto da arquitetura.

7.2 ContribuiçõesAs principais contribuições deixadas por esse trabalho foram:

Seção 7. Conclusão 64

• Uma analise dos direcionadores do negócio de Cloud Storage, que serviu de insumopara o desenvolvimento da arquitetura proposta.

• Uma arquitetura, que pode ser útil para implementar um sistema de armazenamentode arquivos, ou mesmo, como fonte para que novas arquiteturas sejam elaboradas.

• Uma metodologia de avaliação para ser utilizada por equipes geograficamente distri-buídas e com disponibilidade de tempo incompaties.

7.3 Trabalhos FuturosAlgumas possibilidades para novos trabalhos a partir deste:

• Resolver o problema da indisponibilidade temporário dos arquivos enquanto o usuáriotroca a senha.

• Implementar a arquitetura.

• Projetar um serviço de administração que possa prover um controle da nuvem comum mínimo de configurações.

65

Referências

ALJABRE, A. Cloud computing for increased business value. International Journal ofBusiness and Social Science, 2012.

AMAZON. Amazon Elastic Computing Cloud: hospedagem escalonável em nuvem. 2014.Disponível em: <http://aws.amazon.com/pt/ec2/>. Acesso em: 15 jun. 2014.

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

BABAR, M.; GORTON, I. Software architecture review: The state of practice. Computer,v. 42, n. 7, p. 26–32, July 2009. ISSN 0018-9162.

BALAKRISHNAN, H. et al. Looking up data in p2p systems. Commun. ACM, ACM,New York, NY, USA, v. 46, n. 2, p. 43–48, fev. 2003. ISSN 0001-0782. Disponível em:<http://doi.acm.org/10.1145/606272.606299>.

BOHN, R. B. et al. Nist cloud computing reference architecture. In: IEEE WORLDCONGRESS ON SERVICES, 2011, Washington. Proceedings... Washington, DC, USA:IEEE Computer Society, 2011. p. 594–596.

BROWNBRIDGE, D. R.; MARSHALL, L. F.; RANDELL, B. The newcastle connectionor unixes of the world unite! Softw., Pract. Exper., v. 12, n. 12, p. 1147–1162, 1982.

BžOCH, P. Distributed file systems: the state of the art and concept of ph.d. thesis. [S.l.],2012.

CALDER, B. et al. Windows azure storage: a highly available cloud storage service withstrong consistency. In: ACM SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES,23., 2011, Cascais. Proceedings... New York: ACM, 2011. p. 143–157.

CHELLAPPA, R. Intermediaries in cloud-computing: a new computing paradigm.INFORMS, 1997.

CRUZ, F. d. Herb Grosch. 2004. Disponível em: <http://www.columbia.edu/cu/computinghistory/grosch.html>. Acesso em: 14 jun. 2014.

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

DALAKOVI, G. Lisp of Josh McCarthy. 2014. Disponível em: <http://history-computer.com/ModernComputer/Software/LISP.html>. Acesso em: 15 jun. 2014.

DECANDIA, G. et al. Dynamo: Amazon’s highly available key-value store. In:SYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES (SIGOPS), 21., 2007,Washington. Proceedings... New York: ACM, 2007. p. 205–220.

DROPBOX. Dropbox. 2014. Disponível em: <http://www.dropbox.com>. Acesso em: 15jun. 2014.

http://aws.amazon.com/pt/ec2/

http://aws.amazon.com/pt/

http://doi.acm.org/10.1145/606272.606299

http://www.columbia.edu/cu/computinghistory/grosch.html

http://www.columbia.edu/cu/computinghistory/grosch.html

http://history-computer.com/Internet/Birth/Licklider.html

http://history-computer.com/Internet/Birth/Licklider.html

http://history-computer.com/ModernComputer/Software/LISP.html

http://history-computer.com/ModernComputer/Software/LISP.html

http://www.dropbox.com

Referências 66

DURãO, F. et al. Usto.re: a private cloud storage software system. In: INTERNATIONALCONFERENCE ON WEB ENGINEERING, 13., 2013, Aalborg. Proceedings... Berlin:Springer-Verlag, 2013. p. 452–466.

ENISA. Cloud computing: benefits, risks and recommendadtions for information security.2009. Disponível em: <https://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-risk-assessment/at_download/fullReport>. Acesso em: 2jul. 2014.

ERL, T. SOA design patterns. 1st. ed. Upper Saddle River, NJ, USA: Prentice Hall PTR,2009. ISBN 0136135161, 9780136135166.

GANTZ J. E REINSEL, D. Extracting value from chaos state of the universe: an executivesummary. Framingham, MA, USA, 2011.

GARCIA-MOLINA, H.; SALEM, K. Main memory database systems: An overview. IEEETrans. on Knowl. and Data Eng., IEEE Educational Activities Department, Piscataway,NJ, USA, v. 4, n. 6, p. 509–516, dez. 1992. ISSN 1041-4347.

GHEMAWAT, S.; GOBIOFF, H.; LEUNG, S.-T. The google file system. In: ACMSYMPOSIUM ON OPERATING SYSTEMS PRINCIPLES, 19., 2003, Bolton Landing.Proceedings... New York: ACM, 2003. p. 29–43.

GILBERT, S.; LYNCH, N. Brewer’s conjecture and the feasibility of consistent, available,partition-tolerant web services. SIGACT News, ACM, New York, NY, USA, v. 33, n. 2, p.51–59, jun. 2002. ISSN 0163-5700.

GOOGLE. Google Drive. 2014. Disponível em: <http://www.google.com/intl/pt-BR/drive/index.html>. Acesso em: 13 jul. 2014.

GROSSMAN, R. The case for cloud computing. IT Professional, v. 11, n. 2, p. 23–27,March 2009. ISSN 1520-9202.

ISO/IEC. ISO/IEC 25010 - systems and software engineering : systems and softwarequality requirements and evaluation (square) - system and software quality models. [S.l.],2010.

JANSEN, A.; BOSCH, J. Software architecture as a set of architectural design decisions.In: WORKING CONFERENCE ON SOFTWARE ARCHITECTURE (WICSA), 5., 2005,Pittsburgh. Proceedings... Pittsburgh: IEEE Computer Society, 2005. p. 109–220.

JIANG, W. et al. Mystore: a high vailable distributed storage system for unstructured data.In: INTERNATIONAL CONFERENCE ON HIGH PERFORMANCE COMPUTINGAND COMMUNICATION, 14, INTERNATIONAL CONFERENCE ON EMBEDDEDSOFTWARE AND SYSTEMS, 9, 2012, Paris. Proceedings... Paris: IEEE ComputerSociety, 2012. p. 233–240.

JOSUTTIS, N. Soa in practice: the art of distributed system design. [S.l.]: O’Reilly Media,Inc., 2007. ISBN 0596529554.

JSON. Introducing JSON. 2014. Disponível em: <http://json.org>. Acesso em: 7 ago.2014.

https://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-risk-assessment/at_download/fullReport

https://www.enisa.europa.eu/activities/risk-management/files/deliverables/cloud-computing-risk-assessment/at_download/fullReport

http://www.google.com/intl/pt-BR/drive/index.html

http://www.google.com/intl/pt-BR/drive/index.html

http://json.org

Referências 67

KATSOV, I. NoSQL data modeling techiniques. 2012. Disponível em: <http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/>. Acessoem: 7 ago. 2014.

KHAJEH-HOSSEINI, A. et al. The cloud adoption toolkit: Supporting cloud adoptiondecisions in the enterprise. Softw. Pract. Exper., John Wiley & Sons, Inc., New York, NY,USA, v. 42, n. 4, p. 447–465, abr. 2012. ISSN 0038-0644.

KUBIATOWICZ, J. e. a. Oceanstore: An architecture for global-scale persistent storage.SIGPLAN Not., ACM, New York, NY, USA, v. 35, n. 11, p. 190–201, nov. 2000. ISSN0362-1340.

MACHADO, M. A. S. Uma abordagem para indexação e buscas full-text baseadasem conteúdo em sistemas de armazenamento em nuvem. Dissertação (Mestrado) —Universidade Federal de Pernambuco, 2013.

MARANZANO, J. et al. Architecture reviews: practice and experience. Software, IEEE,v. 22, n. 2, p. 34–43, March 2005. ISSN 0740-7459.

MARSTON, S. et al. Cloud computing: the business perspective. In: INTERNATIONALCONFERENCE ON SYSTEM SCIENCES (HICSS), 44., 2011, Hawaii. Proceedings...Hawaii: IEEE Computer Society, 2011. p. 1–11.

MELL, P.; GRANCE, T. The NIST definition of cloud computing. Gaithersburg, MD,2011.

MICROSOFT. Microsoft One Drive. 2014. Disponível em: <http://onedrive.live.com>.Acesso em: 13 jul. 2014.

NOVELL. NetWare core protocols. 2014. Disponível em: <http://www.novell.com/developer/ndk/netware_core_protocols.html>. Acesso em: 15 jun. 2014.

OLIVEIRA, E. M. Vantagens e desvantagens de SOA. 2014. Disponível em:<http://www.devmedia.com.br/vantagens-e-desvantagens-de-soa/27437#>. Acesso em:27 jul. 2014.

PARKHILL, D. F. The challenge of the computer utility. USA: Addison-WesleyProfessional, 1966.

PATTERSON, D. A.; GIBSON, G.; KATZ, R. H. A case for redundant arrays ofinexpensive disks (raid). In: ACM SIGMOD INTERNATIONAL CONFERENCE ONMANAGEMENT OF DATA, 1988, Chicago. Proceedings... New York: ACM, 1988. p.109–116.

RODRIGUES, R. B. RecCloud: um modelo de recomendação para sistemas dearmazenamento em nuvem. Dissertação (Mestrado) — Universidade Federal dePernambuco, 2014.

SALESFORCE. CRM e cloud computing para crescer seu negócio: Salesforce.com brasil.2000. Disponível em: <http://www.salesforce.com/br>. Acesso em: 15 jun. 2014.

SANDBERG, R. The sun network files system: Design, implementation and experience.[S.l.], 1986.

http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/

http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/

http://onedrive.live.com

http://www.novell.com/developer/ndk/netware_core_protocols.html

http://www.novell.com/developer/ndk/netware_core_protocols.html

http://www.devmedia.com.br/vantagens-e-desvantagens-de-soa/27437#

http://www.salesforce.com/br

Referências 68

SANDHU, R.; SAMARATI, P. Access control: principle and practice. CommunicationsMagazine, IEEE, v. 32, n. 9, p. 40–48, Sept 1994. ISSN 0163-6804.

SECURITY, H. N. A closer look at Mega cloud storage. 2013. Disponível em:<http://www.net-security.org/secworld.php?id=14938>. Acesso em: 5 jul. 2014.

SHIVAKUMAR, S. Thought floor : a walk in the clouds (pt 1). 2014. Disponível em:<http://www.infosysblogs.com/thought-floor/2012/02/a_walk_in_the_clouds_part_1.html>. Acesso em: 8 ago. 2014.

SILVA, F. A. P. Monext: an accounting framework for federated clouds. Dissertação(Mestrado) — Universidade Federal de Pernambuco, 2013.

SNIA. Implementing, serving, and using cloud storage. 2013. Disponível em:<http://snia.org/sites/default/files/Implementing_Serving_and_Using_The_Cloud-Nov_2013.pdf>. Acesso em: 15 jun. 2014.

SNIA. What is a storage area network. 2014. Disponível em: <http://www.snia.org/education/storage_networking_primer/san/what_san>. Acesso em: 15 jun. 2014.

SOARES, P. F. A. S. Dedupeer : deduplicação de arquivos através de um algoritmode processamento particionado. Dissertação (Mestrado) — Universidade Federal dePernambuco, 2013.

SOMMERVILLE, I. Software engineering. 8. ed. [S.l.]: Addison Wesley, 2007.

SUBASHINI S. E KAVITHA, V. A metadata based storage model for securing data incloud environment. In: INTERNATIONAL CONFERENCE ON CYBER-ENABLEDDISTRIBUTED COMPUTING AND KNOWLEDGE DISCOVERY (CYBERC), 2011,Beijing. Proceedings... Beijing: IEEE Computer Society, 2011>. p. 429–434.

SUGARSYNC. File sharing, online backup and cloud storage from any device: Sugar sync.2014. Disponível em: <http://www.sugarsync.com>. Acesso em: 13 jul. 2014.

TOMAS, G. H. R. P. Uma arquitetura para cidades inteligentes baseada na internet dascoisas. Dissertação (Mestrado) — Universidade Federal de Pernambuco, Recife, 2014.

YANG, X.; ZHANG, H. Cloud computing and soa convergence research. In:INTERNATIONAL SYMPOSIUM ON COMPUTATIONAL INTELLIGENCE ANDDESIGN (ISCID), 5., 2012, Hangzhou. Proceedings... Hangzhou: IEEE Computer Society,2012. p. 330–335.

http://www.net-security.org/secworld.php?id=14938

http://www.infosysblogs.com/thought-floor/2012/02/ a_walk_in_the_clouds_part_1.html

http://www.infosysblogs.com/thought-floor/2012/02/ a_walk_in_the_clouds_part_1.html

http://snia.org/sites/default/files/Implementing_Serving_and_Using_The_Cloud-Nov_2013.pdf

http://snia.org/sites/default/files/Implementing_Serving_and_Using_The_Cloud-Nov_2013.pdf

http://www.snia.org/education/storage_networking_primer/san/what_san

http://www.snia.org/education/storage_networking_primer/san/what_san

http://www.sugarsync.com

Apêndices

70

APÊNDICE A – Matriz Vantagens eDesvantagens x QAs

APÊNDICE A. Matriz Vantagens e Desvantagens x QAs 71

Tabela 3 – Matriz Vantagens x QAs

Acessoubí-quo

Reduçãode cus-tos

Habilid.decresci-mentosob de-manda

Efetet.com-putaci-onal

Escalab. Conc.de re-cursos

Adequação 0Precisão 0Disponibilidade 1 1 2Tolerância a fa-lhas

1 1

Recuperabilidade 0Comportamentotemporal

1 1

Utilização de re-cursos

1 1 1 3

Reconhecimentode adequação

0

Apreensibilidade 0Facilidade de uso 0Prestatividade 0Atratividade 0Acessibilidadetécnica

1 1 2

Confidencialidade 0Integridade 0Não-repúdio 0Responsabilidade 0Autenticidade 0Susbtituidade 1 1Coexistência 0Interoperabilidade 1 1Modularidade 1 1Reusabilidade 1 1Analisabilidade 1 1Modificabilidade 1 1Estabilidade demodifcação

1 1

Testabilidade 1 1Portabilidade 1 1 1 3Adaptabilidade 1 1 1 3Instalabilidade 1 1 2

APÊNDICE A. Matriz Vantagens e Desvantagens x QAs 72

Tabela 4 – Matriz Desvantagens x QAs

Perdago-vern.

Vinc.Ser-viço

Segur. Dep.co-nect.

Indis.servi-ços

Comp.de re-cursos

Adequação 0Precisão 0Disponibilidade 1 1Tolerância a fa-lhas

1 1

Recuperabilidade 1 1Comportamentotemporal

1 1

Utilização de re-cursos

0

Reconhecimentode adequação

0

Apreensibilidade 0Facilidade de uso 0Prestatividade 0Atratividade 0Acessibilidadetécnica

0

Confidencialidade 1 1 1 3Integridade 1 1Não-repúdio 1 1 1 3Responsabilidade 1 1 1 3Autenticidade 1 1 1 3Susbtituidade 1 1Coexistência 1 1Interoperabilidade 1 1Modularidade 0Reusabilidade 0Analisabilidade 1 1Modificabilidade 0Estabilidade demodifcação

0

Testabilidade 0Portabilidade 0Adaptabilidade 0Instalabilidade 0

Uma Arquitetura de Cloud Storage para Backup de Arquivos...S586a Silva, Thiago Jamir e Uma...

Documents

Transcript of Uma Arquitetura de Cloud Storage para Backup de Arquivos...S586a Silva, Thiago Jamir e Uma...