# 管理する Aurora PostgreSQL 接続チャーンとプーリング クライアントアプリケーションの接続と切断が頻繁に行われ、Aurora PostgreSQL DB クラスターの応答時間が遅くなると、クラスターに*接続チャーン*が発生しているとされます。Aurora PostgreSQL DB クラスターエンドポイントに新たに接続するたびにリソースが消費されるため、実際のワークロードの処理に使用できるリソースが減少します。接続チャーンについては、次のベストプラクティスに沿って対応することをお勧めします。 手始めに、接続チャーンが多い Aurora PostgreSQL DB クラスターの応答時間を改善できます。これを実行するには、RDS プロキシなどの接続プーラーを使用できます。接続プーラーによって、クライアントが接続のキャッシュをすぐに使用できます。Aurora PostgreSQL のほぼすべてのバージョンで RDS プロキシをサポートしています。詳細については、「[Aurora PostgreSQL による Amazon RDS Proxy](Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.md#Concepts.Aurora_Fea_Regions_DB-eng.Feature.RDS_Proxy.apg)」を参照してください。 お使いの Aurora PostgreSQL の特定のバージョンが RDS プロキシをサポートしていない場合は、PgBouncer など、PostgreSQL 互換のある別の接続プーラーを使用できます。詳細については、[PGBouncer](https://www.pgbouncer.org/) のウェブサイトを参照してください。 Aurora PostgreSQL DB クラスターが接続プールのメリットがあるかどうかを確認するには、`postgresql.log` ファイルの接続および切断でチェックできます。また、Performance Insights を使用して、Aurora PostgreSQL DB クラスターで接続チャーンがどの程度発生しているかを確認できます。以下は、この 2 つのトピックについての情報です。 ## 接続と切断のログ PostgreSQL `log_connections` および `log_disconnections` パラメータにより、Aurora PostgreSQL DB クラスターのライターインスタンス、への接続と切断をキャプチャできます。デフォルトでは、これらのパラメータはオフになっています。これらのパラメータをオンにするには、カスタムパラメータグループを使用し、値を 1 に変更することでオンになります。カスタムパラメータグループの詳細については、「[Amazon Aurora DB クラスターの DB クラスターパラメータグループ](USER_WorkingWithDBClusterParamGroups.md)」を参照してください。設定を確認するには、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]** (ログとイベント) タブをクリックします。詳細については、「[データベースログファイルの表示とリスト化](USER_LogAccess.Procedural.Viewing.md)」を参照してください。 または、コンソールからログファイルをダウンロードし、次のコマンドシーケンスを使用することもできます。このシーケンスでは、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.Modifying.md)」を参照してください。 Aurora PostgreSQL DB クラスターで Performance Insights を実行すると、モニタリングするメトリクスを選択できます。Performance Insights には、コンソールのナビゲーションペインからアクセスできます。また、次のイメージのように、Aurora PostgreSQL DB クラスターのライターインスタンスの **[Monitoring]** (モニタリング) タブから Performance Insights にアクセスできます。 ![\[RDS コンソールと選択した Aurora PostgreSQL DB クラスター内から Performance Insights にアクセスしているイメージ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/postgres_connection_pooling_PI_1.png) Performance Insights コンソールから、**[Manage metrics]** (メトリクスの管理) を選択します。Aurora PostgreSQL DB クラスターの接続アクティビティと切断アクティビティを分析するには、次のメトリクスを選択します。これらはすべて PostgreSQL のメトリクスです。 + `xact_commit` — コミットされたトランザクション数。 + `total_auth_attempts` — 認証されたユーザーの 1 分あたりの接続試行数。 + `numbackends` — 現在データベースに接続されているバックエンド数。 ![\[RDS コンソールと選択した Aurora PostgreSQL DB クラスター内から Performance Insights にアクセスしているイメージ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/postgres_connection_churn_PI_4.png) 設定を保存し、接続アクティビティを表示するには、**[Update graph]** (グラフの更新) を選択します。 次のイメージでは、100 人のユーザーで pgbench を実行した場合の影響を確認できます。接続を示す線は、一貫して右肩上がりになっています。pgbench の詳細と使用方法については、PostgreSQL のドキュメントの「[pgbench](https://www.postgresql.org/docs/current/pgbench.html)」を参照してください。 ![\[接続プーリングの必要性を示す Performance Insights のイメージ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/postgres_connection_pooling_PI_2.png) このイメージは、接続プーラーなしでわずか 100 人のユーザーでワークロードを実行した場合でも、ワークロードの処理期間中に `total_auth_attempts` の数が大幅に増加することを示しています。できるだけ `total_auth_attempts` をゼロに近づけることをお勧めします。 RDS プロキシ接続プーリングでは、ワークロードの開始時に接続試行回数が増加します。接続プールを設定すると、平均値は低下します。トランザクションとバックエンドによって使用されるリソースは、ワークロードの処理中は常に一定に保たれます。 ![\[接続プーリングに対する RDS プロキシのメリットを示す Performance Insights のイメージ。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/postgres_connection_pooling_PI_3.png) Aurora PostgreSQL DB クラスターでの Performance Insights 使用の詳細については、「[Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング](USER_PerfInsights.md)」を参照してください。メトリクスを分析するには、「[Performance Insights ダッシュボードを使用してメトリクスを分析する](USER_PerfInsights.UsingDashboard.md)」を参照してください。 ## 接続プーリングの利点のデモンストレーション 前述のとおり、Aurora PostgreSQL DB クラスターに接続チャーンの問題があると判断した場合は、RDS プロキシを使用してパフォーマンスを向上させることができます。以下に、接続をプールする場合としない場合のワークロード処理の違いを示す例を示します。この例では、pgbench を使用してトランザクションワークロードをモデル化しています。 psql と同様に、pgbench はローカルクライアントマシンからインストールして実行できる PostgreSQL クライアントアプリケーションです。また、Aurora PostgreSQL DB クラスターの管理に使用する Amazon EC2 インスタンスからインストールして実行できます。詳細については、PostgreSQL のドキュメントの「[pgbench](https://www.postgresql.org/docs/current/pgbench.html)」を参照してください。 この例で順番に説明すると、まず、データベースに 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: 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: 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](rds-proxy.md)」を参照してください。