1. Infra寄りのDevがお送りする
RDS for Aurora徹底検証
“Aurora” is a new amazing RDBS that is not “MySQL”

2. えっと、誰ですか？
Masashi Terui
JIG-SAW 札幌オフィス
技術開発グループ リーダー
Twitter: @marcy_terui
Github: marcy-terui
Facebook: marcy.terui
Dev for Ops的なお仕事
Like→MySQL、Work→Postgres
AWS Certified SysOps,Dev,SA(Associate)
Winner of Tuningathon #5 (MySQL)

3. Limited Preview中につき情報の開示に制限があるため、
煮え切らない表現に感じる部分があるかと思いますが、
何卒ご理解ください。

4. 今までのMySQLとの違いにフォーカスし、
仮説と検証を元に、インフラ寄りの開発者の目線から
Auroraを実戦で使うためのヒントをお伝えできればと思います。

5. Agenda
Auroraってこんなにすごい！
Auroraに対する評判（一部）
Auroraの特徴からInfra寄りなDev視点で見る着目点
Auroraで変わる運用
Auroraへの移行方法
まとめと感想

6. Auroraってこんなにすごい！
MySQLより5倍速い
高い耐障害性
商用エンタープライズDBより遥かに安い価格で同等の機能
クラウドのためにRDBMSを再設計
MySQL 5.6.10互換
etc…

7. Auroraに対する評判（一部）
革新的
これぞ、クラウド時代のデータベース
うまい、はやい、やすい
MySQLはOracleに買収されて先が不安だから乗り換えたい
MySQLはもう要らない子？

8. それで本当に良いの？

9. 全くトレードオフのないアーキテクチャなど存在しない
SSD, scale-out, multi-tenant storage
Quorum
Log structured storage
Service Oriented Architecture

10. 開発元のベンチマーク結果を鵜呑みにしてはいけない
AWS, Auroraに限らず
例：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が速いことを否定するものではない
自分の要件にあっているかは自分で測る

11. Oracle買収後のMySQLの動向を知らないのでは？
Oracleが買収時に約束した保証期間の5年が過ぎ、どうなったか？
http://www.itmedia.co.jp/enterprise/articles/0912/14/news083.html
Sun時代よりはるかにリソース投入してるし、進化してる
http://japan.zdnet.com/article/35056719/
じゃあ、Amazonは？
• 圧倒的なAWSの進化スピード
• 今までに廃止したサービスは「0」
Amazonを取るか、Oracleを取るか、、、で決めちゃって良いの？

12. じゃあ、何を使えば良いのさ！？

13. Auroraが素晴らしいのは間違いないです。
でも、何にでも使える夢のデータベースではきっとありません。
自分の用途にあう方を使いましょう。
お互いの特徴を知り、目的にあったものを使うべき。
そのためのヒントになれば幸いです。

14. Auroraの特徴から
Infra寄りなDev視点で見る着目点

15. の前にちょっと横道

16. AuroraはMySQL Serverよりも、
MySQL Clusterに似ているのではないか？
表向きはMySQLだけど、バックエンドが違うという点
MySQL Clusterはフラグメントと同期レプリケーションを組み合わせた
シェアードナッシングアーキテクチャ
AuroraはQuorumで信頼性を担保し、
分割による複雑性を排除しつつデータノードのみ多重化している感じ
極限までスケールするのはMySQL Cluster
ただし、大半のアプリケーションそこまで必要ではないので、運用面等も考えると
Auroraは非常に良い所を突いている感じがする

17. MySQL5.7について
もうそろそろRC（リリース候補版）が出そう？
Auroraは現状、5.6互換
Auroraは追従するのか、独自の機能に注力するのか？
個人的にはオプティマイザやパーサーの改善など、
コアの部分は取り込んで欲しい
しかし、FTS、GIS等の機能面は別の道に注力して欲しい

18. Auroraの特徴から
Infra寄りなDev視点で見る着目点

19. Cache

20. InnoDB Buffer Pool
一番大事なやつ
Auroraのストレージが速かろうと（万が一遅かろうと）
ここに載っているデータを見ている場合はきっとあまり変わらない
Readはここに載っていれば速いのとRead Replicaでスケールできる
というのもあり、Writeのスループット向上に注力している感もある

21. Query Cache
AuroraはデフォルトON
（RDS for MySQL及びセルフインストール時のデフォルトはOFF）
キャッシュのチェックと更新のオーバヘッドがバカにならないので、
多くのケースのOLTPではOFFにした方が良いと言われている
最適化されているのかもしれないが、本当にONのままで良いのか？

22. Storage

23. ざっくり補足①：Quorum
http://yoshidashingo.hatenablog.com/entry/2014/11/26/032121
4本の書込みQuorum
残りは非同期で反映
3本の読込みQuorum
3本でデータが えば正と言える
DynamoDB等でも使われている

24. ざっくり補足②：Log structured storage
http://www2.cs.uh.edu/~paris/7360/PowerPoint/LFS3.ppt
ファイルシステムそのものを
ログのように扱う
書き込みは常に追記
ファイルとそれにまつわるメタデータが
まとめて書き出せる
過去データがそのまま取り出せる

25. Select
Full/Big Scan
ストレージが全く別物なので、これに関しては同じということはまず無い
Log structured storageはデータが連続した領域に書き込まれるため、
シーケンシャルアクセスに強そうだが…？
巨大なデータセットをQuorumで多数決するオーバヘッドは？
データがノードを跨がないので、
MySQL Clusterみたいに細かなScanが遅いとかはなさそう
最大64TBのデータが入るっていっても、スキャンはできないと思ったほうが良いんだよね？
Random Select
SSD最適化による高速化に期待

26. Write
ベンチマークが示す通り、速いはず
特にUPDATEやDELETEのコストが
Log structured storageの恩恵で大きく下がっていると思われる
（あらゆる更新が追記となるためINSERT並のコストになるはず）

27. Temporary Table
所謂、クソクエリ（だけとは限らないが）に対する性能
Log structuredである必要がない
問い合わせを受けたノードだけが必要で共有する必要もない

28. Other cores

29. Parser, Optimizer etc…
このあたりはおそらく一緒
クソクエリはAuroraでもクソクエリだろうから書き直せ(#ﾟДﾟ)ｺﾞﾙｧ!!
後で聞いた話ですが、
変わっているそうです。要検証！

30. Auroraが変える運用

31. Backup and Recovery

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

33. After Aurora
過去のデータ全体がそのままの状態で取り出せる
差分適用が無い分、間違いなく高速
かつ、それを継続的にS3へ待避しているため信頼性も抜群

34. Read Replica

35. Before
従来は、Masterから受け取ったバイナリログの更新内容を
Slaveで同じように適用する
つまり、外から見るとRead Onlyだが、
内部的にはガリガリ更新が走っている
SQL(更新を適用する)スレッドがMasterからの更新ログについていけず、
遅延することも多い(特に5.6以前はシングルスレッドだったので顕著)

36. After Aurora
AuroraはMasterとSlaveで同じデータを見ているため、
更新処理が必要ない
つまり、100% Readのためだけに性能をフルに使える
ある意味当然だが、基本的にラグがない
Replicaを増やす場合にもデータコピーやログ適用の必要がない

37. Scaling

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

39. After Aurora
読み込みスケールがRead Replicaなのは一緒だが、
Replicaの作成コストが低い（前述）
書き込みはノードとしては１つであるものの、
裏のストレージがスケールするので青天井ではないもの期待はできる
ディスク容量は自動でスケール（使った分だけ支払い）

40. Failover

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

42. After Aurora
対象はRead Replicaのいずれか
ストレージは同じものであるためデータ損失無し
スタンバイ分の料金が浮く

43. Simulate Failures

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

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

46. Cache Warming

47. Before
InnoDB Buffer Pool Dump(5.6∼)
Query CacheはWarming不可
mysqldが止まると消える（InnoDB Buffer Pool Dump以外）
再起動直後は性能が落ちる

48. After Aurora
Cache機構は別プロセス
Shutdown(正確にはreboot)しても消えない
再起動時の性能が安定する
デフォルトONなくらいだし、きっとQuery Cacheのこと（と思っていた）
InnoDB Buffer Pool Dumpの設定はそれはそれであるので、
必要な場合は要設定（と思っていた）
え？それじゃ、、、？

49. Auroraへの移行方法
使いたくなってきましたか？

50. 基本的にはRDSと同じ
mysqldump
RDS for MySQLからならスナップショットマイグレーションが可能
ただし、innodb_file_per_table=1だとNG
無停止（に近い）移行ならRDS Slaveにmysqldump --single-transaction --
master-data=2 (あるいは--dump-slave=2)のデータをインポートして、外部
Msaterにぶらさげる方式で行けそう
（時間切れで検証できませんでした…Preview来たの5日前…orz）
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/
MySQL.Procedural.Importing.NonRDSRepl.html

51. まとめと感想
Auroraが革新的で素晴らしいのはたしかにそう
特に運用面では優位性が際立つ
どんなものにも向き不向きがある
MySQLの先が不安だからとか、好き嫌いとかで選ぶものではない
小中規模のMySQLよりもむしろ、OracleRACとかエンタープライズの方が乗り換え対象では？
そもそも小さいサイズのインスタンスは提供予定が今のところない
大規模MySQLはAuroraの優位点は大いにあるので、要件とワークロード次第
Auroraに限らず、新しいものの導入に際しては検証をしよう

52. Limited Preview中につき、
今後変わる可能性があります。

53. Previw来てる方、これから来る方
まずは色々弄ってみましょう
その時、今日のお話を思い出していただければ幸いです

54. MySQLerなら
Aurora弄るの楽しいはず(・ ・)
MySQLっぽいけどMySQLじゃない感じが触ってて面白い
まだ途上なので、いっぱい触っていっぱいフィードバックすれば、
より良いものになるはず！

55. ありがとうございました！
ここでは言えない話はPub Crawlでこっそり？ｗ