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	
  25...
Email	
  Marke/ng	
  
•  >	
  32.000	
  Contas	
  a/vas	
  
•  Media	
  de	
  10.000	
  contatos	
  por	
  conta	
  
•  Co...
COMO	
  ESCALAMOS?	
  
ANTES	
  DE	
  MAIS	
  
NADA…	
  
COMO	
  
TRABALHAMOS?	
  
METODOLOGIAS	
  	
  ÁGEIS	
  
Scrum	
  
Pair	
  Programming	
  
Kanban	
  

Stand	
  up	
  mee/ngs	
  
Retrospec/ves	
  
P...
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...
Como	
  trabalhamos?	
  
Base	
  de	
  dados:	
  
Como	
  trabalhamos?	
  
Linux:	
  
	
  
	
  

Debian	
  Squeeze	
  /Wheezy	
  
Como	
  trabalhamos?	
  
Stacks:	
  
	
  
	
  
Como	
  trabalhamos?	
  
Organização	
  =	
  Produ/vidade	
  
	
  
	
  
But	
  
HOW	
  TO	
  SCALE?	
  
How	
  to	
  scale?	
  
Não	
  poderíamos	
  jogar	
  vários	
  servidores	
  na	
  
receita	
  e	
  resolver	
  o	
  prob...
How	
  to	
  scale?	
  

	
  
	
  Mas	
  o	
  que	
  é	
  escalabilidade?	
  
Escalabilidade	
  
É	
  isso:	
  
	
  
É	
  uma	
  desejável	
  
propriedade	
  do	
  sistema	
  
que	
  indica	
  a	
  ha...
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	
  suficiente.	
  
	
  
	
  
O	
  que	
  i...
How	
  to	
  scale?	
  

• 
• 
• 
• 
• 
• 
• 
	
  

O	
  que	
  desejamos?	
  
	
  
Escalabilidade	
  
Alta	
  disponibili...
How	
  to	
  scale?	
  
Verdade	
  #1:	
  
Seu	
  sistema	
  não	
  vai	
  escalar	
  se	
  não	
  foi	
  
desenhado	
  pa...
How	
  to	
  scale?	
  
Verdade	
  #2:	
  
Mesmo	
  se	
  for	
  desenhado	
  para	
  escalar,	
  vai	
  doer!	
  

Quase	...
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	
  +	
  L...
Load	
  Balancer	
  

Internet	
  

Fase	
  1:	
  Boostrapping	
  –	
  The	
  happy	
  beginning	
  
	
  

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

	
  

Risco	
  não	
  é	
  mais	
  uma...
Fase	
  2:	
  O	
  mesmo,	
  mas	
  começando	
  a	
  crescer	
  
	
  
•  Mais	
  redundâncias	
  
–  Mais	
  Servidores	
...
Fase	
  2:	
  O	
  mesmo,	
  mas	
  começando	
  a	
  crescer	
  
	
  

Load	
  Balancer	
  

Internet	
  

Slave	
  

Web...
Publicidade	
  
	
  
	
  
– Google	
  Ads	
  
– Ar/gos	
  nas	
  revistas	
  
– Eventos	
  de	
  patrocino	
  
Fase	
  3:	
  A	
  dor	
  começou	
  
	
  
•  Mais	
  redundâncias	
  ainda!	
  
–  Servidor	
  de	
  Varnish	
  
–  Mais	...
Fase	
  3:	
  A	
  dor	
  começou	
  
	
  
Memcached/Redis	
  

Load	
  Balancer	
  

Internet	
  

Slaves	
  

Database	
...
Fase	
  3:	
  A	
  dor	
  começou	
  
	
  

Gerenciar	
  está	
  mais	
  complexo	
  e	
  mais	
  
dolorido!	
  
Produto	
  de	
  sucesso	
  
	
  
Muitas	
  assinaturas	
  
Churn	
  Baixo	
  
Mais	
  Inves/mento	
  =	
  Mais	
  Publici...
Fase	
  4:	
  Está	
  doendo	
  mais	
  ainda!	
  
	
  

•  Ainda	
  mais	
  cache	
  

–  Clusters	
  Memcached,	
  Redis...
Fase	
  4:	
  Está	
  doendo	
  mais	
  ainda!	
  
	
  

Repensar	
  o	
  código	
  para	
  suportar	
  toda	
  essa	
  lo...
Fase	
  4:	
  Está	
  doendo	
  mais	
  ainda!	
  
	
  
Clusters	
  
Memcached/Redis	
  

Load	
  Balancer	
  

Internet	
...
Produto	
  de	
  sucesso	
  
	
  
Muitas	
  assinaturas	
  VS	
  Churn	
  Baixo	
  

Mais	
  Inves/mento	
  =	
  Mais	
  P...
Está	
  bombando	
  de	
  assinaturas.	
  	
  
	
  
Fase	
  5:	
  Pânico!	
  
	
  
•  Alguém	
  pode	
  nos	
  ajudar???	
  
•  Por	
  que	
  não	
  fizemos	
  isso	
  na	
  f...
Fase	
  5:	
  Swimlane	
  
	
  

Internet	
  

Redis	
  

Smart	
  Router	
  

Usuários	
  com	
  
Login	
  de	
  A	
  a	
...
Fase	
  6:	
  Está	
  melhorando!	
  
	
  
•  Aplicação	
  escalável	
  
•  Performance	
  desejável	
  
•  Agora	
  podem...
Fase	
  7:	
  O	
  futuro	
  é	
  o	
  horizonte!	
  
	
  

	
  

Se	
  sobrevivemos	
  até	
  aqui,	
  
provavelmente	
  ...
Bônus	
  
• 
• 
• 
• 
• 
• 

Envio	
  de	
  emails	
  é	
  sempre	
  assíncrono	
  
MongoDB	
  é	
  caro!	
  Nosso	
  ment...
Obrigado	
  
PERGUNTAS?	
  
Email:	
  rachad.honein@gmail.com

	
  Twi•er:	
  @racx	
  
Próximos SlideShares
Carregando em…5
×

Building Scalable Applications

9.228 visualizações

Publicada em

How to build sustainable and scalable SaaS applications.

Publicada em: Tecnologia
0 comentários
3 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
9.228
No SlideShare
0
A partir de incorporações
0
Número de incorporações
8.420
Ações
Compartilhamentos
0
Downloads
19
Comentários
0
Gostaram
3
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Building Scalable Applications

  1. 1. Building  scalable  applica/ons   Rachad  Honein   Gerente  de  Engenharia  SaaS  -­‐  Locaweb  
  2. 2. O  Que  fazemos  no  SaaS?  
  3. 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. 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. 5. COMO  ESCALAMOS?  
  6. 6. ANTES  DE  MAIS   NADA…  
  7. 7. COMO   TRABALHAMOS?  
  8. 8. METODOLOGIAS    ÁGEIS   Scrum   Pair  Programming   Kanban   Stand  up  mee/ngs   Retrospec/ves   Planning  
  9. 9. TIMES  DE  2  A  5  DEVS   PARA  CADA  PRODUTO  
  10. 10. 3  DEPLOYS/SEMANA   POR  PRODUTO  
  11. 11. Como  trabalhamos?   Linguagens  de  programação:     –  Ruby   –  Python   –  Lua   –  Go   –  Java     –  Javascript  
  12. 12. Como  trabalhamos?   Base  de  dados:  
  13. 13. Como  trabalhamos?   Linux:       Debian  Squeeze  /Wheezy  
  14. 14. Como  trabalhamos?   Stacks:      
  15. 15. Como  trabalhamos?   Organização  =  Produ/vidade      
  16. 16. But   HOW  TO  SCALE?  
  17. 17. How  to  scale?   Não  poderíamos  jogar  vários  servidores  na   receita  e  resolver  o  problema?      
  18. 18. How  to  scale?      Mas  o  que  é  escalabilidade?  
  19. 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. 20. Performance  vs  Scalability      
  21. 21. Performance   VS   Scalibility  
  22. 22. How  to  scale?         Quanto  ao  Solware,  usaríamos  C?      
  23. 23. How  to  scale?                 Não!     Vamos  usar  PHP,  Ruby  e  Python  
  24. 24. How  to  scale?                 Mas  PHP,  Ruby  e  Python  não  são  lentos?  
  25. 25. How  to  scale?       Isso  não  importa!  São  rápidos  o  suficiente.       O  que  importa:  Tempo  de  desenvolvimento  
  26. 26. How  to  scale?   •  •  •  •  •  •  •    O  que  desejamos?     Escalabilidade   Alta  disponibilidade   Performance   Gerenciamento   Custo  mais  baixo  (o/mização)   Muitas  funcionalidades   Gerar  receita  $$$$  
  27. 27. How  to  scale?   Verdade  #1:   Seu  sistema  não  vai  escalar  se  não  foi   desenhado  para  escalar  
  28. 28. How  to  scale?   Verdade  #2:   Mesmo  se  for  desenhado  para  escalar,  vai  doer!   Quase  sempre  
  29. 29. Caso  de  uso:  Um  produto  de  muito  sucesso   Fases  de  crescimento  
  30. 30. Fase  1:  Boostrapping  –  The  happy  beginning    
  31. 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. 32. Load  Balancer   Internet   Fase  1:  Boostrapping  –  The  happy  beginning     WebServers   Database   Storage  
  33. 33. Success:  O  négocio  está  dando  certo,  gerando   receita       Risco  não  é  mais  uma  opção  
  34. 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. 35. Fase  2:  O  mesmo,  mas  começando  a  crescer     Load  Balancer   Internet   Slave   WebServers   Master   Database   Storage  
  36. 36. Publicidade       – Google  Ads   – Ar/gos  nas  revistas   – Eventos  de  patrocino  
  37. 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. 38. Fase  3:  A  dor  começou     Memcached/Redis   Load  Balancer   Internet   Slaves   Database   Varnish   WebServers   SSD   Sta/c  Files   Storage  
  39. 39. Fase  3:  A  dor  começou     Gerenciar  está  mais  complexo  e  mais   dolorido!  
  40. 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. 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. 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. 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. 44. Produto  de  sucesso     Muitas  assinaturas  VS  Churn  Baixo   Mais  Inves/mento  =  Mais  Publicidade     Spot  no  fantás/co   Mais  Google  Ads  
  45. 45. Está  bombando  de  assinaturas.      
  46. 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. 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. 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. 49. Fase  7:  O  futuro  é  o  horizonte!       Se  sobrevivemos  até  aqui,   provavelmente  nós  vamos   sobreviver  pra  sempre!  Ou   não  …  
  50. 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. 51. Obrigado   PERGUNTAS?   Email:  rachad.honein@gmail.com  Twi•er:  @racx  

×