非 Aurora な RDS から Aurora へ移行する時に考えること全部盛り
Japan AWS Jr. Champions Advent Calendar 23日目の投稿です！クリスマスイブイブですね。
今回は、Aurora でない RDS で稼働している DB を Aurora へ移行することを検討してみます。
現在の データベース
具体的な例があった方が分かりやすいので、移行対象の DB の情報を仮定しておきます。
- データベースの情報
- 利用状況
- CPU利用量：余裕あり
- ディスク利用量：余裕あり
- メモリ利用量：2GiB弱程度で安定推移
- システム稼働：時間帯や日による変化はなく、一定した稼働
RDS周りのサービス
具体的な話に入る前に、今日出てくるサービスの全体像を先にまとめておきます。
RDSには Aurora と 非Aurora の別があり、
さらに Aurora には、固定のスペックで稼働するプロビジョンドと、アプリケーションニーズに応じて動的にスペックが変わるサーバレスの別があり、
さらにプロビジョンドには、一般的な課金体系であるオンデマンドと、一定期間の利用を約束することで割引が受けられるリザーブドの別があり、
サーバレスには v1 と v2 の別があります。
この中から、今回のワークロードに適切なものを選択していきます。
Aurora と 非Aurora な RDS は何が違うの？
Aurora への移行の前段で、非 Aurora な RDS と Aurora はそもそも何が違うの？という方は、よくまとまっている記事があるので、こちらをご覧ください！ dev.classmethod.jp dev.classmethod.jp
Aurora の方が料金が高くなるケースもありますが、Aurora にしかない機能が多くあったり、パフォーマンスの優秀さから、Aurora への移行を検討するケースも多いのではないでしょうか。
Aurora を選択する場合の最初の分岐はプロビジョンド or サーバレスです。機能と料金の両面から比較していきます。
Aurora Provisioned vs Aurora Serverless
機能面
上に記載の通り、Auroraサーバレスには、v1 と v2 がありますが、公式docに以下の記載があるように、基本的には v2 はほとんど Aurora プロビジョンドと同等の機能を利用でき、v1 よりパワーアップしているので、v1 は検討の対象から除外します。
Greater feature parity with provisioned – You can use many Aurora features with Aurora Serverless v2 that aren't available for Aurora Serverless v1.
サーバレス v2 とプロビジョンドの機能の差を見ると、公式 doc に以下の記載があります。
Aurora プロビジョン済み DB インスタンスの以下の機能は、現在 Amazon Aurora Serverless v2 では使用できません。
・データベースアクティビティストリーム (DAS)。
・Aurora PostgreSQL のクラスターキャッシュ管理。apg_ccm_enabled 設定パラメータは Aurora Serverless v2 DB インスタンスには適用されません。
前者のデータベースアクティビティストリーム（DAS）は、DBネイティブの仕組みではなく、AWSの仕組みで監査ログを取得する機能です。（もっと深めたい方はこちら）
今回移行対象の DB は該当の要件はないのと、この機能が利用できるインスタンスタイプも限られているため（参考）、サーバレス利用にあたり問題はなさそうです。
後者のクラスターキャッシュ管理は、フェイルオーバーした際、旧ライターインスタンスが利用していたキャッシュを、昇格した新ライターインスタンスも継続利用できるようにすることで、フェイルオーバー時のパフォーマンス低下を防ぐ機能です。（もっと深めたい方はこちら）
こちらは PostgreSQL の機能なので、今回の検討では問題なさそうです。
サーバレス v2 を選択しても、機能面で致命的に不足している点はなさそうなので、次に料金面の比較をしてみます。
料金面
最適なスペックの選択
最初に、どのスペックで試算すべきかを考えます。
プロビジョンドの場合
前述の通り、現在は db.t3.medium で稼働していますが、その選択をしたのも数年前なので、プロビジョンドにおいても、あらためて最適なインスタンスタイプを考え直します。
おさらいですが、現在の DB は、CPU / ディスクは利用量に余裕あり、メモリ利用量が 2GiB 弱程度で安定して推移しているという前提でした。
メモリを基準に考えると、プロビジョンドのインスタンスタイプを選択する場合、以下あたりが候補になりそうです。（インスタンスタイプの一覧はこちら）
| インスタンスクラス | CPU(vCPU) | メモリ(GiB) |
|---|---|---|
| db.t2.small | 1 | 2 |
| db.t2.medium | 2 | 4 |
| db.t3.small | 2 | 2 |
| db.t3.medium | 2 | 4 |
| db.t4g.medium | 2 | 4 |
さすがにメモリが 2GiB のものをプロビジョンドで選択すると、すぐに拡張を考える必要がありそうなので、最低でも 4GiB はあった方が良さそうです。
t2 or t3 のような世代の選択については、以下の通り、できるだけ最新世代を選びます。
（出典：https://pages.awscloud.com/rs/112-TZM-766/images/C2-07.pdf）
※ T系を選択する場合は、世代によってバーストの仕様にも違いあるのでその点も注意が必要です。（詳細はこちら）
ここまで考慮すると、 db.t4g.medium が良さそうですね。
CPU が Graviton2 になる点がこれまでとは変わる点ですが、RDSの場合は、大きな影響はなさそうです。
（出典：https://pages.awscloud.com/rs/112-TZM-766/images/20210603-Instance_Choice_and_Graviton2.pdf）
サーバレスの場合
サーバレスには固定されたスペックがないため、ACU (Aurora Capacity Unit) という単位に対して課金されます。 1ACU = メモリ 2GiBで、設定可能な最小値は 0.5 ACU です。（ACU の詳細はこちら）
現状、メモリは 2GiB で安定推移しているので、今回は 1ACU で試算します。
プロビジョンドの場合は、拡張の負荷を考えて 4GiB としましたが、サーバレスの場合は勝手に拡張してくれるので、検討の負荷が減って良いですね。
試算
プロビジョンドとサーバレスv2のそれぞれの場合の1か月間の料金を試算してみます。
東京リージョンでの単価は以下のようになっています。前述の通り、プロビジョンドの単価は db.t4g.medium を前提にしています。
（Aurora の料金詳細はこちら）
ここでは基本項目だけ取り上げて試算しますが、その他にも金額に響く細かな要素はあるので、詳細は AWS Pricing Calucalator を利用して計算してみましょう。
- 試算前提
- プロビジョンド
- データベースインスタンス：USD 0.113 × 24時間 × 30日 = USD 81.36
- ストレージ：USD 0.12 × 50GB = USD 6.00
- IO：USD 0.24
- 合計：USD 87.60
- サーバレス v2
- データベースインスタンス：USD 0.2 × 24時間 × 30日 = USD 144.00
- ストレージ：同上
- IO：同上
- 合計：USD 150.24
サーバレス v2 の方が、データベースインスタンスの金額が2倍弱高いので、こう見るとやっぱり高いですね。。
サーバレスの良いところは、自動的に拡張するところなので、どのくらいキャパシティが必要か予測がつかないとか、管理対象が多く全てのキャパシティ管理は負荷が高いとか、そんなワークロードに向いていそうです。
Aurora をもっと安く使いたい
ここまでの検討で、Aurora プロビジョンドの db.t4g.medium を利用するのが濃厚です。
すると、次の検討観点はインスタンスをオンデマンドとするか、リザーブドとするかです。
観点は利用料金なので、Aurora をより安く使う方法を検討してみます。
リザーブドインスタンスを利用する
これは Aurora に限った話ではありませんが、一定期間の利用を確約する代わりに、インスタンスを安く利用できます。
移行先の db.t4g.medium のインスタンスについて、非 Aurora な RDS (オンデマンド)、Aurora (オンデマンド)、Aurora (リザーブド)で単価を比較してみます。リザーブドインスタンスの単価は、1年利用確約/前払い無しで算出しています。
データベースインスタンスの料金が、リザーブドではオンデマンドの85%程度なので、USD 75 / 月 程度まで削減できそうです。
前述の通り、現在は非 Aurora のオンデマンドインスタンスを利用していますが、それと比較しても少し安めに使えそうですね。
本当に MultiAZ が必要か検討する
前述の通り、現在の RDS は、MultiAZ 構成です。
上で算出した金額は、インスタンスが1つであることを前提としているため、実際は倍程度の金額がかかります。
RDS と Aurora は、アーキテクチャが大きく異なるため、それによって、SingleAZ構成としたときのリスクに多少の違いがあります。
（出典：https://aws.amazon.com/jp/blogs/news/webinar-bb-amazon-aurora-mysql-2019/]）
まず、RDS は公式に記載の通り、ストレージには EBS が利用されています。
Amazon RDS ストレージのハードウェア構成はどのようなものですか?
Amazon RDS は、データベースとログの格納に EBS ボリュームを使用します。
EBS は AZ に紐づいており、AZ 内の HW にレプリケートされています。
（出典：https://www.slideshare.net/AmazonWebServicesJapan/20190320-aws-black-belt-online-seminar-amazon-ebs]）
一方で Aurora は、インスタンス（コンピュートノード）とストレージは分離されており、インスタンスは 1AZ で構成されていても、データは 3AZ にまたがる 6つのノードに書き込まれます。
さらに、書き込みは 4/6、読み込みは 3/6 のノードが生き残っていれば、データベースとして問題なく稼働し、サービス影響が出ることはありません。
（出典：https://www.slideshare.net/AmazonWebServicesJapan/20190424-aws-black-belt-online-seminar-amazon-aurora-mysql）
つまり、RDS の場合は 1つの AZ のストレージに障害が起きたらサービス稼働に影響が出ますが、Auroraの場合は、残りの2つの AZ に存在するデータノードが無事ならサービス維持が可能です。
また、インスタンスに障害が起きた場合は、そのインスタンスが存在する同じ AZ に、10分未満で自動的に再作成されます。
DB クラスターに Aurora レプリカが含まれていない場合、障害イベントの発生時にプライマリインスタンスが同じ AZ に再作成されます。（中略）新しいプライマリインスタンスが再作成されると、サービスが回復します。これは、通常は 10 分未満で行われます。
しかし、1つの AZ 内の全てのストレージに障害が起きるケースは、大抵 AZ レベルでの障害なんじゃないかと思いますが、AZ レベルで障害が起きてしまった場合は結局手動で復旧するしかなく、サービス維持は不可能です。
プロビジョン済みまたは Aurora Serverless v2 クラスターに 1 つの DB インスタンスしか含まれていない場合、またはプライマリインスタンスとすべてのリーダーインスタンスが同じ AZ にある場合は、別の AZ に 1 つまたは複数の新しい DB インスタンスを手動で作成する必要があります。
というわけで、AZ 障害の場合も継続的にサービス提供可能とする場合は、Aurora であっても MultiAZ とするしかありませんが、可用性要件が比較的低いシステムの場合は、SingleAZ 構成とすることも検討してみてください。
最後に
RDS から Aurora への移行を検討する際の観点全部盛りでお届けしたつもりです。
結構な文字数になりましたがどなたかの参考になれば幸いです！
