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

管理する 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 に変更することでオンになります。カスタムパラメータグループの詳細については、「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 — 認証されたユーザーの接続試行数。

  • numbackends — 現在データベースに接続されているバックエンド数。


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

設定を保存し、接続アクティビティを表示するには、[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_accountspgbench_branchespgbench_historypgbench_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 の使用」を参照してください。