管理する Aurora PostgreSQL 接続チャーンとプーリング

クライアントアプリケーションの接続と切断が頻繁に行われ、Aurora PostgreSQL DB クラスターの応答時間が遅くなると、クラスターに接続チャーンが発生しているとされます。Aurora PostgreSQL DB クラスターエンドポイントに新たに接続するたびにリソースが消費されるため、実際のワークロードの処理に使用できるリソースが減少します。接続チャーンについては、次のベストプラクティスに沿って対応することをお勧めします。

手始めに、接続チャーンが多い Aurora PostgreSQL DB クラスターの応答時間を改善できます。これを実行するには、RDS プロキシなどの接続プーラーを使用できます。接続プーラーによって、クライアントが接続のキャッシュをすぐに使用できます。Aurora PostgreSQL のほぼすべてのバージョンで RDS プロキシをサポートしています。(詳しくは、「Aurora PostgreSQL による Amazon RDS Proxy」を参照してください。)

お使いの Aurora PostgreSQL の特定のバージョンが RDS プロキシをサポートしていない場合は、PgBouncer など、PostgreSQL 互換のある別の接続プーラーを使用できます。詳細については、PGBouncer のウェブサイトを参照してください。

Aurora PostgreSQL DB クラスターが接続プールのメリットがあるかどうかを確認するには、postgresql.log ファイルの接続および切断でチェックできます。また、Performance Insights を使用して、Aurora PostgreSQL DB クラスターで接続チャーンがどの程度発生しているかを確認できます。以下は、この 2 つのトピックについての情報です。

接続と切断のログ

PostgreSQL log_connections および log_disconnections パラメータにより、Aurora PostgreSQL DB クラスターのライターインスタンス、への接続と切断をキャプチャできます。デフォルトでは、これらのパラメータはオフになっています。これらのパラメータをオンにするには、カスタムパラメータグループを使用し、値を 1 に変更することでオンになります。カスタムパラメータグループの詳細については、「Amazon Aurora DB クラスターの DB クラスターパラメータグループ」を参照してください。設定を確認するには、psql を使用して Aurora PostgreSQL の DB クラスターエンドポイントに接続し、次のようにクエリを実行します。


labdb=> SELECT setting FROM pg_settings
  WHERE name = 'log_connections';
 setting
---------
on
(1 row)
labdb=> SELECT setting FROM pg_settings
  WHERE name = 'log_disconnections';
setting
---------
on
(1 row)

この 2 つのパラメータを両方ともオンにすると、ログには新しい接続と切断がすべて記録されます。新しく許可された接続ごとに、ユーザーとデータベースが表示されます。次の例に示されているように、切断時にはセッションの継続時間もログに記録されます。


2022-03-07 21:44:53.978 UTC [16641] LOG: connection authorized: user=labtek database=labdb application_name=psql
2022-03-07 21:44:55.718 UTC [16641] LOG: disconnection: session time: 0:00:01.740 user=labtek database=labdb host=[local]

アプリケーションの接続チャーンをチェックするため、これらのパラメータがまだオンになっていない場合はオンにします。次に、実際のワークロードと期間でアプリケーションを実行して、分析用に PostgreSQL ログにデータを収集します。ログファイルは、RDS コンソールで表示できます。Aurora PostgreSQL DB クラスターのライターインスタンスを選択し、[Logs & events] (ログとイベント) タブをクリックします。(詳しくは、「データベースログファイルの表示とリスト化」を参照してください。)

または、コンソールからログファイルをダウンロードし、次のコマンドシーケンスを使用することもできます。このシーケンスでは、1 分間に許可された接続と切断された接続の合計を求めます。


grep "connection authorized\|disconnection: session time:" postgresql.log.2022-03-21-16|\
awk {'print $1,$2}' |\
sort |\
uniq -c |\
sort -n -k1

出力例では、16:12:10 に認証済み接続が急増し、その後切断していることがわかります。


.....
,......
.........
5 2022-03-21 16:11:55 connection authorized:
9 2022-03-21 16:11:55 disconnection: session
5 2022-03-21 16:11:56 connection authorized:
5 2022-03-21 16:11:57 connection authorized:
5 2022-03-21 16:11:57 disconnection: session
32 2022-03-21 16:12:10 connection authorized:
30 2022-03-21 16:12:10 disconnection: session
31 2022-03-21 16:12:11 connection authorized:
27 2022-03-21 16:12:11 disconnection: session
27 2022-03-21 16:12:12 connection authorized:
27 2022-03-21 16:12:12 disconnection: session
41 2022-03-21 16:12:13 connection authorized:
47 2022-03-21 16:12:13 disconnection: session
46 2022-03-21 16:12:14 connection authorized:
41 2022-03-21 16:12:14 disconnection: session
24 2022-03-21 16:12:15 connection authorized:
29 2022-03-21 16:12:15 disconnection: session
28 2022-03-21 16:12:16 connection authorized:
24 2022-03-21 16:12:16 disconnection: session
40 2022-03-21 16:12:17 connection authorized:
42 2022-03-21 16:12:17 disconnection: session
40 2022-03-21 16:12:18 connection authorized:
40 2022-03-21 16:12:18 disconnection: session
.....
,......
.........
1 2022-03-21 16:14:10 connection authorized:
1 2022-03-21 16:14:10 disconnection: session
1 2022-03-21 16:15:00 connection authorized:
1 2022-03-21 16:16:00 connection authorized:

この情報により、ワークロードに対して接続プーラーが有効かどうかを判断できます。より詳細な分析には、Performance Insights を使用できます。

Performance Insights による接続チャーンの検出

Performance Insights を使用して、Aurora PostgreSQL 互換エディション DB クラスター接続チャーンの量を評価できます。Aurora PostgreSQL DB クラスターを作成する際には、Performance Insights の設定はデフォルトでオンになります。DB クラスターの作成時にこの選択をオフした場合は、クラスターを変更して機能をオンにします。(詳しくは、「Amazon Aurora DB クラスターの変更」を参照してください。)

Aurora PostgreSQL DB クラスターで Performance Insights を実行すると、モニタリングするメトリクスを選択できます。Performance Insights には、コンソールのナビゲーションペインからアクセスできます。また、次のイメージのように、Aurora PostgreSQL DB クラスターのライターインスタンスの [Monitoring] (モニタリング) タブから Performance Insights にアクセスできます。

RDS コンソールと選択した Aurora PostgreSQL DB クラスター内から Performance Insights にアクセスしているイメージ。

Performance Insights コンソールから、[Manage metrics] (メトリクスの管理) を選択します。Aurora PostgreSQL DB クラスターの接続アクティビティと切断アクティビティを分析するには、次のメトリクスを選択します。これらはすべて PostgreSQL のメトリクスです。

xact_commit — コミットされたトランザクション数。
total_auth_attempts — 認証されたユーザーの 1 分あたりの接続試行数。
numbackends — 現在データベースに接続されているバックエンド数。

設定を保存し、接続アクティビティを表示するには、[Update graph] (グラフの更新) を選択します。

次のイメージでは、100 人のユーザーで pgbench を実行した場合の影響を確認できます。接続を示す線は、一貫して右肩上がりになっています。pgbench の詳細と使用方法については、PostgreSQL のドキュメントの「pgbench」を参照してください。

接続プーリングの必要性を示す Performance Insights のイメージ。

このイメージは、接続プーラーなしでわずか 100 人のユーザーでワークロードを実行した場合でも、ワークロードの処理期間中に total_auth_attempts の数が大幅に増加することを示しています。

RDS プロキシ接続プーリングでは、ワークロードの開始時に接続試行回数が増加します。接続プールを設定すると、平均値は低下します。トランザクションとバックエンドによって使用されるリソースは、ワークロードの処理中は常に一定に保たれます。

接続プーリングに対する RDS プロキシのメリットを示す Performance Insights のイメージ。

Aurora PostgreSQL DB クラスターでの Performance Insights 使用の詳細については、「Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。メトリクスを分析するには、「Performance Insights ダッシュボードを使用してメトリクスを分析する」を参照してください。

接続プーリングの利点のデモンストレーション

前述のとおり、Aurora PostgreSQL DB クラスターに接続チャーンの問題があると判断した場合は、RDS プロキシを使用してパフォーマンスを向上させることができます。以下に、接続をプールする場合としない場合のワークロード処理の違いを示す例を示します。この例では、pgbench を使用してトランザクションワークロードをモデル化しています。

psql と同様に、pgbench はローカルクライアントマシンからインストールして実行できる PostgreSQL クライアントアプリケーションです。また、Aurora PostgreSQL DB クラスターの管理に使用する Amazon EC2 インスタンスからインストールして実行できます。詳細については、PostgreSQL のドキュメントの「pgbench」を参照してください。

この例で順番に説明すると、まず、データベースに pgbench 環境を作成します。次のコマンドは、指定されたデータベースの pgbench テーブルを初期化するための基本的なテンプレートです。この例では、ログイン用にデフォルトのメインユーザーアカウントである postgres を使用しています。Aurora PostgreSQL DB クラスターに合わせ、必要に応じて変更します。pgbench 環境は、クラスターのライターインスタンス上のデータベースに作成します。

注記

pgbench の初期化プロセスでは、pgbench_accounts、pgbench_branches、pgbench_history、pgbench_tellers という名前のテーブルが削除され、再作成されます。pgbench を初期化する際には、これらの名前が dbname に選択したデータベースに使用されていないことを確認してください。


pgbench -U postgres -h db-cluster-instance-1.111122223333.aws-region.rds.amazonaws.com -p 5432 -d -i -s 50 dbname

pgbench では、次のパラメータを指定します。

-d: pgbench の実行時にデバッグレポートを出力します。
-h: Aurora PostgreSQL DB クラスターのライターインスタンスのエンドポイントを指定します。
-i: ベンチマークテスト用にデータベースの pgbench 環境を初期化します。
-p: データベース接続に使用されるポートを指定します。Aurora PostgreSQL のデフォルトは、通常 5432 または 5433 です。
-s: テーブルに行を入力する際に使用するスケーリング係数を指定します。デフォルトのスケーリング係数 1 で、pgbench_branches テーブルに 1 行、pgbench_tellers テーブルに 10 行、pgbench_accounts テーブルに 100,000 行が生成されます。
-U: Aurora PostgreSQL DB クラスターのライターインスタンスのユーザーアカウントを指定します。

pgbench 環境をセットアップしたら、接続プールの有無を問わずベンチマークテストを実行できます。デフォルトのテストは、トランザクションごとに 5 つの SELECT、UPDATE、INSERT コマンドが、指定された時間繰り返し実行されます。スケーリング係数、クライアント数などの詳細を指定して、独自のユースケースをモデル化できます。

例として、次のコマンドでは 20 の同時接続 (-c オプション) で 60 秒間 (-T オプション、時間) でベンチマークを実行します。-C オプションでは、クライアントセッションごとに 1 回ではなく、毎回新しい接続を使用してテストを実行します。この設定により、接続のオーバーヘッドがわかります。


pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 -C labdb
Password:**********
pgbench (14.3, server 13.3)
  starting vacuum...end.
  transaction type: <builtin: TPC-B (sort of)>
    scaling factor: 50
    query mode: simple
    number of clients: 20
    number of threads: 1
    duration: 60 s
    number of transactions actually processed: 495
    latency average = 2430.798 ms
    average connection time = 120.330 ms
    tps = 8.227750 (including reconnection times)

接続を再利用せずに Aurora PostgreSQL DB クラスターのライターインスタンスで pgbench を実行した場合、1 秒間で約 8 件のトランザクションしか処理されていないことがわかります。これにより、1 分間のテストで合計 495 件のトランザクションが実行されます。

接続を再利用すると、ユーザー数に対する Aurora PostgreSQL DB クラスターからの応答は約 20 倍速くなります。再利用の場合、同じ時間、同じユーザー数の接続で 495 件のトランザクションが処理されるのに対し、合計 9,042 件のトランザクションが処理されます。次では、各接続が再利用される点が異なります。


pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 labdb
Password:*********
pgbench (14.3, server 13.3)
      starting vacuum...end.
      transaction type: <builtin: TPC-B (sort of)>
      scaling factor: 50
      query mode: simple
      number of clients: 20
      number of threads: 1
      duration: 60 s
      number of transactions actually processed: 9042
      latency average = 127.880 ms
      initial connection time = 2311.188 ms
      tps = 156.396765 (without initial connection time)

この例では、接続をプールすることで応答時間を大幅に改善できることを示しています。Aurora PostgreSQL DB クラスターに RDS プロキシをセットアップする方法については、「Amazon RDS Proxy for Aurora の使用」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

フェイルオーバー後の高速リカバリ

Aurora PostgreSQL のメモリパラメータの調整