【検証】Aurora PostgreSQLの実行計画のキャプチャを試してみた

はじめに

こんにちは！ディップ株式会社、データベースエンジニアの伊藤大地と申します。弊社でははたらこねっとというサービスでPostgreSQL on EC2からAurora PostgreSQLへ移行を進めております。移行を進める中でAuroraの情報をキャッチアップする機会が増えており、先日Amazon CloudWatch Database Insights(以下：Database Insights)からAurora PostgreSQLの実行計画を長期的に保存して確認できるようになったという情報を見ました。

CloudWatch が Aurora PostgreSQL の実行プランのキャプチャを提供

普段サービスが稼働している中で突然DBの負荷が高くなることがあるかと思いますが、原因を特定しようと当初遅かったSQLを後から実行してみると問題なかったりすることがあります。Database Insightsを使っていれば負荷が高まった状況での実行計画をマネジメントコンソール上から確認することができるようになるのでこれは嬉しい機能だと思い試してみました。

誰に向けた記事なのか

Aurora PostgreSQLを利用している方
実行計画と睨めっこする方
少しでも楽をしたい方 ← 大事

概要

今回はDatabase Insightsで利用できるDB負荷分析内のプラン(実行計画)に的を絞ってまとめていきます。 Database Insightsを利用することでDBに負荷をかけている時間帯を特定し、どのSQLが要因なのかを把握、SQLの何が負荷要因になっているのかもしくは負荷の要因がSQL以外なのかを特定できると考えています。

料金はかかるの？

無料枠が設けられています。

データベース負荷メトリクスの 7 日間のパフォーマンスデータ履歴 (ローリング)

参考: Amazon CloudWatch 料金表)

この後に説明しますが、7日間を無料で利用できるのはDatabase Insightsの標準モードであることが条件です。実行計画を見るにはアドバンスモードでの利用が必要なため必ず課金対象となります。

具体的な料金例が公式ドキュメントに記載されていたので一部抜粋した内容が以下の通り

合計 vCPU 数 = (db.r5.xlarge の vCPU 数 × 台数) = (4 × 1) = 4
1 か月あたりの料金 = (合計 vCPU 使用量 × Database Insights のアドバンスモードの 1 時間あたりの vCPU 料金 × その月の時間数) = 4 × 0.0125 × 720 = 108 USD
※ この機能の使用量は時間単位で計測され、端数は切り上げられます。

上記はあくまでもDatabase Insightsの料金なので別途データベースログの料金がかかります。

Database Insightsは何ができるのか？

Database Insightsには2つのモードがあります（スタンダード・アドバンスモード）提供される機能が違うので下記はドキュメントを参考にまとめました。利用にはパフォーマンスインサイトを有効にするとデフォルトではスタンダードモードが使えるようになります。

機能	スタンダードモード	アドバンスモード
DB Load の上位の寄与要因をディメンション別で分析する	◯	◯
最大 7 日間の保持期間を持つデータベースメトリクスにクエリ、グラフ、アラーム設定をする	◯	◯
きめ細かなアクセスコントロールポリシーを定義し、SQL テキストなどの機密性の高いディメンションへのアクセス権を制限する	◯	◯
フリート全体のモニタリングビューを作成して保存し、何百ものデータベースの健全性を評価する	×	◯
クエリごとの統計を視覚化する	×	◯
遅い SQL クエリを分析する	×	◯
CloudWatch Application Signals を使用して通話サービスを表示する	×	◯
メトリクス、ログ、イベント、アプリケーションを含め、すべてのデータベーステレメトリの統合ダッシュボードを表示する	×	◯
Performance Insights のカウンターメトリクスを CloudWatch に自動的にインポートする	×	◯
CloudWatch で Amazon RDS イベントを表示する	×	◯
オンデマンド分析を使用し、選択した期間のデータベースのパフォーマンスを分析する	×	◯

Database Insightsの利用方法

クラスターパラメーターの変更

今回は実行計画を見れるようにするためにクラスターパラメーターの変更が必要です。 aurora_compute_plan_idを有効にします。具体的にはaurora_compute_plan_id = on(1)にすることで利用可能です。動的に反映するので再起動は不要なのはありがたい。

アドバンスモードの有効化

既にPerformance Insightsが有効な状態のインスタンスに対してアドバンスモードを有効化します。 Clusterの設定変更から実施します。スタンダードになっているところをアドバンスを選択するだけで大丈夫です。

パフォーマンス履歴の期間を設定することができますが、最低でも15ヶ月からの選択をしないといけないためアドバンスを利用する場合は課金対象となります。 変更時にはダウンタイムは発生しないため一定期間だけの利用を検討することもできます。

Database Insightsを使ってみる

CloudWatch→インサイト内のデータベースインサイトから利用できます。

様々な項目がありますが詳細については割愛します。

RDS instances overviewで先ほどアドバンスを有効にしたインスタンスを選択します。

インスタンスに対してパフォーマンスの詳細情報が確認できます。

中段以降にタブがあるので「DB負荷分析」、「上位のSQL」を選び、実行計画を確認したいSQLを選択します。今回はINSERTしているSQLを選択しました。

続いて「プラン」があるので選びます。すると実行計画が確認できました。検証データを作るためにサブクエリを利用していたので Subquery Scanが出てきてますね。 ProjectSetは初めて見ましたがここでは深掘りしないでおきます。軽く検索したら関数を利用した際に使われるようですね。（参考）

直接DBに入って同じSQLの実行計画を確認しましたが同じような内容の実行計画でした。

                                   QUERY PLAN                                   
--------------------------------------------------------------------------------
 Insert on test_tbl  (cost=0.00..22500.10 rows=0 width=0)
   ->  Subquery Scan on "*SELECT*"  (cost=0.00..22500.10 rows=1000001 width=80)
         ->  ProjectSet  (cost=0.00..5000.09 rows=1000001 width=96)
               ->  Result  (cost=0.00..0.01 rows=1 width=0)
 Planning:
   Buffers: shared hit=11
(6 rows)

ただし、BUFFERSが見れないのでキャッシュも含めて確認したい場合はDBに入り確認する必要がありそうです。

感想

設定自体はとても簡単で手軽に実行計画を確認できるようになったのはとても便利に感じました。気になる点としてはやはりコスト面。実行計画を手軽に見れるようにするだけでは導入するメリットがあまりないように感じたのでDatabase Insightsの他のメリットを見つけていきたいなと思いました。このブログが参考になれば幸いです。