翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
データベースのパフォーマンスチューニングの主な概念
DevOpsGuru for RDS は、いくつかの主要なパフォーマンス概念に精通していることを前提としています。これらの概念の詳細については、Amazon Aurora ユーザーガイドの「Performance Insights の概要」または Amazon RDS ユーザーガイドの「Performance Insights の概要」を参照してください。
メトリクス
メトリクスは、時間順に並んだ一連のデータポイントを表します。メトリクスはモニターリング対象の変数と考え、データポイントは時間の経過と共に変数の値を表します。Amazon RDS には、DB インスタンスが実行されているデータベースとオペレーティングシステム (OS) のメトリクスをリアルタイムで提供します。Amazon RDS DB インスタンスのすべてのシステムメトリクスとプロセス情報を Amazon RDS コンソールに表示できます。 DevOpsGuru for RDS は、これらのメトリクスの一部をモニタリングし、インサイトを提供します。詳細については、「Amazon Aurora クラスターのメトリクスのモニタリング」または「Amazon リレーショナルデータベース サービス インスタンスのメトリクスのモニタリング」を参照してください。
問題の検出
DevOpsGuru for RDS は、データベースとオペレーティングシステム (OS) のメトリクスを使用して、重大なデータベースパフォーマンスの問題が差し迫っているか、進行中かを検出します。 DevOpsGuru for RDS の問題検出が機能するには、主に 2 つの方法があります。
しきい値を使用する
異常を使用する
しきい値に関する問題の検知
しきい値は、監視対象のメトリクスが評価される境界値です。しきい値は、通常の動作と潜在的に問題のある動作を区別するメトリクスグラフ上の水平線と考えることができます。 DevOpsGuru for RDS は特定のメトリクスをモニタリングし、指定されたリソースで潜在的に問題と見なされるレベルを分析してしきい値を作成します。次に、RDS の DevOpsGuru は、新しいメトリクス値が一定の期間にわたって指定されたしきい値を超えた場合に DevOps、Guru コンソールにインサイトを作成します。インサイトには、将来のデータベースのパフォーマンスへの影響を防ぐためのレコメンデーションが含まれています。
例えば、RDS の DevOpsGuru は 15 分間のディスクを使用して一時テーブルの数をモニタリングし、ディスク/秒を使用する一時テーブルのレートが異常に高い場合にインサイトを作成する場合があります。ディスク上の一時テーブルの使用レベルが増加すると、データベースのパフォーマンスに影響を与える可能性があります。この状況が重要になる前に公開することで、 DevOpsGuru for RDS は問題を防止するための是正措置を講じるのに役立ちます。
異常による問題の検出
しきい値はデータベースの問題を検出する簡単で効果的な方法ですが、状況によってはそれだけでは不十分な場合もあります。日次報告ジョブなどの既知のプロセスが原因で、メトリクス値が定期的に急上昇し、潜在的に問題となる可能性のある動作に変わるケースを考えてみましょう。このような急増は予期されることであり、それぞれについてインサイトや通知を作成することは逆効果になり、アラート疲労につながる可能性があります。
ただし、非常にまれなスパイクを検出することは依然として必要です。他のメトリクスよりもずっと高い値であったり、ずっと長く続くメトリクスは、実際のデータベースパフォーマンスの問題を表している可能性があるためです。この懸念に対処するために、RDS の DevOpsGuru は特定のメトリクスをモニタリングして、メトリクスの動作が非常に異常または異常になったことを検出します。 DevOpsGuru は、これらの異常をインサイトで報告します。
例えば、RDS の DevOpsGuru は、DB 負荷が高いだけでなく、通常の動作から大きく逸脱した場合にインサイトを作成することがあります。これは、データベースオペレーションの予期しない大幅な速度低下を示していることを示しています。 DevOpsGuru for RDS では、異常な DB 負荷のスパイクのみを認識することで、真に重要な問題に集中できます。
DB 負荷
データベースのチューニングの主な概念は、データベース負荷 (DB 負荷) メトリクスです。DB 負荷は、特定の時点でのデータベースのビジー状態を表します。DB 負荷の増加は、データベースアクティビティの増加を意味します。
データベースセッションは、リレーショナルデータベースとのアプリケーションのダイアログを表します。アクティブなセッションは、データベースリクエストの実行中のセッションです。セッションは、CPU での動作中、またはリソースが使用可能になるのを待っているときにアクティブになります。例えば、アクティブなセッションでは、ページがメモリに読み込まれるのを待機し、ページからデータを読み取る間に CPU を消費することがあります。
Performance Insights の DBLoad メトリクスは、平均アクティブセッション (AAS) で測定されます。AAS を計算するために、Performance Insights は、毎秒アクティブセッションの数をサンプリングします。特定の時間間隔において、AAS は、アクティブセッションの総数をサンプルの総数で割った値です。2 の AAS 値は、任意の時点で平均して 2 つのセッションがリクエストでアクティブであったことを意味します。
DB ロードの類比は、倉庫内のアクティビティです。倉庫には100 人のワーカーがいるとします。注文が １ 件入ると、ワーカー １ 人がその注文を処理し、他の作業員はアイドル状態になります。100 件以上の注文が入ると、100 人の作業者全員が同時に注文を履行します。ある特定の期間にアクティブになっているワーカーの人数を定期的にサンプリングすれば、アクティブなワーカーの平均数を算出することができます。計算では、平均してN人のワーカーが常に注文を処理していることになります。昨日の平均が 50 人、今日の平均が 75 人だった場合、倉庫のアクティビティレベルが上がったことになります。同様に、セッションアクティビティの増加につれて DB 負荷が増加します。
詳細については、Amazon Aurora ユーザーガイドの「データベースロード」および「Amazon RDS ユーザーガイド」の「データベースロード」を参照してください。
待機イベント
待機イベントは、データベースセッションが処理できるように待機しているリソースを示すデータベースインストルメンテーションの一種です。Performance Insights がアクティブなセッションをカウントしてデータベースの負荷を計算すると、アクティブなセッションが待機する原因となっている待機イベントも記録されます。この手法により、Performance Insights は、DB 負荷に寄与している待機イベントを表示できます。
すべてのアクティブなセッションはCPU 上で実行されているか、待っています。例えば、セッションでのメモリの検索、計算の実行、またはプロシージャコードの実行の際に CPU が消費されます。セッションが CPU を消費していない場合、データファイルの読み取り、またはログの書き込みを待機している可能性があります。セッションのリソース待機時間が長くなると、CPU 上で動作する時間は短くなります。
データベースを調整するとき、多くの場合、セッションが待機しているリソースを見つけようとします。例えば、2 つまたは 3 つの待機イベントが DB 負荷の 90% を占める場合があります。これは、平均して、アクティブなセッションが少数のリソースを待機するためにほとんどの時間を費やしていることを意味します。これらの待機の原因を突き止めることができれば、問題を解決しようとすることができます。
倉庫ワーカーの例を考えてみましょう。本の注文が入ります。ワーカーは注文を処理するのが遅れる可能性があります。例えば、別の作業者が現在棚の在庫を補充している場合や、トロリーが利用できない場合があります。または、注文ステータスを入力するシステムが遅い可能性があります。作業者が待っている時間が長くなればなるほど、注文の履行にかかる時間は長くなります。待機は倉庫ワークフローの自然な部分ですが、待機時間が過大になると、生産性が低下します。同様に、セッションの待機が繰り返されたり長時間になると、データベースのパフォーマンスが低下する可能性があります。
Amazon Aurora の待機イベントの詳細については、Amazon Aurora ユーザーガイドの「Aurora PostgreSQL の待機イベントでのチューニング」および「Aurora MySQL の待機イベントでのチューニング」を参照してください。
他の Amazon RDS データベースの待機イベントの詳細については、Amazon RDS ユーザーガイドの「RDS for PostgreSQL の待機イベントによるチューニング」を参照してください。
