2

3

Masashi Terui @ marcy_teruiI’m a developer and architect in the operators company (JIG-SAW Inc.)

I'm the organizer on the some of events in sapporo with the theme of "Infrastructure as Code”. I’m a AWS Certified DevOps Engineer Professional.

I’m a member of JAWS-UG Sapporo and GCPUG Sapporo (Coming soon!) I’m the winner of “Tuningathon 5” (The theme was MySQL!)

ABOUT ME

4

ABOUT US

5

Coming soon!!

6

7

Aurora #とは

8

Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、

高性能の商業用データベースの可用性およびスピードと、

オープンソースデータベースのコスト効率性および簡素性を併せ持っています。

Amazon Aurora は、MySQL の 5 倍の性能を持ち、

同様の機能や可用性を提供している商用データベースの 10 分の 1 の価格です。 - Amazon Aurora公式ページ(https://aws.amazon.com/jp/rds/aurora/) より抜粋 -

”

9

∀｀

Auroraの評判 （一部）

10

• 革新的

• これぞ、クラウド時代のデータベースだ！！１

• うまい、はやい、やすい、で使わない理由がない

• MySQLはもう要らない子

11

12

13

14

前提知識① 特徴

15

MySQL5.6互換

ストレージは10GBから64TBまで自動拡張、使った分だけ課金

3つのAZで6つの領域に分散した共有ストレージ

S3へ継続的なバックアップ

独自機能の実装も多数

前提知識② Architecture

16

SSD, scale-out, multi-tenant storage

Quorum

Log structured storage

Service Oriented Architecture

17

4本の書込みQuorum

残りは非同期で反映

3本の読込みQuorum

3本でデータが揃えば正と言える

DynamoDB等でも使われている※DynamoDBはQuorumの本数が異なる

http://yoshidashingo.hatenablog.com/entry/2014/11/26/032121

18

ファイルシステムそのものをログのように扱う

書き込みは常に追記

ファイルとそれにまつわるメタデータがまとめて書き出せる

上書きがないため過去データが残っているバイナリ(REDO)ログ保管の必要がない

http://www2.cs.uh.edu/~paris/7360/PowerPoint/LFS3.ppt

19

20

21

22

Amazon, Auroraに限らず

5倍とは何に対して5倍なのか？

例：RDS 30kPIOPSがi2.8xlargeのローカルSSDより書き込みが速いなんて、

ちゃんとチューニングしてないのでは？http://www.slideshare.net/AmazonWebServices/sdd415-new-launch-amazon-aurora-amazons-new-relational-database-engine-aws-reinvent-2014/21 とはいえ、Auroraが速いことを否定するものではない

自分の要件にあっているかは自分で測る

例の件だけ やってみた

23

Aurora r3.8xlarge

i2.8xlarge, MySQL5.6 Local SSD x1 ext4 ほぼデフォルト設定

i2.8xlarge, MySQL5.6 Local SSD x8 RAID0 XFS

チューニング済み

102768.28 writes/sec

38020.90 writes/sec

108131.92 writes/sec

MySQL Sysbench 1000threads * 4clients Write (Insert) Only

24

25

Point

26

Replication (Scale out, Fault tolerance)

Cache (Buffer Pool, Query Cache)

Storage (Random R/W, Scan)

Engine (Parser, Optimizer)

27

Read Replica

28

厳密にはレプリカ(複製)じゃない

マスターとディスクを共有しているリードオンリーのノード

書き込みはマスターノードのみ

分散ディスクによる耐障害性の確保とQuorumによる一貫性の担保の両立

レプリカ遅延は数ms〜数十ms

同じディスクを見てるのに遅延があるのは何故？

→キャッシュのパージにかかる時間

29

低遅延

SQLスレッド(更新適用)による

パフォーマンス劣化なし

データ追従を考えなくて良いため

ノード追加が高速

遅延レプリケーションができない

マルチソース、部分的レプリケーションなど、

変則的なレプリケーションができない

30

Buffer Pool

31

本体とキャッシュのプロセスを分離

再起動時にBuffer Poolを失わない

innodb_buffer_pool_dumpとの違いは？

→リストア時間・リストアにかかる負荷の有無

Query Cache

32

Query Cacheにも手を入れている デフォルトON オーバヘッドは減っているが、Write Heavyな環境ではOFF推奨

r3.large MySQL5.6 Query Cache ON

522.4tps

MySQL Sysbench 400threads 1Client OLTP (Read Only OFF)

r3.large MySQL5.6 Query Cache OFF

543.14tps

r3.large Aurora Query Cache ON

545.32tps

r3.large Aurora Query Cache OFF

547.03tps

33

Random R/W

34

SSD最適化による高速化

あらゆる更新が追記であるため、DELETEとUPDATEのコストが低い？

r3.large MySQL5.6 Query Cache OFF

9057.89 writes/sec

r3.large Aurora Query Cache OFF

MySQL Sysbench 400threads 1Client UPDATE

5837.87 writes/sec

r3.large MySQL5.6 Query Cache OFF

15361.38 writes/sec

r3.large Aurora Query Cache OFF

16762.52 writes/sec

MySQL Sysbench 400threads 1Client DELETE

Scan

35

ストレージが全く別物なので、これに関しては同じということはまず無い

Log structured storageはデータが連続した領域に書き込まれるため、シーケンシャルアクセスに強そう

巨大なデータセットをQuorumで多数決するオーバヘッドが気になる所（オーバヘッドあるっぽいで・・・）

最大64TBのデータが入るとは言っても、別にスキャンが速いわけではないので、DWHの代わりにはならない？

r3.large MySQL5.6 Local SSD

4.85sec

r3.large Aurora

312.92sec10,000,000 Records Full Scan

Buffer Pool is empty

・・・

36

Parser Optimizer

37

この辺りも変わっている

この辺を見だすとキリが無くなるので、今回は・・・

よりリソースを効率的に使用してスループットを上げるよう改良されているとのこと

→CPU等のリソース消費をあまり気にせず、スループットを見て比較すると良い

38

39

40

従来は、定期フルバックアップ＋差分バイナリログバックアップ

復旧は直近のフルバックアップをリストアした上で、

差分バイナリログによる更新を順次適用

フルバックアップからの更新量に比例して復旧時間が長くなる

RDSならフル・差分どちらもS3に待避されるため信頼性は非常に高い

41

過去のデータがそのままの状態で継続的にS3へバックアップされている

リストアも差分適用が無い分、間違いなく高速

どのタイミングでも安定したリストア時間が期待できる

42

43

まずはスケールアップ

読み込みはRead Replicaでスケール可能

書き込みはShardingするしかない

容量追加はディスク増設(要停止) or Sharding

44

読み込みスケールがRead Replicaなのは一緒だが、

Replicaの作成コストが低い（前述）

書き込みはノードとしては１つであるものの、

分散ディスクによってローカルSSD並の性能が出せているので良好と言える

ディスク容量は64TBまで自動でスケール（使った分だけ支払い）

※64TBはInnoDBの制限でAurora的にはもっといけるらしい

45

46

RDS for MySQLではない場合はRead Replicaを組んで、

mysqlfailoverやMHAが一般的

対象が非同期レプリケーションだとデータ損失の可能性有り

（凖同期でも100%ではない）

RDS for MySQLの場合、Multi-AZスタンバイへのレプリケーションは、

独自の仕組みにより完全同期となっており基本的に損失はない

ただし、Multi-AZスタンバイはRead Replicaとしては使えない

47

対象はRead Replicaのいずれか

ストレージは同じものであるためデータ損失無し

RDS for MySQLのMulti-AZと比べるとスタンバイ分の料金がお得

48

49

基本的に難しい

シャットダウンとクラッシュは違う

想定した復旧オペレーションが想定と違いがうまくいかないことも

50

SQLコマンドで障害のシミュレーション可能

インスタンスのクラッシュのような全体障害

NW、Disk等の部分障害

万が一の障害時のオペレーションが簡単にシミュレートでき、

復旧の確実性が上がる

51

52

InnoDB Buffer Pool Dump(5.6〜)

Query CacheはWarming不可

mysqldが止まると消える（InnoDB Buffer Pool Dump以外）

再起動直後は性能が落ちる

Buffer Pool Dumpは時間とリストア中の性能への影響が・・・

53

Cache機構は別プロセス

Shutdown(正確にはreboot)しても消えない

再起動時の性能が安定する

起動時の影響無し

54

55

1. mysqldump --single-transaction --master-data=2

2. RDS for MySQLからなら既存のスナップショットからマイグレーション可能

3. 稼働中のインスタンスからバックグラウンドでスナップショットを取らせてマイグレーションも可能

4. 無停止（に近い）移行なら1 or 3して、Aurora Slaveに外部Masterにぶらさげて

(AWS謹製ストアドmysql.rds_set_external_masterをコール)、Master昇格させる

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.NonRDSRepl.html

56

57

5.7もかなり進化してます

https://yakst.com/ja/posts/2478

Auroraは相当に手を入れている感じがするので、どう取り込まれるかは未知数という印象

ただ、AuroraはAuroraで進化するし、事実、Preview中からの改良は目を見張るものがある

5.7との性能比較などについては天下のDimitri先生からお聞きください|彡ｻｯ

http://dimitrik.free.fr/blog/archives/2014/11/mysql-performance-57-and-rds-aurora-so-what.html

｀

58

59

特に運用面では優位性が際立つ

どんなものにも向き不向きがあるのは当然

運用まで含めてトータルで考えれば、十分選択肢に入る

小中規模よりは、Write Heavyなハイトランザクション環境へおすすめ

そもそもLarge未満の小さいサイズのインスタンスは提供予定が今のところない

Auroraに限らず、新しいものの導入に際しては検証をしよう

Auroraはこれからも進化するはずなので、期待したい（もちろんMySQLも）

60

61