cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。
Amazon RDSにAWS独自のエンジン「Amazon Aurora | MySQL PostgreSQL Relational Database | Amazon Web Services」が追加になりました。ただし、開始20分前ですら大行列で、ギリギリに行った自分などは立ち見にすら入ることができなかったので、サービスの詳細を聞き逃してしまいました。
といってもすでにさまざまな資料が公開されているので、これをちょっと読み込んでみて、気になる点はあるか、つまりずばり「今すぐ本番投入すべきか」ちょっと考えてみようと思います。
ちなみに合間合間に質問を書いてますが、回答があれば随時記入していこうと思います。
※2014.11.17 以下のとおりスライドが公開になりましたので、回答にあたる部分を追記してあります。
(SDD415) NEW LAUNCH: Amazon Aurora: Amazon’s New Relational Database Engine | AWS re:Invent 2014 from Amazon Web Services
発表
発表は現地時間11/12 9:00からのKeynoteの中で行なわれました。
- Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDS | AWS News Blog
- AWS News Blog
- Keynoteも正直全く聞いてなかったのでだいぶビハインドを感じますがじゃんじゃん行きましょう。開発に3年かかったって言ってたらしいです。
- Q1. 3年の開発期間とのことですが、Auroraを現在リリースする意味を教えて欲しいです
特徴
- RDSとして5つめにあたる、 MySQL 5.6 互換の独自エンジン
- MySQLに比べて5倍のパフォーマンスを発揮
- Q2. 詳細ページにSysBenchなどで測ったとあるが、ベンチマーク結果などは公開されますか？
- A2. 上記スライドに詳細なパフォーマンス測定結果が載っています。
- Q2. 詳細ページにSysBenchなどで測ったとあるが、ベンチマーク結果などは公開されますか？
- 3つのAZに6つのコピーを持って冗長化される
- Q3. 3つのAZに3つのコピーではなく、6つのコピーである理由は詳細ページにあるQuorumによるパフォーマンス改善のためですか？
- Q4. その場合、読み取り一貫性は大丈夫か教えてください
- 自動でバックアップが Amazon S3 に取得される
- Q5. 取得間隔はどの程度か
- Q6. トランザクション中のデータはコミット済みのものだけで取得されますか？
- r3.large から r3.8xlarge まで選択でき、最大で 32 vCPUs、244GiB メモリまで拡張可能
- Q7. r3系列のみの展開だが、MySQLよりも「メモリ消費量」は多いですか？
- Auroraタイプ(※後述)のリードレプリカは15台まで設置が可能
- Q8. 15台はハードリミットか？ソフトリミットか？
- ストレージは最小10GBから最大64TBまで自動的に拡張される
- Q9. 拡張されるトリガは何か（書き込まれた「メモリ量」か「ディスク量」か）
- Q10. INSERTなどのクエリを大量にかけながらでも内部でリバランスされるのか
- クラスターはVPC内に配置され、内外へのデータ転送時にはデータが暗号化される
- Q11. ここでいうデータの暗号化とは通信経路上のデータの暗号化を指すと思うが、ディスクの暗号化は対応していますか？
- ハイエンドの商用データベースと同一のパフォーマンスを1/10の価格で提供する
- Q12. 具体的なベンチマーク（少なくともどういった条件において同一のパフォーマンスが発揮されたなどの条件）などはありますか？
詳細
概要
- データベースエンジンをSSDベースの仮想ストレージ層と統合することでパフォーマンスと可用性を向上している
- Q13. 仮想ストレージ側では具体的にどういった機能を担っていますか？
- A13. ストレージへの書き込みは「非同期」、書込みクォーラム数は4、読み込みは3箇所からとなる
- Q14. 断片化の管理などはどこのレイヤーで解決してますか？
- Q13. 仮想ストレージ側では具体的にどういった機能を担っていますか？
- リサイズやリストライプの性能劣化はない
- Q15. リストライプは詳細ページにある10GB単位のチャンクということだと思うが、チャンクの中身はシャードなどで管理しているのか、そうであればシャードの管理単位はどういった単位（キーとかサイズとか）ですか？
主要な機能
パフォーマンスや拡張性
高スループットで低ジッタ
- I/O操作はQuorumのような分散システム機能を用いてパフォーマンスの一貫性を改善してある
- SysBenchのような標準的なテストにおいて同一ハードウェア上のMySQLより5倍速かった
ボタン一つでコンピュートスケールを変更
- Amazon RDS API や AWS Management Console から数クリックで使える
- 数分でスケール変更可能
ストレージは自動拡張
- ストレージは必要なタイミングで自動的に最小10GBから最大64TBまでされるか、ユーザーが最大サイズをあらかじめ指定可能
- Q16. アーキテクチャ上、自動で増える場合とあらかじめ取得しておくことで違い（内部的な分散の状態への影響）はありますか？
Amazon Aurora Replicas
- Amazon Aurora Replicas を用いて複数インスタンスからの読み出しが可能になりスループットを上げられる
- Amazon Aurora Replicas はストレージを共有してるので、レプリカへの書込みの必要性を避けながらコストを下げることができる
- Q17. マスターインスタンスとリードレプリカはリードレプリカのほうが安いのか？（価格ページにはリードレプリカの価格が表示されていないので）
- 多くの場合、1桁ミリ秒(10ms未満)のレプリカラグ
信頼性
インスタンス監視と修復
- データベースの故障の際にクラッシュリカバリリプレイ（リストア後のREDOログからのリカバリ）が不要
- データベースプロセスからデータベースバッファキャッシュの管理を隔離しているため
- Q17. バッファキャッシュの管理はストレージ側で行っているのか？（Q13関連）
- マスターインスタンスのフェイルオーバーは3つのAZに最大15台設置できるAurora Replicasに対して実行される。
- レプリカが1台もない場合は自動的に新しいAmazon Aurora DBインスタンスを作成する
- Amazon Aurora ストレージもオートヒーリング（自己修復型）でエラーのスキャンもレプリケーションも自動的に行われる
フォルトトレラント性と自己修復性を持ったストレージ
- データベースボリュームは10GB単位のチャンクで3AZをまたいで6方向にレプリケートされる
- Amazon Auroraストレージは最大3コピーへの書き込みに影響を受けずに、フォールトトレラントで透過的に、最大2つのコピーのクラッシュの修復管理を行っている
自動的で継続的な差分バックアップとポイントインタイムリカバリ
- ポイントインタイムリカバリが行われるため、どの瞬間にも戻せる
- Q18. FAQにあったが、ポイントインタイムリカバリで戻せる時点は5分以内の時点ではないでしょうか？
- バックアップは自動的に差分バックアップで、DBのパフォーマンスには影響しない
- Q19. 初回起動時のバックアップはシームレス？あるいは終わるまで何かブロックされますか？
- 35日までバックアップリテンションピリオドが設定可能
- バックアップはS3に格納される
データベーススナップショット
- ユーザーがすでに取得しているDBスナップショットからデータを戻すことも可能
セキュリティ
RESTおよび内部転送時の暗号化
- SSLを使ってREST APIおよび内部転送時の暗号化を行っている
ネットワーク分離
- VPC内で稼働し、IPsec VPNなどでオンプレミスからも接続ができる
リソースレベル権限
- IAMと統合されている
- リソースにタグづけが可能で、タグの内容によって権限レベルを分割できる（ある人はあるタグがついたインスタンスしか操作できないといった）
管理性
簡単に使える
簡単に移行できる
- 標準的なMySQLのインポート／エクスポートツールが使える
- DBスナップショット(RDS for MySQL)ベースの移行であれば、一時間以内だが、この点は容量による
- Q20. RDS for MySQLは最大3TBだが、この場合でも1時間以内でしょうか？
監視とメトリクス
- AWS Management Console で主要な20以上のメトリクスが表示可能
自動ソフトウェアパッチ
- DB Engine Version Managementを用いてパッチの適用ができる
DBイベント通知
- 40種類以上のイベントがSNSを用いてメールやSMSに通知可能
参照：Amazon Aurora | MySQL PostgreSQL Relational Database | Amazon Web Services
価格
オンデマンドインスタンス価格
| インスタンスタイプ | 仮想CPU | メモリ(GiB) | 料金 |
|---|---|---|---|
| db.r3.large | 2 | 15.25 | $0.29 / 時間 |
| db.r3.xlarge | 4 | 30.5 | $0.58 / 時間 |
| db.r3.2xlarge | 8 | 61 | $1.16 / 時間 |
| db.r3.4xlarge | 16 | 122 | $2.32 / 時間 |
| db.r3.8xlarge | 32 | 244 | $4.64 / 時間 |
- Q21. 東京リージョンに展開するときはもう少し値段高くなりますかね？
- Q22. 東京リージョンはAZが2つしかないんだけどローンチは可能ですか？
- Q23. この値段はマスターインスタンスの値段ですか？それともAurora Replicasも同価格ですか？
DBストレージとI/O
- ストレージは $0.10/GB/月
- I/Oは $0.20/100万リクエスト
- Q24. リクエストとは「操作対象の行数」ですか「I/Oブロックサイズ」ですか？ブロックサイズの場合、それはいくつですか？
バックアップストレージ
- データベースに対して100%のストレージ容量までは無料
- Q25. 容量は実データ容量ですか？圧縮などはしないのですか？
リザーブドインスタンス料金
| インスタンスタイプ | (1年)一時払い | (1年)時間単価 | (3年)一時払い | (3年)時間単価 |
|---|---|---|---|---|
| db.r3.large | $625 | $0.09 / 時間 | $1,250 | $0.06 / 時間 |
| db.r3.xlarge | $1,250 | $0.18 / 時間 | $2,500 | $0.12 / 時間 |
| db.r3.2xlarge | $2,500 | $0.36 / 時間 | $5,000 | $0.24 / 時間 |
| db.r3.4xlarge | $5,000 | $0.72 / 時間 | $10,000 | $0.48 / 時間 |
| db.r3.8xlarge | $10,000 | $1.44 / 時間 | $20,000 | $0.96 / 時間 |
- Q26. AZの概念はないということでよいですか？つまりマスターノードのAZがどこかは関係ないでしょうか？
FAQから
- 「MySQL互換」とはInnoDBを使った場合の接続互換性（wire-compatible）。MyISAMは非対応。
- 移行の方法はいくつかあるが、標準的なmysqldumpでMySQLをエクスポートしてmysqlimportでAuroraにインポート可能。逆もできる（vice-versa）
- SysBench結果では「毎秒 500,000 以上の SELECT」と「毎秒 100,000 以上の update」が達成できた。
- DBスナップショットからのリストアには新規DBインスタンスの作成が必要になる
- Q27. これは他のRDS同様、別のPublic DNSが付与されるという意味でよいですか？
- ポイントインタイムリカバリの場合は過去5分以内に戻すことができる
- データベースのクラッシュ時、チェックポイントのログの適用はインスタンスから切り離されているため、データベースの再起動はたいていの場合60秒以内である
- Q28. ログの適用が切り離されたとしてもインスタンスの停止→起動には通常のEC2であれば数分かかると思うが、特別な対応をしてるのですか（インスタンスのコンテナ仮想化とか）？
- レプリカとして「Amazon Aurora Replicas」と「MySQL Read Replicas」をサポートしており、両者の違いは以下のとおり（MySQL Read Replicasはプレビュー段階では提供されない）
| 機能 | Amazon Aurora Replicas | MySQL Replicas |
|---|---|---|
| レプリカ数 | 最大 15 | 最大 5 |
| レプリカケーション形式 | 非同期(ミリ秒オーダー) | 非同期(秒オーダー) |
| プライマリへの性能影響 | 低 | 高 |
| フェイルオーバー対象に指定可能？ | 可能(データの欠損なし) | 可能(数分程度欠損の可能性あり) |
| 自動フェイルオーバー | はい | いいえ |
| ユーザー定義のレプリケーション遅延をサポートしてるか | いいえ | はい |
| プライマリとのデータやスキーマの違いのサポート | いいえ | はい |
- リードレプリカへのフェイルオーバーは、CNAMEの切替で数分以内に完了する
- リードレプリカへのフェイルオーバーは、プライマリの障害検知（自動）すると、読み込み／書き込みのトラフィックをリードレプリカにルートするようにして行われる。平均的には2分以内くらいで完了する
- リードレプリカを持たない単一Amazon Auroraデータベースの場合、同一AZに新規DBインスタンスを作成（ダメなら別AZに作成）するのに15分以内くらいかかる。
- クロスリージョンレプリカはまだ対応してないけど必要なら要望あげてください
開発ドキュメント
- "Survivable" Cache Warming はDB起動時に前回停止時にキャッシュを保存しておいて、スタート時にメモリに載せることができる機能
- Auroraのセキュリティレベルは3箇所で設定する。「IAM」「VPC」「MySQL User Account Management」
- memcachedオプションも使える（ただしプレビュー版では未提供）
ということで机上でのざっくりとした調査や思いつく質問は上がったので、Amazonさん、ぜひプレビューを早くください。おねがいします。
参照：Managing an Amazon Aurora DB cluster - Amazon Aurora
