DAVID LOJUDICE SOBRINHO

Transcrição

1 DAVID LOJUDICE SOBRINHO AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE FACULDADE DE TECNOLOGIA DE SÃO PAULO Pós-graduação em Tecnologia em Análise e Projeto de Sistemas São Paulo 2009

2 DAVID LOJUDICE SOBRINHO AVALIAÇÃO DE MODELOS DE ARQUITETURA DE WEB SITES DE ALTA ESCALABILIDADE Monografia apresentada à Fatec SP, como requisito para obtenção do título de especialista em Tecnologia de Análise e Projeto de Sistemas. Orientador: prof. Eduardo Endo FACULDADE DE TECNOLOGIA DE SÃO PAULO Pós-graduação em Tecnologia em Análise e Projeto de Sistemas São Paulo 2009

3 i DEDICATÓRIA Aos meus pais que sempre me apoiaram incondicionalmente...

4 ii AGRADECIMENTO Agradeço ao meu orientador, prof. Eduardo Endo, a profa. dra. Marcia Ito, e meus professores do curso de pós-graduação da FATEC, pelo conhecimento que eles transmitiram e direcionamento neste trabalho. Ao meu grande amigo prof. Fernando Paes Campos pelo apoio neste trabalho. À minha família e meus amigos que me apóiam agora e sempre.

5 iii BANCA EXAMINADORA Prof. Eduardo Endo - Orientador FATEC Faculdade de Tecnologia de São Paulo Prof a. Dr a. Marcia Ito FATEC Faculdade de Tecnologia de São Paulo Prof. Dr. Kazuo Watanabe FATEC Faculdade de Tecnologia de São Paulo

6 iv SUMÁRIO 1. INTRODUÇÃO FONTE DE INFORMAÇÃO SITES ESTUDADOS APLICAÇÃO WEB ARQUITETURA DE SOFTWARE ESCALABILIDADE ESTRATÉGIAS CAMADAS REUTILIZAÇÃO COMPUTACIONAL PARTICIONAMENTO DE DADOS COMPARATIVO DAS ESTRATÉGIAS EVOLUÇÃO DA ARQUITETURA CONCLUSÃO REFERÊNCIA APÊNDICE... ix

7 v LISTAS EXPRESSÕES Exp.1 - Escalabilidade Linear FIGURAS Fig.1 Shared Nothing Fig.2 - Shared Nothing com Banco de Dados separado Fig.3 - Por Camada Fig.4 - SOA Fig.5 - Arquitetura Mista Fig.6 - Processo Síncrono Fig.7 - Mensagem Assíncrona Fig.8 - Nuvem de Tags do Flickr Fig.9 - Modelo com valor desnormalizado Fig.10 - Cache Local Fig.11 - Cache distribuído Fig.12 - Cache menor que o repositório final Fig.13 - CDN Fig.14 - Modelo ER Lógico Fig.15 - Modelo ER distribuído usando Sharding Vertical Fig.16 - Modelo ER distribuído usando Sharding Horizontal GRÁFICOS Graf.1 Escalabilidade Vertical x Escalabilidade Horizontal... 11

8 vi TABELAS Tab.1 - Sites Estudados... 3 Tab.2 Referências às estratégias de Camadas Tab.3 - Referências às estratégias de Reutilização Computacional Tab.4 - Referências às estratégias de Particionamento de Dados... 46

9 vii GLOSSÁRIO ACID - Atomicity, Consistency, Isolation, Durability API - Application Programming Interface BASE - Basically Available, Soft State, Eventually Consistent CAP - Consistent, Available E Partition-Tolerant CDN - Content Delivery Network CPU - Central Processing Unit CTO - Chief Technology Officer FK - Foreign Key HTML - Hypertext Mark-Up Language HTTP - Hypertext Transfer Protocol I/O - Input/Output Joins - Uma cláusula SQL Join combina registros de duas ou mais tabelas em um banco de dados. JSon - Javascript Object Notation LRU - Least Recently Used MVC - Model View Controller ORDBMS - Object-Relational Database Management System PK - Primary Key RAM - Random Access Memory RDBMS - Relational Database Management System RPC - Remote Procedure Call SOA - Service-Oriented Architecture SOAP - Simple Object Access Protocol SQL - Structured Query Language SSI - Server Side Includes XML - Extensible Markup LanguageServer Side Includes

10 viii RESUMO Com o número cada vez maior de usuários conectados a internet, alguns web sites tem a desafiadora tarefa de atender milhões de usuários simultâneos, e ainda estar sempre disponível, sem comprometer a performance. Esses 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. Os web sites mais visitados no mundo foram bem sucedido e alguns deles disponibilizaram informações sobre como foi possível escalar para atender este volume de trafego. Este trabalho identifica e estuda quais estratégias e métodos de arquitetura de software que foram empregados em alguns dos maiores web sites da internet para escalar, assim atendendo o crescente número de acessos e usuários. Alguns aspectos se mostraram relevantes para a escalabilidade de uma aplicação web, como a comunicação e distribuição das camadas, as formas de reutilização computacional e o impacto do particionamento dos dados. Ainda foi examinado a evolução da arquitetura dos web sites estudados. Palavras chaves: Escalabilidade, Aplicação Web, Arquitetura de Software

11 ix ABSTRACT With the increasing number of users connected to the Internet, some web sites have the challenging task of answering millions of simultaneous users, and be always available, without compromising performance. These users can reach the web site without forecasting and in a large number, which meet all factor is crucial to the success of the site. The most visited websites in the world have been successful in this scenario and provided some information about how it was possible to scale to meet the volume of traffic. This work identifies and examines which strategies and methods of software architecture that were employed in some of the major internet web sites to scale, so acting in response to the increasing number of hits and users. Some aspects were relevant to the scalability of a web application, such as layers communication and distribution, forms of computing reuse and the impact of partitioning the data. Was examined the evolution of the architecture of web sites studied. Keywords: Scalability, Web Application, Software Architecture

12 1 1. INTRODUÇÃO Com o número cada vez maior de usuários conectados a internet, alguns web sites tem a desafiadora tarefa de atender milhões de usuários simultâneos, e ainda estar sempre disponível, sem comprometer a performance. Esses 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. O web site deve lançar mão de várias estratégias na sua arquitetura de software e infra-estrutura para atender todos esses requisitos e ainda continuar a crescer e, em alguns casos, ser flexível o bastante para poder encolher, dependendo do tráfego. Os web sites mais visitados no mundo foram bem sucedidos nesta tarefa, atendendo até bilhões de pageviews por dia e, alguns deles, disponibilizaram informações sobre como foi possível escalar para atender este volume de trafego. Porém, parte das informações disponibilizadas pelos web sites sobre suas arquiteturas foram feitas de forma informal, através de páginas na web ou blogs de funcionários. OBJETIVO O objetivo deste trabalho é investigar quais estratégias e evoluções nas arquiteturas de software foram empregadas em alguns dos maiores web sites da internet para escalar, e assim, atender o crescente número de acessos e usuários. Ficam fora do escopo deste trabalho outras partes importantes para a escalabilidade de uma aplicação web, como arquitetura de infra-estrutura e técnicas empregadas no software Client-side (Navegador Web). Também ficam fora outros requisitos não funcionais, como a alta-disponibilidade e performance, mesmo que em alguns casos esses requisitos possam ser satisfeitos ao se satisfazer o requisito de escalabilidade.

13 2 HIPÓSTESE Algumas hipóteses são levantadas neste trabalho. A primeira é de que exista um conjunto de propriedades das arquiteturas de softwares que são comuns entre os sites dos sites estudados. Isto permitiria uma classificação conforme estas propriedades. Dado essas propriedades comuns, a segunda hipótese é que o estudo transversal (não individual) entre os sites, permita um melhor entendimento dos métodos empregados e como esses métodos podem ser reutilizados em outros projetos. JUSTIFICATIVA O número de usuários que podem chegar a um web site impõe alguns desafios as tradicionais arquiteturas utilizadas para a construção de uma aplicação web. O intuito deste trabalho é auxiliar arquitetos de software na tomada de decisão sobre qual caminho devem escolher no momento de escalar uma aplicação web FONTE DE INFORMAÇÃO Como este trabalho tem a intenção de mostrar técnicas e modelos empregados por web sites comerciais, é importante ressaltar que algumas das fontes não são oficiais ou mesmo de pessoas ou empresas relacionadas ao web site. Na tentativa de garantir a precisão da informação, este trabalho segue as seguintes regras: Evidências: Algumas técnicas podem ser verificadas por evidencias e não é necessário que a empresa proprietária do web site divulgue sua utilização. Funcionários: Algumas empresas permitem que seus funcionários ou exfuncionários escrevam sobre seus trabalhos em blogs ou sites especializados. Ainda assim, muita dessas informações não é dada como oficial pela empresa proprietária do web site. Porém o blog ou web site é reconhecido por pertencer ao funcionário ou ex-funcionário da empresa e, logo, considerado uma fonte confiável para este trabalho.

14 3 No entanto, algumas empresas divulgam em seus blogs oficiais, sites especializados ou livros, informações sobre sua arquitetura e sua evolução. Essa informação será usada aqui neste trabalho com maior prioridade. Outra fonte importante utilizado neste trabalho é o site highscalability.com (Highscalability, 2009), especializado em compilar e divulgar informações sobre técnicas de escalabilidade e arquiteturas de web sites de alta escalabilidade SITES ESTUDADOS A maioria dos sites estudados são sites com um alto tráfego, sendo que a maioria está entre os principais sites da internet (Tab.1), com milhões de visualizações de páginas por dia. Outros são sites menos conhecidos, sites de nicho, mas com grande volume de acesso. Nessa lista ainda encontra-se sites menores, com médio volume de acesso, porém enfrentaram problemas de escalabilidade e disponibilizaram a documentação de sua arquitetura. Atuação Alexa Ranking Page Views per User (via Alexa) Amazon ecommerce Digg Social News ebay Social ecommerce FaceStats Fotos - - Flickr Fotos Google Busca LinkedIn Social Network LiveJournal Blog MySpace Social Network PlentyOfFish Relacionamento Slashdot Notícia 11, Twitter Micro Blog Wikipedia Conteúdo Social Tab.1 - Sites Estudados

15 4 A Tab.1 apresenta a lista dos sites estudados e seu respectivo ranking no Alexa (Alexa, 2009). O site Alexa é um serviço especializado em medir a audiência dos 100 mil principais sites da internet.

16 5 2. APLICAÇÃO WEB Segundo Henderson(2006), uma aplicação web é a junção da idéia de um web site (estático) e uma aplicação desktop, porém não é nenhum dos dois. Ou seja, tem características de web site e funcionalidades de uma aplicação desktop mas não pode ser enquadrado em nenhuma dessas características, pois um web site estático é formado por páginas estáticas, com nenhuma ou pouca interação com o usuário. As informações ali mostradas não são processadas, mas simplesmente entregues do servidor web no formato original ao cliente, geralmente um navegador web. Uma aplicação web tem a mesma idéia de entregar uma página ao cliente, porém essa página passa por um processamento para cada requisição feita ao servidor web. Já uma aplicação desktop tem a possibilidade de interação ampla com o usuário. Para isso utiliza do poder computacional (CPU, memória, etc.) local, do computador do usuário, para processar o que o usuário deseja fazer. Já a aplicação web tenta oferecer a mesma flexibilidade usando um misto de processamento local e processamento remoto, onde o processamento remoto é geralmente responsável por gravar e manipular os dados. O resumo feito por Henderson (2006) é que aplicações web são sistemas com um conjunto de dados central que pode ser acessado e modificado usando-se páginas web, com a possibilidade de outras interfaces (p.2). Tanto web sites estáticos e aplicações desktop ainda tem sua importância em diversos cenários, porém a utilização de aplicações web tem crescido muito como opção para cenários que antes eram exclusivos dessas outras tecnologias, principalmente porque amplia os limites que as duas tecnologias tem: iteratividade, personalização de um lado e poder de processamento e quantidade de informação do outro. Isso é importante ao sites que dependem de audiência ou empresas que querem vender seus produtos, pois segundo Arlitt(2001), personalization is desirable to boost repeat visits and increase revenue.

17 6 PADRÃO DE UTILIZAÇÃO Um dos fatores mais importantes para entender onde escalar uma aplicação web é entender como ela é utilizada pelos seus usuários e sistemas clientes. Conhecendo qual ação (leitura, gravação, etc.) e o conteúdo (página, web API, etc.) recebe mais requisições ou consome mais recursos do lado do servidor é possível tomar uma ação de escalonamento adequada. 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). Um exemplo de como o entendimento desse padrão é importante é o web site Digg.com (DiggA, 2009), onde a grande maioria dos usuário apenas acessam a página principal, lêem o conteúdo e deixam o site logo após. Assim, seu cache tem um "cache hit" (probabilidade de um item estar no cache) muito alto. Além disso, em seu banco de dados, 98% das ações são de leitura, fazendo o trabalho de escalabilidade muito mais fácil. Porém, o padrão de utilização de uma aplicação web pode variar drasticamente. Um desses motivos de variação são os robôs de busca, que varrem todo o site em busca de texto e outros links. Como a intenção desses robôs é varrer o maior número de página possível, isso invalida qualquer estratégia de escalabilidade baseada no padrão de utilização. Mas como não são freqüentes, é possível criar uma estratégia especifica para os robôs de busca. Um exemplo é desabilitar os caches e ler diretamente do banco de dados, deixando o cache válido para o padrão de utilização dos usuários e não do robô. Outro motivo que pode fazer uma aplicação web ter seu padrão de acesso alterado é quando um link do site é colocado em um web site que recebe muito acesso, geralmente um portal, fazendo com que parte desses usuários naveguem para aquela página especifica em um curto espaço de tempo. Esse efeito é conhecido na internet como "Slashdot effect" (Pilgrim, 2005). Isso se dá pois o site Slashdot.com costuma colocar links em sua página principal de sites menores.

18 7 Esses por sua vez recebem uma quantidade de usuários que não estavam acostumados e muitos não consegue escalar a tempo de atender a essa quantidade de usuários. Um exemplo do "Slashdot effect" aconteceu com o site FaceStat.com (FaceStat, 2009), que recebeu quase 650 mil visualizações de páginas simultâneas. O link de sua página principal foi para a página principal do portal Yahoo.com, com um volume de acesso muitas vezes maior do que o seu, o que levou ao site ficar fora do ar por um tempo considerável. Outros fatores podem alterar o padrão de uso da aplicação, como uma promoção de um produto ou personalizações de uma página para o usuário (Arlitt, 2001). Entender o padrão de utilização da aplicação web é extremamente importante para planejar o melhor modelo de escalabilidade.

19 8 3. ARQUITETURA DE SOFTWARE A arquitetura de software é extremamente importante para a escalabilidade de uma aplicação web, primeiro porque pode alterar o modo como a aplicação escala (Ebay, 2009), tornando mais eficaz o uso de recursos e porque pode ser o limitador da capacidade da aplicação escalar (DiggA, 2009). Segundo Fowler(2002), arquitetura de software é definido por dois aspectos: Arquitetura de software é a quebra de um sistema em partes menores, porém ainda com uma visão abstrata. A segunda definição é que arquitetura de software é onde mora as "decisões difíceis de serem alteradas". Quando se trata de escalabilidade de aplicações web esses dois pontos são muito importantes. Um sinal de que a arquitetura de uma aplicação tem qualidade, é quando as pequenas abstrações, as pequenas partes, têm responsabilidades bem definidas. Esse aspecto é importante pois quando chega o momento de refatorar a aplicação web para que ela se torne mais escalável (por ser um limitador ou melhorar o uso dos recursos), conhecer essas responsabilidades é fundamental, pois isso ajuda a atacar apenas aquelas partes que estão impedindo a escalabilidade. O segundo ponto, o da tomada de decisões difíceis de alteração, também é importante, pois as decisões de escalabilidade geralmente estão na base da arquitetura da aplicação. Escolher qual vai ser a arquitetura ou alterá-la implica em tomar decisões que levam em conta muitos fatores (técnicos, organizacionais e de negócios, por exemplo) e que se espera que seja robusta o suficiente de forma que não precise ser alterada. Assim, quando escalabilidade é um pré requisito para uma aplicação, é desejável que essas decisões levem a uma arquitetura que tenham o menor impacto possível nas futuras modificações do sistema. Este trabalho tenta focar exclusivamente em software. Porém algumas vezes, a plataforma de hardware pode influenciar na arquitetura de software (Henderson, 2006, p.16) e será abordado, mas apenas os pontos relevantes à arquitetura de software.

20 9 4. ESCALABILIDADE Existem algumas definições para escalabilidade. Segundo Hill(1990), um sistema é escalável quando sua performance melhora depois da adição de hardware, sendo essa melhora proporcional ao poder computacional do hardware adicionado. Uma definição parecida é dada em Amazon(2009). 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. Uma definição mais ampla é dada por (Schlossnagle, 2006, p.5): Escalar significa quão bem uma solução particular se encaixa em um problema enquanto o escopo do problema aumenta. Neste trabalho, o problema estudado é o aumento de utilização de recursos computacionais causado pelo aumento de acessos e/ou aumento de personalização da aplicação web. Por isso, para este trabalho, 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. Isso vai de encontro com o problema enfrentando pelos web sites (Schlossnagle, 2006, p.9), que tendem a manter o custo baixo no começo de suas operações, minimizando os riscos. Sejam esses custos vindos da necessidade de mais hardware e por isso precisam maximizar a utilização dos recursos existentes, ou da complexidade em manutenção e por isso precisam manter as soluções arquiteturais simples. Assim, uma arquitetura escalável tem que ser também flexível para mudar conforme a necessidade do web site. O fato de um sistema ser escalável é uma característica momentânea. Ou seja, um sistema pode suportar cada vez mais acessos apenas adicionando mais hardware ou melhorando os algoritmos de cache, por exemplo. Mas a partir de um determinado número de acessos, a solução começa a não ter mais ganhos. Seja por

21 10 um problema de hardware ou software, o sistema encontra seu limite de escalabilidade e deixa de ser escalável para aquele novo cenário. Para continuar escalando, é necessário encontrar o limitador e substituí-lo por uma nova solução. ESCALABILIDADE VERTICAL Chama-se 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). Uma vantagem deste modelo de escalabilidade é que normalmente se ganha maior capacidade sem alteração no sistema. Ou seja, quanto maior a capacidade do hardware, maior será a capacidade do sistema. Para algumas partes do sistema, essa abordagem pode ser a mais apropriada como, por exemplo, o banco de dados (Plentyoffish, 2009), onde é possível escalar apenas colocando mais memória RAM. Porém, essa estratégia tem seus limites. Primeiro, o custo deste modelo não escala linearmente (Henderson, 2006, p.204): um servidor com 4 CPUs custa aproximadamente o mesmo que 4 servidores com apenas uma CPU, porém um servidor com 72 CPUs custa aproximadamente 3.5 vezes mais do que o 72 servidores com apenas uma CPU (Graf.1).

22 Custo 11 Múltiplos Servidores Único Servidor CPUs Graf.1 Escalabilidade Vertical x Escalabilidade Horizontal Fonte: Henderson, 2006 E mesmo que o custo não seja um limitador (o que é raro para um web site), se alcançaria o limite imposto pelo fabricante, seja no número de CPUs ou quantidade de memória, que um único servidor pode suportar. Um limite, este mais comum, é que nem todos os recursos deste novo hardware podem estar sendo usados se a arquitetura de software deste sistema não for eficiente. Um exemplo comum é o uso de CPU. Isso acontece quando o novo hardware cresce em número de CPUs, porém o sistema tem poucos processos paralelos (Threads), o que geralmente leva a baixa utilização das múltiplas CPUs. Sem alteração do sistema, alterar o hardware tem pouco impacto na escalabilidade do mesmo. 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.

23 12 O principal motivador para escalar horizontalmente é custo. Como apresentado anteriormente, quando é necessário muito poder computacional, adição de novos servidores comuns é muitas vezes mais barato que a substituição por servidores mais potentes. Além disso, não se perde o investimento feito no hardware atual quando se escala horizontalmente. Porém, fazer o escalonamento horizontal pode ser bem desafiador e até mais caro que o escalonamento vertical. O primeiro desafio começa na administração, que deve gerenciar muitos servidores (alguns casos chega-se até milhares) (Michael, 2007). Administrar a rede, configuração e deploy desses servidores não escalam nas mesmas proporções que os servidores (Henderson, 2006, p.206). A escolha do hardware também deve ser estudado com cuidado para não desperdiçar recursos. Por exemplo, pode-se comprar maquinas com uma boa quantidade de memória RAM, e com CPU e disco mais baratos, pois o servidor vai ser usado apenas para cache, intensivo em uso de memória, mas utiliza pouco processamento ou persiste quase nada em disco. É importante também escolher um hardware onde o custo de manutenção seja balanceado com o custo de troca (Henderson, 2006, p.206). Outro ponto que dificulta e pode custar mais caro para este tipo de escalonamento é a arquitetura de software, o ponto que é objeto de estudo deste trabalho. Se a arquitetura de software não estiver preparada para escalar de forma horizontal, adicionar mais servidores será em vão. ESCALABILIDADE, ALTA DISPONIBILIDADE E PERFORMANCE Alta disponibilidade e performance são algumas das características não funcionais que podem acompanhar um sistema quando este é escalável. Porém é importante ressaltar que são características distintas e podem não aparecer simultaneamente. A alta disponibilidade é dada quando uma requisição feita a um sistema sempre retorne um resultado. Para a alta disponibilidade é necessário que o sistema

24 13 tenha algum tipo de redundância, seja para processar informações ou armazenar dados. Para isso, adicionam-se hardwares e mecanismos para distribuir o trabalho entre os servidores. Para acomodar esse requisito, pode ser que o sistema venha também a ficar escalável, ou ao contrário, sendo que para escalar o sistema ganhe alta disponibilidade. Adicionando hardware ou alterando a arquitetura de um sistema para que este fique escalável, pode trazer também mais performance, mas novamente são características distintas, pois ao mesmo tempo que adicionar hardware acarreta em mais poder computacional, também traz maior número de conexões entre eles, o que pode prejudicar a performance. Assim, mesmo que escalabilidade, alta disponibilidade e performance sejam características de um sistema que podem proposital ou acidentalmente virem juntas, tem propriedades e atendem a requisitos distintos.

25 14 5. ESTRATÉGIAS Durante a construção e evolução de suas aplicações web, os web sites aqui estudados encontraram, de alguma forma, problemas de escalabilidade. Quando isto aconteceu, a primeira coisa a fazer foi encontrar o problema e, uma vez identificado, trazer uma estratégia para atacá-lo. Este trabalho propões evidenciar os problemas de escalabilidade enfrentados pelos web sites e as estratégias escolhidas para tentar solucionar estes problemas. Os tópicos estão divididos em três grandes grupos: 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.

26 CAMADAS Quando se trata de arquitetura de software, a separação das responsabilidades é peça chave (talvez a mais importante) no processo de pensar um sistema. A intenção é sempre quebrar um problema maior em partes menores (Fowler, 2002), com responsabilidades bem definidas. Uma maneira de quebrar esses problemas e distribuir a responsabilidade entre elas é usando o que chama-se de camadas. Segundo Fowler(2002):... the hardest part of a layered architecture is deciding what layers to have and what the responsibility of each layer should be. Inicialmente estudada para sistemas operacionais (Dijkstra, 1968) e depois estudada de forma mais ampla (Parnas, 1972, Parnas, 1974, Parnas, 1976, Parnas, 1979), a idéia de camadas e suas responsabilidades é fundamental para a qualidade de um sistema, influenciando em vários de seus aspectos, principalmente a manutenibilidade e flexibilidade. 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 Flexibilidade, Manutenibilidade e Escalabilidade 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. Quanto mais camadas uma aplicação tem, maior será a sua manutenibilidade, porém com menor flexibilidade (Henderson, 2006, p.13). Ou seja, uma aplicação pode ter poucas camadas e assim terá maior flexibilidade ao se comunicar diretamente com as abstrações das camadas abaixo, sem precisar passar por abstrações intermediárias. Porém terá pouca manutenibilidade, pois provavelmente terá dificuldade em substituir essas camadas inferiores, caso necessário.

27 16 No entanto, 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. Uma distribuição de camadas bastante difundida e usada, principalmente por aplicações web, é a chamada "Arquitetura de Três Camadas" (Fowler, 2002), que contêm as camadas de apresentação, domínio (ou aplicação) e dados (ou persistência). O web site Flickr (Henderson, 2006, p.13), por exemplo, utiliza apenas uma arquitetura MVC na sua camada de apresentação e poucos frameworks, mas tende a criação de novas camadas conforme sua complexidade aumenta. Já o ebay (Ebay, 2009) tem suas camadas muito bem definidas: dados, aplicação, busca, operações, etc. É importante notar aqui que essa arquitetura vai além das três camadas mais conhecidas. A camada de persistência de dados é um ponto onde os web sites dão grande atenção. Por ser de difícil escalabilidade (ver outros tópicos: CAP, Sharding, Desnormalização), os bancos de dados tendem a ser o principal gargalo para estas aplicações (DiggA, 2009). Para evitar este gargalo, o ebay (Ebay, 2009) faz em algumas partes do sistema apenas operações simples na camada de persistência (no banco de dados) e deixa a responsabilidade de integridade referencial, joins e ordenações na camada de aplicação (ou de domínio). Apesar dessas operações serem normalmente feitas pelo banco de dados, neste caso é melhor ter menos utilização de CPU e I/O nos servidores de banco de dados e assim liberá-los para mais acessos. A razão para isto é que, segundo ebay, os servidores para a camada de aplicação são mais baratos, enquanto os de bancos de dados são o gargalo, difíceis de escalar. Outras formas de eliminar acesso ao banco de dados é vista no tópico Reutilização Computacional e Particionamento. O importante aqui é enfatizar a responsabilidade de cada camada, que dependendo da necessidade de escalabilidade, pode tomar responsabilidades que normalmente não lhe seriam atribuídas. Além disso, no caso do ebay, a manutenibilidade teve menos prioridade comparado com a capacidade que a aplicação tem de escalar.

28 Distribuição entre os servidores Outro ponto importante é a distribuição dessas camadas entre os servidores. O importante aqui não é, novamente, discutir a arquitetura de hardware, mas sim verificar como a distribuição física das camadas pode influenciar a arquitetura de software. Basicamente tem-se dois tipos de distribuição: servidores com todas as camadas em cada um deles (conhecido como Shared Nothing) ou servidores dedicados a uma camada ou responsabilidade (por exemplo, Applicantion Servers e SOA) Shared Nothing Uma maneira de se transformar uma solução de um problema em uma solução escalável é através da remoção dos recursos compartilhados. Assim, cada elemento da solução é autônomo e não interfere no trabalho do elemento ao seu lado, já que nada compartilham. Logo, podem-se acrescentar quantos elementos se quer, escalando linearmente. Isso se aplica para uma aplicação web (Flickr, 2009), uma CPU (Stonebraker, 1986) ou qualquer outra solução escalável. Aplicando essa lógica ao extremo às camadas de uma aplicação web, cada servidor teria tudo o que é preciso para rodar a aplicação web, da camada de apresentação a camada de persistência, incluindo o banco de dados. Assim, quando uma requisição fosse feita, ela iria ser executada do começo ao fim por um dos servidores. Se houverem 100 usuários simultâneos e cada servidor suportar 20 usuários cada, tem-se que ter 5 servidores para atende-los (Exp.1). Máximo Usuários Simultâneos Desejado Quantidade Usuários por Servidor = Servidores Exp.1 - Escalabilidade Linear Além disso, se obtém confiabilidade e performance. Confiabilidade pois, caso um dos servidores deixe de responder, isso não irá penalizar o trabalho de nenhum dos outros servidores, a não ser pela maior quantidade de requisições que eles tem

29 18 que atender. Todos os outros continuam a responder, pois não dependem um do outro. E performance, pois operações de I/O feitas em uma mesma máquina são normalmente mais rápidas do que se feitos através de um I/O de rede. A Fig.1 ilustra uma distribuição Shared Nothing. Cluster Load Balance ServerN Web Aplication Cache Server1 Server2 Server3 ServerN Database Fig.1 Shared Nothing Do ponto de vista da arquitetura de software e objetos distribuídos, a complexidade de ter camadas no mesmo servidor tende a ser muitas vezes menor do que camadas distribuídas. Fowler(2002) discute os benefícios de ter uma arquitetura não distribuída e chega a proclamar: First Law of Distributed Object Design: Don't distribute your objects. Porém, as aplicações web nem sempre tem o privilégio de poderem ter todas as camadas e suas dependências em apenas um servidor. Alguns dos motivos mais comuns são bancos de dados compartilhados, comunicação com sistemas ou serviços externos e dificuldade de deploy em múltiplos servidores, conforme ilustra a Fig.2. Ainda assim, quanto menor a dependência entre os servidores, maior a possibilidade de escalabilidade.

30 19 Cluster Load Balance ServerN Web Aplication Cache Server1 Server2 Server3 ServerN Cluster Load Balance ServerN Database Server1 Server2 Server3 ServerN Fig.2 - Shared Nothing com Banco de Dados separado 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, conforme mostra a Fig.3. Web Aplicação Cache Database Fig.3 - Por Camada

31 20 Assim, cada camada (apresentação, aplicação e persistência) tem seu conjunto de servidores dedicados. Quando há a necessidade de atender um número maior de usuários, escalase apenas a camada que se tornou o gargalo de escalabilidade. Normalmente essa distribuição é prejudicada em sua escalabilidade por tentar compartilhar estado, ou seja, os servidores de uma determinada camada compartilham, por exemplo, dados de um usuário, sessão ou uma determinada transação. Manter o gerenciamento de estado do lado do servidor e transações distribuídas, estudados nos tópicos CAP e Sharding, são um problema para escalabilidade. Mas é possível construir aplicações onde algumas camadas utilizam o princípio discutido acima, Shared Nothing, para evitar esses problemas (Ebay, 2009). Ou seja, os servidores de uma mesma camada não têm conhecimento sobre seus pares. Como descrito antes, outro problema deste tipo de distribuição é que a complexidade do software aumenta, pois é necessário criar uma camada para abstrair as chamadas remotas (RPC, SOAP, etc.). Além disso, qualquer chamada feita através da rede é mais custosa em termos de I/O que uma chamada local, no mesmo servidor. 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. Como o SQL já é uma linguagem pensada de modo distribuído (Fowler, 2002), ter o banco de dados em servidores separados não aumenta a complexidade da arquitetura da aplicação SOA - Service-oriented architecture Outra forma de escalar uma aplicação é usando SOA (Service Oriented Architecture). 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. Cada uma dessas responsabilidades teria sua própria arquitetura interna, com suas camadas, e diferentes problemas de escalabilidade.

32 21 SOA tem algumas definições distintas, mas usaremos a seguinte: segundo (Barry, 2003, p.19), duas ideais básicas estão por trás dessa arquitetura: Serviço e Conexão. Um serviço é uma função bem definida, autônoma e não depende do contexto e do estado de outros serviços. Para fazer a conexão, utiliza-se o protocolo de transferência HTTP para fazer a comunicação entre os sistemas. Para a formatação dos dados, apesar de não ser um padrão, é normalmente feito via XML ou, mais recentemente, JSon. Por exemplo, imaginando uma aplicação web que tivesse um módulo de autenticação, publicação de conteúdo e publicação de comentários, poderia-se ter um serviço para cada uma dessas responsabilidades, conforme ilustrado na Fig.4. Serviços Internos Serviços Externos Publicador Search Comentários Produtos Fig.4 - SOA A Amazon (Amazon, 2009), por exemplo, tinha inicialmente uma arquitetura monolítica e, para poder escalar, mudou para uma arquitetura totalmente descentralizada, voltada a serviço. Hoje, tanto seus sistemas internos como suas APIs publicas usam serviço. Segundo o seu CTO, Werner Vogels, para construir uma página da Amazon, pode se necessário chamar mais de cem serviços. Outro

33 22 exemplo é o Digg (DiggA, 2009), que utiliza extensivamente serviços, tanto internamente como para suas APIs. Comparada com a distribuição de servidores por camada, SOA tem algumas vantagens para a escalabilidade de uma aplicação. A primeira é o fato de ser independente de estado (stateless), logo, não existe transações distribuídas ou gerenciamento de estado entre os serviços. Outra vantagem é a comunicação padronizada, utilizando HTTP e XML, ou seja, independente de uma tecnologia ou fornecedor. Ainda assim, os dois tipos de arquitetura compartilham o custo das chamadas remotas. Independente de qual seja a distribuição de camadas entre os servidores, todos eles provavelmente acabam com uma arquitetura mista, onde Shared Nothing, distribuição por camada e SOA se misturam (Fig.5). Publicador Cluster1 Cluster DB Web Aplication Database Cache Search Fig.5 - Arquitetura Mista

34 Mensagens Assíncronas Normalmente, quando uma funcionalidade de uma das camadas é chamada, espera-se um resultado o mais rápido possível. Por exemplo, uma pesquisa no banco de dados (Fig.6). User Interface Aplicação Repositório Obter Comentários Obter Lista Comentários Lista Comentários Lista Comentários Fig.6 - Processo Síncrono 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. Ao mesmo tempo em que é importante que essa mensagem apareça o mais rápido possível aos amigos, não é mandatório que seja em tempo real (Twitter, 2009). São nesses cenários que, ao invés de chamar uma funcionalidade de uma camada de forma síncrona, simplesmente envia-se uma mensagem e a camada é responsável por ler essa mensagem, de forma assíncrona (Fig.7).

35 24 Usuário 2 Usuário 1 UI Aplicação Repositório Mandar Recado Mandar Recado Recado Enviado Gravar Recado Mensagem Assíncrona Recado Enviado Obter Recados Obter Recado Obter Lista Recado Efetivação da Operação Lista Vazia (Repositório ainda não processou) Lista Recados Vazia Lista Recados Vazia Gravar Recado Obter Recados Obter Recado Obter Lista Recado Lista com recados do Usuário 1 Lista Recados Lista Recados Fig.7 - Mensagem Assíncrona Quando falamos de um ambiente extremamente distribuído, mensagens assíncronas tem um papel importante. Segundo Hohpe(2003), asynchronous messaging is fundamentally a pragmatic reaction to the problems of distributed systems. Ainda segundo Hohpe(2003), mensagens assíncronas tem algumas vantagens. A primeira é que a camada consumidora da mensagem tem flexibilidade para consumir essas mensagens conforme sua capacidade e não corre o risco de sofre uma parada por excesso de requisições. Para a escalabilidade de uma aplicação web isto é importante, pois o que vai determinar se é necessário ou não escalar esta camada consumidora é o tempo ao qual a mensagem deve ser consumida. Assim, a necessidade de escalabilidade é proporcional ao tempo de consumo das mensagens. Em outras palavras: para cenários onde o consumo da mensagem deve ser rápido, talvez seja necessário muito poder computacional. Já para cenários onde a velocidade não é importante, estes ganham menos peso no momento de escalar.

36 25 Além disso, 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. Por exemplo: um pedido de uma página que deve salvar um comentário, que será persistido em um banco de dados. Caso a requisição ao banco de dados demore a finalizar, o recurso computacional que poderia atender outro usuário está agora preso até que a requisição termine. A melhor forma de liberar este recurso é fazê-lo de forma assíncrona. Dessa forma o comentário é salvo quando a camada de banco de dados estiver livre e o processo que recebe requisições de páginas está livre para atender novos pedidos. Outra vantagem na utilização de mensagens assíncronas é que as mensagens podem ser gravadas assim que enviadas e, se caso um dos sistemas não estiver disponível no momento, as mensagens podem ser consumidas posteriormente, melhorando assim outro aspecto do sistema: a confiabilidade. Ao mesmo tempo em que esta técnica resolve alguns problemas de escalabilidade, traz consigo complexidades que não existiam na forma síncrona. As principais são: ordenação das mensagens, quando é necessário manter a ordem das mensagens para se ter consistência da operação; padronização do formato e do protocolo da mensagem, para que a camada consumidora entenda a camada produtora da mensagem; repositório de mensagem, que é o local onde as mensagens vão ser gravadas e lidas; e dificuldade para obter o resultado da operação efetuada pela mensagem, já que uma vez envidada, a mensagem perde o contato com a camada produtora. Porém, quando se tem um ambiente distribuído, com alto volume de tráfego, a complexidade é um preço a ser pago, não restando outra opção. Tanto é assim que esta técnica é empregada em vários cenários pelos web sites: - Atualizar e manter consistência de dados particionados (DiggB, 2009, Linkedin, 2009): Ao invés de se fazer várias chamadas síncronas entre os bancos de dados, é possível enviar uma mensagem para cada camada responsável por aquele dado e deixar a responsabilidade atualizá-los para esta camada. O problema aqui é a consistência dos dados. Mais sobre as vantagens e desvantagens dessa solução serão vistas nos tópicos CAP e Sharding.

37 26 - Invalidar caches (Twitter, 2009): Mesmo quando os dados já estão salvos no repositório, invalidar as várias camadas de cache ou lugares onde aquele dado está no cache, pode ser uma tarefa custosa se feita de forma síncrona. Uma estratégia é enviar uma mensagem de forma assíncrona para que um sistema invalide o dado nos caches. - Realizar trabalhos paralelo em geral (DiggB, 2009, Livejournal, 2009): Para montar uma página com várias informações, pode-se fazer uma requisição para cada recurso de forma assíncrona, paralela, e no final esperar até que todas as requisições terminem. Assim, o máximo de tempo que se espera para construir uma página é o tempo da requisição que mais tempo levou para retornar e não a soma de todos os tempos das requisições, caso fosse feito de forma serial. Quanto menos tempo para construir a página, mais recursos são liberados para atender novas requisições.

38 REUTILIZAÇÃO COMPUTACIONAL Um dos pontos mais críticos na escalabilidade de uma aplicação web é o banco de dados. Seja qual for a tecnologia usada ou o tipo de banco de dados (RDBMS, ORDBMS, Document-oriented, etc.), o banco de dados tem que persistir e ler os dados da aplicação web da forma mais consistente possível e ainda assim atender e processar o máximo de requisições possíveis. Manter a consistência dos dados é uma tarefa árdua em um ambiente distribuído, pois para isso é necessário, em algum momento, um ponto de sincronização (detalhes no tópico CAP). Compartilhar um estado, como constatado no tópico Shared Nothing, neste caso o ponto de sincronização, é um característica que dificulta (e pode impedir) a escalabilidade dessa camada. Não é tarefa complicada sincronizar os dados entre dois ou três servidores de banco de dados. Porém a complexidade de manter a consistência entre os servidores cresce exponencialmente conforme a quantidade de servidores aumenta. Por sua dificuldade de escalabilidade, tenta-se evitar o acesso a esta camada (Plentyoffish, 2009), usando-a apenas quando estritamente necessário. Um dos modos de fazer isso é através de reutilização computacional (Schlossnagle, 2006, p.109), ou seja, guarda-se um valor que foi previamente calculado para futuro reuso. Porém, a reutilização computacional pode ir além do banco de dados. É possível guardas os dados vindos da camada de aplicação ou mesmo da camada de apresentação, poupando essas camadas, evitando reprocessamento e, assim, atendendo mais usuários. A seguir serão apresentados como as estratégias de desnormalização dos dados, utilização de cache e criação de conteúdo estático foram usadas pelos web sites e ajudaram a atender mais requisições, evitando escalar as camadas com recursos compartilhados.

39 Desnormalização Manter dados em um único lugar, sem duplicá-los, tem seus benefícios. Entre os principais está o ganho de integridade e a facilidade de manipulação desses dados. Essas são as idéias centrais por trás dos bancos de dados relacionais e a normalização de dados (Codd, 1970). Porém, para agrupar esses dados é necessário gastar processamento e I/O. Dependendo da complexidade do agrupamento ("Join" ou "Group By", por exemplo), processá-lo pode ser bem custoso. Agrupar muitas tabelas ou tabelas com muitos dados em um banco de dados relacional exige muito uso de CPU, memória e disco. Para evitar o custo de agrupar esses dados, e assim não gastar recursos do banco de dados, é possível manter uma cópia desnormalizada dos dados. Ao invés de pedir ao banco de dados para agrupar esses dados a cada requisição, com consultas (SQL) complexas, acessa-se a tabela que contém os dados já agrupados (PlentyoffIsh, 2009, Twitter, 2009) com simples consultas. A desnormalização é uma estratégia comum (Henderson, 2006, p.200) e muito usada entre os sites estudados. Um exemplo para ilustrar este problema é a nuvem de tags. Uma nuvem de tags é a representação gráfica da utilização das tags em um determinado objeto. O web site Flickr (Flickr, 2009), por exemplo, permite que os usuários coloquem tags nas fotos enviadas e mostra em uma de suas páginas as tags mais utilizadas (Fig.8).

40 29 Fig.8 - Nuvem de Tags do Flickr Este problema envolve agrupar os dados únicos, as tags de cada foto dos usuários, em um único lugar, a página de nuvem de tags. Obviamente, não faz sentido calcular a nuvem de tags para cada requisição da página que contém a nuvem, pois o custo para processá-la é muito alto. Uma das soluções é manter as tabelas normalizadas com os dados de cada foto e suas tags e manter uma tabela desnormalizada, já com os valores agregados (Fig.9). PK Foto FotoID Campo que mantém o valor desnormalizado SELECT COUNT(*) FROM FotoTag WHERE TagID = [Tag.TagID] FotoTag Tag PK,FK1 PK,FK2 FotoID TagID PK TagID Count Fig.9 - Modelo com valor desnormalizado O problema em desnormalizar os dados é justamente manter a consistência entre eles. Neste exemplo de nuvem de tags, por exemplo, agora temos a mesma informação em dois lugares (as tabelas normalizadas e a tabela desnormalizada).