[Aurora] インスタンスタイプをdb.r3.largeからdb.t2.mediumに変更してみた

2016.11.25

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

はじめに

AWSチームのすずきです。

AWSがマネージドサービスとして提供する、MySQL互換のRDBMS Amazon Aurora。 2016年11月のアップデートにより、開発、評価環境向けのインスタンスタイプとして「db.t2.medium」を利用する事が可能になりました。

今回、弊社開発環境のAuroraインスタンスを、「db.r3.large」から「db.t2.medium」に変更する機会がありましたので、 その内容を紹介します。

環境情報

  • リージョン : 東京
  • エンジン: Aurora 5.6.10a
  • インスタンス数: 1

手順

クラスタのアップグレード

  • Aurora クラスタ 1.9.1へのアップグレードがリリースされていましたので、その適用を実施しています。

aurora-t2-meduim-06

aurora-t2-meduim-07

  • アップグレードは2分で完了しました。

aurora-t2-meduim-12

  • aurora_version 確認
mysql> select @@aurora_version;
+------------------+
| @@aurora_version |
+------------------+
| 1.9.1            |
+------------------+

インスタンスの変更

  • Auroraインスタンスの変更を実施します

aurora-t2-meduim-08

  • インスタンスタイプとして「db.t2.medium」を指定します

aurora-t2-meduim-09-2

  • 即時にインスタンスタイプを変更するため、オプションをチェックします。
  • 即時変更指定をしない場合、次回メンテナンスウィンドウ時間に変更が行われます。

aurora-t2-meduim-10

  • 確認画面

aurora-t2-meduim-11

変更ログ

  • 「r3」→「t2」への変更、今回は14分を要しました

aurora-t2-meduim-13

モニタ情報

  • 「t2」変更後、CPUクレジット情報のCloudwatchメトリックが確認可能となります。
  • CPUクレジットが枯渇するとCPU性能がベースラインまで大幅に抑制されますので、ご注意ください。

aurora-t2-meduim-14

##まとめ

DB接続などAurora用に最適化されたアプリケーション環境では、 開発、検証用として、本番システムと干渉の心配が無い別DBを用意した場合、 そのAWS利用費が割高になる事がありました。

DBのCPU、メモリ性能を必要としない開発用途であれば、 「db.t2.medium」を採用する事で、「db.r3.large」から大きくコストを抑える事が可能になります。 フェイルオーバの検証や、リードレプリカの負荷分散の確認など、よりAuroraを気軽に試せる様になりました。

尚、DBとして「t2」のインスタンスを利用される場合、そのCPUクレジット残量の枯渇は 大きな性能影響を及ぼす場合がありますので、くれぐれもご注意ください。

参考情報

RDS費用

  • 東京リージョンのRDS、1インスタンスの時間単価(2016年11月現在)より、月額(730時間)料金を計算

RDS(Aurora)

インスタンスタイプ メモリ 1時間単価($) 1ヶ月価格($)
db.t2.medium 4 0.125 91.25
db.r3.large 15 0.35 255.5
db.r3.xlarge 30.5 0.7 511
db.r3.2xlarge 61 1.4 1022
db.r3.4xlarge 122 2.8 2044
db.r3.8xlarge 244 5.6 4088

RDS(MySQL)

インスタンスタイプ メモリ 1時間単価($) 1ヶ月価格($)
db.t2.micro 1 0.026 18.98
db.t2.small 2 0.052 37.96
db.t2.medium 4 0.104 75.92
db.t2.large 8 0.418 305.14