

# Amazon Aurora クラスターでのメトリクスのモニタリング
<a name="MonitoringAurora"></a>

Amazon Aurora は、レプリケートされたデータベースサーバーのクラスターを使用します。通常、Aurora クラスターをモニタリングするには、複数の DB インスタンスの状態を確認する必要があります。インスタンスには、主に書き込みオペレーションか、読み取り専用オペレーション、またはこれらの組み合わせを処理する特殊なロールがあります。また、*レプリケーションラグ*を測定することによって、クラスターの全体的な状態をモニタリングします。これは、1 つの DB インスタンスによって加えられた変更が他のインスタンスで使用可能になるまでの時間です。

**Topics**
+ [モニタリング計画](#MonitoringOverview.plan)
+ [パフォーマンスのベースライン](#MonitoringOverview.baseline)
+ [パフォーマンスガイドライン](#MonitoringOverview.guidelines)
+ [Amazon Aurora のモニタリングツール](MonitoringOverview.md)
+ [クラスターのステータスの表示](accessing-monitoring.md)
+ [Amazon Aurora の推奨事項](monitoring-recommendations.md)
+ [Amazon RDS コンソールでのメトリクスの表示](USER_Monitoring.md)
+ [Performance Insights ダッシュボードを使用して組み合わせたメトリクスを表示する](Viewing_Unifiedmetrics.md)
+ [Amazon CloudWatch を使用した Amazon Aurora メトリクスのモニタリング](monitoring-cloudwatch.md)
+ [CloudWatch Database Insights による Amazon Aurora データベースのモニタリング](USER_DatabaseInsights.md)
+ [Amazon Aurora での Performance Insights を使用したDB 負荷のモニタリング](USER_PerfInsights.md)
+ [Amazon DevOps Guru for Amazon RDS で Aurora のパフォーマンスの異常を分析する](devops-guru-for-rds.md)
+ [拡張モニタリングを使用した OS メトリクスのモニタリング](USER_Monitoring.OS.md)
+ [Amazon Aurora のメトリクスリファレンス](metrics-reference.md)

## モニタリング計画
<a name="MonitoringOverview.plan"></a>

Amazon Aurora のモニタリングをスタートする前に、モニタリングプランを作成します。この計画で、以下の質問に答えるようにします。
+ どのような目的でモニタリングしますか?
+ どのリソースをモニタリングしますか?
+ どのくらいの頻度でこれらのリソースをモニタリングしますか?
+ どのモニタリングツールを使用しますか?
+ 誰がモニタリングタスクを実行しますか?
+ 問題が発生したときに誰に通知しますか?

## パフォーマンスのベースライン
<a name="MonitoringOverview.baseline"></a>

モニタリング目標を達成するには、ベースラインを確立する必要があります。これを行うには、Amazon Aurora 環境で負荷条件と時期をさまざまに変えてパフォーマンスを測定します。次のようなメトリクスをモニタリングできます。
+ ネットワークスループット
+ クライアント接続
+ 読み取り、書き込み、メタデータのいずれかのオペレーションの I/O
+ DB インスタンスのバーストクレジットバランス

Amazon Aurora の履歴パフォーマンスデータを保存することをお勧めします。保存したデータを使用して、現在のパフォーマンスを過去の傾向と比較できます。また、正常なパフォーマンスパターンを異常から区別し、問題に対処するための方法を考案することもできます。

## パフォーマンスガイドライン
<a name="MonitoringOverview.guidelines"></a>

一般的に、パフォーマンスメトリクスの許容値は、ベースラインに対してアプリケーションの現在の動作によって異なります。ベースラインからの一貫した差異またはトレンドになっている差異を調べます。多くの場合、次のメトリクスがパフォーマンスの問題の原因を示しています。
+  **CPU または RAM の高消費量** - CPU または RAM の消費量が大きい値になっていても、それは妥当である場合があります。ただし、アプリケーションの目標 (スループット、同時実行数など) に沿った想定値であることが前提です。
+  **ディスクスペースの消費量 - ** 使用されているディスクスペースが一貫して合計ディスクスペースの 85% 以上である場合は、ディスクスペースの消費量を調べます。インスタンスからデータを削除するか、別のシステムにデータをアーカイブして、スペースを解放できるかどうかを確認します。
+  **ネットワークトラフィック** - ネットワークトラフィックについてシステム管理者に問い合わせて、ドメインネットワークとインターネット接続に対する想定スループットを把握します。スループットが一貫して想定よりも低い場合は、ネットワークトラフィックを調べます。
+  **データベース接続数** - ユーザー接続数が多いことが、インスタンスのパフォーマンスが下がっていること、応答時間が長くなっていることに関連しているとわかった場合、データベース接続数を制限することを検討します。DB インスタンスの最適なユーザー接続数は、インスタンスのクラスと実行中のオペレーションの複雑さによって異なります。データベース接続数を確認するには、`User Connections` パラメータが 0 (無制限) 以外の値に設定されているパラメータグループと DB インスタンスを関連付けます。既存のパラメータグループを使用するか、新しいパラメータグループを作成できます。詳細については、「[Amazon Aurora のパラメータグループ](USER_WorkingWithParamGroups.md)」を参照してください。
+  **IOPS メトリクス - ** IOPS メトリクスの想定値はディスクの仕様とサーバーの設定によって異なるため、ベースラインを使用して一般的な値を把握します。値とベースラインとの差が一貫しているかどうかを調べます。最適な IOPS パフォーマンスを得るには、読み取りおよび書き込みオペレーションが最小限になるように、一般的な作業セットがメモリに収まることを確認してください。

確立したベースラインをパフォーマンスが下回ると、場合によって、ワークロードに対してデータベースの可用性を最適化するために変更を加える必要があります。例えば、DB インスタンスのインスタンスクラスの変更が必要になる場合があります。または、クライアントで使用できる DB インスタンスとリードレプリカの数の変更が必要になる場合があります。