RDS PostgreSQLのボトルネックを特定してみた

はじめに

こんにちは！広島でインフラエンジニアをしているkiyomura（@kiyomura742954）です。この記事はTechBullアドベントカレンダー21日目となります。先日、Amazon RDSのボトルネック調査を行う機会がありました。RDSが原因でアプリケーションの動作が遅くなる状況は、遭遇する機会が多いのではないでしょうか。そこで今回は、調査手順をまとめようと思います。

この記事の前提

今回調査したのは、「Amazon RDS for PostgreSQL」です。pgbenchで実際に負荷をかけてDatabase Insightsのスタンダードモードを使用して調査を行いました。

Database Insights とは？

今回は主にDatabase Insightsを使って調査します。Database Insights は、データベースのパフォーマンスを 監視・分析 できる機能です。たとえば、負荷の高い SQL（重いクエリ）や 発生している待機（wait）の種類などを確認できます。

CloudWatch Database Insightsドキュメント

Database Insights は、従来のPerformance Insightsをベースにしつつ、運用向けに機能が拡張されています。たとえば フリート（複数 DB をまとめた単位） を 1 つのダッシュボードで確認し、調子の悪い DB を見つけて深掘りするといった使い方がしやすくなっています。

12月21日現在はどちらも使用できますが、Performance Insights はサポート終了日をが2026 年 6 月 30 日となっていてdatabase Insightsに移行される予定とのことです。

Performance Insights ドキュメント

pgbenchで負荷をかけてみる

pgbenchというベンチマークツールを使ってデータベースに負荷をかけてみます。あらかじめ用意されたSQLや自作したSQL を使用して負荷をかけることができます。

まずは以下のコマンドでデータを投入します。

-h/-U/-d：接続先
-i：初期化（テーブル作成＋データ投入）
-s：データ量（大きいほどテーブルが大きくなる）

次に作成したテーブルに対してクエリを実行して負荷をかけます。

-S：select-only（読み取りのみ）
-c：クライアント数
-j：スレッド数
-T：実行秒数

pgbenchドキュメント

Database Insightsで負荷を確認する

Database Insightsの「データベース負荷」を確認してみます。

まずは、平均アクティブセッション (AAS)を超えていないかを見ます。

平均アクティブセッション (AAS)はCPUで実行中、待機中の処理の合計です。vCPU数（DBインスタンスのCPUコア数）との比較をしてCPUで実行できる量より、同時に実行中、待機中の処理数が多くないか確認します。

RDSのvCPU数が2(グラフだと点線)でASSが最大で38と大幅に超えていて負荷の高い状態なのがわかりました。次に「上位の待機」を確認して何が原因でASSが高くなっているかみてみます。「上位の待機」はDBの処理が何が原因で止まっているかをランキング表示したものです。

最も割合が高かったのは「IPC:BufferIO」でした。

これは、共有バッファ（shared_buffers)に読み込みたいページが存在し、別プロセスがそのページの読み込み I/O を実行中のため、処理が完了するまで待たされている状態を表す待機イベントです。

テーブル/インデックスの同じページにアクセスが集中したときによく発生するようです。

LWLock:BufferIO (IPC:BufferIO)

「上位のSQL」をみることでどのSQLがDBに負荷をかけているか確認できます。

 

主に「SELECT abalance FROM pgbench_accounts WHERE aid = ?」このクエリが負荷をかけていることがわかりました。

ボトルネック改善に向けたアクション

「IPC:BufferIO」が原因でデータベースの負荷が高くなっている場合は以下の改善策があるようです。

インデックスの追加
未使用のインデックスがある場合は削除
パーティション化されたテーブルを使用
DB パラメータ調整
インスタンスサイズ変更／ストレージ強化
データベースへの最大接続数を制限

今回はインデックスを作成してテストしてみます。先ほど負荷の高かったクエリに対してインデックスを作成します。

pgbenchで前回と同じオプションで負荷をかけて、データベースの負荷がどのように変化するか確認してみます。

結果としては、平均アクティブセッション（AAS）は 38 → 20 まで低下しました。依然として vCPU 数を上回ってはいるものの、インデックス作成前と比較すると 大きく負荷が改善していることが分かります。実際にpgbenchの実行時間も短くなりました。

また、インデックス作成前は、待機イベントの大部分をIPC:BufferIOが占めていましたが、インデックス作成後は CPU がほとんどを占める状態に変化しました。

まとめ

本記事では、Amazon RDS for PostgreSQLに対してpgbenchを用いて負荷をかけDatabase Insightsを、使ったボトルネック調査の流れを紹介しました。私自身、データベースについて勉強中なので、今後もさまざまな負荷シナリオを試しながら改善を重ね、理解を深めていきたいと思います。