O documento discute estratégias para escalabilidade na nuvem AWS, começando com uma única instância EC2 e evoluindo para arquiteturas capazes de suportar milhões de usuários. É recomendado usar redundância, balanceamento de carga, auto-escalonamento, arquitetura orientada a serviços e serviços gerenciados como S3, DynamoDB e ElastiCache. Ferramentas de automação e monitoramento também são importantes para gerenciar a infraestrutura em larga escala.

1. José Papo
AWSTech Evangelist
@josepapo

2. Então, como ter escalabilidade na Nuvem?

3. Auto-Scaling???

4. Começando pelo básico primeiro

5. US-WEST (Oregon)
EU-WEST (Ireland)
ASIA PAC (Tokyo)
US-WEST (N. California)
SOUTH AMERICA (Sao Paulo)
US-EAST (Virginia)
AWS GovCloud (US)
ASIA PAC
(Sydney)
Regiões
ASIA PAC
(Singapore)

6. US-WEST (Oregon)
EU-WEST (Ireland)
ASIA PAC (Tokyo)
US-WEST (N. California)
SOUTH AMERICA (Sao Paulo)
US-EAST (Virginia)
AWS GovCloud (US)
ASIA PAC
(Sydney)
Zonas de Disponibilidade
ASIA PAC
(Singapore)

7. Compute Storage
AWS Global Infrastructure
Database
App Services
Deployment & Administration
Networking

8. Compute Storage
AWS Global Infrastructure
Database
App Services
Deployment & Administration
Networking
Amazon
CloudWatch AWS IAM AWS
CloudFormation
Amazon Elastic
Beanstalk
AWS
Data
Pipeline
AWS
OpsWorks
Amazon
CloudSearch
Amazon SQSAmazon
SNS
Amazon
Elastic
Transcoder
Amazon SWF
Amazon SES
Amazon
DynamoDB
Amazon RDS
Amazon
ElastiCache
Amazon
RedShift
AWS Storage
Gateway
Amazon S3
Amazon
Glacier
Amazon
CloudFrontAmazon
EC2
Amazon
EMR
Amazon
VPC
Amazon
Route 53
AWS
Direct
Connect

9. Vamos então começar pelo dia
um, um usuário ( você! ):

10. Dia Um, Um Usuário
• Uma instancia EC2
– Stack completo
• AplicaçãoWeb
• Banco de Dados
• Gestão
• Etc.
• Um Elastic IP
• Route53 para DNS
EC2
Instance
Elastic IP
Amazon
Route 53
User

11. “Precisamos de uma máquina maior”
• Modo mais simples
• Pode alavancar uso de PIOPs
• Instancias High I/O
• Instancias High Memory
• Instancias High CPU
• Instancias High Storage
• Fácil de mudar tamanhos de
instancias
• Vai eventualmente ter limitações
hi1.4xlarge
m2.4xlarge
m1.small

12. “Precisamos de uma máquina maior”
• Modo mais simples
• Pode alavancar uso de PIOPs
• Instancias High I/O
• Instancias High Memory
• Instancias High CPU
• Instancias High Storage
• Fácil de mudar tamanhos de
instancias
• Vai eventualmente ter limitações
hi1.4xlarge
m2.4xlarge
m1.small

13. Dia Um, Um Usuário:
• Pode potencialmente atender
algumas centenas até alguns
milhares de usuários
dependendo da instancia,
complexidade da app e
tráfego
• Não tem failover
• Não tem redundância
• Todos os ovos no mesmo cesto
EC2
Instance
Elastic IP
Amazon
Route 53
User

14. Dia Um, Um Usuário:
• Pode potencialmente atender
algumas centenas até alguns
milhares de usuários
dependendo da instancia,
complexidade da app e
tráfego
• Não tem failover
• Não tem redundância
• Todos os ovos no mesmo cesto
EC2
Instance
Elastic IP
Amazon
Route 53
User

15. Dia Dois, Usuário >1:
Vamos primeiro
separar os recursos em
mais de uma instancia.
• Instancia Web
• Instancia de Banco Web
Instance
Database
Instance
Elastic IP
Amazon
Route 53
User

16. Gestão Própria Serviço Gerenciado
Banco de Dados
no Amazon EC2
Sua escolha de BD
no Amazon EC2
Bring Your Own
License (BYOL)
Amazon
DynamoDB
Serviço gerenciado
de BD NoSQL que
usa storage SSD
Amazon RDS
MS SQL Server,
Oracle ou MySQL
as a service
BYOL ou Licença
Incluída
Amazon
Redshift
Data Warehouse as
a service
distribuído e com
escala de petabytes
Opções de Bases de Dados

17. Que tecnologia usar?
SQL? NoSQL?

18. Depende do seu caso
de uso, mas…

19. Comece com aquilo que for
mais simples para você

20. Vamos começar com o
Amazon RDS nesse exemplo

21. Usuários >100:
Web
Instance
Elastic IP
RDS DB
Instance
Amazon
Route 53
User
Vamos primeiro separar
os recursos em mais de
uma instancia.
• Instancia Web
• Instancia de Banco
– Use o RDS para ter uma
vida mais simples!

22. Usuários > 1000:
Agora vamos endereçar
a falta de failover e
redundancia:
• Elastic Load Balancer
• Mais uma InstanciaWeb
– Em outra Zona de Disponibilidade
• Habilitar RDS Multi-AZ
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
Web
Instance
RDS DB Instance
Standby (Multi-AZ)
Elastic Load
Balancer
Amazon
Route 53
User

23. Escalando
horizontalmente e
verticalmente podemos
chegar bem longe
( 10s-100s de milhares )

24. Usuários >10ks-100ks:
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
RDS DB Instance
Standby (Multi-AZ)
Elastic Load
Balancer
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User

25. Isso realmente nos levará
longe, mas queremos
também performance e
eficiência.Vamos limpar um
pouco mais

26. Mova a carga:
Diminua a carga nas
instanciasWeb e BD:
• Mova conteúdo estático da
instancia Web para o S3 e
CloudFront
• Mova estado/sessões e faça
cache do BD com ElastiCache
e/ou DynamoDB
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Elastic Load
Balancer
Amazon S3
Amazon
Cloudfront
Amazon
Route 53
User
ElastiCache
DynamoDB

27. Agora que nossas camadas
Web e de BD estão mais
leves vamos voltar ao início
da nossa discussão…

28. Auto-Scaling!!!

29. Escalabilidade automática de
instancias de acordo com políticas
definidas
Trigger auto-scaling
policy
as-create-auto-scaling-group MyGroup
--launch-configuration MyConfig
--availability-zones us-east-1a
--min-size 4
--max-size 200
Auto-Scaling
Amazon
CloudWatch

30. Tráfego em Novembro na Amazon.com
November

31. Provisioned capacity
November
Tráfego em Novembro na Amazon.com

32. 76%
24%
Provisioned capacity
November
Tráfego em Novembro na Amazon.com

33. November
Tráfego em Novembro na Amazon.com
Auto Scaling

34. É possível fazer ainda mais
melhorias deixando suas
camadas ainda mais leves e
orientadas a serviços

36. SOA = Service Oriented Architecture

37. Baixo acoplamente te liberta!
• Reduza o acoplamento para escalar ainda mais
– Componentes independentes
– Projete-os como uma caixa preta
– Desacople as integrações
– Prefira serviços já construídos com redundancia e
escalabilidade ao invés de contruir novamente
Controller A Controller B
Controller A Controller B
Q Q
Alto acomplamento
Use Amazon SQS como Buffers
Baixo acoplamento

38. Baixo acoplamento + SOA = Win!
Exemplos:
• Email
• Filas
• Transcoding de Vídeos
• Busca
• Bancos de Dados
• Monitoramento
• Métricas
• Logs
Amazon
CloudSearch
Amazon SQSAmazon SNS
Amazon Elastic
Transcoder
Amazon SWF
Amazon SES
Não reinvente a roda!

39. Baixo acoplamento + SOA
Exemplo

40. Imagine um site/app para
upload e compartilhamento
de fotos entre usuários

41. Exemplo usando filas de
mensagem SQS

42. S3 Bucket
For Ingest
User
SNS Topic
RRS S3
Bucket to
Serve
content to
CloudFront
S3 Bucket
For
originals
CloudFront
Download
Distribution
SQS Queue
Size for Thumbnail
SQS Queue
Size Image for
Mobile
SQS Queue
Size Image for Web
Auto scaling
Group
Instances
Auto scaling
Group
Instances
Auto scaling
Group
Instances

43. Exemplo usando serviço
Simple Workflow (SWF)

44. S3 Bucket
For Ingest
User
RRS S3
Bucket to
Serve
content to
CloudFront
S3 Bucket
For
originals
CloudFront
Download
Distribution
Auto scaling
Group
Instances
Auto scaling
Group
Instances
Auto scaling
Group
Instances
SWF
Instance running
decider

45. Usuários >1milhão+:
Chegar em um milhão e além requer uma arquitetura que
utilize os recursos vistos anteriormente:
• Multi-AZ
• Elastic Load Balancer entre as camadas
• Auto-Scaling
• Service oriented architecture
• Servir conteúdo estático com as soluções certas (
S3/CloudFront )
• Cache e réplicas de bases de dados
• Mover estado para fora das camadas com auto-scaling

46. Usuários >1milhão+:
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Elastic Load
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

47. Próximos passos

48. Usuários > 10milhões+:
Você provavelmente encontrará dificuldades com sua
base de dados nas escritas no BD Master.
Como resolver?
• Sharding ( separar conjuntos de dados em mais de
uma base de dados )
• Mover funcionalidades para outros tipos de BDs (
NoSQL )

49. Sharding
• Mais complexo para a
camada de aplicação
• Complexidade
operacional
• Shard por função ou
chave
User ShardID
002345 A
002346 B
002347 C
002348 B
002349 A
A
B
C

50. Mover funcionalidades para NoSQL
• Soluções NoSQL usualmente possuem
escalabilidade horizontal transparente
• Use serviços gerenciados como o
DynamoDB
DynamoDB

51. Você também poderá ter problemas relacionados a
velocidade ou performance.
• Tenha soluções de monitoração/métricas/logs
– Se possível, use soluções prontas! ( SaaS )
• Preste atenção no que seus usuários estão dizendo
• Verifique a performance de cada serviço/componente
Usuários > 10milhões+:

52. HOST
LEVEL
METRICS
AGGREGATE
LEVEL
METRICS
LOG
ANALYSIS
EXTERNAL
SITE
PERFORMANCE

53. AWS Marketplace & Partners AWS podem ajudar
Saiba mais em: aws.amazon.com/marketplace

54. Usuários > 10 milhões+:
Gerenciar sua infraestrutura será fundamental com
número de instancias e recursos utilizados em
crescimento.Use ferramentas para automatizar tarefas.
• Ferramentas da AWS
• Ferramentas de gestão de configuração
• Análise automatizada de logs e ações de usuários

55. Soluções de Gestão de Aplicações da AWS
Elastic Beanstalk OpsWorks CloudFormation EC2
Conveniência Controle
Serviços de Alto Nível Faça você mesmo

56. Host Based Configuration Management
Dois grandes players:
– Opscode Chef
– PuppetLabs Puppet
• São parecidos em recursos
• Use HBCM junto com uma das soluções da AWS
(OpsWorks integra com Chef e CloudFormation
com Chef ou Puppet)
• Mais difícil gerenciar muitos recursos
computacionais sem HBCM

57. Breve revisão sobre
escalabilidade

58. Pense em redundância em
todas as camadas

59. Multi-AZ na sua infraestrutura

60. Faça uso de serviços prontos
( ELB, S3, SNS, SQS, SWF,
SES, etc )

61. Use SQL ou NoSQL de
acordo com os requisitos de
seu negócio

62. Crie uma arquitetura
orientada a serviços ( SOA )

63. Use Auto-scaling quando
precisar crescer ou diminuir
automaticamente

64. Use ferramentas de automação
sempre que possível

65. Tenha soluções de
métricas/monitoração/logs

66. Não reinvente a roda!

67. Pensando nesses elementos
você certamente poderá
atender dezenas e até centenas
de milhões de usuários!

68. aws.amazon.com/pt/architecture
Saiba mais em…

69. RECURSOS TÉCNICOS
awshub.com.br

70. OBRIGADO!
aws.typepad.com/brasil
slideshare.net/AmazonWebServicesLATAM
José Papo
AWS Tech Evangelist
@josepapo