Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
FACULDADE DE TECNOLOGIA DE SÃO PAULO - FATECSP<br />Pós-graduação em Tecnologia em Análise eProjeto de Sistemas - Turma 20...
FACULDADE DE TECNOLOGIA DE SÃO PAULO - FATECSP<br />Pós-graduação em Tecnologia em Análise eProjeto de Sistemas - Turma 20...
Contextualização<br />Mais de 1 bilhão de pessoas acessam a Internet no mundo (1)<br />O Brasil é o 9º pais com mais acess...
Problematização<br />Como atender este número crescente de usuários?<br />Os usuários podem chegar ao web site sem previsã...
Escolha do Tema <br />Como Escalar...<br />...utilizando modelos conhecidos ...<br />...de arquitetura de software... <br ...
Escolha do Tema <br />Boas praticas para Aplicações Web Internet são diferentes de aplicações comerciais (setor financeiro...
Campo de Investigação<br />Está no escopo deste projeto:<br />Escalabilidade<br />Arquitetura de Software<br />Server-side...
Campo de Investigação<br />Não está no escopo deste projeto:<br />Outros requisitos não funcionais: alta-disponibilidade e...
Sites estudados<br />Introdução<br />9<br />
O que é uma Aplicação Web?<br />Uma aplicação web é a junção da idéia de um web site estático e uma aplicação desktop (Hen...
Padrão de utilização de uma Aplicação Web<br />Um dos fatores mais importantes para entender onde escalar uma aplicação we...
O que é Arquitetura de Software?<br />Segundo Fowler (2000):<br />Arquitetura de software é a quebra de um sistema em part...
O que é Escalabilidade?<br />Existem algumas definições para escalabilidade:<br />Um sistema é escalável quando sua perfor...
De forma mais ampla...<br />Escalar significa quão bem uma solução particular se encaixa em um problema enquanto o escopo ...
Para este trabalho...<br />Problema: o aumento de utilização de recursos computacionais causado pelo aumento de acessos e/...
Escalabilidade Vertical<br />Chamamos de escalabilidade vertical quando um sistema aumenta sua capacidade trocando o servi...
Escalabilidade Horizontal<br />A escalabilidade horizontal se difere da escalabilidade vertical, pois ao invés de substitu...
Vertical vs Horizontal - Custo<br />Fonte: Henderson, 2006, p.204<br />Escalabilidade<br />18<br />
19<br />Estratégias de Escalabilidade<br />
Estratégias de Escalabilidade<br />Camadas: Como a divisão das camadas, seja lógica ou fisicamente, influencia na escalabi...
21<br />Camadas<br />
Camadas<br />A separação das responsabilidades é peça chave no processo de pensar um sistema. A intenção é sempre quebrar ...
Flexibilidade, Manutenibilidade<br />Quanto mais camadas uma aplicação tem, maior será a sua manutenibilidade, porém com m...
Flexibilidade, Manutenibilidade e Escalabilidade<br />Dependendo da necessidade de escalabilidade, pode tomar responsabili...
Distribuição entre os servidores<br />Estratégias &gt; Camadas  &gt; Distribuição entre os servidores<br />25<br />
SharedNothing<br />Remoção de Recursos Compartilhados<br />Escalonamento (quase) linear<br />Difícil de se conseguir na pr...
SharedNothing<br />SharedNothing + Banco de Dados separado<br />Estratégias &gt; Camadas &gt; Distribuição Entre Os Servid...
Por Camada <br />Uma forma bastante usada para escalar uma aplicação foi a distribuição das três camadas em servidores dis...
Por Camada <br />Dificuldade em manter estado<br />Complexidade do software aumenta, pois é necessário criar uma camada pa...
SOA - Service-orientedarchitecture<br />A idéia de utilizar SOA para escalabilidade de uma aplicação web é separar respons...
Pragmatismo<br />Shared Nothing + Por Camada + SOA<br />Estratégias &gt; Camadas &gt; Distribuição Entre Os Servidores<br ...
Mensagens Assíncronas<br />Estratégias &gt; Camadas &gt; Mensagens Assíncronas <br />32<br />
Mensagens Assíncronas<br />Normalmente, quando uma funcionalidade de uma das camadas é chamada, espera-se um resultado o m...
Mensagens Assíncronas<br />Porém, em alguns cenários, nem sempre é preciso ter um retorno rápido ou mesmo ter um retorno e...
Mensagens Assíncronas<br />Camada consumidora da mensagem tem flexibilidade para consumir essas mensagens conforme sua cap...
36<br />Reutilização<br />Computacional<br />
Reutilização Computacional<br />Guardar um valor que foi previamente calculado para futuro reuso<br />Poupar recursos para...
Desnormalização <br />Estratégias &gt; Reutilização Computacional &gt; Desnormalização <br />38<br />
Desnormalização <br />A utilização de RDBMS de forma rigorosa, utilizando apenas dados normalizados e depois usar “Join” e...
Desnormalização – TagCloud<br />Estratégias &gt; Reutilização Computacional &gt; Desnormalização <br />40<br />
Desnormalização – TagCloud<br />Estratégias &gt; Reutilização Computacional &gt; Desnormalização <br />41<br />
Cache<br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />42<br />
Cache<br />Cache é um mecanismo de reutilização computacional que grava em uma área temporária dados que possuem uma grand...
O que colocar no cache? <br />Dados processados por qualquer uma das camada<br />Interface<br />Aplicação<br />Persistênci...
Localização do Cache <br />Local  (utilizando recurso do servidor)<br />Distribuído (utilizando servidores especializados ...
Localização do Cache - Local <br /><ul><li>Vantagem: Não tem I/O de rede
Desvantagem: Difícil invalidação, limitado ao servidor</li></ul>Estratégias &gt; Reutilização Computacional &gt; Cache<br ...
Localização do Cache - Distribuído <br />Vantagem: Fácil Invalidação e Escalabilidade<br />Desvantagem: I/O Rede<br />Estr...
Política de troca<br />Como saber o que é mais relevanta para o cache?<br />A melhor política de troca de um cache seria a...
Invalidação<br />O maior problema na utilização de um cache é saber quando aquele conteúdo que está no cache não é mais vá...
Invalidação<br />Opções<br />A cada nova ação que altera o dado<br />Por tempo<br />Importante notar aqui que, seja qual f...
Conteúdo Estático <br />Estratégias &gt; Reutilização Computacional &gt; Conteúdo Estático <br />51<br />
Conteúdo Estático <br />Não existe nada mais econômico em termos de processamento para uma aplicação web do que servir um ...
Conteúdo Estático <br />Cenários:<br />Página principal (ex: um portal)<br />Site com pouca interação ou personalização (e...
Conteúdo Estático - CDN<br />Aliviar a carga dos servidores de conteúdos estáticos<br />Melhorar o tempo de entrega desses...
55<br />Particionamento de Dados<br />
Particionamento de Dados<br />Um dos desafios para uma aplicação web é como escalar o processamento e armazenamento dos da...
Consistência e Disponibilidade <br />Estratégias &gt; Particionamento de Dados &gt; Consistência e Disponibilidade <br />5...
Consistência e Disponibilidade <br />CAP (consistent, available e partition-tolerant)<br />Consistência<br />Disponibilida...
Consistência e Disponibilidade <br />Mas se o particionamento é obrigatório?<br />ACID vs. BASE<br />ACID: Atomicity, Cons...
Sharding<br />Estratégias &gt; Particionamento de Dados &gt; Sharding<br />60<br />
Sharding<br />Quando o número de registros ou o número de operações para ler ou gravar em um banco de dados supera a capac...
Sharding - Vertical <br />Estratégias &gt; Particionamento de Dados &gt; Sharding<br />62<br />
Sharding - Horizontal<br />Estratégias &gt; Particionamento de Dados &gt; Sharding<br />63<br />
64<br />Evolução da Arquitetura<br />
Evolução da Arquitetura<br />Monitoramento <br />Modelos Prematuros <br />Evolução da Arquitetura<br />65<br />
66<br />Conclusão<br />
Conclusão<br />Neste trabalho foram estudados aspectos e soluções de escalabilidade na arquitetura de software de web site...
Conclusão<br />Por soluções de escalabilidade para aplicações web, conclui-se que estas soluções são as que auxiliam uma a...
Conclusão<br />Uma classificação possível foi apresentada para as estratégias de escalabilidade estudadas, onde se examino...
Conclusão<br />Camadas<br />a importância da distribuição e comunicação das camadas da arquitetura do web site. Verificou-...
Conclusão<br />Reutilização Computacional<br />Escolhendo por usar conteúdos estáticos, vai-se na direção da alta escalabi...
Conclusão<br />Particionamento de dados<br />O particionamento é sempre uma opção que não pôde ser descartada<br />Escolhe...
Conclusão<br />Evolução da Arquitetura <br />A arquitetura de uma aplicação web deve receber as mudanças, para que se torn...
Upcoming SlideShare
Loading in …5
×

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

4,976 views

Published on

http://dalssoft.com

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

Published in: Technology, Business
  • Be the first to comment

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

  1. 1. FACULDADE DE TECNOLOGIA DE SÃO PAULO - FATECSP<br />Pós-graduação em Tecnologia em Análise eProjeto de Sistemas - Turma 20 - 2009<br />AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE<br />DAVID LOJUDICE SOBRINHO<br />Orientador: prof. Eduardo Endo<br />
  2. 2. FACULDADE DE TECNOLOGIA DE SÃO PAULO - FATECSP<br />Pós-graduação em Tecnologia em Análise eProjeto de Sistemas - Turma 20 - 2009<br />Monografia apresentada à Fatec SP, como requisito para obtenção do título de especialista em Tecnologia de Análise e Projeto de Sistemas.<br />AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE <br />DAVID LOJUDICE SOBRINHO<br />Orientador: prof. Eduardo Endo<br />
  3. 3. Contextualização<br />Mais de 1 bilhão de pessoas acessam a Internet no mundo (1)<br />O Brasil é o 9º pais com mais acessos: 27 milhões (1)<br />Acesso a internet cresceu 10% em Julho/2009 em relação ao mês anterior (2)<br />(1) http://www.techcrunch.com/2009/01/23/comscore-internet-population-passes-one-billion-top-15-countries/ (23/01/2009)<br />(2) http://portalimprensa.uol.com.br/portal/ultimas_noticias/2009/08/21/imprensa30262.shtml (21/08/2009)<br />Introdução<br />3<br />
  4. 4. Problematização<br />Como atender este número crescente de usuários?<br />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.<br />Como os grandes web sites conseguem atender estes usuários?<br />Como a Arquitetura de Software pode influenciar neste requisito?<br />Introdução<br />4<br />
  5. 5. Escolha do Tema <br />Como Escalar...<br />...utilizando modelos conhecidos ...<br />...de arquitetura de software... <br />...de grandes aplicações Web?<br />Introdução<br />5<br />
  6. 6. Escolha do Tema <br />Boas praticas para Aplicações Web Internet são diferentes de aplicações comerciais (setor financeiro, por exemplo)<br />Diferentes requisitos!<br />Introdução<br />6<br />
  7. 7. Campo de Investigação<br />Está no escopo deste projeto:<br />Escalabilidade<br />Arquitetura de Software<br />Server-side<br />Aplicação Web<br />Introdução<br />7<br />
  8. 8. Campo de Investigação<br />Não está no escopo deste projeto:<br />Outros requisitos não funcionais: alta-disponibilidade e performance<br />Arquitetura de Infra-estrutura<br />Client-side<br />Outros tipos de aplicação que não seja uma aplicação Web.<br />Introdução<br />8<br />
  9. 9. Sites estudados<br />Introdução<br />9<br />
  10. 10. O que é uma Aplicação Web?<br />Uma aplicação web é a junção da idéia de um web site estático e uma aplicação desktop (Henderson, 2006):<br />Permite interação e personalização<br />Permite acesso e distribuição via web <br />Aplicação Web<br />10<br />
  11. 11. Padrão de utilização de uma Aplicação Web<br />Um dos fatores mais importantes para entender onde escalar uma aplicação web é entender como ela é utilizada pelos seus usuários e sistemas clientes. <br />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. <br />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).<br />Aplicação Web<br />11<br />
  12. 12. O que é Arquitetura de Software?<br />Segundo Fowler (2000):<br />Arquitetura de software é a quebra de um sistema em partes menores, porém ainda com uma visão abstrata. <br />Arquitetura de software é onde mora as &quot;decisões difíceis de serem alteradas“<br />É importante para a escalabilidade de uma app web:<br />porque pode alterar o modo como a aplicação escala (Ebay, 2009) tornando mais eficaz o uso de recursos <br />porque pode ser o limitador da capacidade de escalar<br />Arquitetura de Software<br />12<br />
  13. 13. O que é Escalabilidade?<br />Existem algumas definições para escalabilidade:<br />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)<br />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.<br />Escalabilidade<br />13<br />
  14. 14. De forma mais ampla...<br />Escalar significa quão bem uma solução particular se encaixa em um problema enquanto o escopo do problema aumenta (Schlossnagle, 2006, p.5)<br />Escalabilidade<br />14<br />
  15. 15. Para este trabalho...<br />Problema: o aumento de utilização de recursos computacionais causado pelo aumento de acessos e/ou aumento de personalização da aplicação web.<br />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.<br />Escalabilidade<br />15<br />
  16. 16. Escalabilidade Vertical<br />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).<br />Escalabilidade<br />16<br />
  17. 17. Escalabilidade Horizontal<br />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.<br />Escalabilidade<br />17<br />
  18. 18. Vertical vs Horizontal - Custo<br />Fonte: Henderson, 2006, p.204<br />Escalabilidade<br />18<br />
  19. 19. 19<br />Estratégias de Escalabilidade<br />
  20. 20. Estratégias de Escalabilidade<br />Camadas: Como a divisão das camadas, seja lógica ou fisicamente, influencia na escalabilidade e na arquitetura de uma aplicação web.<br />Reutilização Computacional: Quais formas de reutilização computacional foram empregadas pelos web sites estudados e como isso possibilitou receber maior tráfego.<br />Particionamento de Dados: Quais as formas de particionamento de dado empregadas pelos web sites estudados e porque particionar é importante para escalar uma aplicação.<br />Estratégias<br />20<br />
  21. 21. 21<br />Camadas<br />
  22. 22. Camadas<br />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.<br /> ... the hardest part of a layered architecture is deciding what layers to have and what the responsibility of each layer should be. Fowler(2002)<br />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.<br />Estratégias &gt; Camadas<br />22<br />
  23. 23. Flexibilidade, Manutenibilidade<br />Quanto mais camadas uma aplicação tem, maior será a sua manutenibilidade, porém com menor flexibilidade (Henderson, 2006, p.13).<br />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.<br />Estratégias &gt; Camadas<br />23<br />
  24. 24. Flexibilidade, Manutenibilidade e Escalabilidade<br />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.<br />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.<br />Estratégias &gt; Camadas<br />24<br />
  25. 25. Distribuição entre os servidores<br />Estratégias &gt; Camadas &gt; Distribuição entre os servidores<br />25<br />
  26. 26. SharedNothing<br />Remoção de Recursos Compartilhados<br />Escalonamento (quase) linear<br />Difícil de se conseguir na prática<br />Ainda assim, quanto menor a dependência entre os servidores, maior a possibilidade de escalabilidade.<br />Estratégias &gt; Camadas &gt; Distribuição entre os servidores<br />26<br />
  27. 27. SharedNothing<br />SharedNothing + Banco de Dados separado<br />Estratégias &gt; Camadas &gt; Distribuição Entre Os Servidores<br />27<br />
  28. 28. Por Camada <br />Uma forma bastante usada para escalar uma aplicação foi a distribuição das três camadas em servidores distintos, um para cada camada<br />Estratégias &gt; Camadas &gt; Distribuição Entre Os Servidores<br />28<br />
  29. 29. Por Camada <br />Dificuldade em manter estado<br />Complexidade do software aumenta, pois é necessário criar uma camada para abstrair as chamadas remotas (RPC, SOAP, etc.).<br />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.<br />Estratégias &gt; Camadas &gt; Distribuição Entre Os Servidores<br />29<br />
  30. 30. SOA - Service-orientedarchitecture<br />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. <br />Estratégias &gt; Camadas &gt; Distribuição Entre Os Servidores<br />30<br />
  31. 31. Pragmatismo<br />Shared Nothing + Por Camada + SOA<br />Estratégias &gt; Camadas &gt; Distribuição Entre Os Servidores<br />31<br />
  32. 32. Mensagens Assíncronas<br />Estratégias &gt; Camadas &gt; Mensagens Assíncronas <br />32<br />
  33. 33. Mensagens Assíncronas<br />Normalmente, quando uma funcionalidade de uma das camadas é chamada, espera-se um resultado o mais rápido possível.<br />Estratégias &gt; Camadas &gt; Mensagens Assíncronas <br />33<br />
  34. 34. Mensagens Assíncronas<br />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. <br />Estratégias &gt; Camadas &gt; Mensagens Assíncronas <br />34<br />
  35. 35. Mensagens Assíncronas<br />Camada consumidora da mensagem tem flexibilidade para consumir essas mensagens conforme sua capacidade<br />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<br />Estratégias &gt; Camadas &gt; Mensagens Assíncronas <br />35<br />
  36. 36. 36<br />Reutilização<br />Computacional<br />
  37. 37. Reutilização Computacional<br />Guardar um valor que foi previamente calculado para futuro reuso<br />Poupar recursos para atender maior número de requisições<br />Principal recurso a ser poupado: Banco de Dados, pois é o mais difícil de escalar<br />Estratégias &gt; Reutilização Computacional<br />37<br />
  38. 38. Desnormalização <br />Estratégias &gt; Reutilização Computacional &gt; Desnormalização <br />38<br />
  39. 39. Desnormalização <br />A utilização de RDBMS de forma rigorosa, utilizando apenas dados normalizados e depois usar “Join” e “GroupBy” pode ser muito custosa.<br />Gravar os dados de forma normalizada, mas também gravar de forma desnormalizada<br />Custo computacional acontece no momento da inserção<br />Estratégias &gt; Reutilização Computacional &gt; Desnormalização <br />39<br />
  40. 40. Desnormalização – TagCloud<br />Estratégias &gt; Reutilização Computacional &gt; Desnormalização <br />40<br />
  41. 41. Desnormalização – TagCloud<br />Estratégias &gt; Reutilização Computacional &gt; Desnormalização <br />41<br />
  42. 42. Cache<br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />42<br />
  43. 43. Cache<br />Cache é um mecanismo de reutilização computacional que grava em uma área temporária dados que possuem uma grande probabilidade de serem utilizados novamente<br />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). <br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />43<br />
  44. 44. O que colocar no cache? <br />Dados processados por qualquer uma das camada<br />Interface<br />Aplicação<br />Persistência<br />Etc.<br />Mas como o banco de dados é o mais difícil de escalar, normalmente esta camada é a primeira a fazer utilização do cache <br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />44<br />
  45. 45. Localização do Cache <br />Local (utilizando recurso do servidor)<br />Distribuído (utilizando servidores especializados em cache)<br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />45<br />
  46. 46. Localização do Cache - Local <br /><ul><li>Vantagem: Não tem I/O de rede
  47. 47. Desvantagem: Difícil invalidação, limitado ao servidor</li></ul>Estratégias &gt; Reutilização Computacional &gt; Cache<br />46<br />
  48. 48. Localização do Cache - Distribuído <br />Vantagem: Fácil Invalidação e Escalabilidade<br />Desvantagem: I/O Rede<br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />47<br />
  49. 49. Política de troca<br />Como saber o que é mais relevanta para o cache?<br />A melhor política de troca de um cache seria aquela que soubesse qual dado seria utilizado no futuro, assim mante-lo armazenado.<br />Política mais comum para aplicações web<br />LRU (elemento recentemente menos usado)<br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />48<br />
  50. 50. Invalidação<br />O maior problema na utilização de um cache é saber quando aquele conteúdo que está no cache não é mais válido. <br />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?<br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />49<br />
  51. 51. Invalidação<br />Opções<br />A cada nova ação que altera o dado<br />Por tempo<br />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.<br />Estratégias &gt; Reutilização Computacional &gt; Cache<br />50<br />
  52. 52. Conteúdo Estático <br />Estratégias &gt; Reutilização Computacional &gt; Conteúdo Estático <br />51<br />
  53. 53. Conteúdo Estático <br />Não existe nada mais econômico em termos de processamento para uma aplicação web do que servir um arquivo simples<br />Diferença entre gerar conteúdo estático e um cache <br />O conteúdo estático não precisa ser descartado, podendo permanecer no disco até que o conteúdo sofra uma alteração<br />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<br />Estratégias &gt; Reutilização Computacional &gt; Conteúdo Estático <br />52<br />
  54. 54. Conteúdo Estático <br />Cenários:<br />Página principal (ex: um portal)<br />Site com pouca interação ou personalização (ex: Wikipedia)<br />Site de imagens (ex: Flickr)<br />Estratégias &gt; Reutilização Computacional &gt; Conteúdo Estático <br />53<br />
  55. 55. Conteúdo Estático - CDN<br />Aliviar a carga dos servidores de conteúdos estáticos<br />Melhorar o tempo de entrega desses conteúdos para usuários distribuídos no globo<br />Difícil Invalidação<br />Estratégias &gt; Reutilização Computacional &gt; Conteúdo Estático <br />54<br />
  56. 56. 55<br />Particionamento de Dados<br />
  57. 57. Particionamento de Dados<br />Um dos desafios para uma aplicação web é como escalar o processamento e armazenamento dos dados. <br />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.<br />Estratégias &gt; Particionamento de Dados<br />56<br />
  58. 58. Consistência e Disponibilidade <br />Estratégias &gt; Particionamento de Dados &gt; Consistência e Disponibilidade <br />57<br />
  59. 59. Consistência e Disponibilidade <br />CAP (consistent, available e partition-tolerant)<br />Consistência<br />Disponibilidade<br />Tolerância a particionamento<br />Um sistema pode ter no máximo duas dessas três características, sendo impossível ter as três ao mesmo tempo<br />Estratégias &gt; Particionamento de Dados &gt; Consistência e Disponibilidade <br />58<br />
  60. 60. Consistência e Disponibilidade <br />Mas se o particionamento é obrigatório?<br />ACID vs. BASE<br />ACID: Atomicity, Consistency, Isolation, Durability<br />BASE: Basically available, soft state, eventually consistent<br />Estratégias &gt; Particionamento de Dados &gt; Consistência e Disponibilidade <br />59<br />
  61. 61. Sharding<br />Estratégias &gt; Particionamento de Dados &gt; Sharding<br />60<br />
  62. 62. Sharding<br />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.<br />Estratégias &gt; Particionamento de Dados &gt; Sharding<br />61<br />
  63. 63. Sharding - Vertical <br />Estratégias &gt; Particionamento de Dados &gt; Sharding<br />62<br />
  64. 64. Sharding - Horizontal<br />Estratégias &gt; Particionamento de Dados &gt; Sharding<br />63<br />
  65. 65. 64<br />Evolução da Arquitetura<br />
  66. 66. Evolução da Arquitetura<br />Monitoramento <br />Modelos Prematuros <br />Evolução da Arquitetura<br />65<br />
  67. 67. 66<br />Conclusão<br />
  68. 68. Conclusão<br />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. <br />Conclusão<br />67<br />
  69. 69. Conclusão<br />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.<br />Conclusão<br />68<br />
  70. 70. Conclusão<br />Uma classificação possível foi apresentada para as estratégias de escalabilidade estudadas, onde se examinou:<br />Camadas<br />Reutilização Computacional<br />Particionamento de dados<br />Conclusão<br />69<br />
  71. 71. Conclusão<br />Camadas<br />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.<br />Conclusão<br />70<br />
  72. 72. Conclusão<br />Reutilização Computacional<br />Escolhendo por usar conteúdos estáticos, vai-se na direção da alta escalabilidade, porém com baixa flexibilidade. <br />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. <br />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<br />Conclusão<br />71<br />
  73. 73. Conclusão<br />Particionamento de dados<br />O particionamento é sempre uma opção que não pôde ser descartada<br />Escolhendo pela consistência, os sistemas tiveram que rejeitar ou por em espera interações com os dados. <br />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.<br />Conclusão<br />72<br />
  74. 74. Conclusão<br />Evolução da Arquitetura <br />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<br />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á.<br />Conclusão<br />73<br />
  75. 75. Fim<br />Obrigado<br />74<br />

×