Amazon Aurora for morning session at CTO Night and Day

1. Amazon Aurora
Amazon Web Services Japan K.K.

2. Amazon Aurora

3. データベース管理を簡単に
• データベースを数分で作成可能
• ⾃動でパッチの適⽤
• 数クリックするだけでスケールアウト可能
• S3への継続的なバックアップ
• 障害の⾃動検知と⾃動フェールオーバ
Amazon RDS

5. 2015/7/28 GAリリース！
Virginia / Oregon / Ireland / Tokyoリージョン

6. Amazon Aurora
• re:Invent 2014で発表されたRDSの新しいエンジン
• Amazonがクラウド時代にリレーショナル・データ
ベースを作るとどうなるかを1から考え構築
– 新しい技術的チャレンジを盛り込んでいる
• エンタープライズグレードの可⽤性とOSSレベルの
コストを両⽴

7. Amazon Aurora
• Amazon AuroraはRDSが提供するエンジンのうちの1つ
– RDSでは現在、MySQL / MariaDB / PostgreSQL / Oracle /
MS SQL Serverが選択可能

8. • ライセンス料⾦は不
要
• ロックインもない
• 使った分だけ課⾦
vCPU Mem Hourly
Price
db.r3.large 2 15.25 $0.29
db.r3.xlarge 4 30.5 $0.58
db.r3.2xlarge 8 61 $1.16
db.r3.4xlarge 16 122 $2.32
db.r3.8xlarge 32 244 $4.64
• ストレージ: $0.10/GB/month
• IO課金: $0.20 per million IO
• Virginiaリージョンの価格
Amazon Aurora pricing

9. Amazon Auroraの特徴
クエリ性能の向上
コストパフォーマンスが良い ⾼可⽤性・⾼耐久性セキュリティにも配慮
MySQL5.6互換スケーラブル

10. Amazon Auroraの特徴
• MySQL5.6と互換性があるため既存のアプリケーションを簡単に移行可能
• ストレージが10GBから64TBまでシームレスに拡張
• 3AZに2つずつ、計6つのデータのコピーを保持
– S3にストリーミングバックアップを実施
• VPC内に起動
– Security GroupやNACLを使⽤してアクセスコントロール可能
• Amazon Auroraは99.99%の可⽤性を実現するように設計されている

11. なぜAmazonがデータベースを再考したか

12. 現在のモノリシックなDB
複数の機能レイヤーが
1つのアプリケーショ
ンになっている
SQL
Transactions
Caching
Logging

13. 現在のモノリシックなデータベース
スケールアウトする場
合は、このセットを増や
していく必要がある SQL
Transactions
Caching
Logging
SQL
Transactions
Caching
Logging
Application

14. コスト・可⽤性・柔軟性の⾯で問題

15. リレーショナルデータベースをもう⼀度考える
• 今、データベースを再度実装するならどうする
か？
– 少なくとも1970年代の⽅法で実装はしない
– AWSサービスを活かすことができ、スケールアウトが簡単で、
セルフヒーリングが出来るようなデータベースを作りたいと考
えた

16. クラウド時代に適したリレーショナルデータベース
• ハイエンドデータベースの様なスピード と 可⽤性
• オープンソースデータベースのシンプルさとコスト効果の⾼さ
• MySQLと互換性を保つ
• 利⽤した分だけお⽀払いいただく課⾦モデル
• AWSサービスと簡単に連携
マネージド・サービスとしてご提供

17. Establishing our ecosystem
“Amazon AuroraがMySQL互換であることは素晴らしいことです。MariaDB
connectorsはAuroraとシームレスに動作します。 MariaDB Enterprise の
MariaDB MaxScaleドライバとコネクタを使ってAurora, MariaDB, そしてMySQLを互換性
の⼼配なしに接続出来ます。私たちは、Auroraチームと今後さらにMySQLエコシステムを
加速させるために⼀緒に働くことを楽しみにしています。”
̶ Roger Levy, VP Products, MariaDB

18. アーキテクチャ

19. Service Oriented Architecture
• ログとストレージレイヤを
シームレスにスケールするス
トレージサービスに移動
• EC2, Amazon DynamoDB,
Amazon SWFなどのAWS
サービスを管理コンポーネン
トに採⽤
• Amazon S3を利⽤して
99.999999999%の耐久性で
ストリーミングバックアップ
Data Plane
Logging + Storage
SQL
Transactions
Caching
Amazon S3
Control Plane
Amazon
DynamoDB
Amazon SWF
Amazon
Route 53

20. キャッシュレイヤの分離
• キャッシュをデータベースプロセス外に
移動させた
• データベースプロセスのリスタート
が発⽣してもキャッシュが残った状
態を維持可能
• サービスにすぐデータベースを戻す
ことが出来る
• ⾼速なクラッシュリカバリ +
survivable cache = DB障害から⾼
速に復帰可能
SQL
Transactions
Caching
SQL
Transactions
Caching
SQL
Transactions
Caching
キャッシュプロセスをDBプロセス外におくことで
DBプロセスの再起動でもキャッシュが残る

21. Auroraのストレージ
• SSDを利⽤したシームレスにスケールするスト
レージ
– 10GBから64TBまでシームレスに⾃動でスケールアップ
– 実際に使った分だけ課⾦
– Peer-to-peer gossipレプリケーション
• 標準でHighly availableを実現
– 3AZに6つのデータのコピーを作成
– 2つのディスクが利⽤不能でも読み書き可能
• 万が⼀1つのAZが利⽤不能になっても3本で読み書き可
能な状態で稼働
– 3つのディスクが利⽤不能の場合読み込みのみ可能
• Log structured Storage
– redo logを複数の⼩さなセグメントに分割
– Log pageによってData pageを作成
SQL
Transactions
AZ 1 AZ 2 AZ 3
Caching
Amazon S3

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

23. Auroraのストレージ
• Amazon Auroraは6本全てのディスクへの書き込み
を待たずに、少なくとも4つのディスクに書き込み
が完了するとすぐに次の処理を実⾏
• ホットスポットの影響を取り除き、⾮常に⾼い並列
度を実現
• ストレージはSSDベースのディスクに10GBずつの
ブロック内に分散して書き込まれる

24. Auroraのストレージの特徴
• リードレプリカもマスタと同じストレージを参照
• Log Structured Storage
• 継続的なS3へ増分バックアップ
– パフォーマンスへの影響なし
• 64TBまで⾃動でストレージがシームレスにスケールアップ
– パフォーマンスや可⽤性に影響無し・利⽤開始時のプロビジョニング不要
• ⾃動で再ストライピング、ミラー修復、ホットスポット管理、
暗号化

25. Log Structured Storage
• 追記型のストレージ・システム
– ログの様に常に末尾にデータを追加していくだけ
– データが書き込まれているブロックを上書いたりはしない
– GCによりデータを効率的に格納する
• シーケンシャルに読み出すことが出来る
• 常に最新のデータが末尾にある
• これらの特徴によりS3への継続バックアップや⾼速なリカバリ、書き込
み性能の向上を実現
空きスペース
data
data
先頭
data
data
data
新規データは末尾に追記される
↓

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

27. レプリケーション
AZ 1 AZ 2
Primary
Instance
Standby
Instance
EBS
Amazon S3
EBS
mirror
EBS
EBS
mirror
MySQL レプリケーション
PITR
シーケンシャ
ル・ライト シーケンシャ
ル・ライト
AZ 1 AZ 3
Primary
Instance
Amazon S3
AZ 2
Replica
Instance
改善点
• Consistency – 異常を修復
• Latency – 同期 vs ⾮同期レプリケーション
• network I/Oを効率的に⾏う
⾮同期 4/6クオーラム 分散書き込み
Amazon Aurora
ログレコード
Binlog
データ
Double-write buffer
metadata
書き込みの種類

28. レプリケーション
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
シングルスレッド
でBinlog適⽤
Data Volume Data Volume
MySQL read scaling
• レプリケーションにはbinlog / relay logが必要
• レプリケーションはマスターへ負荷がかかる
• レプリケーション遅延が増加していくケースが
ある
• フェイルオーバでデータロスの可能性がある
PAGE CACHE
UPDATE

29. レプリケーション
• Amazon Auroraは、15台のリードレプリカを
作成可能
– リードレプリカはマスタサーバとストレージを共有しており、
低負荷で粒度の⾼いほぼ同期型のレプリケーションを⾏う
– 10-20msのレイテンシーでレプリケーションされる
– RDS for MySQLではリードレプリカは5つまで (孫リードレプ
リカを⼊れて30)

30. IO traffic in RDS MySQL
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
EBS
Amazon Elastic
Block Store (EBS)
Primary
instance
Standby
instance
1
2
3
4
5

31. IO traffic in Aurora (データベース)
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順に並ぶ
適切なセグメントに分割する – 部分ごとに並ぶ
ストレージノードへまとめて書き込む

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

33. スレッドプール
• Amazon Auroraはスレッドプールが実装されてい
る
– MariaDBやMySQL EEで提供されているような機能だが、Amazon
Auroraに実装されているものはオリジナル実装
– パラメータグループに項⽬があるが、設定変更は不可能
Client
Thread
Thread
Thread
Thread
Client
MySQL
Client
Thread
Thread
Thread
Thread
Client
Aurora
Thread Pool

34. • アクティブなスレッドに複数のコネクションを収容
• Kernel空間の 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
Adaptive thread pool

35. ⾮同期グループコミット
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のポイントまで

36. Faster, more predictable failover
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

37. DBクラスタ
• Amazon AuroraはDBクラスタという概念を持って
いる
– マスタ (Writer)とリードレプリカ(Reader)をひとまとめにしたも
の
– Parameter GroupとMaintenance WindowもDBクラスタと各ノー
ドそろぞれに存在する
• フェイルオーバが発⽣しても常にマスタを参照する
エンドポイントがクラスタ毎に1つ存在する
– アプリケーションからのWriteクエリは常にこのエンドポイントを
参照するように設定

38. DB Parameter GroupとDB Cluster Parameter Group
• RDS for MySQLではDB Parameter Groupのみ
• Auroraでは設定の適⽤範囲毎にグループを設定
– DB Cluster Parameter Group: Auroraクラスタ内全ノードで共通
– DB Parameter Group: 各Auroraノード個別の設定

39. 新しいメトリクス画⾯
• Throughput
– Select
– Commit
– DML/DDL
• Latency
– Select
– Commit
– DML/DDL
• Cache Hit Ratio
– Buffer Cache
– Result Set
• Deadlocks
• Login Failures
• Blocked Transactions

40. 新しいメトリクス
• 課⾦に関わるディスク利⽤量やIOPS
– Billed storage
– Billed read operations
– Billed write operations

41. メトリクススキーマ
• 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 |
+-----------------+---------------------------------------+--------------------------------------------------------+

42. メトリクススキーマ

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

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

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

46. クラスタエンドポイント
• WriterとReaderのセットをクラスタと呼び、クラスタで常にWriter(マスタ)を指すクラス
タエンドポイントが存在する
• 各Auroraノードは個別にエンドポイントを持っている(⾍眼鏡タブ内のEndpointで確認可
能)
Reader
Writer

47. クラスタエンドポイント
Availability Zone A
Availability Zone B
VPC subnet
VPC subnet
VPC subnet
VPC subnet
Aurora Writer Aurora Reader
クラスタエンドポイント
• 各Auroraノードは個
別にエンドポイントを
持っている
• クラスタエンドポイン
トは、その時アクティ
ブなAurora Writer
ノードのCNAME
• Readは各Readerを参
照する
Write

48. クラスタエンドポイント
• フェイルオーバが発
⽣すると、Aurora
ノードの昇格が⾏わ
れ、クラスタエンド
ポイントの指し先が
変わる
Availability Zone A
Availability Zone B
VPC subnet
VPC subnet
VPC subnet
VPC subnet
Aurora Writer Aurora Reader
クラスタエンドポイント
Write

49. Writer / Readerノードの識別
• innodb_read_onlyを参照
– SHOW GLOBAL VARIABLES LIKE 'innodb_read_onlyʼ;
– OFF: Writer
– ON: Reader
• アプリケーションやドライバでAuroraノードに
対する負荷分散やフェイルオーバーロジックの
実装に利⽤可能
– メトリクススキーマのSEESION_IDも利⽤可能

50. Continuous backup
Segment snapshot Log records
Recovery point
Segment 1
Segment 2
Segment 3
Time
各セグメントの定期的なSnapshotは並列で⾏われ、redo logはストリームで継続バックアップのために
S3に送られる。パフォーマンスや可⽤性に対する影響は無し。
リストアでは、適切なセグメントのSnapshotとログストリームをストレージノードに転送し、並列で⾮
同期で適⽤していく

51. 高速なデータ修復
既存のデータベース
• 最後のチェックポイントからログを適
用していく
• MySQLではシングルスレッドなため
適用完了までの時間が増加
Amazon Aurora
• Disk readの⼀環として、オンデ
マンドでredo logの適⽤を⾏う
• 並列、分散、⾮同期で⾏われる
Checkpointed Data Redo Log
T0 でクラッシュが発⽣すると
最後のチェックポイントからの
ログを適⽤する必要がある
T0 T0
T0 でクラッシュが発⽣するとredo
を並列で分散して⾮同期でログの適⽤を⾏う

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

53. 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 ];
• 他にも
– ディスク障害をシミュレート
– ディスクコンジェスションをシミュレート

54. パフォーマンス

55. Auroraのパフォーマンスを引き出すために
• クエリ並列度が⾼い、データサイズが⼤きい
ケースで効果を発揮
• ロック機構やQuery cache・スレッドプールな
どに⼿を⼊れて性能向上を⾏っている
– write heavyな環境ではoffをおすすめ
– CPUを効率的に利⽤する改善により、CPU利⽤率がMySQLと⽐
較して⾼くなるが、性能が落ちにくくなっている

56. パフォーマンス測定
Availability Zone A
VPC subnet
VPC subnet
Aurora Writer
• 複数のインスタンスから同時に負荷
をかけ並列度を上げる
– NWの影響を抑えるために同⼀リー
ジョンで⾏う
– 1-2時間など⻑時間⾏う
• 単⼀のインスタンスからだけでは、
インスタンス毎のNW帯域の制限に
達する可能性がある
• ⾼負荷環境でもスループット低下を
抑える改善が⼊っているためCPU/
メモリ利⽤率がRDS for MySQLと
⽐較して⾼くなるケースがある

57. defaultパラメータの違い
• RDS for MySQLと⽐べるとbuffer /
connection / 周りの値が少なめ
• query cacheがON
– ONの状態でも性能が出るようにAuroraでは性能向上が⾏われ
ている
– Write heavyな環境ではOFFも検討

58. defaultパラメータの違い
• innodb_change_buffering
– Default: NONE
– 変更不可
– Secondary indexへの更新などに影響が出そうだが、1-2時間など長
時間ベンチマークを行い、change bufferに収まらない量になってくる
と、Auroraの優位性が出てくる
• 数十分の短いベンチマークだと多少影響を受ける可能性がある

59. 新規パラメータ
• thread_handling
– Default: multiple-connections-per-thread
– 変更不可
– multiple-connections-per-thread, no-threads, one-thread-
per-connection, dynamically-loaded
– Clientからの接続を扱うAuroraのスレッドに関する設定

60. パフォーマンス指針
• まずはデフォルトのパラメータグループを使用
– Amazon Auroraはデフォルトの設定でパフォーマンスを発揮できるよ
うにチューニング済み
• 適切なインスタンスタイプを選択することが大切
– それでも性能が出ない場合にパラメータグループの変更を検討

61. パフォーマンス
• 性能が5倍というのはどのようなケースか
– re:Invent で発表された5倍という性能はSysbenchを4インスタンス
(r3.8xlarge + NW関連のkernelパラメータ調整済)からdb.r3.8xlargeの
Auroraインスタンスに実行した場合の結果
• TPC-C をdb.r3.8xlargeに実行した場合は約2.5〜5
倍の性能を観測している
– https://code.launchpad.net/~percona-dev/perconatools/tpcc-mysql

62. パフォーマンス
• FAQとパフォーマンステストのガイドライン・テスト用AMI
を提供しています
– http://aws.amazon.com/rds/aurora/faqs/ の Amazon Aurora
Performance Benchmarking Guide

63. パフォーマンス
• 価格性能⽐5倍
– Amazon Auroraは⾼速でSSDベースのストレージにより⾼速に動
作するが、既存のどんなクエリでも5倍⾼速に実⾏出来ることを意
味しているわけではない
– Amazon Auroraは他の製品よりも、より多くの書き込み・読み込
みクエリを同時に扱うことが出来るためデータベースの集約やス
ループット向上が⾒込める
– Amazon Aurora独⾃で⾼並列なストレージへのアクセスにより保
存されているデータへのコンテンションを解決し、クエリを効率よ
く処理

64. 参考 (re:Inventで発表された資料)

65. よく⾒ると
• Auroraはデッドロックがほんの少し出やすいが
リトライを⾏ってもMｙSQLよりスループット
が出る
• CPU / Memoryの利⽤率がMySQLより⾼いがス
ループットが出ている
– 分散ロック機構によりCPUリソースを使いきってスループット
を出している

66. 何をみるのか？
• よく聞かれる質問
– CPU利用率高いんだけど?
– メモリ利用量多いんだけど？
– Disk IOが多めなんだけど？
• 見てほしいこと
– Auroraはマシンリソースを最大限利用してスループットを出す設
計です
– システムトータルでパフォーマンスが向上
– 管理コスト、障害耐性、データ保全性

67. 何をみるのか？
• AuroraはMySQL互換ですが、マシンリソース
の使い⽅が根本的に違います
• Auroraが得意な場⾯・状況を理解してパフォー
マンスを測定
– マシンリソースを使い切りそうになりながらもMySQLと⽐べる
とスループットやレスポンスタイムの落ち⽅が緩やか

68. Amazon Auroraへの移⾏

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

70. マイグレーション時の注意
• RDS for MySQLとParameter Groupで設定出来る
項⽬や規定値などが異なる
– 例: max_connection / innodb_buffer_pool_size /
query_cache_*など
• マイグレーションに必要なディスクスペース
– スナップショットをインポートする場合、インポート前にEBSボ
リュームを使⽤しデータをフォーマットする
– データをフォーマットするための追加容量が必要になる場合がある

71. マイグレーション時の注意
• Amazon AuroraはInnoDBのみサポート
– MyISAMなどのストレージエンジンは⾮対応
• マイグレーション時に⾃動でMyISAMからコン
バートされますが、事前に⼿動でInnoDBへの
変換を⾏っていただくことがオススメです

72. マイグレーション時の注意
• MyISAM形式のテーブルが含まれない場合
– 移⾏前のディスクで6TBまで容量を利⽤可能
• MyISAM形式のテーブルが含まれる場合
– マイグレーションを⾏うテーブルで3TBを超えるものが無いこ
とを確認する

73. MySQLからレプリケーション
• MySQL5.6からAmazon Auroraへレプリケーションを⾏うこ
とが可能
• 専⽤のProcedureを使⽤
mysql > CALL mysql.rds_set_external_master (DB Hostname or IP address',
3306,’user', ‘password', ’Binlog', position, 0);
mysql > CALL mysql.rds_start_replication;

74. MySQLからレプリケーション
• RDS for MySQLやMySQL on EC2、オンプレ環
境のMySQLからAmazon Auroraにレプリケー
ション可能
– バックアップからAuroraにインポートを⾏い、レプリケーショ
ンを実⾏
– 移⾏時にアプリケーションのメンテナンスを⼊れ、書き込みが
なくなり、レプリケーションが追いついたタイミングでアプリ
ケーションの書き込み先などをAuroraに変更

75. Data Export and Import guide
• Data Export and Import guideを公開してい
ます
– https://d0.awsstatic.com/product-marketing/Aurora/
Aurora_Export_Import_Best_Practices_v1-3.pdf

76. Amazon Aurora Driver

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

78. Aurora Driver

79. Amazon Auroraの使いどころ

80. クエリ同時実⾏数やテーブルサイズが⼤きい
• Amazon Auroraに移行することで、クエリスループッ
トの向上などが見込まれる
– マルチコア環境でCPUを効率的に利用
– 分散ロック機構やquery cacheの改善による性能向上
• ディスク
– データ量の増加に応じてディスク容量を気にする必要が無い
– 性能に影響を及ばさずバックアップ

81. 複数のサーバにシャーディングしている
• 複数の⼩さいDBを1つにまとめる
– コスト効果増⼤と管理コストの軽減
– シャーディングをするデータベースを減らすことでアプリケー
ションの設計を簡略化出来る
– 障害時の影響を考慮する必要はある

82. Advanced monitoring
50+ system/OS metrics | sorted process list view | 1–60 sec granularity
alarms on specific metrics | egress to Amazon CloudWatch Logs | integration with third-party tools
coming soon
ALARM

83. Important systems and OS metrics
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

84. 利⽤事例
• re:Invent 2015 Keynoteで発表

86. まとめ

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