1. O documento apresenta o novo banco de dados relacional da AWS chamado Amazon Aurora. 2. O Aurora foi projetado para superar as limitações das arquiteturas de bancos de dados tradicionais, que são monolíticas e não escalam horizontalmente de forma eficiente. 3. O Aurora usa uma arquitetura orientada a serviços, distribuindo camadas como armazenamento e log em outros serviços AWS para melhor desempenho, disponibilidade e escalabilidade.

1. SÃO PAULO

2. ©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved
Introduzindo
Amazon Elastic File System (EFS)
Angelo Carvalho, Partner Solutions Architect, AWS

3. Agenda
1. Visão geral do EFS
2. Conceitos técnicos do EFS
3. Mecanismos de Segurança do Sistema de Arquivos
4. Modelo de disponibilidade e durabilidade

4. Visão Geral do Amazon EFS

5. Portfolio de Storage da AWS
Amazon S3
• Storage de Objetos: dados apresentados como buckets de objetos
• Dados acessados por APIs através da Internet
Amazon
EFS
• Storage de arquivos (análogo ao NAS): dados apresentados como um file system
• Acesso de baixa latência e compartilhado a partir de múltiplas instâncias EC2
Amazon
Elastic Block
Store
• Storage de Blocos (análogo ao SAN): dados apresentados como discos/volumes
• Acesso de menor latência a partir das Instâncias EC2
Amazon
Glacier
• Storage para Arquivamento: dados apresentados como vaults/archives de objetos
• Storage de menor custo, para dados não acessados frequentemente

6. O Que é o Amazon EFS?
• Um sistema de arquivos gerenciado para as instâncias EC2
• Fornece a semântica padrão para sistema de arquivos
• Funciona com as APIs de sistemas operacionais para
sistemas de arquivos
• Compartilhável entre milhares de instâncias
• Cresce elasticamente a uma escala de petabytes
• Entrega performance para uma variedade de workloads
• Altamente disponível e durável
• Baseado em NFS v4

7. EFS é desenhado para um amplo leque de
casos de uso, como…
• Repositório de Conteúdo (CMS)
• Ambientes de Desenvolvimento
• Diretórios de Usuários
• Big data

8. Operar um storage de arquivos compartilhado é difícil
Application owner
or developer
IT administrator
Business owner
• Estima a demanda
• Compra hardware
• Reserva espaço físico
• Configura e mantém o hardware (e a rede)
• Gerencia acesso e segurança
• Fornece uma estimativa de crescimento
• Precisa adicionar o tempo do provisionamento da infra no
seu cronograma
• Limita a flexibilidade e e agilidade
• Faz investimentos adiantados, compram mais do que o
necessário, ciclo constante de atualização/modernização
• Sacrificam a agilidade do negócio
• Distraem as pessoas da verdadeira missão do negócio

9. EFS muda este jogo completamente
EFS é
simples
EFS é
elástico
EFS é
escálavel
1 2 3

10. EFS é simples
• Totalmente gerenciado
– Sem hardware, rede, camada de arquivos
– Cria um sistema de arquivos escalável em
segundos!
• Integração precisa com ferramentas e
aplicações existentes
– NFS v4—muito adotado, aberto
– Semântica padrão para o sistema de
arquivos
– Funciona com as apis padrões do SO
• Preço simples = Estimativa simples
1

11. EFS é elástico
• Sistemas de arquivos crescem e
diminuem automaticamente conforme
você adiciona ou remove arquivos
• Não é preciso provisionar capacidade
ou performance
• Você paga somente pelo que você
usa, não existe valor mínimo
2

12. • Sistemas de arquivos podem crescer
para uma escala de petabytes
• Throughput e IOPS escalam
automaticamente conforme o sistema
de arquivos cresce
• Baixa latência consistente
independente do tamanho do arquivo
• Suporte para milhares de conexões
NFS concorrentes
EFS é escalável3

13. Porque isso é importante?...
… para app
owners e
developers?
… para seu
negócio?
• Fácil mover para a nuvem código existente, aplicações
e ferramentas que hoje usam servidores NFS
• Storage de arquivos simples para novas aplciações
nativas para cloud
• Preço previsível sem investimento inicial
• Mais agilidade
• Gaste menos tempo gerenciando storage e mais
tempo focado no seu business
… para
administradores
de TI?
• Elimina a necessidade de gerenciar e manter
storage em larga escala

14. Mais detalhes

15. Alguns conceitos chave que precisamos entender
• Região
• Zona de Disponibilidade (AZ)
• Amazon Virtual Private Cloud (VPC)

16. Região
• Áreas geográficas onde os
serviços AWS estão
disponíveis
• Clientes escolhem a região
onde irão provisionar seus
recursos
• Onze regiões ao redor do
mundo
REGIÃO

17. Zona de Disponibilidade (AZ)
• Cada região tem múltiplas
localidades isoladas
conhecidas como zonas de
disponibilidade
• Links de baixa latência
entre AZs dentro de uma
região
• Ao lançar uma instância
EC2, o cliente escolhe qual
AZ
AVAILABILITY ZONE 3
EC2
AVAILABILITY ZONE 2
AVAILABILITY ZONE 1
EC2
EC2
EC2
REGIÃO

18. Virtual Private Cloud (VPC)
• Sessão isolada da nuvem
AWS, rede virtual definida
pelo cliente
• Ao lançar instâncias e
outros recursos, clientes
os colocam numa VPC
• Todos os novos clientes
tem uma VPC default
AVAILABILITY ZONE 1
REGION
AVAILABILITY ZONE 2
AVAILABILITY ZONE 3
VPC
EC2
EC2
EC2
EC2

19. O que é um sistema de arquivos?
• O recurso primário no EFS
• Onde você armazena arquivos e diretórios
• Você pode criar quantos sistemas de arquivos
você quiser pra cada conta.

20. Como acessar um sistema de arquivos a partir de
uma instância
• Você “monta” um sistema de arquivos numa
instância EC2 (comando padrão) — o sistema de
arquivos vai aparecer como um conjunto local de
diretórios e arquivos
• NFS v4 é padrão nas distribuições linux
mount –t nfs4
[file system DNS name]:/
/[user’s target directory]

21. O que é um “mount target”?
• Para acessar o seu sistema
de arquivos a partir das
instâncias numa VPC, você
cria mount targets na VPC
• Um mount target é um
endpoint NFSv4 endpoint
na sua VPC
• Um mount target tem um
endereço IP e um nome
DNS que você usa no seu
comando “mount”
AVAILABILITY ZONE 1
REGION
AVAILABILITY ZONE 2
AVAILABILITY ZONE 3
VPC
EC2
EC2
EC2
EC2
Mount
target

22. Juntando tudo, fica assim:
ZONA DE DISPONIBILIDADE 1
REGIÃO
ZONA DE DISPONIBILIDADE 2
ZONA DE DISPONIBILIDADE 3
VPC
EC2
EC2
EC2
EC2
File System do
Cliente

23. Existem três formas de configurar e
gerenciar um sistema de arquivos
• AWS Management Console
• AWS Command Line Interface (CLI)
• AWS Software Development Kit (SDK)

24. Cada uma lhe permite executar uma variedade de
tarefas de gerenciamento
• Criar um sistema de arquivos
• Criar e gerenciar mount targets
• Adicionar uma Tag num sistema de arquivos
• Excluir um sistema de arquivos
• Ver os detalhes dos sistemas de arquivos da sua conta AWS

25. Configurar e montar um sistema de arquivos leva
menos de um minuto
1. Criar um sistema de arquivos
2. Criar um “mount target” em cada AZ onde você
pretende acessar o sistema de arquivos
3. Habilitar o cliente NFS nas suas instâncias
4. Executar o comando “mount”

26. Segurança no seu Sistema de Arquivos

27. Vários mecanismos de Segurança
• Controle o tráfego de rede para e a partir dos seus sistemas de
arquivos (mount targets) usando os security groups e network
ACLs da sua VPC
• Controle o acesso aos arquivos e diretórios usando o
mecanismo padrão de permissões para diretórios e arquivos do
seu sistema operacional
• Controle o acesso administrativo (acesso a API) aos sistemas de
arquivos usando o AWS Identity and Access Management (IAM)

28. Apenas instâncias EC2 na VPC que você especificar
podem acessar o seu sistema de arquivos
Sistema de
arquivos do
Cliente
VPC
EC2
EC2
EC2
EC2
VPC
EC2
EC2
EC2
EC2

29. VPC
EC2
EC2
Security groups controlam quais instâncias na sua
VPC podem se conectar aos seus “mount targets”
Sistema de
arquivos do
Cliente
Security group:
sg-allowed
Security group:
Permit inbound traffic
from “sg-allowed”
Security group:
sg-not-allowed

30. EFS suporta permissões a nível de usuário para
arquivos e diretórios
• Configure permissões nos arquivos e diretórios para
especificar permissões read-write-execute para usuários
e grupos

31. Integração com IAM fornece segurança administrativa
• Use IAM policies para controlar quem usa
as APIs administrativas para criar,
gerenciar e excluir sistemas de arquivos
• EFS suporta permissões action-level e
resource-level

32. Disponibilidade Regional e Durabilidade

33. Em quais regiões posso usar o EFS?
• US-West (Oregon)
• US-East (Northern Virginia)
• EU (Ireland)

34. Dados são armazenados em múltiplas AZs para alta
disponibilidade e durabilidade
• Cada objeto do
sistema de
arquivos
(diretório,
arquivo, e link) é
redundantemente
armazenado em
múltiplas AZs na
mesma região
ZONA DE
DISPONIBILIDADE 1
REGIÃO
ZONA DE
DISPONIBILIDADE 2
ZONA DE
DISPONIBILIDADE 3
Amazon
EFS

35. Dados podem ser acessados a partir de qualquer AZ
na região enquanto mantém consistência total
• Suas instâncias EC2
podem se conectar ao
seu sistema de arquivos
EFS a partir de qualquer
AZ na região
• Todas as leituras e
escritas serão
totalmente consistentes
em todas as AZs — isto
é, uma leitura em uma
AZ retornará o dado
mais atualizado, mesmo
se este dado tiver sido
escrito em outra AZ
AVAILABILITY
ZONE 1
REGION
VPC
EC2
EC2
EC2
AVAILABILITY
ZONE 2
AVAILABILITY
ZONE 3
EC2
Write
Read

36. Sumário

37. Preço simples e previsível
• Com o EFS, você paga somente pelo espaço de storage que você
usa
• Sem valor mínimo ou adiantamentos de pagamento
– Não é necessário provisionar adiantado
– Nenhuma outra taxa ou cobrança
• Preço do EFS: $0.30/GB-month

38. ©2015, Amazon Web Services, Inc. or its affiliates. All rights reserved
Amazon Aurora: Novo Engine de Banco
de Dados Relacional da Amazon
Angelo Carvalho, Partner Solutions Architect, AWS

39. As arquiteturas de bancos de dados atuais são
monolíticas
Múltiplas camadas de
funcionalidades numa
única caixa
SQL
Transactions
Caching
Logging

40. As arquiteturas de bancos de dados atuais são
monolíticas
Mesmo quando você escala
horizontalmente, você ainda
está replicando a mesma
pilha de funcionalidades
SQL
Transactions
Caching
Logging
SQL
Transactions
Caching
Logging
Application

41. As arquiteturas de bancos de dados atuais são
monolíticas
SQL
Transactions
Caching
Logging
SQL
Transactions
Caching
Logging
Application Mesmo quando você escala
horizontalmente, você ainda
está replicando a mesma
pilha de funcionalidades

42. As arquiteturas de bancos de dados atuais são
monolíticas
SQL
Transactions
Caching
Logging
SQL
Transactions
Caching
Logging
Storage
Application Mesmo quando você escala
horizontalmente, você ainda
está replicando a mesma
pilha de funcionalidades

43. Isto é um problema.
Para custo. Para flexibilidade.
E para disponibilidade.

44. Reimaginando o banco de dados relacional
E se você estevise inventando os bancos de dados hoje?
Você não o desenharia da mesma forma como nós fizemos em 1970.
pelo menos não inteiramente.
Você costruirira algo que escala horizontalmente, que se recupera
automaticamente de falhas, e que faz uso dos serviços AWS
existentes.

45. Bancos de dados reimaginados para a nuvem
Velocidade and disponibilidade dos bancos de dados comerciais de última
geração
Simplicidade e custo-benefício dos bancos de dados open source
Compatiblidade com MySQL
Precificação simples pay as you go
Entregue como um serviço gerenciado

46. Uma arquitetura orientada a serviços aplicada a um
banco de dados
• Movemos as camadas de logging e
storage para um storage multi-tenant,
que escala horizontalmente e que é
otimizado para bancos de dados
• Integramos com oustros serviços
AWS como Amazon EC2, Amazon
VPC, Amazon DynamoDB, Amazon
SWF, and Amazon Route 53 para as
operações de control plane
• Integrado com o Amazon S3 para
backup contínuo com
99.999999999% de durabilidade
Control PlaneData Plane
Amazon
DynamoDB
Amazon SWF
Amazon Route 53
Logging + Storage
SQL
Transactions
Caching
Amazon S3

47. • Se inscreva para ter acesso ao preview em:
https://aws.amazon.com/rds/aurora/preview
• Agora disponível nas regiões US West (Oregon) e EU (Ireland), além da
região US East (N. Virginia)
• Milhares de clientes já foram convidados para o preview
• Agora mudando para o unlimited preview; aceitando todos os requests em
2–3 semanas
• Lançamento oficial do produto nos próximos meses
Aurora preview

48. Preço simplificado
• Sem licenças
• Sem lock-in
• Pague somente o que você usa
Descontos
• 44% para 1 ano de reserva
• 63% para 3 anos de reserva
vCPU Mem Hourly Price
db.r3.large 2 15.25 $0.29
db.r3.xlarge 4 30.5 $0.58
db.r3.2xlarge 8 61 $1.16
db.r3.4xlarge 16 122 $2.32
db.r3.8xlarge 32 244 $4.64
• Storage consumed, up to 64 TB, is $0.10/GB-month
• IOs consumed are billed at $0.20 per million I/O
• Prices are for Virginia
Categoria Enterprise, preço open source

49. Aurora Funciona com Suas Aplicações
Existentes

50. Estabelecendo nosso ecosistema
Business Intelligence Data Integration Query and Monitoring SI and Consulting
“It is great to see Amazon Aurora remains MySQL compatible; MariaDB connectors
work with Aurora seamlessly. Today, customers can take MariaDB Enterprise with
MariaDB MaxScale drivers and connect to Aurora, MariaDB, or MySQL without worrying about
compatibility. We look forward to working with the Aurora team in the future to further accelerate
innovation within the MySQL ecosystem.”— Roger Levy, VP Products, MariaDB

51. Amazon Aurora É Fácil de Usar

52. Simplifique o gerenciamento do banco de dados
• Crie um banco de dados em minutos
• Aplicação automática de patches
• Escale o processamento apertando um botão
• Backup contínuo para o S3
• Detecção de falhas e failover automático
Amazon RDS

53. Simplifique o gerenciamento do storage
• Read replicas estão disponíveis como targets para failover —sem
perda de dados
• Crie snapshots instantaneamente—sem impacto de performance
• Backup para o S3 contínuo e incremental
• Storage escala automaticamente até 64 TB—sem impacto de
performance ou disponibilidade
• Restriping, mirror repair, hot spot management e criptografia
automáticos

54. Simplifique a segurança dos dados
• Criptografia para proteger o dado armazenado
– AES-256; aceleração por hardware
– Todos os blocos no disco e no Amazon S3 são criptografados
– Gerenciamento de chaves via AWS KMS
• SSL para proteger o dado em transito
• Isolamento na rede via Amazon VPC por default
• Sem acesso direto aos nós
• Suporta padrões de segurançã de mercado e
certificações para proteção de dados
Storage
SQL
Transactions
Caching
Amazon S3
Application

55. Amazon Aurora é Altamente Disponível

56. Aurora storage
• Altamente disponível por padrão
– Replicação de 6 vias em 3 AZs
– 4 de 6 write quorum
• Diminui automaticamente para
3 de 4 se uma AZ está indisponível
– 3 de 6 read quorum
• SSD, escalável na horizontal, multi-tenant
– Storage escalável
– Até 64 TB
– Pague somente o que você usa
• Log-structured storage
– Muitos segmentos pequenos, cada um com seu
próprio redo log
– Log pages usados para regerar data pages
SQL
Transactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3

57. Escritas com baixa latência e consistentes
AZ 1 AZ 2
Primary
Instance
Standby
Instance
Amazon Elastic
Block Store
(EBS)
Amazon S3
EBS
mirror
EBS
EBS
mirror
AZ 1 AZ 3
Primary
Instance
Amazon S3
AZ 2
Replica
Instance
Melhorias
• Consistência—Tolerância a valores extremos
• Latência— replicação síncrona vs assíncrona
• Uso de network I/O significativamente mais eficiente
Log records
Binlog
Data
Double-write buffer
FRM files,
metadata
Type of writes
MySQL com standby Amazon Aurora
async
4/6 quorum
PiTR
Sequential
write
Sequential
write Distributed
writes

58. Self-healing, tolerante a falhas
• Perca duas cópias ou uma AZ sem impacto na leitura ou escrita
• Perca três cópias sem impacto de leitura
• Detecção de falha, replicação, e reparo automático
SQL
Transactio
n
AZ 1 AZ 2 AZ 3
Caching
SQL
Transactio
n
AZ 1 AZ 2 AZ 3
Caching
Read and write availabilityRead availability

59. Bancos de dados tradicionais
• Precisam fazer um replay dos logs
desde o último checkpoint
• Single-threaded no MySQL; requer
um número alto de acessos a
disco
Amazon Aurora
• Storage faz o replay dos redo
records sob demanda como parte
de uma leitura no disco
• Paralelo, distribuído, assíncrono
Checkpointed Data Redo Log
Crash no T0 requer
uma re-aplicação do SQL do redo
log desde o último checkpoint
T0 T0
Crash no T0 resultará em redo
logs sendo aplicados para cada segmento
sob demanda, em pararelo, de forma assíncrona
Recuperação de falha instantânea

60. Caches sobrevivem
• Nós movemos o cache para
fora do processo do banco de
dados
• Cache permanece quente no
evento de um restart do
banco de dados
• Instant crash recovery +
survivable cache =
recuperação de falhas
rapidamente e facilmente
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
Processo do cache vive fora do processo do Banco e
permanece quente mesmo após um restart no banco

61. Múltiplos alvos para failover—sem perda de dados
Page cache
invalidation
Aurora Master
30% Read
70% Write
Aurora Replica
100% New
Reads
Shared Multi-AZ Storage
MySQL Master
30% Read
70% Write
MySQL Replica
30% New Reads
70% Write
Single-threaded
binlog apply
Data Volume Data Volume
Escalando as leituras no MySQL
• Replicas precisam fazer o replay dos logs
• Replicas aumentam a carga no master
• Replica lag pode crescer indefinidamente
• Failover resulta em perda de dados

62. Simule falhas usando SQL
• Para causar a falha de um componente no nó do banco de dados:
ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]
• Para simular uma falha no storage:
ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN
[DISK index | NODE index] FOR INTERVAL interval
• Para simular uma falha na rede:
ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type
[TO {ALL | read_replica | availability_zone}] FOR INTERVAL interval

63. Amazon Aurora é Rápido

64. Performance de escrita (screenshot do console)
• MySQL Sysbench
• R3.8XL com 32 cores e
244 GB RAM
• 4 máquinas clientes
machines com 1,000
threads cada

65. Performance de leitura (screenshot do console)
• MySQL Sysbench
• R3.8XL com 32 cores e
244 GB RAM
• Único cliente with
1,000 threads

66. Lag na Read replica (screenshot do console)
• Aurora Replica com 7.27 ms replica lag com 13.8 K updates/second
• MySQL 5.6 no mesmo hardware tem ~2 s de lag com 2 K updates/second

67. Escritas escalam de acordo com o número de tabelas
-
10
20
30
40
50
60
70
10 100 1,000 10,000
ThousandsofWritesperSecond
Number of Tables
Performance de escrita e
quantidade de tabelas
Aurora
MySQL on I2.8XL
MySQL on I2.8XL with RAM Disk
RDS MySQL with 30,000 IOPS (Single AZ)
Tables
Amazon
Aurora
MySQL
I2.8XL
Local SSD
MySQL
I2.8XL
RAM Disk
RDS MySQL
30K IOPS
(Single AZ)
10 60,000 18,000 22,000 25,000
100 66,000 19,000 24,000 23,000
1,000 64,000 7,000 18,000 8,000
10,000 54,000 4,000 8,000 5,000
Write-only workload
1,000 connections
Query cache (default on for Amazon Aurora, off for MySQL)

68. Melhor concorrência
-
20
40
60
80
100
120
50 500 5,000
ThousandsofWritesperSecond
Concurrent Connections
Performance de escrita e
Concorrência
Aurora
RDS MySQL with 30,000 IOPS (Single AZ)
Conexões
Amazon
Aurora
RDS MySQL
30K IOPS
(Single AZ)
50 40,000 10,000
500 71,000 21,000
5,000 110,000 13,000
OLTP Workload
Variable connection count
250 tables
Query cache (default on for Amazon Aurora, off for MySQL)

69. Caching melhora a performance
-
50
100
150
200
250
300
350
400
100/0 50/50 0/100
ThousandsofOperations/Second
Read/Write Ratio
Performance com query cache on e off
Aurora without Caching
Aurora with Caching
RDS MySQL;30,000 IOPS (Single AZ) - without caching
RDS MySQL;30,000 IOPS (Single AZ) - with caching
R/W Ratio
Amazon
Aurora
Sem
Caching
Amazon
Aurora
Com
Caching
RDS MySQL
30K IOPS
Sem
Caching
RDS MySQL
30K IOPS
Com
Caching
100/0 160,000 375,000 35,000 19,000
50/50 130,000 93,000 24,000 20,000
0/100 64,000 64,000 16,000 16,000
OLTP workload
1,000 connections
250 tables
Query cache on/off tested

70. Replicas tem até 400 vezes menos lag
2.6 3.4 3.9 5.4
1,000 2,000 5,000 10,000
0
50,000
100,000
150,000
200,000
250,000
300,000
350,000
Updates per Second
ReadReplicaLaginMilliseconds
Lag na Read Replica
Aurora
RDS MySQL;30,000 IOPS (Single AZ)
Updates/
Second
Amazon
Aurora
RDS MySQL
30K IOPS
(Single AZ)
1,000 2.62 ms 0 s
2,000 3.42 ms 1 s
5,000 3.94 ms 60 s
10,000 5.38 ms 300 s
Write workload
250 tables
Query cache on for Amazon Aurora, off for MySQL (best
settings)

71. Obrigado!