O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Escalando aplicações web: Além da arquitetura

946 visualizações

Publicada em

Slides da palestra sobre escalabilidade de aplicações web apresentada na PythonBrasil[11] no dia 10 de Novembro de 2015, em São José dos Campos.

Publicada em: Software
  • Seja o primeiro a comentar

Escalando aplicações web: Além da arquitetura

  1. 1. Escalando aplicações web Além da arquitetura Francisco Souza @franciscosouza globo .com
  2. 2. what the f**rancisco?! • Desenvolvedor na Globo.com • Pythonista desde 2008 • PythonBrasil desde 2011 • Open source fanboy • Desenvolvedor do tsuru
  3. 3. tsuru • PaaS open source • Nascido dentro da Globo.com • Production-ready
  4. 4. Esta não é uma palestra sobre o tsuru
  5. 5. Escalando aplicações web 24GB 24GB
  6. 6. Escalando aplicações web 1GB 1GB1GB1GB1GB 1GB 1GB 1GB 1GB 1GB 1GB1GB1GB1GB1GB1GB 1GB 1GB1GB1GB1GB 1GB 1GB 1GB 1GB 1GB 1GB1GB1GB1GB1GB1GB 1GB 1GB1GB1GB1GB 1GB 1GB 1GB 1GB 1GB 1GB1GB1GB1GB1GB1GB
  7. 7. “Scaling up is failing up” Martin L. Abbott, Michael T. Fisher, 2011
  8. 8. #comofas/
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. Os slides a seguir são uma obra de ficção, qualquer semelhança com a realidade é mera coincidência…
  14. 14. 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”
  15. 15. 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…
  16. 16. Cache local • Memória / workers • Redis local • Disco
  17. 17. Solução • Redis + Sentinel • Redis Cluster?
  18. 18. Sessão local • Memória / worker (!!!)
  19. 19. Solução • Igual solução para o cache :-)
  20. 20. 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
  21. 21. Solução • Object storage + CDN • Amazon S3 + CloudFront • OpenStack Swift + CDN caseira
  22. 22. Outros problemas • Logs em arquivos • Criação, abertura e gerenciamento de arquivos • Rotacionamento de logs
  23. 23. Facilitando o processo
  24. 24. 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
  25. 25. Estado • Tenha o mínimo de estado possível • Se não há estado, é mais fácil escalar
  26. 26. Na vida real…
  27. 27. Centralize o estado • Redis • memcached • [coloque seu banco de dados chave-valor aqui] • Banco de dados relacional (muita calma nessa hora)
  28. 28. Cache • Cache everywhere
  29. 29. “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
  30. 30. Cache • hit pythonbrasil.org.br github.com/alex/what-happens-when
  31. 31. Quanto tempo? • O dono do dado deve dizer por quanto tempo ele é válido. • DNS TTL • Cache-Control • Expiração de chaves Redis / memcached
  32. 32. Page Cache • Um proxy reverso cacheia o resultado • O dono do dado diz por quanto tempo ele é válido (Cache-Control)
  33. 33. 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
  34. 34. Meça suas página parça
  35. 35. Profiling • cProfile/profile • New Relic • wrk / siege / ab
  36. 36. 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.
  37. 37. Escalando aplicações web Além da arquitetura Francisco Souza @franciscosouza slideshare.net/franciscosouza f@souza.cc globo .com

×