Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Specialist SA, WWSO, AWS ::: AWS Data Roadshow 2023

AWS DATA ROADSHOW 2023
© 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved.
Dalyoung Jung
APAC MySQL Specialist Solutions Architect
Amazon Web Services
Deep dive into Amazon Aurora

• Designed for unparalleled high performance and availability at global scale with full MySQL and PostgreSQL compatibility at 1/10th the cost of
commercial databases
▪ 5x throughput of standard
MySQL and 3x of standard
PostgreSQL
▪ Scale out up to 15 read replicas
▪ Decoupled storage and compute
enabling cost optimization
▪ Fast database cloning
▪ Distributed, dynamically scaling
storage subsystem
성능 및 확장성
▪ 6 copies of data across 3 AZs
(customers pays for 1)
▪ Automatic, continuous,
incremental backups with point-
in-time recovery (PITR)
▪ Fault-tolerant, self-healing, auto-
scaling storage
▪ Global Database for disaster
recovery
가용성 및 내구성
▪ Network isolation
▪ Encryption at rest/in transit
▪ Supports multiple secure
authentication mechanisms and
audit controls
높은 보안성
▪ Automates time-consuming
management of administration
tasks like hardware provisioning,
database setup, patching, and
backups
▪ Serverless configuration options
완전한 관리형
Amazon Aurora

Architecture

Storage
nodes
Shared storage volume
SQL
Transaction
Caching
Availability Zone 1
SQL
Transaction
Caching
Availability Zone 2
SQL
Transaction
Caching
Availability Zone 3
Instance
nodes
SQL
Transaction
Caching
Availability Zone 1
SQL
Transaction
Caching
Availability Zone 2
SQL
Transaction
Caching
Availability Zone 3
Instance
nodes
Network Storage
logging logging logging
Network Storage Network Storage
Storage
nodes
Amazon RDS Amazon Aurora
Amazon RDS vs Aurora

RO
Application
RW
Application
RO
Application
Async
Invalidation
& Update
Async
invalidation
& update
Write log
records
Read
blocks
RW
Aurora
storage
RO
RO
RO
RO
Availability Zone 3
Availability Zone 2
Availability Zone 1
db.r6i.4xlarge db.serverless
db.r6g.4xlarge
6
5
4
3
2
1
AWS JDBC
Aurora storage and replicas

Replication
agents
Region B
Region A
Availability Zone 3
Availability Zone 1 Availability Zone 2
Availability Zone 3
Amazon Aurora Global Database
Aurora storage
RO
Application
RW
Application
RO
Application
Replication
servers Aurora storage
RO
Application Application
RO
Application
RO
RW
DR
primary DB cluster secondary DB cluster

Replication
agents
Region B
Region A
Availability Zone 3
Availability Zone 3
Managed planned failover
Aurora storage
RO
Application
RW
Application
RO
Application
Replication
RO
RO
Application
RO
RW
primary DB cluster secondary DB cluster
RO
verify
Replication
servers
Replication
agents
primary DB cluster
secondary DB cluster

Region A
Availability Zone 3
Aurora storage
RO
Application
RW
Application
RO
Application
Replication
servers
Region B
Availability Zone 3
Replication
agents Aurora storage
R
O
Applicatio
n
Applicatio
n
R
O
Applicatio
n
R
O
Region C
Availability Zone 3
Replication
R
O
Applicatio
n
Applicatio
n
R
O
Region D
Availability Zone 3
Replication
db.serverless

Replication
agents
Region B
Region A
Availability Zone 3
Availability Zone 3
Write Forwarding
Aurora storage
RO
Application
RW
Application
RO
Application
Replication
RO
RO
Application
RO
Application
--enable-global-write-forwarding
TUNNEL

Aurora Storage Internals

Aurora PostgreSQL: Writing less
Aurora
update t set y = 6
Block in
memory
t-v1
t-v2
t-v3
Aurora
storage
t-v2
t-v3
No engine
checkpoint
=
no FPW
Block in
memory
PostgreSQL
t-v1
t-v2
t-v3
Checkpoint
Datafile
t-v2
Full
block
t-v3
WAL
Archive
4K
4K
8K
update t set y = 6
Amazon Simple Storage
Service (Amazon S3)
recovery
in minutes continuous
& parallel
coalesce
recovery in
seconds

Aurora MySQL: Writing less
Aurora
insert
Block in
memory
row1
row2
Aurora
storage
row2
No engine
checkpoint
=
no
doublewrite
buffer
Block in
memory
MySQL
row1
row2
Checkpoint
Datafile
row2
Full
block
log
Archive
4K
4K
16K
insert
Service (Amazon S3)
recovery
in minutes continuous
& parallel
coalesce
recovery in
seconds
4K
4K
doublewrite
buffer

Aurora
RW
Storage Node
Incoming queue Data
blocks
Update
queue
Hot log
Peer storage
nodes
Coalesce
Amazon S3
A A
C C
B
A B C
B C
A

Storage Management – Dynamic resizing
new partitions
every hour
drop
existing
create
new
2 hour
spike drop
existing
create
new
drop
the
spike
used space
inside the db
used storage
space
2X extra
storage
costs

Availability Zone 2
RO
Application
Fast clones
RW
Application
RW
Reporting
application
Write log
records
Read
blocks
Aurora
storage
Primary storage
Clone storage
Clone

Fast clone example
0
5000
10000
15000
20000
25000
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57 60 63 66 69 72 75 78
Transactions
per
second
(TPS)
Minutes
PGBench RW Scale 10K - Target Rate 20K TPS
Main Database Clone Database

Export to S3 via clone
Amazon Aurora
Primary(R/W)
Snapshot
Aurora storage
Service (Amazon S3)
Aurora storage
Amazon Aurora
CLONE
Amazon Aurora
Primary Snapshot
parallel export – Aurora MySQL

Aurora Backtrack
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rewind to t1
Rewind to t3
Invisible Invisible
Backtrack brings the database to a point in time without requiring restore from backups
Recover from an unintentional DML or DDL operation
Backtrack is not destructive; you can backtrack multiple times to find the right point in time
Also useful for QA (rewind your DB between test runs)
NEW! Backtrack Support for Aurora MySQL Version 3 (As of Jan 4, 2023)

Performance Features
Amazon Aurora
Parallel Query
(MySQL)
Query Plan
Management
(PostgreSQL)
Cluster Cache
Management
(PostgreSQL)
Logical
Replication
Cache
(PostgreSQL)

QPM in Aurora PostgreSQL
• Controls how and when query execution plans change
• Prevents plan regressions or plan flips
• Improves plan stability by forcing the optimizer to choose from a small number of known,
good plans
• Optimize plans centrally and then distribute them
• Automatically detects a new minimum-cost plan discovered by the optimizer

Performance Insights

Performance Insights – Zoom In

Plan change
Before
• Aggregate (cost=3804.15..3804.16 rows=1 width=16)
• -> Nested Loop (cost=12.67..3802.61 rows=307 width=8)
• -> Index Scan using pgbench_branches_pkey on pgbench_branches b (cost=0.29..16.60 rows=2 width=8)
• Index Cond: (bid = ANY ('{1,4}'::integer[]))
• -> Bitmap Heap Scan on pgbench_history h (cost=12.39..1891.47 rows=154 width=8)
• Recheck Cond: (bid = b.bid)
• Filter: ((mtime >= (now() - '01:00:00'::interval)) AND (mtime <= (now() - '00:30:00'::interval)))
• -> Bitmap Index Scan on i_p_bid (cost=0.00..12.35 rows=522 width=0)
• Index Cond: (bid = b.bid)
After
• Aggregate (cost=171092.96..171092.97 rows=1 width=16)
• -> Hash Join (cost=329.02..171091.42 rows=307 width=8)
• Hash Cond: (h.bid = b.bid)
• -> Seq Scan on pgbench_history h (cost=0.00..166712.20 rows=1542280 width=8)
• Filter: ((mtime >= (now() - '01:00:00'::interval)) AND (mtime <= (now() - '00:30:00'::interval)))
• -> Hash (cost=329.00..329.00 rows=2 width=8)
• -> Seq Scan on pgbench_branches b (cost=0.00..329.00 rows=2 width=8)
• Filter: (bid = ANY ('{1,4}'::integer[]))
• enable_bitmapscan=off
• enable_indexscan=off
• stats change?
• index change?
• config change?

1. Capture plans
2. Approve plans
Use baseline
3. Evolve Unapproved plans
Compare
4. Re-test Approved plans
and possibly change to
Preferred or Rejected
Automatically happens if query runs
more than once
If an Unapproved plan is faster (slower),
Approve (Reject) it.
First captured plan is automatically
approved
5. See the effect of changing an optimizer
setting for any set of statements, without
risk of plan regression. Any new plans are
created with status ‘Unapproved’.
Using query plan stability and evolution

Plan selection process

QPM – Use plan baselines

Cluster Cache Management
• The cluster cache management (CCM) feature improves the performance of the
new primary/writer instance after failover occurs
• With CCM, you can designate a specific Aurora PostgreSQL replica as the failover
target
• CCM ensures that data in the designated replica’s cache is synchronized with the
data in the primary DB instance’s cache
• If a failover occurs, the designated reader uses values in its warm cache
immediately when it is promoted to the new writer DB instance

Availability Zone 3
RO
Reporting
Application
Cluster Cache Management (CCM) Feature
RW
Application
RO
Application
Async
Invalidation
& Update
Availability Zone 1
Availability Zone 2
RO
RO
RO
RO
Failover
Priority
1 or
higher
apg_ccm_enabled=on
bloom filter - replica cache
block addresses to load Failover
Priority
0
Failover
Priority
0
Distributed Log Based Storage

Failover behavior with Cluster Cache Management
0
50,000
100,000
150,000
200,000
250,000
300,000
350,000
400,000
0 60 120 180 240 300 360 420 480 540 600 660 720 780 840 900 960 1020 1080 1140 1200
Transactions
per
Second
(TPS)
Seconds
PGBench 20X RO / 1X RW 160GB Cached - Failover at 600 Seconds
Baseline CCM Enabled
32 seconds
340 seconds

Aurora PostgreSQL – Logical replication cache
Aurora storage
Amazon
Aurora
write wal log
(needed for logical decoding)
write transaction
log
Users /
Applications
INSERT logical
decoding
AWS Database Migration
Service (AWS DMS)
INSERT
read wal log
(needed for logical decoding)
wal log
cache
cache read

Driving down query latency using Parallel Query (PQ)
• Use cases:
• HTAP, light analytics (aggregations)
• Scheduled reporting jobs on OLTP data
• What it is:
• Aurora storage fleet has thousands of
CPUs
• Push down and parallelize query
processing using the storage fleet
• Moving processing close to data
reduces network traffic and latency
DATABASE NODE
STORAGE NODES
PUSH DOWN
PREDICATES
AGGREGATE
RESULTS

Working with Parallel Query
How it works:
• DB instance has max. number of PQ threads, based on type
• Available for any DB cluster versions >=1.23 (5.6), >=2.09 (5.7) , 3.0
• Enable/disable PQ at session and global level
• EXPLAIN plan will show if PQ is used (“Using parallel query” under ”Extra”)
• Make sure to enable hash joins optimization
• Improved parallel query support for Aurora MySQL 3
Limitations:
• Row format COMPACT and DYNAMIC only
• Partitioned tables not supported(Supported in Aurora MySQL3)
• Blobs, spatial, queries with data on external pages not supported
• Not available with

PQ performance results

Aurora MySQL Enhancements

Aurora MySQL
enhanced binlog
Binlog
Enhanced
Binlog
• greatly reduced
overhead for enabling
binlog
• reduced cost to read
binlogs for cdc

Instant DDL – Aurora MySQL 3 (8.0)
• Supersedes “Lab Mode” Fast DDL.
• Compatible with the instant DDL from community MySQL 8.0
• ALGORITHM=INSTANT with the ALTER TABLE statement.
• Only modifies metadata in the data dictionary. No exclusive metadata locks.
• Not all operations are supported
https://dev.mysql.com/doc/refman/8.0/en/innodb-online-ddl-operations.html
• Limitations* –
• No temp table support
• No compressed row format support
• Only adds last column
*Inherited from MySQL and apply to both Aurora and MySQL Community

Aurora Serverless

Amazon Aurora Serverless
On-demand and automatically scaling configuration
Automatically scales capacity based on application needs
Simple pay-per-use pricing per second
Scales instantly to support demanding applications
Worry-free database capacity management

Instant, in-place scaling
• Scales in place in under a second by adding
more CPU and memory resources and billed
by the second
• No impact due to scaling even when running
hundreds of thousands of transactions
AWS Lambda
Amazon Aurora

Aurora – challenging workload example
db.r6g.4xlarge

Aurora - challenging workload example
db.r6g.4xlarge

Aurora Serverless – CPU scaling
db.serverless
per second scale
up by 8% of max
ACU configured
(128)

db.r6g.4xlarge

db.r6g.4xlarge
point select canary query
10X increase in average latency

Aurora Serverless – memory and CPU scaling
serverless scales up
providing additional
memory and CPU
db.serverless

Aurora Serverless – memory scaling
8X reduction in latency
point select canary query

Buffer pool resizing
Buffer pool
Access frequency
Storage volume
Page
read
Page
read
Evict cold pages
Shrink memory
Reads
Default memory allocation: 75% for buffer
pool and 25% for heap
Buffer pool size scaled along with capacity
Parameters automatically adjusted:
MySQL: innodb_buffer_pool_size
PostgreSQL: shared_buffers
Buffer pool scaled down through a
combination of least frequently used (LFU) and
least recently used (LRU) algorithms

Blue/Green Deployment

How does Amazon RDS Blue/Green Deployment
work?
Users /
Applications
DB endpoint
Logical replication from ‘blue’
to ‘green’
Blue
Primary
Green
Primary
Future
Production
Current
Production
AWS Cloud
Amazon RDS
• Creates a mirrored copy of
the current production
environment (blue) as the
green environment (future
production)
• Sets up logical replication
between blue primary and
green primary
• Modify green, add/remove
replicas, and test changes in
green environment before
switchover

Amazon Aurora Blue/Green Deployments
Region
Availability Zone
3
Availability Zone
1
Availability Zone
2
Aurora storage
RW
Users /
Applications
db cluster
endpoint
RO
Source
mycluster
Aurora MySQL 2.10.2 (5.7)
Aurora storage
RO
RW RO
Target
mycluster-green-x1234
• Major/Minor Upgrades
• Schema Changes
• Static Parameter Changes
• Maintenance Updates
create-blue-green-deployment
RO RO
RO
RO
switchover-blue-green-deployment
delete-blue-green-deployment
Target
mycluster-green-x1234
AVAILABLE
SWITCHOVER_IN_PROGRESS
SWITCHOVER_COMPLETED
Target
mycluster
Source
mycluster-old1
customer verification

Aurora I/O-Optimized
Feature

Compute Storage I/O
Backup
Data transfer
Aurora Global Database
Aurora Backtrack
Export to S3
Aurora Parallel Query*
Fast Database Cloning*
Amazon RDS Blue/Green Deployments*
Every DB Cluster
Most DB Cluster
Use case or
feature dependent
Cluster cache management*
The Aurora bill has several components

Cost Monitoring
Cost Optimization
Read I/O Unit : Number of Physical Page reads (from Aurora Storage)
Read I/O Cost : Per 1 million requests (example: $0.20 per 1 million requests for AWS us-east-1 region)
CloudWatch Metrics: [Billed] Volume Read IOPS (Count)
✓ Tune SQL queries to optimize read operations and avoid additional or full/ large rows scan on table.
✓ Scale DB Instance to optimize read I/O (monitor CloudWatch metrics Buffer Cache Hit Ratio (Percent))
✓ Tune autovacuum process on Aurora PostgreSQL for tables with high DML operations to avoid bloated tables/indexes access
✓ Use logical backup only when it’s required to avoid full table scan for every table backup
✓ Understand Aurora I/O usage impact while using Aurora specific features like Aurora Parallel Query (Aurora MySQL) and Aurora
Cluster Cache Management (Aurora PostgreSQL)
I/O cost costs are generated when reading
from Aurora

Writer
Read
replica
Read
replica
Read
replica
Shared distributed storage volume
AZ3
AZ2
AZ1
A p p
Read I/O’s depends on
DB Cache size i.e. DB instance size
Where rows are stored physically
Data access pattern
Configuration changes can make I/O costs change

Writer
Read
replica
Read
replica
AZ3
AZ2
AZ1
A p p
No cost for redo log record replication
Write I/O cost for one copy of data only
Includes explicit & implicit write operations by SQL
query or DB engine process
Aurora write I/O cost

SQL query access pattern & Aurora I/O
• Difference between rows examined and rows sent may incur additional I/O’s
• Extra 8 rows may cause 8 or less number of data pages access
• Review SQL query execution plan for efficient index utilization
Efficient SQL query pattern & Aurora I/O
rows examined rows sent extra rows processing
10 2 8
SQL query execution
rows examined rows sent extra rows processing
2 2 0
SQL query execution
The way queries are structured can affect I/O costs

P R E D I C T A B L E P R I C E F O R A L L W O R K L O A D S
I M P R O V E D P R I C E - P E R F O R M A N C E F O R I / O H E A V Y W O R K L O A D S
New cluster configuration that allows customers to pay for
compute and storage only, with no charges for read/write IOs
Predictable price for all workloads
Improved price-performance with up to 40% cost savings
when I/O spend exceeds 25% of total Aurora database spend.
Available for Aurora PostgreSQL and Aurora MySQL across
Aurora Serverless v2, On-Demand, and Reserved Instances
With Reserved Instances, customers get additional I/O savings
Amazon Aurora I/O-Optimized

• Aurora I/O-Optimized is a cluster storage configuration
• Aurora cluster can modify storage option (standard to I/O-Optimized) once in a month and
switch back anytime.
• Available from Aurora PostgreSQL 13.x and Aurora MySQL 3.0.3.1 onwards.
• Compatible with
Intel-based Aurora database instance types such as t3, r5, r6i
Graviton-based database instance types such as t4g, r6g, and x2g
Aurora Serverless v2
• Aurora Global database cluster can have different Aurora storage config at cluster level i.e.
primary & secondary clusters can configure with different configuration.
I/O-Optimized can be configured at a cluster level

Aurora
Aurora Standard Aurora I/O-Optimized
• Compute (On-demand / RI )
• Storage (standard – pay-per-use )
• I/O (Pay-per-request)
• Other cost components
• Compute (On-demand / RI) + 30%
• Storage (Standard – pay-per-use) + 125%
• I/O – No additional charges for read and
write I/Os*
• Other cost components
*Aurora I/O cost applicable for Aurora cluster using standard I/O configuration while using Aurora Global DB and no Aurora I/O cost
for primary or secondary cluster is using IO-optimized.
Customers now have more flexibility to choose based on their price predictability and
price-performance needs …
Aurora I/O-Optimized is available alongside Aurora
Standard

Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Specialist SA, WWSO, AWS ::: AWS Data Roadshow 2023

Recommended

More Related Content

What's hot (20)

Similar to Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Specialist SA, WWSO, AWS ::: AWS Data Roadshow 2023 (15)

More from Amazon Web Services Korea (19)

Recently uploaded (20)

Internal Architecture of Amazon Aurora (Level 400) - 발표자: 정달영, APAC RDS Specialist SA, WWSO, AWS ::: AWS Data Roadshow 2023