O documento discute estratégias para escalar aplicações na AWS para milhões de usuários, começando com uma única instância e expandindo para várias instâncias, regiões e serviços gerenciados. É enfatizado começar com banco de dados SQL e mover cargas de trabalho estáticas e sessões para serviços como S3, CloudFront, DynamoDB e ElastiCache para melhorar o desempenho. Auto Scaling é apresentado como forma de dimensionar automaticamente a capacidade de acordo com as métricas.
12. US-WEST (Oregon)
EU (Ireland)
ASIA PACIFIC
(Tokyo)
US-WEST (N. California)
SOUTH
AMERICA (Sao
Paulo)
US-EAST (N. Virginia)
AWS GOVCLOUD (US)
ASIA PACIFIC
(Sydney)
ASIA PACIFIC
(Singapore)
CHINA (Beijing)
Regiões
EU (Frankfurt)
INDIA (2016)
13. US-WEST (Oregon)
EU (Ireland)
ASIA PACIFIC
(Tokyo)
US-WEST (N. California)
SOUTH
AMERICA (Sao
Paulo)
US-EAST (N. Virginia)
AWS GOVCLOUD (US)
ASIA PACIFIC
(Sydney)
ASIA PACIFIC
(Singapore)
CHINA (Beijing)
Zonas de Disponibilidade
EU (Frankfurt)
INDIA (2016)
23. 1 Usuário
• Amazon Route 53 para DNS
• Um único Elastic IP
• Uma única instância EC2
• Com tudo instalado
• Aplicação web
• Banco de dados
• Gerenciamento
• Etc …
Instância
Amazon
EC2
Elastic IP
Usuário
Amazon
Route 53
24. “Vamos precisar de uma máquina maior”
• Estratégia básica
• Pode se basear em PIOPS
• I/O grande
• Memória grande
• CPU grande
• Disco grande
• Fácil de alterar a capacidade da
instância
• Eventualmente vai chegar no limite!
c4.8xlarge
m3.2xlarge
t2.micro
25. “Vamos precisar de uma máquina maior”
• Estratégia básica
• Pode se basear em PIOPS
• I/O grande
• Memória grande
• CPU grande
• Disco grande
• Fácil de alterar a capacidade da
instância
• Eventualmente vai chegar no limite!
c4.8xlarge
m3.2xlarge
t2.micro
26. 1 Usuário
• Dependendo da
aplicação e da carga
poderemos chegar a
centenas ou milhares de
usuários
• Não há tolerância à falha
• Sem redundância
Instância
EC2
Elastic IP
Usuário
Amazon
Route 53
27. 1 Usuário
• Dependendo da
aplicação e da carga
poderemos chegar a
centenas ou milhares de
usuários
• Não há tolerância à falha
• Sem redundância
Instância
EC2
Elastic IP
Usuário
Amazon
Route 53
29. Usuários > 1
Primeiro, vamos separar
alguns componentes em mais
de uma instância:
• Aplicação web
• Banco de dados
Usar um serviço
gerenciado de banco de
dados?
Instância
Web
Instância
de Banco
de Dados
Elastic IP
Usuário
Amazon
Route 53
30. Você gerencia Gerenciado pela AWS
Banco de dados
em EC2
Você é livre para
usar o banco que
escolher
A gestão das
licenças é sua
Amazon
DynamoDB
Banco de dados
NoSQL gerenciado
e executando sobre
SSDs
Escalabilidade
homogênea
Sem administração
Amazon RDS
Microsoft SQL Server
Oracle
MySQL
PostgreSQL
MariaDB
Amazon Aurora
Sua licença ou já
incluída
Amazon
Redshift
DW para
processamento
paralelo
Escala de Petabytes
Rápido, poderoso e
facilmente escalável
Opções de Banco de Dados
31. Você gerencia Gerenciado pela AWS
Banco de dados
em EC2
Você é livre para
usar o banco que
escolher
A gestão das
licenças é sua
Amazon
DynamoDB
Banco de dados
NoSQL gerenciado
e executando sobre
SSDs
Escalabilidade
homogênea
Sem administração
Amazon RDS
Microsoft SQL Server
Oracle
MySQL
PostgreSQL
MariaDB
Amazon Aurora
Sua licença ou já
incluída
Amazon
Redshift
DW para
processamento
paralelo
Escala de Petabytes
Rápido, poderoso e
facilmente escalável
Opções de Banco de Dados
32. Amazon Aurora
• Disco escala automaticamente até 64 TB
• Até 15 réplicas de leitura
• Backup incremental no Amazon S3
• Replicado em 3 AZs
• Compatível com MySQL
36. Por que começar com SQL?
• Tecnologia madura e bem posicionada.
• Muito código disponível, comunidades, livros e
ferramentas.
• Você não vai quebrar o seu banco SQL nos seus
primeiros 10 milhões de usuários. Não, não vai.
• Estratégias de escala já bem conhecidas.
* A não ser que você esteja fazendo algo SUPER peculiar com os dados ou você tenha um
volume de dados massivo… mas ainda o banco SQL terá um lugar na sua arquitetura.
38. > 5 TB em um ano?
Workload de dados incrivelmente
intensos??
OK!
Você pode precisa de NoSQL!
39. Por que você pode precisar de um NoSQL?
• Aplicações de baixa latência
• Metadata-driven
• Dados não estruturados (não relacional)
• Precisa de um modelo de dados sem esquemas*
• Quantidade expressiva de dados (TB+)
• Necessidade de ingestão rápida de dados (milhares de
registros/sec)
*Precisa!= “É mais fácil desenvolver sem schemas”
41. Usuários >100
Primeiro, vamos separar
nosso servidor em dois
componentes:
• Aplicação web
• Banco de dados
Use Amazon RDS para
facilitar a sua vida Instância
Web
Elastic IP
Instância
RDS DB
Usuário
Amazon
Route 53
43. Usuários >1000
Agora, vamos adicionar
tolerância à falhas e
redundância:
Mais uma instância web
• Em outra Zona de
disponibilidade
RDS Multi-AZ
Elastic Load Balancing (ELB)
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
Web
Instance
RDS DB Instance
Standby (Multi-AZ)
ELB
Balancer
User
Amazon
Route 53
44. Elastic Load Balancing
• Em alta disponibilidade
• 1 - 65535
• Health checks
• Redirecionamento por
sessões
• SSL
• Monitoramento
• Logs
47. Usuários > 10,000s–100,000s
RDS DB Instância
Ativa (Multi-AZ)
Availability Zone Availability Zone
RDS DB Instância
Standby (Multi-AZ)
ELB
Balancer
RDS DB
Read Replica
RDS DB
Read Replica
RDS DB
Read Replica
RDS DB
Read Replica
Instância
Web
Instância
Web
Instância
Web
Instância
Web
Instância
Web
Instância
Web
Instância
Web
Instância
Web
Amazon
Route 53Usuário
50. RDS DB Instance
Active (Multi-AZ)
Availability Zone
ELB
Balancer
Amazon S3
Amazon
CloudFront
Amazon
Route 53
User
Mova algum workload
Web Instances
• Conteúdo estático para o
Amazon S3 e Amazon
CloudFront
Mova…
51. Amazon Simple Storage Service (S3)
• Storage de objetos
• Altamente durável
• Muito bom para objetos
estáticos
• “Escala infinita”
• Objectos até 5 TB
• Criptografia opcional
52. Amazon CloudFront
• Cache de conteúdo para entrega
rápida
• Diminui a carga na origem
• Conteúdo estático e dinâmico
• Streaming de vídeos
• Certificados SSL
• Baixo TTLs (tão baixo qnt 0)
• Otimizado para AWS
54. Mova algum workload
• Conteúdo estático no Amazon S3
e Amazon CloudFront
Move…
• Sessão/estado para o Amazon
DynamoDB
• Cache dos dados no Amazon
ElastiCache RDS DB Instance
Ativo (Multi-AZ)
Availability Zone
ELB
Balancer
Amazon S3
Amazon
CloudFront
Amazon
Route 53
Usuário
ElastiCache DynamoDB
Instâncias Web
55. Amazon DynamoDB
• Banco de dados NoSQL gerenciado
• Throughput provisionado
• Rápido e previsível
• Distribuído e tolerante a falhas
• Suporte à JSON
• Itens até 400 KB
56. Amazon Elasticache
• Memcached ou Redis gerenciado
• Escala de 01 a vários nós
• Self-healing (substitui instâncias com
problemas)
• Single AZ para nó de Memcache
• Possível Multi-AZ com Redis
57. Mova algum workload
Move…
RDS DB Instância
Ativa (Multi-AZ)
Availability Zone
ELB
Balancer
Amazon S3
Amazon
CloudFrontUsuário
ElastiCache DynamoDB
Instâncias Web
Amazon
Route 53
• Conteúdo estático no Amazon S3
e Amazon CloudFront
• session/estado para o Amazon
DynamoDB
• Cache dos dados no Amazon
ElastiCache
• Conteúdo dinâmico para o Cloud
Front
58. Agora que a camada web está
mais leve, vamos voltar ao
começo da nossa conversa…
60. Redimencionamento automático da quantidade de servidores
Define o tamanho mínimo e máximo para a quantidade de servidores
Use as métricas do CloudWatch para ativar o redimencionamento
Use instâncias EC2 no modelo de On-demand ou Spot
aws autoscaling create-auto-scaling-group
--auto-scaling-group-name MeuGrupo
--launch-configuration-name MinhaConfig
--min-size 4
--max-size 200
--availability-zones us-west-2c, us-west-2b
Auto Scaling
61. Domingo Segunda Terça Quarta Quinta Sexta Sábado
Típico tráfego semanal da Amazon.com
62. Domingo Segunda Terça Quarta Quinta Sexta Sábado
Capacidade Provisionada
Típico tráfego semanal da Amazon.com
70. Users > 500,000+
Availability Zone
Amazon
Route 53
User
Amazon S3
Amazon
CloudFront
Availability Zone
ELB
Balancer
DynamoDB
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
ElastiCache RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
ElastiCacheRDS DB Instance
Standby (Multi-AZ)
RDS DB Instance
Active (Multi-AZ)
71. Users > 500,000+
Availability Zone
Amazon
Route 53
User
Amazon S3
Amazon
CloudFront
Availability Zone
ELB
Balancer
DynamoDB
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
ElastiCache RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
ElastiCacheRDS DB Instance
Standby (Multi-AZ)
RDS DB Instance
Active (Multi-AZ)
73. Gestão de aplicações com serviços da AWS
Conveniência Controle
Serviços de alto nível Faça você mesmo
AWS
Elastic Beanstalk
AWS
OpsWorks
AWS
CloudFormation
Amazon EC2
74. AWS CodeDeploy
• Deploys seu código para uma “frota” de instâncias EC2
• 1 – 10,000s de instâncias
• Agenda updates automaticamente (múltipas AZs)
• Grupo de Deployment e Aplicação descritos em
arquivos no formato YAML
• Pode referencias Auto Scaling Groups
• Console de Gerenciamento da AWS, CLI, ou APIs
• Pode ser usado com receitas de Chef ou scripts Puppet
75. Usuários >500,000+
• Monitoramento, métricas e logs
• Se você não vai construir use de
terceiros (SaaS)
• O que os clientes estão dizendo?
• Tente obter o máximo de performance
de cada serviço ou componente
81. Aqui é onde vc
deve começar!
Muita coisa para
ler!
Não é o lugar
para começar
82. SOAing
Mais serviços na mesma camada:
• Trate-os separadamente e
escale de maneira independente.
A Amazon e a AWS fazem isso o tempo
todo!
Oferece flexibilidade e mais compreensão
sobre cada componente.
83. Baixo acoplamento + SOA = vitória!
Mas não reinvente a roda
• Email
• Filas
• Transcodificação
• Busca
• Banco de dados
• Monitoração
• Métricas
• Logging
• Computação
Amazon
CloudSearch
Amazon SQSAmazon SNS
Amazon Elastic
Transcoder
Amazon SWFAmazon SES
AWS Lambda
84. • Confiável (Multi-AZ)
• Escalável (# mensages ilimitado)
• Seguro (autenticação por fila)
• Simples (APIs extremamente simples)
Application Services – Amazon SQS
SQS
messages
Get
Message
Instance
Put
Message
Instance
Amazon SNS Topic
Publish
Notification
Queue Is Subscribed
to Topic
86. Desacoplamento te liberta!
Quanto menos acoplamento, melhor eles escalam
• Componentes independentes
• Desenhe os componentes como caixa preta
• Desacople as interações
• Prefira o uso de serviços com tolerância e redundância
S3 Bucket
Lambda
Push: Event
Notification
DynamoDB
Pull: DynamoDB
Stream
Amazon
Kinesis
Pull:
DynamoDB Stream
SQS
messages
Get
Message
Instance
Put
Message
Instance
Amazon SNS Topic
Publish
Notification
Queue Is Subscribed
to Topic
88. Usuários >1 milhão+
Com um milhão de usuários vamos precisar de um pouco
de cada coisa:
• Multi-AZ
• Elastic Load Balancing entre camadas
• Auto Scaling
• Service Oriented Architecture
• Forneça conteúdo de maneira inteligente (Amazon
S3/CloudFront )
• Adicionando um cache na frente do banco de dados
• Mova os estados das camadas de auto scaling
89. Users >1 million+
RDS DB Instance
Active (Multi-AZ)
Availability Zone
ELB
Balancer
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User
Amazon S3
Amazon
CloudFront
DynamoDB
Amazon SQS
ElastiCache
Worker
Instance
Worker
Instance
Amazon
CloudWatch
Internal App
Instance
Internal App
Instance Amazon SES
Lambda
92. Usuários >5 milhões - 10 milhões
Você deve começar a ter um gargalo no banco de dados,
principalmente na escrita.
Como você resolve isso?
• Federação — separe os bancos por função
• Sharding — separe um dataset entre vários servidores
• Mova algumas funcionalidades para outros tipos de banco (NoSQL,
Graph)
93. Federação de BD
• Separe por função
• Mais difícil de fazer com queries cross-function
• E não funciona para tabelas gigantescas
Foruns DB
Usuários
DB
Produtos
DB
94. Escalabiliade com Shards
• Mais complicado para a aplicação
• Sem limite para escalabilidade
• Complexidade na operação
• Shard por função ou por chaves
• RDBMS ou NoSQL
User ShardID
002345 A
002346 B
002347 C
002348 B
002349 A
CBA
95. Use NoSQL
• Mesma idéia da federação
• Use serviços gerenciados da AWS como o
DynamoDB
Alguns casos de uso:
• Placar de jogos online
• Ingestão de logs ou clickstream
• Dados temporários (carrinho de compras)
• Dados quentes
• Tabela para metadado ou pesquisa rápidaDynamoDB
97. Revisão
• Use Multi-AZ
• Faça uso de serviços que escalam — ELB, Amazon S3,
Amazon SNS, Amazon SQS, Amazon SWF, Amazon SES, e
outros.
• Redundância em todos os níveis.
• Comece com SQL. Sério!
• Faça cache dentro e fora da sua infra.
• Use ferramentas para automação.
98. Revisão
• Tenha boas métricas, monitoramento e logs
• Divida a mesma camada em serviços
• Use Auto Scaling quando sua aplicação estive pronta
• Não reinvente a roda
• Mova para NoSQL se e quando fizer sentido
100. Escalar sem limites
• Plataforma de comércio eletrônico
SaaS.
• + 1000 lojas
• Estamos em 14 países
• + 12 milhões de pedidos em 2015
• + 2 bilhões de pageviews em 2015
“Vamos focar no
objetivo da nossa
empresa, nós
desenvolvemos
software.
Infraestrutura não pode
gastar nosso tempo.”
- Marcelo Couto
101. O Desafio
• Ter um sistema com uma infra-
estrutura escalável para atender
todos os clientes. SaaS.
• Transformar um sistema grande em
microserviços
• Conseguir lançar versões sem
downtime
• Fazer o lançamento de versões ser
frequente.
102. Solução
• Mais de 40 serviços, cada um
com a sua infraestrutura e
repositórios de dados.
• Todos os ambientes
monitorados e com alarmes
criados.
• 1130 versões lançadas nos
ultimos 30 dias.
105. Usuários >11 milhões
Fazer iterações sobre os
padrões discutidos aqui lhe
dará capacidade para
crescer para mais de 100
milhões de usuários.
106. • Ajuste fino da sua aplicação
• Mais SOA
• Ampliando de Multi-AZ para multi-região
• Criar soluções mais personalizadas
• Análise profunda da pilha da sua aplicação
Usuários >11 milhões