概要

少し前に、Performance Insights で推奨事項を生成してくれる機能がリリースされました。

Amazon RDS (Relational Database Service) Performance Insights では、推奨事項を生成して、データベースのパフォーマンスと可用性に関する差し迫った問題が深刻になる前にお客様に通知できるようになりました。
Amazon RDS Performance Insights、メトリクスが推奨しきい値を超えた場合に推奨事項を生成

当時、検証環境で負荷を与えて、試行錯誤してみたのですが、なかなか推奨事項が出ず検証を断念しました。
そこで、実環境に導入してしばらく放置していたら推奨事項が生成されていました。
本記事は、その内容を見てみた記録です。

RDS の推奨事項の詳細については以下をご覧ください。

Amazon RDS Performance Insights を有料利用枠にすると熱い | NHN テコラス Tech Blog | AWS、機械学習、IoT などの技術ブログ
Amazon RDS で推奨事項を表示する機能がリリースされました | NHN テコラス Tech Blog | AWS、機械学習、IoT などの技術ブログ

生成された推奨事項を見てみる

2 つ推奨事項が生成されていましたが、内容としては同じで、検知されたタイミングが異なっていました。

推奨事項の詳細は以下の 3 つで構成されていました。

• レコメンデーションの概要
• メトリクス
• 分析とレコメンデーション

それぞれ、セクションに分けて詳細を見ていきます。

なお、簡単ではありますがドキュメントに手順がまとまっているためこちらも合わせてご覧ください。
Performance Insights のプロアクティブな推奨事項の表示 – Amazon Relational Database Service

ちなみに、推奨事項の内容が DB エンジンごとによって変わりそうなので本環境について簡単に記載しておきます。

• エンジンバージョン : 5.7.mysql_aurora.2.11.2
• インスタンスクラス : db.r6g.xlarge

レコメンデーションの概要

推奨事項の基本情報が記載されています。
「検知」項目にて推奨事項の詳細が簡潔に書かれているため、内容を把握するためにはとてもわかり易いです。

検出された問題、推奨事項と問題のステータス、問題の開始時刻と終了時刻、推奨事項の変更時刻、エンジン タイプ。
Performance Insights のプロアクティブな推奨事項の表示 – Amazon Relational Database Service

今回の場合は、以下理由により推奨事項が生成されていました。

01/29/2024 22:12:00 以降、最近のディスク上の一時テーブルの使用量が大幅に増加しました (最大 54.46 %)。データベースはディスク上で 1 秒あたり最大 3 個の一時テーブルを作成しているため、パフォーマンスに影響を及ぼす可能性があります。このインサイトは、ディスク上の一時テーブルの割合と、1 秒あたりに作成されるディスク上の一時テーブルのレートの両方がしきい値を超えたために表示されます。

メトリクス

全部で 3 つのメトリクスに対して分析結果が提示されています。

• Temporary Tables On Disk (1 秒あたりの一時テーブル数 単位)
• Percentage of the temporary tables created that use disk (% 単位)
• Total Created Temporary Tables (1 秒あたりの一時テーブル数 単位)

全体を映すと分かりづらいので、それぞれ詳細を見ていきます。

Temporary Tables On Disk (1 秒あたりの一時テーブル数 単位)

ディスク上に、一時テーブルの使用されたテーブル数で閾値を超えていたようです。

以下、メトリクスの説明。

1 秒あたりにディスクを使用するデータベースで作成された一時テーブルの数。RDS はメトリクス集計を監視します。
詳細については、以下を参照してください
MySQL リファレンスマニュアルの MySQL での内部一時テーブルの使用

他にも閾値を超えているタイミングが見受けられますが、検知された判定になっている時間は「22:12 ~ 22:39」までのようです。
どうやら、ただ単に閾値を超えただけではなく一定時間継続されることが条件みたいですね。

Percentage of the temporary tables created that use disk (% 単位)

「Created_tmp_disk_tables / Created_tmp_tables」の割合に対するメトリクスで評価されているようです。

• Created_tmp_disk_tables : 内部一時テーブルがディスク上に作成された回数
• Created_tmp_tables : 内部一時テーブルがメモリーまたはディスクに作成された回数

以下、メトリクスの説明。

データベースで作成された一時テーブルの総数に対するディスク上のデータベース作成一時テーブルの割合。RDS はメトリクス集計を監視します。
詳細については、以下を参照してください
MySQL リファレンスマニュアルの MySQL での内部一時テーブルの使用

こちらの改善には、 AWS ドキュメントが提供されていました。
データベースはディスク上にテンポラリテーブルを作成している – Amazon Aurora

Total Created Temporary Tables (1 秒あたりの一時テーブル数 単位)

Created_tmp_tablesを元に生成された分析のようです。

以下、メトリクスの説明。

データベースで作成された一時テーブルの 1 秒あたりの総数。RDS はメトリクス集計を監視します。

これは他のメトリクスに比べて、「ピーク値」や「しきい値の制限」の情報が欠けています。
他と関連があるメトリクスなので表示されたが、異常値ではなかったのでそのままとなった感じですかね。

分析とレコメンデーション

最後のセクションです。
先程までの結果を踏まえて、どうすればいいかのアクションが記載されています。

以下、レコメンデーション

レコメンデーション
使用状況に基づいて、次のことをお勧めします:

メモリパラメータを確認し、クエリを調整してください。例:
MySQL 8.0 で TempTable ストレージエンジンを使用してください。
データベースパラメータ tmp_table_size と max_heap_table_size を調整してください。
必要な列のみを選択し、BLOB と TEXT 列を使用しないようにします。
ソートとグループ化に関係する列のインデックスを作成してください。
クエリによって返されるデータを削減してください。sys.statements_with_temp_table をクエリして調査してください。
トラブルシューティングに関するドキュメントを表示

これが推奨される理由
一時データがメモリに収まらない場合、データベースはディスク上の一時テーブルを使用します。これらのテーブルにより、パフォーマンスが低下し、スケジュールされたアップグレードの時間が長くなり、IOPS レートが増加する可能性があります。

15 分間で、データベースは 1 秒あたり 3 個以上の一時テーブルを作成し、すべての一時テーブルの 50% 超がディスクを使用しました。

かなり詳しく記載されていますね。
この場合すぐできることといえば、パラメーターチューニングになるのかなと思ってます。

まとめ

DB エンジンのポイントを押さえて推奨事項が提示される機能なためかなり便利な機能だなと思いました。
今までの Performance Insights は、こういったメトリクスを見比べる作業はユーザー側で行っていたのですがすごく時間とスキルが要求されていました。
こういった作業が自動的に行われ改善まで提案してくれるのはかなり良いですね。

有料化してもそこまで高くないため有料化しておくのが良いのかなと思いました。

ただ、推奨事項が生成されたことを通知したいのですが、軽く調べた感じなさそうなのでできるようになればいいなと思ってます。