# Amazon CloudWatch メトリクスを使用して Aurora PostgreSQL のリソース使用状況を分析する
<a name="AuroraPostgreSQL_AnayzeResourceUsage"></a>

Aurora はメトリクスデータを 1 分間隔で CloudWatch に自動的に送信します。CloudWatch メトリクスを使用して Aurora PostgreSQL のリソース使用状況を分析することができます。メトリクスを使用して、ネットワークのスループットとネットワーク使用量を評価できます。

## CloudWatch によるネットワークスループットの評価
<a name="AuroraPostgreSQL_AnayzeResourceUsage.EvaluateNetworkThroughput"></a>

システム使用量がインスタンスタイプのリソース限界に近づくと、処理が遅くなることがあります。CloudWatch の **[Logs Insights]** (ログのインサイト) を使用して、ストレージリソースの使用状況をモニタリングし、十分なリソースが使用可能であることを確認できます。必要に応じて、DB インスタンスをより大きなインスタンスクラスに変更できます。

 Aurora ストレージの処理は、次の理由で遅くなることがあります。
+ クライアントと DB インスタンス間のネットワーク帯域幅が不十分です。
+ ストレージサブシステムへのネットワーク帯域幅が不十分です。
+ ご使用のインスタンスタイプでは大きいワークロード。

CloudWatch の **[Logs Insights]** (ログのインサイト) にクエリを実行して、Aurora ストレージリソースの使用状況のグラフを生成し、リソースを監視できます。グラフには CPU 使用率とメトリクスが表示され、より大きなインスタンスサイズにスケールアップするかどうかの判断に役立ちます。CloudWatch **[Logs Insights]** (ログのインサイト) のクエリ構文の詳細については、「[CloudWatch Logs Insights クエリ構文](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html)」を参照してください。

CloudWatch を使用するには、Aurora PostgreSQL ログファイルを CloudWatch にエクスポートする必要があります。既存のクラスターを変更して、ログを CloudWatch にエクスポートすることもできます。 ログを CloudWatch にエクスポートする方法については、「[Amazon CloudWatch にログを発行するオプションをオンにする](AuroraPostgreSQL.CloudWatch.Publishing.md)」を参照してください。

CloudWatch **[Logs Insights]** (ログのインサイト) にクエリを実行するには、DB インスタンスの **[Resource ID]** (リソース ID) が必要です。**[Resource ID]** (リソース ID) は、コンソールの **[Configuration]** (設定) タブで確認できます。

![\[Aurora コンソールの設定タブのリソース ID。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/Aur_PG_resource_id.png)


**ログファイルにリソースストレージメトリクスを照会するには:**

1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。

   CloudWatch 概要のホームページが表示されます。

1. 必要に応じて AWS リージョン を変更します。ナビゲーションバーで、AWS リソースがある AWS リージョン を選択します。詳細については、「[リージョンとエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html)」を参照してください。

1. ナビゲーションペインで、**[Logs]** (ログ)、**[Logs Insights]** (ログのインサイト) の順に選択します。

   **[Logs Insights**] (ログのインサイト) ページが表示されます。

1. ドロップダウンリストから、分析するログファイルを選択します。

1. フィールドに次のクエリを入力します。`<resource ID>` を DB クラスターのリソース ID に置き換えてください。

   `filter @logStream = <resource ID> | parse @message "\"Aurora Storage Daemon\"*memoryUsedPc\":*,\"cpuUsedPc\":*," as a,memoryUsedPc,cpuUsedPc | display memoryUsedPc,cpuUsedPc #| stats avg(xcpu) as avgCpu by bin(5m) | limit 10000`

1. **[Run query]** (クエリを実行) をクリックします。

   ストレージ使用率グラフが表示されます。

   次の画像は、**[Logs Insights]** (ログのインサイト) ページとグラフ表示を示しています。  
![\[Logs Insights ページとグラフ表示。\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/AurPG-CW-LogsInsights.png)

## CloudWatch メトリクスで Aurora PostgreSQL の DB インスタンスの使用量を評価する
<a name="AuroraPostgreSQL_AnayzeResourceUsage.EvaluateInstanceUsage"></a>

CloudWatch メトリクスを使用して、インスタンスのスループットを監視し、インスタンスクラスがアプリケーションに十分なリソースを提供しているかどうかを確認できます。DB インスタンスクラスの制限については、[Aurora 用の DB インスタンスクラスのハードウェア仕様](Concepts.DBInstanceClass.Summary.md) に移動し、DB インスタンスクラスの仕様を確認して、ネットワークパフォーマンスを確認してください。

DB インスタンスの使用量がインスタンスクラスの限界に近い場合、パフォーマンスが低下し始める可能性があります。CloudWatch メトリクスによってこの状況を確認できるので、より大きなインスタンスクラスへの手動スケールアップを計画できます。

以下の CloudWatch メトリクス値を組み合わせて、インスタンスクラスの限界に近づいているかどうかを確認します。
+ **NetworkThroughput** - Aurora DB クラスター内の各インスタンスについて、各クライアントによって送受信されたネットワークスループットの量。このスループット値には、DB クラスターとクラスターボリューム内のインスタンス間のネットワークトラフィックは含まれません。
+ **StorageNetworkThroughput** – Aurora DB クラスター内の各インスタンスによって Aurora ストレージサブシステムとの間で送受信されたネットワークスループットの量。

**NetworkThroughput** を **StorageNetworkThroughput** に加えると、Aurora DB クラスター内の各インスタンスによって Aurora ストレージサブシステムとの間で送受信されたネットワークスループットになります。インスタンスのインスタンスクラス限界は、この 2 つのメトリクスの合計よりも大きい必要があります。

 以下のメトリクスを使用して、送受信時のクライアントアプリケーションからのネットワークトラフィックの詳細を確認できます。
+ **NetworkReceiveThroughput** – Aurora PostgreSQL DB クラスター内の各インスタンスがクライアントから受信したネットワークスループットの量。 DB クラスターとクラスターボリューム内のインスタンス間のネットワークトラフィックは、このスループットに含まれません。
+ **NetworkTransmitThroughput** – Aurora DB クラスター内の各インスタンスが各クライアントに送信したネットワークスループットの量。 DB クラスターとクラスターボリューム内のインスタンス間のネットワークトラフィックは、このスループットに含まれません。
+ **StorageNetworkReceiveThroughput** – DB クラスター内の各インスタンスが Aurora ストレージサブシステムから受信したネットワークスループットの量。
+ **StorageNetworkTransmitThroughput** – DB クラスター内の各インスタンスが Aurora ストレージサブシステムに送信したネットワークスループットの量。

これらすべてのメトリクスを合計して、ネットワーク使用量とインスタンスクラスの限界との比較を評価します。インスタンスクラス限界は、これらのメトリクスの合計よりも大きい必要があります。

ネットワーク限界とストレージの CPU 使用率は相互に関係しています。ネットワークのスループットが増加すると、CPU 使用率も増加します。CPU とネットワークの使用状況を監視すると、リソースがどのくらい枯渇しているのか、またなぜ枯渇しているのかについての情報が得られます。

ネットワークの使用量を最小限に抑えるには、次のことを検討してください。
+ より大きなインスタンスクラスを使用します。
+ `pg_partman` パーティショニング戦略を使用します。
+ 書き込みリクエストをバッチに分割して、トランザクション全体を減らします。
+ 読み取り専用ワークロードを読み取り専用インスタンスに転送します。
+ 未使用のインデックスをすべて削除します。
+ 膨張したオブジェクトと VACUUM をチェックします。膨張がひどい場合は、PostgreSQL 拡張機能 `pg_repack` を使用します。`pg_repack` の詳細については、「[最小限のロックで PostgreSQL データベース内のテーブルを再編成する](https://reorg.github.io/pg_repack/)」を参照してください。