最終更新日 2023年05月17日(水)

Heroku Postgres​ データベースの自動監視により、アプリとデータベースのパフォーマンスに関する分析情報を得ることができます。監視ツールを使用して、事前に問題を見つけて、インシデントに迅速に対応し、問題の根本原因を特定します。この記事では、使用するツールや探すメトリクスなど、データベースの監視を効果的に設定する方法について説明します。

プラットフォーム監視ツールを使用してメトリクス監視を設定する

Heroku Postgres は、インスタンスのステータスに関する情報を提供するデータベースとサーバーのメトリクスを提供します。これらのメトリクスを理解して監視することで、アプリケーションの実行および拡張時にデータベースのヘルスが確保されます。

データベースメトリクスを追跡する最も効果的な方法は、プラットフォーム監視アドオンをインストールすることです。監視アドオンの完全な一覧は、Heroku Elements Marketplace​ で確認できます。

提供されるメトリクスの完全な一覧については、Heroku Postgres のメトリクスのログ​を参照してください。次のメトリクスでは、データベースのヘルスに関連する意味のあるアラームを提供するようにアラートが設定されます。

db_size

db_size​ メトリクスは、すべてのテーブルとインデックスデータ、およびデータベースの肥大化​を含むデータベースのサイズです。

ご利用の Postgres データベースのサイズが、ご利用のプラン​に割り当てられたサイズを超えた場合、問題を解決するための指示が記載された警告メールが届きます。場合によっては、データベースがプラン制限を下回るまで、単一のデータベース接続のみが許可され、アクセスが READ​、DELETE​、および TRUNCATE​ アクセスに制限される施行日を設定します。

プラン制限に基づいてアラート​を設定し、それに近づき始めたら事前に通知されるようにします。データベースがプランに割り当てられたサイズの 80% に達した場合の警告​アラートと、割り当てられたサイズの 90% に達した場合のクリティカル​アラートを設定することをお勧めします。

最大サイズに近づいた場合は、プランをアップグレードする​か、データを削除してプラン制限内に収まるようにしてください。

active-connections

active-connections​ メトリクスは、データベースへの確立された接続の数を一覧表示します。

Heroku Postgres は、Postgres のメモリ使用量とスケーリングを最適化するために接続制限​を適用します。

Heroku Postgres のプラン tier-3​ 以降では、500 接続のハード制限があります。その制限に達すると、新しい接続を作成できなくなります。

データベース接続数に基づいてアラートを設定するには、次の 2 つの戦略があります。

• 現在の接続数が突然大きく変化した場合のアラートを設定します。​ベースラインの接続数からの大きな変化は、クエリやトランザクションの実行時間が増加したことを示している可能性があります。アラートのしきい値は、通常の動作条件下で評価された、アプリケーションの接続数の範囲によって異なります。通常の 1 日の最大値よりも +50/+100 を考慮してください。
• 接続数が最大値に近づいた場合のアラートを設定します。​tier 3 以上のプランの場合、最大接続数は 500 であるため、ここから始めるには 400 と 450 が適切な警告とクリティカルの数です。

日常的に接続制限に近づいている場合は、接続プールの使用を検討してください。詳細は、PgBouncer の設定​のベストプラクティスに関するドキュメントを参照してください。

waiting-connections

waiting-connections​ メトリクスは、続行可能になるまでデータベースロックを待機している接続の数を示します。

不定期のロックの待機が予想されますが、持続的なロックの待機は、データベース並列性​が誤って処理されていることを示している可能性があります。

5 分間連続して待機している接続がある場合のアラートを設定します。pg-extras CLI プラグイン​を使用すると、他の操作の実行を妨げているクエリを特定できます。

その後、ロックの競合を解決するために、クエリのブロックを終了​することができます。さらに、ブロックを引き起こすステートメントを知ることは、ロックを減らすために最適化できるアプリケーションコードを特定するのに役立ちます。

load-avg (1m、5m、および 15m の平均)

load-avg​ メトリクスは、指定された期間の平均 CPU 負荷を示します。Heroku の報告された負荷メトリクスは、システム負荷を CPU の数で割ることによって正規化されます。

特定の時間帯での平均負荷が 1.0 の場合は、すべての CPU が完全に使用されていることを示します。負荷が 1.0 を超える場合は、プロセスが特定の時間帯で CPU 時間を待機する必要があることを示します (値が大きいほど、待機中のプロセスにより多くの時間が費やされていることを示します) 。1.0 より小さい値は、CPU が特定の時間帯の間にアイドル時間を費やしたことを示します。この値が高いと、クエリの実行時間の一貫性が低下し、待機時間が長くなります。

1.0 を超える値は過剰な稼働状況を示しているため、負荷がその数に達する前に把握する必要があります。この load-avg​ が 0.8 (警告​) および 0.9 (クリティカル​) に達した場合のアラートを設定します。

CPU 使用率の高いクエリについては、pg:ps​ コマンド​を使用して現在のアクティビティを確認してください。さらに、プロビジョニングされた IOPS を超えると、プロセスは I/O が使用可能になるまで待機してから処理できるようになるため、IOPS を確認してください。load-avg​ の値が常に高いように見える場合は、Heroku Postgres のより大きなプランにアップグレード​する時期を迎えています。それを行う前に、またはすでに最大のプランの場合は、データベースサーバーで実行される処理作業の量やディスクから読み取られるデータの量を減らすために、高コストなクエリを調整する​ことを検討してください。

read-iops

read-iops​ メトリクスは、メインデータベースのディスクパーティションに対して行われた読み取り IO リクエストの数を、IOPS (IO 操作数/秒) の値で追跡します。各 Heroku Postgres のプランには、プロビジョニングされた IOPS (PIOPS) の最大値​が提供されています。これは、プロビジョニングされたディスクボリュームが維持できる 1 秒あたりの最大合計読み取り + 書き込みです。

理想的には、ディスクの読み取りはメモリよりもはるかに遅いため、データベースの読み取りはディスクではなくメモリ (キャッシュ) から行う必要があります。プロビジョニングされた IOPS を超えると、プロセスは I/O が使用可能になるまで待機してから処理できるようになるため、トランザクション時間が長くなり、load-avg​ が高くなります。

90% のプロビジョニングされた IOPS (PIOPS)​ にアラートを設定して、対処できるように重要な I/O を必要とするアクティビティまたはステートメントを特定できるようにします。

read-iops​ の値が常に高いように見える場合は、Heroku Postgres のより大きなプランにアップグレード​する時期を迎えています。それを行う前に、またはすでに最大のプランの場合は、ディスクから直接読み取られるデータの量を減らすために、高コストなクエリを調整する​ことを検討してください。

wal-percentage-used

wal-percentage-used​ メトリクスは、Postgres の一時的なログ先行書き込みを保存するために残されたスペースを追跡します。Heroku Postgres は、継続的保護​の一環として Postgres のログ先行書き込みを使用します。データベースの変更は、データベースのデータファイルの前にログ先行書き込みに書き込まれます。

WAL の生成率が WAL のアーカイブ率を超えると、WAL のボリュームが完全にいっぱいになるリスクがあります。これによりデータベースがシャットダウンされ、データが失われるリスクがあります。

ボリュームの使用率が 75% に達すると、Heroku はデータベース接続制限の調整を自動的に開始し、使用率が 95% に達すると最終的にすべての接続を終了します。接続制限が呼び出される前に通知されるように、この数が 60% に達した場合のアラートを設定します。

詳細と修復戦略については、Postgres のログ先行書き込みの使用法​を参照してください。

ログ記録ツールをインストールする

データベースシステムのメトリクスを補足するために、Heroku Postgres はメッセージをアプリのログストリーム​に記録します。Heroku は長期間ログを保存しない​ため、ログ履歴を保持するための外部ツールが必要になります。ログ記録アドオンをインストールして、ログ記録ツール​を設定します。

インシデント中、ログは問題を調査して実行時間の長いクエリを特定するのに役立ちます。インシデントの後は、根本原因分析に使用できます。

ログ​のカテゴリには、さまざまな機能と保持期間を持ついくつかのログ記録ツールが含まれています。

Heroku Postgres のログからのイベントは、postgres​ プロセスをフィルタリングすることで分離できます。例と詳細は、Heroku Postgres のログ文とよくあるエラーを理解する​の記事を参照してください。どのような種類のメッセージが定期的にログに記録され、どのメッセージがアプリケーションにとって異常であるかを理解するために、ログに精通することが重要です。ログは、実行時間の長いクエリ​やロック​を見つけるための非常に貴重なツールです。

pg-extras をインストールする

Postgres は、パフォーマンスの問題を分析するために使用できるクエリとテーブルに関する統計情報を自動的に収集します。Heroku の pg-extras CLI プラグイン​は、これらの統計を解釈するためのショートカットを提供します。

データベース統計を定期的に確認すると、潜在的な問題が問題になる前に特定できます。

pg-extras CLI プラグイン、設定手順、およびコマンドリファレンスは、GitHub リポジトリ​で確認できます。

未使用のインデックス、大きなテーブルとインデックス、バキューム統計、肥大化統計、外れ値クエリなど、改善の機会を定期的に確認してください。

さらに、Heroku CLI​ に含まれている pg:diagnose​ コマンドは、複数のチェックを実行し、リアルタイムのアクティビティと収集された統計に基づいて、潜在的な問題を示すレポートを生成します。

アプリケーションの監視

データベースの監視は、アプリ全体の監視の一部にすぎません。「Monitoring Your App on Heroku​」(Heroku でのアプリの監視) のガイダンスを参照してください。