RDSでスナップショット取得時のサービスへの影響ースナップショット取得時にサービスへ影響はあるのか

sayu — Fri, 10 Mar 2023 13:47:36 +0000

RDSでスナップショット取得時のサービスへの影響を調べてみました。

本記事で、以下のことがわかります！

本記事に記載すること

RDSでスナップショット取得時にサービスへの影響はあるのか
サービス無停止で、かつ、サービスに影響なくスナップショット取得できるのか

シングル AZ DB インスタンスの DB スナップショットの作成 - Amazon Relational Database Service

バックアップする DB インスタンスを識別することにより DB スナップショットを作成し、その DB スナップショットに名前を付けます。

上記、公式情報から「Single-AZインスタンス」と「マルチ AZ インスタンス」で挙動が異なるようです。

早速結論から記載していきます。

RDSでスナップショット取得時にサービスへの影響があるかの結論

「Single-AZインスタンス」と「マルチ AZ インスタンス」で挙動が異なり、以下の結論となります。

結論

Single-AZインスタンス：サービスへ若干影響あり
マルチ AZ インスタンス：サービスへ影響なし、ただしSQL Serverの場合は影響あり

次に、Single-AZインスタンスのスナップショット取得時の挙動を書いていきます。

Single-AZインスタンスのスナップショット取得時の挙動

DB スナップショットを作成するとI/O が短時間中断(数秒から数分)する
- 中断時間はDBインスタンスのサイズやクラスによって異なる

数秒から数分、I/Oできない影響があるということですね。

次は、マルチ AZ インスタンスについてです！

マルチ AZインスタンスのスナップショット取得時の挙動

MariaDB、MySQL、Oracle、PostgreSQL の場合
- バックアップはスタンバイから取得されるため、プライマリで I/O アクティビティは中断しない
- ただし、SQL Server 場合は、 I/O アクティビティが一時中断する

MariaDB、MySQL、Oracle、PostgreSQLでは影響なし

SQL Server 場合は、 Single-AZインスタンスと同様、I/Oできない影響があるということです！

まとめ

RDSでスナップショット取得時のサービスへの影響について、マルチAZの場合、SQL Serverを除いて影響なしなので、安心してスナップショットをとって大丈夫。サービスに影響を出さずにバックアップを取れる。

シングルAZとSQL Serverの場合は、サービス影響は多少ある(数秒から数分、I/Oできない影響がある)ため、要注意。どのくらいの時間影響が出るかについて、RDSスペックとDBサイズによります！

RDSまたはAuroraのMySQL メモリ使用率が高くなる原因と対処法

sayu — Fri, 24 Feb 2023 07:05:47 +0000

RDSまたはAuroraのMySQLのメモリ使用率が高い場合の原因と対処法について書いていきます。

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

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

から安心で良いです。

でも、監視は必要です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

メモリについてまとめ

メモリの 80% から 90% がデフォルトのパラメータで利用されるように設定されている
→メモリ使用率が90%以下の場合は、効率良く動いている状態なので、気にしなくて大丈夫
→メモリの主な用途はバッファプール

AWSに限らず一般的に、80%程度のメモリーがバッファプールに割り当てられる
→メモリ使用量は、バッファプールに割り当てられている値まで増加し、その後は増えない(再利用される)という挙動が基本となる

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

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

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

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

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

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

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

2つの対応方法

クエリーチューニングの実施
DBインスタンスのスペックをあげる

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

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

まとめ

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

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

RDS | さゆフィクション