DevOpsGuru for RDS の主要な概念 - Amazon DevOps Guru
事前対応型インサイト事後対応型インサイトレコメンデーション

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

DevOpsGuru for RDS の主要な概念

インサイトは、運用アプリケーションで異常または問題のある動作を検出すると DevOpsGuru によって生成されます。インサイトには、リソースの異常が含まれます。異常は、 DevOpsGru によって検出された 1 つ以上の関連メトリクスのうち、予期しないものまたは異常なものを表します。

インサイトの重要度は、高、中, または低です。インサイトの重要度は、インサイトの作成に寄与した最も重要な異常によって決定されます。例えば、インサイト AWS-ECS_MemoryUtilization_and_others に重要度の低い異常と重要度の高い異常が含まれている場合、インサイトの全体的な重要度は高くなります。

Amazon RDS DB インスタンスで Performance Insights がオンになっている場合、RDS の DevOpsGuru は、これらのインスタンスの異常に関する詳細な分析と推奨事項を提供します。異常を識別するために、RDS の DevOpsGuru はデータベースメトリクス値のベースラインを開発します。RDS の DevOpsGuru は、現在のメトリクス値を過去のベースラインと比較します。

事前対応型インサイト

事前対応型インサイトでは、問題のある動作を発生前に知ることができます。これには異常と共に、問題が大きくなる前に問題に対処するのに役立つレコメンデーションと、関連指標が含まれています。

各事前対応型インサイトページには、1 つの異常に関する詳細が表示されます。

事後対応型インサイト

事後対応型インサイトは、異常な動作を発生時に識別します。これには、現在の問題を理解して対処するのに役立つレコメンデーション、関連するメトリクス、およびイベントを含む異常が含まれています。

因果異常

因果異常は、事後対応型インサイト内のトップレベルの異常です。 DevOpsGuru コンソールの異常詳細ページのプライマリメトリクスとして表示されます。データベース負荷 (DB 負荷） は、RDS の DevOpsGuru の因果異常です。例えば、インサイト AWS-ECS_MemoryUtilization_and_others にはいくつかのメトリクス異常があり、そのうちの 1 つはリソース AWS/RDS のデータベースロード (DB ロード） です。

インサイト内では、異常データベース負荷 (DB 負荷) は、複数の Amazon RDS DB インスタンスで発生することがあります。異常の重要度は、DB インスタンスごとに異なる可能性があります。例えば、1 つの DB インスタンスの重要度が高で、他の DB インスタンスの重要度が低である場合があります。コンソールは、最も高い重要度の異常にデフォルト設定されます。

コンテキスト異常

コンテキスト異常は、事後対応型インサイトに関連するデータベースロード (DB ロード)での所見です。 DevOpsGuru コンソールの異常詳細ページの関連メトリクスセクションに表示されます。各コンテキスト異常は、調査が必要な特定の Amazon RDS パフォーマンス上の問題を記述しています。例えば、因果異常には、次のようなコンテキスト異常が含まれることがあります。

  • CPU 容量の超過 — CPU 実行キューまたは CPU 使用率が通常を上回っています。

  • データベースメモリ不足 — プロセスに十分なメモリがありません。

  • データベース接続のスパイク — データベース接続の数が通常を超えています。

レコメンデーション

各インサイトには、少なくとも 1 つの推奨アクションがあります。次の例は、 DevOpsGuru for RDS によって生成されるレコメンデーションです。

  • SQL ID list_of_ids をチューニングして CPU 使用量を減らすか、インスタンスタイプをアップグレードして CPU 容量を増やします。

  • 現在のデータベース接続の関連スパイクを確認します。新しいデータベース接続の頻繁な動的割り当てを回避するために、アプリケーションプールの設定を調整することを検討してください。

  • メモリ内ソートや大きな結合など、過剰なメモリ操作を実行する SQL ステートメントを探します。

  • SQL ID (list_of_ids) の高い I/O 使用量を調査します。

  • 大量の一時データを作成するステートメント (大規模なソートを実行するステートメントや大きな一時テーブルを使用するステートメントなど) がないかどうかをチェックします。

  • アプリケーションをチェックして、データベースワークロードの増加の原因を確認します。

  • MySQL のパフォーマンススキーマを有効にすることを検討してください。

  • 実行時間の長いトランザクションをチェックし、コミットまたはロールバックで終了します。

  • 指定した時間を超えて「トランザクションのアイドル」状態にあるセッションを終了するように、idle_in_transaction_session_timeout パラメーターを設定します。