具体的には以下のことについて記載していきます。

• Aurora Serverless v2とは
• 用途
• 注意点

まずはAurora Serverless v2とは？について書いていきます。

Aurora Serverless v2とは

Aurora Serverless v2は、オンデマンドでAuto Scaling設定できるデータベースです。

以下の点について、具体的に記載していきます。

性能

ACUという単位で管理されることになります。

1ACUは、約2GB のメモリと、対応する CPU、ネットワークの組み合わせとなります。

ACUは最大、128 ACU を指定することができます。

ACUの最大はどれくらいのインスタンスかというと、メモリは128 ACU × 2GB = 256GBとなります。DBインスタンスクラスタイプがr6gの場合、以下の公式ページから、r6gかつメモリ：256GBのインスタンスを探して、db.r6g.8xlargeが最大ということになります。

Aurora DB インスタンスクラス - Amazon Aurora

DB インスタンスクラスによって、 Amazon Aurora DB インスタンスの計算とメモリの容量を決定します。

docs.aws.amazon.com

スケーリング

Aurora Serverless v2は以下に記載されている通り、スケーリングが早く、アクセスのスパイクにも耐えたれそうです。(実際に耐えられるかどうかは、システムがDBへどれくらいの負荷をかけるか次第になるので、要検証ですね)

Amazon Aurora Serverless v2 は、ほんの一瞬で数十万ものトランザクションにスケールできます。スケールに応じて、容量をきめ細かい増分で調整し、アプリケーションが必要とする適切な量のデータベースリソースを提供します。

Amazon Aurora Serverless | AWS

Amazon Aurora Serverless では、管理する DB インスタンスはありません。データベースは、アプリケーションニーズに応じて、容量を自動的に起動、停止、および拡大または縮小します。

aws.amazon.com

また、Aurora Serverless v2 では、以下のようなケースでもスケーリング可能なようです。

• データベースの接続中
• SQL トランザクション処理中
• テーブルロック中
• 一時テーブルの使用中

可用性

Aurora Serverless v2は、以下の特徴を持ち、高可用性を確立しています。

• マルチ AZ 対応
• 自動的フェイルオーバー

次は、用途について記載します。

用途

• 変化の大きいアクセスやアクセス量が予測できない時
  アクセスが多い時と少ない時の落差が大きい場合や、アクセス量が予測できない場合、データベースは負荷に応じて、自動的にスケーリングしてくれます。
• 開発時のAuroraの代替
  本番は、Auroraを使用している場合でも、開発環境は、Aurora Serverlessを利用するとコスト削減につながることあります。

次は、注意点です。

 

注意点

以下に注意点を記載します。

• MySQLの場合、Aurora MySQL バージョン 3のみ対応しています
  • MySQLのバージョン8系しか対応していないということになります
• ACUは最大、128 ACU(db.r6g.8xlargeくらい)が最大となっています
  • 最大が決まっているため、要注意です
• Aurora Serverless v1 では Data API が使えましたが、v2ではData APIは使えません。
• 費用の予測がしにくい
  • 最大ACUから最大の費用は算出することができますが、実際にどれくらいの費用となるかについては予測がしづらいです

まとめ

v1では、SQL実行中はスケーリングできないなどの制限がありましたが、v2では改善され用途が広がりそうですね。素晴らしーい！

まず、各バージョンのサポート期限は以下のようになっています。

Amazon RDS での MySQL のバージョン - Amazon Relational Database Service

Amazon RDS for MySQL のバージョンについて学びます。

docs.aws.amazon.com

Amazon Aurora バージョン - Amazon Aurora

Amazon Aurora のバージョンについて説明します。バージョンには、それぞれのバージョン番号、リリースサイクル、バージョン廃止のタイムラインなどがあります。

docs.aws.amazon.com

MySQL5.7のサポート期限は、もうすぐそこまで来ています！

では、バージョンアップについて、記載していきます。

公式情報の参考ページは以下になります。

メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれる場合があります。

MySQL DB エンジンのアップグレード - Amazon Relational Database Service

MySQL を実行する Amazon RDS DB インスタンスをアップグレードします。

docs.aws.amazon.com

マイナーバージョンのアップグレードに含まれるのは、既存のアプリケーションとの下位互換性がある変更のみです。

MySQL DB エンジンのアップグレード - Amazon Relational Database Service

MySQL を実行する Amazon RDS DB インスタンスをアップグレードします。

docs.aws.amazon.com

バージョンアップにはメジャーバージョンアップとマイナーバージョンアップがあるということです。

まずはメジャーバージョンアップについて記載します。

メジャーバージョンアップ

以下のいづれかのバージョンアップを指します。

• MySQL 5.6 から MySQL 5.7 へ
• MySQL 5.7 から MySQL 8.0 へ

公式情報に記載の通り、メジャーバージョンアップには非互換性な点があります。

メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれる場合があります。

MySQL DB エンジンのアップグレード - Amazon Relational Database Service

MySQL を実行する Amazon RDS DB インスタンスをアップグレードします。

docs.aws.amazon.com

よく検証してバージョンアップする必要があります。

通常のMySQLのバージョンアップと同様にリリースノートの調査や動作検証を行ってから、バージョンアップします。

また性能面でも

• MySQL 5.6 から MySQL 5.7 へのバージョンアップ

では、性能が劣化するケースがあるため、注意が必要です。

また、MySQL 8.0ではクエリキャッシュ機能がなくなるので、この点も要注意です。

MySQLで2回目のSELECTで速度が向上するクエリキャッシュについて

MySQLで同じSELECT文の2回目以降の読み取りの速度が向上するクエリキャッシュですが、MySQL 8.0ではキャッシュしませんということについて書いていきます。 MySQL5.7までは、デフォルトでONになっていたクエリキャッシュですが、MySQL8.0では使えない機能(削除された機能)となります。

it.kensan.net

2023.05.02

また、インスタンスクラスによって、選択可能なAurora MySQLバージョンが異なるので注意が必要です。

例えば、インスタンスクラスがdb.t3.smallの場合、MySQL8.0系(3.01.0 以降)はサポートされていません。db.t3.smallでは、現状、MySQL5.7系しか選択不可で、MySQL8.0系(3.01.0 以降)にアップデートできないということになります。

db.t3.smallを使用していて、MySQL8.0にアップデートしたい場合は、インスタンスクラスをdb.t3.smallから変更する必要があるということです。

DBインスタンスクラスと利用可能なAurora MySQL バージョンの対応表は以下の公式ページで確認できます。

Aurora DB インスタンスクラス - Amazon Aurora

DB インスタンスクラスによって、 Amazon Aurora DB インスタンスの計算とメモリの容量を決定します。

docs.aws.amazon.com

次にマイナーバージョンアップについてです。

マイナーバージョンアップ

公式情報に記載の通り、マイナーバージョンのアップグレードに含まれるのは、下位互換性がある変更のみです。

マイナーバージョンのアップグレードに含まれるのは、既存のアプリケーションとの下位互換性がある変更のみです。

MySQL DB エンジンのアップグレード - Amazon Relational Database Service

MySQL を実行する Amazon RDS DB インスタンスをアップグレードします。

docs.aws.amazon.com

経験上、特に検証なしでバージョンアップして問題なしです。

リリースノートを念の為、確認しておくとより安心かと思います。

結論：MySQLバージョンはAuroraのメジャーバージョンによって決まります。

AuroraバージョンとMySQLバージョン関係は以下のようになっています。

AuroraのバージョンからMySQLのバージョンが分かるので、まずは、Auroraのバージョンの確認方法から見ていきます。

Aurora バージョンの確認方法

以下のいずれかのSQL文を実行することで確認できます

select aurora_version();

select @@aurora_version;

実行すると以下のような結果が返ってきます。

2.08.1

上記の結果は「<major version>.<minor version>.<patch version>」を示しています。

• major version:2
• minor version:8
• patch version:1

と読み取ることができます。

Auroraのバージョンが調べられるようになったかと思いますので、

次に調べたAuroraのバージョンからMySQLのバージョンを調べます。

AuroraバージョンとMySQLバージョン関係

AuroraバージョンとMySQLバージョン関係は以下のようになっていますので、Auroraバージョンが調べられれば、すぐにMySQLのバージョンが分かるかと思います。

• Auroraメジャーバージョン１：MySQL 5.6
• Auroraメジャーバージョン２：MySQL 5.7
• Auroraメジャーバージョン３：MySQL 8.0

以下の公式記事を参考にしています。

Amazon Aurora MySQL 5.6のサポート終了のお知らせ | Amazon Web Services

Aurora MySQL 5.6 (Amazon Aurora MySQL Version 1) のメジャーバ

aws.amazon.com

注意点

Auroraメジャーバージョン１(MySQL 5.6)はサポートが切れているため、ご注意ください。

Auroraバージョンの詳細を知りたい

Aurora MySQLバージョン場合は以下の公式のリリースノートを確認しましょ！

Amazon Aurora MySQL 互換エディションのリリースノート - Amazon Aurora

Amazon Aurora MySQL 互換エディションのリリースノートをご案内します。

docs.aws.amazon.com

結論としては、RDSとAuroraで同じで、

メモリ使用率が高い＝効率良く動いている

から安心で良いです。

でも、監視は必要です。

ちなみにメモリ使用率をAWSマネージメントコンソール画面から確認できないので、CloudWatchのメトリクス「FreeableMemory(メモリ空き容量)」から確認することになります。

まず、RDSやAuroraのメモリ使用率が高くなる理由について書いていきます。

RDS/Auroraのメモリ使用率が高くなる理由

AWS公式に以下の記載があります。

Amazon RDS for MySQL で確保できるメモリが少ない問題をトラブルシューティングする

Amazon Relational Database Service (Amazon RDS) または MySQL インスタンスを実行しています。使用可能なメモリが少ない、データベースのメモリが不足している、またはメモリが少ないためにアプリケーションでレイテンシー問題が発生しています。メモリ使用率の原因を特定するにはど...

repost.aws

Amazon RDS for MySQL では、インスタンスで利用可能なメモリの 80% から 90% がデフォルトのパラメータで割り当てられます。この割り当てはパフォーマンスには最適ですが、より多くのメモリを使用するパラメータを設定する場合は、他のパラメータを変更してより少ないメモリを使用するように補正してください。

パフォーマンスの最適化のために、メモリの 80% から 90% が利用されるように設定されているようです。

メモリ使用率が90%以下の場合は、効率良く動いている状態なので、気にしなくて大丈夫ということです。

ちなみにAuroraのパラメータは効率良く動くように設定されているので、設定変更しないことがベストプラクティスです。

次にメモリの用途について書いていきます！

メモリの主な用途はバッファプールです。バッファプールの解説は以下の通りです。

バッファプールは、InnoDB がアクセス時にテーブルおよびインデックスデータをキャッシュするメインメモリー内の領域です。 バッファープールを使用すると、頻繁に使用されるデータをメモリーから直接処理できるため、処理速度が向上します。 専用サーバーでは、多くの場合、最大 80% の物理メモリーがバッファプールに割り当てられます。

MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.5.1 バッファプール

dev.mysql.com

バッファプールはLRUアルゴリズムというもので、管理されているようです。

バッファプールは、最低使用頻度 (LRU) アルゴリズムのバリエーションを使用してリストとして管理されます。 バッファプールに新しいページを追加するための領域が必要な場合は、最も最近使用されていないページが削除され、新しいページがリストの中央に追加されます。 このミッドポイント挿入戦略はリストを 2 つのサブリストとして扱います。

「専用サーバーでは、多くの場合、最大 80% の物理メモリーがバッファプールに割り当てられます。 」とMySQLの公式に記載されていることから、RDSやAuroraに限らず、MySQLでは、メモリ使用率が高くても問題ないということになります。

また、「バッファプールに新しいページを追加するための領域が必要な場合は、最も最近使用されていないページが削除され、新しいページがリストの中央に追加されます。」と記載されています。

よって、MySQLでのメモリは以下のように使用され、バッファプールに割り当てられている値まで増加し、その後は増えないという挙動が基本となります。(減ることもない)

• メモリは、バッファプールに割り当てられている値まで増加する
  • その後は、新しい情報をメモリに書き込む際は、古い情報を削除してから書き込みがされる
    • 古い情報を削除して新しい情報を書き込むという再利用がされるため、バッファプールに割り当てられている値以上にメモリを消費することはない

次に監視について書いていきます。

メモリ使用率の監視は必要

AWS公式より、監視は必要です。95%を超えたらアラートをあげるようにしておくのが、ベストプラクティスのようです。

• FreeableMemory メトリクスに CloudWatch アラームを設定して、利用可能なメモリが 95% に到達したときに通知を受け取るようにします。インスタンスメモリを 5% 以上空けておくのがベストプラクティスです。

Amazon RDS for MySQL で確保できるメモリが少ない問題をトラブルシューティングする

Amazon Relational Database Service (Amazon RDS) または MySQL インスタンスを実行しています。使用可能なメモリが少ない、データベースのメモリが不足している、またはメモリが少ないためにアプリケーションでレイテンシー問題が発生しています。メモリ使用率の原因を特定するにはど...

repost.aws

監視アラートが上がったらどうするか

基本的に以下のいずれかの対応となります。

時間的余裕がない場合は、「DBインスタンスのスペックをあげる」の一択ですね。

ちなみにメモリ使用率を下げるためにパラメータ(max_connectionsなど)を変更することはお勧めしません。パラメータはパフォーマンス良く動くよう設定されているためです。

まとめ

RDS/Aurora MySQLのメモリ使用率について、みてきました。

正しく理解し対応していきましょ！