O documento descreve a arquitetura de uma aplicação web hospedada na nuvem Amazon EC2 usando balanceamento de carga, clusters e dimensionamento automático para atender demandas variáveis. A aplicação consiste em módulos Ruby on Rails e Java EE hospedados em clusters JBoss e balanceados por Apache. A arquitetura usa Gossip Router e scripts para registrar e descobrir nós dinamicamente.

1. Deploying JBoss AS
on the Cloud
Setembro de 2010
Fábrica de Software
Sistemas e aplicações sob medida para as
necessidades do seu negócio.

2. Amazon EC2
Amazon EC2 (Elastic Compute Cloud)
IaaS – Infrastructure as a Service
Elástico
Controle completo (acesso de root)
Flexível (hardware, SO, etc)
Confiável (SLA de 99,95%)
Seguro
●
Firewall – Security Groups
●
Amazon VPC
Economia
●
Baixo custo para demandas sazonais

3. Aplicação Envolvida
Camada web desenvolvida usando Ruby on Rails
Dois módulos desenvolvidos usando Java EE:
Módulo de Acompanhamento – acessado via JavaScript via
HTTP/REST e JSON
Módulo de Lançamento - acessado pelo Módulo de
Acompanhamento via JMS
●
Filas para o processamento dos lançamentos
Módulos totalmente stateless

4. Dimensionamento
Estimativa de aproximadamente 150 mil usuários
cadastrados
Estimativa de carga muito alta durante alguns períodos do
dia
Durante os períodos de pico, foram estimados 100 mil
usuário simultâneos
Fora dos períodos de pico, os módulos Java EE não são
acessados

5. Dimensionamento
Elastic Compute Cloud
Possibilidade de aumentar ou diminuir a capacidade de
hardware de acordo com a variação da demanda durante o dia
De alguns poucos servidores a até 200 servidores nos períodos
de pico
Redimensionamento automático do ambiente utilizando API
WebServices da Amazon EC2
●
Linha de comando / totalmente scriptable

6. Principais Desafios
Elasticidade do ambiente
Muitos nós instanciados e desligados em um curto período de
tempo
Automatização total do processo
Registro automático de nós em clusters, load balancers, etc
Restrições da Amazon
Sem multicast
●
Impossibilita protocolo
UDP no cluster
IPs dinâmicos

7. Arquitetura Final

8. Arquitetura Final
Amazon HTTP Load Balancer
Sticky session usando Cookie
Configuração manual (adição de nós)
Health Check
Mongrel Cluster
Apache2 e mod_proxy_balancer
Cada cluster Mongrel possui 5 nós

9. Arquitetura Final
Gossip Router – JGroups
Permite a atribuição de nomes às máquinas com IP dinâmico
O nome atribuído vale enquanto a máquina estiver ativa
Gossip Router configurado em todas as máquinas Apache
Os nós dos clusters Frontend e Backend se registram durante o
startup
●
O registro é realizado em todos os Gossip Routers
ativos no momento do startup
●
Ao criar as máquinas JBoss, são informados os IPs das
máquinas onde estão instalados os Gossip Routers
Cron + Script atualiza o /etc/hosts da máquina Apache para
que ela possa encontrar os nós do JBoss de Frontend
O mesmo ocorre nas máquinas de Frontend para que consigam
encontrar os nós do JBoss de Backend

10. Arquitetura Final
Balanceamento via mod_jk
Foram pré-configurados 150 workers, apontando para 150
hostnames diferentes (frontend1, frontend2, ...)
Todos estão previamentre desabilitados
Cron + Script habilitam os workers que possuem um IP
atribuído pelo Gossip Router da máquina em questão
A habilitação é realizada dinamicamente através do módulo
JKStatusManager
Balanceamento Round Robin sem sticky session

11. Arquitetura Final
Frontend
Nós do JBoss 5.1.0.GA independentes (não configurados em
cluster)
Cada nó se registra em todos os Gossip Routers ativos durante
o startup
Cron + Script atualiza o /etc/hosts da máquina para que ela
possa encontrar os nós do JBoss de Backend
Integração com o Backend via JMS

12. Arquitetura Final
Backend
Cluster JBoss 5.1.0.GA com filas JMS (JBoss Messaging) para
distribuição do trabalho
Cada nó também se registra em todos os Gossip Routers ativos
durante o startup
JGroups – TCP Gossip Routing

13. Outras Abordagens Testadas
mod_cluster × mod_jk
mod_cluster
●
Nós se registram automaticamente
●
Não segue o padrão de configuração do Apache 2 –
Virtual Hosts
●
Conflitos de bibliotecas com mod_proxy_balancer
mod_jk
●
Nós são registrados manualmente, mas podem ser
ativados, inativados e ter seus dados atualizados via
JkStatusManager
●
Segue o padrão de configuração Apache 2
●
Sem conflitos com outros módulos

14. Monitoramento
Uso do RHQ 3.0.0
Monitoramento do Sistema Operacional (Ubuntu) das principais
máquinas envolvidas (Apache, pelo menos uma máquina JBoss
de Frontend / Backend e Postgres)
Monitoramento do JBoss em pelo menos uma máquina
Frontend e uma Backend
Foi necessária alteração do plugin JBoss AS para identificar e
monitorar corretamente o JBoss 5.1.0.GA
Foi criado um plugin que permite monitorar o tempo de
resposta da aplicação a partir, por exemplo, de um test case
Jmeter
Problema:
●
Nome do agente atrelado ao IP da máquina

15. Monitoramento

16. Monitoramento

17. Caminhos Futuros
Rails on JBoss
Realizar o deploy da aplicação no JBoss e remover o cluster
Mongrel
Facilidade de administração e escalabilidade
Alternativas para o deploy
●
Warbler – cria um
WAR a partir de
uma aplicação Rails
●
JBoss 5 Rails
Deployer – nativo
Apoio à evolução do RHQ 3.0.0
Melhor suporte a ambientes
elásticos / cloud

18. Obrigado!
www.dextra.com.br
contato@dextra-sw.com
(11) 2824-6722
(19) 3256-6722