Baixado 22 vezes
Carregado porAmazon Web Services LATAM
Rodando a BlackFriday do seu eCommerce na nuvem
O documento aborda estratégias para gerenciar e escalar um ecommerce durante a Black Friday na nuvem, enfatizando a importância de escolher a região correta, usar serviços gerenciados e aplicar boas práticas de segurança e escalabilidade. Apresenta o Well Architected Framework como uma ferramenta fundamental para garantir segurança, confiabilidade, desempenho e otimização de custos. Também discute a necessidade de um plano de continuidade, monitoramento eficiente e suporte adequado para o sucesso operacional.
Mais conteúdo relacionado
Semelhante a Rodando a BlackFriday do seu eCommerce na nuvem
Rodando a BlackFriday do seu eCommerce na nuvem
- 1. Rodando a BlackFriday do seu eCommerce na nuvem Felipe Garcia, Arquiteto de Soluções 22 de Agosto de 2016
- 2. Agenda • Arquitetura • Quala melhor região? • Multi AZ vs Multi Região • Serviços Gerenciados vs EC2 • Persistência poliglota • Segurança • Well Architected Framework • Exemplos de Arquitetura
- 3. Agenda • Escalabilidade • Escolhendoa instância correta • Esteja preparado para escalar horizontalmente • Escalando com Auto Scaling e ELB
- 4. Agenda • Disponibilidade • Planode Continuidade • 1,2,3 Testando • Monitoramento • Suporte • Lições Aprendidas
- 5.
- 6. Qual é amelhor região?
- 8. Quais fatores considerarna escolha da região? Conformidade Localidade dos dados Latência Serviços Custos
- 9. Qual é amelhor região? • Certifique-se sobre conformidade e localidade dos dados • Latência, geralmente não é o problema • Utilize o Amazon CloudFront como sua CDN • Testes e testes
- 10. Multi AZ vsMulti Região
- 11.
- 12.
- 13. E aí, MultiAZ ou Multi Região? • Utilizar somente uma AZ é SPoF (Ponto único de falha) • EC2 Multi AZ com SLA de 99,95% • Comece a trabalhar com Multi AZ, mas sempre preparado e pensando em Multi Região • Conheça o serviço que está utilizando • Tenha um plano de continuidade do negócio
- 14.
- 15. Por que usarServiços Gerenciados? • Menos “levantamento de peso não diferenciado”. Menos carga de trabalho na sua equipe. Sua equipe consegue focar na aplicação e na entrega de valor pro negócio. • Utilize ElasticBeanstalk ou Amazon ECS para rodar sua aplicação ou API web, ao invés de manter toda stack você mesmo em servidores EC2. Além disso, ele traz outras funcionalidades para facilitar sua vida com deployment, teste ab, rollback, escalabilidade, etc. • Utilize Elasticache ao invés de seu cache em EC2. Ele trás funcionalidades como cliente com auto discovery para memcached, e réplicas de leitura e failover automático para redis. • Utilize RDS ao invés de seu banco em EC2. Ele oferece backup automático com RPO de 5 minutos, réplicas de leitura, etc.
- 16.
- 17. Na era doBanco de Dados Business Logic Search API Catalog API ReportsCart API Session Banco de Dados (Relacional, NoSql, etc)
- 18. Na era doBanco de Dados Business Logic Search API Catalog API ReportsCart API Session Banco de Dados (Relacional, NoSql, etc)
- 19. Na era dasFerramentas de Busca e Indexação Business Logic Search API Catalog API ReportsCart API Session Ferramenta de Busca (ex: Solr, Elasticsearch, etc)
- 20. Na era dasFerramentas de Busca e Indexação Business Logic Search API Catalog API ReportsCart API Session Ferramenta de Busca (ex: Solr, Elasticsearch, etc)
- 21. When you onlyhave a hammer, everything looks like a nail – Abraham Maslow
- 22. Trabalhando com PersistênciaPoliglota Business Logic Search API Catalog API ReportsCart API Session Amazon DynamoDB Amazon Redshift Amazon ElastiCache Amazon RDS Amazon DynamoDB Amazon Elasticsearch Service
- 23.
- 24. Boas práticas • Protejasua conta da AWS, dentro e fora • Proteja seu perímetro e reduza a superfície de ataque • Mantenha seus sistemas atualizados • Não armazene dados sensíveis. Criptografe dados em descanso, quando necessário • HTTPS em todo lugar. Criptografe dados em trânsito. Utilize o AWS Certificate Manager para criar seus certificados • Conduza auditorias PCI periodicamente • Consulte o AWS Trusted Advisor periodicamente • Utilize o AWS WAF
- 25.
- 26. O que éo Well Architected Framework? • O framework Well Architected é baseado em 4 pilares – segurança, confiabilidade, desempenho eficiente e otimização de custos • Segurança • Habilidade de proteger informação, sistemas, e ativos entregando valor par ao negócio através de avaliações de risco e estratégias de mitigação • Confiabilidade • Habilidade de um sistema se recuperar de problemas de infraestrutura ou serviços, adquirir dinamicamente recursos computacionais para atender a demanda, e mitigar disrupturas de serviço causadas por problemas temporários de rede ou má configuração • Desempenho Eficiente • Habilidade de usar recursos computacionais de maneira eficiente para atender os requisitos do sistema, e manter esta eficiência mesmo com a mudança das demandas e evoluções tecnológicas • Otimização de Custos • Habilidade de evitar ou eliminar custos desnecessários ou recursos sub-utilizados. Referência: http://amzn.to/2bvc8bj
- 27.
- 28.
- 29.
- 30. Sistema de recomendaçãoe campanha de marketing
- 31.
- 32. Escolhendo a instânciacorreta
- 33. Tipos de instância •Propósito Geral • T2 • M1 (geração antiga) • M3 • M4 • Otimizado para CPU (C1, C3, C4) • Otimizado para Memória • M2 (geração antiga) • R3 • X1 • Outros tipos • G2 (GPU) • D2 (I/O Armazenamento denso) • I2 (I/O Alto desempenho)
- 34. Boas práticas • Definasuas métricas de sucesso, e realize testes com diferentes famílias e tipos de instância • Prefira as instâncias da última geração • Para banco de dados, ou workloads que tem I/O intensivo, escolha instâncias que são “EBS Optimized” • Conheça quantos IOPS seu banco de dados precisa. Na maioria das vezes os volumes GP2 dão conta do recado • Se escolher uma instância muito grande estará desperdiçando dinheiro por estar super-provisionado, e se escolher uma instância muito pequena, poderá prejudicar a experiência do usuário final, como também gastar mais dinheiro por ter que escalar mais • Consulte o AWS Trusted Advisor periodicamente
- 35. Esteja preparado paraescalar horizontalmente
- 36. Boas práticas • Construaaplicações web stateless. Se tiver que armazenar estado, armazene em um serviço externo • Se sua aplicação faz upload de arquivos ou serve arquivos estáticos (ex: CSS, JS, Imagens, etc), armazene os mesmos no S3 • Prepare suas instâncias (e containers, caso utilize) para ter o menor tempo de criação possível e beneficiar seu processo de Auto Scaling • Cache • Utilize clientes que aceitem consistent hashing • Utilize réplicas de leitura • Prefira Elasticache a utilizar seu próprio cache em EC2
- 37. Boas práticas • Bancode Dados • Utilize persistência poliglota. Entenda como seu banco de dados escala horizontalmente para escritas e leituras • Nem todos RDMS suportam réplicas de leitura, e a maioria não suporta multi master - e quando suportam, é muito complexo de gerenciar • Prefira RDS ou outros serviços de bancos de dados gerenciados da AWS ao invés de EC2 • Caso seu banco RDBMS não suporte escalar horizontalmente escrita e leitura, delegue essa tarefa para algum proxy reverso como por exemplo, o ScaleArc
- 38. Escalando com AutoScaling e ELB
- 39. Entendendo a demandada sua aplicação
- 40. Provisionando para aconsumo máximo
- 41. Provisionando para oconsumo médio
- 42. Provisionando capacidade sobdemanda
- 43. Exemplo: escalando naprodução
- 44. Boas práticas • Certifique-seque seu ELB está com “Cross Zone Load Balancing” habilitado • Certifique-se que tem pelo menos 2 Availability Zones selecionadas em seu ELB • Configure o timeout do seu ELB para ser maior ou igual ao timeout do das instâncias EC2 que estão recebendo as conexões • Utilize ELB público e mantenha as instâncias EC2 em subnets privadas • O ELB escala muito bem, mas antes de qualquer evento grande, abra um chamado no suporte para avaliar necessidades de pre-warming • Habilite os logs do seu ELB
- 45. Boas práticas • Façascale out mais agressivos, e faça scale in menos agressivos • Configure suas métricas 25% abaixo do desejado para dar tempo para seu ambiente e sua aplicação subirem • Ex: se sua métrica de CPU para scale out é 80%, quando configurar o auto scaling, utilize 60% • Compre instâncias EC2 reservadas para seu consumo médio. • Utilize diferentes Auto Scaling Groups para escalar com On-Demand e Spot para as demandas adicionais • Ex: se sua métrica para scale out é 60% CPU, crie um Auto Scaling Group para instâncias on-demand fazer scale out com 60% de CPU, crie outro Auto Scaling Group para fazer scale out com instâncias spot com 50% de CPU
- 46.
- 47.
- 48. Everything fails allthe time – Werner Voegels
- 49. Planejando a continuidadedo seu negócio • Se ocorrer uma falha • Quanto tempo meu negócio pode ficar for a do ar? • Quanto tempo de dados meu negócio pode perder? • Qual o RTO e o RPO do seu negócio? • Tenha claro quais são os objetivos do negócio e estabeleça o RTO e RPO para então decidir qual a melhor estratégia
- 50. Backup & Restore •Tenha cópias de suas AMIs em outra região • Se estiver utilizando RDS, tenha uma read replica ou cópia do snapshot em outra região • Exercite seu plano de continuidade dos negócios periodicamente para garantir que ele está funcional e que os objetivos de RTO e RPO estão sendo cumpridos
- 51. Pilot Light -Desenho
- 52. Pilot Light -Failover
- 53. Warm Standby -Desenho
- 54. Warm Standby -Failover
- 55. Multi Site -Desenho
- 56. Multi Site -Failover
- 57.
- 58. Por que testar? •Como diz nosso CTO, as coisas falham o tempo todo • Integre os testes de carga unitários em seu processo de CI/CD • Conduza testes de carga estruturados periodicamente em seu workload • Alguns erros só vão acontecer em produção, tente utilizar ferramentas como o Gor para testar seu sistema com dados reais e o Hoverfly para simular hipóteses • Te ajudará a encontrar e refinar suas métricas
- 59. Frameworks e ferramentaspara testes estruturados • Apache JMeter (free) - http://jmeter.apache.org/ • Java/XML/Javascript • Locust (free) - http://locust.io/ • Python • Hoverfly - http://hoverfly.io/ • Python • Artillery (free) - https://artillery.io/ • Node.js • Gor (free) • Go • Gatling (free) - http://gatling.io/ • Scala • Perfcake (free) • Java
- 60.
- 61.
- 62. Ferramentas para testessimples • AB (Apache Bench) http://httpd.apache.org/docs/current/programs/ab.html • Siege https://github.com/JoeDog/siege • Bees with Machine Guns! https://github.com/newsapps/beeswithmachineguns
- 63. Ferramentas Online • Loader- http://loader.io/ • BlazeMeter - https://www.blazemeter.com • Blitz - https://www.blitz.io/ • Load Impact - https://loadimpact.com/
- 64.
- 65. You can’t managewhat you don’t measure – Peter Drucker
- 66. Importância do Monitoramento •Não conseguimos gerenciar, aquilo que não medimos • Pare de ser reativo, e seja pró-ativo! • Métricas de negócio • Automação e melhoria contínua • ZzzzZzzzzzzz
- 67. Ferramentas de monitoraçãoAWS • Amazon CloudWatch • Logs • Events • Dashboard
- 68. Ferramentas de monitoraçãode propósito geral • Datadog • Zabbix • Nagios • PCP (Performance Co-Pilot) • Icinga • PRTG • NewRelic • Librato • Dynatrace
- 69. Ferramentas de monitoraçãode banco de dados • Vividcortex • Monyog • NewRelic • Nagios • Datadog
- 70.
- 71. Importância do suporte •Tenha pelo menos um plano de suporte para garantir um SLA • Toda dúvida ou problema que tiver, abra um caso de suporte • Se o seu workload está em produção, o mínimo recomendado é o suporte Business • Caso não tenha budget para o business, tenha pelo menos o Developer
- 72.
- 73. Sempre ter emmente… • O mito da região • A Black Friday nunca acaba • Utilize o Well Architected Framework e o Trusted Advisor • Entenda seus pontos fracos e esteja pronto para escalar horizontalmente • DR não é D(epois) R(esolve) • PDCA • Monitore t.u.d.o • Teste t.u.d.o • Seja segurado. Tenha um plano de suporte
- 74.
Notas do Editor
- #10 Latência é um problema, é algo do senso comum. Colete dados Planejar, desenvolver, conferir, ajustar
- #12 Auto suficientes Conectadas por um anel de fibra Distantes o suficiente para proteger de desastres Proximas o suficiente para fornecer baixa latência
- #13 Comunição via internet Exceto para regiões nos estados unidos que podem ter uma rota otimizada interna e de baixa latência entre delas, mas é best effort