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

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


Load Balancer

WebServers

Storage

Database

Internet


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


Gerenciar está mais complexo e mais dolorido!


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


Load Balancer

WebServers

Clusters Memcached/Redis

Sta/c Files

Varnish Cluster

Storage Cluster

Internet

Writes Cluster

Reads Cluster

SSD

SSD


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

PERGUNTAS?

Obrigado

Email: [email protected] Twi�er: @racx

Building Scalable Applications

Technology