How to build sustainable and scalable SaaS applications.

1. Building
scalable
applica/ons
Rachad
Honein
Gerente
de
Engenharia
SaaS
-­‐
Locaweb

2. O
Que
fazemos
no
SaaS?

3. 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

4. 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

5. COMO
ESCALAMOS?

6. ANTES
DE
MAIS
NADA…

7. COMO
TRABALHAMOS?

8. METODOLOGIAS
ÁGEIS
Scrum
Pair
Programming
Kanban
Stand
up
mee/ngs
Retrospec/ves
Planning

9. TIMES
DE
2
A
5
DEVS
PARA
CADA
PRODUTO

10. 3
DEPLOYS/SEMANA
POR
PRODUTO

11. Como
trabalhamos?
Linguagens
de
programação:
– Ruby
– Python
– Lua
– Go
– Java
– Javascript

12. Como
trabalhamos?
Base
de
dados:

13. Como
trabalhamos?
Linux:
Debian
Squeeze
/Wheezy

14. Como
trabalhamos?
Stacks:

15. Como
trabalhamos?
Organização
=
Produ/vidade

16. But
HOW
TO
SCALE?

17. How
to
scale?
Não
poderíamos
jogar
vários
servidores
na
receita
e
resolver
o
problema?

18. How
to
scale?
Mas
o
que
é
escalabilidade?

19. 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)

20. Performance
vs
Scalability

21. Performance
VS
Scalibility

22. How
to
scale?
Quanto
ao
Solware,
usaríamos
C?

23. How
to
scale?
Não!
Vamos
usar
PHP,
Ruby
e
Python

24. How
to
scale?
Mas
PHP,
Ruby
e
Python
não
são
lentos?

25. How
to
scale?
Isso
não
importa!
São
rápidos
o
suficiente.
O
que
importa:
Tempo
de
desenvolvimento

26. How
to
scale?
•
•
•
•
•
•
•
O
que
desejamos?
Escalabilidade
Alta
disponibilidade
Performance
Gerenciamento
Custo
mais
baixo
(o/mização)
Muitas
funcionalidades
Gerar
receita
$$$$

27. How
to
scale?
Verdade
#1:
Seu
sistema
não
vai
escalar
se
não
foi
desenhado
para
escalar

28. How
to
scale?
Verdade
#2:
Mesmo
se
for
desenhado
para
escalar,
vai
doer!
Quase
sempre

29. Caso
de
uso:
Um
produto
de
muito
sucesso
Fases
de
crescimento

30. Fase
1:
Boostrapping
–
The
happy
beginning

31. 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

32. Load
Balancer
Internet
Fase
1:
Boostrapping
–
The
happy
beginning
WebServers
Database
Storage

33. Success:
O
négocio
está
dando
certo,
gerando
receita
Risco
não
é
mais
uma
opção

34. 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

35. Fase
2:
O
mesmo,
mas
começando
a
crescer
Load
Balancer
Internet
Slave
WebServers
Master
Database
Storage

36. Publicidade
– Google
Ads
– Ar/gos
nas
revistas
– Eventos
de
patrocino

37. 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

38. Fase
3:
A
dor
começou
Memcached/Redis
Load
Balancer
Internet
Slaves
Database
Varnish
WebServers
SSD
Sta/c
Files
Storage

39. Fase
3:
A
dor
começou
Gerenciar
está
mais
complexo
e
mais
dolorido!

40. Produto
de
sucesso
Muitas
assinaturas
Churn
Baixo
Mais
Inves/mento
=
Mais
Publicidade
Entrevista
dos
founders
na
TV
Mais
Google
Ads
Mais
Eventos
de
patrocino

41. 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

42. Fase
4:
Está
doendo
mais
ainda!
Repensar
o
código
para
suportar
toda
essa
loucura
– Devs
nunca
fizeram
isso
antes
– Google
não
tem
resposta
– StackOverflow
também

43. 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

44. Produto
de
sucesso
Muitas
assinaturas
VS
Churn
Baixo
Mais
Inves/mento
=
Mais
Publicidade
Spot
no
fantás/co
Mais
Google
Ads

45. Está
bombando
de
assinaturas.

46. Fase
5:
Pânico!
• Alguém
pode
nos
ajudar???
• Por
que
não
fizemos
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á

47. 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

48. 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

49. Fase
7:
O
futuro
é
o
horizonte!
Se
sobrevivemos
até
aqui,
provavelmente
nós
vamos
sobreviver
pra
sempre!
Ou
não
…

50. Bônus
•
•
•
•
•
•
Envio
de
emails
é
sempre
assíncrono
MongoDB
é
caro!
Nosso
mente
é
relacional
Redis
é
seu
amigo
mais
fiel
Memcached
também
Usem
NewRelic
em
produção
Usem
Configura/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

51. Obrigado
PERGUNTAS?
Email:
rachad.honein@gmail.com
Twi•er:
@racx