Amazon RDSの新しいDBエンジン「Aurora」について気になるトコロ #reinvent

198件のシェア(すこし話題の記事)

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

よく訓練されたアップル信者、都元です。RDS for Aurora、気になりますね! MySQL 5.6との高互換性を謳っている製品なので、RDS for MySQLとの比較という視点で、色々見て行きましょう。

まず、Auroraは「RDBをAWSが作りなおしたら?」というテーマで新しく作られた製品であるため、インターフェイスをMySQL 5.6互換としているだけで、中身は全く別物であろうと推測されます。これにより、MySQLの5倍のパフォーマンスを実現しています。

お値段

まずは気になるお値段。発表時にはオープンソースDBの価格で、と謳っていますが、具体的にはこんな感じでした。(現在はus-east-1でのpreview公開のみなので、このリージョンで比較)

class MySQL Aurora
db.r3.large $0.240 $0.29
db.r3.xlarge $0.475 $0.58
db.r3.2xlarge $0.945 $1.16
db.r3.4xlarge $1.890 $2.32
db.r3.8xlarge $3.780 $4.64

開発コストは掛かったでしょうから、さすがにMySQLと同価格、とは行かなかったようですが、概ね1.2倍強の価格で提供されています。詳しくは料金表を御覧ください。

ちなみに、インスタンスクラスの選択肢は、現状上記5種類のようです。開発環境用にt2シリーズも欲しいですねぇ…。

MySQL 5.6からのマイグレーション

マイグレーションには2つの選択肢があります。1つ目は「mysqldump & mysqlimport」、単純にダンプして、それをAuroraに食わせればいいんですね。見た目にも分かりやすいです。

もう一つはMySQLのDBスナップショットからAuroraのインスタンスを立てることもできるようです。これは簡単。

制限事項としては2つ。MyISAMエンジンを使っている場合は、予めInnoDBに変換しておく必要があります。そもそもRDS for MySQLでは推奨されていなかったエンジンではありますが。

もう一つの制限事項はinnodb_file_per_tableオプションが有効な状態で作られたテーブルもサポートしないようです。従って、このオプションは無効にし、対象テーブルも元に戻しておく必要があります。

ストレージの拡張

従来のRDSでは、ストレージ容量が不足した場合、手動で領域拡張の操作をする *1必要がありました。

これは「あらゆるシステムは、正常なライフサイクルをひた走っていたとしても、管理をしなければ、ディスク容量不足による障害を避ける事ができない」という悲しい現実を表しています。RDS for MySQLを立てた場合は、CloudWatchによる空き容量アラームは必須です。アプリケーションがバグってなくても、いつか容量は底をつくのですから…。

一方Auroraでは。Auroraのストレージは、10GB単位で勝手に増えます! SUGEEE! 地味かもしれませんが、これは嬉しい特徴です。正にAdministration Free *2

ちなみに、最低ストレージ容量は10GBとのことです。

インスタンスクラスのスケールアップ

これは、正直RDS for MySQLとあまり変わらないようです。ダウンタイムも存在します。

バックアップとリストア

ドキュメントに「Automated backups are always enabled」とありました。つまり、逆に、自動バックアップを止めることは出来ないのかもしれません。まぁ、普通バックアップしますよね。

その他、マニュアルバックアップや、リストアの方法、Point-in-timeリカバリ等は、MySQLと同等のようです。

多重化(耐障害性と読み込み性能拡張性)

RDS for MySQLでは、Multi-AZとRead-Replicaという2通りの多重化方式がありました。前者が障害耐性を担い、後者が読み込み性能拡張性を担っています。

しかし、逆に言えば。Multi-AZとして、プライマリの他にセカンダリとして、もう一台分のリソースを消費しつつも、障害が無い限り、セカンダリが利用されることは無く、読み込み性能拡張性に寄与することはできませんでした。

そして、Read-Replicaは、読み込み性能拡張性に寄与するものの、障害耐性への寄与は薄い(Multi-AZほどではない)のが現実でした。Multi-AZは障害検知し次第、自動的にフェイルオーバーが起こり、自己修復を行いますが、Read-Replicaは自動的な復旧は行いません。手動で(旧)マスタを切り離し、マスタ昇格することはできるので、障害耐性への寄与が無いわけではないとは思います。

そんな中、Auroraでは「Aurora Replica」と呼ばれる多重化方式のみが提供され、障害耐性と読み込み性能拡張性の両方をカバーするようになっています。つまり、通常はリードレプリカとして機能しつつ、障害時のフェイルオーバー先としても機能します。AWS上で本番用RDSを運用する場合は、通常Multi-AZとするはずです。その隠れた1台が、リードレプリカとしても利用できると考えると、嬉しいですね。

ところで、Aurora Replicaは、書き込まれたデータを3つのAZに2つずつ、計6箇所に多重化します。6つのストレージのうち、同時に2つに障害が発生しても書き込み可用性を損ないません *3! そして、同時に3つに障害が発生しても読み込み可用性を損ないません *4! 凄いですね。

さて、実際にフェイルオーバーが起こる時。Aurora Replicaがある場合はレプリカのマスタ昇格及びエンドポイントのCNAMEフリップが発生します。これはRDS for MySQLと同じですね。ただ、所要時間は短縮され、平均的には2分とのことです。そしてレプリカが無い場合は、新しいインスタンスを作ることになるため、15分程度掛かるとのこと。ちなみに、Aurora Replicaに対して読み込みトラフィックがある中で、フェイルオーバーによるマスタ昇格が発生すると、一時的にインタラプトが発生するようです。

次にレプリカの方式です。MySQLのレプリカでは、Multi-AZでは各インスタンスに属するストレージに対する同期書き込み、Read-Replicaでは非同期書き込みを行っていました。つまり、後者にはレプリカ・ラグがあると言えます。実際、MySQLレプリカには秒オーダーのラグが発生することがあります。

Auroraレプリカは、どうやら複数のノードで同じストレージを共有 *5しているようです。そのため、論理的にはレプリカ・ラグは無いことになります。まぁ、実際には10ms程度のラグがあるようですが、ほぼ問題にならないかと。

ということで、クラッシュリカバリ時の挙動にも差が出てきます。MySQLのクラッシュリカバリでは、5分毎のチェックポイントからredoログを適用(その後に整合性チェック)するというリカバリ方式をとっていました。Auroraではそもそも共有ストレージなので、この時間消費がありません。

まとめ

個人的には、Multi-AZとRead-Replicaの統合が嬉しかったです。早く使ってみたいですね!

脚注

  1. まぁ、その場合でもサービスは継続したまま、ダウンタイム無しで行うことができました。
  2. とは言え64TBというキャップはあるのですが。
  3. つまり、2つ同時に障害が起きていても書ける! 3つだと書けなくなる…。
  4. つまり、3つ同時に障害が起きていても読める! 4つだと読めなくなる…。
  5. 私、これを聞いた時「えっ!」と思ったんです。もしかしたらEBSボリュームが複数インスタンスから共有できるようなNFS的な機能が…。出たりしないかなぁ。まぁ、そもそもEBSじゃない可能性も充分あるので何とも言えません…。