1) O documento discute como criar infraestrutura de sites para receber milhões de usuários de forma escalável e altamente disponível. 2) Problemas como ponto único de falha no DNS, desempenho do banco de dados, tamanho de arquivos e consultas externas são abordados. 3) A solução proposta inclui balanceamento de carga, replicação, cache, sistemas de arquivos distribuídos e alta disponibilidade em vários níveis.

1. Como criar infraestrutura de sitesComo criar infraestrutura de sites
para receber milhões de usuários?para receber milhões de usuários?
Marcelo Dieder – marcelodieder@gmail.com
FLISOL 2014 / Novo Hamburgo

2. Internet na AtualidadeInternet na Atualidade
● População Mundial: 7.1 bilhões de pessoas
(2013) *
● Número de dispositivos conectado na internet:
39% da população mundial (2013) *
● Crescimento de serviços: Serviços Cloud, Redes
sociais, Internet das Coisas.
* Fonte: ITU

3. Internet na AtualidadeInternet na Atualidade
● Tudo na internet está sendo centralizado
no protocolo HTTP!
* Fonte: ITU

4. Protocolo HTTPProtocolo HTTP
● HTTP - Hypertext Transfer Protocol
● Versão atual: HTTP/1.1 (RFC 2616)
● Futuro prevê melhorias com o HTTP 2.0
● Situada na camada de aplicação
● Utiliza protocolo TCP como apoio
● Utiliza session/cookies como complemento
● Mensagem HTTP (Request x Response)
● Requisição
● Cabeçalho da mensagem (header)
● Corpo da mensagem

5. Protocolo HTTPProtocolo HTTP
(Request x Response)(Request x Response)
Fonte: http://www3.ntu.edu.sg/

6. Protocolo HTTPProtocolo HTTP
(Request x Response)(Request x Response)
Request
Response
Fonte: http://www3.ntu.edu.sg/

7. Server SideServer Side
● Operações ocorridas no lado do servidor
● Exemplos:
● Banco de dados
● Manipulação de imagens
● Busca de arquivos
● Linguagens de programação (PHP, JAVA,
PERL, RUBY, PYTHON, etc)

8. Client SideClient Side
● Operações ocorridas no lado do cliente
(navegador)
● Exemplos:
● Javascript
● CSS
● HTML
● XML
● Cookies

9. Renderização da PáginaRenderização da Página
● Processo de renderização monta o HTML/CSS no
server-side (servidor) para ser interpretado pelo
client-side (navegador).
● Como agilizar a montagem e entrega de uma página?
● Reduzir o tamanho e o número de objetos da página
● Evitar busca de conteúdos externos (web) no
server-side e também no client-side
● Disponibilizar conteúdo estático sempre que possível
● Utilizar cache no server-side, client-side, banco de
dados
● Utilizar compressão no protocolo http (gzip)

10. E a infraestrutura?E a infraestrutura?
● Como criar um ambiente para receber requisições
(server-side) de clientes, sem a existência de pontos
únicos de falhas?
● É necessário garantir alta disponibilidade dos serviços
de:
● Internet (BGP)
● Resolução DNS (autoritativo)
● Servidor HTTP
● Servidor Banco de Dados

11. Processo de conexão HTTPProcesso de conexão HTTP
Fonte: http://blog.catchpoint.com/

12. E agora?E agora?
Então, quais os problemas existentes
para podermos garantir a alta
disponibilidade da infraestrutura e
também garantir a entrega de sites
rápidos para milhões de usuários?

13. Problema 1: Alta Disponibilidade doProblema 1: Alta Disponibilidade do
registro A do DNSregistro A do DNS
● Todo domínio que possua um site, possui um registro A
apontando para um IP. Ex: linux.com aponta
140.211.167.50.
● Mas como garantir a alta disponibilidade do IP?
● Existe a opção de utilizar registros SRV para definir
pesos para servidores. Assim como ocorre no registro
MX para serviços de e-mail. Infelizmente a RFC do
HTTP não suporta SRV, talvez no HTTP 2.0?
● É possível balancear as requisições com a criação de
vários registros A, mas isto resolve o problema?

14. Problema 2: Banco de dadosProblema 2: Banco de dados
● Consultas lentas
● Falta de índices
● Uso incorreto do vínculo de tabelas
● Grande quantidade de registros
● Tipo de tabela no MySQL/MariaDB: Myisam x
InnoDB
● Myisam: Leitura muito rápida
● Myisam: Problemas com locks
● InnoDB: Indicado para leitura e escrita
● InnoDB: select pode ser mais lento mas ideal
para concorrência de inserts, updates e
selects

15. Problema 3: Manipulação deProblema 3: Manipulação de
imagensimagens
● A manipulação de imagens (crop,
redimensionamento, tratamento) deve ser feito
apenas 1 vez e não a cada acesso!
● Se possível separar servidor do tratamento de
imagens do servidor de distribuição de
conteúdo.

16. Problema 4: Tamanho de objetosProblema 4: Tamanho de objetos
● Atenção para o tamanho de objetos (imagens,
scripts, include de códigos, etc)
● Imagine que o usuário possui plataformas de
acesso e velocidade de internet diferentes do
que a sua. (celulares, tablets, banda larga, 3G).
● Se o conteúdo é enviado através de um editor,
certifique-se que são aplicados filtros para
verificar o tamanho do upload de objetos. (ex:
imagens)

17. Problema 5: Consulta a conteúdosProblema 5: Consulta a conteúdos
externosexternos
● Objetos externos devem ser utilizados apenas
em casos isolados. (ex.: tempo, facebook,
twitter, banners, imagens, etc).
● JAMAIS colocar a busca de objetos no processo
de renderização de uma página.
● O conteúdo pode ser buscado pelo servidor em
processos de apoio (ex.: crontab) ou ainda
diretamente no cliente-side (ex.: utilizando
javascript).

18. Problema 6: HTTP x HTTPS -Problema 6: HTTP x HTTPS -
Quando utilizar?Quando utilizar?
● HTTP é simples, texto puro, e não há
criptografia
● HTTPS realiza criptografia e utiliza mais
recursos do servidor e do cliente (cpu, memória,
link de internet).
● Utilizar HTTPS em sites envolvendo troca de
senhas ou operações de valor.
● Porque utilizar HTTPS em sites de publicação
de conteúdo? (ex.: portais, blogs)
● Controlar o uso de HTTP x HTTPS por
sessão/cookie.

19. Cache, cache, cache!Cache, cache, cache!
● Sempre que possível utilize cache
● Cache de DNS (ttl dns)
● Cache no http server-side
● Cache no http client-side
● Cache no banco de dados

20. Como criar infraestrutura de sitesComo criar infraestrutura de sites
para receber milhões de usuários?para receber milhões de usuários?
● Requisitos
● High Avaiability (HA)
● Load Balance (LB)
● Crescimento Horizontal
● Arquitetura Aberta
● Sem pontos de falhas

21. Camada de virtualizaçãoCamada de virtualização
● Garante o HA e LB da máquina virtual
● Não garante o HA e o LB da camada de
aplicação
● Permite melhor aproveitamento dos recursos do
hardware
● Qualquer virtualizador pode ser utilizado (KVM,
Xen, Vmware, outros)
● No cenário foi utilizado Vmware como
virtualizador.

22. Replicação do Banco de DadosReplicação do Banco de Dados
MySQL (Master-Master)MySQL (Master-Master)
● Permite a replicação do banco de dados em outras
instâncias.
● Garante o crescimento horizontal
● Existem diversas soluções para replicação do MySQL.
● Sistema nativo do Mysql
● Sistema nativo Mysql Cluster
● Galera Cluster (Codership)
● Principais problemas das soluções nativas do Mysql:
● Split brain
● Perda de sincronismo
● Complexidade

23. Galera Cluster (MySQL)Galera Cluster (MySQL)
● Multi-master replication
● Replicação sincrona
● Transparente para as aplicações
● Não é necessário dividir os nós de escrita e leitura
● Replicação em nível de arquivo
● Utiliza sistema de votação - Quorum-based system (mínimo
3 nós para evitar split brain)
● 2 nós → Split Brain!
● Suporta SSL
● Utiliza necessariamente engine Innodb
● Suportado também com MariaDB

24. Galera Cluster (MySQL)Galera Cluster (MySQL)

25. HA e LB do banco de dados comHA e LB do banco de dados com
proxyproxy
● Para LB e HA do banco de dados necessita de driver ou
sistema de proxy.
● Proxy: Pen, HAProxy, Pound
● Driver: mysqlnd (PHP), jdbc connector (JAVA)
● Utilizando driver pode necessitar de mudanças de código e
não tem tanta eficiência.
● Utilizando proxy tem melhor resultados
● Utilizado o HAProxy

26. HAproxyHAproxy
● Open source HTTP/TCP load balancer
● Pode fazer proxy de vários protocolos
● Utilizado para realizar o balanceamento e alta
disponibilidade do uso do banco de dados.
● Instalado em cada servidor de aplicação
● Aplicação utilizava um banco “local” (localhost)

27. Sistema de arquivos distribuídoSistema de arquivos distribuído
● Todos os nós de aplicação precisam acessar o mesmo
volume de arquivos.
● Para isto é necessário um sistema de arquivos
distribuido ou compartilhado.
● Opções: GFS2 (RedHat), OFCS2 (Oracle)
● Também é necessário a replicação do bloco de dados
ou o compartilhamento de um mesmo bloco. Ex: Ceph,
Volume iSCSI, DRDB.
● No cenário foi utilizado OCFS2 (melhor documentação
e estabilidade) e RAW Device Mapping no Vmware.

28. HTTP para a aplicaçãoHTTP para a aplicação
● Aplicação para receber requisições HTTP
● Opções: Nginx, Apache, Lighttpd, Tomcat,
outros.
● Utilizado o serviço Apache.

29. Replicação de sessãoReplicação de sessão
● Replicação de sessão para garantir sessão de
usuários autenticados entre os nós de aplicação.
● Alteração da regra: session.save_path no
php.ini apontando para uma pasta replicado
entre o cluster de aplicação.

30. Cache da aplicação HTTPCache da aplicação HTTP
● Melhora a experiência de navegação do usuário
● Reduz significativamente a carga dos servidores de
aplicação.
● Efetua LB e HA entre os servidores de aplicação.
● Sistema de cache utilizado garante a entrega de páginas
estáticas.
● O cache, tempo (ttl), pode ser configurado em nível de
objeto (fotos, html, imagens, css, etc.)
● Alternativas disponíveis: Varnish, Apache Proxy, Squid.
● Utilizado: Varnish
● Varnish: Permite regras baseados em cookies, pastas,
domínios, objetos.

31. Alta disponibilidade do IPAlta disponibilidade do IP
● Utilizado dois servidores FreeBSD com o protocolo CARP.
● Alternativa ao protocolo VRRP
● Protocolo CARP é exclusivo da família *BSD
● CARP pode garantir HA de um IP, resolvendo o problema
da publicação do DNS registro A.
● Também suporta o LB, apesar de não ter sido utilizado no
cenário.
● Consiste em disponibilizar um IP virtual que é
compartilhado entre n+1 hosts.

32. Alta disponibilidade do IP - CarpAlta disponibilidade do IP - Carp
Fonte:http://nomoa.com/

33. Alta disponibilidade do serviço deAlta disponibilidade do serviço de
internetinternet
● É necessário ser uma operadora de Internet
Autonomous System (AS) com mais de duas
operadores.
● Possui um bloco de ips independente da
operadora utilizada.

34. Topologia final do modeloTopologia final do modelo

35. Dúvidas?Dúvidas?
OBRIGADO!
Marcelo Dieder
marcelodieder@gmail.com