SlideShare uma empresa Scribd logo
FACULDADE DE TECNOLOGIA DE SÃO PAULO - FATECSP Pós-graduação em Tecnologia em Análise eProjeto de Sistemas - Turma 20 - 2009 AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE DAVID LOJUDICE SOBRINHO Orientador: prof. Eduardo Endo
FACULDADE DE TECNOLOGIA DE SÃO PAULO - FATECSP Pós-graduação em Tecnologia em Análise eProjeto de Sistemas - Turma 20 - 2009 Monografia apresentada à Fatec SP, como requisito para obtenção do título de especialista em Tecnologia de Análise e Projeto de Sistemas. AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE  DAVID LOJUDICE SOBRINHO Orientador: prof. Eduardo Endo
Contextualização Mais de 1 bilhão de pessoas acessam a Internet no mundo (1) O Brasil é o 9º pais com mais acessos: 27 milhões (1) Acesso a internet cresceu 10% em Julho/2009 em relação ao mês anterior  (2) (1) http://www.techcrunch.com/2009/01/23/comscore-internet-population-passes-one-billion-top-15-countries/  (23/01/2009) (2) http://portalimprensa.uol.com.br/portal/ultimas_noticias/2009/08/21/imprensa30262.shtml (21/08/2009) Introdução 3
Problematização Como atender este número crescente de usuários? Os usuários podem chegar ao web site sem previsão e em grande número, sendo que atender todos eles é fator crucial para o sucesso do site. Como os grandes web sites conseguem atender estes usuários? Como a Arquitetura de Software pode influenciar neste requisito? Introdução 4
Escolha do Tema  Como Escalar... ...utilizando modelos conhecidos ... ...de arquitetura de software...  ...de grandes aplicações Web? Introdução 5
Escolha do Tema  Boas praticas para Aplicações Web Internet são diferentes de aplicações comerciais (setor financeiro, por exemplo) Diferentes requisitos! Introdução 6
Campo de Investigação Está no escopo deste projeto: Escalabilidade Arquitetura de Software Server-side Aplicação Web Introdução 7
Campo de Investigação Não está no escopo deste projeto: Outros requisitos não funcionais: alta-disponibilidade e performance Arquitetura de Infra-estrutura Client-side Outros tipos de aplicação que não seja uma aplicação Web. Introdução 8
Sites estudados Introdução 9
O que é uma Aplicação Web? Uma aplicação web é a junção da idéia de um web site estático e uma aplicação desktop (Henderson, 2006): Permite interação e personalização Permite  acesso e distribuição via web  Aplicação Web 10
Padrão de utilização de uma Aplicação Web Um dos fatores mais importantes para entender onde escalar uma aplicação web é entender como ela é utilizada pelos seus usuários e sistemas clientes.  Normalmente, as aplicações web tem 80% de leitura e 20% de gravação, sendo que esse número varia dependendo principalmente do tipo da aplicação web.  Os acessos também se concentram em poucas páginas, normalmente seguindo a distribuição parecida com a distribuição Zipf (Breslau, 1999, Padmanabhan 2000). Aplicação Web 11
O que é Arquitetura de Software? Segundo Fowler (2000): Arquitetura de software é a quebra de um sistema em partes menores, porém ainda com uma visão abstrata.  Arquitetura de software é onde mora as "decisões difíceis de serem alteradas“ É importante para a escalabilidade de uma app web: porque pode alterar o modo como a aplicação escala (Ebay, 2009)  tornando mais eficaz o uso de recursos  porque pode ser o limitador da capacidade de escalar Arquitetura de Software 12
O que é Escalabilidade? Existem algumas definições para escalabilidade: Um sistema é escalável quando sua performance melhora depois da adição de hardware, sendo essa melhora proporcional ao poder computacional do hardware adicionado (Hill, 1990) Porém, segundo (Henderson, 2006, p.204), escalabilidade não tem relação com performance e sim com a capacidade de acomodar o aumento do uso do sistema e da quantidade de dados adicionando hardware, sem perder a manutenibilidade. Escalabilidade 13
De forma mais ampla... Escalar significa quão bem uma solução particular se encaixa em um problema enquanto o escopo do problema aumenta (Schlossnagle, 2006, p.5) Escalabilidade 14
Para este trabalho... Problema: o aumento de utilização de recursos computacionais causado pelo aumento de acessos e/ou aumento de personalização da aplicação web. Logo, escalar não implica necessariamente adição de mais hardware, pois a melhor utilização dos recursos computacionais existentes através da arquitetura de software pode também ser uma possível solução ao problema proposto. Escalabilidade 15
Escalabilidade Vertical Chamamos de escalabilidade vertical quando um sistema aumenta sua capacidade trocando o servidor que o hospeda por um servidor mais potente (mais memória RAM, harddisk ou CPU). Escalabilidade 16
Escalabilidade Horizontal A escalabilidade horizontal se difere da escalabilidade vertical, pois ao invés de substituir os hardwares atuais utilizado pela aplicação, apenas adiciona-se mais servidores, sem substituição. Escalabilidade 17
Vertical vs Horizontal - Custo Fonte: Henderson, 2006, p.204 Escalabilidade 18
19 Estratégias de Escalabilidade
Estratégias de Escalabilidade Camadas: Como a divisão das camadas, seja lógica ou fisicamente, influencia na escalabilidade e na arquitetura de uma aplicação web. Reutilização Computacional: Quais formas de reutilização computacional foram empregadas pelos web sites estudados e como isso possibilitou receber maior tráfego. Particionamento de Dados: Quais as formas de particionamento de dado empregadas pelos web sites estudados e porque particionar é importante para escalar uma aplicação. Estratégias 20
21 Camadas
Camadas A separação das responsabilidades é peça chave no processo de pensar um sistema. A intenção é sempre quebrar um problema maior em partes menores (Fowler, 2002), com responsabilidades bem definidas. 	... the hardest part of a layered architecture is deciding what layers to have and what the responsibility of each layer should be. Fowler(2002) No caso de uma aplicação web, a distribuição das responsabilidades das camadas e como elas se comunicam influencia também na sua escalabilidade. Estratégias > Camadas 22
Flexibilidade, Manutenibilidade Quanto mais camadas uma aplicação tem, maior será a sua manutenibilidade, porém com menor flexibilidade (Henderson, 2006, p.13). Uma aplicação com muitas camadas tem maior facilidade de manutenção, mas terá pouca flexibilidade em utilizar funcionalidades que as camadas abaixo não expõem. Estratégias > Camadas 23
Flexibilidade, Manutenibilidade e Escalabilidade Dependendo da necessidade de escalabilidade, pode tomar responsabilidades que normalmente não lhe seriam atribuídas. Além disso, a manutenibilidade teve menos prioridade comparado com a capacidade que a aplicação tem de escalar. Encontrar o balanceamento entre manutenibilidade e flexibilidade, e ainda assim manter o sistema escalável, é o motivo pelo qual o estudo das camadas e sua arquitetura é importante para uma aplicação web. Estratégias > Camadas 24
Distribuição entre os servidores Estratégias > Camadas  > Distribuição entre os servidores 25
SharedNothing Remoção de Recursos Compartilhados Escalonamento (quase) linear Difícil de se conseguir na prática Ainda assim, quanto menor a dependência entre os servidores, maior a possibilidade de escalabilidade. Estratégias > Camadas  > Distribuição entre os servidores 26
SharedNothing SharedNothing + Banco de Dados separado Estratégias > Camadas > Distribuição Entre Os Servidores 27
Por Camada  Uma forma bastante usada para escalar uma aplicação foi a distribuição das três camadas em servidores distintos, um para cada camada Estratégias > Camadas > Distribuição Entre Os Servidores 28
Por Camada  Dificuldade em manter estado Complexidade do software aumenta, pois é necessário criar uma camada para abstrair as chamadas remotas (RPC, SOAP, etc.). Foi observado entre os sites estudados que este tipo de distribuição não é a mais usada, porém algumas camadas ainda hoje são mais fáceis de escalar se isoladas, como é o caso de banco de dados. Estratégias > Camadas > Distribuição Entre Os Servidores 29
SOA - Service-orientedarchitecture A idéia de utilizar SOA para escalabilidade de uma aplicação web é separar responsabilidades, e não camadas, da aplicação e escalar individualmente essas partes.  Estratégias > Camadas > Distribuição Entre Os Servidores 30
Pragmatismo Shared Nothing + Por Camada + SOA Estratégias > Camadas > Distribuição Entre Os Servidores 31
Mensagens Assíncronas Estratégias > Camadas > Mensagens Assíncronas  32
Mensagens Assíncronas Normalmente, quando uma funcionalidade de uma das camadas é chamada, espera-se um resultado o mais rápido possível. Estratégias > Camadas > Mensagens Assíncronas  33
Mensagens Assíncronas Porém, em alguns cenários, nem sempre é preciso ter um retorno rápido ou mesmo ter um retorno em si. Um exemplo é o envio de um recado aos amigos em uma rede social.  Estratégias > Camadas > Mensagens Assíncronas  34
Mensagens Assíncronas Camada consumidora da mensagem tem flexibilidade para consumir essas mensagens conforme sua capacidade Como o produtor da mensagem não espera a finalização da requisição, liberam-se recursos para atender novas requisições do lado do produtor Estratégias > Camadas > Mensagens Assíncronas  35
36 Reutilização Computacional
Reutilização Computacional Guardar um valor que foi previamente calculado para futuro reuso Poupar recursos para atender maior número de requisições Principal recurso a ser poupado: Banco de Dados, pois é o mais difícil de escalar Estratégias > Reutilização Computacional 37
Desnormalização  Estratégias > Reutilização Computacional > Desnormalização  38
Desnormalização  A utilização de RDBMS de forma rigorosa, utilizando apenas dados normalizados e depois usar “Join” e “GroupBy” pode ser muito custosa. Gravar os dados de forma normalizada, mas também gravar de forma desnormalizada Custo computacional acontece no momento da inserção Estratégias > Reutilização Computacional > Desnormalização  39
Desnormalização – TagCloud Estratégias > Reutilização Computacional > Desnormalização  40
Desnormalização – TagCloud Estratégias > Reutilização Computacional > Desnormalização  41
Cache Estratégias > Reutilização Computacional > Cache 42
Cache Cache é um mecanismo de reutilização computacional que grava em uma área temporária dados que possuem uma grande probabilidade de serem utilizados novamente Na arquitetura de uma aplicação web, o cache tem papel fundamental, sendo talvez a estratégia com o melhor custo/benefício em termos de ganhos para uma aplicação (Slashdot, 2009).  Estratégias > Reutilização Computacional > Cache 43
O que colocar no cache?  Dados processados por qualquer uma das camada Interface Aplicação Persistência Etc. Mas como o banco de dados é o mais difícil de escalar, normalmente esta camada é a primeira a fazer utilização do cache  Estratégias > Reutilização Computacional > Cache 44
Localização do Cache  Local  (utilizando recurso do servidor) Distribuído (utilizando servidores especializados em cache) Estratégias > Reutilização Computacional > Cache 45
Localização do Cache - Local  ,[object Object]
Desvantagem: Difícil invalidação, limitado ao servidorEstratégias > Reutilização Computacional > Cache 46
Localização do Cache - Distribuído  Vantagem: Fácil Invalidação e Escalabilidade Desvantagem: I/O Rede Estratégias > Reutilização Computacional > Cache 47
Política de troca Como saber o que é mais relevanta para o cache? A melhor política de troca de um cache seria aquela que soubesse qual dado seria utilizado no futuro, assim mante-lo armazenado. Política mais comum para aplicações web LRU (elemento recentemente menos usado) Estratégias > Reutilização Computacional > Cache 48
Invalidação O maior problema na utilização de um cache é saber quando aquele conteúdo que está no cache não é mais válido.  Por exemplo: um site de notícias que aceite que seus usuários comentem nos artigos disponíveis. Para evitar ler os comentários diretamente do banco de dados para cada requisição, coloca-se os comentários em cache. Porém, qual é o melhor momento de invalidar este valor no cache e pegar os comentários mais atuais? Estratégias > Reutilização Computacional > Cache 49
Invalidação Opções A cada nova ação que altera o dado Por tempo Importante notar aqui que, seja qual for o modo de invalidação do cache, um requisito não-funcional, que é a escalabilidade da aplicação web, influencia diretamente na forma como o conteúdo é exibido ao usuário. Estratégias > Reutilização Computacional > Cache 50
Conteúdo Estático  Estratégias > Reutilização Computacional > Conteúdo Estático  51
Conteúdo Estático  Não existe nada mais econômico em termos de processamento para uma aplicação web do que servir um arquivo simples Diferença entre gerar conteúdo estático e um cache  O conteúdo estático não precisa ser descartado, podendo permanecer no disco até que o conteúdo sofra uma alteração Todos os servidores web sabem naturalmente como servir um arquivo estático diretamente, ao passo que o cache deve ser lido por uma aplicação Estratégias > Reutilização Computacional > Conteúdo Estático  52
Conteúdo Estático  Cenários: Página principal (ex: um portal) Site com pouca interação ou personalização (ex: Wikipedia) Site de imagens (ex: Flickr) Estratégias > Reutilização Computacional > Conteúdo Estático  53
Conteúdo Estático - CDN Aliviar a carga dos servidores de conteúdos estáticos Melhorar o tempo de entrega desses conteúdos para usuários distribuídos no globo Difícil Invalidação Estratégias > Reutilização Computacional > Conteúdo Estático  54
55 Particionamento de Dados
Particionamento de Dados Um dos desafios para uma aplicação web é como escalar o processamento e armazenamento dos dados.  A escalabilidade vertical pode ser usada nos servidores de banco de dados ou repositórios, mas quando o volume de dados é muito alto o particionamento (ou escalabilidade horizontal) é inevitável. Estratégias > Particionamento de Dados 56
Consistência e Disponibilidade  Estratégias > Particionamento de Dados > Consistência e Disponibilidade  57
Consistência e Disponibilidade  CAP (consistent, available e partition-tolerant) Consistência Disponibilidade Tolerância a particionamento Um sistema pode ter no máximo duas dessas três características, sendo impossível ter as três ao mesmo tempo Estratégias > Particionamento de Dados > Consistência e Disponibilidade  58
Consistência e Disponibilidade  Mas se o particionamento é obrigatório? ACID vs. BASE ACID: Atomicity, Consistency, Isolation, Durability BASE: Basically available, soft state, eventually consistent Estratégias > Particionamento de Dados > Consistência e Disponibilidade  59
Sharding Estratégias > Particionamento de Dados > Sharding 60
Sharding Quando o número de registros ou o número de operações para ler ou gravar em um banco de dados supera a capacidade de um único servidor é necessário escalar este banco. Para isto é necessário dividir os dados em partes menores e distribuir essas partes pelos servidores (Digg, 2009), também chamados de shards. Estratégias > Particionamento de Dados > Sharding 61
Sharding - Vertical  Estratégias > Particionamento de Dados > Sharding 62
Sharding - Horizontal Estratégias > Particionamento de Dados > Sharding 63
64 Evolução da Arquitetura
Evolução da Arquitetura Monitoramento  Modelos Prematuros  Evolução da Arquitetura 65
66 Conclusão
Conclusão Neste trabalho foram estudados aspectos e soluções de escalabilidade na arquitetura de software de web sites diversos, alguns representativos na internet em volume de trafego e outros web sites menores, mas que apresentaram informações igualmente valiosas sobre sua respectivas arquitetura de software.  Conclusão 67
Conclusão Por soluções de escalabilidade para aplicações web, conclui-se que estas soluções são as que auxiliam uma aplicação web a receber um tráfego de crescimento continuo, podendo-se alcançar isto através do processamento distribuído ou por maximizar o uso de cada um dos servidores, sendo que ambas as soluções foram empregadas nas aplicações web estudadas. Conclusão 68
Conclusão Uma classificação possível foi apresentada para as estratégias de escalabilidade estudadas, onde se examinou: Camadas Reutilização Computacional Particionamento de dados Conclusão 69
Conclusão Camadas a importância da distribuição e comunicação das camadas da arquitetura do web site. Verificou-se que quanto menor a dependência entre os servidores, maior a possibilidade de escalabilidade. Porém, dada a complexidade das camadas, nem sempre é possível eliminar essa dependência. Conclusão 70
Conclusão Reutilização Computacional Escolhendo por usar conteúdos estáticos, vai-se na direção da alta escalabilidade, porém com baixa flexibilidade.  Já, por outro lado, escolher por conteúdo extremamente personalizado, exige uma arquitetura de software com maior uso de reutilização computacional para se conseguir escalabilidade.  Outro ponto importante é que um requisito não-funcional, que é a escalabilidade da aplicação web, pode influenciar diretamente na forma como o usuário interage com a aplicação web Conclusão 71
Conclusão Particionamento de dados O particionamento é sempre uma opção que não pôde ser descartada Escolhendo pela consistência, os sistemas tiveram que rejeitar ou por em espera interações com os dados.  Escolhendo pela disponibilidade, os sistemas tiveram que estar preparados para lidar com o fato de que algumas das suas respostas podem, mais tarde, revelarem-se inconsistentes. Conclusão 72
Conclusão Evolução da Arquitetura  A arquitetura de uma aplicação web deve receber as mudanças, para que se torne escalável, de forma gradual e constante, assim que os problemas de escalabilidade sejam identificados, evitando modelos prematuros Porém, algumas estratégias podem ser aplicadas na arquitetura inicial, dado a facilidade de implementação e o ganho de escalabilidade que a estratégia trará. Conclusão 73

Mais conteúdo relacionado

Semelhante a AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE

Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016
Renato Groff
 
Introdução ao 12 Factors APP
Introdução ao 12 Factors APPIntrodução ao 12 Factors APP
Introdução ao 12 Factors APP
Douglas Alonso
 
Infraestrutura em nuvem com Amazon Web Services (AWS)
Infraestrutura em nuvem com Amazon Web Services (AWS)Infraestrutura em nuvem com Amazon Web Services (AWS)
Infraestrutura em nuvem com Amazon Web Services (AWS)
Infosimples
 
Artigo_Thiago_Lenz_versao2.3-Final
Artigo_Thiago_Lenz_versao2.3-FinalArtigo_Thiago_Lenz_versao2.3-Final
Artigo_Thiago_Lenz_versao2.3-Final
thiago.lenz
 
Saa s software como serviço (slides)
Saa s   software como serviço (slides)Saa s   software como serviço (slides)
Saa s software como serviço (slides)
Daniela Nunes
 
Alta Disponibilidade e Tolerância a Falhas: uma abordagem em Banco de Dados
Alta Disponibilidade e Tolerância a Falhas: uma abordagem em Banco de DadosAlta Disponibilidade e Tolerância a Falhas: uma abordagem em Banco de Dados
Alta Disponibilidade e Tolerância a Falhas: uma abordagem em Banco de Dados
Alex Camargo
 
Oficina cake php
Oficina cake phpOficina cake php
Oficina cake php
Allan George
 
Escalabilidade via Software no ExpressoV3
Escalabilidade via Software no ExpressoV3Escalabilidade via Software no ExpressoV3
Escalabilidade via Software no ExpressoV3
Flávio Lisboa
 
Blue coat 4 steps_high_performance_wan_internet-por-br
Blue coat 4 steps_high_performance_wan_internet-por-brBlue coat 4 steps_high_performance_wan_internet-por-br
Blue coat 4 steps_high_performance_wan_internet-por-br
Ronaldo Cesar Espíndola Ferreira
 
Artigo cloud computing pdf
Artigo cloud computing pdfArtigo cloud computing pdf
Artigo cloud computing pdf
Universidade de São Paulo (EEL USP)
 
COMPUTAÇÃO EM NUVEM: ESTUDO DE CASO EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO
COMPUTAÇÃO EM NUVEM: ESTUDO DE CASO EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃOCOMPUTAÇÃO EM NUVEM: ESTUDO DE CASO EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO
COMPUTAÇÃO EM NUVEM: ESTUDO DE CASO EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO
Allan Reis
 
Riscos de segurança em cloud computing - Parte 4
Riscos de segurança em cloud computing - Parte 4Riscos de segurança em cloud computing - Parte 4
Riscos de segurança em cloud computing - Parte 4
Fristtram Helder Fernandes
 
Asp net mvc
Asp net mvcAsp net mvc
O desafio de sustentar centenas de servicos
O desafio de sustentar centenas de servicosO desafio de sustentar centenas de servicos
O desafio de sustentar centenas de servicos
Graziella Bonizi
 
Armazenamento de Dados Aplicado à Computação em Nuvem
Armazenamento de Dados Aplicado à Computação em NuvemArmazenamento de Dados Aplicado à Computação em Nuvem
Armazenamento de Dados Aplicado à Computação em Nuvem
Daniel Rossi
 
Ria
RiaRia
Desenvolvimento_Distribuído_Google_Estudo_de_caso.pdf
Desenvolvimento_Distribuído_Google_Estudo_de_caso.pdfDesenvolvimento_Distribuído_Google_Estudo_de_caso.pdf
Desenvolvimento_Distribuído_Google_Estudo_de_caso.pdf
ssuserb64840
 
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Renato Groff
 
Precisamos de um barco maior introdução ao dimensionamento de aplicações
Precisamos de um barco maior introdução ao dimensionamento de aplicaçõesPrecisamos de um barco maior introdução ao dimensionamento de aplicações
Precisamos de um barco maior introdução ao dimensionamento de aplicações
Jackson F. de A. Mafra
 
Transformando a ti com cloud computing e virtualização
Transformando a ti com cloud computing e virtualizaçãoTransformando a ti com cloud computing e virtualização
Transformando a ti com cloud computing e virtualização
Darlan Segalin
 

Semelhante a AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE (20)

Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016Microserviços - Universidade Metodista - EETI 2016
Microserviços - Universidade Metodista - EETI 2016
 
Introdução ao 12 Factors APP
Introdução ao 12 Factors APPIntrodução ao 12 Factors APP
Introdução ao 12 Factors APP
 
Infraestrutura em nuvem com Amazon Web Services (AWS)
Infraestrutura em nuvem com Amazon Web Services (AWS)Infraestrutura em nuvem com Amazon Web Services (AWS)
Infraestrutura em nuvem com Amazon Web Services (AWS)
 
Artigo_Thiago_Lenz_versao2.3-Final
Artigo_Thiago_Lenz_versao2.3-FinalArtigo_Thiago_Lenz_versao2.3-Final
Artigo_Thiago_Lenz_versao2.3-Final
 
Saa s software como serviço (slides)
Saa s   software como serviço (slides)Saa s   software como serviço (slides)
Saa s software como serviço (slides)
 
Alta Disponibilidade e Tolerância a Falhas: uma abordagem em Banco de Dados
Alta Disponibilidade e Tolerância a Falhas: uma abordagem em Banco de DadosAlta Disponibilidade e Tolerância a Falhas: uma abordagem em Banco de Dados
Alta Disponibilidade e Tolerância a Falhas: uma abordagem em Banco de Dados
 
Oficina cake php
Oficina cake phpOficina cake php
Oficina cake php
 
Escalabilidade via Software no ExpressoV3
Escalabilidade via Software no ExpressoV3Escalabilidade via Software no ExpressoV3
Escalabilidade via Software no ExpressoV3
 
Blue coat 4 steps_high_performance_wan_internet-por-br
Blue coat 4 steps_high_performance_wan_internet-por-brBlue coat 4 steps_high_performance_wan_internet-por-br
Blue coat 4 steps_high_performance_wan_internet-por-br
 
Artigo cloud computing pdf
Artigo cloud computing pdfArtigo cloud computing pdf
Artigo cloud computing pdf
 
COMPUTAÇÃO EM NUVEM: ESTUDO DE CASO EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO
COMPUTAÇÃO EM NUVEM: ESTUDO DE CASO EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃOCOMPUTAÇÃO EM NUVEM: ESTUDO DE CASO EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO
COMPUTAÇÃO EM NUVEM: ESTUDO DE CASO EM UMA EMPRESA DE TECNOLOGIA DA INFORMAÇÃO
 
Riscos de segurança em cloud computing - Parte 4
Riscos de segurança em cloud computing - Parte 4Riscos de segurança em cloud computing - Parte 4
Riscos de segurança em cloud computing - Parte 4
 
Asp net mvc
Asp net mvcAsp net mvc
Asp net mvc
 
O desafio de sustentar centenas de servicos
O desafio de sustentar centenas de servicosO desafio de sustentar centenas de servicos
O desafio de sustentar centenas de servicos
 
Armazenamento de Dados Aplicado à Computação em Nuvem
Armazenamento de Dados Aplicado à Computação em NuvemArmazenamento de Dados Aplicado à Computação em Nuvem
Armazenamento de Dados Aplicado à Computação em Nuvem
 
Ria
RiaRia
Ria
 
Desenvolvimento_Distribuído_Google_Estudo_de_caso.pdf
Desenvolvimento_Distribuído_Google_Estudo_de_caso.pdfDesenvolvimento_Distribuído_Google_Estudo_de_caso.pdf
Desenvolvimento_Distribuído_Google_Estudo_de_caso.pdf
 
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
Arquitetura de Microserviços - Stone Tech Saturday - Março/2017
 
Precisamos de um barco maior introdução ao dimensionamento de aplicações
Precisamos de um barco maior introdução ao dimensionamento de aplicaçõesPrecisamos de um barco maior introdução ao dimensionamento de aplicações
Precisamos de um barco maior introdução ao dimensionamento de aplicações
 
Transformando a ti com cloud computing e virtualização
Transformando a ti com cloud computing e virtualizaçãoTransformando a ti com cloud computing e virtualização
Transformando a ti com cloud computing e virtualização
 

Último

Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
Danilo Pinotti
 
Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!
Jonathas Muniz
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
TomasSousa7
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
Faga1939
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
Momento da Informática
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
Momento da Informática
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Gabriel de Mattos Faustino
 

Último (7)

Segurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas PráticasSegurança Digital Pessoal e Boas Práticas
Segurança Digital Pessoal e Boas Práticas
 
Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!Guardioes Digitais em ação: Como criar senhas seguras!
Guardioes Digitais em ação: Como criar senhas seguras!
 
História da Rádio- 1936-1970 século XIX .2.pptx
História da Rádio- 1936-1970 século XIX   .2.pptxHistória da Rádio- 1936-1970 século XIX   .2.pptx
História da Rádio- 1936-1970 século XIX .2.pptx
 
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
PRODUÇÃO E CONSUMO DE ENERGIA DA PRÉ-HISTÓRIA À ERA CONTEMPORÂNEA E SUA EVOLU...
 
Logica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptxLogica de Progamacao - Aula (1) (1).pptx
Logica de Progamacao - Aula (1) (1).pptx
 
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdfTOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
TOO - TÉCNICAS DE ORIENTAÇÃO A OBJETOS aula 1.pdf
 
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdfEscola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
Escola Virtual - Fundação Bradesco - ITIL - Gabriel Faustino.pdf
 

AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE

  • 1. FACULDADE DE TECNOLOGIA DE SÃO PAULO - FATECSP Pós-graduação em Tecnologia em Análise eProjeto de Sistemas - Turma 20 - 2009 AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE DAVID LOJUDICE SOBRINHO Orientador: prof. Eduardo Endo
  • 2. FACULDADE DE TECNOLOGIA DE SÃO PAULO - FATECSP Pós-graduação em Tecnologia em Análise eProjeto de Sistemas - Turma 20 - 2009 Monografia apresentada à Fatec SP, como requisito para obtenção do título de especialista em Tecnologia de Análise e Projeto de Sistemas. AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE DAVID LOJUDICE SOBRINHO Orientador: prof. Eduardo Endo
  • 3. Contextualização Mais de 1 bilhão de pessoas acessam a Internet no mundo (1) O Brasil é o 9º pais com mais acessos: 27 milhões (1) Acesso a internet cresceu 10% em Julho/2009 em relação ao mês anterior (2) (1) http://www.techcrunch.com/2009/01/23/comscore-internet-population-passes-one-billion-top-15-countries/ (23/01/2009) (2) http://portalimprensa.uol.com.br/portal/ultimas_noticias/2009/08/21/imprensa30262.shtml (21/08/2009) Introdução 3
  • 4. Problematização Como atender este número crescente de usuários? Os usuários podem chegar ao web site sem previsão e em grande número, sendo que atender todos eles é fator crucial para o sucesso do site. Como os grandes web sites conseguem atender estes usuários? Como a Arquitetura de Software pode influenciar neste requisito? Introdução 4
  • 5. Escolha do Tema Como Escalar... ...utilizando modelos conhecidos ... ...de arquitetura de software... ...de grandes aplicações Web? Introdução 5
  • 6. Escolha do Tema Boas praticas para Aplicações Web Internet são diferentes de aplicações comerciais (setor financeiro, por exemplo) Diferentes requisitos! Introdução 6
  • 7. Campo de Investigação Está no escopo deste projeto: Escalabilidade Arquitetura de Software Server-side Aplicação Web Introdução 7
  • 8. Campo de Investigação Não está no escopo deste projeto: Outros requisitos não funcionais: alta-disponibilidade e performance Arquitetura de Infra-estrutura Client-side Outros tipos de aplicação que não seja uma aplicação Web. Introdução 8
  • 10. O que é uma Aplicação Web? Uma aplicação web é a junção da idéia de um web site estático e uma aplicação desktop (Henderson, 2006): Permite interação e personalização Permite acesso e distribuição via web Aplicação Web 10
  • 11. Padrão de utilização de uma Aplicação Web Um dos fatores mais importantes para entender onde escalar uma aplicação web é entender como ela é utilizada pelos seus usuários e sistemas clientes. Normalmente, as aplicações web tem 80% de leitura e 20% de gravação, sendo que esse número varia dependendo principalmente do tipo da aplicação web. Os acessos também se concentram em poucas páginas, normalmente seguindo a distribuição parecida com a distribuição Zipf (Breslau, 1999, Padmanabhan 2000). Aplicação Web 11
  • 12. O que é Arquitetura de Software? Segundo Fowler (2000): Arquitetura de software é a quebra de um sistema em partes menores, porém ainda com uma visão abstrata. Arquitetura de software é onde mora as "decisões difíceis de serem alteradas“ É importante para a escalabilidade de uma app web: porque pode alterar o modo como a aplicação escala (Ebay, 2009) tornando mais eficaz o uso de recursos porque pode ser o limitador da capacidade de escalar Arquitetura de Software 12
  • 13. O que é Escalabilidade? Existem algumas definições para escalabilidade: Um sistema é escalável quando sua performance melhora depois da adição de hardware, sendo essa melhora proporcional ao poder computacional do hardware adicionado (Hill, 1990) Porém, segundo (Henderson, 2006, p.204), escalabilidade não tem relação com performance e sim com a capacidade de acomodar o aumento do uso do sistema e da quantidade de dados adicionando hardware, sem perder a manutenibilidade. Escalabilidade 13
  • 14. De forma mais ampla... Escalar significa quão bem uma solução particular se encaixa em um problema enquanto o escopo do problema aumenta (Schlossnagle, 2006, p.5) Escalabilidade 14
  • 15. Para este trabalho... Problema: o aumento de utilização de recursos computacionais causado pelo aumento de acessos e/ou aumento de personalização da aplicação web. Logo, escalar não implica necessariamente adição de mais hardware, pois a melhor utilização dos recursos computacionais existentes através da arquitetura de software pode também ser uma possível solução ao problema proposto. Escalabilidade 15
  • 16. Escalabilidade Vertical Chamamos de escalabilidade vertical quando um sistema aumenta sua capacidade trocando o servidor que o hospeda por um servidor mais potente (mais memória RAM, harddisk ou CPU). Escalabilidade 16
  • 17. Escalabilidade Horizontal A escalabilidade horizontal se difere da escalabilidade vertical, pois ao invés de substituir os hardwares atuais utilizado pela aplicação, apenas adiciona-se mais servidores, sem substituição. Escalabilidade 17
  • 18. Vertical vs Horizontal - Custo Fonte: Henderson, 2006, p.204 Escalabilidade 18
  • 19. 19 Estratégias de Escalabilidade
  • 20. Estratégias de Escalabilidade Camadas: Como a divisão das camadas, seja lógica ou fisicamente, influencia na escalabilidade e na arquitetura de uma aplicação web. Reutilização Computacional: Quais formas de reutilização computacional foram empregadas pelos web sites estudados e como isso possibilitou receber maior tráfego. Particionamento de Dados: Quais as formas de particionamento de dado empregadas pelos web sites estudados e porque particionar é importante para escalar uma aplicação. Estratégias 20
  • 22. Camadas A separação das responsabilidades é peça chave no processo de pensar um sistema. A intenção é sempre quebrar um problema maior em partes menores (Fowler, 2002), com responsabilidades bem definidas. ... the hardest part of a layered architecture is deciding what layers to have and what the responsibility of each layer should be. Fowler(2002) No caso de uma aplicação web, a distribuição das responsabilidades das camadas e como elas se comunicam influencia também na sua escalabilidade. Estratégias > Camadas 22
  • 23. Flexibilidade, Manutenibilidade Quanto mais camadas uma aplicação tem, maior será a sua manutenibilidade, porém com menor flexibilidade (Henderson, 2006, p.13). Uma aplicação com muitas camadas tem maior facilidade de manutenção, mas terá pouca flexibilidade em utilizar funcionalidades que as camadas abaixo não expõem. Estratégias > Camadas 23
  • 24. Flexibilidade, Manutenibilidade e Escalabilidade Dependendo da necessidade de escalabilidade, pode tomar responsabilidades que normalmente não lhe seriam atribuídas. Além disso, a manutenibilidade teve menos prioridade comparado com a capacidade que a aplicação tem de escalar. Encontrar o balanceamento entre manutenibilidade e flexibilidade, e ainda assim manter o sistema escalável, é o motivo pelo qual o estudo das camadas e sua arquitetura é importante para uma aplicação web. Estratégias > Camadas 24
  • 25. Distribuição entre os servidores Estratégias > Camadas > Distribuição entre os servidores 25
  • 26. SharedNothing Remoção de Recursos Compartilhados Escalonamento (quase) linear Difícil de se conseguir na prática Ainda assim, quanto menor a dependência entre os servidores, maior a possibilidade de escalabilidade. Estratégias > Camadas > Distribuição entre os servidores 26
  • 27. SharedNothing SharedNothing + Banco de Dados separado Estratégias > Camadas > Distribuição Entre Os Servidores 27
  • 28. Por Camada Uma forma bastante usada para escalar uma aplicação foi a distribuição das três camadas em servidores distintos, um para cada camada Estratégias > Camadas > Distribuição Entre Os Servidores 28
  • 29. Por Camada Dificuldade em manter estado Complexidade do software aumenta, pois é necessário criar uma camada para abstrair as chamadas remotas (RPC, SOAP, etc.). Foi observado entre os sites estudados que este tipo de distribuição não é a mais usada, porém algumas camadas ainda hoje são mais fáceis de escalar se isoladas, como é o caso de banco de dados. Estratégias > Camadas > Distribuição Entre Os Servidores 29
  • 30. SOA - Service-orientedarchitecture A idéia de utilizar SOA para escalabilidade de uma aplicação web é separar responsabilidades, e não camadas, da aplicação e escalar individualmente essas partes. Estratégias > Camadas > Distribuição Entre Os Servidores 30
  • 31. Pragmatismo Shared Nothing + Por Camada + SOA Estratégias > Camadas > Distribuição Entre Os Servidores 31
  • 32. Mensagens Assíncronas Estratégias > Camadas > Mensagens Assíncronas 32
  • 33. Mensagens Assíncronas Normalmente, quando uma funcionalidade de uma das camadas é chamada, espera-se um resultado o mais rápido possível. Estratégias > Camadas > Mensagens Assíncronas 33
  • 34. Mensagens Assíncronas Porém, em alguns cenários, nem sempre é preciso ter um retorno rápido ou mesmo ter um retorno em si. Um exemplo é o envio de um recado aos amigos em uma rede social. Estratégias > Camadas > Mensagens Assíncronas 34
  • 35. Mensagens Assíncronas Camada consumidora da mensagem tem flexibilidade para consumir essas mensagens conforme sua capacidade Como o produtor da mensagem não espera a finalização da requisição, liberam-se recursos para atender novas requisições do lado do produtor Estratégias > Camadas > Mensagens Assíncronas 35
  • 37. Reutilização Computacional Guardar um valor que foi previamente calculado para futuro reuso Poupar recursos para atender maior número de requisições Principal recurso a ser poupado: Banco de Dados, pois é o mais difícil de escalar Estratégias > Reutilização Computacional 37
  • 38. Desnormalização Estratégias > Reutilização Computacional > Desnormalização 38
  • 39. Desnormalização A utilização de RDBMS de forma rigorosa, utilizando apenas dados normalizados e depois usar “Join” e “GroupBy” pode ser muito custosa. Gravar os dados de forma normalizada, mas também gravar de forma desnormalizada Custo computacional acontece no momento da inserção Estratégias > Reutilização Computacional > Desnormalização 39
  • 40. Desnormalização – TagCloud Estratégias > Reutilização Computacional > Desnormalização 40
  • 41. Desnormalização – TagCloud Estratégias > Reutilização Computacional > Desnormalização 41
  • 42. Cache Estratégias > Reutilização Computacional > Cache 42
  • 43. Cache Cache é um mecanismo de reutilização computacional que grava em uma área temporária dados que possuem uma grande probabilidade de serem utilizados novamente Na arquitetura de uma aplicação web, o cache tem papel fundamental, sendo talvez a estratégia com o melhor custo/benefício em termos de ganhos para uma aplicação (Slashdot, 2009). Estratégias > Reutilização Computacional > Cache 43
  • 44. O que colocar no cache? Dados processados por qualquer uma das camada Interface Aplicação Persistência Etc. Mas como o banco de dados é o mais difícil de escalar, normalmente esta camada é a primeira a fazer utilização do cache Estratégias > Reutilização Computacional > Cache 44
  • 45. Localização do Cache Local (utilizando recurso do servidor) Distribuído (utilizando servidores especializados em cache) Estratégias > Reutilização Computacional > Cache 45
  • 46.
  • 47. Desvantagem: Difícil invalidação, limitado ao servidorEstratégias > Reutilização Computacional > Cache 46
  • 48. Localização do Cache - Distribuído Vantagem: Fácil Invalidação e Escalabilidade Desvantagem: I/O Rede Estratégias > Reutilização Computacional > Cache 47
  • 49. Política de troca Como saber o que é mais relevanta para o cache? A melhor política de troca de um cache seria aquela que soubesse qual dado seria utilizado no futuro, assim mante-lo armazenado. Política mais comum para aplicações web LRU (elemento recentemente menos usado) Estratégias > Reutilização Computacional > Cache 48
  • 50. Invalidação O maior problema na utilização de um cache é saber quando aquele conteúdo que está no cache não é mais válido. Por exemplo: um site de notícias que aceite que seus usuários comentem nos artigos disponíveis. Para evitar ler os comentários diretamente do banco de dados para cada requisição, coloca-se os comentários em cache. Porém, qual é o melhor momento de invalidar este valor no cache e pegar os comentários mais atuais? Estratégias > Reutilização Computacional > Cache 49
  • 51. Invalidação Opções A cada nova ação que altera o dado Por tempo Importante notar aqui que, seja qual for o modo de invalidação do cache, um requisito não-funcional, que é a escalabilidade da aplicação web, influencia diretamente na forma como o conteúdo é exibido ao usuário. Estratégias > Reutilização Computacional > Cache 50
  • 52. Conteúdo Estático Estratégias > Reutilização Computacional > Conteúdo Estático 51
  • 53. Conteúdo Estático Não existe nada mais econômico em termos de processamento para uma aplicação web do que servir um arquivo simples Diferença entre gerar conteúdo estático e um cache O conteúdo estático não precisa ser descartado, podendo permanecer no disco até que o conteúdo sofra uma alteração Todos os servidores web sabem naturalmente como servir um arquivo estático diretamente, ao passo que o cache deve ser lido por uma aplicação Estratégias > Reutilização Computacional > Conteúdo Estático 52
  • 54. Conteúdo Estático Cenários: Página principal (ex: um portal) Site com pouca interação ou personalização (ex: Wikipedia) Site de imagens (ex: Flickr) Estratégias > Reutilização Computacional > Conteúdo Estático 53
  • 55. Conteúdo Estático - CDN Aliviar a carga dos servidores de conteúdos estáticos Melhorar o tempo de entrega desses conteúdos para usuários distribuídos no globo Difícil Invalidação Estratégias > Reutilização Computacional > Conteúdo Estático 54
  • 57. Particionamento de Dados Um dos desafios para uma aplicação web é como escalar o processamento e armazenamento dos dados. A escalabilidade vertical pode ser usada nos servidores de banco de dados ou repositórios, mas quando o volume de dados é muito alto o particionamento (ou escalabilidade horizontal) é inevitável. Estratégias > Particionamento de Dados 56
  • 58. Consistência e Disponibilidade Estratégias > Particionamento de Dados > Consistência e Disponibilidade 57
  • 59. Consistência e Disponibilidade CAP (consistent, available e partition-tolerant) Consistência Disponibilidade Tolerância a particionamento Um sistema pode ter no máximo duas dessas três características, sendo impossível ter as três ao mesmo tempo Estratégias > Particionamento de Dados > Consistência e Disponibilidade 58
  • 60. Consistência e Disponibilidade Mas se o particionamento é obrigatório? ACID vs. BASE ACID: Atomicity, Consistency, Isolation, Durability BASE: Basically available, soft state, eventually consistent Estratégias > Particionamento de Dados > Consistência e Disponibilidade 59
  • 61. Sharding Estratégias > Particionamento de Dados > Sharding 60
  • 62. Sharding Quando o número de registros ou o número de operações para ler ou gravar em um banco de dados supera a capacidade de um único servidor é necessário escalar este banco. Para isto é necessário dividir os dados em partes menores e distribuir essas partes pelos servidores (Digg, 2009), também chamados de shards. Estratégias > Particionamento de Dados > Sharding 61
  • 63. Sharding - Vertical Estratégias > Particionamento de Dados > Sharding 62
  • 64. Sharding - Horizontal Estratégias > Particionamento de Dados > Sharding 63
  • 65. 64 Evolução da Arquitetura
  • 66. Evolução da Arquitetura Monitoramento Modelos Prematuros Evolução da Arquitetura 65
  • 68. Conclusão Neste trabalho foram estudados aspectos e soluções de escalabilidade na arquitetura de software de web sites diversos, alguns representativos na internet em volume de trafego e outros web sites menores, mas que apresentaram informações igualmente valiosas sobre sua respectivas arquitetura de software. Conclusão 67
  • 69. Conclusão Por soluções de escalabilidade para aplicações web, conclui-se que estas soluções são as que auxiliam uma aplicação web a receber um tráfego de crescimento continuo, podendo-se alcançar isto através do processamento distribuído ou por maximizar o uso de cada um dos servidores, sendo que ambas as soluções foram empregadas nas aplicações web estudadas. Conclusão 68
  • 70. Conclusão Uma classificação possível foi apresentada para as estratégias de escalabilidade estudadas, onde se examinou: Camadas Reutilização Computacional Particionamento de dados Conclusão 69
  • 71. Conclusão Camadas a importância da distribuição e comunicação das camadas da arquitetura do web site. Verificou-se que quanto menor a dependência entre os servidores, maior a possibilidade de escalabilidade. Porém, dada a complexidade das camadas, nem sempre é possível eliminar essa dependência. Conclusão 70
  • 72. Conclusão Reutilização Computacional Escolhendo por usar conteúdos estáticos, vai-se na direção da alta escalabilidade, porém com baixa flexibilidade. Já, por outro lado, escolher por conteúdo extremamente personalizado, exige uma arquitetura de software com maior uso de reutilização computacional para se conseguir escalabilidade. Outro ponto importante é que um requisito não-funcional, que é a escalabilidade da aplicação web, pode influenciar diretamente na forma como o usuário interage com a aplicação web Conclusão 71
  • 73. Conclusão Particionamento de dados O particionamento é sempre uma opção que não pôde ser descartada Escolhendo pela consistência, os sistemas tiveram que rejeitar ou por em espera interações com os dados. Escolhendo pela disponibilidade, os sistemas tiveram que estar preparados para lidar com o fato de que algumas das suas respostas podem, mais tarde, revelarem-se inconsistentes. Conclusão 72
  • 74. Conclusão Evolução da Arquitetura A arquitetura de uma aplicação web deve receber as mudanças, para que se torne escalável, de forma gradual e constante, assim que os problemas de escalabilidade sejam identificados, evitando modelos prematuros Porém, algumas estratégias podem ser aplicadas na arquitetura inicial, dado a facilidade de implementação e o ganho de escalabilidade que a estratégia trará. Conclusão 73