db tech showcase 2015 Sapporo http://www.insight-tec.com/dbts-sapporo-2015.html

2. 2

3. 3

4. Masashi Terui @ marcy_terui
I’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

5. ABOUT US
5
Coming soon!!

6. 6

7. 7

8. Aurora #とは
8
Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、
高性能の商業用データベースの可用性およびスピードと、
オープンソースデータベースのコスト効率性および簡素性を併せ持っています。
Amazon Aurora は、MySQL の 5 倍の性能を持ち、
同様の機能や可用性を提供している商用データベースの 10 分の 1 の価格です。
- Amazon Aurora公式ページ(https://aws.amazon.com/jp/rds/aurora/) より抜粋 -
”

9. 9
∀｀

10. Auroraの評判
（一部）
10
• 革新的
• これぞ、クラウド時代のデータベースだ！！１
• うまい、はやい、やすい、で使わない理由がない
• MySQLはもう要らない子

11. 11

12. 12

13. 13

14. 14

15. 前提知識①
特徴
15
MySQL5.6互換
ストレージは10GBから64TBまで自動拡張、使った分だけ課金
3つのAZで6つの領域に分散した共有ストレージ
S3へ継続的なバックアップ
独自機能の実装も多数

16. 前提知識②
Architecture
16
SSD, scale-out, multi-tenant storage
Quorum
Log structured storage
Service Oriented Architecture

17. 17
4本の書込みQuorum
残りは非同期で反映
3本の読込みQuorum
3本でデータが揃えば正と言える
DynamoDB等でも使われている
※DynamoDBはQuorumの本数が異なる
http://yoshidashingo.hatenablog.com/entry/2014/11/26/032121

18. 18
ファイルシステムそのものを
ログのように扱う
書き込みは常に追記
ファイルとそれにまつわるメタデータが
まとめて書き出せる
上書きがないため過去データが残っている
バイナリ(REDO)ログ保管の必要がない
http://www2.cs.uh.edu/~paris/7360/PowerPoint/LFS3.ppt

19. 19

20. 20

21. 21

22. 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. 例の件だけ
やってみた
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. 24

25. 25

26. Point
26
Replication (Scale out, Fault tolerance)
Cache (Buffer Pool, Query Cache)
Storage (Random R/W, Scan)
Engine (Parser, Optimizer)

27. 27

28. Read Replica
28
厳密にはレプリカ(複製)じゃない
マスターとディスクを共有しているリードオンリーのノード
書き込みはマスターノードのみ
分散ディスクによる耐障害性の確保とQuorumによる一貫性の担保の両立
レプリカ遅延は数ms〜数十ms
同じディスクを見てるのに遅延があるのは何故？
→キャッシュのパージにかかる時間

29. 29
低遅延
SQLスレッド(更新適用)による
パフォーマンス劣化なし
データ追従を考えなくて良いため
ノード追加が高速
遅延レプリケーションができない
マルチソース、部分的レプリケーションなど、
変則的なレプリケーションができない

30. 30

31. Buffer Pool
31
本体とキャッシュのプロセスを分離
再起動時にBuffer Poolを失わない
innodb_buffer_pool_dumpとの違いは？
→リストア時間・リストアにかかる負荷の有無

32. 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. 33

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

35. Scan
35
ストレージが全く別物なので、これに関しては同じということはまず無い
Log structured storageはデータが連続した領域に書き込まれるため、シーケンシャルアクセスに強そう
巨大なデータセットをQuorumで多数決するオーバヘッドが気になる所（オーバヘッドあるっぽいで・・・）
最大64TBのデータが入るとは言っても、別にスキャンが速いわけではないので、DWHの代わりにはならない？
r3.large MySQL5.6
Local SSD
4.85sec
r3.large Aurora
312.92sec
10,000,000 Records
Full Scan
Buffer Pool is empty
・・・

36. 36

37. Parser
Optimizer
37
この辺りも変わっている
この辺を見だすとキリが無くなるので、今回は・・・
よりリソースを効率的に使用してスループットを上げるよう改良されているとのこと
→CPU等のリソース消費をあまり気にせず、スループットを見て比較すると良い

38. 38

39. 39

40. 40
従来は、定期フルバックアップ＋差分バイナリログバックアップ
復旧は直近のフルバックアップをリストアした上で、
差分バイナリログによる更新を順次適用
フルバックアップからの更新量に比例して復旧時間が長くなる
RDSならフル・差分どちらもS3に待避されるため信頼性は非常に高い

41. 41
過去のデータがそのままの状態で継続的にS3へバックアップされている
リストアも差分適用が無い分、間違いなく高速
どのタイミングでも安定したリストア時間が期待できる

42. 42

43. 43
まずはスケールアップ
読み込みはRead Replicaでスケール可能
書き込みはShardingするしかない
容量追加はディスク増設(要停止) or Sharding

44. 44
読み込みスケールがRead Replicaなのは一緒だが、
Replicaの作成コストが低い（前述）
書き込みはノードとしては１つであるものの、
分散ディスクによってローカルSSD並の性能が出せているので良好と言える
ディスク容量は64TBまで自動でスケール（使った分だけ支払い）
※64TBはInnoDBの制限でAurora的にはもっといけるらしい

45. 45

46. 46
RDS for MySQLではない場合はRead Replicaを組んで、
mysqlfailoverやMHAが一般的
対象が非同期レプリケーションだとデータ損失の可能性有り
（凖同期でも100%ではない）
RDS for MySQLの場合、Multi-AZスタンバイへのレプリケーションは、
独自の仕組みにより完全同期となっており基本的に損失はない
ただし、Multi-AZスタンバイはRead Replicaとしては使えない

47. 47
対象はRead Replicaのいずれか
ストレージは同じものであるためデータ損失無し
RDS for MySQLのMulti-AZと比べるとスタンバイ分の料金がお得

48. 48

49. 49
基本的に難しい
シャットダウンとクラッシュは違う
想定した復旧オペレーションが想定と違いがうまくいかないことも

50. 50
SQLコマンドで障害のシミュレーション可能
インスタンスのクラッシュのような全体障害
NW、Disk等の部分障害
万が一の障害時のオペレーションが簡単にシミュレートでき、
復旧の確実性が上がる

51. 51

52. 52
InnoDB Buffer Pool Dump(5.6〜)
Query CacheはWarming不可
mysqldが止まると消える（InnoDB Buffer Pool Dump以外）
再起動直後は性能が落ちる
Buffer Pool Dumpは時間とリストア中の性能への影響が・・・

53. 53
Cache機構は別プロセス
Shutdown(正確にはreboot)しても消えない
再起動時の性能が安定する
起動時の影響無し

54. 54

55. 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. 56

57. 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. 58

59. 59
特に運用面では優位性が際立つ
どんなものにも向き不向きがあるのは当然
運用まで含めてトータルで考えれば、十分選択肢に入る
小中規模よりは、Write Heavyなハイトランザクション環境へおすすめ
そもそもLarge未満の小さいサイズのインスタンスは提供予定が今のところない
Auroraに限らず、新しいものの導入に際しては検証をしよう
Auroraはこれからも進化するはずなので、期待したい（もちろんMySQLも）

60. 60

61. 61