ついに解禁！Amazon Aurora徹底検証！

ついに解禁！Amazon Aurora徹底検証！

1. 1. 2
2. 2. 3
3. 3. 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
4. 4. ABOUT US 5 Coming soon!!
5. 5. 6
6. 6. 7
7. 7. Aurora #とは 8 Amazon Aurora は、MySQL と互換性のあるリレーショナルデータベースエンジンで、 高性能の商業用データベースの可用性およびスピードと、 オープンソースデータベースのコスト効率性および簡素性を併せ持っています。 Amazon Aurora は、MySQL の 5 倍の性能を持ち、 同様の機能や可用性を提供している商用データベースの 10 分の 1 の価格です。 - Amazon Aurora公式ページ(https://aws.amazon.com/jp/rds/aurora/) より抜粋 - ”
8. 8. 9 ∀｀
9. 9. Auroraの評判 （一部） 10 • 革新的 • これぞ、クラウド時代のデータベースだ！！１ • うまい、はやい、やすい、で使わない理由がない • MySQLはもう要らない子
10. 10. 11
11. 11. 12
12. 12. 13
13. 13. 14
14. 14. 前提知識① 特徴 15 MySQL5.6互換 ストレージは10GBから64TBまで自動拡張、使った分だけ課金 3つのAZで6つの領域に分散した共有ストレージ S3へ継続的なバックアップ 独自機能の実装も多数
15. 15. 前提知識② Architecture 16 SSD, scale-out, multi-tenant storage Quorum Log structured storage Service Oriented Architecture
16. 16. 17 4本の書込みQuorum 残りは非同期で反映 3本の読込みQuorum 3本でデータが揃えば正と言える DynamoDB等でも使われている
 ※DynamoDBはQuorumの本数が異なる http://yoshidashingo.hatenablog.com/entry/2014/11/26/032121
17. 17. 18 ファイルシステムそのものを
 ログのように扱う 書き込みは常に追記 ファイルとそれにまつわるメタデータが
 まとめて書き出せる 上書きがないため過去データが残っている
 バイナリ(REDO)ログ保管の必要がない http://www2.cs.uh.edu/~paris/7360/PowerPoint/LFS3.ppt
18. 18. 19
19. 19. 20
20. 20. 21
21. 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が速いことを否定するものではない 自分の要件にあっているかは自分で測る
22. 22. 例の件だけ やってみた 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
23. 23. 24
24. 24. 25
25. 25. Point 26 Replication (Scale out, Fault tolerance) Cache (Buffer Pool, Query Cache) Storage (Random R/W, Scan) Engine (Parser, Optimizer)
26. 26. 27
27. 27. Read Replica 28 厳密にはレプリカ(複製)じゃない マスターとディスクを共有しているリードオンリーのノード 書き込みはマスターノードのみ 分散ディスクによる耐障害性の確保とQuorumによる一貫性の担保の両立 レプリカ遅延は数ms〜数十ms 同じディスクを見てるのに遅延があるのは何故？
 →キャッシュのパージにかかる時間
28. 28. 29 低遅延 SQLスレッド(更新適用)による
 パフォーマンス劣化なし データ追従を考えなくて良いため
 ノード追加が高速 遅延レプリケーションができない マルチソース、部分的レプリケーションなど、
 変則的なレプリケーションができない
29. 29. 30
30. 30. Buffer Pool 31 本体とキャッシュのプロセスを分離 再起動時にBuffer Poolを失わない innodb_buffer_pool_dumpとの違いは？
 →リストア時間・リストアにかかる負荷の有無
31. 31. 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
32. 32. 33
33. 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
34. 34. 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 ・・・
35. 35. 36
36. 36. Parser Optimizer 37 この辺りも変わっている この辺を見だすとキリが無くなるので、今回は・・・ よりリソースを効率的に使用してスループットを上げるよう改良されているとのこと
 →CPU等のリソース消費をあまり気にせず、スループットを見て比較すると良い
37. 37. 38
38. 38. 39
39. 39. 40 従来は、定期フルバックアップ＋差分バイナリログバックアップ 復旧は直近のフルバックアップをリストアした上で、
 差分バイナリログによる更新を順次適用 フルバックアップからの更新量に比例して復旧時間が長くなる RDSならフル・差分どちらもS3に待避されるため信頼性は非常に高い
40. 40. 41 過去のデータがそのままの状態で継続的にS3へバックアップされている リストアも差分適用が無い分、間違いなく高速 どのタイミングでも安定したリストア時間が期待できる
41. 41. 42
42. 42. 43 まずはスケールアップ 読み込みはRead Replicaでスケール可能 書き込みはShardingするしかない 容量追加はディスク増設(要停止) or Sharding
43. 43. 44 読み込みスケールがRead Replicaなのは一緒だが、
 Replicaの作成コストが低い（前述） 書き込みはノードとしては１つであるものの、
 分散ディスクによってローカルSSD並の性能が出せているので良好と言える ディスク容量は64TBまで自動でスケール（使った分だけ支払い）
 ※64TBはInnoDBの制限でAurora的にはもっといけるらしい
44. 44. 45
45. 45. 46 RDS for MySQLではない場合はRead Replicaを組んで、
 mysqlfailoverやMHAが一般的 対象が非同期レプリケーションだとデータ損失の可能性有り
 （凖同期でも100%ではない） RDS for MySQLの場合、Multi-AZスタンバイへのレプリケーションは、
 独自の仕組みにより完全同期となっており基本的に損失はない ただし、Multi-AZスタンバイはRead Replicaとしては使えない
46. 46. 47 対象はRead Replicaのいずれか ストレージは同じものであるためデータ損失無し RDS for MySQLのMulti-AZと比べるとスタンバイ分の料金がお得
47. 47. 48
48. 48. 49 基本的に難しい シャットダウンとクラッシュは違う 想定した復旧オペレーションが想定と違いがうまくいかないことも
49. 49. 50 SQLコマンドで障害のシミュレーション可能 インスタンスのクラッシュのような全体障害 NW、Disk等の部分障害 万が一の障害時のオペレーションが簡単にシミュレートでき、
 復旧の確実性が上がる
50. 50. 51
51. 51. 52 InnoDB Buffer Pool Dump(5.6〜) Query CacheはWarming不可 mysqldが止まると消える（InnoDB Buffer Pool Dump以外） 再起動直後は性能が落ちる Buffer Pool Dumpは時間とリストア中の性能への影響が・・・
52. 52. 53 Cache機構は別プロセス Shutdown(正確にはreboot)しても消えない 再起動時の性能が安定する 起動時の影響無し
53. 53. 54
54. 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
55. 55. 56
56. 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 ｀
57. 57. 58
58. 58. 59 特に運用面では優位性が際立つ どんなものにも向き不向きがあるのは当然 運用まで含めてトータルで考えれば、十分選択肢に入る 小中規模よりは、Write Heavyなハイトランザクション環境へおすすめ
 そもそもLarge未満の小さいサイズのインスタンスは提供予定が今のところない Auroraに限らず、新しいものの導入に際しては検証をしよう Auroraはこれからも進化するはずなので、期待したい（もちろんMySQLも）
59. 59. 60
60. 60. 61