先の自分用メモから大分開きましたが、第三弾を投稿します。
今回は『RDS for Aurora』について徒然なるままに書いていきます。
#Auroraって？
高い可用性とパフォーマンスを追及した、MySQLと互換性のあるAmazonお手製のRDBです。
Amazon曰く、"MySQLの5倍のパフォーマンス"だそうです。
MySQLのようなOOSではなく、AmazonのDB専用サーバーのサービス『RDS』の選択できるエンジンの種類の一つとして提供されております。
ただSQLやJDBCなどはMySQLとほとんど変わらないようで、
実際に私が触っていた時間はそんなに長くないですが、
MySQLのSQLとJDBCで普通に使用でき、今のところ違いは感じていません。
ちなみにAuroraの由来ですが、(ちゃんと調べた訳ではないのでホントかどうかは定かではないですが)
『オーロラは雲(Cloud)の上にあるから』だとか。
しゃれてますねーーーー!!!!!!
#MySQLと違いは？
細かいとこや私が把握できていないところもあるかもですが、ざっとあげると
- ストレージ
- Read Replica
- キャッシュ
- 料金
こんなところです。
##ストレージ
Auroraの特徴はまず、ストレージです。
Auroraのストレージは(実際の裏側がどうかわかりませんが)これまでのRDSのように、建てたインスタンスの内部にのみ抱えません。
- 3AZの2つずつ、計6つのコピーデータを作成
- 6つの内4つに書き込めた段階で次の処理が開始されます
- 6つの内2つまでは(障害などで)使えなくなっても、書き込み可用性に影響なし
- 6つの内3つ以上から読み込めたデータのみ読み込み成功データとして判断されます
- 6つの内3つまでは使えなくなっても、読み込み可用性に影響なし
また、書き込みについてもMySQLとは異なり、Log-structured Storageの方式を採用しています。 (後述)
Auroraはストレージ容量が大きいほどIOPSがあがるらしく、ストレージも最低10GBから最大64TBまで自動スケールするので
書き込みが多いケースの場合は適してそうですね。
####Log-structured Storageとは?
がっつり説明すると長くなるので要点だけ
- ログのように常に末尾(or先頭)に追記だけをしていくStorageシステム
- 『更新』も『追加』も平等に追記
- 『更新』によって古くなったほうのデータは適宜GCされる
要するに"Writeが単純なので早い"ってことです。
##Read Replica
Auroraの特徴としてもう一つ外せないのは『Read Replica』についてです。
MySQLはMasterとSlaveが各々ストレージを持ち、Master更新時にバイナリログ等を使ってSlaveにも更新を反映させる方式です。
対してAuroraはMasterもReplicaもストレージは共通です。
上述のように複数のAZにコピーを作成しているため、Replicaが自分用のStorageを持つ必要がありません。
これによるメリットは幾つかあります。
- Master-Slave間の通信がmetadataのみで済む
- Replica分のストレージ料金はかからない (・・・はず。)
- レプリケーション遅延がほぼない
- (障害などで)Masterが落ちた時も欠損しない
- Replica側は低負荷
Replicaは15台まで構築可能で、フェイルオーバー先としても機能します。
フェイルオーバーの時間はレプリカの有無で差があります。
可用性を考慮するのであればレプリケーションは必須かと。
| レプリカあり | レプリカなし |
|---|---|
| 1分程(30秒未満という話も) | 10分程度 |
ただしここまではReplicaもAuroraで建てた場合のお話です。
###AuroraのReplicaをMySQLで建てる
Master：Aurora / Replica：MySQL の構成をとることができます。
但しその場合、バイナリログを使用してのレプリケーションになるため、この設定を有効にする必要があります。
デフォルトで有効だった気がしますが、ウソだったら許してちょ。
そのため上記レプリケーションに対してのメリットがほぼなくなり、そもそも互換性もあるものなので
正直あんまりメリットがあるのか、個人的には疑問です。。
私自身は試してないですが、試した人がいたのでリンク張っておきます。
http://dev.classmethod.jp/cloud/aws/enable-aurora-binary-logs/
##キャッシュ
キャッシュもストレージ同様、DBインスタンスからは切り離されております。
それにより再起動などを実施しても、Cacheが消えることはまずありません。
これのおかげでメンテナンスなどで再起動が掛かった場合もウォームアップすることなくサービスに戻すことができるのです！
##料金
正直計算方法があっている自信が無いので、鵜呑みにはしないでください！！！！
そして正しい計算方法をご存知の方！教えてください・・・
かかる料金としては以下の項目になります
- インスタンスコスト (r3.db.large：$0.29/hour 他)
- MySQLよりちょっと高い
- ストレージ (1GB $0.1)
- 時間に依存せず、使った分だけ毎月かかる
- I/O (100万リクエスト毎に$0.2)
- I/Oの単位 ⇒ Read：16KB / Write：4KB （ウソだったらごめんなさい)
コスト算出例 (月額)
■インスタンスコスト
r3.db.largeを使用する場合
⇒ $0.29 * 24(hour) * 30 (day) = $208.8/月
■ストレージ
一ヶ月間で(月はまたがない)で100GBから1000GBに増加した場合
⇒ 最終的なサイズ：1000GBで計算
⇒ 1000 * 0.1 = $100/月
■I/O
○前提
1回のRead 単位 (KB)：16
1回のWrite 単位 (KB)：4
月のRead数：5000万
月のWrite数：2000万
MySQLでの１レコード分の平均サイズ：48KB (インデックス分を含む)
○算出
Read １回分のI/Oリクエスト数：48/16 = 3
Readの料金 ：{月のRead数} × {Read １回分のI/Oリクエスト数} × {I/O料金} ÷ {100万リクエスト}
⇒ 5000万 × 3 × 0.2 ÷ 100万 = $30/月
Write １回分のI/Oリクエスト数：48/4 = 12
Writeの料金 ：{月のWrite数} × {Write １回分のI/Oリクエスト数} × {I/O料金} ÷ {100万リクエスト}
⇒ 2000万 × 12 × 0.2 ÷ 100万 = $48/月
I/Oの合計コスト：$130/月
全合計：$438.8/月
疑問なのがI/OってCacheに1度のって、そこからReadしているものはI/Oとして料金がかからない、
ってどっかで見た気がするのだけれど、どうなんですかね。。
#ずばり早いの？
さぁ？
まー公式の発表では『MySQLの5倍』と唄っており、ベンチマークとか他に取っている方々の結果では早いらしいですよ。
ただそこまでまだがっつりいじってる訳ではないので断言はできないですが、遅いとはあんまり感じないですね。
Aurora自体が得意としているのは
- 大量の並列処理
- データサイズが大きい
といった状況なのでバッチ利用とかの場合、MySQLから乗り換えると劇的に早くなるのではないでしょうか。
逆にデータサイズが小さい、並列処理がそんなに多くない場合はDynamoDBとかの方が向いてそうですね。
#まとめ
ざっくりまとめると・・
- 複数のコピーを3AZにつくるので障害に強い
- 容量は64TBまで自動スケール
- 書き込みに強い
- レプリカとのタイムラグはほぼ無し
- レプリカをフェイルオーバー先として利用可
- レプリカはAurora以外にもMySQLを選べる
- 再起動してもキャッシュは消えない
- 料金はMySQLより少し高くなっている
ってな感じです。
ホントはもう少しパラメータとかについても書きたかったですが、
今日のところはここまでです。おしまい。