De 1 a 1.000.00 de usuários
2 gostaram437 visualizações
O documento apresenta uma visão abrangente sobre escalabilidade e arquitetura de aplicações, destacando a importância de entender os conceitos por trás das ferramentas utilizadas, em vez de simplesmente adotá-las. Sugere iniciar com soluções maduras e escaláveis, enfatizando o papel crítico do cache e a estrutura de dados relacional antes de considerar NoSQL. Além disso, discute a colaboração entre desenvolvimento e operações, propondo práticas como services-oriented architecture e microserviços para sistemas com alta demanda de usuários.
Mais conteúdo relacionado
![Melhorando o desempenho do seu WordPress [WordCamp Porto Alegre 2015]](https://cdn.slidesharecdn.com/ss_thumbnails/wordcampportoalegre2015-151113143626-lva1-app6892-thumbnail.jpg?width=560&fit=bounds)
Semelhante a De 1 a 1.000.00 de usuários (20)
De 1 a 1.000.00 de usuários
- 1. De 1 a 1.000.000 de usuários
- 2. Felipe Klerk Signorini DevOps - ativo.com ● Arquiteto de software ● Infra estrutura ● Desenvolvimento.
- 6. Não seja o programador StackOverflow
- 7. "Aqui as coisas sempre funcionaram assim..." Cultura e conhecimento
- 9. Para os primeiros milhões de usuários a linguagem não importa.
- 10. Não importa a ferramenta ➔ Estude os conceitos, o porque aquela ferramenta foi feita. ➔ Aplicação e servidores andam juntos ➔ Se questione o porque utiliza determinadas ferramentas. ➔ Pense primeiro na arquitetura e por último em quais ferramentas utilizar ➔ A capacidade em visualizar o todo impacta direto na escalabilidade do sistema
- 11. "Meoo coloca um MongoDB que sua aplicação vai voar" NoSQL, você realmente precisa?
- 12. Começe com um banco relacional ➔ Tecnologias maduras e estáveis ➔ Documentação e comunidade ➔ Ferramentas de mercado Sistema de monitoramento, análises, forks e afins ➔ Se bem estruturado seu banco relacional dará conta dos seus primeiros milhões de usuários. ➔ Sua estrutura de dados normalmente é relacional
- 13. Quando pensar em NoSQL ➔ Sua estrutura de dados é baseado em meta dados ➔ Base sem esquema ➔ Massiva quantidade de dados (TB`s) ➔ Massiva quantidade de registros (muitos mesmos)
- 14. "Isso não é minha responsabilidade." Arquitetura de aplicações
- 15. Arquitetura? Infraestrutura Como as máquinas se relacionam, banco de dados, serviços, sistema de cache, firewall e afins. “Contanization”, “Infra is code”, “LoadBalances/AutoScaling” Serviços Como os aplicativos se comunicam, relação entre gateways, APIs, sistemas e afins. “ESB”, “Microservices”, “monoliticos” Aplicativo Estrutura em nível de aplicação, como as classes e funções se relacionam. “OOP”, “Design Pattern”
- 16. "O problema está no servidor." Escalabilidade é responsabilidade da Infra?
- 18. 1 Usuário
- 20. Apache/PHP e DB
- 21. >10 Usuários
- 22. Escalabilidade? 4 GBs 1 CPU 8 GBs 2 CPUs 16 GBs 4 CPUS 2 GBs ● Consiste em aumentar o poder computacional ● Exige downtime do aplicativo ● Muito caro ● Haverá um limite
- 23. Escalabilidade ? 4 GBs 1 CPU 4 GBs 1 CPU 4 GBs 1 CPU ● Mais barato que a escalabilidade vertical ● Garante failbacks no aplicativo ● SOA ● Alta disponibilidade ● A longo prazo se torna o único caminho
- 25. >100 Usuários
- 26. Cache Guardar algo temporáriamente para uso posterior
- 27. ● Aumenta a performance da aplicação ● Diminui gastos em recursos computacionais ● Aumenta o uso de IO (file cache) ● Considero o cache o item mais importante para começar a escalar a aplicação
- 28. HTTP Cache - App Routes Controller DataBase View MIddleware
- 29. HTTP Cache - App Routes Controller DataBase View MIddleware Cache
- 30. View Object Cache - View Render Controller View Object Render View Object Render
- 31. View Object Cache - View Render Controller View Object Render View Object Render Cache
- 32. Model Cache - Models Database Controller Model Database
- 33. Model Cache - Models Database Controller Model Database Cache
- 34. get_file_contents Cache - Request HTTP Controller get_file_contents HTTP Controller
- 35. get_file_contents Cache - Request HTTP Controller get_file_contents HTTP Controller Cache
- 39. Cache - Memoria
- 40. PHP/Script Cache - OpCache Parser Compile Execute OutPut
- 41. PHP/Script Cache - OpCache Parser Execute OutPut Compile
- 42. Cache - Nginx HTTP Routes Controller DataBase View MIddleware
- 43. Cache - Nginx HTTP Routes Controller DataBase View MIddleware Cache
- 44. Cache - Nginx
- 45. Replica Banco "não" escala, mais existe opções.
- 46. MySQL - Replica App Master ReplicaEscrita Escrita Leitura
- 48. Existe a possibilidade da criação de clusters, e/ou utilização de técnicas de sharding data, porém ainda não é o momento
- 50. >1000 Usuários
- 51. Concorrência Agora sim vamos falar de LoadBalances e AutoScaling.
- 54. Entenda que cada máquina deve ser Stateless, não pode conter nenhuma informação vital. ● Uploads de arquivos ● Sessões do php ● Logs
- 59. Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such as Memcached or Redis
- 61. session_drive=memcached session.save_handler = memcache session.save_path = tcp://10.1.1.1:11211'
- 62. Sessões
- 64. Logs - ELK - Stack
- 65. Logs
- 66. AutoScaling Crescimento e redução automática de clusters.
- 68. Autscaling
- 69. Indexação Resultados de buscas, listagem de dados, seleção de dados de forma geral.
- 71. nginx/php+fpm LoadBalance MasterReplica nginx/php+fpmstorage Servidores de busca MC Elastic Search
- 73. Topologia
- 74. DevOps DevOps is a new term emerging from the collision of two major related trends. The first was also called “agile system administration” or “agile operations”; it sprang from applying newer Agile and Lean approaches to operations work. The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world. -Ernest Mueller, Aug 2, 2010 – Last Revised Jan 16, 2016
- 75. nginx/php+fpm LoadBalance Master nginx/php+fpmstorage MC Elastic Search nginx/php+fpm Replica Replica
- 76. nginx/php+fpm LoadBalance Master nginx/php+fpmCDN MC Elastic Search nginx/php+fpm Replica Replica storage
- 77. nginx/php+fpm LoadBalance Master nginx/php+fpmCDN MC Elastic Search nginx/php+fpm Replica Replica storage Elastic Search Elastic Search
- 78. nginx/php+fpm LoadBalance Master nginx/php+fpmCDN MC Elastic Search nginx/php+fpm Replica Replica storage Elastic Search Elastic SearchMC MC
- 83. SOA na prática ➔ Serviços por módulos independentes ➔ Administrados e escalados independentemente ➔ Flexibilidade e entendimento de cada função ➔ Automatizar processos operacionais ➔ SOA + Modularização = Agilidade
- 85. MicroServices
- 86. LoadBalance Route 53 LoadBalance nginx/php+fpm nginx/php+fpm nginx/php+fpm nginx/php+fpm LoadBalance Master Replica Replica LBs, LBs e LBs
- 88. Brokers
- 89. RabbitMq Worker - P API Pedidos Pagamento - Adquirente Checkout Ativo - Checkout Ativo - Cielo - Redes - Stone RabbitMq Cielo Redes Stone Trap Gateway - Cielo API - Redis Redis 1 - Teste de Cartão de crédito Processo de pagamento FailBack Entre as adquirentes Status de processo Cielo Redes Stone API Users Consulta existência do cartão API Geradores
- 90. nginx/php+fpm LoadBalance Master nginx/php+fpmCDN MC Elastic Search nginx/php+fpm Replica Replica storage Elastic Search Elastic SearchMC MC Worker Worker Worker Worker RabbitMQ Worker Worker Worker Worker RabbitMQ Worker Worker RabbitMQ