Query Insights を使用してクエリのパフォーマンスを向上させる

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

はじめに

Query Insights では、Cloud SQL データベースに対するクエリ パフォーマンスの問題を検出、診断、防止できます。直感的なモニタリングをサポートし、検出するだけでなくパフォーマンスの問題の根本原因の特定に役立つ診断情報を提供します。

Query Insights では、アプリケーション レベルでパフォーマンスをモニタリングでき、モデル、ビュー、コントローラ、ルート、ユーザー、ホストによるアプリケーション スタック全体で、問題のあるクエリの元をトレースできます。Query Insights ツールは、オープン標準と API を使用して、既存のアプリケーション モニタリング(APM)ツールや Google Cloud サービスと統合できます。これにより、お好みのツールを使用してクエリの問題をモニタリングし、トラブルシューティングできます。

Query Insights では、次の手順を行い、Cloud SQL クエリのパフォーマンスを向上させることができます。

  1. 上位のクエリのデータベース負荷を表示する
  2. 問題がある可能性のあるクエリまたはタグを特定する
  3. クエリまたはタグを調べて問題を特定する
  4. 問題の原因を特定する

Query Insights は、すべての Cloud SQL マシンタイプでサポートされ、すべての Google Cloud リージョンで利用できます。

料金

Query Insights に追加料金は発生しません。Query Insights ダッシュボードから 1 週間分のデータにアクセスできます。

Query Insights は、Cloud SQL インスタンスの保存容量を占有しません。指標は Cloud Monitoring に保存されます。API リクエストについては、Cloud Monitoring の料金をご覧ください。Cloud Monitoring には、追加費用なしで使用できる枠が用意されています。

始める前に

クエリプランを表示するか、エンドツーエンドのトレースを行うには、特定の IAM 権限が必要です。カスタムロールを作成し、cloudtrace.traces.get IAM 権限を追加します。次に、Query Insights を使用するユーザー アカウントごとに、このロールを追加します。

Query Insights を有効にする

Query Insights 指標は保存時に暗号化されます。Cloud SQL ダッシュボードにアクセスできるユーザーは、Query Insights ダッシュボードで Query Insights 指標にアクセスできます。インスタンスを更新する権限がある場合は、Query Insights を構成できます。Cloud SQL インスタンスに必要な権限の一覧については、Cloud SQL プロジェクトのアクセス制御をご覧ください。

Console

Google Cloud コンソールを使用して Cloud SQL インスタンスの Query Insights を有効にするには、次の手順を行います。

  1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
  3. [構成] タイルで、[構成の編集] をクリックします。
  4. 構成オプションのセクションで [Query Insights] を開きます。
  5. [クエリ分析情報を有効化] チェックボックスを選択します。
  6. 省略可: 以下の Query Insights オプションを 1 つ以上選択します。

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

    クエリの送信元であるクライアント IP アドレスを保存します。これにより、そのデータをグループ化して、そのデータに対して指標を実行できます。クエリは複数のホストから送信されます。クライアント IP アドレスからのクエリのグラフを確認すると、問題の原因を特定しやすくなります。

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

    アプリケーション タグを保存します。このタグは、リクエストを行っている API とモデル ビュー コントローラ(MVC)のルート決定や、指標を実行するためのデータのグループ化に役立ちます。このオプションでは、sqlcommenter オープンソースのオブジェクト リレーショナル マッピング(ORM)自動計測ライブラリを使用して、特定のタグセットを含むクエリをコメント化する必要があります。この情報は、Query Insights で問題の原因を特定する際に役立ちます。また、問題の原因となっている MVC も把握できます。アプリケーション パスは、アプリケーションのモニタリングに役立ちます。

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

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

    最大サンプリング レートを設定する

    インスタンス上のすべてのデータベースで、実行されるクエリプランのサンプルがデフォルトで 1 分間に最大 5 回キャプチャされます。この値を、0(サンプリングを無効にする場合)~20 の範囲で変更します。サンプリング レートを上げると、通常は得られるデータポイントの数が増えますが、パフォーマンスのオーバーヘッドが増加する可能性があります。

  7. [保存] をクリックします。

gcloud

Cloud SQL インスタンスで gcloud を使用して Query Insights を有効にするには、INSTANCE_ID をインスタンスの ID に置き換えてから、次に示す --insights-config-query-insights-enabled フラグを指定して gcloud sql instances patch を実行します。

gcloud sql instances patch INSTANCE_ID \
--insights-config-query-insights-enabled
  

また、次のオプション フラグを 1 つ以上使用します。

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

    クエリの送信元であるクライアント IP アドレスを保存します。これにより、そのデータをグループ化して、そのデータに対して指標を実行できます。クエリは複数のホストから送信されます。クライアント IP アドレスからのクエリのグラフを確認すると、問題の原因を特定しやすくなります。

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

    アプリケーション タグを保存します。このタグは、リクエストを行っている API とモデル ビュー コントローラ(MVC)のルート決定や、指標を実行するためのデータのグループ化に役立ちます。このオプションでは、特定のタグセットを使用してクエリにコメントする必要があります。これを行うには、sqlcommenter オープンソース オブジェクト リレーショナル マッピング(ORM)自動計測ライブラリを使用します。この情報は、Query Insights で問題の原因を特定する際に役立ちます。また、問題の原因となっている MVC も把握できます。アプリケーション パスは、アプリケーションのモニタリングに役立ちます。

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

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

  • --query_plans_per_minute

    インスタンス上のすべてのデータベースで、実行されるクエリプランのサンプルがデフォルトで 1 分間に最大 5 回キャプチャされます。この値を、0(サンプリングを無効にする場合)~20 の範囲で変更します。サンプリング レートを上げると、通常は得られるデータポイントの数が増えますが、パフォーマンスのオーバーヘッドが増加する可能性があります。

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

gcloud sql instances patch INSTANCE_ID \
--insights-config-query-insights-enabled \
--insights-config-query-string-length=INSIGHTS_CONFIG_QUERY_STRING_LENGTH \
--query_plans_per_minute=QUERY_PLANS_PER_MINUTE \
--insights-config-record-application-tags \
--insights-config-record-client-address \
--tier=API_TIER_STRING \
--region=REGION
  

REST v1

REST API を使用して Cloud SQL インスタンスの Query Insights を有効にするには、insightsConfig 設定で instances.patch メソッドを呼び出します。

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

  • 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"
}

指標は、クエリの完了から数分以内に Query Insights で利用できるようになると想定されています。Cloud Monitoring のデータ保持ポリシーを確認します。Query Insights のトレースは Cloud Trace に保存されます。Cloud Trace のデータ保持ポリシーを確認します。

Query Insights ダッシュボードを表示する

Query Insights ダッシュボードには、選択された要素に基づいて、クエリ負荷が表示されます。クエリ負荷は、選択された時間範囲内のインスタンス内のすべてのクエリの合計作業量の測定値です。ダッシュボードには、クエリの負荷を確認するための一連のフィルタが用意されています。

Query Insights ダッシュボードを開くには、次の手順を行います。

  1. インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
  2. 左側のナビゲーション パネルで [Query insights] タブを選択するか、[クエリ分析情報に移動すると、クエリとパフォーマンスに関する詳細情報を確認できます] リンクをクリックします。

Query Insights ダッシュボードが開きます。インスタンスの詳細が上部に表示されます。

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

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

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

すべてのクエリのデータベース負荷を表示する

データベースのクエリ負荷は、選択したデータベースで時間の経過に伴って実行されたクエリの作業量の測定結果(CPU 秒単位)です。実行中の各クエリは、CPU リソース、IO リソース、またはロックリソースを使用または待機しています。データベースのクエリ負荷は、実時間に対する、指定の時間枠内で完了したすべてのクエリで要した時間の比率です。

トップレベルの Query Insights ダッシュボードには、[データベース負荷 - すべての上位クエリ] グラフが表示されます。ダッシュボードのプルダウン メニューでは、特定のデータベース、ユーザー、またはクライアント アドレスのグラフがフィルタされます。

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

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

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

  • IO 待機: 実時間に対する、IO を待機していたクエリで要した時間の比率です。IO 待機には、読み取り IO 待機と書き込み IO 待機が含まれます。

    PostgreSQL のイベント テーブルをご覧ください。

    IO 待機に関する情報の内訳が必要な場合は、Cloud Monitoring で確認できます。詳細については、Cloud SQL の指標をご覧ください。

  • ロック待機: 実時間に対する、ロックを待機していたクエリで要した時間の比率です。通常のロック待機の他に、LwLock 待機と BufferPin ロック待機が含まれます。ロック待機の情報の詳細を確認するには、Cloud Monitoring を使用します。詳細については、Cloud SQL の指標をご覧ください。

グラフを確認し、フィルタ オプションを使用して以下の質問を検討してください。

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

データベース負荷のフィルタリング

クエリまたはタグでデータベース負荷をフィルタリングできます。

クエリでフィルタリングする

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

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

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

  • クエリ: 正規化されたクエリ文字列。Query Insights では、デフォルトでクエリ文字列の 1,024 文字のみが表示されます。

    UTILITY COMMAND というラベルの付いたクエリには通常、BEGINCOMMITEXPLAIN コマンド、またはラッパー コマンドが含まれます。

  • データベース: クエリが実行されたデータベース。

  • 負荷(合計時間別)/ 負荷(CPU 別)/ 負荷(IO 待機別)/ 負荷(ロック待機別): 特定のクエリをフィルタして最大の負荷を見つけるオプションです。

  • 平均実行時間(ミリ秒): クエリの平均実行時間。

  • 呼び出された回数: アプリケーションがクエリを呼び出した回数。

  • 返された平均行数: クエリに対して返された行数の平均。

Query Insights は、正規化されたクエリのみを保存し、表示します。デフォルトでは、Query Insights は IP アドレスやタグ情報を収集しません。この情報を収集するように Query Insights を設定できます。また、必要に応じて収集を無効にすることもできます。クエリプランのトレースでは、定数値が収集または保存されず、定数として表示される PII 情報が削除されます。

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

クエリタグでフィルタリングする

アプリケーションのトラブルシューティングを行うには、最初に SQL クエリにタグを追加する必要があります。クエリ負荷タグは、選択したタグのクエリ負荷の内訳の時間変化を示します。

Query Insights は、アプリケーション中心のモニタリングを提供して、ORM を使用して構築されたアプリケーションのパフォーマンスの問題を診断できるようにします。アプリケーション スタック全体の担当者である場合、Query Insights で、アプリケーションの視点からクエリをモニタリングできます。クエリのタグ付けは、ビジネス ロジックやマイクロサービスの使用など、より高レベルなコンストラクトで問題を見つけるのに役立ちます。

たとえば、支払いタグ、在庫タグ、ビジネス分析タグ、出荷タグなどを使用して、ビジネス ロジックでクエリにタグを付けることができます。このようにすることで、さまざまなビジネス ロジックごとに作成されるクエリ負荷を特定できます。たとえば、午後 1 時のビジネス分析タグの急増や、過去 1 週間の決済サービス トレンドの異常な増加など、予期しないイベントに気づく可能性があります。

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

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

Query Insights ダッシュボードに、タグの読み込みとタグのリストが表示されます。

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

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

特定のクエリまたはタグの調査

クエリまたはタグが問題の根本原因であるかどうかを確認するには、[クエリ] タブまたは [タグ] タブで次の操作を行います。

  1. リストを降順で並べ替えるには、[負荷(合計実行時間別)] ヘッダーをクリックします。
  2. リストの上部にあるクエリまたはタグをクリックします。負荷が最も高く、他のインスタンスよりも時間がかかります。

選択したクエリまたはタグの詳細を示すダッシュボードが開きます。

特定のクエリ負荷の調査

選択したクエリのダッシュボードが次のように表示されます。

特定のクエリのデータベース負荷とレイテンシのグラフを表示します。

[データベースの負荷 - 特定のクエリ] グラフは、正規化クエリが選択したクエリで時間の経過に伴って行った作業量(CPU 秒)の測定結果を示します。実時間の 1 分間隔で完了した正規化クエリで要した時間を使用して、負荷を計算します。テーブルの上部には、集計と PII の理由からリテラルが削除された状態で、正規化されたクエリの最初の 1,024 文字が表示されます。

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

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

タグ付けされた特定のクエリ負荷の調査

選択したタグのダッシュボードが次のように表示されます。たとえば、マイクロサービスの支払いからのすべてのクエリに payment というタグを付けている場合、payment タグを表示することで、急上昇しているクエリの負荷を確認できます。

特定のタグのページに、データベースの負荷とレイテンシのグラフを表示します。

[データベースの負荷 - 特定のタグ] グラフは、選択したタグに一致するクエリが選択したデータベースで行った作業量(CPU 秒)の測定結果を時系列で示します。全クエリのグラフと同様に、データベースユーザークライアント アドレスで、特定のタグの負荷をフィルタリングできます。

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

クエリプランは、クエリのサンプルを取得し、それを個々のオペレーションに分割します。クエリ内の各オペレーションが説明され、分析されます。

[クエリプランのサンプル] グラフには、特定の時間に実行されているすべてのクエリプランと、各プランの実行にかかった時間が表示されます。クエリプランのサンプルが 1 分あたりにキャプチャされるペースを変更できます。Query Insights を有効にするをご覧ください。

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

デフォルトでは、クエリプランのサンプルのグラフに表示されているとおり、右側のパネルには長時間かかるサンプル クエリプランの詳細が表示されます。別のサンプル クエリプランの詳細を表示するには、グラフで関連する円をクリックします。詳細が開き、クエリプランのすべてのオペレーションのモデルが表示されます。オペレーションごとに、レイテンシ、返される行、そのオペレーションの費用が表示されます。オペレーションを選択すると、共有ヒットブロック、スキーマのタイプ、ループ、プラン行などの詳細が表示されます。

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

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

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

レイテンシの調査

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

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

CPU 容量、CPU と CPU 待機、IO 待機、ロック待機のフィルタを選択した、特定のクエリのレイテンシのグラフを示します。

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

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

  1. 高負荷の原因は何ですか?CPU 容量、CPU と CPU 待機、I/O 待機、ロック待機を確認するオプションを選択します。
  2. 高い負荷がどのくらい続いていますか?高いのは今だけですか?それとも、長い間、高いですか?期間を変更して、負荷が悪化しはじめた日時を見つけます。
  3. レイテンシの急増はありますか?時間ウィンドウを変更して、正規化されたクエリの履歴レイテンシを調査します。

問題の原因の特定

負荷が最大の領域と時間を見つけたら、トレースを使用してさらに掘り下げて、問題の原因を特定します。

モデル、ビュー、コントローラ、ルート、ホスト、ユーザーなど、問題の原因を特定できるように、クエリ分析情報では、コンテキストに応じたエンドツーエンドのアプリケーション トレース ビューが表示されます。特定のリクエストのデータベース レイヤで何が起こっているかを理解し、モデル、ビュー、コントローラ、ルートによって問題のあるクエリのソースを見つけることができます。

OpenCensus または OpenTelemetry を有効にすると、opencensus スパンの情報が SQL コメント内のタグ情報とともにデータベースに送信されます。アプリケーションから Cloud Logging に送信されたトレースは、データベース クエリプラン トレースにリンクされ、問題の原因特定に役立ちます。

[クエリの例] 画面の [エンドツー エンド] タブをクリックすると、インコンテキスト トレースが表示されます。

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

問題を起こしているクライアントとユーザーを特定するには、トップ クライアント アドレストップユーザーのテーブルを使用して、負荷が最大のものを探します。ユーザーまたは IP アドレスをフィルタに追加して、特定のユーザーまたはクライアント アドレスをさらに分析できます。テーブルの詳細には、クエリ負荷の割合、平均実行時間(ミリ秒)、呼び出し時間が含まれます。

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

Cloud Trace を使用して、クエリプランの各手順をエンドツー エンドでトレースして確認できます。Query Insights ダッシュボードで [Trace で表示] のリンクをクリックして、Cloud Trace ツールを開きます。トレースグラフには、選択した期間に実行されたすべてのトレースが表示されます。

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

詳細については、トレースの検索と表示をご覧ください。

SQL クエリへのタグの追加

SQL クエリにタグを追加すると、アプリケーションのトラブルシューティングが簡単になります。sqlcommenter を使用すると、自動または手動で SQL クエリにタグを追加できます。

ORM での sqlcommenter の使用

SQL クエリを直接記述する代わりに ORM を使用すると、パフォーマンスの問題を引き起こすアプリケーション コードが見つからない可能性があります。また、アプリケーション コードによるクエリのパフォーマンスへの影響の分析に支障をきたすことがあります。この問題に対処するために、Query Insights では sqlcommenter というオープンソース ライブラリが用意されています。このライブラリは、ORM ツールを使用するデベロッパーと管理者が、パフォーマンスの問題を引き起こしているアプリケーション コードを検出するのに役立ちます。

ORM と sqlcommenter を併用している場合、タグは自動的に作成されます。アプリケーションでコードの追加や変更を行う必要はありません。

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

sqlcommenter の詳細と、ORM フレームワークで sqlcommenter を使用する方法については、sqlcommenter のドキュメントをご覧ください。

sqlcommenter を使用してタグを追加する

ORM を使用していない場合は、SQL クエリに対して正しい SQL コメント形式で、sqlcommenter のタグまたはコメントを手動で追加する必要があります。また、シリアル化された Key-Value ペアを含むコメントで、各 SQL ステートメントを拡張する必要があります。次のキーの少なくとも 1 つを使用します。

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

Query Insights は、他のすべてのキーを無視します。

Query Insights を無効にする

コンソール

Google Cloud コンソールを使用して Cloud SQL インスタンスの Query Insights を無効にするには、次の手順を行います。

  1. Google Cloud コンソールで Cloud SQL の [インスタンス] ページに移動します。

    Cloud SQL の [インスタンス] に移動

  2. インスタンスの [概要] ページを開くには、インスタンス名をクリックします。
  3. [構成] タイルで、[構成の編集] をクリックします。
  4. 構成オプションのセクションで [Query Insights] を開きます。
  5. [クエリ分析情報の有効化] チェックボックスをオフにします。
  6. [保存] をクリックします。

gcloud

Cloud SQL インスタンスで gcloud を使用して Query Insights を無効にするには、INSTANCE_ID をインスタンスの ID に置き換えてから、次に示す --no-insights-config-query-insights-enabled フラグを指定して gcloud sql instances patch を実行します。

gcloud sql instances patch INSTANCE_ID \
--no-insights-config-query-insights-enabled
  

REST

REST API を使用して Cloud SQL インスタンスの Query Insights を無効にするには、次のように queryInsightsEnabledfalse に設定して instances.patch メソッドを呼び出します。

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

  • 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"
}

次のステップ

  • Cloud SQL の指標をご覧ください。Query Insights の指標タイプの文字列は database/postgresql/insights で始まります。