Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Infra寄りのDevがお送りする
RDS for Aurora徹底検証
“Aurora” is a new amazing RDBS that is not “MySQL”
えっと、誰ですか?
Masashi Terui
JIG-SAW 札幌オフィス
技術開発グループ リーダー
Twitter: @marcy_terui
Github: marcy-terui
Facebook: marcy.terui
Dev f...
Limited Preview中につき情報の開示に制限があるため、
煮え切らない表現に感じる部分があるかと思いますが、
何卒ご理解ください。
今までのMySQLとの違いにフォーカスし、
仮説と検証を元に、インフラ寄りの開発者の目線から
Auroraを実戦で使うためのヒントをお伝えできればと思います。
Agenda
Auroraってこんなにすごい!
Auroraに対する評判(一部)
Auroraの特徴からInfra寄りなDev視点で見る着目点
Auroraで変わる運用
Auroraへの移行方法
まとめと感想
Auroraってこんなにすごい!
MySQLより5倍速い
高い耐障害性
商用エンタープライズDBより遥かに安い価格で同等の機能
クラウドのためにRDBMSを再設計
MySQL 5.6.10互換
etc…
Auroraに対する評判(一部)
革新的
これぞ、クラウド時代のデータベース
うまい、はやい、やすい
MySQLはOracleに買収されて先が不安だから乗り換えたい
MySQLはもう要らない子?
それで本当に良いの?
全くトレードオフのないアーキテクチャなど存在しない
SSD, scale-out, multi-tenant storage
Quorum
Log structured storage
Service Oriented Architecture
開発元のベンチマーク結果を鵜呑みにしてはいけない
AWS, Auroraに限らず
例:RDS 30kPIOPSがi2.8xlargeのローカルSSDより書き込みが速い
なんて、ちゃんとチューニングしてないのでは?

http://www.sli...
Oracle買収後のMySQLの動向を知らないのでは?
Oracleが買収時に約束した保証期間の5年が過ぎ、どうなったか?

http://www.itmedia.co.jp/enterprise/articles/0912/14/news08...
じゃあ、何を使えば良いのさ!?
Auroraが素晴らしいのは間違いないです。
でも、何にでも使える夢のデータベースではきっとありません。
自分の用途にあう方を使いましょう。
お互いの特徴を知り、目的にあったものを使うべき。
そのためのヒントになれば幸いです。
Auroraの特徴から
Infra寄りなDev視点で見る着目点
の前にちょっと横道
AuroraはMySQL Serverよりも、
MySQL Clusterに似ているのではないか?
表向きはMySQLだけど、バックエンドが違うという点
MySQL Clusterはフラグメントと同期レプリケーションを組み合わせた

シェアード...
MySQL5.7について
もうそろそろRC(リリース候補版)が出そう?
Auroraは現状、5.6互換
Auroraは追従するのか、独自の機能に注力するのか?
個人的にはオプティマイザやパーサーの改善など、

コアの部分は取り込んで欲しい
しか...
Auroraの特徴から
Infra寄りなDev視点で見る着目点
Cache
InnoDB Buffer Pool
一番大事なやつ
Auroraのストレージが速かろうと(万が一遅かろうと)

ここに載っているデータを見ている場合はきっとあまり変わらない
Readはここに載っていれば速いのとRead Replicaでスケー...
Query Cache
AuroraはデフォルトON

(RDS for MySQL及びセルフインストール時のデフォルトはOFF)
キャッシュのチェックと更新のオーバヘッドがバカにならないので、

多くのケースのOLTPではOFFにした方が良い...
Storage
ざっくり補足①:Quorum
http://yoshidashingo.hatenablog.com/entry/2014/11/26/032121
4本の書込みQuorum

残りは非同期で反映

3本の読込みQuorum

3本でデータが ...
ざっくり補足②:Log structured storage
http://www2.cs.uh.edu/~paris/7360/PowerPoint/LFS3.ppt
ファイルシステムそのものを

ログのように扱う

書き込みは常に追記

フ...
Select
Full/Big Scan
ストレージが全く別物なので、これに関しては同じということはまず無い
Log structured storageはデータが連続した領域に書き込まれるため、

シーケンシャルアクセスに強そうだが…?
巨大...
Write
ベンチマークが示す通り、速いはず
特にUPDATEやDELETEのコストが

Log structured storageの恩恵で大きく下がっていると思われる

(あらゆる更新が追記となるためINSERT並のコストになるはず)
Temporary Table
所謂、クソクエリ(だけとは限らないが)に対する性能
Log structuredである必要がない
問い合わせを受けたノードだけが必要で共有する必要もない
Other cores
Parser, Optimizer etc…
このあたりはおそらく一緒
クソクエリはAuroraでもクソクエリだろうから書き直せ(#゚Д゚)ゴルァ!!
後で聞いた話ですが、

変わっているそうです。要検証!
Auroraが変える運用
Backup and Recovery
Before
従来は、定期フルバックアップ+差分バイナリログバックアップ
復旧は直近のフルバックアップをリストアした上で、

差分バイナリログによる更新を順次適用
フルバックアップからの更新量に比例して復旧時間が長くなる
RDSなら定期・フルど...
After Aurora
過去のデータ全体がそのままの状態で取り出せる
差分適用が無い分、間違いなく高速
かつ、それを継続的にS3へ待避しているため信頼性も抜群
Read Replica
Before
従来は、Masterから受け取ったバイナリログの更新内容を

Slaveで同じように適用する
つまり、外から見るとRead Onlyだが、

内部的にはガリガリ更新が走っている
SQL(更新を適用する)スレッドがMasterからの...
After Aurora
AuroraはMasterとSlaveで同じデータを見ているため、

更新処理が必要ない
つまり、100% Readのためだけに性能をフルに使える
ある意味当然だが、基本的にラグがない
Replicaを増やす場合にもデ...
Scaling
Before
まずはスケールアップ
読み込みはRead Replicaでスケール可能
書き込みはShardingするしかない
容量追加はディスク増設 or Sharding
After Aurora
読み込みスケールがRead Replicaなのは一緒だが、

Replicaの作成コストが低い(前述)
書き込みはノードとしては1つであるものの、

裏のストレージがスケールするので青天井ではないもの期待はできる
ディ...
Failover
Before
RDSではない場合はRead Replicaを組んで、

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

(凖同期でも100%ではない)
RDSの場合、Multi-AZスタンバ...
After Aurora
対象はRead Replicaのいずれか
ストレージは同じものであるためデータ損失無し
スタンバイ分の料金が浮く
Simulate Failures
Before
基本的に難しい
シャットダウンとクラッシュは違う
想定した復旧オペレーションが想定と違いがうまくいかないことも
After Aurora
SQLコマンドで障害のシミュレーション可能
インスタンスのクラッシュのような全体障害
NW、Disk等の部分障害
万が一の障害時のオペレーションが簡単にシミュレートでき、

復旧の確実性が上がる
Cache Warming
Before
InnoDB Buffer Pool Dump(5.6∼)
Query CacheはWarming不可
mysqldが止まると消える(InnoDB Buffer Pool Dump以外)
再起動直後は性能が落ちる
After Aurora
Cache機構は別プロセス
Shutdown(正確にはreboot)しても消えない
再起動時の性能が安定する
デフォルトONなくらいだし、きっとQuery Cacheのこと(と思っていた)
InnoDB Buffer ...
Auroraへの移行方法
使いたくなってきましたか?
基本的にはRDSと同じ
mysqldump
RDS for MySQLからならスナップショットマイグレーションが可能

ただし、innodb_file_per_table=1だとNG
無停止(に近い)移行ならRDS Slaveにmysqldump...
まとめと感想
Auroraが革新的で素晴らしいのはたしかにそう
特に運用面では優位性が際立つ
どんなものにも向き不向きがある
MySQLの先が不安だからとか、好き嫌いとかで選ぶものではない
小中規模のMySQLよりもむしろ、OracleRACと...
Limited Preview中につき、

今後変わる可能性があります。
Previw来てる方、これから来る方

まずは色々弄ってみましょう
その時、今日のお話を思い出していただければ幸いです
MySQLerなら

Aurora弄るの楽しいはず(・ ・)
MySQLっぽいけどMySQLじゃない感じが触ってて面白い

まだ途上なので、いっぱい触っていっぱいフィードバックすれば、

より良いものになるはず!
ありがとうございました!
ここでは言えない話はPub Crawlでこっそり?w
Upcoming SlideShare
Loading in …5
×

[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証

8,923 views

Published on

JAWS Days 2015 AWS Technical Deep Dive

Published in: Technology

[Deep Dive]Infra寄りのDevがお送りするRDS for Aurora徹底検証

  1. 1. Infra寄りのDevがお送りする RDS for Aurora徹底検証 “Aurora” is a new amazing RDBS that is not “MySQL”
  2. 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. 3. Limited Preview中につき情報の開示に制限があるため、 煮え切らない表現に感じる部分があるかと思いますが、 何卒ご理解ください。
  4. 4. 今までのMySQLとの違いにフォーカスし、 仮説と検証を元に、インフラ寄りの開発者の目線から Auroraを実戦で使うためのヒントをお伝えできればと思います。
  5. 5. Agenda Auroraってこんなにすごい! Auroraに対する評判(一部) Auroraの特徴からInfra寄りなDev視点で見る着目点 Auroraで変わる運用 Auroraへの移行方法 まとめと感想
  6. 6. Auroraってこんなにすごい! MySQLより5倍速い 高い耐障害性 商用エンタープライズDBより遥かに安い価格で同等の機能 クラウドのためにRDBMSを再設計 MySQL 5.6.10互換 etc…
  7. 7. Auroraに対する評判(一部) 革新的 これぞ、クラウド時代のデータベース うまい、はやい、やすい MySQLはOracleに買収されて先が不安だから乗り換えたい MySQLはもう要らない子?
  8. 8. それで本当に良いの?
  9. 9. 全くトレードオフのないアーキテクチャなど存在しない SSD, scale-out, multi-tenant storage Quorum Log structured storage Service Oriented Architecture
  10. 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. 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. 12. じゃあ、何を使えば良いのさ!?
  13. 13. Auroraが素晴らしいのは間違いないです。 でも、何にでも使える夢のデータベースではきっとありません。 自分の用途にあう方を使いましょう。 お互いの特徴を知り、目的にあったものを使うべき。 そのためのヒントになれば幸いです。
  14. 14. Auroraの特徴から Infra寄りなDev視点で見る着目点
  15. 15. の前にちょっと横道
  16. 16. AuroraはMySQL Serverよりも、 MySQL Clusterに似ているのではないか? 表向きはMySQLだけど、バックエンドが違うという点 MySQL Clusterはフラグメントと同期レプリケーションを組み合わせた
 シェアードナッシングアーキテクチャ AuroraはQuorumで信頼性を担保し、
 分割による複雑性を排除しつつデータノードのみ多重化している感じ 極限までスケールするのはMySQL Cluster ただし、大半のアプリケーションそこまで必要ではないので、運用面等も考えると Auroraは非常に良い所を突いている感じがする
  17. 17. MySQL5.7について もうそろそろRC(リリース候補版)が出そう? Auroraは現状、5.6互換 Auroraは追従するのか、独自の機能に注力するのか? 個人的にはオプティマイザやパーサーの改善など、
 コアの部分は取り込んで欲しい しかし、FTS、GIS等の機能面は別の道に注力して欲しい
  18. 18. Auroraの特徴から Infra寄りなDev視点で見る着目点
  19. 19. Cache
  20. 20. InnoDB Buffer Pool 一番大事なやつ Auroraのストレージが速かろうと(万が一遅かろうと)
 ここに載っているデータを見ている場合はきっとあまり変わらない Readはここに載っていれば速いのとRead Replicaでスケールできる
 というのもあり、Writeのスループット向上に注力している感もある
  21. 21. Query Cache AuroraはデフォルトON
 (RDS for MySQL及びセルフインストール時のデフォルトはOFF) キャッシュのチェックと更新のオーバヘッドがバカにならないので、
 多くのケースのOLTPではOFFにした方が良いと言われている 最適化されているのかもしれないが、本当にONのままで良いのか?
  22. 22. Storage
  23. 23. ざっくり補足①:Quorum http://yoshidashingo.hatenablog.com/entry/2014/11/26/032121 4本の書込みQuorum 残りは非同期で反映 3本の読込みQuorum 3本でデータが えば正と言える DynamoDB等でも使われている
  24. 24. ざっくり補足②:Log structured storage http://www2.cs.uh.edu/~paris/7360/PowerPoint/LFS3.ppt ファイルシステムそのものを
 ログのように扱う 書き込みは常に追記 ファイルとそれにまつわるメタデータが
 まとめて書き出せる 過去データがそのまま取り出せる
  25. 25. Select Full/Big Scan ストレージが全く別物なので、これに関しては同じということはまず無い Log structured storageはデータが連続した領域に書き込まれるため、
 シーケンシャルアクセスに強そうだが…? 巨大なデータセットをQuorumで多数決するオーバヘッドは? データがノードを跨がないので、
 MySQL Clusterみたいに細かなScanが遅いとかはなさそう 最大64TBのデータが入るっていっても、スキャンはできないと思ったほうが良いんだよね? Random Select SSD最適化による高速化に期待
  26. 26. Write ベンチマークが示す通り、速いはず 特にUPDATEやDELETEのコストが
 Log structured storageの恩恵で大きく下がっていると思われる
 (あらゆる更新が追記となるためINSERT並のコストになるはず)
  27. 27. Temporary Table 所謂、クソクエリ(だけとは限らないが)に対する性能 Log structuredである必要がない 問い合わせを受けたノードだけが必要で共有する必要もない
  28. 28. Other cores
  29. 29. Parser, Optimizer etc… このあたりはおそらく一緒 クソクエリはAuroraでもクソクエリだろうから書き直せ(#゚Д゚)ゴルァ!! 後で聞いた話ですが、 変わっているそうです。要検証!
  30. 30. Auroraが変える運用
  31. 31. Backup and Recovery
  32. 32. Before 従来は、定期フルバックアップ+差分バイナリログバックアップ 復旧は直近のフルバックアップをリストアした上で、
 差分バイナリログによる更新を順次適用 フルバックアップからの更新量に比例して復旧時間が長くなる RDSなら定期・フルどちらもS3に待避されるため信頼性は非常に高い
  33. 33. After Aurora 過去のデータ全体がそのままの状態で取り出せる 差分適用が無い分、間違いなく高速 かつ、それを継続的にS3へ待避しているため信頼性も抜群
  34. 34. Read Replica
  35. 35. Before 従来は、Masterから受け取ったバイナリログの更新内容を
 Slaveで同じように適用する つまり、外から見るとRead Onlyだが、
 内部的にはガリガリ更新が走っている SQL(更新を適用する)スレッドがMasterからの更新ログについていけず、
 遅延することも多い(特に5.6以前はシングルスレッドだったので顕著)
  36. 36. After Aurora AuroraはMasterとSlaveで同じデータを見ているため、
 更新処理が必要ない つまり、100% Readのためだけに性能をフルに使える ある意味当然だが、基本的にラグがない Replicaを増やす場合にもデータコピーやログ適用の必要がない
  37. 37. Scaling
  38. 38. Before まずはスケールアップ 読み込みはRead Replicaでスケール可能 書き込みはShardingするしかない 容量追加はディスク増設 or Sharding
  39. 39. After Aurora 読み込みスケールがRead Replicaなのは一緒だが、
 Replicaの作成コストが低い(前述) 書き込みはノードとしては1つであるものの、
 裏のストレージがスケールするので青天井ではないもの期待はできる ディスク容量は自動でスケール(使った分だけ支払い)
  40. 40. Failover
  41. 41. Before RDSではない場合はRead Replicaを組んで、
 mysqlfailoverやMHAが一般的 対象が非同期レプリケーションだとデータ損失の可能性有り
 (凖同期でも100%ではない) RDSの場合、Multi-AZスタンバイへのレプリケーションは、
 独自の仕組みにより完全同期となっており基本的に損失はない ただし、Multi-AZスタンバイはRead Replicaとしては使えない
  42. 42. After Aurora 対象はRead Replicaのいずれか ストレージは同じものであるためデータ損失無し スタンバイ分の料金が浮く
  43. 43. Simulate Failures
  44. 44. Before 基本的に難しい シャットダウンとクラッシュは違う 想定した復旧オペレーションが想定と違いがうまくいかないことも
  45. 45. After Aurora SQLコマンドで障害のシミュレーション可能 インスタンスのクラッシュのような全体障害 NW、Disk等の部分障害 万が一の障害時のオペレーションが簡単にシミュレートでき、
 復旧の確実性が上がる
  46. 46. Cache Warming
  47. 47. Before InnoDB Buffer Pool Dump(5.6∼) Query CacheはWarming不可 mysqldが止まると消える(InnoDB Buffer Pool Dump以外) 再起動直後は性能が落ちる
  48. 48. After Aurora Cache機構は別プロセス Shutdown(正確にはreboot)しても消えない 再起動時の性能が安定する デフォルトONなくらいだし、きっとQuery Cacheのこと(と思っていた) InnoDB Buffer Pool Dumpの設定はそれはそれであるので、
 必要な場合は要設定(と思っていた) え?それじゃ、、、?
  49. 49. Auroraへの移行方法 使いたくなってきましたか?
  50. 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. 51. まとめと感想 Auroraが革新的で素晴らしいのはたしかにそう 特に運用面では優位性が際立つ どんなものにも向き不向きがある MySQLの先が不安だからとか、好き嫌いとかで選ぶものではない 小中規模のMySQLよりもむしろ、OracleRACとかエンタープライズの方が乗り換え対象では? そもそも小さいサイズのインスタンスは提供予定が今のところない 大規模MySQLはAuroraの優位点は大いにあるので、要件とワークロード次第 Auroraに限らず、新しいものの導入に際しては検証をしよう
  52. 52. Limited Preview中につき、
 今後変わる可能性があります。
  53. 53. Previw来てる方、これから来る方
 まずは色々弄ってみましょう その時、今日のお話を思い出していただければ幸いです
  54. 54. MySQLerなら
 Aurora弄るの楽しいはず(・ ・) MySQLっぽいけどMySQLじゃない感じが触ってて面白い
 まだ途上なので、いっぱい触っていっぱいフィードバックすれば、
 より良いものになるはず!
  55. 55. ありがとうございました! ここでは言えない話はPub Crawlでこっそり?w

×