escalando aplicações web: além da arquitetura

Escalando aplicações web

Além da arquitetura

Francisco Souza @franciscosouza

globo .com

what the f**rancisco?!• Desenvolvedor na Globo.com

• Pythonista desde 2008

• PythonBrasil desde 2011

• Open source fanboy

• Desenvolvedor do tsuru

tsuru

• PaaS open source

• Nascido dentro da Globo.com

• Production-ready

Esta não é uma palestra sobre o tsuru


24GB 24GB


1GB 1GB1GB1GB1GB 1GB 1GB 1GB 1GB 1GB 1GB1GB1GB1GB1GB1GB



“Scaling up is failing up” Martin L. Abbott, Michael T. Fisher, 2011

#comofas/

Backing services

“The code for a twelve-factor app makes no distinction between local and third party services. To the app, both are attached resources,

accessed via a URL or other locator/credentials stored in the config.”

http://12factor.net/backing-services

Backing services“The code for a twelve-factor app makes no distinction between local

and third party services. To the app, both are attached resources, accessed via a URL or other locator/credentials stored in the config.”

http://12factor.net/backing-services

Concurrency

“In the twelve-factor app, processes are a first class citizen.

…

The process model truly shines when it comes time to scale out. The share-nothing, horizontally partitionable nature of twelve-factor app

processes means that adding more concurrency is a simple and reliable operation.

http://12factor.net/concurrency

Disposability

The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This

facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys.

http://12factor.net/disposability

Os slides a seguir são uma obra de ficção, qualquer semelhança

com a realidade é mera coincidência…

Um conto de migração

• Uma aplicação fictícia rodava em duas máquinas gigantes

• Uma galera moda jovem decide economizar uma grana e migrar para a “cloud”

Um conto de migração

• Ao invés de 2 máquinas grandes, a aplicação passa a roda em 40 containers

• E aí alguns problemas apareceram…

Cache local

• Memória / workers

• Redis local

• Disco

Solução

• Redis + Sentinel

• Redis Cluster?

Sessão local

• Memória / worker (!!!)

Solução

• Igual solução para o cache :-)

Assets compartilhados

• Arquivos gravados em disco

• Mount points compartilhados entre as máquinas

• Read-only filesystem de tempos em tempos

• Forte dependência de um file server

Solução

• Object storage + CDN

• Amazon S3 + CloudFront

• OpenStack Swift + CDN caseira

Outros problemas

• Logs em arquivos

• Criação, abertura e gerenciamento de arquivos

• Rotacionamento de logs

Facilitando o processo

Menos é mais• Foque no objetivo da aplicação

• Delegue para outras ferramentas funcionalidades importantes que não fazem parte do objeto da aplicação

• Gerenciamento do processo / daemon

• Logs

• Quanto mais simples, mais fácil de escalar

Estado• Tenha o mínimo de estado possível

• Se não há estado, é mais fácil escalar

Na vida real…

Centralize o estado

• Redis

• memcached

• [coloque seu banco de dados chave-valor aqui]

• Banco de dados relacional (muita calma nessa hora)

Cache

• Cache everywhere

“By caching at every level from the browser through the cloud, your network, application servers, and even databases, one can significantly increase

one’s ability to scale”

Martin L. Abbott, Michael T. Fisher, 2011

Cache

• hit pythonbrasil.org.br

github.com/alex/what-happens-when

Quanto tempo?

• O dono do dado deve dizer por quanto tempo ele é válido.

• DNS TTL

• Cache-Control

• Expiração de chaves Redis / memcached

Page Cache

• Um proxy reverso cacheia o resultado

• O dono do dado diz por quanto tempo ele é válido (Cache-Control)

Object cache• Uma página é grande demais

• Páginas podem variar por usuário

• Partes do conteúdo não

• Tempo controlado de acordo com a ferramenta escolhida

• Alternativamente, deixar a ferramenta controlar com LRU

Meça suas página parça

Profiling

• cProfile/profile

• New Relic

• wrk / siege / ab

Automatize• Faça track de mudanças de performance em

servidores de integração contínua

• Use testes automatizados para garantir certos comportamentos e previnir regressões

• Headers de cache

• Object cache: TTL, invalidação manual e automática, etc.


Além da arquitetura

Francisco Souza @franciscosouza slideshare.net/franciscosouza [email protected]

globo .com

escalando aplicações web: além da arquitetura

Software