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 for Ops的なお仕事 Like→MySQL、Work→Postgres

AWS Certified SysOps,Dev,SA(Associate) Winner of Tuningathon #5 (MySQL)

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

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

AgendaAuroraってこんなにすごい！

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.slideshare.net/AmazonWebServices/sdd415-new-launch-amazon-aurora-amazons-new-relational-database-engine-aws-reinvent-2014/21

とはいえ、Auroraが速いことを否定するものではない

自分の要件にあっているかは自分で測る

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を取るか、、、で決めちゃって良いの？

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

Auroraが素晴らしいのは間違いないです。

でも、何にでも使える夢のデータベースではきっとありません。

自分の用途にあう方を使いましょう。

お互いの特徴を知り、目的にあったものを使うべき。

そのためのヒントになれば幸いです。

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

の前にちょっと横道

AuroraはMySQL Serverよりも、 MySQL Clusterに似ているのではないか？表向きはMySQLだけど、バックエンドが違うという点

MySQL Clusterはフラグメントと同期レプリケーションを組み合わせたシェアードナッシングアーキテクチャ

AuroraはQuorumで信頼性を担保し、分割による複雑性を排除しつつデータノードのみ多重化している感じ

極限までスケールするのはMySQL Cluster

ただし、大半のアプリケーションそこまで必要ではないので、運用面等も考えるとAuroraは非常に良い所を突いている感じがする

MySQL5.7についてもうそろそろRC（リリース候補版）が出そう？

Auroraは現状、5.6互換

Auroraは追従するのか、独自の機能に注力するのか？

個人的にはオプティマイザやパーサーの改善など、コアの部分は取り込んで欲しい

しかし、FTS、GIS等の機能面は別の道に注力して欲しい

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

Cache

InnoDB Buffer Pool

一番大事なやつ

Auroraのストレージが速かろうと（万が一遅かろうと）ここに載っているデータを見ている場合はきっとあまり変わらない

Readはここに載っていれば速いのとRead Replicaでスケールできるというのもあり、Writeのスループット向上に注力している感もある

Query Cache

AuroraはデフォルトON （RDS for MySQL及びセルフインストール時のデフォルトはOFF）

キャッシュのチェックと更新のオーバヘッドがバカにならないので、多くのケースのOLTPではOFFにした方が良いと言われている

最適化されているのかもしれないが、本当にONのままで良いのか？

Storage

ざっくり補足①：Quorum

http://yoshidashingo.hatenablog.com/entry/2014/11/26/032121

4本の書込みQuorum

残りは非同期で反映

3本の読込みQuorum

3本でデータが揃えば正と言える

DynamoDB等でも使われている

ざっくり補足②：Log structured storage

http://www2.cs.uh.edu/~paris/7360/PowerPoint/LFS3.ppt

ファイルシステムそのものをログのように扱う

書き込みは常に追記

ファイルとそれにまつわるメタデータがまとめて書き出せる

過去データがそのまま取り出せる

SelectFull/Big Scan

ストレージが全く別物なので、これに関しては同じということはまず無い

Log structured storageはデータが連続した領域に書き込まれるため、シーケンシャルアクセスに強そうだが…？

巨大なデータセットをQuorumで多数決するオーバヘッドは？

データがノードを跨がないので、MySQL Clusterみたいに細かなScanが遅いとかはなさそう

最大64TBのデータが入るっていっても、スキャンはできないと思ったほうが良いんだよね？

Random Select

SSD最適化による高速化に期待

Write

ベンチマークが示す通り、速いはず

特にUPDATEやDELETEのコストがLog structured storageの恩恵で大きく下がっていると思われる（あらゆる更新が追記となるためINSERT並のコストになるはず）

Temporary Table

所謂、クソクエリ（だけとは限らないが）に対する性能

Log structuredである必要がない

問い合わせを受けたノードだけが必要で共有する必要もない

Other cores

Parser, Optimizer etc…

このあたりはおそらく一緒

クソクエリはAuroraでもクソクエリだろうから書き直せ(#ﾟДﾟ)ｺﾞﾙｧ!!

後で聞いた話ですが、変わっているそうです。要検証！

Auroraが変える運用

Backup and Recovery

Before

従来は、定期フルバックアップ＋差分バイナリログバックアップ

復旧は直近のフルバックアップをリストアした上で、差分バイナリログによる更新を順次適用

フルバックアップからの更新量に比例して復旧時間が長くなる

RDSなら定期・フルどちらもS3に待避されるため信頼性は非常に高い

After Aurora

過去のデータ全体がそのままの状態で取り出せる

差分適用が無い分、間違いなく高速

かつ、それを継続的にS3へ待避しているため信頼性も抜群

Read Replica

Before

従来は、Masterから受け取ったバイナリログの更新内容をSlaveで同じように適用する

つまり、外から見るとRead Onlyだが、内部的にはガリガリ更新が走っている

SQL(更新を適用する)スレッドがMasterからの更新ログについていけず、遅延することも多い(特に5.6以前はシングルスレッドだったので顕著)

After Aurora

AuroraはMasterとSlaveで同じデータを見ているため、更新処理が必要ない

つまり、100% Readのためだけに性能をフルに使える

ある意味当然だが、基本的にラグがない

Replicaを増やす場合にもデータコピーやログ適用の必要がない

Scaling

Before

まずはスケールアップ

読み込みはRead Replicaでスケール可能

書き込みはShardingするしかない

容量追加はディスク増設 or Sharding

After Aurora

読み込みスケールがRead Replicaなのは一緒だが、Replicaの作成コストが低い（前述）

書き込みはノードとしては１つであるものの、裏のストレージがスケールするので青天井ではないもの期待はできる

ディスク容量は自動でスケール（使った分だけ支払い）

Failover

BeforeRDSではない場合はRead Replicaを組んで、mysqlfailoverやMHAが一般的

対象が非同期レプリケーションだとデータ損失の可能性有り（凖同期でも100%ではない）

RDSの場合、Multi-AZスタンバイへのレプリケーションは、独自の仕組みにより完全同期となっており基本的に損失はない

ただし、Multi-AZスタンバイはRead Replicaとしては使えない

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 AuroraCache機構は別プロセス

Shutdown(正確にはreboot)しても消えない

再起動時の性能が安定する

デフォルトONなくらいだし、きっとQuery Cacheのこと（と思っていた）

InnoDB Buffer Pool Dumpの設定はそれはそれであるので、必要な場合は要設定（と思っていた）

え？それじゃ、、、？

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

基本的には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

まとめと感想Auroraが革新的で素晴らしいのはたしかにそう

特に運用面では優位性が際立つ

どんなものにも向き不向きがある

MySQLの先が不安だからとか、好き嫌いとかで選ぶものではない

小中規模のMySQLよりもむしろ、OracleRACとかエンタープライズの方が乗り換え対象では？

そもそも小さいサイズのインスタンスは提供予定が今のところない

大規模MySQLはAuroraの優位点は大いにあるので、要件とワークロード次第

Auroraに限らず、新しいものの導入に際しては検証をしよう

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

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

MySQLerならAurora弄るの楽しいはず(・∀・)

MySQLっぽいけどMySQLじゃない感じが触ってて面白いまだ途上なので、いっぱい触っていっぱいフィードバックすれば、

より良いものになるはず！

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