Aprenda como gigantes do comércio eletrônico brasileiro como Magazine Luiza, Dafiti e Kanui já se beneficiam da escalabilidade, agilidade e segurança dos serviços da Amazon Web Services sem que precisem adivinhar a capacidade necessária para a BlackFriday, além de pagarem somente pelo uso.

1. Rodando a Black Friday do
seu eCommerce na nuvem
Felipe Garcia, Arquiteto de Soluções
22 de Agosto de 2016

2. 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

3. Agenda
• Escalabilidade
• Escolhendo a instância correta
• Esteja preparado para escalar horizontalmente
• Escalando com Auto Scaling e ELB

4. Agenda
• Disponibilidade
• Plano de Continuidade
• 1,2,3 Testando
• Monitoramento
• Suporte
• Lições Aprendidas

5. Arquitetura

6. Qual é a melhor região?

8. Quais fatores considerar na escolha da
região?
Conformidade
Localidade dos
dados
Latência
Serviços
Custos

9. 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

10. Multi AZ vs Multi Região

11. Multi AZ
Região
Availability
Zone
Availability
Zone
Availability
Zone

12. Multi Região
Região
Availability
Zone
Availability
Zone
Availability
Zone
Região
Availability
Zone
Availability
Zone
Availability
Zone

13. 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

14. Serviços Gerenciados ou EC2

15. 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.

16. Persistência Poliglota

17. Na era do Banco de Dados
Business
Logic
Search
API
Catalog
API
ReportsCart
API
Session
Banco de Dados
(Relacional, NoSql, etc)

18. Na era do Banco de Dados
Business
Logic
Search
API
Catalog
API
ReportsCart
API
Session
Banco de Dados
(Relacional, NoSql, etc)

19. Na era das Ferramentas de Busca e Indexação
Business
Logic
Search
API
Catalog
API
ReportsCart
API
Session
Ferramenta de Busca
(ex: Solr, Elasticsearch, etc)

20. Na era das Ferramentas de Busca e Indexação
Business
Logic
Search
API
Catalog
API
ReportsCart
API
Session
Ferramenta de Busca
(ex: Solr, Elasticsearch, etc)

21. When you only have a hammer,
everything looks like a nail
– Abraham Maslow

22. Trabalhando com Persistência Poliglota
Business
Logic
Search
API
Catalog
API
ReportsCart
API
Session
Amazon
DynamoDB
Amazon
Redshift
Amazon
ElastiCache
Amazon
RDS
Amazon
DynamoDB
Amazon Elasticsearch
Service

23. Segurança

24. 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

25. Well Architected

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. Exemplos de Arquitetura

28. Web Frontend

29. Fluxo de Compras

30. Sistema de recomendação e campanha de
marketing

31. Escalabilidade

32. Escolhendo a instância correta

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
• 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

35. Esteja preparado para escalar
horizontalmente

36. 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

37. 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

38. Escalando com Auto Scaling e ELB

39. Entendendo a demanda da sua aplicação

40. Provisionando para a consumo máximo

41. Provisionando para o consumo médio

42. Provisionando capacidade sob demanda

43. Exemplo: escalando na produção

44. 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

45. 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

46. Disponibilidade

47. Plano de Continuidade

48. Everything fails all the time
– Werner Voegels

49. 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

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. 1,2,3 Testando

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 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

60. Hoverfly

61. Gor

62. Ferramentas para testes simples
• 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. Monitoramento

65. You can’t manage what 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ção AWS
• Amazon CloudWatch
• Logs
• Events
• Dashboard

68. Ferramentas de monitoração de propósito
geral
• Datadog
• Zabbix
• Nagios
• PCP (Performance Co-Pilot)
• Icinga
• PRTG
• NewRelic
• Librato
• Dynatrace

69. Ferramentas de monitoração de banco de
dados
• Vividcortex
• Monyog
• NewRelic
• Nagios
• Datadog

70. Suporte

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. Lições Aprendidas

73. 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

74. Obrigado!