2017/09/06 db tech showcaseでの発表資料「Amazon Aurora - Auroraの止まらない進化とその中身」です - http://www.db-tech-showcase.com/dbts/tokyo

1. Amazon Aurora
Auroraの止まらない進化とその中身
Yutaka Hoshino, Database Specialist Solutions Architect
Amazon Web Services Japan K.K.

2. 内容についての注意点
• 本資料では2017年9月6日時点のサービス内容および価格についてご説明しています。最新の情報は
AWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。
• 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違が
あった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。
• 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途消費税
をご請求させていただきます。
• AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to
change in accordance with the AWS Customer Agreement available at
http://aws.amazon.com/agreement/. Any pricing information included in this document is
provided only as an estimate of usage charges for AWS services based on certain
information that you have provided. Monthly charges will be based on your actual use of
AWS services, and may vary from the estimates provided.

3. データベース管理を簡単に
• データベースを数分で作成可能
• 自動でパッチの適用
• 数クリックするだけでスケールアウト可能
• S3への継続的なバックアップ
• 障害の自動検知と自動フェールオーバ
• DBAが本来行うべき作業に注力して頂けるように
– スキーマ設計・チューニング
– クエリ設計・チューニング などなど
Amazon RDS

4. Amazon Auroraの特徴
ハイパフォーマンス
フルマネージド 高可用性・高耐久性セキュリティにも配慮
MySQL5.6互換スケーラブル

5. • ライセンス料金は
不要
• ロックインもない
• 使った分だけ課金
vCPU Mem Hourly
Price
db.t2.small 1 2 $0.063
db.t2.medium 2 4 $0.125
db.r3.large 2 15.25 $0.35
db.r3.xlarge 4 30.5 $0.70
db.r3.2xlarge 8 61 $1.40
db.r3.4xlarge 16 122 $2.80
db.r3.8xlarge 32 244 $5.60
• ストレージ: $0.120/GB/月
• IO課金: $0.240/100万リクエスト
• 東京リージョンの価格
Amazon Auroraの価格
*NEW*
*NEW*

6. アーキテクチャ

7. Auroraのストレージ
• SSDを利用したシームレスに
スケールするストレージ
– 10GBから64TBまでシームレスに自
動でスケールアップ
– 実際に使った分だけ課金
• 標準で高可用性を実現
– 3AZに6つのデータのコピーを作成
• Log Structured Storage
SQL
Transactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3

8. ストレージノードクラスタ
• Protection Group毎に6つのストレージノードを使用
• 各ログレコードはLog Sequence Number(LSN)を持っており不
足・重複しているレコードを判別可能
• 不足している場合はストレージノード間でゴシッププロトコルを利用し補完を行う

9. IO traffic in Aurora (ストレージノード)
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を検証

10. ディスク障害検知と修復
• 2つのコピーに障害が起こっても、読み書きに影響は無い
• 3つのコピーに障害が発生しても読み込みは可能
• 自動検知、修復
SQL
Transaction
AZ 1 AZ 2 AZ 3
Caching
SQL
Transactio
n
AZ 1 AZ 2 AZ 3
Caching
読み書き可能読み込み可能

11. セキュリティ
• データの暗号化
– AES-256 (ハードウエア支援)
– ディスクとAmazon S3に置かれている全ブロックを暗号化
– AWS KMSを利用したキー管理
• SSLを利用したデータ通信の保護
• 標準でAmazon VPCを使ったネットワークの分離
• ノードへ直接アクセスは不可能
• 業界標準のセキュリティとデータ保護の認証をサ
ポート
Storage
SQL
Transactions
Caching
Amazon S3
Application

12. フェイルオーバとリカバリ

13. フェイルオーバ と リプレース
• リードレプリカが存在する場合は1分程でフェイル
オーバ可能
– RDS for MySQLよりも高速にフェイルオーバ可能
– リードレプリカが存在しない場合は10-15分程
• Multi-AZ配置として別AZで起動可能
– RDS for MySQLと違いリードアクセス可能

14. 高速でより予測可能なフェイルオーバー時間
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

15. 0.00%
5.00%
10.00%
15.00%
20.00%
25.00%
30.00%
35.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
0 - 5s – 30% of fail-overs
0.00%
10.00%
20.00%
30.00%
40.00%
50.00%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
5 - 10s – 40% of fail-overs
0%
10%
20%
30%
40%
50%
60%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
10 - 20s – 25% of fail-overs
0%
5%
10%
15%
20%
1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35
20 - 30s – 5% of fail-overs
フェイルオーバー時間

16. Streaming backupとPITR
• Amazon Auroraでは各セグメント毎にAmazon S3
へ継続的に増分バックアップを取得している
– Backup retention periodでバックアップを残す期間を指定可能
• Amazon Auroraが使用しているディスクの仕組み
によりパフォーマンスへ影響を与えない
• PITRで5分前からBackup Retention Periodまでの
任意の位置に秒単位で復元可能

17. Streaming backup
Segment snapshot Log records
Recovery point
Segment 1
Segment 2
Segment 3
Time
– 各セグメントの定期的なスナップショットは並列で行われ、redo logはストリー
ムで継続バックアップのためにS3に送られる。パフォーマンスや可用性に対する
影響は無し
– リストアでは、セグメントのスナップショットとログストリームをストレージ
ノードに転送し、並列で非同期で適用

18. SQLによるフェイルオーバのテスト
SQLによりノード・ディスク・ネットワーク障害をシミュレーション可能
• データベースノードのクラッシュをシミュレート:
ALTER SYSTEM CRASH [{INSTANCE | DISPATCHER | NODE}]
• レプリケーション障害をシミュレート:
ALTER SYSTEM SIMULATE percentage_of_failure PERCENT
READ REPLICA FAILURE [ TO ALL | TO "replica name" ]
FOR INTERVAL quantity [ YEAR | QUARTER | MONTH | WEEK| DAY |
HOUR | MINUTE | SECOND ];
• 他にも
– ディスク障害をシミュレート
– ディスクコンジェスションをシミュレート

19. Aurora Driver
• MariaDB Connector/J 1.2.0以降に含まれている
– https://mariadb.com/kb/en/mariadb/mariadb-connector-j-120-release-
notes/
– リリースノートには明確にAuroraの記述は無いがドキュメント中に記載
• https://mariadb.com/kb/en/mariadb/about-mariadb-connector-j/
• https://mariadb.com/kb/en/mariadb/failover-and-high-availability-with-
mariadb-connector-j/#specifics-for-amazon-aurora
– 2015.09 Amazon Linuxよりrpmを提供
• 現在の提供機能
– Fast failover
– Auto node discovery

20. パフォーマンスTips

21. チューニング指針
• まずはデフォルトのパラメータグループを使用
– Amazon Auroraはデフォルトの設定でパフォーマンスを発揮できる
ようにチューニング済み
– 適切なインスタンスタイプを選択することが大切
• Amazon AuroraはCPUやメモリなどのマシンリソー
スを最大限使うように様々な改良が入っています
– 監視項目などは実際のシステムで必要なレイテンシなどの要件に
従って設定を行う
– ClowdWatchやperformance schemaを活用

22. WRITE PERFORMANCE READ PERFORMANCE
インスタンスサイズによるスケール
AuroraはRead/Writeパフォーマンス共にインスタンスサイズに比例してスケール
Aurora MySQL 5.6 MySQL 5.7

23. チューニングTips
• 1トランザクションで大量の更新や削除を行ったり、
大量データのシーケンシャルリードを行う場合
• Amazon Auroraのアーキテクチャに合わせてクエリを
実行することで性能を向上させることが可能

24. チューニングTips
#1> SELECT * FROM Table;
#1> SELECT * FROM Table WHERE id BETWEEN 1 AND 10000;
#2> SELECT * FROM Table WHERE id BETWEEN 10001 AND 20000;
#3> SELECT * FROM Table WHERE id BETWEEN 20001 AND 30000;
#4> .........
• SELECT (Parallel Read Aheadで大幅性能改善)
• DELETE / UPDATE
#1> DELETE * FROM Table WHERE id
>= 100000;
#1> DELETE FROM Table WHERE id BETWEEN 10000 AND 20000;
#2> DELETE FROM Table WHERE id BETWEEN 20001 AND 30000;
#3> DELETE FROM Table WHERE id BETWEEN 300001AND 40000;
#4> .........

25. メトリクススキーマ
• INFORMATION_SCHEMA.REPLICA_HOST_STATUS
• mysql.ro_replica_status
mysql> SELECT SERVER_ID, REPLICA_LAG_IN_MILLISECONDS, SESSION_ID FROM
INFORMATION_SCHEMA.REPLICA_HOST_STATUS;
+-----------------+-----------------------------------------------------+-----------------------------------------+
| SERVER_ID | REPLICA_LAG_IN_MILLISECONDS | SESSION_ID |
+-----------------+----------------------------------------------------+-------------------------------------------+
| demo-db01 | 18.458999633789062 | 62c35a1c-2f61-11e5-96de-06be620fb7bd |
| demo-db02 | 0 | MASTER_SESSION_ID |
| demo-db03 | 19.39299964904785 | 6194b000-2f61-11e5-9bf6-12715c13435b |
+-----------------+---------------------------------------+--------------------------------------------------------+

26. 拡張モニタリング
User
System
Wait
IRQ
Idle
CPU Utilization
Rx per declared ethn
Tx per declared ethn
Network
Num processes
Num interruptible
Num non-interruptible
Num zombie
Processes
Process ID
Process name
VSS
Res
Mem %
consumed
CPU % used
CPU time
Parent ID
Process List
MemTotal
MemFree
Buffers
Cached
SwapCached
Active
Inactive
SwapTotal
SwapFree
Dirty
Writeback
Mapped
Slab
Memory
TPS
Blk_read
Blk_wrtn
read_kb
read_IOs
read_size
write_kb
write_IOs
write_size
avg_rw_size
avg_queue_len
Device IO
Free
capacity
Used
% Used
File System
これらのメトリクスを最短1秒間隔で取得可能

27. 拡張モニタリング
• CloudWatch Logsにメト
リクス送信可能
• CloudWatch logs-
>Lambda-
>Elasticsearch Service
連携も容易
– Kibanaを使ってアプリケー
ション・DBサーバメトリク
ス・クエリのパフォーマンス
を一箇所で閲覧可能

28. Amazon Auroraへの移行

29. マイグレーション時の注意
• Amazon AuroraはInnoDB /
ROW_FORMAT=Dynamicのみサポート
– InnoDB以外のストレージエンジンやROW_FORMAT=COMPRESSは
非対応
• マイグレーション時に自動でからコンバートされる
が、事前に手動で対応ストレージエンジンやROW
FORMATへの変換を推薦
• ホワイトペーパー: http://bit.ly/2qjQzBc

30. RDS for MySQLからマイグレーション
• マネージメントコンソールから数クリックでAmazon Aurora
へ移行可能
– RDS for MySQLのスナップショットからAmazon Auroraへマイグレーション
可能
– RDS for MySQLは5.6を使う必要がある

31. RDS MySQL DBインスタンスからAmazon
Aurora Read Replica を作成
• RDS MySQLインスタンスからAmazon Auroraにダウ
ンタイムを最小限に移行する場合、スナップショットか
らAuroraクラスタを起動し、手動でレプリケーション
を設定する必要があった
• この機能を利用することによって、ワンクリックでRDS
MySQLのスナップショットからAurora Read Replica
を起動し、レプリケーションの設定まで自動で行われる

32. RDS MySQL DBインスタンスからAmazon Aurora
Read Replica を作成
RDS MySQL5.6
(Master)
Aurora
(Writer)
Aurora
(Reader)
Application
Write
Read
Auroraクラスタへレプリケーション環境を自動で作成

33. MySQLスナップショットバックアップからの移行
• Percona Xtrabackupを利用して作成したバックアッ
プデータを利用してオンプレミス環境やAmazon EC2
上のMySQLからAmazon Auroraクラスへ移行可能
– mysqldumpと比較したテストで約20倍高速に移行可能
• S3にアップロードしたバックアップデータを利用
– アップロードにはManagement ConsoleやCLI tools、データサイズが大
きい場合はAWS Import/Export Snowballを利用してS3へ転送する

34. 改善した機能

35. Reader Endpointの追加
• Amazon Aurora cluster内のReaderに単一のエンドポイントを提供
– ReaderがFailoverした場合は、再接続を行うことで新しいReaderに接続が可能
– Round Robinで接続
• メリット
– Load Balancing – クラスタエンドポイントに接続することでDBクラスタ内のリードレプリカ間
でコネクションのロードバランシングが可能
– Higher Availability – 複数のAuroraレプリカをAvailability Zone毎に配置し、リードエンドポイン
ト経由で接続することが可能
– 今までHAproxyなどで分散されていた方は置き換えることでシンプルに負荷分散
• 注意点
– DNSベースなのでアプリケーションやドライバ側でIPアドレスのキャッシュ周りの設定の確認や
failoverのテストを推薦
– Readerが1インスタンスもいなくなった場合はWriterへfailbackを行う

36. Reader Endpoint
• クラスタ内のReader
にラウンドロビンで
接続
• 常にReaderに接続さ
れるが、Readerが1イ
ンスタンスもいなく
なった場合はWriterに
failback
• Readerの追加・削除
は自動で行われる
Availability Zone A Availability Zone B
VPC subnet VPC subnet
VPC subnet VPC subnet
Aurora Reader Aurora Reader
リーダエンドポイント
Read
Aurora Writer

37. IAM Authentication Integration
• Amazon Auroraへログインするための認証にIAMが利用可
能
• IAMのリソース制限を利用可能
• パスワードとしてSignature Version 4 を利用 (15分間有効の一時token)
• SSL接続が必須
• データベースアクセスに必要な認証情報をEC2インスタンスなどに配置しなく
ても良い
• AWS SDKやAWS CLI Tools対応

38. IAM Authentication Integration
SSL接続
CREATE USER iam-database-user IDENTIFIED
WITH AWSAuthenticationPlugin as 'RDS';
server

39. Load Data From S3
• S3バケットに保存されたデータを直接Auroraにインポート可
能
– テキスト形式(LOAD DATA FROM S3)・XML形式(LOAD XML FROM S3)
– LOAD DATA INFILEとほぼ同様のオプションをサポート (圧縮形式のデータは現在
未サポート)
– Manifestによる一括ロードにも対応 (Version 1.11以降)
<row column1="value1" column2="value2" />
<row column1="value1" column2="value2" />
<row>
<column1>value1</column1>
<column2>value2</column2>
</row>
<row>
<field name="column1">value1</field>
<field name="column2">value2</field>
</row>

40. Export Data into S3
• S3バケットにデータを直接Auroraエクスポート可能
– LOAD DATA FROM S3で利用できるManifestファイルを生成可能
– 1ファイルは最大6GBずつ分割される
• 25GBを超えるようなデータをexportする場合は、複数のSQLに分割して
exportする領域をずらして実行する事を推薦
SELECT * FROM employees INTO OUTFILE S3 's3://bucket_name/prefix’
FIELDS TERMINATED BY ',’
LINES TERMINATED BY '¥n’
MANIFEST ON
OVERWRITE ON;

41. 空間インデックスサポート
• Amazon Auroraは今までもGEOMETRY型や、
ST_Contains, ST_CrossesやST_Distanceといっ
たspatial queryが利用可能
• 大きなデータセットに対してスケールするには不十分な点や制限が
あった
• Amazon Auroraではdimensionally ordered space-
filling curveを利用しスケールし、高速かつ正確
に情報を取得できる改善を行った
• MySQL5.7と比較して最大2倍のパフォーマンス

42. Advanced Auditing
MariaDB server_audit plugin Aurora native audit support
• 500K/sでイベントの
書き出しが可能
イベント情報の
書き出し
DDL
DML
Query
DCL
Connect
DDL
DML
Query
DCL
Connect
ログ
書き
出し
イベント情報の書
き出し
イベント情報の書
き出し
イベント情報の書
き出し
イベント情報の書
き出し
イベント情報の書
き出し
Latch-
free
queue
ログ書き出
し
ログ書き出
し
ログ書き出
し
MySQL 5.7 Aurora
Audit Off 95K 615K 6.47x
Audit On 33K 525K 15.9x
Sysbench Select-only Workload on 8xlarge Instance

43. Zero Downtime Patch (ZDP)
• コネクションを切断すること無くオンラインでパッチを
適用
– 5秒程度スループットの低下が起こるが、アプリケーションとの接続を維持
したままパッチを適用可能
– ベストエフォート
• 既に開かれているSSLコネクション、アクティブなロック、トランザクション
の完了やテンポラリテーブルの削除を待機し、パッチ適用可能なウインドウが
出来た場合、ゼロダウンタイムパッチとして適用
• ゼロダウンタイムパッチで適用出来るウインドウがなかった場合、通常のパッ
チ適用プロセスを実行
– 以下の条件では通常通りのパッチ適用プロセスを実施
• バイナリログを有効にしている
• SSLを利用した接続を行っており、ZDPのリトライ回数内に接続が終了しない

44. Zero downtime patch (ZDP)
Networking
state
Application
state
Storage Service
App
state
Net
state
App
state
Net
state
BeforeZDP
New
DB
Engine
Old DB
Engine
New
DB
Engine
Old DB
Engine
WithZDP
セッションはパッチ
適用時に切断される
パッチ適用中でも
セッションは維持される
Storage Service

45. Database Cloning
• ストレージコストを増やすことなく
データベースのコピーを作成
• データをコピーするわけではないため、
クローンの作成はほぼ即座に完了
• データのコピーはオリジナルボリュームと
コピー先のボリュームのデータが異なる
場合の書き込み時のみ発生
ユースケース
• プロダクションデータを使用したテスト
• データベースの再構成
• プロダクションシステムに影響を及ばさずに
分析目的で特定の時点での
スナップショットを保存
本番データベース
Clone Clone
Clone
開発/テスト
アプリケーション
ベンチマーク
本番
データベース
本番
データベース

46. 性能・安定面向上に対する新機能

47. Cached read performance
• Catalog concurrency: デー
タ・ディクショナリの同期と
キャッシュ破棄の効率化
• NUMA aware scheduler:
NUMA を考慮したスケジューラへ
変更すること、複数CPUが搭載さ
れているインスタンスで性能向上
• Read views: read viewを作成
する際にラッチフリーなread
viewを作成するアルゴリズムに変
更
0
100
200
300
400
500
600
700
MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016
1,000 read requests/sec
* R3.8xlarge instance, <1GB dataset Sysbench25% Throughput gain

48. • Smart scheduler: IOヘビー・
CPUヘビーなワークロードそれぞ
れに動的に処理スレッドを割り当
てるスケジューラに変更
• Smart selector: 最も良いパ
フォーマンスのストレージノード
にあるデータを選択することで
リードレイテンシーを軽減
• Logical read ahead (LRA):
btreeの順序に応じて事前にpage
を読み込んで置くことで、IO
waitを軽減
0
20
40
60
80
100
120
MySQL 5.6 MySQL 5.7 Aurora 2015 Aurora 2016
1,000 requests/sec
* R3.8xlarge instance, 1TB dataset Sysbench
10% Throughput gain
Non-cached read performance

49.  プライマリーキーでソートされている
データのバッチインサートの速度を改善。
インデックス走査を行う際のカーソル位
置をキャッシュ
 データパターンに応じて動的に機能を有
効・無効化
 ツリーを下方向に走査する際のラッチ
ロックの競合を軽減
 双方向で全てのINSERTワークロードで
有効
– LOAD INFILE, INSERT INTO SELECT,
INSERT INTO REPLACE, Multi-value
inserts.
Insert performance
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
Index
R4 R5R2 R3R0 R1 R6 R7 R8
Index
Root
MySQL: 全てのINSERTがrootからB-treeをトラバースする
Aurora: indexトラバースを抑制

50. Faster index build
 MySQL 5.6 はLinuxの先読みを活用して
いるため、btreeに連続したブロックア
ドレスが必要。そのためエントリーを
トップダウンで新しいbtreeに挿入する
際に、分割と多くオンロギングが発生
 Auroraはtree内のポジションを元にブ
ロックをスキャンしてプリフェッチし、
リーフブロックを作製してからブランチ
を作製していく
• 分割が発生しない
• 各ページは1度のみ参照される
• 1ページに1ログレコード
2-4X better
0
2
4
6
8
10
12
r3.large on 10GB
dataset
r3.8xlarge on
10GB dataset
r3.8xlarge on
100GB dataset
Hours
RDS MySQL 5.6 RDS MySQL 5.7 Aurora 2016

51. Lab Mode
• 今後提供予定の機能を試すことが可能
– DBパラメータグループ aurora_lab_mode 変数で設定可能
– 開発中の機能なので本番適用ではなく検証目的でお使い下さい
• GAクオリティですが、全てのワークロードで性能が発揮出来るか検証
を行っている段階です
– フィードバックをお待ちしています！
• 現在ご提供中
– Lock compression
• ロックマネージャーが利用するメモリを最大66%削減
• OOMを起こさず、更に多くの行ロックを同時に取得することが可能に
– Fast DDL
• nullableカラムをテーブルの最後に追加する場合にデータ件数によらず
高速に変更が行なえます

52. Fast DDL: Aurora vs. MySQL
 フルテーブルコピー: 全てのインデックスを
再構築 - 数時間から数日かかることも
 DMLクエリ実行のために一時領域が必要
 DDLクエリがDMLクエリスループットに影響
 DMLクエリ実行中にテーブル・ロックが発生
Index
LeafLeafLeaf Leaf
Index
Root
table name operation column-name time-stamp
Table 1
Table 2
Table 3
add-col
add-col
add-col
column-abc
column-qpr
column-xyz
t1
t2
t3
 メタデータテーブルにエントリーを追加し、
スキーマバージョニングを利用
 変更を適用するために最新のスキーマへブロックを
アップグレードする際はmodify-on-write
 現在はテーブルの最後にNullableなカラムを
追加する場合に対応
MySQL Amazon Aurora

53. Fast DDLのパフォーマンス
On r3.large
On r3.8xlarge
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.27 sec 3,960 sec 1,600 sec
50GB table 0.25 sec 23,400 sec 5,040 sec
100GB table 0.26 sec 53,460 sec 9,720 sec
Aurora MySQL 5.6 MySQL 5.7
10GB table 0.06 sec 900 sec 1,080 sec
50GB table 0.08 sec 4,680 sec 5,040 sec
100GB table 0.15 sec 14,400 sec 9,720 sec

54. さらなる改善に向けて

55. Database backtrack

56. – データベースの状態を容量によらず瞬時に特定の時点へ巻き戻す
• オペミスなどをしてしまった場合に、作業実行前の状態にすぐに巻き戻すことでサー
ビスへの影響を最小限に抑えることが可能
How does it work?
t0 t1 t2
t0 t1
t2
t3 t4
t3
t4
Rewind to t1
Rewind to t3
Invisible Invisible

57. P o s t g r e S Q L F o r A u r o r a
Aurora is now fully compatible with
both PostgreSQL and MySQL

58. 1/10th The Cost Of
Commercial Grade
Databases
Fully PostgreSQL
Compatible
Several times better
performance than typical
PostgreSQL database
Scalable,
Durable and Secure
Migrate From
RDS For PostgreSQL
Amazon Aurora PostgreSQL-Compatible Edition

59. 一貫したスループットを発揮
測定中のパフォーマンスは、PostgreSQL に比べて 3倍以上一貫した結果に
pgbench は TPC-B を想定したワークロードを実行。Aurora は 1280クライアントで実行時の結果。PostgreSQL は
523 クライアントで実行時の結果(クライアント数はそれぞれもっともよいスループットを出した際のものを採用)
開発中の結果のため正式リリース時と異なる可能性があります

60. Amazon Aurora with PostgreSQL Compatibility
性能測定のまとめ
Measurement Result
PgBench >= 2x faster
SysBench 2x-3x faster
Data Loading 3x faster
Response Time >2x faster
Throughput Jitter >3x more consistent
Throughput at Scale 3x faster
Recovery Speed Up to 85x faster
開発中の結果のため正式リリース時と異なる可能性があります

61. Performance Insights
• DBの知識を持ったエンジニアがいな
くとも、クエリパフォーマンスの評
価やDBの状態チェックを実施可能に
する機能
• Amazon Aurora PostgreSQL-
Compatible Editionには既に組み込
まれた状態でリリースされる
• 他のデータベースエンジンにも順次
展開予定

62. まとめ

63. Amazon Aurora
• クラウド時代にAmazonが再設計したRDBMS
– MySQL5.6/PostgreSQL9.6と互換があり既存の資産を活かしやすい
• 高いクエリ実行並列度・データサイズが大きい環境で
性能を発揮
– Amazon Auroraはコネクション数やテーブル数が多い環境で優位
• 高可用性・実環境での性能向上を実現するための多く
のチャレンジを継続して行っている

64. 参考資料
• Amazon Aurora SIGMOD論文
– http://www.allthingsdistributed.com/files/p1041-verbitski.pdf
• Amazon Auroraストレージエンジン
– https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/
• Amazon Auroraストレージのquorumに関する実装について
– https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-reads-and-
mutating-state/
– https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-and-
correlated-failure/
– https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-reducing-costs-
using-quorum-sets/
– https://aws.amazon.com/blogs/database/amazon-aurora-under-the-hood-quorum-
membership/
• AWS Database Blog (Amazon Aurora)
– https://aws.amazon.com/blogs/database/category/aurora/