Query Insights を使用したクエリのパフォーマンスの問題のトラブルシューティング

このページでは、Query Insights ダッシュボードを使用してパフォーマンスの問題を検出して分析する方法について説明します。詳細については、Query Insights の概要をご覧ください。

始める前に

自分または他のユーザーがクエリプランの表示やエンドツーエンドのトレースを行う必要がある場合は、特定の IAM 権限が必要です。カスタムロールを作成し、必要な IAM 権限を追加できます。その後、Query Insights を使用して問題のトラブルシューティングを行うユーザー アカウントに、このロールを追加できます。カスタムロールの作成をご覧ください。

カスタムロールには、次の IAM 権限が必要です。

  • cloudtrace.traces.get

Query Insights ダッシュボードを開く

Console

  1. Google Cloud Console の [Cloud SQL インスタンス] ページに移動します。
    [Cloud SQL インスタンス] ページに移動
  2. インスタンス名をクリックして [概要] ページに移動します。

  3. Query Insights ダッシュボードを開くには、[Query Insights] タブを選択するか、[クエリとパフォーマンスに関する詳細情報のために Query Insights に移動する] をクリックします。

    図 1. [Query Insights] タブまたはグラフの下部にあるアイコンを使用して、Query Insights ダッシュボードを開きます。
    図 1. Query Insights ダッシュボードを開く方法。

  4. インスタンスで Query Insights がまだ有効になっていない場合は、[有効] をクリックします。

  5. 必要な Query Insights のオプションを選択します。これらのオプションはいつでも変更できます。次のオプションがあります。

    クライアント IP アドレスを保存する

    クエリの送信元のクライアント IP アドレスを使用して、そのデータをグループ化し、そのデータに対して指標を実行できます。クエリは複数のホストから送信されます。一部のホストが適切に動作していないか、ホストがさまざまなアプリケーションを処理している可能性があります。クライアント IP アドレスからのクエリのグラフを確認すると、問題の原因を特定しやすくなります。

    アプリケーション タグを保存する

    どの API とモデル、ビュー、コントローラ(MVC)ルートがリクエストを行っているかを確認し、そのデータをグループ化して、そのデータに対して指標を実行できます。この情報は、Query Insights で問題の原因を特定する際に役立ちます。この場合、問題の原因となっている MVC を把握します。アプリケーション パスは、アプリケーションのモニタリングに役立ちます。このオプションでは、特定のタグセットを使用してクエリにコメントする必要があります。これを行うには、アプリケーション サーバーで sqlcommenter オープンソース ソフトウェアを使用します。

    クエリの長さをカスタマイズする

    デフォルトのクエリ長は 1,024 バイトです。デフォルトの上限は、最大で 4,500 バイト、最小で 256 バイトまで変更できます。分析クエリの場合はより長いほうが便利ですが、必要なメモリ量が増えます。クエリ長を変更するには、インスタンスを再起動する必要があります。長さの上限を超えているクエリにも、タグは追加されます。

  6. [有効にする] をクリックします。

    Query Insights ダッシュボードを有効にすると、フィルタのオプションとすべてのクエリに対するデータベース負荷のグラフが表示されます。

gcloud

Insights を有効にして新しいインスタンスを作成するには、--insights-config-query-insights-enabled フラグを使用して gcloud beta sql instances create コマンドを実行します。

このフラグは、次のオプションのフラグの 1 つ以上と組み合わせて使用できます。

  • --insights-config-record-client-address

    クエリの送信元のクライアント IP アドレスを使用して、そのデータをグループ化し、そのデータに対して指標を実行できます。クエリは複数のホストから送信されます。一部のホストが適切に動作していないか、ホストがさまざまなアプリケーションを処理している可能性があります。クライアント IP アドレスからのクエリのグラフを確認すると、問題の原因を特定しやすくなります。

  • --insights-config-record-application-tags

    どの API とモデル、ビュー、コントローラ(MVC)ルートがリクエストを行っているかを確認し、そのデータをグループ化して、そのデータに対して指標を実行できます。この情報は、Query Insights で問題の原因を特定する際に役立ちます。この場合、問題の原因となっている MVC を把握します。アプリケーション パスは、アプリケーションのモニタリングに役立ちます。このオプションでは、特定のタグセットを使用してクエリにコメントする必要があります。これを行うには、アプリケーション サーバーで sqlcommenter オープンソース ソフトウェアを使用します。

  • --insights-config-query-string-length

    デフォルトのクエリ長は 1,024 バイトです。デフォルトの上限は、最大で 4,500 バイト、最小で 256 バイトまで変更できます。分析クエリの場合はより長いほうが便利ですが、必要なメモリ量が増えます。クエリ長を変更するには、インスタンスを再起動する必要があります。

次のように置き換えます。

  • INSIGHTS_CONFIG_QUERY_STRING_LENGTH: Query Insights の機能で保存されるクエリ文字列の長さ(バイト単位)。デフォルトの長さは 1,024 バイトです。許容範囲: 256~4,500 バイト。
  • API_TIER_STRING: インスタンスに使用するカスタム マシンタイプ
  • REGION: インスタンスのリージョン
  gcloud sql instances create INSTANCE_NAME
    --insights-config-query-insights-enabled
    --insights-config-query-string-length=INSIGHTS_CONFIG_QUERY_STRING_LENGTH
    --insights-config-record-application-tags
    --insights-config-record-client-address
    --tier=API_TIER_STRING
    --region=REGION
  

REST API v1

このコマンドのリファレンス情報については、インスタンスの設定をご覧ください。

後述のリクエストのデータを使用する前に、次のように置き換えます。

  • project-id: プロジェクト ID
  • instance-id: インスタンス ID

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

JSON 本文のリクエスト:

{
  "settings" : { "insightsConfig" : { "queryInsightsEnabled" : true } }
}

リクエストを送信するには、次のいずれかのオプションを展開します。

次のような JSON レスポンスが返されます。

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2021-01-28T22:43:40.009Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

Insights ダッシュボード

図 2 に、データベース、ユーザー、アドレスのプルダウン メニューを備えた、Query Insights ダッシュボードを示します。プルダウン メニューの右側には、期間を設定するフィルタがあります。その下には、すべてのクエリに対するデータベース負荷のグラフが表示されます。グラフの下部には、CPU 容量、CPU と CPU 待機、IO 待機、ロック待機の選択ボックスがあります。グラフの下には、2 つのタブ(クエリとタグ)が表示されています。
図 2. Query Insights ダッシュボード。

ダッシュボードには、次の領域があります。

  1. データベース。特定のデータベースまたはすべてのデータベースのクエリ負荷をフィルタリングします。
  2. ユーザー。特定のユーザー アカウントからのクエリ負荷をフィルタリングします。
  3. クライアント アドレス。特定の IP アドレスからのクエリ負荷をフィルタリングします。
  4. 期間。時間、日、週、カスタム範囲などの期間でクエリ負荷をフィルタリングします。
  5. データベース負荷のグラフ。フィルタリングされたデータに基づいてクエリ負荷のグラフを表示します。
  6. CPU 容量、CPU と CPU 待機、IO 待機、ロック待機。選択したオプションに基づいて負荷をフィルタリングします。これらのフィルタの詳細については、クイック検出: クエリのデータベース負荷の表示をご覧ください。
  7. クエリとタグ。選択したクエリまたは SQL クエリタグのいずれかでクエリ負荷をフィルタリングします。タグの仕組みの詳細については、クイック検出: タグによるデータベース負荷のフィルタリングをご覧ください。クエリにタグを追加する方法については、SQL クエリへのタグの追加をご覧ください。

パフォーマンスの問題のトラブルシューティングに関する高レベルのガイド

Query Insights では、Cloud SQL クエリのトラブルシューティングを行い、パフォーマンスの問題を特定できます。Query Insights ダッシュボードには、選択された要素に基づいて、クエリ負荷が表示されます。クエリ負荷は、選択された時間範囲内のインスタンス内のすべてのクエリの合計作業量の測定値です。

Query Insights では、クエリのパフォーマンスの問題を検出して分析できます。Query Insights では、次の 3 つのフェーズでクエリのトラブルシューティングを行います。

  • クイック検出 - 問題のあるクエリとアプリケーションを特定する
  • 根本原因の分析 - クエリプラン分析でクエリが遅い理由を特定する
  • ソースを特定する - 問題のあるクエリのアプリケーション、ユーザー、ホストを特定する

クイック検出: クエリのデータベース負荷の表示

トップレベルの Query Insights ダッシュボードには、[データベース負荷 - すべての上位クエリ] グラフが表示されます。データベースのクエリ負荷は、選択したデータベースで時間の経過に伴って実行されたクエリの作業量の測定結果(CPU 秒単位)です。実行中の各クエリは、CPU リソース、IO リソース、またはロックリソースを使用または待機しています。データベースのクエリ負荷は、実時間に対する、指定の時間枠内で完了したすべてのクエリで要した時間の比率です。

プルダウン メニューを使用すると、特定のデータベース、ユーザー、クライアント アドレスでグラフをフィルタリングできます。

データベース負荷のグラフ

CPU 容量、CPU と CPU 待機、IO 待機、ロック待機の負荷によるデータベース負荷のグラフを示します。
図 3. CPU 容量、CPU と CPU 待機、IO 待機、ロック待機の負荷によるデータベース負荷のグラフを示します。

グラフの色付きの線で、クエリ負荷を 4 つのカテゴリに分けて表示します。

  • CPU 容量: インスタンスで利用可能な CPU の数。
  • CPU と CPU 待機: 実時間に対する、アクティブな状態のクエリで要した時間の比率です。IO 待機とロック待機は、アクティブ状態のクエリをブロックしません。この指標は、クエリが CPU を使用している可能性があることを示します。また、他のプロセスが CPU を使用しているときに、Linux スケジューラがクエリを実行しているサーバー プロセスをスケジューリングするのをクエリが待機している可能性もあります。

    注: CPU 負荷では、ランタイムと、Linux スケジューラが実行中のサーバー プロセスをスケジューリングするのを待機する時間の両方が考慮されます。その結果、CPU 負荷が最大コアラインを超える可能性があります。

  • IO 待機: 実時間に対する、IO を待機していたクエリで要した時間の比率です。IO 待機には、読み取り IO 待機と書き込み IO 待機が含まれます。PostgreSQL のイベント テーブルをご覧ください。IO 待機に関する情報の内訳が必要な場合は、Cloud Monitoring で確認できます。詳しくは、Insights の指標をご覧ください。

  • ロック待機: 実時間に対する、ロックを待機していたクエリで要した時間の比率です。通常のロック待機の他に、LwLock 待機と BufferPin ロック待機が含まれます。ロック待機に関する情報の内訳が必要な場合は、Cloud Monitoring で確認できます。詳しくは、Insights の指標をご覧ください。

グラフを確認し、フィルタのオプションを使って次の質問に答えます。

  1. クエリ負荷は高いですか?クエリ負荷のグラフを確認します。グラフは時間の経過にともなって増加または減少していますか?負荷が高くない場合は、クエリに問題はありません。
  2. 高い負荷がどのくらい続いていますか?高いのは今だけですか?それとも、長い間、高いですか?範囲の選択を使用して、さまざまな期間を選択して、問題が発生した期間を探します。あるいは、クエリ負荷の急増が観測される時間枠を拡大表示できます。縮小表示して最大 1 週間のタイムラインを表示することもできます。
  3. 高い負荷の原因は何ですか?CPU 容量、CPU と CPU 待機、ロック待機、IO 待機を確認するオプションを選択できます。これらの各オプションのグラフの色は異なるため、どこで最も負荷が高くなっているかを確認できます。グラフの濃い青色の線は、システムの最大 CPU 容量を示しています。これにより、クエリ負荷をシステムの最大 CPU 容量と比較できます。この比較を行うことで、インスタンスの CPU リソースが不足しているかどうかを把握できます。
  4. どのデータベースで負荷が発生していますか?[データベース] プルダウン メニューからデータベースを選択して、負荷が最も高いデータベースを特定します。
  5. 特定のユーザーまたは IP アドレスが高負荷の原因となっていますか?プルダウン メニューからユーザーとアドレスを選択して、どれが高負荷の原因となっているかを比較できます。

クイック検出: すべてのクエリのデータベース負荷のフィルタリング

[クエリ] テーブルでは、クエリ負荷が最も大きいクエリの概要を確認できます。このテーブルには、Query Insights ダッシュボードで選択された時間枠とオプションに対応する、正規化されたすべてのクエリが表示されます。

[クエリ] テーブルは、選択した時間枠における合計実行時間でクエリを並べ替えます。

CPU 容量、CPU と CPU 待機、IO 待機、ロック待機のフィルタを選択した、クエリの負荷によるデータベース負荷のグラフを示します。
図 4. CPU 容量、CPU と CPU 待機、IO 待機、ロック待機のフィルタを選択した、クエリのデータベース負荷のグラフを示します。

テーブルを並べ替えるには、[クエリのフィルタリング] からプロパティを選択するか、列見出しを選択します。テーブルには以下のプロパティが表示されます。

  • クエリ文字列。正規化されたクエリ文字列です。Query Insights では、クエリ文字列のうち 1,024 文字のみが表示されます(デフォルト)。
  • データベース。クエリが実行されたデータベース。
  • 負荷(合計実行時間別) / 負荷(CPU 別) / 負荷(IO 待機別) / 負荷(ロック待機別)。これらのオプションにより、特定のクエリをフィルタリングして、各オプションの最大負荷を見つけることができます。
  • 平均実行時間(ミリ秒)。クエリの平均実行時間です。
  • 呼び出された回数。アプリケーションによってクエリが呼び出された回数。
  • 取得した平均行。クエリに対して取得された行数の平均。

PostgreSQL 9.6 と 10 では、Query Insights は正規化されたクエリを表示します。つまり、文字定数は「?」に置換されます。以下の例では、名前定数が削除され、「?」に置換されます。次に例を示します。

UPDATE
  "demo_customer"
SET
  "customer_id" = ?::uuid,
  "name" = ?,
  "address" = ?,
  "rating" = ?,
  "balance" = ?,
  "current_city" = ?,
  "current_location" = ?
WHERE
  "demo_customer"."id" = ?

PostgreSQL バージョン 11 以降では、文字定数は $1、$2 などに置換されます。次に例を示します。

UPDATE
  "demo_customer"
SET
  "customer_id" = $1::uuid,
  "name" = $2,
  "address" = $3,
  "rating" = $4,
  "balance" = $5,
  "current_city" = $6,
  "current_location" = $7
WHERE
  "demo_customer"."id" = $8

この定数値は無視されるため、Query Insights は類似したクエリを集計し、定数で表示される可能性のある PII 情報を削除できます。

ここで、[クエリ] タブから以下のことを行って、クエリが問題の根本原因であるかどうかを判断します。

  1. [負荷(合計実行時間別)] をクリックして、クエリに長い時間がかかっているかどうかを確認します。
  2. あるクエリが他のクエリよりも時間がかかっているように見える場合は、詳細なトラブルシューティングのために、その特定のクエリのグラフに移動します。クエリに問題がないようであれば、「根本原因の分析: アプリケーション タグ」のセクションに進みます。

根本原因の分析: 特定のクエリのデータベース負荷のフィルタリング

大きなクエリ負荷を示すクエリが見つかったら、そのクエリをクリックして [データベースの負荷 - 特定のクエリ] ダッシュボードを開きます。

[データベースの負荷 - 特定のクエリ] グラフは、選択した正規化クエリが選択したクエリで時間の経過に伴って行った作業量(CPU 秒)の測定結果を示します。実時間の 1 分間隔で完了した正規化クエリで要した時間を使用して、負荷を計算します。

テーブルの上部に、(集計と PII の理由から文字が削除された)正規化されたクエリの最初の 1,024 文字が表示されます。

CPU 容量、CPU と CPU 待機、IO 待機、ロック待機のフィルタを選択した、特定のクエリの負荷によるデータベース負荷のグラフを示します。
図 5. CPU 容量、CPU と CPU 待機、IO 待機、ロック待機のフィルタを選択した、特定のクエリの負荷によるデータベース負荷のグラフを示します。

全クエリのグラフと同様に、データベースユーザークライアント アドレスで、特定のクエリの負荷をフィルタリングできます。クエリ負荷は、CPU 容量CPU と CPU 待機IO 待機ロック待機に分割されます。

クエリのレイテンシの調査

クエリのレイテンシを調べるには、レイテンシ グラフを使用します。レイテンシとは、正規化されたクエリの実行に要した実時間です。レイテンシ ダッシュボードには、50、95、99 パーセンタイルのレイテンシが表示されるため、外れ値の挙動を確認できます。

CPU 容量、CPU と CPU 待機、IO 待機、ロック待機のフィルタを選択した、特定のクエリのレイテンシのグラフを示します。
図 6. CPU 容量、CPU と CPU 待機、IO 待機、ロック待機のフィルタを選択した、特定のクエリの 50 パーセンタイルでのデータベース負荷のグラフを示します。

並列クエリでは、クエリの一部を実行するのに複数のコアが使用されるためクエリ負荷が高くなる可能性がありますが、レイテンシは実時間で測定されます。

以下のことを確認して、問題を絞り込んでみてください。

  1. 高い負荷の原因は何ですか?CPU 容量、CPU と CPU 待機、ロック待機、IO 待機を確認するオプションを選択します。
  2. レイテンシの急増はありますか?時間枠を変更して、正規化されたクエリの履歴レイテンシを調べることができます。
  3. 負荷が最も高い領域と時間が見つかったら、さらにドリルダウンする方法を学ぶために、トレーシングを使用した問題の原因の特定に移動します。

クイック検出: タグによるデータベース負荷のフィルタリング

Query Insights は、アプリケーション中心のモニタリングを提供して、ORM を使用して構築されたアプリケーションのパフォーマンスの問題を診断できるようにします。

アプリケーション スタック全体の担当者である場合、Query Insights で、アプリケーションの視点からクエリをモニタリングできます。クエリのタグ付けは、ビジネス ロジック、マイクロサービス、他のコンストラクトの使用など、より高レベルなコンストラクトで問題を見つけるために役立ちます。たとえば、支払いタグ、在庫タグ、ビジネス分析タグ、出荷タグなどを使用して、ビジネス ロジックでクエリにタグを付けることができます。このようにすることで、さまざまなビジネス ロジックごとに作成されるクエリ負荷を特定できます。たとえば、午後 1 時のビジネス分析タグの急上昇など、予期しないイベントが発生するかもしれません。あるいは、前週に決済サービス トレンドの異常な増加が確認されるかもしれません。

クエリ負荷タグは、選択したタグのクエリ負荷の内訳の時間変化を示します。

タグのデータベース負荷を計算するために、Query Insights は選択したタグを使用するすべてのクエリにかかる時間を使用します。Query Insights は、実時間を使用して 1 分間隔で完了時間を計算します。

Query Insights ダッシュボードで、[タグ] を選択して [タグ] テーブルを表示します。[タグ] テーブルは、合計負荷を合計時間で割った値でタグを並べ替えます。

図 7 は、タグに対応した負荷を表示する Query Insights ダッシュボードを示しています。
         グラフの下には、タグの一覧が表示されます。
図 7. 選択したタグのデータベース負荷。

テーブルを並べ替えるには、[クエリのフィルタリング] からプロパティを選択するか、列見出しをクリックします。テーブルには以下のプロパティが表示されます。

  • アクション、コントローラ、フレームワーク、ルート、アプリケーション、DB ドライバ。クエリに追加したプロパティは、列として表示されます。タグでフィルタリングする場合は、これらのプロパティのうち少なくとも 1 つを追加する必要があります。
  • 負荷(合計実行時間別) / 負荷(CPU 別) / 負荷(IO 待機別) / 負荷(ロック待機別)。これらのオプションにより、特定のクエリをフィルタリングして、各オプションの最大負荷を見つけることができます。
  • 平均実行時間(ミリ秒)。クエリの平均実行時間です。
  • 呼び出された回数。アプリケーションによってクエリが呼び出された回数。
  • 取得した平均行。クエリに対して取得された行数の平均。
  • データベース。クエリが実行されたデータベース。

ここで、[タグ] タブから以下のことを行って、クエリが問題の根本原因であるかどうかを判断します。

  1. [負荷(合計実行時間別)] をクリックして、クエリに長い時間がかかっているかどうかを確認します。
  2. あるタグが他のタグよりも時間がかかっているように見える場合は、詳細なトラブルシューティングのために、その特定のタグのグラフに移動します。

根本原因の分析: タグ付けされたクエリ負荷の詳細の表示

正規化されたクエリの負荷と同様に、[タグ] テーブルでいずれかのエントリをクリックすると、タグ付けされたクエリの負荷の詳細が表示されます。たとえば、マイクロサービスの支払いからのすべてのクエリに payment というタグを付けている場合、payment タグを表示することで、急上昇しているクエリの負荷を確認できます。

図 8 は、特定のタグのページに表示されたデータベース負荷とレイテンシのグラフを示しています。
図 8. 特定のタグのデータベース負荷とレイテンシのグラフ。

全クエリのグラフと同様に、データベースユーザークライアント アドレスで、特定のクエリの負荷をフィルタリングできます。クエリ負荷は、CPU 容量CPU と CPU 待機IO 待機ロック待機に分割されます。

以下のことを確認して、問題を絞り込んでみてください。

  1. 高い負荷の原因は何ですか?CPU 容量、CPU と CPU 待機、ロック待機、IO 待機を確認するオプションを選択します。
  2. 高い負荷がどのくらい続いていますか?高いのは今だけですか?それとも、長い間、高いですか?期間を変更して、負荷が悪化しはじめた日時を見つけます。
  3. 負荷が最も高い領域と時間が見つかったら、さらにドリルダウンする方法を学ぶために、トレーシングを使用した問題の原因の特定に移動します。

サンプリングされたクエリプランでのオペレーションの調査

クエリプランは、クエリのサンプルを取得し、それを個々のオペレーションに分割します。クエリ内の各オペレーションが説明され、分析されます。[クエリプランのサンプル] グラフには、特定の時間に実行されているすべてのクエリプランと、各プランの実行にかかった時間が表示されます。

図 9 は、サンプル クエリプランのグラフを示しています。グラフの下部は実行時刻(x 軸)、右側は実行された秒数(Y 軸)を表します。
図 9. サンプル クエリプラン、それが実行された日時、実行された秒数を示すグラフ。

サンプル クエリプランの詳細を表示するには、[クエリプランのサンプル] グラフのドットをクリックします。すべてではありませんが、ほとんどのクエリで、実行されたサンプル クエリプランが表示されます。開かれた詳細は、クエリプランのすべてのオペレーションのモデルを示しています。オペレーションごとに、レイテンシ、返される行、そのオペレーションの費用が表示されます。オペレーションを選択すると、共有ヒットブロック、スキーマのタイプ、実際のループ、プラン行などの詳細を確認できます。

図 10. クエリプランは、クエリに対して実行される各オペレーションのレイテンシと費用を表示します。まず、48 個の行を返す集計から始まります。レイテンシは 31.06 ミリ秒、費用は 296.34 です。次のオペレーションはネストされたループです。これは、別のネストされたループと実体化に分割されます。
         ネストされたループは、別のネストされたループとインデックス スキャンに分割されます。実体化はシーケンス スキャンにつながります。
図 10. クエリプランは、クエリに対して実行される各オペレーションのレイテンシと費用を表示します。

以下のことを確認して、問題を絞り込んでみてください。

  1. リソースを消費しているのは何ですか?
  2. 他のクエリとどのように関係していますか?
  3. 消費は時間とともに変化していますか?

トレーシングを使用した問題の原因の特定

トラブルシューティングの処理の最後に訊く必要がある質問は、「問題の原因は何ですか?」です。より明確には、「どのモデル、ビュー、コントローラ、ルート、ホスト、ユーザーが問題の原因となっていますか?」です。

Query Insights は、特定のリクエストのデータベース レイヤで何が起こっているかを理解するために、インコンテキスト エンドツーエンドのトレースビューを提供します。インコンテキスト エンドツーエンドのアプリケーション トレースを使用して、モデル、ビュー、コントローラ、ルートによって問題のあるクエリの元を見つけます。OpenCensus または OpenTelemetry を有効にすると、opencensus スパンの情報が SQL コメント内のタグ情報とともにデータベースに送信されます。アプリケーションから Cloud Logging に送信されたトレースは、データベース クエリプラン トレースにリンクされて、問題の原因を特定します。下図の [エンドツー エンド] タブをクリックすると、インコンテキスト トレースが表示されます。

図 11. [エンドツー エンド] でタグを選択すると、そのタグに関する特定の情報が表示されます。[サマリー] には、そのタグの各オペレーションの RPC と合計時間(ミリ秒)が表示されます。
図 11. [エンドツー エンド] でタグを選択すると、そのタグに関する特定の情報が表示されます。

問題を起こしているクライアントとユーザーを特定するには、トップ クライアント アドレスとトップユーザーのテーブルを使用して、負荷が最大のものを探します。ユーザーまたは IP アドレスをフィルタに追加して、特定のユーザーまたはクライアント アドレスをさらに分析できます。

図 12. この画像は、トップ クライアント アドレスでは、負荷が 100%、平均実行時間が 19,568 秒、呼び出された回数が 1,226 であることを示しています。トップユーザーの場合、ユーザー postgres は負荷が 100%、平均実行時間が 19,568 ミリ秒で、1,226 回呼び出されています。
図 12. トップ クライアント アドレスとトップユーザーの詳細には、クエリ負荷の割合、平均実行時間(ミリ秒)、呼び出された回数が含まれます。

クエリについては、Cloud Trace を使用して、クエリプランの各手順をエンドツー エンドでトレースして確認できます。Insights ダッシュボードで [Trace で表示] のリンクをクリックして、Cloud Trace ツールを開きます。

図 13. トレースグラフには、選択した期間(この場合は 1 時間)に実行されたすべてのトレースが表示されます。このページには、レイテンシ、HTTP メソッド、URL、トレースが実行された時刻を示すテーブルも表示されます。
図 13. トレースグラフには、選択した期間に実行されたすべてのトレースが表示されます。

Cloud Trace のツールの使用方法について詳しくは、トレースの検索と表示をご覧ください。

SQL クエリへのタグの追加

SQL クエリにタグを追加すると、アプリケーションのトラブルシューティングが簡単になります。ORM と sqlcommenter を組み合わせて使用している場合、タグが自動的に作成されます。アプリケーションにカスタムコードを追加する必要はありません。ORM を使用していない場合は、SQL クエリに手動で sqlcommenter タグを追加する必要があります。

sqlcommenter を使用した手動でのタグの追加

クエリでは、シリアル化された Key-Value ペアを含むコメントで各 SQL ステートメントを拡張する必要があります。次のキーの少なくとも 1 つを使用します。

  • action=''
  • controller=''
  • framework=''
  • route=''
  • application=''
  • db driver=''

Query Insights は、他のすべてのキーを無視します。正しい SQL コメント形式については、sqlcommenter のドキュメントをご覧ください。

ORM での sqlcommenter の使用

SQL クエリを直接記述する代わりに、オブジェクト リレーショナル マッピング(ORM)を使用すると、パフォーマンスの問題を引き起こすアプリケーション コードを見つけられないことがあります。また、アプリケーション コードによるクエリのパフォーマンスへの影響の分析に支障をきたすことがあります。この問題に対処するため、Query Insights には ORM インストルメンテーション ライブラリである sqlcommenter というオープンソース ライブラリが用意されています。このライブラリは、デベロッパーが ORM と Admin を使用して、パフォーマンスの問題を引き起こしているアプリケーション コードを検出するのに役立ちます。注目するべきこととして、処理全体でアプリケーション コードを変更する必要がありません。

この問題に対処するため、Query Insights には sqlcommenter と呼ばれる ORM インストルメンテーション ライブラリが用意されています。sqlcommenter はアプリケーション サーバーにインストールできます。インストルメンテーション ライブラリを使用すると、モデル、ビュー、コントローラ(MVC)フレームワークに関連するアプリケーション情報を、SQL コメントとしてクエリとともにデータベースに伝達できます。データベースはこれらのタグを取得し、正規化されたクエリによって集計される統計とは無関係に、タグによる統計の記録と集計を開始します。Query Insights でタグが表示されるため、クエリ負荷の原因となったアプリケーションを把握できます。この情報により、パフォーマンスの問題を引き起こしているアプリケーション コードを検出できます。注目するべきこととして、処理全体でアプリケーション コードを変更する必要がありません。

SQL データベース ログの結果を調べると、次のようになります。

SELECT * from USERS /*action='run+this',
controller='foo%3',
traceparent='00-01',
tracestate='rojo%2'*/

サポートされるタグには、コントローラ名、ルート、フレームワーク、アクションが含まれます。

一連の sqlcommenter の ORM は、さまざまなプログラミング言語でサポートされています。

Python
  • Django
  • psycopg2
  • Sqlalchemy
  • Flask
Java
  • Hibernate
  • Spring
Ruby
  • Rails
Node.js
  • Knex.js
  • Sequelize.js
  • Express.js

詳細については、GitHub の sqlcommenter のドキュメントをご覧ください。

ORM フレームワークでの sqlcommenter のインストール

詳細とインストールの手順については、GitHub の sqlcommenter のドキュメントをご覧ください。

Insights の無効化

インスタンスで Insights を無効にするには:

Console

  1. Google Cloud Console の [Cloud SQL インスタンス] ページに移動します。
    [Cloud SQL インスタンス] ページに移動
  2. インスタンス名をクリックして [概要] ページに移動します。

  3. [構成] タイルで、[構成の編集] をクリックします。
  4. [構成オプション] で、[Query Insights] を展開します。
  5. [Query Insights の有効化] チェックボックスをオフにします。
  6. [保存] をクリックします。

gcloud

--no-insights-config-query-insights-enabled フラグを使用して gcloud beta sql instances patch コマンドを実行します。

  gcloud beta sql instances patch --no-insights-config-query-insights-enabled
  

REST API

後述のリクエストのデータを使用する前に、次のように置き換えます。

  • project-id: プロジェクト ID
  • instance-id: インスタンス ID

HTTP メソッドと URL:

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id

JSON 本文のリクエスト:

{
  "settings" : { "insightsConfig" : { "queryInsightsEnabled" : false } }
}

リクエストを送信するには、次のいずれかのオプションを展開します。

次のような JSON レスポンスが返されます。

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2021-01-28T22:43:40.009Z",
  "operationType": "UPDATE",
  "name": "operation-id",
  "targetId": "instance-id",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/operations/operation-id",
  "targetProject": "project-id"
}

次のステップ