Transcript

• 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でこっそり？ｗ