rodando a blackfriday do seu ecommerce na nuvem
TRANSCRIPT
Rodando a Black Friday do seu
eCommerce na nuvem
Felipe Garcia, Arquiteto de Soluções22 de Agosto de 2016
Agenda• Arquitetura• Qual a 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
Agenda• Escalabilidade• Escolhendo a instância correta• Esteja preparado para escalar horizontalmente• Escalando com Auto Scaling e ELB
Agenda• Disponibilidade• Plano de Continuidade• 1,2,3 Testando• Monitoramento• Suporte
• Lições Aprendidas
Arquitetura
Qual é a melhor região?
Quais fatores considerar na escolha da região?
Conformidade
Localidade dos dados
Latência
Serviços
Custos
Qual é a melhor 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
Multi AZ vs Multi Região
Multi AZ
RegiãoAvailability
Zone
Availability Zone
Availability Zone
Multi Região
RegiãoAvailability
Zone
Availability Zone
Availability Zone
RegiãoAvailability
Zone
Availability Zone
Availability Zone
E aí, Multi AZ 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
Serviços Gerenciados ou EC2
Por que usar Serviç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.
Persistência Poliglota
Na era do Banco de Dados
Business Logic
SearchAPI
CatalogAPI
ReportsCartAPI
Session
Banco de Dados(Relacional, NoSql, etc)
Na era do Banco de Dados
Business Logic
SearchAPI
CatalogAPI
ReportsCartAPI
Session
Banco de Dados(Relacional, NoSql, etc)
Na era das Ferramentas de Busca e Indexação
Business Logic
SearchAPI
CatalogAPI
ReportsCartAPI
Session
Ferramenta de Busca(ex: Solr, Elasticsearch, etc)
Na era das Ferramentas de Busca e Indexação
Business Logic
SearchAPI
CatalogAPI
ReportsCartAPI
Session
Ferramenta de Busca(ex: Solr, Elasticsearch, etc)
When you only have a hammer, everything looks like a nail– Abraham Maslow
Trabalhando com Persistência Poliglota
Business Logic
SearchAPI
CatalogAPI
ReportsCartAPI
Session
AmazonDynamoDB
Amazon Redshift
Amazon ElastiCache
AmazonRDS
AmazonDynamoDB
Amazon Elasticsearch Service
Segurança
Boas práticas• Proteja sua 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
Well Architected
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
Exemplos de Arquitetura
Web Frontend
Fluxo de Compras
Sistema de recomendação e campanha de marketing
Escalabilidade
Escolhendo a instância correta
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)
Boas práticas• Defina suas 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
Esteja preparado para escalar horizontalmente
Boas práticas• Construa aplicaçõ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
Boas práticas• Banco de 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
Escalando com Auto Scaling e ELB
Entendendo a demanda da sua aplicação
Provisionando para a consumo máximo
Provisionando para o consumo médio
Provisionando capacidade sob demanda
Exemplo: escalando na produção
Boas práticas• Certifique-se que 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
Boas práticas• Faça scale 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
Disponibilidade
Plano de Continuidade
Everything fails all the time
– Werner Voegels
Planejando a continuidade do 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
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
Pilot Light - Desenho
Pilot Light - Failover
Warm Standby - Desenho
Warm Standby - Failover
Multi Site - Desenho
Multi Site - Failover
1,2,3 Testando
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
Frameworks e ferramentas para 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
Hoverfly
Gor
Ferramentas para testes simples• AB (Apache Bench)http://httpd.apache.org/docs/current/programs/ab.html
• Siegehttps://github.com/JoeDog/siege
• Bees with Machine Guns!https://github.com/newsapps/beeswithmachineguns
Ferramentas Online• Loader - http://loader.io/• BlazeMeter - https://www.blazemeter.com• Blitz - https://www.blitz.io/• Load Impact - https://loadimpact.com/
Monitoramento
You can’t manage what you don’t measure– Peter Drucker
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
Ferramentas de monitoração AWS• Amazon CloudWatch• Logs • Events• Dashboard
Ferramentas de monitoração de propósito geral• Datadog• Zabbix• Nagios• PCP (Performance Co-Pilot)• Icinga• PRTG• NewRelic• Librato• Dynatrace
Ferramentas de monitoração de banco de dados• Vividcortex• Monyog• NewRelic• Nagios• Datadog
Suporte
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
Lições Aprendidas
Sempre ter em mente…• 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
Obrigado!