building scalable applications
DESCRIPTION
How to build sustainable and scalable SaaS applications.TRANSCRIPT
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
COMO ESCALAMOS?
ANTES DE MAIS NADA…
COMO TRABALHAMOS?
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?
But
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 suficiente.
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
• 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
Fase 1: Boostrapping – The happy beginning
Load Balancer
WebServers
Storage
Database
Internet
Fase 1: Boostrapping – The happy beginning
Success: O négocio está dando certo, gerando receita
Risco não é mais uma opção
• 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
WebServers
Storage
Database Internet
Master
Slave
Fase 2: O mesmo, mas começando a crescer
– Google Ads
– Ar/gos nas revistas
– Eventos de patrocino
Publicidade
• 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
Load Balancer
WebServers
Memcached/Redis
Sta/c Files
Varnish
Storage
Internet
Database
Slaves
SSD
Fase 3: A dor começou
Gerenciar está mais complexo e mais dolorido!
Fase 3: A dor começou
Muitas assinaturas Churn Baixo
Produto de sucesso
Entrevista dos founders na TV Mais Google Ads Mais Eventos de patrocino
Mais Inves/mento = Mais Publicidade
• 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 fizeram isso antes
– Google não tem resposta
– StackOverflow também
Fase 4: Está doendo mais ainda!
Load Balancer
WebServers
Clusters Memcached/Redis
Sta/c Files
Varnish Cluster
Storage Cluster
Internet
Writes Cluster
Reads Cluster
SSD
SSD
Fase 4: Está doendo mais ainda!
Muitas assinaturas VS Churn Baixo
Produto de sucesso
Spot no fantás/co Mais Google Ads
Mais Inves/mento = Mais Publicidade
Está bombando de assinaturas.
• 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á
Fase 5: Pânico!
Usuários com Login de A a C
Internet
Usuários com Login de D a F
Usuários com Login de G a I
Smart Router
Redis
Fase 5: Swimlane
• 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 6: Está melhorando!
Se sobrevivemos até aqui, provavelmente nós vamos sobreviver pra sempre! Ou não …
Fase 7: O futuro é o horizonte!
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
