Arquitetando aplicações escaláveis e resilientes com PHP

Transcript

1. Arquitetando aplicações escaláveis e resilientes com PHP
2. “CENSO POPULACIONAL” Só pra conhecer vocês um pouco
3. Gus Antoniassi Infrastructure Engineer na Mandic Cloud Solutions “Ex” web dev, agora DevOps Experiência com o desenvolvimento do e-commerce Gazin Atacado - Hospedado na AWS, infra auto-escalável linkedin.com/in/gus-antoniassi $~ whoami
4. O que é “escalar”?
5. - Escalabilidade - Escalar - Exemplos: Black Friday, promoções, horário comercial O que é “escalar”?
8. Startups Crescimento exponencial
9. Escala vertical vs horizontal Escala Vertical = Upgrade nos recursos Escala Horizontal = Adicionar mais recursos
10. Escala vertical vs horizontal
11. Escala vertical vs horizontal
12. Qual é melhor? Custo benefício - Escala horizontal vence - Comprar um processador poderoso é mais caro do que comprar vários processadores ordinários - Intel Xeon E7-2860, 2.26 GHz c/ 10 cores => $ 17.000 ou R$ 67.630,25 - 5 processadores Intel Core i7-6600U, 2.6 GHz, 2 cores cada => $ 400 x 5 = $ 2000 ou R$ 7.956,50 - $ 15.000 ou R$ 59.673,75 de diferença Fonte: Horizontal vs Vertical Scaling - Pudgy Logic (2016) Cotação USD: $1 = R$ 3,98 (24/04 - Google Finance)
13. Qual é melhor? Custo benefício - Quando se trata de Cloud, você só paga pelo tempo que usar - Exemplo: iFood - Compensa muito mais usar umas 10.000 máquinas medianas durante os horários de pico (almoço e janta) do que umas 1.000 máquinas top durante 24 horas
14. Qual é melhor? Tolerância a falhas e disponibilidade - Escala horizontal vence - Quanto mais servidores redundantes em um sistema, melhor a disponibilidade - Se der qualquer problema de rede no seu servidor top super ultra mega blaster de $ 200.000, sua aplicação para - Múltiplas zonas de disponibilidade (AZs) - Eliminar o “ponto único de falha” Fonte: Horizontal vs Vertical Scaling - Pudgy Logic (2016)
15. Qual é melhor? Tolerância a falhas e disponibilidade
16. Qual é melhor? Complexidade do sistema - Escala vertical vence - Dificuldades: - Sua aplicação pode estar sendo executada em qualquer um dos múltiplos servidores - Necessidade de uma camada a mais (Load balancer) - “Entrega” do código no servidor
17. Escala automática (Autoscaling)
18. ◦ Aumentar (ou diminuir) sua infra automaticamente, baseada no uso ◦ Possibilitado com o conceito de Cloud Computing Autoscaling
19. Capa- cidade Dia da semana Dom Seg Ter Qua Qui Sex Sáb O problema: (melhor cenário)
20. Capa- cidade Dia da semana Dom Seg Ter Qua Qui Sex Sáb (pior cenário)
21. Capa- cidade usada Dia da semana Autoscaling ajusta a capacidade conforme necessário Dom Seg Ter Qua Qui Sex Sáb Introduzindo o AutoScaling:
22. Dom Seg Ter Qua Qui Sex Sáb
23. Capa- cidade usada Dia da semana R$ 6,00 R$ 6,00 R$ 6,00 R$ 6,00 R$ 6,00 R$ 6,00 R$ 6,00 = R$ 42,00 Dom Seg Ter Qua Qui Sex Sáb
24. Capa- cidade usada Dia da semana R$ 2,00 R$ 4,00 R$ 4,00 R$ 6,00 R$ 6,00 R$ 6,00 R$ 2,00 1 inst. 2 inst. 3 inst. = R$ 30,00 -R$ 12,00/s Dom Seg Ter Qua Qui Sex Sáb
25. ◦ Quando a escala é feita?? ◦ Métricas ▫ CPU ▫ Memória ▫ Disco (espaço e leitura/escrita) ▫ Pacotes de rede Autoscaling
26. Como os múltiplos servidores são gerenciados?
27. Load balancing
30. Load Balancer
31. Load Balancer Servidores
32. Load Balancer Servidores Clientes
33. Servidor 4 parou de funcionar
34. Load balancer “arrumou” o servidor e voltou a servir as requisições
35. Hardware-based Load Balancing - Como fazer?
36. Cloud-based ou “as a Service” ◦ Amazon Elastic Load Balancer (ELB) ◦ Google Cloud Load Balancing ◦ Microsoft Azure Load Balancer Load Balancing - Como fazer?
37. Software-based ◦ HAProxy ◦ Traefik ◦ NGINX / NGINX Plus ◦ KEMP Load Balancer Load Balancing - Como fazer?
38. Problemas que aparecem
39. Múltiplos servidores ◦ Estado da aplicação não é compartilhado (ex. Session) ◦ Logs ◦ Cache em arquivos ◦ Uploads Problemas com escala
40. JWT - Token para armazenar dados do usuário, pode substituir o $_SESSION Compartilhando o estado da aplicação
41. { "avatar": "http://placehold.it/32x32", "idade": 23, "nome": "João da Silva", "email": "joao@silva.com" } Compartilhando o estado da aplicação
42. eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ hdmF0YXIiOiJodHRwOi8vcGxhY2Vob2xkLm l0LzMyeDMyIiwiaWRhZGUiOjIzLCJub21lIjoiS m_Do28gZGEgU2lsdmEiLCJlbWFpbCI6Imp vYW9Ac2lsdmEuY29tIn0.oaQaQptR2ctlTVt0 wQ7Qi2rBcjYuqAkkB4AeqolHDvY Compartilhando o estado da aplicação Corpo Cabeçalho Assinatura
43. Alternativa ao JWT - Sticky Sessions - Usuário “freguês”, load balancer redireciona o usuário logado sempre pro mesmo servidor - Introduz mais problemas - Armazenamento chave-valor - Redis e Memcached* * não é ideal pra armazenar sessões pois não garante a persistência dos dados Compartilhando o estado da aplicação
44. Centralizar logs Como você vai abrir os logs de acesso/erro de uma requisição que o Zezinho fez no dia 12 de março às 16:43? Logs - One log to rule them all
45. Soluções - Logstash / Elastic Stack - Datadog - AWS CloudWatch Logs Logs - One log to rule them all
46. CloudWatch Logs
47. Centralizar - Sugestões: Redis e Memcached Cache em arquivos
48. Centralizar - Servidor específico para receber uploads - Amazon S3 / Google Cloud Storage / Azure Blob Storage Uploads
49. Ataques na aplicação podem gerar um alto custo - Definir número máximo de instâncias - Geoblocking - Web Application Firewall (WAF) - Serviços de proteção - CloudFlare - AWS Shield DDoS
50. Outras soluções interessantes
51. - “Separa” partes críticas da aplicação - Ex: serviço de login pode parar, mas o checkout continua funcionando Arquitetura orientada a serviços
52. Kubernetes - Orquestrador de containers - Gerencia escala
53. Function as a Service (FaaS) - Seu código vira uma “função” - Você não sabe em que tipo de servidor ela será executada, isso é feito pelo serviço backend - Plataforma Serverless gerencia as rotas da aplicação (API Gateway) Serverless
54. Meu case triste :( E como sofrer menos com servidores auto-escaláveis
55. Douradina, dia 23 de novembro de 2018, 8h da manhã Depois de muita preparação, configuração de infra escalável e testes de carga... Pré-black friday
56. Pré-black friday
57. “Elo mais fraco” - Banco de dados - API de pagamento - Sistema de cálculo de frete - Servidor de cache - ... Gargalo
58. Banco de dados - Tornar autoescalável - Escala horizontal no dia anterior Gargalo
59. Sistemas externos - Tornar a sua aplicação tolerante a falhas externas - Netflix - Chaos Engineering - “Failure Injection Testing” Gargalo
60. Testes de carga Como sua aplicação vai responder a 100 usuários ativos? E 300? E 1.000? - Encontrar a faixa ideal de usuários e o pico máximo esperado Prevenção
61. Monitoramento e observabilidade Prevenção
62. Testes de carga IMPORTANTE: Testar TODO o sistema, com acesso ao BD, chamadas à API de pagamento, etc - Subir um ambiente de homologação por 1 hora - Ficar 1 hora parado em horário de pico Prevenção
63. Testes de carga IMPORTANTE 2: As aplicações auto-escaláveis tem um “tempo de aquecimento” (warmup time) - Distribuir 1.000 usuários durante 5 minutos Prevenção
64. Ferramentas para teste de carga - Loader.io Prevenção
65. Ferramentas para teste de carga - Apache Benchmark (ab) ab -n 1000 -c 10 http://localhost/ Prevenção
66. Ferramentas para teste de carga - Locust Prevenção
69. Obrigado pela atenção! PERGUNTAS? OPINIÕES? Contato: linkedin.com/in/gus-antoniassi Feedback e slides: bit.ly/phpconf-gus-escala