Performance Insights を使用して Amazon Aurora の MySQL のワークロードを分析する

Amazon Relational Database Service (Amazon RDS) Performance Insights を使用すれば、パフォーマンスの問題の原因だけでなく、Amazon RDS データベース上のワークロードの性質を即座に把握できます。このブログ記事では、Amazon Aurora MySQL-Compatible Edition の Performance Insights ダッシュボードを手短に見て、パフォーマンスの問題を分析する方法を学びます。前回のブログ記事「Performance Insights で Amazon RDS データベースのワークロードを分析する」では、Performance Insights へのアクセスに関する基本的な事項と、Amazon Aurora PostgreSQL-Compatible Edition でそれを使用することについて取り上げました。

以下では、Performance Insights が、Aurora MySQL データベースで実行されている負荷が示されています。この例では、負荷グラフは待機でスライスされます。待機から、どのような作業が負荷の原因となっているか、そしてCPU、I/O 読み取り、ロック、安定したストレージへの書き込み、または他のデータベースリソースからの競合によってどれくらいの負荷がかかているかがわかります。Aurora MySQL は、MySQL の Performance Schema を使用してデータベースの待機を計測します。つまり、Performance Insights を最大限に活用したい Aurora MySQL ユーザーは、MySQL Performance Schema を有効にする必要があります。RDS パラメータグループで Performance Schema を有効または無効にしたことがない場合は、Performance Insights を有効にすると、自動的に MySQL Performance Schema が有効になり、設定されます。

データベースの負荷

ダッシュボードの上半分には、平均アクティブセッション (AAS) で測定されたデータベースの負荷が表示されます。デフォルトでは、Performance Insights は 1 時間の履歴を表示し、各ポイントは 1 分間の平均を表します。グラフは毎分自動的に更新され、新しい着信データを表示します。

平均アクティブセッション (AAS) で測定されるデータベースの負荷は、データベースパフォーマンスの新規表現および視覚化であり、本質的にデータベース内で同時にクエリを実行するデータベース接続の数を反映しています (この場合、セッションは接続と同じです) 。たとえば、ユーザーがアイドル状態のデータベースで 60 秒かかるクエリを実行した場合、1 分間にアクティブになっているセッションが 1 つあるため、その分の DB 負荷は 1 になります。2 人のユーザーが 60 秒かかるクエリを同時に実行すると、その分の DB 負荷は 2 になります。60 人のユーザーがそれぞれ 1 秒かかるクエリを実行し、1 分以内に 1 回だけクエリを実行したとすると、その分の DB 負荷は 1 になります (平均して、その分の任意の秒に 1 つの接続がクエリを実行しているためです) 。各実行に 1 秒しかかからない場合、1 分間アクティブな平均接続数は 1 です。

Performance Insights は、DB 負荷だけを表示するのではありません。どのような種類のアクティビティがその負荷の原因となっているかも示します。待機別スライスを選択すると、Performance Insights は、CPU、I/O、ロック、または他のデータベースリソースの待機など、発生しているアクティビティの種類によって DB 負荷をグループ化します。どの待機が DB 負荷の原因であるかを観察することで、パフォーマンスを制限する競合の種類を理解できます。

負荷図には重要なグラフィック要素があります。点線の Max vCPU の行は、CPU キューイングが発生する前に CPU でアクティブにできるセッションの最大数を表します。たとえば、2 つの vCPU と 4 つのアクティブなプロセスがあった場合、一度に 2 つのプロセスだけが vCPU でアクティブになります。他の 2 つのプロセスは実行キューで待機します。 したがって、vCPU ラインは、負荷が使用可能なリソースを超えているかどうか、またはインスタンスに空き容量があるかどうかを測定するための良い基準です。

上位の SQL

デフォルトでは、DB 負荷グラフの下のリストには、その負荷の原因となる SQL クエリが表示されます。リストの一番上にあるものが負荷の最大の要因となっているもので、ボトルネックを解決するためのチューニングを集中して行いたい SQL です。

データベースはいつアイドル状態になっているか?

データベースがアイドル状態であることを知ることは重要です。データベースがアイドル状態になっていれば、アプリケーションのパフォーマンスの問題は、データベースによるものではない可能性が高くなります。Performance Insights では、データベースがアイドル状態にあるかどうかを素早く確認できます。データベースの負荷図には何のアクティビティもありません。例を以下に示します。

CPU のボトルネックはありますか？

以下の DB 負荷図には、13:30 分の直前にスパイクがあります。スパイクの大半は、緑色の CPU です。CPU 需要による DB 負荷は、15 AAS 前後にピークに達します。

データベースは 8 つの vCPU にしかアクセスできないため、CPU の需要ピーク時にセッションのほぼ半分が、ある時点で CPU サイクルの待機状態にあったことを意味します。別の言い方をすると、そのピーク時に 15 セッションが CPU にアクセスするのに時間の半分近くを費やしていたことになります。CPU の量を 2 倍にすると、潜在的にほぼ 2 倍の速さで動作する可能性があります。

Performance Insights では、クリックしてドラッグすることで、DB 負荷グラフの一部を拡大表示できます。この画像では、8 月 24 日の CPU の負荷スパイクを拡大しています。

Performance Insights は選択したスパイクを拡大し、上位の SQL リストを新しい時間枠に再スコープします。

負荷図の下にある SQL タブでは、1 つのストアドプロシージャ my_sqrt () が複数のセッションで同時に実行されており、CPU に負荷をかける唯一の原因となっています。このシナリオでは、関数の内部ロジックを調べるか、またはアプリケーションが呼び出す頻度を減らすことによって、このストアドプロシージャを最適化することに焦点を当てます。

ボトルネックはありますか？

次の例では、DB 負荷図の左側にスパイクが表示されています。 この場合、スパイクは負荷の大部分が Aurora MySQL 待機イベント io/aurora_redo_log_flush からのものであり、安定した Aurora ストレージへの書き込みを待機している状態にあることを示しています。

スパイクを拡大すると、次のように表示されます。

ほとんどの io/aurora_redo_log_flush の待機は、2 つの更新ステートメントに由来しています。これらの更新ステートメントを調べると、明示的なトランザクションの一部ではない単一行の更新ステートメントであることがわかります。Aurora MySQL は、デフォルトで、トランザクション外の DML ステートメントを実行する度に暗黙的コミット (自動コミット) を使用します。コミットには耐久性のある書き込みが必要です。したがって、更新後はいつも、安定したストレージへの書き込みを待機しています。これを最適化するには、一括処理 (50 など) を実行してからコミットしたり、複数の異なる DML ステートメントを最後にコミットするトランザクションにグループ化したりすることができます。

ここにマイクロベンチマークの例があります。次のケースでは、4 回の同時セッションを実行し、それぞれ 10,000 回の更新で合計 40,000 回の更新を行いました。最初のケースでは、自動コミットがオンになっており、40,000 回の更新を完了するのに 40 秒かかりました。接続時間のほとんどは io/aurora_redo_log_flush を待機する時間に費やされました。2 番目のケースでは、自動コミットがオフになっており、40,000 回の更新を実行するのに 10 秒しかかかりませんでした。 以下の負荷図では、結果を視覚的に見ることができます。以下の負荷図では、左側に自動コミットの最初の実行が表示され、40 秒の AAS 負荷 4 として表示されています。そして負荷の大半が「io/aurora_redo_log_flush」の待機状態であることがわかります。その後、スクリプトがスリープしている間に 20 秒のアイドルギャップがあります。最後に、自動コミットがオフになっている設定で、主に「io/aurora_respond_to_client」を待機するワークロードを表す 10 秒間のワイドスパイクがあります。負荷の 2 回目の実行は 10 秒で、最初の 4 倍の速さで、「io/aurora_redo_log_flush」の待機時間がすべて無くなりました。自動コミットをオフにすることによって、コミットはレコードの各バッチの終わりに行うのではなく、すべての更新後に行われるようになり、「io/aurora_redo_log_flush」の待機時間がなくなりました。

概要

Performance Insights は、Aurora MySQL のパフォーマンスのボトルネックを迅速かつ簡単に特定し、そのボトルネックに対処するためのエリアを特定するのに役立ちます。デフォルトでは、Performance Insights はデータベース作成時に有効になっています。Performance Insights を有効にするコントロールは、データベースインスタンスを作成または変更するときに RDS コンソールで見つかります。Performance Insights は完全に自動化されており、ほとんどの場合、オーバーヘッドは vCPU の約 1 ％です。すべてのデータの格納、処理、集約は自動的に管理され、データベースホスト外で行われ、データベースへの影響を最小限に抑えます。

このブログの投稿に関するコメントは、以下のコメントセクションからお送りください。

著者について

Kyle Haileyは、アマゾン ウェブ サービスの Performance Insights のプロダクトマネージャーです。