Deep Dive Amazon Aurora

© 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Daniel Bento
Solutions Architect, AWS
DAT302
Deep Dive Amazon Aurora

O que é o Amazon Aurora?
Um banco de dados re imaginado para a nu ve m
 Velocidade e disponibilidade de bancos de dados
comerciais de alto nível
 Simplicidade e efetividade em custo de banco de dados
open source
 Compatibilidade com MySQL e PostgreSQL
 Preço simplificado: pague conforme o uso
Entregue como um serviço gerenciado

Reimaginando o banco relacional
1
2
3
Escalabilidade, arquitetura distribuída
Arquitetura orientada a serviços, aproveitando os serviços da AWS
Automatize tarefas administrativas - serviço totalmente gerenciado

Escalabilidade, arquitetura distribuída
 Sistema de armazenamento
distribuído, estruturado em log, criado
especificamente para o banco de
dados
 O volume de armazenamento é
distribuído em centenas de storage
nodes em três diferentes zonas de
disponibilidade
 Seis cópias de dados, duas cópias em
cada zona de disponibilidade, para
proteger contra falhas de AZ+1
Master Replica
Availability
Zone 1
Shared storage volume
Availability
Zone 2
Availability
Zone 3
Storage nodes with SSDs
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching

Aproveitando os serviços da AWS
Lambda
S3
IAM
CloudWatch
Invoque o Amazon Lambda a partir de stored procedures/triggers
Carregar dados do S3, armazenamento de snapshots e backups
Use roles do IAM para gerenciar o controle de acesso ao
banco de dados
Carregar métricas de sistemas e registros de auditoria com o
CloudWatch

Automatize tarefas administrativas
Desenho de schemas
Construção de Queries
Otimização de Queries
Recuperação automática de
falhas
Backup & recovery
Isolamento & segurança
Compliance
Escalabilidade a um clique
Aplicação de patchs
Monitoramento avançado
Manutenções de rotina
Aurora cuida das suas tarefas de gerenciamento de banco de dados,
liberando para que você se concentre em seus aplicativos e no negócio
You
AWS

Aurora é utilizado
por ¾ dos top 100
clientes da AWS
Serviço de mais
rápido crescimento na
história da AWS
Clientes que adotaram o Aurora

Quem está se mudando para Aurora e por quê?
Clientes usando engines
open source
 Maior desempenho - até 5x
 Melhor disponibilidade e durabilidade
 Redução de custo - até 60%
 Migração fácil; nenhuma alteração na
aplicação
 Um décimo do custo; sem licenças
 Integração com o ecossistema da nuvem
 Desempenho e disponibilidade comparáveis
 Ferramentas e serviços de migração
Clientes usando
engines comerciais

DESEMPENHO DO AURORA
5x mais rápido que o MySQL; 3x mais rápido que o
PostgreSQL

Aurora MySQL - desempenho
WRITE PERFORMANCE READ PERFORMANCE
MySQL SysBench: R4.16XL: 64cores / 488 GB RAM
Throughput de leitura e escrita do Aurora comparado ao MySQL 5.6
- baseado em benchmark padrão da indústria.
Aurora MySQL 5.6
0
100000
200000
300000
400000
500000
600000
700000
0
50000
100000
150000
200000
250000

Aurora PostgreSQL - desempenho
0
5000
10000
15000
20000
25000
30000
35000
40000
45000
10 15 20 25 30 35 40 45 50 55 60
Throughput,tps
Minutes
pgbench throughput over time, 150 GiB, 1024 clients
PostgreSQL (Single AZ) Amazon Aurora (Three AZs)
D u r a n t e a e x e c u ç ã o d o p g b e n c h , o t h r o u g h p u t é
3 x m a i s c o n s i s t e n t e q u e o P o s t g r e S Q L

Como conseguimos isso?
Fazendo menos IOs
Minimizando os pacotes de redes
Fazendo cache de resultados
Offload do motor do banco de dados
FAZENDO MENOS TRABALHO
Processamento assíncrono
Reduzindo o caminho de latência
Utilizando estruturas de dados sem lock
Agrupando operações em lote
SENDO MAIS EFICIENTE
BANCO DE DADOS É UMA QUESTÃO DE I/O
STORAGE DE REDE ATACHADO É UMA QUESTÃO DE PACOTES/SEGUNDOS
PROCESSAMENTO COM ALTO THROUGHPUT: TROCAS DE CONTEXTO

Aurora I/O profile
BINLOG DATA DOUBLE-WRITELOG FRM FILES
TYPE OF WRITE
MYSQL COM REPLICA
EBS mirrorEBS mirror
AZ 1 AZ 2
Amazon S3
EBS
Amazon Elastic
Block Store (EBS)
Primary
Instance
Replica
Instance
1
2
3
4
5
AZ 1 AZ 3
Primary
Instance
Amazon S3
AZ 2
Replica
Instance
ASYNC
4/6 QUORUM
DISTRIBUT
ED WRITES
Replica
Instance
AMAZON AURORA
780K transações
7,388K I/Os por milhões de tx (excluindo mirroring, standby)
Média 7.4 I/Os por transação
MySQL I/O profile por 30 min com Sysbench run
27.378K transações 35X MAIS
0.95 I/Os por transação (6X amplification) 7.7X MENOS
Aurora IO profile por 30 min com Sysbench run

Tráfego de IO no Aurora (storage node)
LOG RECORDS
Primary
Instance
INCOMING QUEUE
STORAGE NODE
S3 BACKUP
1
2
3
4
5
6
7
8
UPDATE
QUEUE
ACK
HOT
LOG
DATA
BLOCKS
POINT IN TIME
SNAPSHOT
GC
SCRUB
COALESCE
SORT
GROUP
PEER TO PEER GOSSIPPeer
Storage
Nodes
Todos os passos são assíncronos
Somente as etapas 1 e 2 estão no caminho de latência de
primeiro plano
Input queue é 46X menor do que MySQL (não amplificado,
por node)
Favorece operações sensíveis a latência
Usa espaço em disco como buffer para suportar picos de
atividade
OBSERVAÇÕES
Fluxo de IO
① Recebe o registro e adiciona para a fila em memória
② Persiste o registro e faz o ACK
③ Organiza os registros e identifica os gaps nos logs
④ Gossip com os pares para preencher os buracos
⑤ Agrupamento de registros de log em novas versões de
blocos de dados
⑥ Periodicamente grava os logs e novas versões dos blocos no
S3
⑦ Periodicamente realiza o garbage collect de versões antigas
⑧ Periodicamente valida os códigos CRC nos blocos

MONITORANDO O DESEMPENHO DO
BANCO DE DADOS

Performance Insights
E se você pudesse descobrir o
que está acontecendo com
seu banco de dados?
Performance Insights é a
resposta:
 Permite que você veja a
carga na instância
 Detalhamento dos
comandos SQL (drill down)

E SOBRE DISPONIBILIDADE?
“Desempenho somente importa se seu banco de dados
estiver rodando”

Storage replicado 6x
Sobre vive à falhas catastr óficas
Seis cópias em três zonas de disponibilidade
4 de 6 para quorum de escrita; 3 de 6 para quorum de leitura
Replicação ponto-a-ponto para reparos
Volume distribuído em centenas de nós de armazenamento
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
Read and write availabilityRead availability

Até 15 réplicas de leitura
Master
Read
Replica
Read
Replica
Read
Replica
Shared distributed storage volume
Reader end-point
► Até 15 réplicas de leitura em várias zonas de disponibilidade
► Replicação baseada em re-do log permite baixo lag de replicação – normalmente < 10ms
► End-point de leitura com balanceamento de carga e auto-scaling * NOVO *

Recuperação instantânea de falhas
BANCOS DE DADOS TRADICIONAIS
Tem que fazer o replay dos logs desde o
último checkpoint
Normalmente, 5 minutos entre os
checkpoints
Single thread no MySQL; requer um
grande número de acessos ao disco
AMAZON AURORA
O storage faz o replay dos registros de
redo sob demanda como parte da leitura
do disco
Paralelo, distribuído, assíncrono
Não há replay para inicialização
Checkpointed Data Redo Log
Falha em T0 requer a
reaplicação do SQL no
redo log desde o último
checkpoint
T0 T0
Falha em T0 resultará em redo logs sendo
aplicados em cada segmento sob demanda,
em paralelo, de maneira assíncrona

INOVAÇÕES RECENTES

Disponibilidade não é somente falha de HW
Solu çõe s para disponibilidade
1. Aplicação de patch no software do banco de dados
 Aplicação de Patch com Zero Downtime
2. Cópias do banco de dados em grande escala
 Fast Cloning
3. Erros de DBA que requerem restore do banco de dados
 Backtrack
4. Desastres
 Replicação Global

Aplicação de Patch com Zero downtime
Networking
state
Application
state
Storage Service
App
state
Net
state
App
state
Net
state
BeforeZDP
New DB
Engine
Old DB
Engine
New DB
Engine
Old DB
Engine
WithZDP
User sessions terminate
during patching
User sessions remain
active through patching
Storage Service

Fast database cloning
Clone seu banco de dados sem copiar os
dados
 Criação do clone é praticamente instantânea
 A cópia de dados acontece apenas na
gravação - quando os dados de volume
original e clonado diferem
Casos de usos
 Clonar um ambiente de produção para rodar
testes
 Reorganizar um banco de dados
 Salvar um snapshot point in time para
análise sem afetar o sistema em produção
PRODUCTION DATABASE
CLONE CLONE
CLONE
DEV/TEST
APPLICATIONS
BENCHMARKS
PRODUCTION
APPLICATIONS
PRODUCTION
APPLICATIONS

Database backtrack
O Backtrack leva o banco de dados para um ponto no tempo sem precisar fazer o restore
de backups
• Backtrack de uma operação de DML ou DDL
• Backtrack não é destrutivo. Você pode fazer o backtrack múltiplas vezes para encontrar o
ponto certo no tempo
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rewind to t1
Rewind to t3
Invisible Invisible

Como o Backtrack funciona?
Mantemos snapshots periódicos de cada segmento; também preservamos os redo logs
Para o backtrack, nós identificamos os snapshots dos segmentos
Aplicamos log streams aos snapshots dos segmentos em paralelo de maneira assíncrona
SEGMENT
SNAPSHOT
LOG
RECORDS
RECOVERY
POINT
SEGMENT 1
SEGMENT 2
SEGMENT 3
TIME

Online DDL: MySQL vs. Aurora
 Cópia completa da tabela em background
 Reconstrução de todos os índices - pode demorar
horas ou dias
 Operações de DDL afetam o throughput de DML
 Lock de tabelas utilizado para aplicar alterações
de DML
INDEX
LEAFLEAFLEAF LEAF
INDEX
ROOT
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
 Utiliza versionamento do schema para decodificar o bloco.
 Primitivas para atualizar para o schema mais recente
 Suporta adicionar colunas NULL no final da tabela
 Adicione colunas em qualquer lugar em breve.
MySQL Aurora

Desempenho do Online DDL
On r3.large
On r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.27 sec 3,960 sec 1,600 sec
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.06 sec 900 sec 1,080 sec

Replicação Global – camada lógica
DR mais rápido e localidade de dados aprimorada
Promova uma réplica de leitura
para master para uma
recuperação mais rápida em
caso de desastre
Coloque os dados perto das
aplicações de seus usuários em
diferentes regiões
Promover para master para
facilitar a migração

Replicação Global – camada física
AZ 1 AZ 3
Primary
Instance
AZ 2
Aurora
Replica
Aurora
Replica
ReplicationServer
ReplicationAgentREDO LOG FRM FILES
TIPO DE ESCRITA
Aurora
Replica
(optional)
Region 1: Primary Aurora Cluster Region 2: Read Replica
AZ 1
Replicação consistentemente rápida, de baixo-lag, com alta performance, para banco de dados
relacionais globais
• Replicação em escala global em segundos ou menos
• Infraestrutura de replicação dedicada garante desempenho
• Leituras locais, recuperação rápida, DR mais rigoroso e migrações transparentes entre regiões
Async.

AURORA SERVERLESS

Casos de uso para Aurora Serverless
• Aplicações de acesso infrequente (ex:
blog site de baixo volume)
• Aplicações com cargas intermitentes
ou imprevisíveis (ex: site de notícias)
• Banco de dados de teste que não são
utilizados a noite ou nos finais de
semana
• Consolidação de aplicações SaaS
multi-tenant

Aurora Serverless
• Início sob demanda,
desligado quando não está
em uso
• Escalabilidade automática
• Sem impacto para aplicação
quando estiver escalando
• Pague por segundo, mínimo
de 1 minuto.
WARM POOL
OF INSTANCES
APPLICATION
DATABASE STORAGE
SCALABLE DB CAPACITY
REQUEST ROUTER
DATABASE END-POINT

AURORA MULTI-MASTER

Gerenciador de Locks Distribuído
GLOBAL
RESOURCE
MANAGER
SQL
TRANSACTIONS
CACHING
LOGGING
SQL
TRANSACTIONS
CACHING
LOGGING
SHARED DISK CLUSTER
STORAGE
APPLICATION
LOCKING PROTOCOL MESSAGES
SHARED STORAGE
M1 M2 M3
M1 M1 M1M2 M3 M2
Cons
Tráfego de coerência de cache pesado (por lock)
Redes pode ser custoso
Escalabilidade negative com hot blocks
Pros
Todos os dados disponíveis para todos os nós
Fácil para construir aplicações
Coerência de cache semelhante aos dos
multiprocessadores

Consensus com two phase commit ou Paxos commit
DATA
RANGE #1
DATA
RANGE #2
DATA
RANGE #4
DATA
RANGE #3
DATA
RANGE #5
L
L L
L
L
SHARED NOTHING
SQL
TRANSACTIONS
CACHING
LOGGING
SQL
TRANSACTIONS
CACHING
LOGGING
APPLICATION
STORAGE STORAGE
Cons
Protocolos pesados de commits e mudança de
membership
Particionamento por range pode resultar em hot
partitions e não apenas hot blocks. Reparticionar é caro.
Operações cross partition são caras. Melhores em
pequenas requisições.
Pros
Query dividida e enviada para o data node
Menos tráfego de coerência - apenas para
commits
Pode escalar para muitos nós

Resolução de conflitos com distributed ledgers
• Os nós do DB sabem a
ordem das transações
daquele nó
• Os nós de storage sabem a
ordem das transações
aplicadas naquele nó
• Só há conflitos quando os
dados são alterados ao
mesmo tempo em vários
nós do banco de dados e em
vários nós de
armazenamento
• Necessário menor
coordenação
2 3 4 5 61
BT1 [P1]
BT2 [P1]
BT3 [P1]
BT4 [P1]
BT1
BT2
BT3
BT4
Page1
Quorum
OT1
OT2
OT3
OT4
Page 1 Page 2
2 3 4 5 61
OT1[P2]
OT2[P2]
OT3[P2]
OT4[P2]
PAGE1 PAGE2
MASTER
MASTER
Page 2

Resolução de conflitos hierárquicos
• Ambos masters estão
escrevendo em duas
páginas P1 e P2
• BLUE master vence quórum
na página P1; ORANGE
master vence na P2
• Ambos masters reconhecem
o conflito e tem duas
escolhas: (1) roll back ou (2)
escalar para o regional
resolver
• O regional resolver decide
quem vence o desempate.
2 3 4 5 61
BT1 [P1]
OT1 [P1]
2 3 4 5 61
OT1[P2]
BT1[P2]
PAGE1 PAGE2
MASTER
MASTER
BT1 OT1
Regional
resolver
Page 1 Page 2 Page 1 Page 2
Quorum
X X

Multi-região Multi-Master
Escritas aceitas localmente
Controle de concorrência otimista – sem gerenciador
de locks distribuído, sem chatty protocol para
gerenciamento de lock
REGION 1 REGION 2
HEAD NODES HEAD NODES
MULTI-AZ STORAGE VOLUME MULTI-AZ STORAGE VOLUME
LOCAL PARTITION LOCAL PARTITIONREMOTE PARTITION REMOTE PARTITION
Conflitos resolvidos hierarquicamente – nos head
nodes, nos storage nodes, nas AZs e árbitros de
nível regional
Escala de desempenho quase linear quando não
há ou há baixos níveis de conflitos

AURORA PARALLEL QUERY

Parallel query - Processamento
Storage do Aurora tem milhares de CPUs
 Oportunidade para executar e paralelizar o
processamento de queries utilizando a frota do
storage
 Movendo o processamento para próximos dos dados
reduz o tráfego de rede e a latência
Entretanto, existem desafios
 Dado armazenado no storage node não é
particionado – requer full scans
 Dados podem estar em vôo
 As visualizações de leitura podem não permitir a
visualização dos dados mais recentes
 Nem todas as funções poder ser executadas nos
storage nodes
DATABASE NODE
STORAGE NODES
PUSH DOWN
PREDICATES
AGGREGATE
RESULTS

Gostaria de experimentar novos recursos?
AURORA SERVERLESS AURORA MULTI-MASTER
AURORA PARALLEL QUERY
PERFORMANC
E INSIGHTS
Escale a
capacidade do BD
para atender às
necessidades dos
apps
Escalabilidad
e de escritas
em múltiplas
AZs
Apromoramento
do desempenho
de queries
PERFORMANCE INSIGHTS
Avaliação de
carga e tuning de
desempenho
I nscre va -se para os pre vie ws: aws.amazon.com/rds/aurora/

Muito Obrigado!

Por favor, preencha a pesquisa da
sessão no aplicativo mobile do
Summit.

Deep Dive Amazon Aurora

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Deep Dive Amazon Aurora

Semelhante a Deep Dive Amazon Aurora (20)

Mais de Amazon Web Services

Mais de Amazon Web Services (20)

Deep Dive Amazon Aurora