Deep Dive on Amazon Aurora · 2020-06-07 · © 2019, Amazon Web Services, Inc. or its affiliates....

© 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

Deep Dive on Amazon Aurora

Yoav EilatSenior Product Manager, Amazon Aurora and Amazon RDSAWS


Amazon Aurora…Enterprise database at open source price

Delivered as a managed service

Amazon Aurora

コマーシャルデータベースの性能と可用性

オープンソースデータベースのシンプルさとコスト効果

MySQL, PostgreSQLと互換性がある

利用した分だけお支払い


Aurora scale-out, distributed architecture

Amazon Aurora向けに作られた log-structured 分散ストレージシステム

ストレージボリュームは3AZに数百〜数千インスタンスのストレージノードを配置

それぞれのAZに2つずつ、計6つのデータのコピーを保存することでAZ+1の障害に対応

データは10GBずつ“protection groups”に保存され、64TBまで自動的にスケールアップ

Shared storage volume

Storage nodes with SSDs

Availability Zone 1

SQL

Transactions

Caching

Availability Zone 2

SQL

Transactions

Caching

Availability Zone 3

SQL

Transactions

Caching


Six-way replicated storage

SQL

Transaction

AZ 1 AZ 2 AZ 3

Caching

SQL

Transaction

AZ 1 AZ 2 AZ 3

Caching


2 3 4 5 61

[T1]

Quorum

[T2]

PAGE 1

APPLICATION

Shared Storage Volume

[T3]

[T4]


I/O flow in Aurora storage node① ログレコードを受信してインメモリキューに

追加

② ホットログとACKでレコードを保持

③ レコードを整理し、ログのギャップを特定

④ ギャップを埋めるためにゴシッププロトコルを利用

⑤ ログレコードを新しいページバージョンに結合

⑥ 定期的にログと新しいページのバージョンをS3に保存

⑦ 定期的に古いバージョンをガベージコレクション

⑧ ブロックのCRCコードを定期的に検証

Notes:すべてのステップは非同期

ステップ1と2だけがフォアグラウンド待ち時間がある

LOG RECORDS

Database Instance

INCOMING QUEUE

STORAGE NODE

S3 BACKUP

1

2

3

4

5

6

7

8

UPDATE QUEUE

ACK

HOTLOG

DATAPAGES

CONTINUOUS BACKUP

GC

SCRUB

COALESCE

SORTGROUP

PEER TO PEER GOSSIPPeerStorageNodes


Write and read throughputAurora MySQL is 5x faster than MySQL

0

50,000

100,000

150,000

200,000

250,000

MySQL 5.6 MySQL 5.7 MySQL 8.0

Aurora 5.6 Aurora 5.7

0

100,000

200,000

300,000

400,000

500,000

600,000

700,000

800,000

MySQL 5.6 MySQL 5.7 MySQL 8.0

Aurora 5.6 Aurora 5.7

Write Throughput Read Throughput

Using Sysbench with 250 tables and 200,000 rows per table on R4.16XL


Bulk data load performanceAurora MySQL loads data 2.5x faster than MySQL

Data loading

Data loading

Index build

Index build

0 100 200 300 400 500 600 700 800

MySQL

Amazon

Aurora

Runtime (sec.)

10 Sysbench Tables, 10MM rows per each


Bulk data load performanceAurora PostgreSQL loads data 2x faster than PostgreSQL

Copy In

Copy In

Vacuum

Vacuum

Index Build

Index Build

0 500 1000 1500 2000 2500 3000 3500 4000

PostgreSQL

Amazon Aurora

Runtime (seconds)

pgbench initialization, scale 10000 (150 GiB)

86% reduction in vacuum time


Continuous HW upgrades to boost performance

Aurora MySQL – 2015 to 2018

R3.8xl (2015)32 cores, 256-GB memory

R4.16xl (2017)64 cores, 512-GB memory

R5.24xl (new in 2019)96 cores, 768-GB memory

0

50

100

150

200

250

2015 2016 2017 2018

Max write throughput – up 100%

0

100

200

300

400

500

600

700

800

2015 2016 2017 2018

Max read throughput – up 42%


Aurora Read Replicas

複数のアベイラビリティーゾーンに最大15の昇格可能なリードレプリカ

REDOログベースの（物理）レプリケーションにより、レプリカの遅延が低い（通常10ms未満）

フェイルオーバーの順序を設定可能なカスタムリーダーエンドポイント

MasterRead

replicaRead

replicaRead

replica

Shared distributed storage volume

Reader end-point #1 Reader end-point #2


MySQL vs. Aurora I/O profile

BINLOG DATA DOUBLE-WRITELOG FRM FILES

TYPE OF WRITE

MYSQL WITH REPLICA

EBS mirrorEBS mirror

AZ 1 AZ 2

EBSAmazon Elastic

Block Store (EBS)

PrimaryInstance

ReplicaInstance

1

2

3

4

5

AZ 1 AZ 3

PrimaryInstance

AZ 2

ReplicaInstance

ASYNC4/6 QUORUM

DISTRIBUTED WRITES

ReplicaInstance

Amazon S3

AMAZON AURORA

0.78MM transactions

7.4 I/Os per transaction

MySQL I/O profile for 30 min Sysbench run

27MM transactions 35X MORE

0.95 I/Os per transaction 7.7X LESS

Aurora IO profile for 30 min Sysbench run

Amazon S3


Aurora read replicas are dedicated to reads

論理的な完全な変更

マスターと同じ書き込みワークロード

独立したストレージ

物理的な差分の変更

書き込みが発生しないレプリカ

シェアードストレージ

PAGE CACHEUPDATE

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-THREADEDBINLOG APPLY

Data Volume Data Volume

MYSQL READ SCALING AMAZON AURORA READ SCALING


Aurora read scaling options

• クラスタ毎に昇格可能な15台のリードレプリカ

• 自動的に追加・削除を行うAuto-scalingレプリカ

• リージョンを跨いだリードレプリカ(Aurora Global Database)

• MySQLからbinlogを利用したレプリケーション

Asynchronous replication

BI/reporting application server

Read only

Read/write Primary

Read replica


Aurora Global DatabaseFaster disaster recovery and enhanced data locality

Portland, OR

M R RR R

R R

R R

Columbus, OH

Washington D.C.

Dublin


Global replication performanceLogical vs. physical replication

Logical replication with MTS Physical replication

0

100

200

300

400

500

600

0

50,000

100,000

150,000

200,000

250,000

seconds

QP

S QPS

Lag

0.00

0.50

1.00

1.50

2.00

2.50

3.00

3.50

4.00

4.50

5.00

0

50,000

100,000

150,000

200,000

250,000

seconds

QP

S QPS

Lag

SysBench OLTP (write-only) stepped every 600 seconds on R4.16xlarge


Aurora Parallel QuerySpeeding up analytical queries

Auroraストレージには数千のCPUが存在する• クエリ処理をプッシュダウンして並列化

• 処理をデータの近くに移動することでネットワークトラフィックと待ち時間を削減

実現のためには多くのチャレンジ• データは範囲分割されていない - フルスキャンが

必要

• データは実行中の可能性があるリードビューでは最新のデータを表示できない場合がある

• すべての機能をプッシュダウンできるわけではない

Database Node

Storage nodes

Push down predicates

Aggregateresults


Parallel Query performance resultsWell-known decision support benchmark

Auroraのパラレルクエリ機能をテストし、パフォーマンス向上は非常に優れていました。インスタンスタイプをr3.8xlargeからr3.2xlargeに減らすことができました。このユースケースでは、パラレルクエリは私たちにとって大きな利点でした。

Jyoti Shandil, Cloud Data Architect

0x

20x

40x

60x

80x

100x

120x

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10Q11Q12Q13Q14Q15Q16Q17Q18Q19Q20Q21Q22

Query response time reduction

Peak speed up ~120x

>10x speedup: 8 of 22 queries


Aurora lock management

MySQL lock manager Aurora lock manager

Scan

Delete

Insert

Scan

Scan

Delete

Scan

Insert

Insert

Delete

Insert

Scan

MySQLと同じロックセマンティクス

ロックチェーンへの同時アクセス

個々のロックチェーン内の複数のスキャナ

ロックフリーデッドロック検出

多くの同時セッションをサポートする、高い更新スループット


Asynchronous key prefetch

バッチ・キー・アクセス（BKA）結合アルゴリズム+マルチレンジ読み取り（MRR）最適化を使用したクエリに利用可能

JOIN評価中にセカンダリ・プライマリインデックスを実行

バックグラウンドスレッドを使用して、非同期でページをメモリにロード Latency improvement factor vs. Batched Key Access (BKA)

join algorithm. Decision support benchmark, R3.8xlarge

14.57

-

2.00

4.00

6.00

8.00

10.00

12.00

14.00

16.00

Cold buffer

AKP used in queries 2, 5, 8, 9, 11, 13, 17, 18, 19, 20, 21


Batched scans

標準のMySQLでは1行毎に処理を行うためオーバーヘッドが大きくなる• functionの読み出し

• ロックとラッチ

• カーソルの保存とフェッチ

• InnoDB から MySQL フォーマットへの変換

Amazon AuroraはInnoDB buffe poolからタプルをバッチで読み込む• Table full scans

• Index full scans

• Index range scansLatency improvement factor vs. Batched Key Access (BKA) join algorithm. Decision support benchmark, R3.8xlarge

1.78X

-

0.20

0.40

0.60

0.80

1.00

1.20

1.40

1.60

1.80

2.00


Instant crash recovery

Traditional database最後のチェックポイント以降からログを適用する必要がある

チェックポイント間は通常5分

MySQLではシングルスレッド。大量のディスクアクセスが必要

Amazon Auroraストレージがディスク読み取りの一部としてREDOレコードをオンデマンドで再適用

並列、分散、非同期

起動時に再適用なし

Checkpointed Data Redo Log

T0でのクラッシュでは、最後のチェックポイント以降にREDOログ内のSQLを再適用する必要がある

T0 T0

T0でクラッシュが発生すると、REDOログが各セグメントにオンデマンドで並行して、非同期に適用


Cluster Cache Management – Aurora PostgreSQLAvoiding a cold cache after failover

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

Tra

nsactions p

er

Second (

TP

S)

Seconds

PGBench 20X RO / 1X RW 160GB Cached - Failover at 600 Seconds

Baseline

通常、データベースをバックアップしてキャッシュをウォームアップするにはしばら

く時間がかかります。このフェールオーバーの例では、CCMがないと、DBの起動に

32秒かかりましたが、パフォーマンスの90％を回復するには340秒でした

340 seconds

32 seconds


How Cluster Cache Management works

Application

M

Application

R

Application

AsyncInvalidation& Update

Availability Zone 1 Availability Zone 3Availability Zone 2

Auro

ra

stora

ge

R R R


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

Tra

nsactions p

er

Second (

TP

S)

Seconds

PGBench 20X RO / 1X RW 160GB Cached - Failover at 600 Seconds

Baseline

CCM Enabled

Cluster Cache Management – Aurora PostgreSQLFailover to an (almost) fully warm cache

CCMが有効になっていると、データベースはウォームアップされたキャッシュにフェ

イルオーバ。フェイルオーバーから32秒後に、パフォーマンスの90％に復帰

340 seconds

32 seconds


Aurora Backtrack

Backtrackにより、バックアップからの復元を必要とせずにデータベースを特定の時点に戻すことが可能• 意図しないDMLまたはDDL操作から回復

• Backtrackは破壊的ではないため、正しい時点を見つけるために複数回Backtrackすることが可能

• QA（テスト実行の間にDBを巻き戻す）にも役立ちます

t0 t1 t2

t0 t1

t2

t3 t4

t3

t4

Rewind to t1

Rewind to t3

Invisible Invisible


InvisibleInvisible

How Backtrack works

ログは、LSNツリー内の分岐に基づいて表示または非表示にする

• t2でBacktrackを実施し、t1 へ巻き戻す場合はオレンジログを不可視にする

• t4 でBacktrackを実施し、t3 へ巻き戻す場合は赤ログを不可視にする

t0 t1 t2

t0 t1

t2

t3 t4

t3

t4

Rewind to t1

Rewind to t3

Log stream· · · ·


Fast Database Cloning

Production database

Clone Clone

CloneDev/test

applications

Benchmarks

Production applications

Productionapplications

重複したストレージコストなしでデータベースのコピーを作成するCreation of a クローンはほぼ瞬間的なもの - データをコピーしない

• データのコピーは書き込み時にのみ行われる - 元のボリュームデータとクローンされたボリュームデータが異なる場合がある

• 最大15クローンまで作成可能

ユースケース

• 本番のデータベースをテスト目的で利用

• データベースの再構成

• 本番システムに影響を及ぼさず、分析目的でスナップショットDBを作成


How Fast Database Cloning works

M

Application

R

Application

M

ReportingApplication

Write log records

Read blocks

Availability Zone 1 Availability Zone 3Availability Zone 2

Auro

ra

stora

ge Primary

storage

Clone storage

Clone


Aurora Serverless: scale up and down with load

1

2

4

8

16

32

64

128

0

500

1000

1500

2000

2500

3000

10

12

0

23

0

34

0

45

0

56

0

67

0

78

0

89

0

10

00

11

10

12

20

13

30

14

40

15

50

16

60

17

70

18

80

19

90

21

00

22

10

23

20

24

30

25

40

26

50

27

60

28

70

29

80

30

90

32

00

33

10

34

20

35

30

36

40

37

50

38

60

39

70

40

80

41

90

43

00

44

10

45

20

46

30

47

40

48

50

49

60

50

70

51

80

52

90

54

00

55

10

56

20

57

30

58

40

59

50

60

60

61

70

62

80

63

90

65

00

66

10

67

20

68

30

69

40

70

50

71

60

72

70

TPS ACU


Aurora Serverless: stabilizing latency quickly

0

10

20

30

40

50

60

70

10

12

0

23

0

34

0

45

0

56

0

67

0

78

0

89

0

10

00

11

10

12

20

13

30

14

40

15

50

16

60

17

70

18

80

19

90

21

00

22

10

23

20

24

30

25

40

26

50

27

60

28

70

29

80

30

90

32

00

33

10

34

20

35

30

36

40

37

50

38

60

39

70

40

80

41

90

43

00

44

10

45

20

46

30

47

40

48

50

49

60

50

70

51

80

52

90

54

00

55

10

56

20

57

30

58

40

59

50

60

60

61

70

62

80

63

90

65

00

66

10

67

20

68

30

69

40

70

50

71

60

72

70

0

50

100

150

200

250

300

350

400

450

500

Latency (ms) ACU


Amazon

SUMMIT © 2019, Amazon Web Services, Inc. or its affiliates. All rights reserved.

お手元のサミットガイドブックの表紙、受講票にも記載している『QRコード』からご回答ください。

もれなく素敵なAWSオリジナルグッズ＆アイスをプレゼントします。

本セッションのFeedbackをお願いします

プレゼントの引き換えは、EXPOエリア内アンケートコーナー・出口付近のいずれかにお越しください。

涼感マフラータオル（巾着入り）


Thank you!


Yoav Eilat

[email protected]

Deep Dive on Amazon Aurora · 2020-06-07 · © 2019, Amazon Web Services, Inc. or its affiliates....

Documents

Transcript of Deep Dive on Amazon Aurora · 2020-06-07 · © 2019, Amazon Web Services, Inc. or its affiliates....