O documento discute modelos de arquitetura de websites de alta escalabilidade. Aborda conceitos como escalabilidade, arquitetura de software, aplicações web e estratégias de escalabilidade como camadas, reutilização computacional e particionamento de dados. O autor analisa como grandes websites lidam com alto tráfego e usuários usando essas estratégias arquiteturais.

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

9. Sites estudados Introdução 9

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

21. 21 Camadas

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

36. 36 Reutilização Computacional

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

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

56. 55 Particionamento de Dados

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

67. 66 Conclusão

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

75. Fim Obrigado 74