UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE ARQUIVOS
Dissertação de Mestrado
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
UMA ARQUITETURA DE CLOUD STORAGE PARA BACKUP DE
ARQUIVOS
Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Univer-sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientador: Silvio Romero de Lemos Meira
Co-Orientador: Rodrigo Elia Assad
RECIFE 2014
Catalogação na fonte
Bibliotecária Monick Raquel Silvestre da S. Portes, CRB4-1217
S586a Silva, Thiago Jamir e
Uma arquitetura de cloud storage para backup de arquivos / Thiago Jamir e Silva. – 2014.
72 f.: il., fig., tab.
Orientador: Sílvio Romero de Lemos Meira.
Dissertação (Mestrado) – Universidade Federal de Pernambuco. CIn, Ciência da Computação, Recife, 2014.
Inclui referências e apêndice.
1. Engenharia de software. 2. Computação em nuvem. 3. Arquitetura de software. 4. Sistemas distribuídos. I. Meira, Sílvio Romero de Lemos (orientador). II. Título.
005.1 CDD (23. ed.) UFPE- MEI 2016-132
Antes de mais nada, gostaria de agradecer à toda minha família por todo o apoio. Principalmente minha esposa, Eduarda, por ter acreditado na minha capacidade, quando eu mesmo duvidei. Meus pais, e meu irmão pelo apoio constante, e pelos exemplos que me deixaram para seguir.
Aos meus amigos cujo apoio foi fundamental para o término deste trabalho. Fica aqui o meu obrigado a todos.
Aos professores Professores Silvio Meira (orientador), Rodrigo Assad (co orientador) e Vinícius Garcia, pela oportunidade dada, pelas trocas de idéia, pela cobrança e pelos caminhos que foram indicados.
Ao professor Cícero Garrozi, por se disponibilizar a fazer parte da banca deste trabalho. Ao Centro de Informática da UFPE e todos que o fazem, pelo ensino e suporte dado para que este possa ter concluído.
Aos colegas do ASSERT Lab por todos os feedbacks dados durante a evolução desse projeto. Tenho certeza que essas discussões foram proveitosas para todos nós.
A todos os colegas da Ustore, pela paciência e colaboração de todos , que para mim, é uma segunda casa.
Finalmente, gostaria de agradecer a todos que contribuíram diretamente e indiretamente à realização de mais etapa na minha vida.
Nos últimos anos, o volume de dados gerados por indivíduos e organizações tem crescido exponencialmente. Estima-se que globalmente existia 2.7 zetabytes em 2012 e esse número tem dobrado a cada dois anos. Além disso, com a popularização de dispositivos móveis conectados, cresceu-se a necessidade de que usuários tenham acesso a arquivos de forma ubíqua. As soluções tradicionais de backup e armazenamento de arquivos online já não conseguem suprir as necessidades atuais dos usuários.
A utilização de Cloud Storage para backup e sincronização de arquivos vem a ser uma ferramenta de grande valia para esse tipo de problema. Porém, implementar um sistema deste tipo vem a ser um desafio tecnológico relevante.
Nesse sentido, este trabalho se propõe a resolver o problema de armazenamento de arquivos, propondo uma arquitetura de Cloud Storage para armazenamento de arquivos.
Ao longo trabalho, é feita uma análise dos principais direcionadores de negócio para Cloud
Storage e armazenamento de arquivos, levantando insumos para se projetar uma arquitetura.
Tal arquitetura é descrita em nível de detalhe para que se possa ser implementada. Finalmente, o trabalho é validado através de uma avaliação de arquitetura cuja metodologia foi adaptada de acordo com as características da equipe de avaliação.
Palavras-chave: Arquitetura de software. Cloud computing. Cloud storage. Backup. Sincronização.
In the last years, the amount of data generated by individuals and organizations has grown exponentially. It is estimated that there were 2.7 zettabytes of global data in 2012, and this number has doubled each two years. In addition to this, with the popularization of mobile connected devices, the user’s need to have ubiquous access has grown. Traditional solutions for backup and online file storage can no longer meet the current needs.
The use of cloud storage for backup and file synchronization becomes a tool of great value to this kind of problem. However, implementing such a system becomes a significant technological challenge.
Thus, this works proposes to solve the problem of storing files, designing a Cloud Storage architecture for storing archives.
Throughout work, an analysis of the key business drivers for Cloud Storage and File storage is done by lifting inputs for designing an architecture. This architecture is described in detail for level that can be implemented.
Finally, the work is validated through an evaluation of architecture whose methodology was adapted according to the characteristics of the evaluation team.
Keywords: Software Architecture. Cloud Computing. Cloud storage. Backup. Synchro-nization.
Figura 1 – Modelos de Serviços . . . 19
Figura 2 – Atributos de Qualidade . . . 29
Figura 3 – Divisão em camadas de serviço . . . 40
Figura 4 – Listagem dos Serviços . . . 41
Figura 5 – Visão da estrutura interna . . . 44
Figura 6 – Visão de Implantação . . . 45
Figura 7 – Visão de implantação do basic storage . . . 46
Figura 8 – Visão de componentes do basic storage . . . 47
Figura 9 – Inserção de dados na DHT . . . 49
Figura 10 – Diagrama de classes do nó de armazenamento . . . 50
Figura 11 – Estrutura de um serviço . . . 50
Figura 12 – Diagrama de classes do file storage . . . 51
Figura 13 – Diagrama de sequência de um backup de arquivo . . . 52
Tabela 1 – Atributos de Qualidade escolhidos . . . 30
Tabela 2 – Consolidação dos Resultados . . . 61
Tabela 3 – Matriz Vantagens x QAs . . . 71
ESB Enterprise Service Bus
ATAM Architecture Tradeoff Analisys Method SAAM Software Architecture Analisys Method REST Representational state transfer
1 INTRODUÇÃO . . . 13 Introdução . . . 13 1.1 Definição do problema . . . 13 1.2 Metodologia . . . 14 1.3 Fora do escopo . . . 14 1.4 Estrutura da dissertação . . . 14
2 CONTEXTUALIZAÇÃO E TRABALHOS RELACIONADOS . . . . 16
2.1 Cloud Computing . . . 16
2.1.1 História de cloud computing . . . 16
2.1.2 Definição de Cloud Computing . . . 17
2.2 Cloud Storage . . . 20
2.2.1 História do armazenamento em rede . . . 20
2.2.2 Definindo cloud storage . . . 21
2.2.3 Aplicações de cloud storage . . . 21
2.3 Trabalhos Relacionados . . . 22
2.3.1 Oceanstore . . . 22
2.3.2 Windows Azure Storage . . . 23
2.3.3 Google File System . . . 23
2.3.4 Ustore . . . 24
3 CLOUD STORAGE BUSINESS DRIVERS . . . 25
3.1 Definição do Negócio . . . 25
3.1.1 Principais Vantagens . . . 25
3.1.2 Principais Desvantagens e Ameaças . . . 26
3.1.3 Identificação dos Principais Stakeholders . . . 27
3.1.4 Restrições do negócio . . . 28 3.1.5 Restrições técnicas . . . 28 3.2 Atributos de Qualidade . . . 29 3.2.1 Metodologia . . . 29 3.2.2 Resultados . . . 30 3.3 Requisitos . . . 30 3.4 Conclusão . . . 33 4 DEFINIÇÃO DA ARQUITETURA . . . 34
4.1.2 Persistência . . . 36
4.1.3 Utilização de DHT . . . 37
4.1.4 Controle de Acesso . . . 39
4.2 Orientação a Serviços . . . 39
4.2.1 Camadas de Serviços . . . 40
4.2.2 Descrição dos serviços . . . 41
4.3 Visão Geral da arquitetura . . . 43
4.4 Camada de Serviços Básicos . . . 44
4.5 Camada de Serviços Importantes . . . 48
4.6 Modelo de Dados . . . 51
4.7 Segurança . . . 52
4.8 Conclusão . . . 54
5 AVALIACAO DA ARQUITETURA . . . 55
5.1 Processo de avaliação de arquitetura de software . . . 55
5.2 Equipe de Avaliação da arquitetura . . . 56
5.3 Ameaças á validação . . . 56
5.4 Metodologia de avaliação . . . 57
5.5 Execução do processo de avaliação . . . 57
5.6 Cenários propostos e resultados da avaliação . . . 58
5.7 Consolidação dos Resultados . . . 60
5.8 Conclusão . . . 61 6 CONCLUSÃO . . . 62 7 CONCLUSÃO . . . 63 7.1 Principais Conclusões . . . 63 7.2 Contribuições . . . 63 7.3 Trabalhos Futuros . . . 64 REFERÊNCIAS . . . 65
APÊNDICES
69
APÊNDICE A – MATRIZ VANTAGENS E DESVANTAGENS X QAS . . . 701 Introdução
Atualmente, tem-se observado um crescimento alarmante no volume de dados mundial. De acordo com Gantz J. e Reinsel (2011), esse volume global superou 1 zettabyte em 2010 e tem previsão de alcançar 8 zettabytes em 2015.
Este fato tem ocorrido devido à crescente quantidade de aplicativos e dispositivos que geram conteúdos para armazenar. Desde textos, e-mails até vídeos em alta resolução. Além disso, com o advento dos dispositivos portáteis e a internet móvel, surgiu a necessidade dos usuários de acessar seus conteúdos de forma ubíqua.
As soluções de de backups e sincronização de arquivos tradicionais já não têm suprido a demanda crescente dos usuários. Pois, podemos encontrar alguns problemas nessas solução, tais como:
• Não permitem acesso de qualquer dispositivo;
• Requerem que o usuário esteja conectado a uma rede;
• Tem um custo elevado de hardware para serem implantados; • Não escalam para o volume crescente de dados.
A utilização de sistemas de Cloud Computing e Cloud Storage(MELL; GRANCE, 2011) pode suprir essa demanda. Pois esses sistemas trazem benefícios como acesso amplo, escalabilidade e baixo custo de implantação.
Desenvolver uma arquitetura de Cloud Storage para armazenar arquivos nessa escala, pode se tornar um grande desafio. Pois, além do desafio tecnológico inerente a natureza desses sistemas, também existe uma grande necessidade de se entender seu contexto de negócio. Este trabalho visa analisar o negócio de armazenamento de arquivos através de cloud
storage, para obter insumos e projetar uma arquitetura escalável e segura para armazenar
arquivos.
1.1
Definição do problema
O problema que se pretende resolver neste trabalho é projetar uma arquitetura para armazenamento de arquivos de forma elástica, escalável e segura. Para apoiar esse desenvolvimento, pretende-se responder duas perguntas:
• Quais são os direcionadores de negócio para o uso de Cloud Storage? • Como projetar uma arquitetura que atenda esses contexto?
1.2
Metodologia
Para desenvolver este trabalho, a seguinte metodologia foi utilizada:
• Foi feita uma revisão exploratória da literatura, com o objetivo de encontrar os direcionares de negócio de cloud storage, assim como técnicas que poderiam ser utilizadas para projetar a arquitetura;
• Das informações obtidas sobre o contexto de negócio, foram levantados os atributos de qualidades assim como os requisitos para o sistema;
• Com as técnicas encontradas na revisão, foi projetada uma arquitetura para atender os requisitos e atributos de qualidade.
• Com a ajuda de uma metodologia de avaliação de arquitetura, esse trabalho foi validado;
1.3
Fora do escopo
Os seguintes tópicos foram excluídos do escopo para esse trabalho: • Requisitos e necessidades relativas ao cloud broker (BOHN et al., 2011)
• Serviços e features na arquitetura que não estão diretamente ligadas com o armaze-namento, tais como indexação e busca, APIs externas, entre outros.
• Implementação da arquitetura. • Questões de tarifação (billing).
• Planos de negócio para sistema de Cloud Storage.
1.4
Estrutura da dissertação
O restante da dissertação estará organizada da seguinte forma:
• Na Seção 2 é feita uma contextualização sobre Cloud Storage e trabalhos relacionados. • Na Seção 3 são levantados os direcionadores de negócio de cloud storage.
• Na Seção 4 é apresentada a arquitetura projetada. • Na Seção 5, a avaliação da arquitetura é executada.
• Na Seção 7 são apresentadas as conclusões do trabalho e são levantadas possibilidades para trabalhos futuros.
• Finalmente no Apêndice A é mostrada as tabelas que apoiaram as decisões dos principais atributos de qualidade da Seção 3.
2 Contextualização e Trabalhos
Relaciona-dos
Esta seção visa apresentar uma visão geral de cloud storage, com o objetivo de definir o conceito de cloud computing, cloud storage e backup online, bem como fazer um levantamento histórico de sua origem até o estado atual da arte. Além disso, tem o objetivo de discutir e analisar alguns trabalhos que se relacionam com este.
2.1
Cloud Computing
Antes de estudar cloud storage, é importante ter uma visão geral dos conceitos de
cloud computing, ou computação em nuvem. Uma breve visão histórica e contextual de cloud computing será feita nesta seção.
2.1.1
História de cloud computing
Apesar de ter ganhado destaque nos últimos anos, o conceito de cloud computing não pode ser considerado recente. Em 1950, o cientista da computação Herb Grosh (CRUZ, 2004) postulou que o mundo inteiro operaria em “terminais burros” que seriam servidos por aproximadamente 15 clusters de computadores.
Mais tarde, em 1961, Dalakovi (2014b) sugeriu num discurso que a tecnologia de comparti-lhamento de processamento levaria a um futuro cujo poder computacional ou até aplicações poderiam ser vendidas como um serviço, tal como energia ou eletricidade. Em 1962, J.C.R Licklider (DALAKOVI, 2014a) descreveu um conceito de uma “Rede Intergaláctica de Computadores”, antes de fazer parte da Agência de Projetos de Pesquisa Avançada (
Advanced Research Project Agency - ARPA), que pode ser considerada como a origem da
internet. Nesta rede, usuários poderiam rapidamente localizar e acessar dados e softwares dentro dela e poderiam migrá-las caso necessário. Este conceito descreve não só a Internet como conhecemos hoje, mas também um dos princípios de cloud computing.
Em 1966, Douglas Parkhill, em seu livro “The Challenge of the Computer Utility” (PARKHILL, 1966) descreveu o provisionamento de poder computacional de forma elástica e infinita. Apesar da ideia de cloud computing ter surgido há mais de 50 anos atrás, o termo só veio surgir no ano de 1997 quando Ramnath Chellappa publicou o trabalho chamado
“Intermediaries in Cloud Computing: A New Computing Paradigm” (CHELLAPPA, 1997).
Em 1999 surgiu o SalesForce, a primeira aplicação entregue ao usuário usando o conceito de
software como um serviço de forma escalável e de rápido provisionamento (SALESFORCE,
Em 2002, a Amazon lança a plataforma Amazon Web Service (AMAZON, 2014b), que disponibiliza serviços como computação e armazenamento em larga escala como um serviço. Posteriormente, em 2006, seria lançado o Amazon Elastic Cloud Computing (AMAZON, 2014a), um marco para cloud computing, sendo o primeiro serviço no modelo Infrastructure
as a Service (IaaS).
Outro grande aspecto relevante do cloud computing foi em 2009, quando a chamada Web 2.0 apresentou uma grande evolução e a Google, assim como outras organizações, começou a oferecer aplicações baseadas em browser através de serviços como o Google Apps. Posteriormente, ainda surgiram novas ferramentas baseadas em cloud computing das quais podemos destacar Heroku1, Azure2, Digital Ocean3, Cloud Foundry4, entre outros.
2.1.2
Definição de Cloud Computing
De acordo com o NIST citeMell2011, Cloud Computing pode ser introduzido com a seguinte definição que foi traduzida livremente:
“Computação em Nuvem é um modelo que proporciona um acesso de rede
ubíquo, conveniente e sob demanda, para uma reserva compartilhada de
recursos computacionais (ex: rede, servidores, armazenamento, aplicações e serviços) que pode ser rapidamente providas e liberadas com um esforço mínimo de configuração ou mínima interação com o provedor de serviços. Este modelo é composto por cinco características essenciais, três modelos de serviços e quatro modelos de implantação.”
Dentro da definição apresentada acima, é importante destacar alguns elementos. O compar-tilhamento de recursos viabiliza que um recurso computacional ocioso para um usuário seja utilizado por outros, conforme necessidade. Também é importante frisar que a expansão ou encolhimento da nuvem, deverá ser feita conforme a necessidade e com o mínimo possível de esforço do administrador. Isso viabiliza aplicativos e serviços que outrora dependeriam de toda uma infraestrutura para operar.
Ainda de acordo com o NIST, a Cloud Computing tem cinco características essenciais. São elas:
• Auto serviço sob demanda: Um cliente pode prover unilateralmente capacidade computacional sem necessidade de interação humana com cada serviço.
1 https://www.heroku.com/ 2 http://azure.microsoft.com 3 https://www.digitalocean.com/ 4 http://cloudfoundry.org/index.html
• Acesso de rede amplo: Capacidades são disponibilizadas sobre a rede e acessadas por mecanismos padrões que promovem o uso por uma plataforma heterogêneas de clientes. Elas podem variar desde de telefones celulares a estações de trabalho. • Reserva de recursos: Os recursos computacionais do serviço são agrupados para
servir múltiplos consumidores, sendo dinamicamente realocadas de acordo com a demanda. Geralmente o cliente não tem controle ou informações sobre a localização exata do recurso computacional em uso. Porém, pode haver a possibilidade de especificar esse tipo de informação dentro de uma macro região.
• Elasticidade rápida: Capacidade computacional pode ser provida e liberada, em alguns casos, automaticamente, para rapidamente escalar dependendo da demanda. Para o consumidor, a capacidade disponível frequentemente parece ser ilimitada e pode ser adquirida em qualquer quantidade e a qualquer hora.
• Serviço instrumentado: Sistemas em nuvem automaticamente controlam e otimi-zam o uso de recursos através de instrumentação da capacidade computacional. O uso de recursos pode ser controlado, monitorado e reportado, provendo transparência tanto para o usuário quanto para o provedor.
O termo computação pode ter diversos significados, desde utilização de hardware a execução de um aplicativo específico. Por esse motivo, foram criados os distintos modelos de serviços, que agrupam o que pode ser entregue como serviço. O modelo SPI, que significa Software,
Platform, Infrastructure, é utilizado para classificar os sistemas de cloud computing de
acordo com o tipo de serviço, como se segue:
• Software as a Service (SaaS): O provedor disponibiliza aplicações que são executadas em uma infraestrutura de cloud computing. Geralmente, essas aplicações são utilizadas em um modelo de pagamento por uso e são acessíveis a vários clientes tanto através de um “terminal burro”, como um browser ou por meio de um software cliente. O cliente não tem controle sobre a infraestrutura usada pela aplicação. • Platform as a Service (PaaS): O provedor disponibiliza uma plataforma capaz
de executar programas desenvolvidos ou adquiridos pelo cliente, que foram criados utilizando linguagens de programação, bibliotecas, serviços e ferramentas suportadas pelo provedor. O cliente não tem controle sobre a infra-estrutura utilzada pela aplicação.
• Infrastructure as a Services(IaaS): O provedor disponibiliza para o cliente processamento, armazenamento, rede e outros recursos computacionais básicos, nos quais o cliente pode implantar e executar qualquer tipo de software, que inclui sistemas operacionais e aplicações. O cliente não tem controle total sobre a infraestrutura
que é utilizada, mas gerencia recursos como armazenamento, sistema operacionais e aplicações em execução.
A Figura 1, extraida de Shivakumar (2014) ilustra os diferentes níveis dos modelos de serviços, com alguns exemplos de ferramentas em cada nível de serviço. Quanto maior o nível de abstração, maior o julgamento de valor sobre o serviço que está sendo adquirido e também menor o controle sobre a infraestrutura em uso.
Figura 1 – Modelos de Serviços
Fonte: Infosys Blogs
Ainda de acordo com o NIST, podemos classificar os sistemas de cloud computing de acordo com o modelo de implantação. Como se segue:
• Nuvem privada: A infraestrutura é fornecida para uso exclusivo de uma única organização composta de múltiplos consumidores. Pode pertencer, ser gerenciada e operada pela própria entidade, por um terceiro ou alguma combinação entre eles. • Nuvem comunitária: A infraestrutura é fornecida para uso exclusivo de uma
comunidade de consumidores que tem preocupações semelhantes (por exemplo, missão, restrições de seguranças, entre outros). Pode pertencer, ser gerenciada e operada por uma ou mais das organizações que fazem parte da comunidade, um terceiro ou alguma combinação entre eles.
• Nuvem pública: A infraestrutura é fornecida para uso aberto do público em geral. Pode pertencer, ser gerenciada e operada por uma organização de negócios, acadêmica ou governamental, ou alguma combinação entre eles.
• Nuvem híbrida: A infraestrutura é composta por duas ou mais nuvens, que conti-nuam únicas mas são interligadas de forma que se permita a portabilidade de dados e aplicações.
2.2
Cloud Storage
Uma vez que foi entendida a idéia de cloud computing e suas principais caracte-rísticas, vamos introduzir e analisar conceitos, requisitos e técnicas envolvidas com cloud
storage.
2.2.1
História do armazenamento em rede
Até o início da década de 1980, os computadores armazenavam dados apenas em sistemas de arquivos locais, diretamente conectados àquelas máquinas. Porém, em 1982, Brownbridge conseguiu demonstrar o acesso remoto através de várias estações Linux (BROWNBRIDGE; MARSHALL; RANDELL, 1982), introduzindo assim o conceito da
chamada Network Attached Storage (NAS).
Em 1983, é lançado o sistema operacional NetWare Server com o protocolo NCP (NO-VELL, 2014), que permitia servidores compartilharem arquivos, impressoras, diretórios, comandos remotos, entre outros recursos computacionais.
Em 1984, a Sun desenvolve o NFS (SANDBERG, 1986), que permitiria que servidores compartilhassem seu espaço de armazenamento com terminais clientes.
Em 1985, a 3Com lança o 3Server, o primeiro servidor direcionado para armazenamento, que incluía software e hardware proprietários, e discos múltiplos.
Em 1988, é publicado o artigo “A Case of redundant arrays of inexpensive disks (RAID)” (PATTERSON; GIBSON; KATZ, 1988), que sugeria combinar vários discos baratos, com
capacidade limitada, em uma matriz de forma a aumentar a performance e a confiabilidade dos discos. Este trabalho, juntamente com o Fibre Channel viabilizou as chamadas Storage
Area Network (SAN) (SNIA, 2014).
No início dos anos 90, impulsionados pelo sucesso dos servidores de arquivos de empresas como Novell, IBM e Sun, várias empresas passaram a construir servidores de arquivos dedicados. Ainda nessa época, a Microsoft lança o New Technology File System (NTFS) que permite a um computador acessar uma unidade de armazenamento remota, da mesma forma que um armazenamento local.
Em 2000, as agências do governo dos EUA começam a desenvolver sistemas de computação em grid de forma que permitam usuários compartilhar recursos sem necessidade de um controle central.
No início da década de 2000, algumas companhias começaram a oferecer soluções de NAS em forma de cluster, aumentando ainda mais a confiabilidade e performance dos sistemas de
2014). Serviço que passaria a vender backup e cloud storage como uma mercadoria, num modelo utilizado até os dias atuais.
2.2.2
Definindo cloud storage
Cloud storage nada mais é que um caso especial de Cloud Computing com um
propósito específico de armazenar dados.
Dessa forma, baseado na definição dada pelo NIST, podemos definir Cloud storage como "um modelo que proporciona o armazenamento de dados de forma ubíqua, conveniente e sob demanda a partir de uma reserva de armazenamento compartilhada que pode ser rapidamente disponibilizada com o mínimo de esforço de configuração ou interação com o provedor de serviços."
Assim como nos sistemas de cloud computing, as cinco características são aplicáveis ao cloud
storage (auto-serviço sob demanda, acesso de rede amplo, reserva de recursos, elasticidade
rápida e serviço instrumentado).
Além disso, os três modelos de serviços também se aplicam ao cloud storage. É possível a um cliente adquirir armazenamento como um software, como uma aplicação de backup e sincronização; como uma plataforma, no caso em que o provedor oferece, por exemplo, um banco de dados relacional ou não; ou mesmo como infraestrutura, quando o provedor oferece armazenamento bruto, que seria um disco virtual para que o usuário armazene documentos, dados de aplicativos ou qualquer outro tipo de dados.
2.2.3
Aplicações de cloud storage
De acordo com SNIA (2013), os sistemas de Cloud Storage podem ter várias aplicações dependendo dos objetivos das organizações que as utilizam. Seguem alguns dos principais cenários:
• Backup - Em qualquer organização dados críticos têm que estar seguros, disponíveis e recuperáveis para uma versão prévia. Um sistema de cloud storage pode substituir as soluções tradicionais de backup, como por exemplo, fitas magnéticas, sendo uma forma mais segura, barata e prática de armazenamento de backups.
• Arquivamento - As organizações estão cada vez sendo mais forçadas a reter volumes maiores de dados por longos períodos. Assim como no backup, os sistemas de Cloud
Storage podem substituir as formas tradicionais de arquivamento reduzindo custos e
aumentando a agilidade da recuperação de informação.
• Armazenamento de dados de aplicativos - Aplicações de negócios requerem armazenamento temporário e permanente, que geralmente é disponibilizado por discos
ou soluções de armazenamento em rede como NAS ou SAN. Dados de aplicativos têm requisitos mais críticos de acesso e latência. Uma solução de cloud storage pode trazer vantagem em relação a essas soluções tradicionais, tais como facilidade de backup de aplicativos, redução de custos, entre outros.
2.3
Trabalhos Relacionados
Nesta seção, serão apresentados alguns trabalhos que se relacionam com este trabalho, pois se tratam de sistemas de cloud storage, que foram ou estão sendo utilizados tanto na academia quanto na indústria. Os trabalhos foram apresentados por ordem de publicação.
2.3.1
Oceanstore
Oceanstore (KUBIATOWICZ, 2000) é um projeto concebido na Universidade de Berkley, que visa fornecer uma plataforma aberta e global para armazenamento de dados. Em sua concepção, foi idealizada para objetivos como servir de plataforma para aplicações
groupware (e-mail, calendário, lista de contatos), repositório de dados de grande volume
para grupos científicos ou como servidor para streaming.
A plataforma Oceanstore tem duas premissas: ser construída a partir de um grande grupo de servidores não confiáveis, pois equipamentos quebram sem advertência e não se pode confiar a durabilidade de um dado aos mesmos; a segunda premissa é que os dados são nômades, pois em um sistema de grandes proporções a localidade dos dados é muito importante. O Oceanstore faz cache dos dados em várias localidades para manter a escalabilidade do sistema, abrindo mão da consistência dos dados.
Cada objeto no OceanStore é armazenado com um nome único gerado pseudo-aleatoriamente, chamado GUID (Global Unique Identifier ). Alguns GUID funcionam como um diretório, contendo uma lista de GUID’s, dando a possibilidade da criação de uma estrutura seme-lhante a uma árvore.
O controle de acesso é feito em basicamente duas operações: restrição de leitura e restrição de escrita.
Cada objeto que não é público, é encriptado com uma chave única. Cada usuário que tem permissão de leitura, recebe essa chave para desencriptar. Para revogar o acesso em dado objeto, as replicas são reencriptados com uma nova chave.
Para prevenir escritas não autorizadas, cada escrita é assinada digitalmente e cada objeto tem uma lista de controle de acesso indicando quem pode alterar aquele objeto. A restrição de escrita é feita pelo server que verifica se o usuário que tenta escrever naquele objeto tem acesso ao mesmo.
Cada objeto armazenado no OceanStore pode ter uma réplica em qualquer servidor. Para localizar esses objetos, conta com dois algoritmos. O primeiro, é um algoritmo probabilístico
e rápido, que toma a premissa que existe uma grande probabilidade de um dado acessado frequentemente residir em um servidor próximo. O segundo é um algoritmo hierárquico mais lento, porém mais confiável.
2.3.2
Windows Azure Storage
Windows Azure Storage (CALDER et al., 2011), ou WAS é o sistema de Cloud
Storage da Microsoft, que está em produção desde o final de 2008.
O WAS armazena dados em três formatos: BLOBs, tabelas ou filas para entrega de mensagens. O projeto do WAS, levou em consideração pedidos de vários clientes, que direcionou algumas decisões de projeto. Entre elas estão consistência forte, armazenamento global e escalável, recuperação de desastres, armazenamento multi-tenant.
O WAS roda em múltiplos servidores espalhados ao redor do mundo. Ele possui uma camada que provê gerenciamento de nós, monitoramento da status, e implantação do serviço para o sistema. Essa camada é chamada de Fabric Controller.
Os nós de armazenamento do Windows Azure estão organizados em clusters, denomidados
Storage Stamp, que são gerenciados pelos Location Service, que é um servidor localizado
em uma dada localização, como Europa, América do Norte e Ásia.
Existem dois engenhos de replicação dentro do WAS, o chamado Intra-Stamp, que é responsável pela replicação dentro do cluster de armazenamento, e o Inter-Stamp, que armazena dados de um Stamp para outro, para uma recuperação em caso de desastre.
2.3.3
Google File System
O Google File System (GHEMAWAT; GOBIOFF; LEUNG, 2003), ou GFS é um sistema de arquivos distribuído que foi desenvolvido para satisfazer a demanda de armazenamento e processamento de dados do Google.
Assim como no OceanStore, a arquitetura do GFS assume que servidores não são confiáveis. O sistema de arquivo é formado por uma grande quantidade de hardware barato. Além disso, assume-se que arquivos são naturalmente grandes. Toda a otimização existente no GFS foi feita para arquivos grandes. O GFS também assume que arquivos são modificados anexando-se dados no fim dos mesmos.
O GFS suporta as operações usuais em sistemas de arquivos, tais como criação, deleção, abertura, fechamento, leitura e escrita de arquivos. Contudo, ele ainda introduz duas novas operações: inserção, em que se escreve no fim do arquivo, e snapshot, operação que cria uma cópia do arquivo com um custo muito baixo.
No GFS, ao contrário do OceanStore, existe um servidor central, denominado servidor mestre e vários outros servidores de chunks5. O servidor mestre sabe da existência de todos os outros servidores e é responsável pelo armazenamento de metadados, que são os 5 Chunks são pequenos pedaços dos quais se compões um arquivo, registro, ou qualquer unidade de armazenamento
arquivos, os chunks que compõem cada arquivo e a localização de cada chunk. O servidor mestre armazena todos os metadados em memória.
Cada arquivo é composto por chunks de 64MB, e eles são armazenados no sistema de arquivo local dos chunk servers.
Os chunks são replicados de acordo com a necessidade. Existe um controle para que chunks novos não criem muitas réplicas, para evitar sobrecarga na escrita de novos arquivos. O controle da replicação do GFS é feito através do mestre.
2.3.4
Ustore
Ustore (DURãO et al., 2013) é uma plataforma de Cloud Storage em nuvem privada desenvolvido para armazenar arquivos, fazendo backup e sincronização deles.
Uma diferença marcante na plataforma Ustore é que ele pode utilizar discos ociosos das máquinas de uma corporação, formando uma nuvem privada com as estações de trabalho. Para que as estações se comuniquem, é utilizado uma rede overlay peer to peer (P2P), que implementa o protocolo conhecido como JXTA6.
A arquitetura do Ustore leva em consideração quatro atributos de qualidade como pilares de suas decisões arquiteturais, que são: escalabilidade, otimização das interações, disponi-bilidade e segurança.
Na rede overlay existe um tipo de peer especial que tem a responsabilidade de configurar a rede e manter rotas entre estações diferentes. Esse peer é chamado de Super Peer, e precisa ser mantido em um servidor conhecido por todos os peers, como uma espécie de servidor central. Porém, sua úncia função é manter a conectividade entre os peers. Além da existência do superpeer, existem os chamados peers servidores, que implementam uma gama de serviços e são localizados pelos peers clientes, através do anúncio de seus serviços na rede JXTA.
Finalmente os simple peers, ou apenas clientes, que são peers que são utilizados para enviar ou recuperar arquivos da nuvem, assim como utilizar o espaço ocioso na máquina do usuário para salvar arquivos de outros usuários.
A replicação no Ustore se dá através de um algoritmo estatístico, em que se registra o histórico de conexão de cada cliente, traçando assim um perfil do mesmo. As replicados dos backups são enviados a outros clientes que têm perfil semelhante ao do usuário, otimizando assim a disponibilidade do arquivo, mantendo um número mínimo de réplicas.
3 Cloud Storage Business Drivers
Nesta seção será feita uma análise nos direcionadores de negócio de Cloud Storage, e a partir daí serão desenvolvidos os business drivers. A partir dos business drivers, é possível obter insumos para pautar as decisões arquiteturais, tais como os Requisitos do sistema, assim como os principais atributos de qualidade.
Esses insumos também serão úteis para, durante a avaliação da arquitetura, verificar a conformidade dessa com as necessidades de negócio.
3.1
Definição do Negócio
Embora cloud storage ja tenha sido definido anteriormente, é necessário ressaltar que o conceito de armazenamento em nuvem é bastante abstrato. Neste trabalho, os esforços serão concentrados em sistemas de armazenamento de arquivos.
Deseja-se utilizar a elasticidade da nuvem para armazenar arquivos, garantindo fatores como a disponibilidade, segurança, escalabilidade e acesso ubíquo aos dados armazenados pelos usuários, para uso de backup, sincronização de arquivos ou arquivamento.
Esta solução irá representar duas das maiores tendências na Tecnologia da Informação (MARSTON et al., 2011) a eficiência tecnológica, pois o poder computacional é melhor utilizado através de recursos de hardware e software escaláveis e agilidade de negócio, que possibilita empresas pequenas ou em estágio inicial, ter acesso a um elevado poder computacional.
Em Grossman (2009), ENISA (2009) e Aljabre (2012) é possível observar algumas das principais vantagens e desvantagens da adoção de Cloud Computing por empresas. A partir delas, foi possível observar também sua aplicabilidade para Cloud Storage.
3.1.1
Principais Vantagens
• Acesso ubíquo - Provedores de serviços de armazenamento em nuvem podem disponibilizar várias interfaces de acesso diferentes para seu serviço, possibilitando, assim, aos usuários, acesso aos dados através de formas e dispositivos distintos. • Redução de custos - Organizações podem ter acesso a recursos computacionais
com custo reduzido, uma vez que essas aplicações usufruem dos recursos que está na nuvem do provedor do serviço. Essa redução de custos engloba aquisição e manutenção tanto de hardware como de software.
• Habilidade de crescimento sob demanda - É possível para um pequeno negócio usar Cloud Computing, com um pequeno custo, e com o crescimento do negócio, aumentar a capacidade computacional sob demanda.
• Efetividade computacional - É possível prover serviços, continuidade e segurança mais efetivamente do que soluções tradicionais de TI.
• Escalabilidade - Arquiteturas em Cloud Computing mostram-se amplamente esca-láveis (GROSSMAN, 2009).
• Concentração de recursos -O compartilhamento de hardware físico proporciona uma perimetrização mais barata assim como um controle de acesso físico mais eficiente.
3.1.2
Principais Desvantagens e Ameaças
A adoção de cloud storage pode apresentar um conjunto de benefícios, conforme apresentado anteriormente. Entretanto, é relevante se considerar os pontos fracos, ameaças e preocupações relativas ao uso de cloud storage. A lista abaixo apresenta algumas das principais desvantagens de utilizar um serviço de nuvem para armazenamento.
• Perda de governança das informações - Em se utilizando do serviço da nuvem para armazenamento, o cliente está cedendo ao provedor de serviço controle sobre informações de sua empresa. Alguns sistemas de Cloud Storage, como o Mega (SECURITY, 2013), armazenam de forma que somente o proprietário do conteúdo,
ou alguém com sua permissão, possa acessar aquele conteúdo.
• Vínculo com o serviço - Uma vez que um usuário adota um serviço de armazena-mento em nuvem, mudar para outro provedor de serviço, ou voltar para abordagens tradicionais de armazenamento pode tornar-se inviável devido ao grande número de dados armazenados.
• Segurança - Apesar de armazenamento em nuvem ter um nível de segurança satisfatório, sempre existe um risco permanente da mesma ser exposta, e dados de uma organização sejam acessados por pessoas não autorizadas.
• Dependência de conectividade - Para se acessar um serviço de armazenamento em nuvem, é necessário uma conexão de rede com o provedor do serviço. A perda dessa conexão, implicará na impossibilidade temporária de acesso a dados, que podem ser críticos.
• Indisponibilidade dos serviços - Apesar dos sistemas de cloud storage terem um nível de disponibilidade bem alto, uma eventual disponibilidade do sistema,
pode impedir temporariamente dados cruciais. Assim como em qualquer sistema de armazenamento de dados.
• Compartilhamento de recursos - Apesar do compartilhamento de recursos ser um benefício, por trazer redução de custos, também pode ser uma preocupação em relação a confidencialidade e segurança. Principalmente em um ambiente de nuvem pública, onde várias organizações compartilham o mesmo recurso.
3.1.3
Identificação dos Principais Stakeholders
Para desenvolver uma arquitetura para um sistema precisamos identificar o prin-cipais envolvidos com o mesmo e suas devidas necessidades. De acordo com Bohn et al. (2011), podemos listar os seguintes stakeholders para qualquer sistema de Cloud Computing:
• Cloud Consumer - São pessoas ou organizações que mantêm um relacionamento e usam os serviços de um Cloud Provider. No nosso caso, são os indivíduos ou corporações que utilizam o sistema de Cloud Storage para armazenar arquivos. Eles necessitam de uma ferramenta para fazer backup e sincronização de arquivos online. • Coud Provider - Uma pessoa, grupo ou entidade responsável por manter o serviço disponível para as partes interessadas. No caso do sistema de Cloud Storage, que hospedaria e manteria o sistema de cloud storage. Além do serviço em si, também precisa de um módulo em que possa administrar, mensurar e manter o serviço. • Cloud Auditor - Uma organização que pode conduzir uma auditoria independente
dos serviços de cloud, das operações, performance e segurança da implementação da
cloud. Devem possuir ferramentas que se possa mensurar um grupo de métricas para
se realizar essas auditorias.
• Cloud Broker - Uma entidade que gerencia o uso, performance e entrega dos serviços de cloud, e negocia a relação entre Cloud Provider e Cloud Consumer. Têm a necessidade de um módulo que possa gerenciar a nuvem, mensurar o uso e taxar os usuários.
• Cloud Carrier - Uma organização intermediária que provê conectividade e trans-porte de serviço de Cloud Providers para Cloud Consumers. Tipicamente são os provedores de internet.
Para o escopo desse trabalho, serão focadas as necessidades relacionadas aos grupos de
Cloud Consumers, que serão chamados de usuários finais, ou apenas usuários, e os Cloud Providers, que serão denominados de provedores de serviços.
3.1.4
Restrições do negócio
Adicionalmente, para o desenvolvimento de qualquer arquitetura, é imperativo se observar as restrições que o negócio impõe ao software. Em Khajeh-Hosseini et al. (2012) são apresentadas algumas dessas restrições que pode afetar um sistema de cloud computing. Dentre elas, destacamos algumas:
• Custos - O custo de utilização ou implantação de um sistema de cloud storage não pode ter um impacto financeiro considerável, seja relativo ao custo de implantação de uma nuvem privada interna, ou à aquisição do serviço através de um provedor. • Mudanças organizacionais - O processo de mudança para utilização de soluções
em nuvem ocasionará em um impacto organizacional. O tipo de mudança varia de organização para organização. Alguns tipos de mudanças que podem ocorrer são em relação à contabilidade, segurança, geografia, suporte e até ao trabalho dos usuários finais.
3.1.5
Restrições técnicas
Assim como no caso das restrições de negócio, é relevante listar as restrições técnicas para evitar surpresas no desenvolvimento de uma arquitetura. Algumas delas são encontradas em sistemas de cloud storage:
• Teorema de Brewer - Conhecido também como teorema do CAP, foi demonstrado em Gilbert e Lynch (2002) e prova que não é possível em um sistema computacional manter a consistência, disponibilidade e a tolerância à partição simultaneamente. Isso é de grande relevância para sistemas de cloud storage, dado que a disponibilidade é essencial, e geralmente se opta entre a consistência e a tolerância à partição. • Limitação do hardware - Apesar de elástico, o volume armazenado por um
sistema de cloud storage é limitado pelo armazenamento do hardware (físico ou virtual) que o hospeda. Assim como sua largura de banda será limitada pela banda da comunicação entre o usuário e o provedor do serviço.
• Acordo de nível de serviço (Service Level Agreement - SLA) - É uma parte do contrato entre o provedor de serviço e o usuário que estabelece métricas mínimas para o funcionamento do serviço. São exemplos de métricas comuns de SLA para serviço de armazenamento em nuvem a disponibilidade, o tempo de resposta, taxa de erros, entre outras.
3.2
Atributos de Qualidade
Em um sistema computacional, as funcionalidades são fundamentais. Pois a partir das necessidades dos usuários, surge a demanda para o software. Contudo, os atributos de qualidade também são relevantes para guiar as decisões arquiteturais.
A qualidade de software pode ser avaliada pelo grau em que o software possui de combinação dos atributos de qualidade, que são características importantes e devem ser priorizadas no desenvolvimento do software. Existem várias formas de se expressar atributos de qualidade, tais como funcionalidade, negócio, segurança, entre outras.
A norma ISO/IEC 25010.2 (ISO/IEC, 2010) define um modelo de qualidade de produto que é composto por oito características que relatam tanto propriedades estáticas, quanto dinâmicas de um sistema de computação.
A Figura 2 mostra o modelo de qualidade de software apresentado na norma. Ela divide a qualidade de software em oito características que são adequação de funcionalidade, confiabilidade, eficiência de performance, operacionalidade, segurança, compatibilidade, manutenibilidade e transmissibilidade. Essas características são subdivididas em trinta e oito sub-características que auxiliam na descrição da qualidade de um software.
Figura 2 – Atributos de Qualidade
Fonte: ISO/IEC 25010.2
3.2.1
Metodologia
Para definir os atributos de qualidade, a seguinte metodologia foi utilizada: Por meio de revisão bibliográfica foram levantadas as principais vantagens da utilização de
cloud storage as desvantagens, preocupações e ameaças. Além disso, também foram listados
software.
Em seguida, foi feita uma matriz, cujas colunas representam as vantagens e desvantagens, enquanto as linhas representam os atributos de qualidade. Essa matriz foi preenchida com o valor um, caso a presença do atributo de qualidade contribua para uma das vantagens ou amenize uma desvantagem, ou zero caso contrário. Dessa forma, foi possível selecionar os atributos de qualidade de forma que se possa maximizar os benefícios e atenuar as perdas, selecionando os atributos de qualidade com maior número de 1s seriam considerados os prioritários.
3.2.2
Resultados
Os atributos de qualidade foram enumerados de acordo com as Tabelas 3 e 4 disponíveis no Apêndice A. Como se pode observar, os principais atributos de qualidade eleitos estão de acordo com a Tabela 1.
Tabela 1 – Atributos de Qualidade escolhidos ID Nome Q1 Disponibilidade Q2 Utilização de recursos Q3 Confidencialidade Q4 Não-repúdio Q5 Autenticidade Q6 Portabilidade Q7 Adaptabilidade
A ordem dos atributos não necessariamente representa a ordem de prioridade nas definições arquiteturais.
Se analisarmos a lista de atributos, podemos observar que precisamos de um sistema que mantenha-se o maior tempo possível online (Q1), que tenha o menor custo possível (Q2), que seja seguro (Q3, Q4 e Q5) e possa ser facilmente instalado em qualquer ambiente (Q6 e Q7).
3.3
Requisitos
Em um sistema de software, além dos atributos de qualidade, os requisitos também guiam as decisões arquiteturais. De acordo com Sommerville (2007), o verdadeiro teste de uma arquitetura recai sobre quão bem ela atende os requisitos funcionais e não-funcionais depois de implantada.
Para a definição de requisitos funcionais e não-funcionais neste trabalho, foram observadas as principais ferramentas de backup em nuvem, tais como o Dropbox (DROPBOX, 2014), SugarSync (SUGARSYNC, 2014), Google Drive (GOOGLE, 2014), Onedrive (MICRO-SOFT, 2014), entre outros. Além disso, tais requisitos foram revistos por analistas com
experiência na indústria nesse segmento. A partir daí, foi possível listar os seguintes requisitos funcionais e não-funcionais:
• R1 - Upload (backup) de arquivos
O usuário final pode enviar arquivo para seu drive virtual na nuvem. Uma vez que esse arquivo é enviado para nuvem, deverá permanecer até que o usuário decida excluir ou modificar aquele arquivo. O usuário poderá enviar arquivos para nuvem de múltiplos dispositivos de forma ubíqua.
• R2 - Download (restore) de arquivos
Uma vez que um usuário tenha enviado um arquivo para o seu drive virtual, a qualquer momento, desde que tenha conectividade com o sistema, ele pode recuperar e baixar aquele arquivo, de qualquer dispositivo que ele tenha acesso ao sistema. • R3 - Exclusão de arquivos
O usuário pode excluir arquivos que tenham sido previamente salvos na nuvem. Não se pode fazer download de arquivos excluídos. Uma vez que o arquivo tenha sido deletado, o usuário pode recuperá-lo dentro de um período definido pelo provedor do serviço.
• R4 - Compartilhamento de arquivos
O usuário pode compartilhar qualquer arquivo ou diretório dentro de seu disco virtual. Este processo em uma pasta será recursivo. Ou seja, uma vez que uma pasta tenha sido compartilhada, qualquer arquivo ou subpasta também o será. A qualquer momento o proprietário do arquivo poderá revogar o acesso àquele arquivo ou pasta. • R5 - Publicação de arquivos
Assim como um usuário pode compartilhar arquivos, ele também pode publicá-los, garantindo acesso aos arquivos compartilhados para todos os usuários da nuvem. Assim como no compartilhamento, a qualquer momento o proprietário pode revogar acesso aos arquivos.
• R6 - Pesquisa de arquivos
O usuário pode pesquisar arquivos dentro de seu disco, seja por nome de arquivos, seja pelo conteúdo dos arquivos.
• R7 - Cadastro de usuários
O provedor de serviços terá acesso a um cadastro de usuários, que permitirá incluir, modificar ou remover usuários. Também será possível habilitar uma funcionalidade para que o próprio usuário efetue seu cadastro.
• R8 - Tarifação de usuários
para que possa taxar o usuário de acordo com os termos de serviços estabelecidos entre as partes.
• R9 - Expansão ou encolhimento da nuvem
O provedor de serviços deverá ser capaz de aumentar ou diminuir a capacidade da nuvem, seja através de software, ou mesmo através da adição de mais hardware para sua nuvem.
• R10 - Tempo de resposta
O sistema deve manter um tempo de resposta de acordo com o SLA firmado no contrato com usuário. Não podemos estipular um valor exato, uma vez que, esse valor depende do valor contrato entre usuário e provedor.
• R11 - Disponibilidade
O sistema deve manter-se disponível por um período igual ou superior àquele firmado no SLA entre usuário e provedor. É importante observar que alguns contratos estipulam um downtime mínimo para que o serviço possa ser considerado indisponível. • R12 - Resiliência dos arquivos
O sistema deve se recuperar de eventuais falhas de hardware sem perder os dados nele armazenados. Mais uma vez, o SLA pode prever exceções para este requisito, especificando uma taxa máxima de falhas irrecuperáveis que podem ocorrer.
• R13 - Integridade dos dados
Os dados armazenados no sistema não devem sofrer modificações indesejadas, que venham a corromper os dados armazenados. O SLA poderá especificar uma taxa máxima de dados corrompidos.
• R14 - Consistência de dados
Mesmo se tratando de um sistema distribuído, o sistema deve manter a consistência das informações nele armazenadas, havendo apenas uma única versão de um dado qualquer. Então, se por exemplo, um cliente escreve um arquivo em um nó, ele deve acessar o mesmo conteúdo em outro nó do sistema.
• R15 - Durabilidade
Uma vez armazenados, os dados contidos no sistema estarão em definitivo, não sendo excluídos pelo próprio sistema ou fatores externos, salvo se excluído pelo proprietário do arquivo.
• R16 - Autenticação
Para garantir a segurança do sistema, para toda ação executada pelo sistema, o autor daquela ação deverá estar devidamente identificado através de credenciais seguras.
• R17 - Autorização
Em adição à Autenticação, para cada ação realizada pelo usuário, deverá se verificar se ele tem a permissão para executá-la, impedindo assim, ao usuário executar ações que o mesmo não tem direitos.
• R18 - Auditoria
Cada ação de um usuário, além do mesmo estar devidamente identificado e autorizado, o sistema também manterá um registro de todas as ações críticas executadas pelo mesmo. Os requisitos Autenticação, Autorização e Auditoria completam a segurança do sistema.
• R19 - Interface externa
O sistema deverá prover interfaces para o desenvolvimento de aplicações de terceiros, que possam usar o armazenamento em nuvem como plataforma, respeitando todos os requisitos listados anteriormente.
3.4
Conclusão
A partir de uma análise do negócio de cloud storage e backup online, foi possível estabelecer diretrizes para o desenvolvimento de uma arquitetura de cloud storage para
backup e armazenamento de arquivos.
A partir dos requisitos e atributos de qualidade, é possível tomar decisões arquiteturais de forma que os satisfazem, priorizando os principais atributos de qualidade.
Além disso, deveremos utilizar os atributos de qualidade na avaliação da arquitetura proposta, validando assim este trabalho
4 Definição da Arquitetura
Nesta seção, será apresentada a arquitetura de software para resolver o problema proposto. A partir da análise de negócios, temos os requisitos e atributes de qualidade que deverão ser satisfeitos.
Inicialmente foram documentadas todas as principais decisões arquiteturais para o sistema, e, tomando essas decisões como diretrizes, a arquitetura foi projetada.
4.1
Decisões arquiteturais
Um conhecido problema em projetos de arquitetura de software é a falta de clareza nas justificativas sobre o seu projeto. As decisões arquiteturais estão embutidas no projeto da arquitetura. Desta forma, o conhecimento sobre as decisões arquiteturais é perdido durante a execução do projeto. Com base nessas informações, Jansen e Bosch (2005) propõe documentar a arquitetura como um conjunto de decisões arquiteturais.
Decisões arquiteturais podem ser definidas como uma descrição de um conjunto de adições, subtrações e modificações da arquitetura de software, da linha de raciocínio, das regras e restrições do projeto e requisitos adicionais que realizam completamente ou parcialmente um ou mais requisitos do software.
Desta forma, como primeiro passo para projetar a arquitetura proposta, iremos destacar e justificar as principais decisões arquiteturais.
4.1.1
Orientação a Serviços através de REST
Arquitetura Orientada a Serviços (JOSUTTIS, 2007) ou Services Oriented Archi-tecture (SOA) (do inglês Software Oriented ArchiArchi-tecture) é um paradigma de pensamento que leva a uma arquitetura concreta. SOA tem como objetivo aumentar a flexibilidade do negócio.
SOA possui alguns direcionadores, tais como sistemas distribuídos, diferentes provedores e heterogeneidade. Esses são conceitos que combinam com os drivers de negócio de um sistema de cloud storage. Além disso, os direcionadores do SOA estão de acordo com os atributos de qualidades indicados na Seção 3.
Em uma arquitetura orientada a serviços, o software é decomposto em serviços, unidades lógicas que representam um grupo de funcionalidade de negócios. Os serviços são projetados de forma a abstrair todo o seu funcionamento interno, de forma que pessoas não técnicas possam entender o papel do serviço dentro do ecossistema do negócio. Esses serviços
podem ser heterogêneos, sendo implementados em diferentes tecnologias, em hardwares diferentes, ou até mesmo em provedores diferentes.
Dados que estes serviços são heterogêneos, é importante que eles se comuniquem facilmente. Este conceito é chamado de interoperabilidade, e é o segundo conceito de SOA, sendo o primeiro os serviços.
O último conceito de SOA é o baixo acoplamento, que significa minimizar a depen-dência entre os serviços. Assim, modificações têm efeitos mínimos e o sistema continua parcialmente funcional ainda que uma parte do sistema esteja quebrada.
A opção da abordagem SOA ocorreu, entre outros motivos, pelas suas vantagens apre-sentadas em Oliveira (2014). Dentre elas, as seguintes vantagens podem ser consideradas relevantes para um sistema cloud storage:
• Baixo acoplamento, que possibilita o funcionamento parcial do sistema, mesmo em caso da não disponibilidade de algum serviço, além de diminuir o impacto em modificações nos serviços;
• Reuso, serviços podem ser reutilizados para funções comuns dentro do sistema de
cloud storage. Além disso, serviços existentes podem ser reutilizados em
desenvolvi-mento de novos sistemas de software;
• Manutenibilidade, como consequência do baixo acoplamento, a manutenção do sistema é feito apenas no serviço que está sofrendo alterações, não havendo modifica-ções de grande impacto nos demais, agilizando o processo de melhoramento contínuo do software;
• Interoperabilidade, dado que cada serviço é independente de hardware ou mesmo de tecnologia de desenvolvimento, mantendo-se uma interface de comunicação bem definida.
Entretanto, essa opção trará pontos adversos, que deverão ser considerados no restante do projeto do sistema de software. São elas:
• Aumento da complexidade, visto que cada serviço é executado de forma in-dependente, a interoperabilidade terá um custo: o maior número de camadas de software para comunicação entre os serviços; perda de performance, que também é consequência da complexidade da abordagem SOA. Isso poderá afetar o tempo de resposta do sistema, que apesar de importante, não é um dos principais atributos de qualidade do sistema;
• Perda de robustez, pelo fato de que transações podem envolver vários serviços, nesse caso, não é possível garantir a atomicidade das mesmas. Esse ponto deverá ser observado nas demais decisões e design da solução;
• Segurança, pode ser um problema relevante, dado que como os serviços executam de forma distribuída e independente, então um agente malicioso pode se passar por um serviço e conseguir acesso a informações não autorizadas.
Outro aspecto entre o casamento entre SOA e Cloud Computing pode ser justificado de acordo com Yang e Zhang (2012) que declara as seguintes afirmações:
• SOA pode ajudar a construir o ambiente de Cloud Computing; • SOA e Cloud Computing são complementares;
• Cloud Computing fornece uma realização de SOA; • SOA e Cloud Computing podem se misturar.
Finalmente, na abordagem SOA para o sistema de Cloud Storage, deverá ser imple-mentado utilizando o padrão de projeto SOA chamado camada de serviços (ERL, 2009), que consiste em várias camadas de inventários de serviços, que são serviços agrupados por afinidade. Funciona como o estilo arquitetural em camadas em softwares tradicionais. As camadas serão apresentadas mais adiante neste mesma Seção.
4.1.2
Persistência
Assim como qualquer sistema, o Cloud Storage precisa persistir dados de forma organizada. Em um sistema de grande porte, tipicamente se utiliza um banco de dados, relacional ou não, para armazená-los. Porém, um sistema de cloud storage, por definição, é utilizado para guardar dados de forma segura e escalável, assim como os sistemas de gerenciamento de banco de dados.
Logo, optou-se por não utilizar um banco de dados externo para armazenar metadados do sistema, de forma a reduzir custos e aumentar a portabilidade do sistema. Será utilizado o próprio ambiente de cloud storage para se guardar tanto os conteúdos dos arquivos, que serão denominados de dados, como as metainformações sobre o sistema de arquivo, que serão chamados de metadados.
É comum em sistemas de arquivos distribuídos (DFS) (BžOCH, 2012) subdividir o arma-zenamento em duas unidades, sendo uma para conteúdo dos arquivos (dados) e outra para metadados.
storage para armazenar metadados de forma eficiente e segura. Nesse trabalho, a segurança
é obtida através da fragmentação de dados sensíveis.
Em Jiang et al. (2012) podemos observar que é possível utilizar um ambiente de cloud para implementar uma arquitetura de cloud flexível e escalável, abrindo mão da consistência imediata. Nesses trabalhos, a consistência é atingida através da chamada consistência eventual, em que os dados salvos no nós distribuídos em um certo intervalo de tempo após sua inclusão.
Podemos listar as vantagens dessa abordagem. Primeiramente seria a escalabilidade já que o armazenamento de metadados deverá crescer de acordo com o crescimento do sistema. Ademais, trata-se de um armazenamento distribuído, por isso elimina pontos únicos de falha. Também é importante considerar a portabilidade e adaptabilidade, visto que devido à não necessidade de um software externo para armazenar metadados, não há dependência de sistema operacional, ambiente ou qualquer situação que restrinja o uso de um software. Ou seja, na fase de implantação do software, ele elimina o pré-requisito de um software de um sistema de gerenciamento de banco de dados, e não requer a manutenção do mesmo na fase de produção.
Contudo, uma consequência dessa decisão arquitetural será o maior esforço de imple-mentação, visto que utilizar um sistema de gerenciamento de banco de dados seria mais rápido. Um aspecto importante nesse sentido, seria manter o baixo acoplamento, para flexibilizar a utilização de diferentes formas de armazenamento de metadados no futuro. É importante deixar em aberto na arquitetura, interface para que se acople formas diferente de armazenamento tais como sistemas de arquivos, banco de dados em memória, bancos de dados externos entre outros. Porém, nesse trabalho, utilizaremos apenas o cloud storage como armazenamento de metadados. Assim como na implementação, a manutenibilidade é outro ponto a se considerar, pois da mesma forma que a implementação, utilizar um banco de dados externo tornaria mais fácil a manutenção do sistema. Finalmente, a falta de segurança é uma ameaça importante, pois esses metadados não poderão ser acessados por pessoas não autorizadas.
4.1.3
Utilização de DHT
Em um sistema de cloud storage, os dados são armazenados em diversos nós. Assim, um problema que ocorre, é a localização desses dados. Deve-se haver uma estratégia para se definir tanto para em qual nó um certo dado será armazenado, assim como, de qual local será possível recuperar esse dado rapidamente, sem tornar a busca custosa ou lenta. A solução adotada para este problema é a utilização de uma distributed hash table (DHT) (BALAKRISHNAN et al., 2003). Como o próprio nome diz, uma DHT não é nada mais
que uma estrutura de tabela de hash distribuída em vários nós. Uma DHT tipicamente contém duas operações básicas: inserção de objetos (put), no qual se associa uma chave a um dado objeto e esse objeto é armazenado na tabela; e recuperação (get) na qual, a
partir da chave de um objeto, que é conhecida, pode-se recuperar aquele objeto na DHT. Em geral, os algoritmos de DHT lidam com três problemas básicos:
• Mapear chaves com nós de forma balanceada: Cada nó deve conter aproxi-madamente a mesma quantidade de dados para evitar problemas de sobrecarga de um dado nó. Geralmente esse problema é resolvido utilizando uma função de hash tanto para a identificação do nós (ex: o endereço IP do nó) quanto para a chave em questão, e feita uma correlação entre eles;
• Redirecionar uma requisição para o nó correto: Qualquer nó que recebe uma requisição para um dado nó, deve ter a capacidade de redirecionar a requisição para o nó correto. Esse redirecionamento pode conter vários saltos até se alcançar o nó em questão; e
• Construir tabelas de rotas: Para redirecionar as requisições, cada nó deve conhe-cer os seus nós mais próximos. Um exemplo para esse caso é a disposição de nós em anéis, onde cada nó conhece o próximo, e pode redirecionar mensagens até que a mesma alcance seu destinatário.
Para a arquitetura proposta optou-se por utilizar um esquema similar ao Amazon
DynamoDB (DECANDIA et al., 2007) que é utilizado para um sistema de armazenamento
de dados em cloud. Nesse esquema, os dados e metadados são distribuídos em vários nós, e cada nó é responsável pelo subconjunto de hashes. Suas responsabilidades incluem armazenamento, replicação e busca. Essa abordagem será descrita em maiores detalhes na seção 4.3.
As principais vantagens dessa decisão arquitetural são a escalabilidade, já que os dados são armazenados de forma distribuída e não há um nó central para receber as requisições, e a tolerância a falhas, visto que não há um ponto único de falha. Além disso os sistemas de DHT tratam problema como a entradas e falhas de nós, nos quais as tuplas devem ser realocadas para novos nós em caso de desconexão de algum nó ou a entrada de novos nós na rede; e por fim, tempo de resposta, considerando que algoritmos de pesquisa de recursos numa DHT otimizam o tempo de busca de recursos.
Uma preocupação em relação a essa decisão seria em relação à segurança, uma vez que um agente mal intencionado poderia se passar por um nó para receber ou obter dados confidenciais. Além disso, de acordo com o teorema de Brewer (GILBERT; LYNCH, 2002) é impossível manter a consistência dos dados e simultaneamente manter a sua distribuição e a disponibilidade.
4.1.4
Controle de Acesso
Uma preocupação constante em Cloud Storage, é a segurança dos dados. Um sistema de controle de acesso é necessário tanto para proteger a confidencialidade dos arquivos nele armazenados, como evitar que um agente malicioso remova arquivos de grande valia.
Além disso, uma funcionalidade importante para esse sistema é o compartilhamento de arquivos, que permite que um usuário conceda ou revogue acesso a outros usuários. Finalmente, os metadados do sistema também precisam ser mantidos em segurança, pois através deles é possível remontar o sistema de arquivo dos usuários do sistema.
Uma possível solução para acesso a arquivos e compartilhamento, é implementar um sistema de controle de acesso discricionário (SANDHU; SAMARATI, 1994). Em um sistema de acesso discricionário, cada usuário tem um conjunto de autorizações sobre cada objeto, que, no caso do sistema proposto, seriam os arquivos, e os modos de acesso que aquele usuário tem acesso, tais como escrita ou leitura. Para cada acesso à determinado objeto, é verificado se existe alguma autorização para aquele tipo de acesso ao objeto pelo usuário. Se existe, o acesso é permitido, caso contrário, negado.
Além disso cada proprietário de um recurso, tem o direito de modificar as autorizações para cada usuário, garantindo acesso ou revogando caso necessário.
Para se implementar esse controle de acesso deve-se utilizar criptografia de dados. Esses dados devem ser encriptados de forma que apenas o dono ou alguém autorizado a esses dados tenham acesso aos mesmos.
Uma vantagem clara dessa decisão é o aumento da segurança do sistema, que não havia sido priorizada em nenhuma das decisões anteriores. Porém, o custo desse controle de acesso, somado com a encriptação e decriptação de dados, consumirá mais recursos do sistema, impactando negativamente no tempo de resposta, na escalabilidade e na utilização de recursos.
4.2
Orientação a Serviços
Como foi demonstrado na seção anterior, a arquitetura em concepção deverá utilizar o paradigma de orientação a serviços. Portanto, deve-se listar todos os serviços que farão parte da arquitetura e como eles irão se relacionar entre si. Também foi decidido utilizar uma abordagem com o padrão de projeto de camada de serviços para que o sistema tenha uma organização de negócio mais clara, além de ser uma forma de encapsular a lógica de toda uma camada de serviços, contribuindo ainda mais para o baixo acoplamento do sistema.
4.2.1
Camadas de Serviços
A Figura 3 mostra a divisão lógica dos serviços do sistema. A camada fundamental do sistema é a camada de serviços básicos. Essa camada é responsável pelo armazena-mento, recuperação e resiliência de dados e metadados do sistema. Ela terá a função de camada de persistência para as demais camadas, sendo uma plataforma para as outras camadas armazenarem dados e metadados. Os dados armazenados na camada de serviços básico são tuplas chave-valor. Os valores são salvos de forma bruta, como um stream de
bytes, sem haver qualquer análise ou semântica associada. Acima da camada de serviços
Figura 3 – Divisão em camada de serviços
básicos, encontra-se a camada de serviços importantes, ou de armazenamento de arquivos. Por meio dessa camada é possível se manter um sistema de arquivos de nuvem, com todas as operações básicas sobre arquivos virtuais, tais como enviar arquivos, recuperar arquivos, compartilhar arquivos, renomear arquivos, etc. A camada de serviços importantes utiliza os serviços básicos como plataforma para salvar os arquivos, dividindo-os em chunks, assim como em um sistema de arquivos distribuídos (BžOCH, 2012).
Por fim, existe a camada de serviços desejáveis, que utiliza as camadas de serviços básicos e importantes para executar operações adicionais para um sistema de cloud, que podem agregar funcionalidades, oferecendo alguns diferenciais para os usuários. Exemplos de serviços desejáveis são: indexação de conteúdo, deduplicação, recomendação de conteúdo, ferramentas administrativas, entre outros.
A camada de serviços desejáveis está fora do escopo, e não será aborda em detalhes neste trabalho.
Finalmente, para que o cliente e as camadas se comuniquem utilizamos um barramento de serviço (Enterprise Service Bus - Enterprise Service Bus (ESB)), que visa remover o acoplamento entre os serviços e os meio de transporte, tornando a aplicação mais flexível
