© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Anurag Gupta, VP, Aurora, Amazon

Redshift, EMR

October 2015

DAT405

Amazon Aurora Deep DiveDesign Overview of Aurora Performance and Availability

MySQL互換のリレーショナルデータベース

商用データベース並みの

パフォーマンス と 可用性

オープンソースデータベース並みの

使いやすさとコスト効果

Amazon Auroraとは?

4クライアントから各1,000接続（計4,000接続）

WRITE PERFORMANCE READ PERFORMANCE

1クライアントから1,600接続

MySQL SysBench

R3.8XL with 32 cores and 244 GB RAM

SQLベンチマーク結果

ベンチマークを再現するには

h t t p s : / / d 0 . a w s s t a t i c . c o m / p r o d u c t - m a rk e t i n g / Au r o r a / R D S_ Au r o r a _ Pe r f o r m a n c e _ As s e s s m e n t _ Be n c hm a r k i n g _ v 1 - 2 . p d f

AMAZON

AURORA

R3.8XLARGE

R3.8XLARGE

R3.8XLARGE

R3.8XLARGE

R3.8XLARGE

• Amazon VPCを作成 (もしくは既存の物を使用)

• SysBenchを実行するために、EC2 r3.8xlargeインスタン

スを4台、同じアベイラビリティゾーンで起動

• 拡張ネットワーキングを有効

• Linuxのkernelパラメータを調整

(詳細はホワイトペーパー参照)

• Sysbench version 0.5をインストール

• r3.8xlarge Amazon Aurora DBをEC2インスタンスと同じ

VPC、アベイラビリティゾーンで起動

• ベンチマークを実行

1

2

3

4

5

6

7

ベンチマークを越えて

現実世界のアプリケーションがベンチマークのようなパフォーマンスを発揮できれば良いのだが…

現実世界における歪み

リクエストが互いに競合する

メタデータがデータ・ディクショナリのキャッシュに収まらない

データがバッファ・キャッシュに乗り切らない

本番データベースは高可用性構成で動かす必要がある

接続数をスケール

SysBench OLTP workload

250 tables

Connections Amazon Aurora

RDS MySQL

30K IOPS (single AZ)

50 40,000 10,000

500 71,000 21,000

5,000 110,000 13,000

8xU P TO

FA S T E R

テーブル数をスケール

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

SysBench write-only workload

1,000 connections

Default settings

11xU P TO

FA S T E R

データサイズをスケール

DB Size Amazon Aurora

RDS MySQL

30K IOPS (single AZ)

1GB 107,000 8,400

10GB 107,000 2,400

100GB 101,000 1,500

1TB 26,000 1,200

67xU P TO

FA S T E R

SYSBENCH WRITE-ONLY

DB Size Amazon Aurora

RDS MySQL

30K IOPS (single AZ)

80GB 12,582 585

800GB 9,406 69

CLOUDHARMONY TPC-C

136xU P TO

FA S T E R

リードレプリカを使う

Updates per

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

SysBench write-only workload

250 tables

500xU P TO

L O W E R L A G

I/Oを減らす

ネットワークパケットを最小限にする

結果をキャッシュしておく

データベースエンジンをオフロードする

DO LESS WORK

非同期で処理する

レイテンシーの通り道を減らす

ロックフリーなデータ構造を使う

バッチ操作を同時に行う

BE MORE EFFICIENT

これらの結果をどう達成したか？

データベースは I/O が全て

ネットワーク接続したストレージは PACKETS/SECOND が全て

高スループットの処理に コンテキストスイッチ は許されない

RDS MySQLのI/Oトラフィック

BINLOG DATA DOUBLE-WRITELOG FRM FILES

T Y P E O F W R I T E

MYSQL WITH STANDBY

EBSに書き込み – EBSがミラーへ複製し、両方終了後ack

DRBD経由でスタンバイインスタンスへ書き込みを伝播

スタンバイインスタンス側のEBSに書き込み

IO FLOW

ステップ1, 3, 5はシーケンシャルかつ同期

それによりレイテンシーもパフォーマンスのゆらぎも増加

各ユーザー操作には様々な書き込みタイプがある

書き込み破損を避けるためにデータブロックを2回書く必要性

OBSERVATIONS

780K トランザクション

100万トランザクション当たり7,388K I/Os (ミラー, スタンバイを除く)

平均1トランザクション当たり7.4 I/Os

PERFORMANCE

30 minute SysBench write-only workload, 100 GB data set, RDS SingleAZ, 30K

PIOPS

EBS mirrorEBS mirror

AZ 1 AZ 2

Amazon S3

EBSAmazon Elastic

Block Store (EBS)

Primary

instance

Standby

instance

1

2

3

4

5

AuroraのI/Oトラフィック(データベース)

AZ 1 AZ 3

Primary

instance

Amazon S3

AZ 2

Replica

instance

AMAZON AURORA

ASYNC

4/6 QUORUM

DISTRIBUTED

WRITES

BINLOG DATA DOUBLE-WRITELOG FRM FILES

T Y P E O F W R I T E

30 minute SysBench write-only workload, 100 GB data set

IO FLOW

REDOログレコードのみ書き込む; 全てのステップは非同期

データブロックは書かない(チェックポイント, キャッシュ置換時)

6倍のログ書き込みだが, 1/9のネットワークトラフィック

ネットワークとストレージのレイテンシー異常時の耐性

OBSERVATIONS

27,378K トランザクション 35X MORE

100万トランザクション当たり950K I/Os 7.7X LESS(6X amplification)

PERFORMANCE

REDOログレコードをまとめる –完全にLSN順に並ぶ

適切なセグメントに分割する –部分ごとに並ぶ

ストレージノードへまとめて書き込む

AuroraのI/Oトラフィック(ストレージノード)

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

全てのステップは非同期

ステップ1と 2だけがフォアグラウンドのレイテンシーに影響

インプットキューはMySQLの1/46 (unamplified, per node)

レイテンシーにセンシティブな操作に向く

ディスク領域をバッファーに使ってスパイクに対処

OBSERVATIONS

IO FLOW

① レコードを受信しインメモリのキューに追加

② レコードを永続化してACK

③ レコードを整理してギャップを把握

④ ピアと通信して穴埋め

⑤ ログレコードを新しいバージョンのデータブロックに合体

⑥ 定期的にログと新しいバージョンのブロックをS3に転送

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

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

非同期グループコミット

Read

Write

Commit

Read

Read

T1

Commit (T1)

Commit (T2)

Commit (T3)

LSN 10

LSN 12

LSN 22

LSN 50

LSN 30

LSN 34

LSN 41

LSN 47

LSN 20

LSN 49

Commit (T4)

Commit (T5)

Commit (T6)

Commit (T7)

Commit (T8)

LSN GROWTHDurable LSN at head-node

COMMIT QUEUEPending commits in LSN order

TIME

GROUP

COMMIT

TRANSACTIONS

Read

Write

Commit

Read

Read

T1

Read

Write

Commit

Read

Read

Tn

TRADITIONAL APPROACH AMAZON AURORA

ディスクへ書き込むためののログバッファを管理

バッファが一杯になるか書き込み待ち時間を超過すると書き込みを実行

書き込み頻度が少ない場合は最初の書き込みが遅くなる

最初の書き込みと同時にI/Oリクエストを実行。書き込みが実行されるまでバッファを埋める

6つの内4つのストレージノードからACKが返ってきた時点で堅牢性のある書き込みが完了

先行するDB durableポイントは最新のペンディングACKのポイントまで

アクティブなスレッドに複数のコネクションを収容

カーネル空間のepoll() がラッチフリーキューにコネクションをアサイン

スレッドプールの数は動的に調整される

r3.8xlインスタンスのAmazon Auroraで5,000同時接続を扱える

Standard MySQL – コネクション毎に1スレッド

コネクション数に応じてスケールしない

MySQL EE –スレッドプール毎にコネクションをアサイン

閾値を慎重に設定する必要がある

CLIE

NT

CO

NN

EC

TIO

N

CLIE

NT

CO

NN

EC

TIO

N

LATCH FREE

TASK QUEUE

ep

oll(

)

MYSQL THREAD MODEL AURORA THREAD MODEL

適応型スレッドプール

AuroraのI/Oトラフィック(リードレプリカ)

PAGE CACHE

UPDATE

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

Logical: SQLステートメントをレプリカに伝達

書き込みワークロードはマスター・リードレプリカ双方ともほぼ同じ

ストレージに依存しない

マスターとリードレプリカで結果が大きく遅れることがある

Physical: REDOログをレプリカに伝達

レプリカはストレージをマスターと共有しているので書き込みワークロードは発生しない

キャッシュされたページにログを適用

コミットされたデータはリードレプリカで低遅延で参照可能

MYSQL READ SCALING AMAZON AURORA READ SCALING

過去数ヶ月で改善してきたこと

書き込みバッチサイズのチューニング

read/write I/O要求送信の非同期化

パージスレッドのパフォーマンス

バルクインサートのパフォーマンス

バッチ操作

フェイルオーバー時間の短縮

mallocの削減

システムコールの削減

Undoスロットのキャッシュパターン

協調したログ適用

その他

binlogと分散トランザクション

ロックの圧縮

先読み(read-ahead)

顧客フィードバック

ホットな行競合

ディクショナリ統計

小さなトランザクションのコードパス

クエリーキャッシュのread/write競合

ディクショナリシステムのmutex

ロック競合

可用性

“パフォーマンスが問題となるのは、DBが動いていればこそ”

ストレージノードの可用性

データの読み書きにクオーラムを採用。レイテンシーを軽減

Peer-to-peer gossipレプリケーション

S3への継続的バックアップ (99.999999999%の耐久性)

継続的なデータブロックの検査

継続的なノードやディスクの障害検知

修復やホットスポット解消のリバランスを高速に実行するため、10GB

のセグメント単位でデータを格納

クオーラムのメンバーシップが変わっても書き込みに影響しない

AZ 1 AZ 2 AZ 3

Amazon S3

トラディショナルなDB

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

一般的にチェックポイントの間隔は5分

MySQLではシングルスレッドで行われる;

ディスクアクセスが多く発生する

Amazon Aurora

Disk readの一環として、オンデマンドでredo

logの適用を行う

並列、分散、非同期で行われる

インスタンス起動時に適用する必要がない

Checkpointed data Redo log

T0 でクラッシュが発生すると最後のチェックポイントからのログを適用する必要がある

T0 T0

T0 でクラッシュが発生するとredo

を並列で分散して非同期でログの適用を行う

高速なクラッシュリカバリ

存続可能なキャッシュ

キャッシュをデータベースプロセスから分離

データベースプロセスの再起動が発生しても、キャッシュが残った状態を維持可能

より速くアプリケーションを通常負荷状態に戻すことが出来る

高速なクラッシュリカバリ＋存続可能なキャッシュ＝ DB障害から高速に復帰可能

SQL

Transactions

Caching

SQL

Transactions

Caching

SQL

Transactions

Caching

キャッシュプロセスをDBプロセスと分離することでDBプロセスの再起動でもキャッシュが残る

高速でより予測可能なフェイルオーバー時間

ApprunningFailure detection DNS propagation

Recovery Recovery

DBfailure

MYSQL

App

running

Failure detection DNS propagation

Recovery

DB

failure

AURORA WITH MARIADB DRIVER

1 5 - 2 0 s e c

3 - 2 0 s e c

ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]

ALTER SYSTEM SIMULATE percent_failure DISK failure_type IN

[DISK index | NODE index] FOR INTERVAL interval

ALTER SYSTEM SIMULATE percent_failure NETWORK failure_type

[TO {ALL | read_replica | availability_zone}] FOR INTERVAL interval

SQLで障害時挙動をシミュレート

データベースノードの障害をシミュレート:

ディスクの障害をシミュレート:

ネットワークの障害をシミュレート:

Amazon Aurora team

work hard. have fun. make history.

Thank you!