Amazon RDS for PostgreSQL および Amazon Aurora PostgreSQL データベース向け AI 搭載チューニングツール: PI Reporter

AWS では、Amazon Relational Database Service (Amazon RDS) のデータベースパフォーマンスメトリクスを収集・分析するためのいくつかのサービスを提供しています。これには Amazon CloudWatch と CloudWatch Database Insights が含まれます。さらに、さまざまなツールを使用して Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL-Compatible Edition を監視するためのカスタムダッシュボードを作成できます (詳細については、Create an Amazon CloudWatch dashboard to monitor Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL と Monitor Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL performance using PGSnapper をご覧ください)。

人工知能と機械学習 (AI/ML) の進歩により、データベース監視領域で ML 機能を使用する無数のソリューションが利用可能になっています。これらのツールは、パフォーマンスの監視のボトルネックから運用上の問題まで、幅広い機能を提供します。また、問題をプロアクティブかつリアクティブに解決するための規範的な推奨事項も提供します。

このブログでは、セルフマネージドの Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのマネージドデータベースサービスを使用して、PostgreSQL 向けの人工知能と機械学習 (AI/ML) を活用したデータベース監視ツールについて探求します。

監視に関する考慮事項

このセクションでは、すべてのデータベースにとって重要なメトリクスについて説明します。これらのメトリクスは、ワークロード、データベースパラメータ、およびパフォーマンスに影響するその他の要因の変化を比較およびベンチマークするための履歴情報を保持するために、定期的に監視する必要があります。次の表は、AWS マネージドデータベースで監視することを推奨するメトリクスを示しています。

監視のソース	パラメータ/メトリクス
Amazon CloudWatch	Database Connections
	CPU Utilization
	Freeable Memory
	FreeStorageSpace
	ReadLatency, WriteLatency
	DiskQueueDepth
	ReadIOPS, WriteIOPS
	WriteThroughput, ReadThroughput
	ReplicaLag
	OldestReplicationSlotLag
	ReplicationSlotDiskUsage
	MaximumUsedTransactionIDs
Amazon CloudWatch Database Insights	DatabaseLoad
	IO Latency
	EBS IO
	LongestIdleInTransaction
	CPU Utilization (%)
	Sessions
	Tuples
	Transactions, Transaction in progress
	IO cache vs Disk read
	Deadlocks
	OS Processes
pg_stat_progress_vacuum	Vacuum progress
pg_stat_activity	state of the query/idle_in_transaction

完全なリストについては、拡張モニタリングの OS メトリクス、RDS PostgreSQL の SQL 統計、Amazon RDS for PostgreSQL の CloudWatch Database Insights カウンター、Vacuum Progress Reporting、pg_stat_activity を参照してください。

ここでは、AI/ML ベースのデータベース監視およびトラブルシューティングツールである PI Reporter について、その機能とユースケースを含めて説明します。

PI Reporter は、AWS ソリューションアーキテクトが開発したオープンソースツールで、パフォーマンスメトリクスとワークロードスナップショットを取得し、Amazon Aurora PostgreSQL-Compatible Edition の詳細な比較レポートを生成し、Amazon Bedrock の支援によるオプションのレポート分析を提供します。

PI Reporter

PI Reporter は Amazon Bedrock と統合し、Anthropic の Claude や Amazon Nova モデルなどの大規模言語モデル (LLM) の機能を活用して、個別のスナップショットと比較データを分析します。必要なモデルにアクセスできることを確認してください。この分析により、スナップショットウィンドウで発見されたデータベースパフォーマンスの問題に対する包括的な要約、根本原因分析、実行可能な推奨事項が生成されます。

PI Reporter では、以下のことが実行可能です :

インスタンス関連情報の包括的な HTML レポートを数分で取得
定期的なレポートを比較して、パフォーマンス、ワークロード、または設定の変更を検出
インスタンスがワークロードを処理できるかを評価し、適切なサイジングのニーズを特定
システムセキュリティを損なうことなく、サードパーティとインスタンス統計を共有
根本原因の特定と推奨事項を含む LLM 分析を受信

このツールは、さまざまなシナリオで活用できます。一般的な例をいくつか紹介します。データベースのパフォーマンスが突然低下した場合、PI Reporter は影響を受けた期間と、通常のデータベースアクティビティを示す比較可能な期間の両方のスナップショットを取得できます。HTML 比較レポートは、何が変わったのか、そして考えられる根本原因を即座に表示します。

もう 1 つの有用なユースケースは、計画通りにデータベースを変更した後のワークロードの変化を評価することです。これには、新しい主要なアプリケーションをリリースする場合、データベースのメジャーバージョンにアップグレードする場合、ブルーグリーンデプロイメントを使用して新しいクラスターに移行する場合、またはその他の重要な変更を行う場合などの状況が含まれます。これらのシナリオでは、変更前後にスナップショットを取得して比較レポートを生成できます。

Amazon Aurora PostgreSQL Serverless インスタンスの監視において、PI Reporter は、予想される ACU 使用パターンと予想外の ACU 使用パターンの期間を比較することで、予想外の高い Aurora Capacity Units (ACU) 使用量の原因を特定するのに役立ちます。

これらの例は、このツールを活用できる方法のほんの一部を示しています。パフォーマンスの比較と分析が必要なあらゆるシナリオに可能性が広がります。

このツールは軽量で使いやすいように設計されています。Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスで Node.js スクリプトとしてデプロイできます。Linux x86 システム用にコンパイルされたポータブル版のスクリプトも含まれています。PI Reporter のセットアップの詳細については、GitHub リポジトリを参照してください。

ソリューション概要

次の図は、AWS サービスを使用した PI Reporter アーキテクチャを示しています。

このソリューションの動作方法を説明します。4 つのレイヤーで構成されています :

データ収集レイヤー:
- Amazon CloudWatch Database Insights は、インスタンスレベルのカウンターパフォーマンスメトリクスと SQL レベルのメトリクスを提供します
- Amazon CloudWatch は、インフラストラクチャとリソースのメトリクスを提供します
- Amazon RDS は、メタデータとデータベースログファイル情報を提供します
処理レイヤー:
- PI Reporter ツールは、すべてのデータソースからデータを集約します
- 適切な権限を持つインスタンスロールが必要で、pireporterPolicy.json IAM ポリシーを通じて設定されます
- このツールは収集されたデータを処理し、統合されたメトリクスを含む JSON スナップショットファイルを生成します
分析レイヤー:
- 高度な分析のために、このソリューションは Amazon Bedrock と統合されます
- システムは、パフォーマンスメトリクス、リソース使用率データ、ワークロード情報 (SQL 統計を含む) を関連する知識と組み合わせて Amazon Bedrock に送信します
- Amazon Bedrock の LLM 機能は以下を提供します:
  - 包括的な要約
  - 詳細な分析
  - 実行可能な推奨事項
出力:
- 最終的な出力は、生のメトリクスと LLM による洞察の両方を含む HTML レポートとして生成されます
- このアーキテクチャは、適切な IAM ロールと権限を通じてセキュリティを維持しながら、包括的なパフォーマンス監視と分析を確保します

前提条件

PI Reporter は Amazon CloudWatch Database Insights からの情報を使用するため、まず Amazon CloudWatch Database Insights を有効にする必要があります。

以下は、チューニングとトラブルシューティングツールに共通する PostgreSQL 固有の要件です :

pg_stat_statements 拡張機能を有効にして、クエリごとの統計情報を収集します。この拡張機能は、Aurora PostgreSQL ではデフォルトで有効になっています
デフォルトでは、PostgreSQL データベースは 1,024 バイトを超えるクエリを切り捨てます。ログに記録されるクエリサイズを増やすには、DB インスタンスに関連付けられた DB パラメータグループの track_activity_query_size パラメータを変更します。このパラメータを変更する場合、データベースの再起動が必要です

詳細については、GitHub リポジトリを参照してください。

PI Reporter のインストールと実行

PI Reporter は使いやすいように設計されています。Linux OS を搭載した Amazon EC2 上、または Aurora PostgreSQL クラスターが実行されている AWS リージョンにアクセス可能なオンプレミスの Linux ホスト上で、GitHub リポジトリからダウンロードできます。

PI Reporter をインストールするには、以下の手順を実行します :

リポジトリをローカルファイルシステムにクローンします :
```
git clone https://github.com/awslabs/pireporter.git
```
リポジトリをクローンした後、pireporter ディレクトリ内に pireporterPolicy.json AWS Identity and Access Management (IAM) ポリシーファイルがあります。このポリシーには、PI Reporter を実行するために必要な権限が含まれています。これらの権限は読み取り専用で、必須のもののみが含まれています。このポリシーにより、pireporter:allow タグが付いたインスタンスとクラスターのみにアクセスできます。制限条件を緩和したい場合は、提供されたポリシーファイルを変更できます。
pireporterPolicy を、ツールを実行する予定の EC2 インスタンスのインスタンスロールにアタッチします。オンプレミスの Linux ホストでツールを実行する場合は、共有認証情報ファイル ~/.aws/credentials でアクセスキーとシークレットキーを使用します。EC2 インスタンスに最新バージョンの AWS CLI をインストールして、プログラムで RDS インスタンスに接続します。PI Reporter で使用される AWS SDK は、ロード時にポリシーファイルを自動的に読み取ります。この場合、ポリシーはアクセスキーが適用される IAM エンティティにアタッチされている必要があります。AWS リージョンは、インスタンスメタデータに基づいて、ホスティング EC2 インスタンスのリージョンに自動的に設定されます。特にオンプレミスでツールを実行する場合は、AWS_REGION 環境変数を希望の値に設定することで、これをオーバーライドできます
ツールを実行するには 2 つのオプションがあります :
1. Node.js を使用して pireporter ツールを実行するには、レポートを生成したいホストに Node.js がインストールされている必要があります :
```
cd pireporter 
 npm install 
 node pireporter.js --help
```
2. ポータブル版を使用する場合（ホストに Node.js をインストールしたくない場合）は、次のコマンドを使用します :
```
cd pireporter/portable 
./pireporter --help
```
特定の期間のスナップショットを生成するには、次のコマンドを使用します :
```
./pireporter --create-snapshot --rds-instance myinstance --start-time 2025-01-20T10:00 --end-time 2025-01-20T10:15 --comment "Unusually slow inserts"
```
上記の例では、create-snapshot コマンドが疑わしいアクティビティや異常な動作を観察した 15 分間の時間間隔のデータをキャプチャします。そうでない場合は、終了して次のメッセージを出力します :No performance data available from Performance Insights for the selected time frame. Please choose a time frame with application load or user activity. これは、指定した時間枠によって数秒から 1 分程度かかる場合があります。メトリクスの平均値の希釈を減らすために、スナップショットの境界を関心のある期間に制限してください。このコマンドは、snapshots サブフォルダに JSON スナップショットファイルを生成します。--comment 引数を使用すると、生成されたスナップショットにコメントを関連付けることができます。このコメントは LLM に渡され、その推論動作に影響を与える可能性があります。
キャプチャしたスナップショットに対して生成 AI 分析と推奨事項を含む HTML レポートを生成するには、次のコマンドを使用します :
```
./pireporter --create-report --snapshot snapshot_myinstance_202501201000_202501201015.json --ai-analyzes
```
--ai-analyzes 引数は、Amazon Bedrock によって提供される LLM の分析を HTML レポートに含めます。レポートは reports サブフォルダに保存されます。

ツールで使用される LLM (リージョンとモデル ID) は、conf.json ファイルで確認できます。Converse API をサポートする Amazon Bedrock の LLM を使用できます。

考慮事項と推奨事項

PI Reporter はインスタンスの動作の変化を特定して問題検出フェーズを最小化するために作成されたため、2 つのスナップショットを生成することを推奨します :

インスタンスが異常な動作をしている問題のある期間
インスタンスが正常に動作していた類似の期間

次に --create-compare-report を使用して比較 HTML レポートを生成します。これにより、大幅に変更されたメトリクスと SQL を確認できます。

比較期間レポートの生成 AI 分析は、両方の期間のデータがあることで、より洞察に富んだものになります。両方の期間は以下の要件を満たす必要があります :

両方の期間は同じ長さである必要があります
問題のあるスナップショットは、問題が開始した時点から開始する必要があります
問題のあるスナップショットは、問題が終了した時点で終了するか、問題がまだ存在する場合は開始時刻から 60 分など合理的な時間後に終了する必要があります

また、スナップショットに意味のあるコメントを提供することも検討してください。LLM に対して、特定の領域に注意を向けるよう指示したり、ユーザーとしての観察結果を伝えるなどのヒントを提供できます。

生成 AI は幻覚を起こしたり、間違った仮定を提供したりする可能性があります。私たちは、有用なデータベースエンジン固有の知識を含む追加のコンテキストを LLM に提供することで、これを最小限に抑えるよう努めました。生成 AI 分析は、それらを評価できるデータベース専門家と組み合わせて使用することをお勧めします。

レポートの解釈

LLM が生成するレポートの部分は、HTML レポートの上部にある薄い青色のボックスに表示されます。生成 AI セクションは一般的な要約から始まり、主な発見事項と問題の根本原因 (ある場合) が含まれます。

一般的なレポートサマリーの後に、レポートの各セクションのサマリーが表示されます。これには、一般的なインスタンス設定、非デフォルトパラメータ、待機イベント、OS メトリクス、DB メトリクス、および DB インスタンスの全体的なネットワークスループットなどの追加メトリクスが含まれます。これらは他の統計情報と SQL セクションから計算されます。スナップショット作成時に --include-logfiles 引数が指定されていた場合、レポートにはスナップショット期間のデータベースログファイルの分析も含まれます。

次のスクリーンショットは、ユースケース用に生成されたレポートからの生成 AI 分析のサマリーセクションを示しています。サマリーには、CPU、メモリ、ネットワークスループットなどの非常に高いリソース使用率に関するいくつかの観察結果が含まれています。また、高負荷の原因となっているワークロードタイプ（ insert ステートメントやその他の書き込みアクティビティ）に関する情報も取得できます。さらに、public.employee テーブルでの insert と autovacuum アクティビティという 2 つの SQL ステートメントが表示されます。SQL 参照 ID を選択すると、完全な SQL テキストを表示できます。レポートでは、パフォーマンス問題の根本原因も提供されます。

一般的な要約の次のセクションは、推奨事項セクションです。このセクションには、問題の根本原因を修正するために LLM が生成したステップが含まれています。この特定のケースでは、LLM は観測されたワークロードを処理できる推奨インスタンスタイプの 1 つにインスタンスをスケールアップすることを推奨しています。また、ワークロードを確認し、システムへの影響を減らすために特定の autovacuum パラメータを調整することも推奨しています。

リアクティブユースケース: バルクデータインサート

このセクションでは、データベースでバルクデータロードを実行し、CPU、ディスク、IOPS、ネットワークなどの異なるリソースの使用率を観察するユースケースについて説明します。リソースの使用率が高くなると、アクティブまたはパッシブアラートがトリガーされる可能性があるため、リソースが過度に使用されており、アップグレードが必要であることを理解できます。

バルクデータインサートの前提条件

このユースケースを検証するには、データを一括挿入するテーブルが必要です。例えば、以下のコードを参照してください。

BEGIN ;

 CREATE TABLE employee(
 emp_id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 name TEXT NOT NULL 
 ); 
 COMMIT ;

バルクデータインサートのユースケース

以下のコードを使用してバルクインサートを実行します :

BEGIN ;
 INSERT INTO employee (name)
 SELECT substr(md5(random()::text), 1, 12)
 FROM generate_series(1, 100000000) AS _g ;
 ANALYZE ;
 COMMIT ;

このテストケースでは、employee テーブルに大量のデータを挿入するために、前述の INSERT 文を 100000000 の件数で実行しました。これにより 500 MB のデータが作成され、テーブルに挿入されました。

次に、PI Reporter を使用して AI/ML ベースのレポートを作成するには、以下のコマンドを実行します :

./pireporter --create-snapshot --rds-instance myinstance --start-time 2024-10-15T09:00 --end-time 2024-10-16T08:00 --comment "Bulk inserts"
./pireporter --create-report --snapshot snapshot_myinstance_202410150900_202410160800.json --ai-analyzes

ここで、--start-time と --end-time パラメータは、insert 文の実行前のタイムスタンプと insert 文の完了後のタイムスタンプに対応する必要があります。レポートが生成されたら、HTML レポートファイルを開いてレポートを読むことができます。次の推奨事項が表示されます :

レポートの最初の部分では、レポートの開始時刻と終了時刻、およびレポートが生成された総期間の詳細が表示されます。次に、インスタンスの高レベルな詳細と、一括実行した insert 文などのリソース使用率上昇の責任または主要な原因が示されます。パフォーマンスに影響を与えるクエリと、定期的な vacuum および checkpoint チューニングの必要性が強調されています。

同じ情報が上記の推奨事項セクションに記載されていますが、ポイントごとの詳細が含まれています。

推奨事項の最初の部分は、インスタンスの一般情報に関するもので、従っている高可用性プラクティス、設定されているバックアップと監視オプションが含まれます。次のセクションには、レポート期間のメモリと CPU 使用率に関する静的メトリクスが含まれます。最後のセクションは、存在する場合のデフォルト以外のパラメータに関するものです。

AI によって生成されたレポートの分析では、リソース使用率と IO イベントに関する洞察が提供されます。また、インスタンスの現在のサイズ、使用率、推奨される適切なインスタンスタイプについても説明されています。さらに、CPU 使用率、ディスク IO、メモリ、ネットワーク、スワップ使用量などの重要な OS メトリクスも提供されます。この場合、リソースが十分に活用されていなかったため、コスト最適化のために適切なインスタンスタイプを選択することが推奨されました。これらの推奨事項を生成する際は、レポートを生成する期間を十分に長く設定することを確認してください。実装前に、データベースの専門家と推奨事項を検証してください。

上記の画像のデータベースメトリクスに関する推奨事項は価値があります。バルクインサートトランザクションアクティビティ、チェックポイントチューニング、定期的なバキュームに関する提案が含まれているためです。

最終的な GenAI 分析では、インスタンスを十分に活用できていないことに関するインサイトが提供されますが、ダウンサイジングを実行する前に、インスタンスのパフォーマンスを総合的に確認することを強く推奨します。CPU、ネットワーク帯域幅、効率的なキャッシュ、ディスク IO、チェックポイント、autovacuum などの要素を考慮してください。これらの洞察はすべて、データベースパフォーマンスの最適化において価値があります。統合された推奨事項では、クエリ最適化、インスタンスアップグレード、削除保護、バックアップ保持、高可用性のためのリーダーインスタンスの追加がカバーされています。

アイドルトランザクションのユースケース

PI Reporter ツールは、スナップショットを使用して収集されたデータで動作します。アイドル状態のトランザクションセッションがあるスナップショットで収集された統計は、最終レポートで報告されます。アイドル状態のトランザクションを自動的に終了し、リソースの保持を防ぐために、idle_in_transaction_session_timeout パラメータを 300 秒 (5 分) の値で実装することを推奨します。

上記の画像では、PI Reporter がトランザクション内でアイドル状態のセッションを明確に特定し、関連するパラメータに適切な値を設定することを推奨しています。また、コミットやロールバックのないトランザクションブロックを見つけるために、アプリケーションコードを確認することも提案しています。5 分以上アイドル状態のトランザクションに対する監視アラートを設定することを推奨しており、これにより、そのようなトランザクションを終了したり、データベースリソースの大部分を消費し始める前に問題を修正したりできます。Amazon CloudWatch Database Insights は、Database Telemetry -> Metrics オプションの下で、最大アイドルトランザクションメトリクスを提供します。

データベースメトリクスセクションでは、セッションがトランザクション内でアイドル状態になっている概算時間を確認できます。最後の Analysis セクションでは、パフォーマンスの向上とコスト最適化のためのインスタンス全体の推奨事項をまとめています。

クリーンアップ

Amazon Bedrock によって作成された AWS リソースは、使用している限りコストが発生します。生成 AI 分析を含むレポートを生成するたびに、PI Reporter は特定の呼び出しで使用された入力トークンと出力トークンの数を出力します。リソースが不要になったら、関連するサービスとスクリプトを削除してクリーンアップしてください。この投稿に従ってテスト環境を作成した場合は、使用が完了したらリソースをクリーンアップしてください。

機能の概要

次の表は、PI Reporter ツールの機能の概要を示しています。

パラメータ/機能	PI Reporter
クラウドに依存しない	No
オンプレミスデータベース	No
設定の推奨事項	Yes
データベースの健全性	Yes
インデックスの推奨事項	Yes
非効率な SQL	Yes
Autovacuum	Yes
パフォーマンスチャート	No
エージェントタイプ	No
本番環境対応	Yes
コスト	Apache-2.0 ライセンスインフラストラクチャと Amazon Bedrock に関連するコスト

*デプロイメントオプション、データベースフリートのサイズ、複数年契約などの要因が最終的なコストに大きく影響します。

まとめ

この投稿では、PI Reporter ツールの監視機能と可能なユースケースについて説明しました。PI Reporter は数秒で有用な情報を収集し、JSON スナップショットに保存できます。これらは HTML レポートの生成や将来の調査のための保存に使用できます。これは、トラブルシューティングや DB インスタンスの健全性を理解するのに役立つツールです。Amazon Bedrock でホストされている LLM と組み合わせて使用することで、利用可能なメトリクスと SQL を分析し、生成 AI に調査結果の要約、問題の根本原因の検出、推奨事項の提供を行わせることができます。

この記事で説明した PI Reporter ツールには独自の機能があり、お客様のワークロードに適合する場合もあれば適合しない場合もあるため、慎重にテストと評価を行う必要があります。本番環境で実行する前に、非本番環境でこれらのツールをテストすることを強く推奨します。

皆様のフィードバックをお待ちしています。ご質問やご提案がございましたら、コメント欄でお聞かせください。

Amazon Web Services ブログ