re:Invent 2015のセッション「DAT205 Amazon Aurora Deep Dive」資料の日本語翻訳版です。 http://www.slideshare.net/AmazonWebServices/dat405-amazon-aurora-deep-dive

1. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Anurag Gupta, VP, Aurora, Amazon
Redshift, EMR
October 2015
DAT405
Amazon Aurora Deep Dive
Design Overview of Aurora Performance and Availability

2. MySQL互換のリレーショナルデータベース
商用データベース並みの
パフォーマンス と 可用性
オープンソースデータベース並みの
使いやすさとコスト効果
Amazon Auroraとは?

3. 4クライアントから各1,000接続（計4,000接続）
WRITE PERFORMANCE READ PERFORMANCE
1クライアントから1,600接続
MySQL SysBench
R3.8XL with 32 cores and 244 GB RAM
SQLベンチマーク結果

4. ベンチマークを再現するには
https ://d0.a wsstat ic . com /product -m ark eting/Aurora /R DS_ Auro ra_Perf orm ance_Assessm ent_Benchm ark ing_v 1-2 .pdf
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

5. ベンチマークを越えて
現実世界のアプリケーションがベンチマークのような
パフォーマンスを発揮できれば良いのだが…
現実世界における歪み
リクエストが互いに競合する
メタデータがデータ・ディクショナリのキャッシュに収まらない
データがバッファ・キャッシュに乗り切らない
本番データベースは高可用性構成で動かす必要がある

6. 接続数をスケール
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
8x
U P TO
FASTER

7. テーブル数をスケール
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
11x
U P TO
FASTER

8. データサイズをスケール
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
67x
U P TO
FA STER
SYSBENCH WRITE-ONLY
DB Size Amazon Aurora
RDS MySQL
30K IOPS (single AZ)
80GB 12,582 585
800GB 9,406 69
CLOUDHARMONY TPC-C
136x
U P TO
FA STER

9. リードレプリカを使う
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
500x
U P TO
LOWER LAG

10. I/Oを減らす
ネットワークパケットを最小限にする
結果をキャッシュしておく
データベースエンジンをオフロードする
DO LESS WORK
非同期で処理する
レイテンシーの通り道を減らす
ロックフリーなデータ構造を使う
バッチ操作を同時に行う
BE MORE EFFICIENT
これらの結果をどう達成したか？
データベースは I/O が全て
ネットワーク接続したストレージは PACKETS/SECOND が全て
高スループットの処理に コンテキストスイッチ は許されない

11. RDS MySQLのI/Oトラフィック
BINLOG DATA DOUBLE-WRITELOG FRM FILES
T Y P E O F W R IT 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
EBS
Amazon Elastic
Block Store (EBS)
Primary
instance
Standby
instance
1
2
3
4
5

12. 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 IT 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順に並ぶ
適切なセグメントに分割する – 部分ごとに並ぶ
ストレージノードへまとめて書き込む

13. 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を検証

14. 非同期グループコミット
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 GROWTH
Durable LSN at head-node
COMMIT QUEUE
Pending 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のポイントまで

15. アクティブなスレッドに複数のコネクションを収容
カーネル空間のepoll() がラッチフリーキューにコネクションをアサイン
スレッドプールの数は動的に調整される
r3.8xlインスタンスのAmazon Auroraで5,000同時接続を扱える
Standard MySQL – コネクション毎に1スレッド
 コネクション数に応じてスケールしない
MySQL EE – スレッドプール毎にコネクションをアサイン
 閾値を慎重に設定する必要がある
CLIENTCONNECTION
CLIENTCONNECTION
LATCH FREE
TASK QUEUE
epoll()
MYSQL THREAD MODEL AURORA THREAD MODEL
適応型スレッドプール

16. 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

17. 過去数ヶ月で改善してきたこと
書き込みバッチサイズのチューニング
read/write I/O要求送信の非同期化
パージスレッドのパフォーマンス
バルクインサートのパフォーマンス
バッチ操作
フェイルオーバー時間の短縮
mallocの削減
システムコールの削減
Undoスロットのキャッシュパターン
協調したログ適用
その他
binlogと分散トランザクション
ロックの圧縮
先読み(read-ahead)
顧客フィードバック
ホットな行競合
ディクショナリ統計
小さなトランザクションのコードパス
クエリーキャッシュのread/write競合
ディクショナリシステムのmutex
ロック競合

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

19. ストレージノードの可用性
データの読み書きにクオーラムを採用。レイテンシーを軽減
Peer-to-peer gossipレプリケーション
S3への継続的バックアップ (99.999999999%の耐久性)
継続的なデータブロックの検査
継続的なノードやディスクの障害検知
修復やホットスポット解消のリバランスを高速に実行するため、10GB
のセグメント単位でデータを格納
クオーラムのメンバーシップが変わっても書き込みに影響しない
AZ 1 AZ 2 AZ 3
Amazon S3

20. トラディショナルなDB
最後のチェックポイントからのログを適用する
必要がある
一般的にチェックポイントの間隔は5分
MySQLではシングルスレッドで行われる;
ディスクアクセスが多く発生する
Amazon Aurora
Disk readの一環として、オンデマンドでredo
logの適用を行う
並列、分散、非同期で行われる
インスタンス起動時に適用する必要がない
Checkpointed data Redo log
T0 でクラッシュが発生する
と最後のチェックポイントか
らのログを適用する必要が
ある
T0 T0
T0 でクラッシュが発生するとredo
を並列で分散して非同期でログの適用を行う
高速なクラッシュリカバリ

21. 存続可能なキャッシュ
キャッシュをデータベースプロセスから分
離
データベースプロセスの再起動が発生し
ても、キャッシュが残った状態を維持可能
より速くアプリケーションを通常負荷状態
に戻すことが出来る
高速なクラッシュリカバリ ＋ 存続可能な
キャッシュ ＝ DB障害から高速に復帰可
能
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
キャッシュプロセスをDBプロセスと分離することで
DBプロセスの再起動でもキャッシュが残る

22. 高速でより予測可能なフェイルオーバー時間
App
runningFailure detection DNS propagation
Recovery Recovery
DB
failure
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

23. 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で障害時挙動をシミュレート
データベースノードの障害をシミュレート:
ディスクの障害をシミュレート:
ネットワークの障害をシミュレート:

24. Amazon Aurora team
work hard. have fun. make history.

25. Thank you!