Building Scalable Applications

Building
scalable
applica/ons

Rachad
Honein

Gerente
de
Engenharia
SaaS
-‐
Locaweb

O
Que
fazemos
no
SaaS?

Webstore

•  ~
3600
lojas
a/vas

•  >
250.000
Page
views
/
dia

•  Picos
de
2500
visitas
a/vas

Google
Analy/cs:
Domingo
6/10/2013
as
13:30

Email
Marke/ng

•  >
32.000
Contas
a/vas

•  Media
de
10.000
contatos
por
conta

•  Contas
com
mais
que
5
Milhões
de
contatos

•  Acima
de
1
Bi
de
envios
por
mês

ANTES
DE
MAIS

NADA…

METODOLOGIAS

ÁGEIS

Scrum

Pair
Programming

Kanban

Stand
up
mee/ngs

Retrospec/ves

Planning

TIMES
DE
2
A
5
DEVS

PARA
CADA
PRODUTO

3
DEPLOYS/SEMANA

POR
PRODUTO

Como
trabalhamos?

Linguagens
de
programação:

–  Ruby

–  Python

–  Lua

–  Go

–  Java

–  Javascript

Como
trabalhamos?

Base
de
dados:

Como
trabalhamos?

Linux:

Debian
Squeeze
/Wheezy

Como
trabalhamos?

Stacks:

Como
trabalhamos?

Organização
=
Produ/vidade

How
to
scale?

Não
poderíamos
jogar
vários
servidores
na

receita
e
resolver
o
problema?

How
to
scale?

Mas
o
que
é
escalabilidade?

Escalabilidade

É
isso:

É
uma
desejável

propriedade
do
sistema

que
indica
a
habilidade
de

suportar
grande

quan/dade
de
trabalho,

ou

facilidade
de

crescimento
quando
há

demanda.

Mas
não
é
isso:

•  Recursos
de
servidor

(2Ghz,
24Gb
Ram
…)

•  Sistema
operacional

(Solaris,
Linux,

windows)

•  Technologia
(
Java
vs

Django
vs
Cake
PHP
vs

Ruby
on
Rails)

Performance
vs
Scalability

Performance

VS

Scalibility

How
to
scale?

Quanto
ao
Solware,
usaríamos
C?

How
to
scale?

Não!

Vamos
usar
PHP,
Ruby
e
Python

How
to
scale?

Mas
PHP,
Ruby
e
Python
não
são
lentos?

How
to
scale?

Isso
não
importa!
São
rápidos
o
suﬁciente.

O
que
importa:
Tempo
de
desenvolvimento

How
to
scale?

• 
• 
• 
• 
• 
• 
• 

O
que
desejamos?

Escalabilidade

Alta
disponibilidade

Performance

Gerenciamento

Custo
mais
baixo
(o/mização)

Muitas
funcionalidades

Gerar
receita
$$$$

How
to
scale?

Verdade
#1:

Seu
sistema
não
vai
escalar
se
não
foi

desenhado
para
escalar

How
to
scale?

Verdade
#2:

Mesmo
se
for
desenhado
para
escalar,
vai
doer!

Quase
sempre

Caso
de
uso:
Um
produto
de
muito
sucesso

Fases
de
crescimento

Fase
1:
Boostrapping
–
The
happy
beginning

Fase
1:
Boostrapping
–
The
happy
beginning

•  Arquitetura
simples:

–  Firewall
+
Load
Balancer
(F5,
LVS,
HaProxy
…)

–  Alguns
servidores
web

–  Base
de
dados

–  Storage

•  Complexidade
baixa

•  Risco
baixo

•  Não
tem
muita
redundância,
custo
operacional

baixo
=>
Melhor
cenário
para
Startups
em
geral

Load
Balancer

Internet

Fase
1:
Boostrapping
–
The
happy
beginning

WebServers

Database

Storage

Success:
O
négocio
está
dando
certo,
gerando

receita

Risco
não
é
mais
uma
opção

Fase
2:
O
mesmo,
mas
começando
a
crescer

•  Mais
redundâncias

–  Mais
Servidores
Web

–  Mais
Load
Balancers

–  Replicação
de
Base
de
dados

•  Ainda
simples
de
ponto
de
vista
Aplicação

–  A
aplicação
con/nua
a
mesma,
é
só
infra

Fase
2:
O
mesmo,
mas
começando
a
crescer

Load
Balancer

Internet

Slave

WebServers

Master

Database

Storage

Publicidade

– Google
Ads

– Ar/gos
nas
revistas

– Eventos
de
patrocino

Fase
3:
A
dor
começou

•  Mais
redundâncias
ainda!

–  Servidor
de
Varnish

–  Mais
o/mização
no
banco

–  Mais
redondância
no
banco

•  Necessário
mexer
na
aplicação

–  Servidor
de
sessão

–  Mais
Cache

=>
mais
cache
para
invalidar
direito

Fase
3:
A
dor
começou

Memcached/Redis

Load
Balancer

Internet

Slaves

Database

Varnish

WebServers

SSD

Sta/c
Files

Storage

Fase
3:
A
dor
começou

Gerenciar
está
mais
complexo
e
mais

dolorido!

Produto
de
sucesso

Muitas
assinaturas

Churn
Baixo

Mais
Inves/mento
=
Mais
Publicidade

Entrevista
dos
founders
na
TV

Mais
Google
Ads

Mais
Eventos
de
patrocino

Fase
4:
Está
doendo
mais
ainda!

•  Ainda
mais
cache

–  Clusters
Memcached,
Redis
e
outros

•  Replicação
não
funciona

para
tudo

–  Replicação
leva
muito
tempo
(slaves
replicam

devagar)

–  Isola
escrita
da
leitura

•  “Database
par//oning”
salva
o
dia

–  Algumas
das
funcionalidades
tem
os
próprios
bancos

•  Repensar
na
modelagem
da
base
de
dados

–  “Denormalizar"
a
modelagem

Fase
4:
Está
doendo
mais
ainda!

Repensar
o
código
para
suportar
toda
essa
loucura

–  Devs
nunca
ﬁzeram
isso
antes

–  Google
não
tem
resposta

–  StackOverﬂow
também

Fase
4:
Está
doendo
mais
ainda!

Clusters

Memcached/Redis

Load
Balancer

Internet

Reads
Cluster

Varnish

Cluster

WebServers

Writes

Cluster

SSD

Sta/c
Files

SSD

Storage
Cluster

Produto
de
sucesso

Muitas
assinaturas
VS
Churn
Baixo

Mais
Inves/mento
=
Mais
Publicidade

Spot
no
fantás/co

Mais
Google
Ads

Está
bombando
de
assinaturas.

Fase
5:
Pânico!

•  Alguém
pode
nos
ajudar???

•  Por
que
não
ﬁzemos
isso
na
fase
de
desenho

da
arquitetura?

•  Criar
clusters
por
usuários

–  Divide
and
Conquer

–  Baseado
em
grupos
de
usuários,
criar
ambientes

totalmente
separados

•  Smart
rou/ng
para
saber
onde
cada
usuário

está

Fase
5:
Swimlane

Internet

Redis

Smart
Router

Usuários
com

Login
de
A
a
C

Usuários
com

Login
de
D
a
F

Usuários
com

Login
de
G
a
I

Fase
6:
Está
melhorando!

•  Aplicação
escalável

•  Performance
desejável

•  Agora
podemos
retomar
o
desenvolvimento

de
novos
features

•  O/mização
de
código
e
refatoração

•  Ainda
crescendo,
mas
gerenciável

Fase
7:
O
futuro
é
o
horizonte!

Se
sobrevivemos
até
aqui,

provavelmente
nós
vamos

sobreviver
pra
sempre!
Ou

não
…

Bônus

• 
• 
• 
• 
• 
• 

Envio
de
emails
é
sempre
assíncrono

MongoDB
é
caro!
Nosso
mente
é
relacional

Redis
é
seu
amigo
mais
ﬁel

Memcached
também

Usem
NewRelic
em
produção

Usem
Conﬁgura/on
Management

–  Chef

–  Puppet

–  CF
Engine

•  Nunca
servem
imagens
pela
VM!
Usem
CDN,
Varnish
com
storage,

S3,
CloudFront

•  Divide
sua
aplicação
em
várias
aplicações

•  Nginx
+
Lua
Module
=
Smart
Rou/ng
made
easy

Obrigado

PERGUNTAS?

Email:
rachad.honein@gmail.com

Twi•er:
@racx

Building Scalable Applications

Mais conteúdo relacionado

Mais procurados

Semelhante a Building Scalable Applications

Building Scalable Applications