このページは Cloud Translation API によって翻訳されました。

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

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

Gemini in Databases アシスタントを使用すると、AlloyDB リソースのモニタリングとトラブルシューティングを行うことができます。詳細については、Gemini アシスタンスによるモニタリングとトラブルシューティングをご覧ください。

始める前に

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

カスタムロールには、IAM 権限 cloudtrace.traces.get が必要です。

クエリ分析情報ダッシュボードを開く

クエリ分析情報ダッシュボードを開く手順は次のとおりです。

クラスタとインスタンスのリストで、インスタンスをクリックします。
クラスタの [概要] ページの指標グラフの下にある [クエリ分析情報に移動すると、クエリとパフォーマンスに関する詳細情報を確認できます] をクリックするか、左側のナビゲーションパネルで [クエリ分析情報] タブを選択します。

次のページで、次のオプションを使用して結果をフィルタできます。

インスタンスセレクタ。クラスタ内のプライマリインスタンスまたは読み取りプールインスタンスを選択できます。デフォルトでは、プライマリインスタンスが選択されています。表示される詳細は、接続されているすべての読み取りプールインスタンスとそのノードについて集計されます。
データベース。特定のデータベースまたはすべてのデータベースのクエリ負荷をフィルタリングします。
ユーザー。特定のユーザーアカウントからのクエリ負荷をフィルタリングします。
クライアントアドレス。特定の IP アドレスからのクエリ負荷をフィルタリングします。
期間。時間、日、週、カスタム範囲などの期間でクエリ負荷をフィルタリングします。

クエリ分析情報ダッシュボードには、インスタンス選択ツールと、データベース、ユーザー、アドレスのプルダウンメニューがあります。プルダウンメニューの右側には、期間を設定するフィルタがあります。

Query Insights の構成を編集する

Query Insights は、AlloyDB インスタンスでデフォルトで有効になっています。デフォルトの Query Insights 構成を編集できます。

AlloyDB インスタンスの Query Insights 構成を編集する手順は次のとおりです。

Console

Google Cloud コンソールで、[クラスタ] ページに移動します。

[クラスタ] に移動
[リソース名] 列でクラスタをクリックします。
左側のナビゲーションパネルで [クエリ分析情報] をクリックします。
[クエリ分析情報] リストから [プライマリ] または [読み取りプール] を選択し、[編集] をクリックします。
[Query Insights] フィールドを編集します。
1. AlloyDB が分析するクエリの長さのデフォルト制限（1, 024 バイト）を変更するには、[クエリの長さをカスタマイズする] フィールドに 256 ～ 4, 500 の数字を入力します。
  
  このフィールドを編集すると、インスタンスが再起動します。
  
  注: クエリ長の上限を大きくすると、必要なメモリが増えます。
2. Query Insights の機能セットをカスタマイズするには、次のオプションを調整します。
  - クエリプランを有効にする。 このチェックボックスをオンにすると、クエリのサンプルの実行に使用されるオペレーションを確認できます。
    [最大サンプリングレート] フィールドに 1 ～ 20 の数値を入力します。デフォルトでは、サンプリングレートは 5 に設定されています。サンプリングを無効にするには、[クエリプランを有効にする] チェックボックスをオフにします。
    サンプリングレートは、AlloyDB がインスタンスごとにノードごとに 1 分あたりサンプリングできるクエリの最大数を決定します。
  - クライアント IP アドレスを保存する。このチェックボックスをオンにすると、クエリの送信元を把握し、その情報をグループ化して指標を実行できます。
  - アプリケーションタグを保存する。このチェックボックスをオンにすると、リクエストを行っているタグ付けされたアプリケーションを確認し、その情報をグループ化して指標を実行できます。アプリケーションタグの詳細については、仕様をご覧ください。
[Update instance] をクリックします。

gcloud

Google Cloud CLI コマンドを使用して AlloyDB インスタンスのクエリ分析情報を有効にするには、次の操作を行います。

Google Cloud CLI をインストールします。
gcloud CLI を初期化するには:
```
gcloud init
```
ローカルシェルを使用している場合は、ユーザーアカウントのローカル認証情報を作成します。
```
gcloud auth application-default login
```
Cloud Shell を使用している場合は、この操作は必要ありません。

詳細については、ローカル開発環境の認証を設定するをご覧ください。

次に例を示します。

gcloud alloydb instances update INSTANCE \
--cluster=CLUSTER \
--project=PROJECT \
--region=REGION \
--insights-config-query-string-length=QUERY_LENGTH \
--insights-config-query-plans-per-minute=QUERY_PLANS \
--insights-config-record-application-tags \
--insights-config-record-client-address

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

<var>CLUSTER</var>: 更新するインスタンスの ID
<var>CLUSTER</var>: インスタンスのクラスタの ID
<var>PROJECT</var>: クラスタのプロジェクトの ID
<var>REGION</var>: クラスタのリージョン（例: us-central1）
<var>QUERY_LENGTH</var>: クエリの長さ（256 ～ 4,500）
<var>QUERY_PLANS</var>: 1 分あたりに構成するクエリプランの数

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

--insights-config-query-string-length: デフォルトのクエリ長の上限を 256 ～ 4,500 バイトに設定します。デフォルトのクエリ長は 1,024 バイトです。分析クエリの場合はより長いほうが便利ですが、必要なメモリ量が増えます。クエリ長を変更するには、インスタンスを再起動する必要があります。長さの上限を超えるクエリにもタグを追加できます。
--insights-config-query-plans-per-minute: デフォルトでは、インスタンス上のすべてのデータベースで、実行されるクエリプランのサンプルが 1 分間に最大 5 個キャプチャされます。この値を 1 ～ 20 の範囲で変更します。サンプリングを無効にするには、0 を入力します。サンプリングレートを上げると、通常は得られるデータポイントの数が増えますが、パフォーマンスのオーバーヘッドが増加する可能性があります。
--insights-config-record-client-address: クエリの送信元であるクライアント IP アドレスを保存します。これにより、そのデータをグループ化して、そのデータに対して指標を実行できます。クエリは複数のホストから送信されます。クライアント IP アドレスからのクエリのグラフを確認すると、問題の原因を特定しやすくなります。クライアント IP アドレスを保存しない場合は、--no-insights-config-record-client-address を使用します。
--insights-config-record-application-tags: リクエストを行っている API とモデルビューコントローラ（MVC）のルート決定や、指標を実行するためのデータのグループ化に役立つアプリケーションタグを保存します。このオプションでは、特定のタグセットを使用してクエリにコメントする必要があります。アプリケーションタグを保存しない場合は、--no-insights-config-record-application-tags を使用します。

Terraform

Terraform を使用してクエリ分析情報を構成するには、google_alloydb_instance リソースを使用します。

次に例を示します。

  query_insights_config {
    query_string_length = QUERY_STRING_LENGTH_VALUE
    record_application_tags = RECORD_APPLICATION_TAG_VALUE
    record_client_address = RECORD_CLIENT_ADDRESS_VALUE
    query_plans_per_minute = QUERY_PLANS_PER_MINUTE_VALUE5
  }

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

QUERY_STRING_LENGTH_VALUE: クエリ文字列の長さ。デフォルト値は 1024 です。256 ～ 4500 の整数を指定できます。
RECORD_APPLICATION_TAG_VALUE: インスタンスのアプリケーションタグを記録します。デフォルト値は true です。
RECORD_CLIENT_ADDRESS_VALUE: インスタンスのクライアントアドレスを記録します。デフォルト値は true です。
QUERY_PLANS_PER_MINUTE_VALUE: すべてのクエリを合計した 1 分あたりの Insights によってキャプチャされたクエリ実行プランの数。デフォルト値は 5 です。0 ～ 20 の整数を指定できます。

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

クエリ分析情報の構成が追加されたサンプルインスタンス構成は次のようになります。
```
resource "google_alloydb_instance" "instance_name" {
provider = "google-beta"
cluster       = google_alloydb_cluster.default.name
instance_id   = "instance_id"
instance_type = "PRIMARY"

machine_config {
 cpu_count = 8
}

query_insights_config {
query_string_length = 1024
record_application_tags = false
record_client_address = false
query_plans_per_minute = 5
}

depends_on = [google_alloydb_instance.default]
}
```

REST v1

この例では、AlloyDB インスタンスでオブザーバビリティ設定を構成します。この呼び出しのパラメータの一覧については、メソッド: projects.locations.clusters.instances.patch をご覧ください。

Query Insights の設定を構成するには、必要に応じてオプションフィールドを変更します。この呼び出しのフィールドの一覧については、QueryInsightsInstanceConfig をご覧ください。

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

CLUSTER_ID: 作成するクラスタの ID。先頭は英小文字にします。英小文字、数字、ハイフンを使用できます。
PROJECT_ID: クラスタを配置するプロジェクトの ID。
LOCATION_ID: クラスタのリージョンの ID。
INSTANCE_ID: 作成するプライマリインスタンスの名前。

インスタンス構成を変更するには、次の PATCH リクエストを使用します。

PATCH https://alloydb.googleapis.com/v1beta/{instance.name=projects/PROJECT_ID/locations/LOCATION_ID/clusters/CLUSTER_ID/instances/INSTANCE_ID?updateMask=observabilityConfig.enabled}

すべてのオブザーバビリティフィールドを構成するリクエストの JSON 本文は次のようになります。

{
  "queryStringLength": integer,
  "recordApplicationTags": boolean,
  "recordClientAddress": boolean,
  "queryPlansPerMinute": integer
}

クエリのパフォーマンスを向上させる手順

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

クエリ分析情報は、クエリのパフォーマンスの問題を検出して分析するのに役立ちます。クエリ分析情報では、次の 4 つの手順でクエリのトラブルシューティングを行います。

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

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

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

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

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

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

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

[クエリとタグ] セクションでは、選択したクエリまたは SQL クエリタグのクエリ負荷をフィルタまたは並べ替えることができます。

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

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

デフォルトでは、テーブルは選択した期間内の合計実行時間でクエリを並べ替えます。

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

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

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

UTILITY COMMAND というラベルの付いたクエリには通常、BEGIN、COMMIT、EXPLAIN コマンド、またはラッパーコマンドが含まれます。
データベース。クエリが実行されたデータベース。
負荷（合計実行時間別） / 負荷（CPU 別） / 負荷（IO 待機別） / 負荷（ロック待機別）。これらのオプションにより、特定のクエリをフィルタリングして、各オプションの最大負荷を見つけることができます。
平均実行時間（ミリ秒）。すべてのサブタスクがすべての並列ワーカーでクエリを完了するために要する合計時間。詳細については、平均実行時間と継続時間をご覧ください。
呼び出された回数。アプリケーションによってクエリが呼び出された回数。
取得した平均行。クエリに対して取得された行数の平均。

Query Insights は正規化されたクエリを表示します。つまり、文字定数は $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

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

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

アプリケーションのトラブルシューティングを行うには、最初に SQL クエリにタグを追加する必要があります。

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

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

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

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

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

図 5 は、タグに対応した負荷を表示するクエリ分析情報ダッシュボードを示しています。グラフの下には、タグの一覧が表示されます。

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

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

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

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

[負荷（合計実行時間別）] ヘッダーをクリックして、リストを降順で並べ替えます。
負荷が最も高く、他のクエリより時間がかかっているクエリまたはタグをクリックします。

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

クエリを選択した場合は、選択したクエリの概要が表示されます。

タグを選択した場合は、選択したタグの概要が表示されます。

特定のクエリまたはタグの負荷を調査する

[データベースの負荷 - 特定のクエリ] グラフは、選択した正規化クエリが選択したクエリで時間の経過に伴って行った作業量（CPU 秒）の測定結果を示します。実時間の 1 分間隔で完了した正規化クエリで要した時間を使用して、負荷を計算します。テーブルの上部に、（集計と PII の理由から文字が削除された）正規化されたクエリの最初の 1, 024 文字が表示されます。全クエリのグラフと同様に、データベース、ユーザー、クライアントアドレスで、特定のクエリの負荷をフィルタリングできます。クエリ負荷は、CPU 容量、CPU と CPU 待機、IO 待機、ロック待機に分割されます。

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

レイテンシを調べる

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

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

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

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

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

負荷が最も高い領域と時間が見つかったら、さらにドリルダウンできます。

クラスタ全体のレイテンシを調べる

クラスタ内のインスタンスにわたるクエリまたはタグの P99 レイテンシを調べるには、クラスタ全体での同じクエリに対する P99 レイテンシグラフを使用します。

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

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

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

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

クエリプランは、クエリに対して実行される各オペレーションのレイテンシと費用を表示します。

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

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

問題の原因の特定

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

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

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

この画像は、上位のクライアントアドレスと上位のユーザーに関する情報を示しています。

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

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

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

SQL クエリへのタグの追加

SQL クエリにタグを追加すると、アプリケーションのトラブルシューティングが簡単になります。SQL クエリにタグを追加するには、sqlcommenter を使用します。このとき、オブジェクトリレーショナルマッピング（ORM）で自動的に追加することも、手動で追加することもできます。

ORM での sqlcommenter の使用

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

ORM と sqlcommenter を組み合わせて使用している場合、タグが自動的に作成されます。カスタムコードの変更やアプリケーションへの追加は必要もありません。

sqlcommenter はアプリケーションサーバーにインストールできます。インストルメンテーションライブラリを使用すると、MVC フレームワークに関連するアプリケーション情報を、SQL コメントとしてクエリとともにデータベースに伝播できます。データベースはこれらのタグを取得し、正規化されたクエリによって集計される統計とは無関係に、タグによる統計の記録と集計を開始します。クエリ分析情報でタグが表示されるため、クエリ負荷の原因となったアプリケーションを把握できます。この情報により、パフォーマンスの問題を引き起こしているアプリケーションコードを検出できます。

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 を使用する方法については、GitHub の sqlcommenter のドキュメントをご覧ください。

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

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

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

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

実行時間と実行時間

クエリ分析情報には、平均実行時間（ms）の指標があります。これは、すべての並列ワーカーのすべてのサブタスクがクエリを完了するのに要する合計時間を報告します。この指標は、CPU オーバーヘッドが最も大きいクエリを見つけて最適化することで、データベースの総リソース使用率を最適化するのに役立ちます。

経過時間を表示するには、psql クライアントで \timing コマンドを実行してクエリの所要時間を測定します。クエリの受信から PostgreSQL サーバーがレスポンスを送信するまでの時間を測定します。この指標は、特定のクエリに時間がかかっている理由を分析し、実行時間を短縮するために最適化するかどうかを判断するのに役立ちます。

クエリが単一のタスクによってシングルスレッドで完了した場合、所要時間と平均実行時間は変わりません。

AlloyDB の高度な Query Insights 機能を有効にする

AlloyDB ダッシュボードの高度な Query Insights 機能は、標準の Query Insights ダッシュボードに統合されています。高度なクエリ分析情報の機能を有効にする方法については、高度なクエリ分析情報の機能を使用してクエリのパフォーマンスを改善するをご覧ください。