rodando a blackfriday do seu ecommerce na nuvem

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!