

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# DB インスタンスのモニタリング
<a name="db-instance-monitoring"></a>

[https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.html)とは、Amazon RDS の基本的な構成要素であり、クラウド上で動作する独立したデータベース環境でもあります。MySQL および MariaDB データベースの DB インスタンスは、MySQL サーバーとも呼ばれる [mysqld](https://dev.mysql.com/doc/refman/8.0/en/mysqld.html) プログラムで、これは、SQL パーサー、クエリオプティマイザ、スレッド/接続ハンドラー、システム変数とステータス変数、1 つ以上のプラガブルストレージエンジンといった、複数のスレッドやコンポーネントで構成されます。ストレージエンジンはそれぞれ、特殊なユースケースに対応できるよう設計されています。デフォルトの推奨ストレージエンジンは [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-architecture.html) です。InnoDB は、汎用的なトランザクションリレーショナルデータベースエンジンであり、原子性、一貫性、独立性、耐久性 (ACID) モデルに準拠しています。また、[インメモリ構造](https://dev.mysql.com/doc/refman/8.0/en/innodb-in-memory-structures.html) (バッファプール、変更バッファ、アダプティブハッシュインデックス、ログバッファ) と[オンディスク構造](https://dev.mysql.com/doc/refman/8.0/en/innodb-on-disk-structures.html) (テーブルスペース、テーブル、インデックス、UNDO ログ、REDO ログ、二重書き込みバッファファイル) を特徴としています。データベースを ACID モデルに厳密に準拠させるために、InnoDB ストレージエンジンには、トランザクション、コミット、ロールバック、クラッシュリカバリ、行レベルのロック、マルチバージョン同時実行制御 (MVCC) といった[多数の機能が実装されています](https://dev.mysql.com/doc/refman/8.0/en/mysql-acid.html)。

DB インスタンスのこうしたすべての内部コンポーネントが連携して動作することで、データの可用性、整合性、セキュリティが想定どおりのパフォーマンスレベルで維持されます。ワークロードによっては、各コンポーネントと機能が、CPU、メモリ、ネットワーク、ストレージサブシステムなどのリソースに負荷をかける場合があります。特定のリソース需要が急増し、プロビジョニングした容量や、そのリソース (設定パラメータまたはソフトウェア設計によって要求される) のソフトウェア制限を超えると、DB インスタンスのパフォーマンスが低下したり、完全に利用できない、あるいは破損という状態になったりする可能性があります。したがって、これらの内部コンポーネントを測定およびモニタリングして、定義済みのベースライン値と比較し、モニタリングした値が期待値から逸脱した場合にアラートを生成することがきわめて重要です。

前述のように、さまざまな[ツール](monitoring-tools.md)を使用して、MySQL インスタンスと MariaDB インスタンスをモニタリングできます。モニタリングとアラートには Amazon RDS Performance Insights と CloudWatch のツールを使用すると良いでしょう。なぜなら、これらを Amazon RDS と連携させると、高解像度のメトリクスを収集して、最新のパフォーマンス情報をほぼリアルタイムで取得し、アラームを生成できるからです。

どのモニタリングツールを選択するかに関係なく、MySQL と MariaDB DB のインスタンスでは、[パフォーマンススキーマを有効にする](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.EnableMySQL.html)ことをお勧めします。[パフォーマンススキーマ](https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html)は、MySQL サーバー (DB インスタンス) のオペレーションを低レベルでモニタリングするオプション機能であり、データベース全体のパフォーマンスへの影響を最小化できるように設計されています。この機能を管理するには、`performance_schema` パラメータを使用します。このパラメータはオプションですが、SQL ごとの高解像度 (1 秒) メトリクス、アクティブセッションのメトリクス、待機イベント、その他の詳細な低レベルモニタリング情報を Amazon RDS Performance Insights で収集する場合は、これを使用する必要があります。

**セクション**
+ [DB インスタンスの Performance Insights メトリクス](db-instance-performance-insights.md)
+ [DB インスタンスの CloudWatch メトリクス](db-instance-cloudwatch-metrics.md)
+ [Performance Insights のメトリクスを CloudWatch に発行する](publishing-performance-insights-to-cloudwatch.md)

# DB インスタンスの Performance Insights メトリクス
<a name="db-instance-performance-insights"></a>

Performance Insights では、このセクションで説明するように、さまざまなタイプのメトリクスをモニタリングできます。

## データベース負荷
<a name="dbload"></a>

データベースロード (`DBLoad`) は、データベース内のアクティビティレベルを測定する Performance Insights の主要なメトリクスであり、毎秒収集され、Amazon CloudWatch に自動的に発行されます。このメトリクスは、平均アクティブセッション (AAS) で生じている、DB インスタンスのアクティビティを表すもので、AAS とは、SQL クエリを同時実行しているセッションの数を意味します。また、`DBLoad` メトリクスは、その解釈に、待機、SQL、ホスト、ユーザー、データベースの 5 つのディメンションのいずれかを使用するという点が、他の時系列メトリクスとは異なっています。これらのディメンションは、`DBLoad` メトリクスのサブカテゴリであり、データベース負荷のさまざまな特性を表すために、*カテゴリごとにスライス*として使用できます。データベース負荷の計算方法については、Amazon RDS ドキュメントの「[データベース負荷](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.Overview.ActiveSessions.html)」で詳しくご覧いただけます。

次のスクリーンショットは、Performance Insights ツールを示しています。

![\[Performance Insights ツールの [データベース負荷]\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/database-load.png)


## ディメンション
<a name="dimensions"></a>
+ *待機イベント*とは、データベースセッションの処理を続行するために、リソース処理や別のオペレーションが完了するまで待機している状態を指します。`SELECT * FROM big_table` のような SQL ステートメントを実行し、そのテーブルが割り当てた InnoDB バッファプールよりもはるかに大きい場合、セッションが、`wait/io/file/innodb/innodb_data_file` 待機イベントによって待機状態になる可能性が非常に高くなります。これらのイベントはデータファイルの物理 I/O オペレーションが原因で生じます。データベースをモニタリングする場合、待機イベントは、パフォーマンスのボトルネックの可能性を示すという点で重要なディメンションとなります。このイベントは、セッション内で実行中の SQL ステートメント処理において、どのようなリソースやとオペレーションに対し、非常に長い時間待機状態になっているかを示すものです。例えば、`wait/synch/mutex/innodb/trx_sys_mutex` イベントは多数のトランザクションを持つデータベースアクティビティが多い場合に発生し、`wait/synch/mutex/innodb/buf_pool_mutex` イベントは、特定のスレッド処理において、メモリ内ページに排他的にアクセスできるよう InnoDB バッファプールがロックされている場合に発生します。MySQL と MariaDB のすべての待機イベントに関する情報については、MySQL ドキュメントの「[イベント待機サマリーテーブル](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-wait-summary-tables.html)」を参照してください。計測名の解釈方法については、MySQL ドキュメントの「[パフォーマンススキーマインストゥルメント命名規則](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-instrument-naming.html)」を参照してください。
+ *SQL* は、データベースの総ロードに最も寄与している SQL ステートメントを示しています。Amazon RDS Performance Insights の**データベース負荷**チャートにある**上位ディメンション**テーブルはインタラクティブに操作できます。**[待機別の負荷 (AAS)]** 列のバーをクリックすると、SQL ステートメントに関連付けられた待機イベントについて詳細なリストを取得できます。そのリストで SQL ステートメントを選択すると、関連する待機イベントが **[データベース負荷]** チャートに、SQL ステートメントテキストが **[SQL テキスト]** セクションに表示されます。SQL 統計は、**[上位ディメンション]** テーブルの右側に表示されます。
+ *ホスト*は、接続済みクライアントのホスト名を示しています。このディメンションにより、どのクライアントホストが非常に多くの負荷をデータベースにかけているかを特定しやすくなります。
+ *ユーザー*を使用すると、データベースにログインしているユーザーごとに DB 負荷をグループ化できます。
+ *データベース*を使用すると、クライアントが接続しているデータベースの名前で DB 負荷をグループ化できます。

## カウンターメトリクス
<a name="counter-metrics"></a>

カウンターメトリクスは、累積メトリクスであり、これによって、DB インスタンスの再起動時にのみ値を増加させたり、ゼロにリセットしたりできます。カウンターメトリクスの値を以前の値に減らすことはできません。これらのメトリクスは、単調に増加する 1 つのカウンターを表すものです。
+ [ネイティブカウンター](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights_Counters.html#USER_PerfInsights_Counters.MySQL.Native)とは、Amazon RDS ではなく、データベースエンジンによって定義されるメトリクスです。例えば、次のようになります。
  + `SQL.Innodb_rows_inserted` は、InnoDB テーブルに挿入された行数を表します。
  + `SQL.Select_scan` は、最初のテーブルのフルスキャンを完了した結合の数を表します。
  + `Cache.Innodb_buffer_pool_reads` は、InnoDB エンジンがバッファプールから読み取れず、ディスクから直接読み取る必要があった論理読み取りの数を表します。
  + `Cache.Innodb_buffer_pool_read_requests` は、論理読み取りリクエストの数を表します。

  すべてのネイティブメトリックの定義については、MySQL ドキュメントの「[サーバーステータス可変](https://dev.mysql.com/doc/refman/8.0/en/server-status-variables.html)」を参照してください。
+ [非ネイティブカウンター](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights_Counters.html#USER_PerfInsights_Counters.MySQL.NonNative)は、Amazon RDS によって定義されています。これらのメトリクスを取得するには、特定のクエリを使用するか、計算に 2 つ以上のネイティブメトリクスを使用します。非ネイティブカウンターメトリクスにより、レイテンシー、比率、ヒット率を表すことができます。例えば、次のようになります。
  + `Cache.innoDB_buffer_pool_hits` は、InnoDB がディスクを使用せずにバッファプールから取得できる読み取りオペレーションの数を表しています。これは、ネイティブカウンターメトリクスに基づいて、次のように計算されます。

    ```
    db.Cache.Innodb_buffer_pool_read_requests - db.Cache.Innodb_buffer_pool_reads
    ```
  + `IO.innoDB_datafile_writes_to_disk` は、InnoDB データファイルによる、ディスクへの書き込みオペレーションの数を表しています。データファイルへのオペレーションのみをキャプチャするもので、二重書き込みや REDO ログの書き込みオペレーションはキャプチャされません。これは、次のように計算されます:

    ```
    db.IO.Innodb_data_writes - db.IO.Innodb_log_writes - db.IO.Innodb_dblwr_writes
    ```

DB インスタンスメトリクスは、Performance Insights ダッシュボードで直接視覚化できます。次の図に示すように、**[メトリクスを管理]** を選択して、**[データベースメトリクス]** タブを選択し、目的のメトリクスを選択します。

![\[Performance Insights で DB インスタンスメトリクスを選択する\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/selecting-metrics.png)


**[グラフを更新]** ボタンを選択すると、次の図に示すように、選択したメトリクスが表示されます。

![\[Performance Insights で DB インスタンスメトリクスを表示する\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/selecting-metrics-results.png)


## SQL 統計
<a name="sql-stats"></a>

Performance Insights では、クエリを実行している 1 秒ごと、および SQL コールごとに、SQL クエリに関するパフォーマンス関連メトリクスを収集します。一般的には、ステートメントおよびダイジェストレベルで [SQL 統計](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.MySQL.html)を収集しますが、MariaDB および MySQL DB インスタンスの場合、ダイジェストレベルでのみ収集します。
+ ダイジェスト統計は、複合メトリクスであり、パターンが同じであっても最終的には異なるリテラル値を持つすべてのクエリで構成されます。ダイジェストでは、次のように、特定のリテラル値を変数に置き換えます。

  ```
  SELECT department_id, department_name FROM departments WHERE location_id = ?
  ```
+ ダイジェストした SQL ステートメントごとに *1 秒*あたりの統計を表すメトリクスも用意されています。例えば、`sql_tokenized.stats.count_star_per_sec` は、1 秒あたりの呼び出し回数 (SQL ステートメントが 1 秒あたりに実行された回数) を表します。
+ Performance Insights は、各 SQL ステートメントの*呼び出しごと*の統計情報を得られるメトリクスも備えています。例えば、`sql_tokenized.stats.sum_timer_wait_per_call` は、SQL ステートメント 1 回あたりの平均レイテンシーをミリ秒単位で示しています。

SQL 統計情報は、Performance Insights ダッシュボードの **[上位ディメンション]** テーブルにある **[上位 SQL]** タブで確認できます。

![\[SQL 統計\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/amazon-rds-monitoring-alerting/images/sql-stats.png)


# DB インスタンスの CloudWatch メトリクス
<a name="db-instance-cloudwatch-metrics"></a>

Amazon CloudWatch には、Amazon RDS によって自動的に公開されるメトリクスも用意されています。`AWS/RDS` 名前空間に存在するメトリクスは、*インスタンスレベルのメトリクス*ですが、[mysqld](https://dev.mysql.com/doc/refman/8.0/en/mysqld.html) プロセスにおける厳密な意味での DB インスタンスではなく、Amazon RDS (サービス) のインスタンス (クラウドで稼働する独立したデータベース環境) を指します。したがって、こうした[デフォルトのメトリクス](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-metrics.html)のほとんどは、用語の厳密な定義において、OS メトリクスのカテゴリに分類されます。その例として、`CPUUtilization`、`WriteIOPS`、`SwapUsage` などが挙げられます。ただし、MariaDB と MySQL に適用される次のような DB インスタンスメトリクスがあります。
+ `BinLogDiskUsage` – バイナリログが占めるディスク容量。
+ `DatabaseConnections` - DB インスタンスへのクライアントネットワーク接続の数。
+ `ReplicaLag` – リードレプリカ DB インスタンスとソース DB インスタンス間で生じるタイムラグ。

# Performance Insights のメトリクスを CloudWatch に発行する
<a name="publishing-performance-insights-to-cloudwatch"></a>

Amazon RDS Performance Insights は、ほとんどの DB インスタンスのメトリクスとディメンションをモニタリングし、 AWS マネジメントコンソールの [Performance Insights ダッシュボード](https://console.aws.amazon.com/rds/home#performance-insights-v20206:)から利用できるようにします。このダッシュボードは、データベースのトラブルシューティングと根本原因の分析に適していますが、パフォーマンス関連メトリクスのアラームを Performance Insights で作成することはできません。Performance Insights メトリクスに基づいてアラームを作成する場合は、それらのメトリクスが CloudWatch に存在する必要があります。

Performance Insights により、[メトリクスが CloudWatch に自動的に公開されます](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights.Cloudwatch.html)。Performance Insights からも同じデータを照会できますが、CloudWatch にメトリクスが存在すると、CloudWatch アラームの追加や既存の CloudWatch ダッシュボードへのメトリクスの追加が容易になります。[カウンター](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PerfInsights_Counters.html)は、オペレーティングシステムとデータベースのパフォーマンスメトリクスであり、その例には、`os.memory.free` や `db.Locks.Innodb_row_lock_time` などがあります。OS メトリクスの収集は、拡張モニタリングの設定によって異なります。拡張モニタリングがオフになっている場合、OS メトリックは 1 分ごとに収集されます。拡張モニタリングがオンになっている場合、OS メトリクスは、選択した期間を対象に収集されます。詳細については、Amazon RDS ドキュメントの「[拡張モニタリングのオンとオフを切り替える](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.Enabling.html#USER_Monitoring.OS.Enabling.Procedure)」を参照してください。

Performance Insights を使用すると、[DB インスタンス用に事前設定した、またはカスタマイズしたメトリクスダッシュボードを CloudWatch にエクスポート](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PI_metrics_export_CW.html)できます。メトリクスダッシュボードを新しいダッシュボードとしてエクスポートするか、それらを既存の CloudWatch ダッシュボードに追加できます。Performance Insights メトリクスダッシュボードを CloudWatch ダッシュボードにエクスポートすると、システムの状態を包括的な統一ビューで確認できます。具体的には、EC2 インスタンス、Amazon Elastic File System (Amazon EFS) リソース、Elastic Load Balancing (ELB) リソースといった、システム内の各種リソースに関連付けたメトリクスの概要に加え、DB インスタンスのメトリクスも取得することが可能です。

また、CloudWatch `DB_PERF_INSIGHTS` メトリクス数学関数を使用すると、CloudWatch の Performance Insights メトリクスに基づいて、アラームとグラフをクエリおよび作成できます。Performance Insights メトリクスにアラームを作成するには、[CloudWatch ドキュメント](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_alarm_database_performance_insights.html)の手順に従います。例えば、DB インスタンス内のアクティブなトランザクションの合計が特定のしきい値に達したときにアラームをトリガーする場合は、そのページの手順に従って、`DB_PERF_INSIGHTS` 数式を使用し、**[適用]** を選択します。

```
DB_PERF_INSIGHTS('RDS', 'db-BQ2TPYY7HG2GDFC7APMB3BVB3M', 'db.Transactions.active_transactions.avg')
```

この式の `db-BQ2TPYY7HG2GDFC7APMB3BVB3M` は DB インスタンスのリソース ID です。期間 (1 分など) と条件 (1000 より大きいなど) を指定します。アラームの作成を完了するには、アラームアクションを設定して、名前と説明を追加します。その後、アラームをプレビューし作成します。