RUBY ON RAILS ESCALÁVEL: ESTUDO E SOLUÇÕES

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA CATARINA SISTEMAS DE INFORMAÇÃO RUBY ON RAILS ESCALÁVEL: ESTUDO E SOLUÇÕES GABRIEL GONÇALVES NUNES MAZETTO TRABALHO DE CONCLUSÃO DO CURSO Orientador: Prof. Leandro José Komosinski Florianópolis, 2011

2 GABRIEL GONÇALVES NUNES MAZETTO RUBY ON RAILS ESCALÁVEL: ESTUDO E SOLUÇÕES Trabalho de conclusão de curso apresentado como parte das atividades para obtenção do grau de Bacharel em Sistemas de Informação pela Universidade Federal de Santa Catarina a Gabriel Gonçalves Nunes Mazetto. Orientador: Prof. Leandro José Komosinsk Banca Examinadora: Renato Fileto Mario Dantas Florianópolis, 2011

3 Dedico este trabalho a todas as pessoas que de alguma forma contribuíram com a realização deste, em especial aos amigos da área de tecnologia que participaram de inúmeras discussões e trocas de informação sobre o tema, a minha namorada, pela paciência e compreensão e a minha família pela educação e oportunidade que me deram.

4 AGRADECIMENTOS Agradecimentos aos amigo Nassor Paulino da Silva, por toda ajuda e troca de conhecimentos que foram fundamentais a conclusão deste trabalho, Guilherme Arthur Gerônimo, pela oportunidade de trabalhar durante meu estágio com diversas questões relacionadas ao assunto deste TCC, ao meu orientador, pelas várias horas de atendimento durante a elaboração deste trabalho, e as diversas pessoas dentro da SeTIC/UFSC que foram fundamentais para tornar este trabalho realidade.

5 640kB devem ser bastantes para qualquer um. Bill Gates, 1981

6 RESUMO Este trabalho contém um estudo sobre as técnicas de escalabilidade aplicado ao contexto de aplicações Web, focado no framework de desenvolvimento Ruby on Rails. É realizado um levantamento das diversas opções de servidores, bases de dados relacionais e não relacionais (NoSQL) que podem ser utilizados com o framework, juntamente com um mapeamento dos problemas de escalabilidade que podem afetar uma aplicação web em geral, e quais desses problemas se manifestam em uma aplicação construída utilizando Ruby on Rails. Este trabalhado traz além de simulações para avaliar soluções de escalabilidade horizontal e vertical, uma proposta para construção de aplicações Multi-Site, tratando a questão de escalabilidade de aplicações como serviço (SaaS). Palavras-chave: Ruby on Rails, escalabilidade, Ruby, web, SGBD, NoSQL, Benchmark.

7 ABSTRACT This document contains a study of scalability techniques applied to the context of Web Applications, with focus to the web development framework, Ruby on Rails. It contains a list of many different sorts of web servers, relational databases, non-relational databases, that can be used with the framework, also contains a list of the chief scalability problems that can affect a web application, and which of this can affect one built using Ruby on Rails. This document brings, in addition to simulations to help analyze scalability solutions, a proposal on how to build Multi-Site web applications, dealing with Software as a Service scalability problem. Keywords: Ruby on Rails, scalability, Ruby, web, DBMS, NoSQL, Benchmark.

8 LISTA DE ILUSTRAÇÕES Gráfico 1: Benchmark entre principais servidores web para Ruby...27 Gráfico 2: Tempo de execução do benchmark realizado pelo "Programming Zen"...36 Gráfico 3: Consumo de memória do benchmark realizado pelo "Programming Zen"...40 Gráfico 4: Valor médio de requisições por segundo do Apache e Nginx pela carga de conexões concorrentes Gráfico 5: Tempo médio de resposta das requisições pelo Nginx em baixa concorrência...62 Gráfico 6: Tempo médio de resposta das requisições pelo Apache em baixa concorrência...63 Gráfico 7: Tempo médio de resposta das requisições pelo Nginx em alta concorrência...64 Gráfico 8: Tempo médio de resposta das requisições pelo Apache em alta concorrência...65 Gráfico 9: Valor médio de requisições por segundo do Apache+Passenger e Nginx+Passenger pela carga de conexões concorrentes Gráfico 10: Comparativo de performance entre o resultado do Teste 1 e Teste Gráfico 11: Benchmark simulando escalabilidade vertical...70 Gráfico 12: Benchmark para 1 e 2 nodos em ambiente com distribuição de cargas...72

9 SUMÁRIO Lista de ilustrações... 6 Introdução Motivação Metodologia Escalabilidade Definição Tipos de escalabilidade Verticalmente Escalável (scale up) Horizontalmente Escalável (scale out) Maneiras de medir escalabilidade Escalabilidade de Carga Escalabilidade Geográfica Escalabilidade administrativa Lei de Amdahl Soluções comuns para problemas de escalabilidade Balanceamento de Carga Balanceamento de Armazenamento Balanceamento de Rede Balanceamento de CPU Escalabilidade em aplicações para web Introdução Arquitetura Web Problemas de escalabilidade Aplicações com processamento intenso Aplicações com enormes necessidades de armazenamentos Aplicações que precisem atender um grande número de usuários Aplicações Multi-Site Conclusão... 24

10 8 4 Escalabilidade em Ruby on Rails Introdução Servidores Web para Ruby Webrick Mongrel Thin Possibilidades Futuras Servidores Web de múltiplo propósito Apache Nginx Lighttpd Cherokee Servidores de Banco de Dados Relacional SQL Lite MySQL PostgreSQL Servidores de Banco de Dados NoSQL Introdução MongoDB CouchDB Cassandra Hadoop database Redis Implementações da linguagem Ruby Comparativos de performance Problemas Número crescente de acessos Necessidade crescente de processamento de informações Aplicações com necessidade crescente de armazenamento de dados ou arquivos Aplicações Multi-Site Soluções Arquitetura escalável para aplicações com muitos acessos Aplicações que necessitem processar muitas informações Aplicações com necessidade de armazenar muitos dados/arquivos Aplicações Multi-Site Como identificar gargalos (bottlenecks) Monitoramento e Análise de performance... 52

11 9 5 SIMULAÇÕES Configuração Ambiente de Virtualização Instalação do Passenger + Ruby Máquina Virtual Apache2 + Passenger Máquina Virtual Nginx + Passenger Metodologia Ferramentas Apache Benchmark Gnuplot Cenários Comparativo entre soluções de servidor multi-propósito Comparativo de escalabilidade horizontal vs. vertical com Ruby on Rails Conclusão...73

12 INTRODUÇÃO Este trabalho tem por finalidade apresentar uma série de estratégias e soluções, para problemas de escalabilidade, relacionados a aplicações Web desenvolvidas utilizando o framework Ruby on Rails, em sua ultima versão, atualmente 3.0. Por questões ideológicas do autor, o foco deste trabalho será em soluções que se adequem ao conceito de software livre ou free software 1 pela Free Software Fundation. Pelas mesmas razões, não farão parte do universo de pesquisa sistemas operacionais, aplicações e componentes considerados proprietários ou não livres. No entanto, a existência deles poderá ser comentada. O sistema operacional de referência para esse trabalho é o Ubuntu Linux, de forma que todos os exemplo, configurações, aplicativos e trechos de código foram testados e executados nele. O fato da escolha não limita este trabalho e suas soluções a esta distribuição em específico, sendo que qualquer outra distribuição que atinja os requisitos mínimos dos softwares e versões compatíveis, serão capazes de reproduzir resultados semelhantes, atentando as especificidades de cada uma. Ainda o fato da escolha do sistema operacional, não inviabiliza por completo que algumas soluções possam funcionar de forma completa ou parcial também em outros sistemas que sejam capazes de rodar o framework Ruby On Rails, porém a essas, o autor deixa o leitor a tarefa de experimentar e adaptar. 1 A definição conceitual e filosófica pode ser encontrada no endereço: [EN]

13 Motivação Existem diversos tipos de tecnologias para desenvolvimento de aplicações web, algumas se baseiam em linguagens e trabalhos acadêmicos, outras, estritamente nas necessidades do mercado. Ruby on Rails é um caso de tecnologia que surgiu atendendo estritamente necessidades do mercado. Sua concepção se deu a partir da extração de parte do código-fonte da ferramenta Basecamp da 37 signals, na época em fase ainda embrionária, teve sua primeira release em julho de 2004, com licença de código livre. De lá pra cá, conquistou espaço mundialmente na industria de desenvolvimento de software, concentrando o conhecimento a seu respeito e a direção do seus desenvolvimento no ecossistema criado em torno da mesma, composta por desenvolvedores entusiastas e algumas empresas. Devido suas características e sua origem essencialmente no mercado, muito pouco conhecimento acadêmico foi gerado a respeito desta tecnologia. Além deste fato, com a adoção crescente da mesma, para projetos de médio e grande porte, criou-se um vazio de conhecimento separando as empresas e desenvolvedores que passaram pela necessidade de escalar suas aplicações e adquiriram o conhecimento de como fazê-las, daquelas que ainda não o fizeram. Com isso, fica claro a necessidade colaborar com a geração de conhecimento acadêmico a respeito do assunto, procurando oferecer informações e ferramentas para aqueles que desejam desenvolver aplicações que possam escalabilidade utilizando o framework Ruby on Rails. 1.2 Metodologia Para entender o problema é necessário primeiramente compreender os conceitos fundamentais de escalabilidade e o que influencia uma aplicação a ser ou não escalável.

14 12 Portanto, será apresentado no capítulo 2 o embasamento teórico relacionado a escalabilidade, seus tipos, e os problemas mais comuns que sistemas de maneira em geral apresentam, relacionados a ela. No capítulo 3, o foco passará para aplicações Web, e portanto será visto de que forma o problema de escalabilidade se apresenta neste contexto e quais as soluções que geralmente são feitas. Essas informações ampliam a utilidade deste trabalho, tornando parte dele utilizável para outras tecnologias que não a foco deste. No capítulo 4 o problema de escalabilidade será abordado no contexto específico de aplicações Ruby on Rails, listando os casos comuns, soluções, e um levamtamento dos diversos componentes de infra-estrutura que poderão ser utilizados ao desenvolver uma aplicação, em conjunto com seus pontos positivos e negativos. No capítulo 5, serão feitas a execução de algumas simulações em conjunto com medições, para auxiliar a avaliação das estraégias de escalabilidade, que poderão ser repetidas em conjunto com uma aplicação real, para avaliar a melhor estratégia a ser adotada. Pretende-se fornecer informações que sejam úteis a auxiliar na implementação de código para tornar as aplicações escaláveis, em conjunto com a sugestão de algumas ferramentas, plugins, servidores, etc disponíveis atualmente.

15 2 ESCALABILIDADE 2.1 Definição Em telecomunicações e na engenharia de software, escalabilidade é uma característica desejável em todo o sistema, em uma rede ou em um processo, que indica sua habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para crescer. (André B. Bondi, p ) De maneira mais geral, pode-se afirmar que um sistema é escalável quando o mesmo tem a capacidade de crescer, seja em numero de utilizadores, em quantidade de requisições, em quantidade de dados armazenados, processados etc, sem necessidade de reescrita ou alteração considerável no código. Um sistema capaz de escalar (escalável) é um sistema que continua eficaz quando há um aumento significativo do número de recursos e utilizadores, em que não é necessário alterar a implementação dos componentes e da forma de interação das mesmas. Num sistema escalável, as seguintes propriedades devem ser verdadeiras: Os recursos envolvidos devem aumentar linearmente com a dimensão do sistema O aumento na dimensão dos dados/recursos não deve levar a uma diminuição significativa do desempenho a redução não deve ser superior a O(log n). 2.2 Tipos de escalabilidade A escalabilidade pode ser analisada por diversos ângulos.

16 Verticalmente Escalável (scale up) Significa adicionar recursos em um único nó do sistema (mais memória ou um disco rígido mais rápido) Horizontalmente Escalável (scale out) Significa adicionar mais nós ao sistema, tais como adicionar um novo computador com uma aplicação para clusterizar o software. 2.3 Maneiras de medir escalabilidade Existem algumas maneiras de medir ou determinar que um sistema é escalável Escalabilidade de Carga Quando um sistema distribuído deve ser fácil para ser expandido e usar sua gama de recursos para acomodar tanto exigências do mesmo sendo elas pouca ou excessiva Escalabilidade Geográfica Um sistema é geograficamente escalável quando ele mantém sua performance, utilidade e usabilidade, independente da maneira como ele está distribuído, isto é, ele consegue ir de uma arquitetura mais concentrada para uma mais distribuída Escalabilidade administrativa Não importa a variação de informação que diferentes organizações necessitam compartilhar em um único sistema distribuído, ele deve permanecer fácil de ser usado e gerenciado Escalabilidade Funcional Um sistema é funcionalmente escalável quando é possível adicionar recursos ou melhorias ao sistema com esforços mínimos.

17 Lei de Amdahl A Lei de Amdahl é a lei que governa o speedup (ganho) na utilização de processadores paralelos em relação ao uso de apenas um processador. Seu nome deriva do arquiteto de computadores Gene Amdahl. O ganho de desempenho que pode ser obtido melhorando uma determinada parte do sistema é limitado pela fração de tempo que essa parte é utilizada pelo sistema durante a sua operação. O ganho depende de dois fatores: 1. Fração de melhoria (Fm): fração de tempo da computação que pode tirar proveito da melhoria feita. Esta fração é sempre menor ou igual a Ganho de execução (Ge): ganho obtido com a melhoria na parte específica modificada do sistema. Este ganho é sempre maior que 1. 1 ganho= 1 Fm Fm Ge Speedup pode ser definido como a relação entre o tempo gasto para executar uma tarefa com um único processador e o tempo gasto com N processadores, ou seja, Speedup é a Medida do ganho em tempo. S = T 1 T N Onde S é o speedup e T(N) é o tempo gasto para N processadores Wikipédia (2010a) 2.4 Soluções comuns para problemas de escalabilidade Podemos dividir os tipos mais comuns de soluções para problemas de escalabilidade em: balanceamento de carga, balanceamento de armazenamento, balanceamento de rede e balanceamento de CPU. Wikipédia (2010b)

18 Balanceamento de Carga Um serviço conforme comece a crescer, pode esbarrar nos limites do hardware ao qual ele está atrelado, independente do quão caro e moderno seja. Nesse caso, é o momento em que o serviço precisa ser distribuído por várias máquinas. Os casos mais genéricos de problemas com limitação de hardware são relacionados a processamento, memória ram, espaço de armazenamento limitações de rede. Wikipédia (2010c) Balanceamento de Armazenamento O balanceamento do suporte de armazenamento permite distribuir o acesso a sistemas de arquivos por vários discos (software/hardware RAID 2 ), garantindo ganhos em tempos de acesso. Estas soluções podem ser dedicadas ou existir em cada um dos servidores do cluster. A distribuição dos dados quando objetivada para melhorar o tempo de acesso, tem como desafios principais questões como replicação dos dados, garantia de integridade (garantir que ao alterar o arquivo em uma copia principal, as cópias adicionais receberão também aquela alteração), transação (um arquivo precisa ser alterado, mas o mesmo está sendo acessado por outros usuários, como garantir que seja feita a alteração e ao mesmo tempo que todos usuários consigam ter o acesso ao conteúdo do arquivo naquele momento sem receber uma versão corrompida?). Quando esse tipo de replicação é feita utilizando-se de uma solução RAID, a complexidade de implementação é reduzida, já que tudo acontece na máquina do servidor ou no storage. Nesses casos, o próprio software ou hardware é quem cuida de todas as questões que envolvam a replicação e a garantia de integridade. No caso da utilização de soluções com RAID, pode-se ganhar também em confiabilidade, podendo ter redundância de disco em caso de falha. Existe a possibilidade de se trabalhar com replicação através de algum serviço no sistema operacional, replicando esses dados para outras máquinas da rede, utilizando por exemplo 2 Conjunto Redundante de Discos Independentes (Redundant Array of Independent Drives)

19 17 rsync do Linux. Um exemplo de utilização dessa abordagem é a criação de mirrors (espelhamento de dados) de um repositório Linux, ou de um serviço de downloads. Quando a necessidade de balancear o armazenamento se dá para conseguir ampliar sua capacidade, os problemas passam a ser diferentes do primeiro caso. Novamente a solução pode ser feita diretamente na própria máquina, através da adição de mais hardwares de discos, utilizar uma solução dedicada de storage, ou uma solução codificada na própria aplicação que seja capaz de distribuir e recuperar esses arquivos em diversos servidores diferentes. No primeiro caso, dependendo das características do sistema operacional, no qual o serviço está sendo disponibilizado, pode ser necessário que a aplicação seja adaptada, juntamente com configurações específicas, para realizar o mapeamento desses discos Balanceamento de Rede O balanceamento da utilização da rede resume-se em reencaminhar o tráfego destinado a um destino específico que esteja sendo muito requisitado, para outros destinos alternativos que também ofereçam o mesmo serviço/aplicação, a fim distribuir os acessos aos servidores. Este balanceamento pode ocorrer a qualquer nível da camada OSI Wikipédia (2010c). Um dos tipos mais comuns de solução para balanceamento em rede, na camada de aplicação, é realizado utilizando o serviço de DNS 3, responsável por prover a resolução de nomes dos servidores. Através da utilização de um escalonador usando algorítimo de Round-robin, distribui uniformemente entre os clientes, endereços distintos de máquinas. Esta solução não é ideal, já que não baseia essa distribuição em nenhuma informação dos servidores e nem garante que a carga de fato será distribuída uniformemente, pois os clientes podem ter comportamentos diferentes uns dos outros. Enquanto a solução utilizando DNS é uma das mais simples, a mesma não é considerada confiável, já que pode repassar o tráfego para um servidor que não esteja disponível naquele momento por algum motivo qualquer. 3 Do inglês Domain Name Server, refere-se a um dos serviços básicos de resolução de nomes da internet.

20 18 Um balanceamento um pouco mais elaborado, pode ser feito, por exemplo, por uma aplicação servidora que receba a requisição e através de algum algoritmo próprio, repasse a mesma para uma outra máquina em um cluster, agindo como se fosse um proxy. Este caso é comumente utilizado quando o cluster de servidores provê algum serviço que seja muito acessado ou que execute um processamento mais pesado. Para implementar isso, utiliza-se uma aplicação servidora altamente paralelizável e de baixa latência, para receber as requisições iniciais, fazendo a ponte entre as diversas outras máquinas e os clientes. Nessa solução é possível também que a aplicação servidora colete dados de carga e performance das demais máquinas para conseguir distribuir de fato as cargas uniformemente, bem como, realizar verificações para, caso algum dos servidores caia, não repasse o tráfego para ele. O problema da segunda solução é que ela se torna também um ponto de falha, não sendo assim considerada 100% confiável se utilizada sozinha. Uma alternativa para contornar esses problemas está na utilização de hardware específico, conhecido como load balancer, que pode trabalhar na camada de rede ou até mesmo na camada de aplicação. Este procura sanar tanto a questão de roteamento do tráfego, quando a questão de garantir que o tráfego esteja sendo repassado para algum servidor que seja capaz de responder. Dependendo do harware ou solução escolhida, pode utilizar outras variáveis para levar em conta para qual máquina ele deve direcionar tais quais carga atual, uptime, etc Balanceamento de CPU Este tipo de balanceamento é efetuado pelos sistemas de processamento distribuído e consiste, basicamente, em dividir a carga total de processamento pelos vários processadores no sistema (sejam eles locais ou remotos) Wikipédia (2010c).

21 3 ESCALABILIDADE EM APLICAÇÕES PARA WEB Aplicação Web é o termo utilizado para designar, de forma geral, sistemas de informática projetados para utilização através de um navegador, na internet ou em redes privadas ( Intranet ). Trata-se de um conjunto de programas que é executado em um servidor de HTTP (Web Host). O desenvolvimento da tecnologia web está relacionado, entre outros fatores, a necessidade de simplificar a atualização e manutenção mantendo o código-fonte em um mesmo local, de onde ele é acessado pelos diferentes usuários. Pode-se definir uma aplicação web como uma aplicação de software que utiliza a web, através de um browser como ambiente de execução. Wikipédia (2010d) 3.1 Introdução Neste capítulo será abordado de maneira comparativa e com alguns exemplos teóricos, quais as questões de escalabilidade que estão envolvidas em aplicações para Web e como as soluções mais tradicionais procuram sanar esse problema. 3.2 Arquitetura Web Não é objetivo deste trabalho detalhar o funcionamento da Web, mas de maneira simplificada podemos entender a arquitetura como composta por dois atores principais, um sendo o cliente (geralmente acessando por um programa chamado navegador), e outro, servidor (podendo este não necessariamente ser uma única máquina, se considerarmos sistemas distribuídos). Toda comunicação é feita através de protocolo HTTP 4 que por sua vez é implementado utilizando TCP e IP. Este protocolo é responsável pela requisição de recursos remotos (textos, imagens, etc), envio de informações de formulários, etc. Wikipédia (2010e) 4 Hipertext Transfer Protocol Protocolo de comunicação responsável pelo acesso a páginas web

22 20 Uma aplicação Web, dependendo de como foi projetada e programada, pode rodar em um simples servidor Web, ou rodar no chamado servidor de aplicação. Segundo a Wikipédia (2010f) podemos definir um servidor Web como sendo: um programa de computador responsável por aceitar pedidos HTTP de clientes, geralmente os navegadores, e servi-los com respostas HTTP, incluindo opcionalmente dados, que geralmente são páginas web, tais como documentos HTML com objetos embutidos (imagens, etc.). Já sobre um servidor de aplicação, é definido como: um servidor de aplicação ou em inglês, application server, é um software que disponibiliza um ambiente para a instalação e execução de certas aplicações. Os servidores de aplicação também são conhecidos como software de middleware. O objetivo do servidor de aplicações é disponibilizar uma plataforma que abstraia do desenvolvedor de software algumas das complexidades de um sistema computacional. No desenvolvimento de aplicações comerciais, por exemplo, o foco dos desenvolvedores deve ser a resolução de problemas relacionados ao negócio da empresa, e não de questões de infraestrutura da aplicação. O servidor de aplicações responde a algumas questões comuns à todas as aplicações, como segurança, garantia de disponibilidade, balanceamento de carga e tratamento de exceções. Wikipédia (2010g) 3.3 Problemas de escalabilidade No contexto de aplicações Web, os problemas fundamentais de escalabilidade se manifestam de diversas maneiras diferentes e atingem principalmente, aplicações, conforme classificaremos a seguir Aplicações com processamento intenso Considerando o cenário de uma aplicação Web que realize diversas tarefas que exijam processamento mais intenso, existem dois caminhos tradicionais a serem seguidos: Escalar verticalmente adicionando mais recursos de hardware a máquina servidora, para suprir as necessidades computacionais crescentes, até atingir o limite que a arquitetura de

23 21 harware permitir. Essa primeira abordagem é considerada mais limitada e pode resolver o problema até determinado ponto. Escalar horizontalmente, adicionando mais máquinas servidoras e distribuindo a carga de acesso e processamento entre essas diversas máquinas. Essa abordagem é mais interessante pois permite um crescimento muito maior do que a primeira. Qualquer que seja o problema, não é necessário escolher apenas um caminho, podendo combinar ambos procurando atingir melhores resultados Aplicações com enormes necessidades de armazenamentos Algumas aplicações podem necessitar armazenar grandes volumes de dados, sejam eles dados relacionais, que comumente são armazenados em bancos de dados realacionais, ou arquivos de mídia tais como fotos, vídeos, planilhas, etc. Quando falamos em dados relacionais, levamos o problema para o domínio dos bancos de dados e neste caso, podem existir inúmeras maneiras de se tratar este problema. Alguns bancos de dados são capazes de lidar com esse tipo de problema sozinhos e de maneira transparente para a aplicação. Um banco de dados pouco conhecido do grande público, mas bastante explorado pela comunidade de desenvolvedores de Ruby on Rails é o MongoDB 5. Ele difere dos bancos de dados relacionais e se auto-classifica na categoria de banco de dados orientado a documento. 10gen (2010) Quanto ao volume de dados, novamente pode ser escalado de maneira vertical, utilizando unidades de armazenamento realmente grandes, ou de maneira horizontal, dividindo o armazenamento dessas informações em vários nodos (servidores). Ao se utilizar a primeira opção o impacto mais claro é a performance das consultas, que, por estarem trabalhando com enormes volumes de dados de maneira concentrada, tendem a serem mais lentas. Por esse motivo, não é mais comum sua utilização. 5 Disponível em:

24 22 Ao trabalhar com a segunda alternativa, essa carga de processamento é dividida entre os nodos da mesma forma que a responsabilidade pelo armazenamento. Essa distribuição recebe o nome de Sharding e no caso do MongoDB é feita de maneira transparente para a aplicação. Algumas das técnicas implementadas por esse banco de dados, podem ser simuladas pela própria aplicação Web e gerenciada por algum algorítimo, especificamente criado para isso, quando o próprio banco de dados não der suporte a elas. Quando analisamos o caso de aplicações que precisem trabalhar com um grande volume de dados de mídia, os quais não estão armazenados em um banco de dados, podemos aplicar a técnica de Sharding ou investir em unidades de armazenamentos grandes o suficiente Aplicações que precisem atender um grande número de usuários Quando uma aplicação possui um grande número de usuários (e consequentemente de acessos), e principalmente, se é um número crescente conforme o tempo, ela precisa ter sido pensada desde o princípio para isso. Neste cenário, podemos incluir as questões de armazenamento citadas anteriormente bem como de processamento. Além dessas questões temos que levar em conta que parte da responsabilidade está no servidor Web que deve ser capaz de atender as necessidades intensas de acesso. A outra parte está na própria aplicação que deve ter seu código otimizado, sem gargalos de performance e preparado para funcionar com um ambiente distribuído. Nestes casos, a solução mais comum está em dividir os acessos em diversas máquinas, quantas forem necessárias a demanda dos clientes. Essa abordagem pode trazer diversos desafios, dependendo do suporte disponível pela arquitetura utilizada Aplicações Multi-Site Existe um tipo específico de aplicação Web, que é feitos pensando em oferecer um serviço para um grande número de pessoas, que se assemelha, em questão de funcionalidade e cus-

25 23 tomização a noção de que cada um possui uma própria instalação da aplicação, mesmo não sendo esse o caso. Um exemplo clássico desse tipo de aplicação é o caso de blogs. Qualquer pessoa pode instalar uma aplicação para disponibilizar um blog online, ou utilizar um serviço que cria e hospeda seu próprio blog. Na primeira situação em que existe de fato uma instalação para cada pessoa, se pensarmos em um serviço que trabalhe dessa maneira, conseguimos concluir rapidamente que existe um certo desperdício de espaço em disco e replicação de código. Pensando em aplicações Rails, o problema é ainda maior, já que isso implica também em desperdício de memória RAM (já que cada aplicação deve ser iniciada por completo para responder as requisições, e após responder, continua ativa). Existe também o problema de gerenciamento dessas diversas instalações, e o deploy de novas versões. Contudo, a abordagem tradicional fornece algum nível de escalabilidade horizontal out of the box, já que a carga acaba podendo ser dividida entre várias máquinas (e as várias instalações da aplicação). Como esse tipo de serviço, existe uma grande quantidade de outros serviços que se se encaixam nesse mesmo modelo. Dessa forma, é necessário pensar em uma estratégia para eliminar esse disperdício e ao mesmo tempo oferecer uma escalabilidade maior e melhor que a solução tradicional. A maneira com que o maior serviço de blogs, o Wordpress.com encontrou, foi utilizar uma mesma instalação física, para atender um número maior de endereços/proprietários de blog, a qual está preparada para essa finalidade. A solução utilizada por eles, pode ser estudada e aplicada para qualquer tipo de aplicação Web, tornando elas também Multi-site. Esse modelo de construção de aplicação web, será abordado em capítulo futuro, contextualizados para o framework Ruby on Rails.

26 3.4 Conclusão 24 Pelo fato de aplicações Web serem diferentes de conteúdos estáticos HTML, existem uma série de dificuldades que precisam ser tratadas quando pretende-se tornar o sistema escalável. Alguns desses problemas precisam ser resolvidos no domínio de banco de dados, outros em nível de hardware e parque de máquinas, mas acaba se tornando necessário na maioria dos casos que a aplicação seja pensada inicialmente para enfrentar esse tipo de situação, seja por ela mesma, ou por algum framework que implemente as técnicas necessárias.

27 4 ESCALABILIDADE EM RUBY ON RAILS 4.1 Introdução Neste capítulo será abordado as questões de escalabilidade que envolvem o framework Ruby on Rails, as soluções já existentes e problemas ainda em aberto. Pode-se inicialmente considerar que os problemas que afetam de uma forma geral aplicações Web também impactam nas aplicações que são feitas utilizando o framework Ruby on Rails. Dessa forma, devemos começar a análise pela camada de interação mais baixa de uma aplicação Rails, que é composta pelo servidor Web. Em seguida passaremos pelos servidores de bancos de dados e sua integração ao framework, as diversas implementações da linguagem Ruby para então analisar os problemas e propor soluções. Atualmente existem diversas opções de servidores que podem ser utilizados para rodar aplicações Ruby on Rails. Neste trabalho estão sendo citados os principais, mais conhecidos e relevantes ao problema que está sendo abordado. 4.2 Servidores Web para Ruby Uma primeira categoria de servidores que podem ser mencionados são aqueles que foram escritos especificamente para rodarem aplicações em Ruby. Estes podem ser considerados servidores especialistas no sentido que eles foram desenvolvidos para rodar códigos Ruby (consequentemente Ruby on Rails) e não se esforçam em fazer muito mais que isso.

28 Em ambiente de produção, dificilmente algum deles será utilizado sozinho, geralmente em conjunto com um servidor web de propósito multiplo que será comentado a seguir Webrick Talvez o servidor mais conhecido para aplicações Ruby on Rails, já que vem disponível em todas aplicações construídas com o framework, por padrão. Ele geralmente é utilizado nas fases iniciais de desenvolvimento. Criado por Masayoshi Takahashi e Yuuzou Gotou juntamente com contribuições de outros desenvolvedores, ele é totalmente escrito em Ruby e funciona como um servidor HTTP simplificado. Pela sua característica de ser uma implementação simplista, sem recursos para atender grandes demandas, não é indicado para ambientes de produção. Wikipédia (2011a) Mongrel É uma biblioteca HTTP de código aberto e um servidor web para aplicações escritas em Ruby, criado por Zed Shaw. Considerado o primeiro servidor web em Ruby que possui recursos de escalabilidade. O servidor em sí não é utilizado sozinho em ambiente de produção, por sua arquitetura single thread não suportar uma carga grande de acessos. Configurações mais comuns são feitas com várias instâncias do Mongrel em conjunto com Apache ou Nginx, estes fazendo papel de balanceadores de carga. Nessa arquitetura, o Apache ou Nginx, se encarregam de disponibilizar o conteúdo estático, e através de algum módulo de balanceamento de carga, distribui as requisições dinâmicas entre os processos do Mongrel, de certa forma, contornando os efeitos da limitação de thread única. Além desses servidores mais comuns, outras soluções também são utilizadas como o Lighthttpd ou ainda um hardware específico para balanceamento de carga entre as requisições das instâncias do Mongrel. Wikipédia (2011b)

29 Thin O mais rápido dos três, desenvolvido utilizando o componente de parser do Mongrel, a biblioteca EventMachine, uma biblioteca para lidar com operações de I/O da rede, que proporciona alta performance, estabilidade e alta escalabilidade, e a biblioteca Rack, responsável pela interface entre o servidor e a aplicação. O Gráfico 1 a seguir demonstra testes feito 6 com os principais servidores web para Ruby e a relação de ganho de performance que o Thin consegue em relação aos demais: Gráfico 1: Benchmark entre principais servidores web para Ruby Possibilidades Futuras No dia 11 de junho de 2010 teve início o desenvolvimento de uma nova e versão do Mongrel (chamada Mongrel2), que promete aproveitar a biblioteca de parser HTTP da versão anterior, já bastante consolidada, porém com o restante da aplicação totalmente reescrito, tendo escalabilidade como objetivo principal. Além do código ter sido repensado, houve mudanças estruturais que tornaram a aplicação algo totalmente diferente da primeira versão. Algumas das novas características são, segundo o próprio autor: Mongrel2 is an application, language, and network architecture agnostic web server that focuses on web applications using modern browser technologies. SHAW (2011) 6 Disponível em: