BERLIN. 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved

Size: px

Start display at page:

Lawrence Harrington
6 years ago
Views:

3 Current DB architectures are monolithic SQL Transactions Multiple layers of functionality all on a single box Logging

4 Current DB architectures are monolithic SQL Transactions Logging Application SQL Transactions Logging Even when you scale it out, you re still replicating the same stack

5 Current DB architectures are monolithic SQL Transactions Logging Application SQL Transactions Logging Even when you scale it out, you re still replicating the same stack

6 Current DB architectures are monolithic SQL Transactions Logging Application SQL Transactions Logging Even when you scale it out, you re still replicating the same stack Storage

7 This is a problem. For cost. For flexibility. And for availability.

8 Reimagining the relational database What if you were inventing the database today? You wouldn t design it the way we did in At least not entirely. You d build something that can scale out, that is self-healing, and that leverages existing AWS services.

9 Relational databases reimagined for the cloud Speed and availability of high-end commercial databases Simplicity and cost-effectiveness of open source databases Drop-in compatibility with MySQL Simple pay as you go pricing Delivered as a managed service

A service-oriented architecture applied to the database Data

a multi-tenant, scale-out database-optimized storage service

VPC, Amazon DynamoDB, Amazon SWF, and Amazon Route 53 for

10 A service-oriented architecture applied to the database Data Plane Control Plane Moved the logging and storage layer into a multi-tenant, scale-out database-optimized storage service Integrated with other AWS services like Amazon EC2, Amazon VPC, Amazon DynamoDB, Amazon SWF, and Amazon Route 53 for control plane operations Integrated with Amazon S3 for continuous backup with % durability SQL Transactions Logging + Storage Amazon S3 Amazon DynamoDB Amazon SWF Amazon Route 53

11 Aurora preview Sign up for preview access at: Now available in US West (Oregon) and EU (Ireland), in addition to US East (N. Virginia) Thousands of customers already invited to the limited preview Now moving to unlimited preview; accepting all requests in 2 3 weeks Full service launch in the coming months

12 Enterprise grade, open source pricing vcpu Mem Hourly Price db.r3.large $0.29 db.r3.xlarge $0.58 db.r3.2xlarge 8 61 $1.16 db.r3.4xlarge $2.32 db.r3.8xlarge $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 Simple pricing No licenses No lock-in Pay only for what you use Discounts 44% with a 1-year RI 63% with a 3-year RI

13 Aurora Works with Your Existing Apps

Establishing our ecosystem It is great to see Amazon Aurora remains MySQL compatible;

Today, customers can take MariaDB Enterprise with MariaDB MaxScale drivers and connect

We look forward to working with the Aurora team in the future to further accelerate

14 Establishing our ecosystem 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 Business Intelligence Data Integration Query and Monitoring SI and Consulting

15 Amazon Aurora Is Easy to Use

16 Simplify database management Create a database in minutes Automated patching Push-button scale compute Continuous backups to S3 Amazon RDS Automatic failure detection and failover

17 Simplify storage management Read replicas are available as failover targets no data loss Instantly create user snapshots no performance impact Continuous, incremental backups to S3 Automatic storage scaling up to 64 TB no performance or availability impact Automatic restriping, mirror repair, hot spot management, encryption

18 Simplify data security Encryption to secure data at rest AES-256; hardware accelerated All blocks on disk and in Amazon S3 are encrypted Key management via AWS KMS SSL to secure data in transit Application SQL Transactions Network isolation via Amazon VPC by default No direct access to nodes Storage Supports industry standard security and data protection certifications Amazon S3

19 Amazon Aurora Is Highly Available

20 Aurora storage Highly available by default 6-way replication across 3 AZs 4 of 6 write quorum Automatic fallback to 3 of 4 if an AZ is unavailable 3 of 6 read quorum SSD, scale-out, multi-tenant storage Seamless storage scalability Up to 64 TB database size Only pay for what you use AZ 1 AZ 2 AZ 3 SQL Transactions Log-structured storage Many small segments, each with their own redo logs Log pages used to generate data pages Eliminates chatter between database and storage Amazon S3

21 Consistent, low-latency writes MySQL with standby AZ 1 AZ 2 Amazon Aurora AZ 1 AZ 2 AZ 3 Primary Instance Standby Instance Primary Instance Replica Instance async 4/6 quorum PiTR Amazon Elastic Block Store (EBS) EBS EBS mirror Sequential write EBS mirror Sequential write Distributed writes Amazon S3 Improvements Consistency tolerance to outliers Latency synchronous vs. asynchronous replication Significantly more efficient use of network I/O Amazon S3 Type of writes Log records Binlog Data Double-write buffer FRM files, metadata

22 Self-healing, fault-tolerant Lose two copies or an AZ failure without read or write availability impact Lose three copies without read availability impact Automatic detection, replication, and repair AZ 1 AZ 2 AZ 3 SQL Transaction AZ 1 AZ 2 AZ 3 SQL Transaction Read availability Read and write availability

23 Instant crash recovery Traditional databases Have to replay logs since the last checkpoint Single-threaded in MySQL; requires a large number of disk accesses Crash at T 0 requires a re-application of the SQL in the redo log since last checkpoint Amazon Aurora Underlying storage replays redo records on demand as part of a disk read Parallel, distributed, asynchronous Crash at T 0 will result in redo logs being applied to each segment on demand, in parallel, asynchronously Checkpointed Data Redo Log T 0 T 0

24 Survivable caches We moved the cache out of the database process process is outside the DB process and remains warm across a database restart Cache remains warm in the event of a database restart SQL Transactions SQL Transactions SQL Transactions Lets you resume fully loaded operations much faster Instant crash recovery + survivable cache = quick and easy recovery from DB failures

25 Multiple failover targets no data loss MySQL Master 70% Write 30% Read Single-threaded binlog apply MySQL Replica 70% Write 30% New Reads Aurora Master 70% Write 30% Read Page cache invalidation Aurora Replica 100% New Reads Data Volume Data Volume Shared Multi-AZ Storage MySQL read scaling Replicas must replay logs Replicas place additional load on master Replica lag can grow indefinitely Failover results in data loss

26 Simulate failures using SQL To cause the failure of a component at the database node: ALTER SYSTEM CRASH [{INSTANCE DISPATCHER NODE}] To simulate the failure of disks: ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN [DISK index NODE index] FOR INTERVAL interval To simulate the failure of networking: ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type [TO {ALL read_replica availability_zone}] FOR INTERVAL interval

27 Amazon Aurora Is Fast

28 Write performance (console screenshot) MySQL Sysbench R3.8XL with 32 cores and 244 GB RAM 4 client machines with 1,000 threads each

29 Read performance (console screenshot) MySQL Sysbench R3.8XL with 32 cores and 244 GB RAM Single client with 1,000 threads

30 Read replica lag (console screenshot) Aurora Replica with 7.27 ms replica lag at 13.8 K updates/second MySQL 5.6 on the same hardware has ~2 s lag at 2 K updates/second

31 Thousands of Writes per Second Writes scale with table count Write Performance and Table Count 70 Tables Amazon Aurora MySQL I2.8XL Local SSD MySQL I2.8XL RAM Disk RDS MySQL 30K IOPS (Single AZ) ,000 18,000 22,000 25, ,000 19,000 24,000 23, ,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) Number of Tables Aurora MySQL on I2.8XL MySQL on I2.8XL with RAM Disk RDS MySQL with 30,000 IOPS (Single AZ)

32 Thousands of Writes per Second Better concurrency Write Performance and Concurrency 120 Connections Amazon Aurora RDS MySQL 30K IOPS (Single AZ) 50 40,000 10, ,000 21,000 5, ,000 13, OLTP Workload Variable connection count 250 tables Query cache (default on for Amazon Aurora, off for MySQL) Concurrent Connections Aurora RDS MySQL with 30,000 IOPS (Single AZ)

33 Thousands of Operations/Second improves performance Performance with query cache on and off R/W Ratio Amazon Aurora Without Amazon Aurora With RDS MySQL 30K IOPS Without RDS MySQL 30K IOPS With 100/0 160, ,000 35,000 19, /50 130,000 93,000 24,000 20,000 0/100 64,000 64,000 16,000 16, OLTP workload 1,000 connections 250 tables Query cache on/off tested - 100/0 50/50 0/100 Read/Write Ratio Aurora without Aurora with RDS MySQL;30,000 IOPS (Single AZ) - without caching RDS MySQL;30,000 IOPS (Single AZ) - with caching

Read Replica Lag in Milliseconds Replicas have up to 400 times less lag Read Replica Lag Updates/ Second Amazon Aurora RDS MySQL 30K IOPS (Single AZ) 350.000 300.000 1,000 2.62 ms 0 s 250.000 2,000 3.

34 Read Replica Lag in Milliseconds Replicas have up to 400 times less lag Read Replica Lag Updates/ Second Amazon Aurora RDS MySQL 30K IOPS (Single AZ) , ms 0 s , ms 1 s , ms 60 s 10, ms 300 s Write workload 250 tables Query cache on for Amazon Aurora, off for MySQL (best settings) ,6 3,4 3,9 5, Updates per Second Aurora RDS MySQL;30,000 IOPS (Single AZ)

35 BERLIN

Amazon Aurora Relational databases reimagined.

Amazon Aurora Relational databases reimagined. Ronan Guilfoyle, Solutions Architect, AWS Brian Scanlan, Engineer, Intercom 2015, Amazon Web Services, Inc. or its affiliates. All rights reserved Current