이 페이지에서는 쿼리 통계 대시보드를 사용하여 성능 문제를 감지하고 분석하는 방법을 설명합니다.
Databases의 Gemini 지원을 사용하여 PostgreSQL용 Cloud SQL 리소스를 관찰하고 문제를 해결할 수 있습니다. 자세한 내용은 Gemini 지원을 통한 관찰 및 문제 해결을 참조하세요.소개
쿼리 통계는 Cloud SQL 데이터베이스의 쿼리 성능 문제를 감지하고 진단하고 방지하는 데 도움이 됩니다. 직관적인 모니터링을 지원하고 성능 문제를 감지하는 것뿐만 아니라 근본 원인까지 파악하는 데 도움을 주는 진단 정보를 제공합니다.
쿼리 통계를 사용하면 애플리케이션 수준에서 성능을 모니터링하고 모델, 뷰, 컨트롤러, 경로, 사용자, 호스트별로 애플리케이션 스택에서 문제가 있는 쿼리의 소스를 추적할 수 있습니다. 쿼리 통계 도구는 개방형 표준 및 API를 사용하여 기존 애플리케이션 모니터링(APM) 도구 및 Google Cloud 서비스와 통합할 수 있습니다. 그러면 원하는 도구를 사용하여 쿼리 문제를 모니터링하고 해결할 수 있습니다.
쿼리 통계는 다음 단계에 대한 안내를 통해 Cloud SQL 쿼리 성능을 향상시킬 수 있게 해줍니다.
- 상위 쿼리의 데이터베이스 부하를 확인합니다.
- 잠재적으로 문제가 발생할 수 있는 쿼리 또는 태그를 식별합니다.
- 쿼리 또는 태그를 조사하여 문제를 식별합니다.
- 문제 원인을 trace합니다.
쿼리 통계는 모든 Cloud SQL 머신 유형에서 지원되며 모든 Google Cloud 리전에서 제공됩니다.
가격 책정
쿼리 통계는 추가 비용 없이 사용할 수 있습니다. 쿼리 통계 대시보드에서 1주일 분량의 데이터에 액세스할 수 있습니다.
쿼리 통계는 Cloud SQL 인스턴스 저장공간을 전혀 차지하지 않습니다. 측정항목은 Cloud Monitoring에 저장됩니다. API 요청은 Cloud Monitoring 가격 책정을 참조하세요. Cloud Monitoring에는 추가 비용 없이 사용할 수 있는 등급이 있습니다.
시작하기 전에
쿼리 계획을 보거나 엔드 투 엔드 trace를 수행하려면 특정 IAM 권한이 필요합니다. 커스텀 역할을 만들고 여기에 cloudtrace.traces.get
IAM 권한을 추가합니다. 그런 후 쿼리 통계를 사용해야 하는 각 사용자 계정에 이 역할을 추가합니다.
쿼리 계획과 엔드 투 엔드 뷰를 보려면 Google Cloud 프로젝트에 Trace API가 사용 설정되어 있어야 합니다. 이 설정을 사용하면 Google Cloud 프로젝트가 추가 비용 없이 인증된 소스에서 trace 데이터를 수신할 수 있습니다. 이 데이터를 사용하면 인스턴스의 성능 문제를 감지하고 진단할 수 있습니다.
Trace API가 사용 설정되었는지 확인하려면 다음 단계를 수행합니다.
- Google Cloud Console에서 API 및 서비스로 이동합니다.
- API 및 서비스 사용 설정을 클릭합니다.
- 검색창에
Trace API
를 입력합니다. - API 사용 설정됨이 표시된 경우는 이 API가 사용 설정되어 있으므로 아무 조치를 하지 않아도 됩니다. 그렇지 않은 경우에는 사용 설정을 클릭합니다.
쿼리 통계 사용 설정
쿼리 통계 측정항목은 저장 상태에서 암호화됩니다. Cloud SQL 대시보드에 대한 액세스 권한이 있는 사용자는 쿼리 통계 대시보드에서 쿼리 통계 측정항목에 액세스할 수 있습니다. 인스턴스를 업데이트할 권한이 있으면 쿼리 통계를 구성할 수 있습니다. Cloud SQL 인스턴스에 필요한 권한 목록은 Cloud SQL 프로젝트 액세스 제어를 참조하세요. 이러한 권한이 없는데 인스턴스에 쿼리 통계를 사용 설정하려면 관리자에게 문의하세요.
콘솔
인스턴스에 쿼리 통계 사용 설정
-
Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- 인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
- 구성 타일에서 구성 수정을 클릭합니다.
- 구성 옵션 섹션에서 쿼리 통계를 펼칩니다.
- 쿼리 통계 사용 설정 체크박스를 선택합니다.
- (선택사항) 다음 쿼리 통계 옵션을 하나 이상을 선택합니다.
- 저장을 클릭합니다.
클라이언트 IP 주소 저장
기본값: false
쿼리가 시작되는 클라이언트 IP 주소를 저장하고 측정항목을 실행할 수 있도록 데이터를 그룹화할 수 있게 해줍니다. 쿼리는 두 개 이상의 호스트에서 가져옵니다. 클라이언트 IP 주소에서 쿼리 그래프를 검토하면 문제의 원인을 식별하는 데 도움이 될 수 있습니다.
애플리케이션 태그 저장
기본값: false
요청을 실행하는 API 및 MVC(Model-View-Controller) 경로를 확인하고 이에 대해 측정항목을 실행할 데이터를 그룹화하는 데 도움이 되는 애플리케이션 태그를 저장합니다. 이 옵션을 사용하려면 sqlcommenter 오픈소스 객체 관계형 매핑(ORM) 자동 계측 라이브러리를 사용하여 특정 태그 집합을 사용하여 쿼리에 주석을 추가해야 합니다. 이 정보는 쿼리 통계로 문제의 원인과 문제가 발생한 MVC를 식별하는 도움이 됩니다. 애플리케이션 경로를 사용하면 애플리케이션 모니터링을 수행할 수 있습니다.
쿼리 길이 맞춤설정
기본값: 1024
쿼리 길이 제한을 256~4500바이트의 지정된 값으로 설정합니다. 쿼리 길이가 길수록 분석 쿼리에 더 유용하지만 더 많은 메모리가 필요합니다. 쿼리 길이를 변경하려면 인스턴스를 다시 시작해야 합니다. 길이 제한을 초과하는 쿼리에도 태그를 추가할 수 있습니다.
최대 샘플링 레이트 설정
기본값: 5
최대 샘플링 레이트를 설정합니다. 샘플링 레이트는 인스턴스의 모든 데이터베이스에 분 단위로 캡처되는 실행된 쿼리 계획 샘플 수입니다. 이 값을 0(샘플링 사용 중지)에서 20 사이의 숫자로 변경하세요. 샘플링 레이트를 늘리면 더 많은 데이터 포인트를 얻을 가능성이 있지만 성능 오버헤드가 증가할 수 있습니다.
-
Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- 행에서 작업 더보기 메뉴를 클릭합니다.
- 쿼리 통계 사용 설정을 선택합니다.
- 대화상자에서 여러 인스턴스에 쿼리 통계 사용 설정 체크박스를 선택합니다.
- 사용 설정을 클릭합니다.
- 이후 대화상자에서 쿼리 통계를 사용 설정할 인스턴스를 선택합니다.
- 쿼리 통계 사용 설정을 클릭합니다.
gcloud
gcloud
를 사용하여 Cloud SQL 인스턴스에 쿼리 통계를 사용 설정하려면 INSTANCE_ID를 인스턴스의 ID로 바꾼 후 다음과 같이 --insights-config-query-insights-enabled
플래그와 함께 gcloud sql instances patch
를 실행합니다.
gcloud sql instances patch INSTANCE_ID \ --insights-config-query-insights-enabled
또한 다음 선택적인 플래그를 하나 이상 사용합니다.
--insights-config-record-client-address
쿼리가 시작되는 클라이언트 IP 주소를 저장하고 측정항목을 실행할 수 있도록 데이터를 그룹화할 수 있게 해줍니다. 쿼리는 두 개 이상의 호스트에서 가져옵니다. 클라이언트 IP 주소에서 쿼리 그래프를 검토하면 문제의 원인을 식별하는 데 도움이 될 수 있습니다.
--insights-config-record-application-tags
요청을 실행하는 API 및 MVC(Model-View-Controller) 경로를 확인하고 이에 대해 측정항목을 실행할 데이터를 그룹화하는 데 도움이 되는 애플리케이션 태그를 저장합니다. 이 옵션을 사용하려면 특정 태그 집합을 사용하여 쿼리에 주석을 추가해야 합니다. 이렇게 하려면 sqlcommenter 오픈소스 객체 관계형 매핑(ORM) 자동 계측 라이브러리를 사용합니다. 이 정보는 쿼리 통계로 문제의 원인과 문제가 발생한 MVC를 식별하는 도움이 됩니다. 애플리케이션 경로를 사용하면 애플리케이션 모니터링을 수행할 수 있습니다.
--insights-config-query-string-length
기본 쿼리 길이 제한을 256~4500바이트의 지정된 값으로 설정합니다. 기본 쿼리 길이는 1024바이트입니다. 쿼리 길이가 길수록 분석 쿼리에 더 유용하지만 더 많은 메모리가 필요합니다. 쿼리 길이를 변경하려면 인스턴스를 다시 시작해야 합니다. 길이 제한을 초과하는 쿼리에도 태그를 추가할 수 있습니다.
--query_plans_per_minute
기본적으로 인스턴스의 모든 데이터베이스에서 실행된 쿼리 계획 샘플이 분당 최대 5개까지 캡처됩니다. 이 값을 0(샘플링 사용 중지)에서 20 사이의 숫자로 변경하세요. 샘플링 레이트를 늘리면 더 많은 데이터 포인트를 얻을 가능성이 있지만 성능 오버헤드가 추가될 수 있습니다.
다음을 바꿉니다.
- INSIGHTS_CONFIG_QUERY_STRING_LENGTH: 저장할 쿼리 문자열 길이(바이트)입니다.
- API_TIER_STRING: 인스턴스에 사용할 커스텀 인스턴스 구성입니다.
- REGION: 인스턴스의 리전입니다.
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 인스턴스에 대해 쿼리 통계를 사용 설정하려면 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" }
Terraform
Terraform을 사용하여 Cloud SQL 인스턴스에 대한 쿼리 통계를 사용 설정하려면 query_insights_enabled
플래그를 true
로 설정합니다.
또한 다음과 같은 선택적인 플래그를 하나 이상 사용할 수 있습니다.
query_string_length
: 기본값은 1024
이며 바이트 단위로 256
~4500
사이의 값으로 구성할 수 있습니다.record_application_tags
: 쿼리에서 애플리케이션 태그를 기록하려면 값을 true
로 설정합니다.record_client_address
: 클라이언트 IP 주소를 기록하려면 값을 true
로 설정합니다.query_plans_per_minute
: 기본값은 5
이며 5
~20
사이의 값으로 구성할 수 있습니다. resource "google_sql_database_instance" "INSTANCE_NAME" { name = "INSTANCE_NAME" database_version = "POSTGRESQL_VERSION" region = "REGION" root_password = "PASSWORD" deletion_protection = false # set to true to prevent destruction of the resource settings { tier = "DB_TIER" insights_config { query_insights_enabled = true query_string_length = 2048 # Optional record_application_tags = true # Optional record_client_address = true # Optional query_plans_per_minute = 10 # Optional } } }
Google Cloud 프로젝트에 Terraform 구성을 적용하려면 다음 섹션의 단계를 완료하세요.
Cloud Shell 준비
- Cloud Shell을 실행합니다.
-
Terraform 구성을 적용할 기본 Google Cloud 프로젝트를 설정합니다.
이 명령어는 프로젝트당 한 번만 실행하면 되며 어떤 디렉터리에서도 실행할 수 있습니다.
export GOOGLE_CLOUD_PROJECT=PROJECT_ID
Terraform 구성 파일에서 명시적 값을 설정하면 환경 변수가 재정의됩니다.
디렉터리 준비
각 Terraform 구성 파일에는 자체 디렉터리(루트 모듈이라고도 함)가 있어야 합니다.
-
Cloud Shell에서 디렉터리를 만들고 해당 디렉터리 내에 새 파일을 만드세요. 파일 이름에는
.tf
확장자가 있어야 합니다(예:main.tf
). 이 튜토리얼에서는 파일을main.tf
라고 합니다.mkdir DIRECTORY && cd DIRECTORY && touch main.tf
-
튜토리얼을 따라 하는 경우 각 섹션이나 단계에서 샘플 코드를 복사할 수 있습니다.
샘플 코드를 새로 만든
main.tf
에 복사합니다.필요한 경우 GitHub에서 코드를 복사합니다. 이는 Terraform 스니펫이 엔드 투 엔드 솔루션의 일부인 경우에 권장됩니다.
- 환경에 적용할 샘플 매개변수를 검토하고 수정합니다.
- 변경사항을 저장합니다.
-
Terraform을 초기화합니다. 이 작업은 디렉터리당 한 번만 수행하면 됩니다.
terraform init
원하는 경우 최신 Google 공급업체 버전을 사용하려면
-upgrade
옵션을 포함합니다.terraform init -upgrade
변경사항 적용
-
구성을 검토하고 Terraform에서 만들거나 업데이트할 리소스가 예상과 일치하는지 확인합니다.
terraform plan
필요에 따라 구성을 수정합니다.
-
다음 명령어를 실행하고 프롬프트에
yes
를 입력하여 Terraform 구성을 적용합니다.terraform apply
Terraform에 '적용 완료' 메시지가 표시될 때까지 기다립니다.
- 결과를 보려면 Google Cloud 프로젝트를 엽니다. Google Cloud 콘솔에서 UI의 리소스로 이동하여 Terraform이 리소스를 만들었거나 업데이트했는지 확인합니다.
쿼리 완료 후 수분 내에 쿼리 통계에서 측정항목을 사용할 수 있습니다. Cloud Monitoring 데이터 보관 정책을 검토합니다. 쿼리 통계 Trace는 Cloud Trace에 저장됩니다. Cloud Trace 데이터 보관 정책을 검토합니다.
쿼리 통계 대시보드 보기
쿼리 통계 대시보드에는 선택한 요소를 기반으로 쿼리 부하가 표시됩니다. 쿼리 부하는 선택한 기간 내의 인스턴스에 있는 모든 쿼리의 전체 작업을 측정한 것입니다. 대시보드는 쿼리 부하를 볼 수 있는 일련의 필터를 제공합니다.
쿼리 통계 대시보드를 열려면 다음 단계를 수행합니다.
- 인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
- 왼쪽 탐색 패널에서 쿼리 통계 탭을 선택하거나 쿼리 통계로 이동하여 쿼리 및 성능에 대한 자세한 정보 보기 링크를 클릭합니다.
쿼리 통계 대시보드가 열립니다. 인스턴스에 대한 다음 정보가 표시됩니다.
- 데이터베이스: 특정 데이터베이스 또는 모든 데이터베이스의 쿼리 부하를 필터링합니다.
- 사용자: 특정 사용자 계정의 쿼리 부하를 필터링합니다.
- 클라이언트 주소: 특정 IP 주소의 쿼리 부하를 필터링합니다.
- 시간 범위: 시간, 일, 주, 개월 또는 커스텀 범위와 같은 시간 범위별로 쿼리 부하를 필터링합니다.
- 데이터베이스 부하 그래프: 필터링된 데이터를 기반으로 쿼리 부하 그래프를 표시합니다.
- CPU 용량, CPU 및 CPU 대기, IO 대기, 잠금 대기: 선택한 옵션에 따라 부하를 필터링합니다. 이러한 각 필터에 대한 자세한 내용은 상위 쿼리의 데이터베이스 부하 보기를 참조하세요.
- 쿼리 및 태그. 선택한 쿼리 또는 선택한 SQL 쿼리 태그에 따라 쿼리 부하를 필터링합니다. 데이터베이스 부하 필터링을 참조하세요.
모든 쿼리의 데이터베이스 부하를 보기
데이터베이스 쿼리 부하는 선택한 데이터베이스에서 제외된 모든 쿼리가 시간에 따라 수행되는 작업을 측정(CPU-초)합니다. 실행 중인 각 쿼리는 CPU 리소스, IO 리소스 또는 잠금 리소스를 사용하거나 대기합니다. 데이터베이스 쿼리 부하는 지정된 기간에 완료된 모든 쿼리에 걸린 시간과 실제로 경과한 시간의 비율입니다.
최상위 수준 쿼리 통계 대시보드에 데이터베이스 부하 - 모든 상위 쿼리 그래프가 표시됩니다. 대시보드의 드롭다운 메뉴를 사용하면 특정 데이터베이스, 사용자 또는 클라이언트 주소에 대한 그래프를 필터링할 수 있습니다.
그래프에서 색상이 지정된 선은 쿼리 부하를 다음 4개의 카테고리로 구분합니다.
- CPU 용량: 인스턴스에서 사용할 수 있는 CPU 수입니다.
CPU 및 CPU 대기: 활성 상태의 쿼리에 걸린 시간과 실제로 경과한 시간의 비율입니다. IO 및 잠금 대기는 활성 상태의 쿼리를 차단하지 않습니다. 이 측정항목은 쿼리가 CPU를 사용하고 있거나 다른 프로세스가 CPU를 사용하는 동안 Linux 스케줄러가 쿼리 실행 서버 프로세스를 예약하도록 기다리고 있음을 의미할 수 있습니다.
IO 대기: IO 대기 중인 쿼리에 걸린 시간과 실제로 경과한 시간의 비율입니다. IO 대기에는 읽기 IO 대기 및 쓰기 IO 대기가 포함됩니다.
PostgreSQL 이벤트 테이블을 참조하세요.
IO 대기에 대한 정보를 분석하려면 Cloud Monitoring에서 확인할 수 있습니다. 자세한 내용은 Cloud SQL 측정항목을 참조하세요.
잠금 대기: 잠금 대기 중인 쿼리에 걸린 시간과 실제로 경과한 시간의 비율입니다. 여기에는 Lock 대기, LwLock 대기, Buffer pin Lock 대기가 포함됩니다. 잠금 대기에 대한 분석 정보를 보려면 Cloud Monitoring을 사용합니다. 자세한 내용은 Cloud SQL 측정항목을 참조하세요.
그래프를 검토하고 필터링 옵션을 사용하여 다음 질문에 답하세요.
- 쿼리 부하가 높은가요? 시간이 지남에 따라 그래프가 급증하거나 상승했나요? 높은 부하가 없으면 쿼리에 문제가 없는 것입니다.
- 부하는 얼마 동안 높은 상태였나요? 지금만 높은가요? 아니면 오랜 시간 동안 높았나요? 범위 선택기를 사용하여 여러 기간을 선택해서 문제가 지속된 기간을 확인합니다. 쿼리 부하 급증이 관측된 기간을 확인하려면 화면을 확대합니다. 타임라인을 최대 1주까지 표시하려면 화면을 축소합니다.
- 부하가 높은 원인은 무엇인가요? 옵션에 따라 CPU 용량, CPU 및 CPU 대기, 잠금 대기 또는 IO 대기를 검사하도록 선택할 수 있습니다. 이러한 각 옵션의 그래프는 부하가 가장 높은 지점을 쉽게 식별할 수 있도록 색상별로 다르게 표시됩니다. 그래프의 어두운 파란색 선은 시스템의 최대 CPU 용량을 보여줍니다. 쿼리 부하를 최대 CPU 시스템 용량과 비교할 수 있습니다. 이 비교를 통해 인스턴스의 CPU 리소스가 부족한지 확인할 수 있습니다.
- 어떤 데이터베이스에서 부하가 발생하나요? 데이터베이스 드롭다운 메뉴에서 다른 데이터베이스를 선택하여 부하가 가장 높은 데이터베이스를 찾습니다.
- 특정 사용자 또는 IP 주소로 인해 더 높은 부하가 발생하나요? 드롭다운 메뉴에서 다른 사용자와 주소를 선택하여 더 높은 부하를 유발하는 사용자 및 주소를 식별합니다.
데이터베이스 부하 필터링
쿼리 또는 태그로 데이터베이스 부하를 필터링할 수 있습니다.
쿼리로 필터링
쿼리 테이블에는 쿼리 부하가 가장 많이 발생하는 쿼리의 개요가 제공됩니다. 테이블은 쿼리 통계 대시보드에서 선택한 기간 및 옵션에 대한 정규화된 모든 쿼리를 보여줍니다. 이 테이블은 선택한 기간의 총 실행 시간을 기준으로 쿼리를 정렬합니다.
테이블을 정렬하려면 쿼리 필터링에서 열 제목 또는 속성을 선택합니다. 테이블에는 다음 속성이 표시됩니다.
쿼리: 정규화된 쿼리 문자열입니다. 쿼리 통계에는 기본적으로 쿼리 문자열에 1024자만 표시됩니다.
UTILITY COMMAND
라벨이 지정된 쿼리에는 일반적으로BEGIN
,COMMIT
,EXPLAIN
명령어 또는 래퍼 명령어가 포함됩니다.데이터베이스: 쿼리가 실행된 데이터베이스입니다.
총 시간별 부하/CPU별 부하/IO 대기별 부하/잠금 대기별 부하: 특정 쿼리를 필터링하여 가장 큰 부하를 찾을 수 있는 옵션입니다.
평균 실행 시간(밀리초): 쿼리가 실행되는 평균 시간입니다.
호출된 횟수: 애플리케이션이 쿼리를 호출한 횟수입니다.
반환된 행 평균: 쿼리로 반환된 평균 행 수입니다.
쿼리 통계는 정규화된 쿼리만 저장하고 표시합니다. 기본적으로 쿼리 통계는 IP 주소 또는 태그 정보를 수집하지 않습니다. 이 정보를 수집하도록 쿼리 통계를 사용 설정하고, 필요에 따라 수집을 사용 중지할 수 있습니다. 쿼리 계획 trace는 상수 값을 수집하거나 저장하지 않으며 상수가 표시할 수 있는 개인 식별 정보를 삭제합니다.
PostgreSQL 9.6 및 10의 경우 쿼리 통계에 정규화된 쿼리가 표시됩니다. 즉 리터럴 상수 값이 ?
로 바뀝니다. 다음 예시에서는 이름 상수가 삭제되고 ?
로 바뀝니다.
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 쿼리에 태그를 추가해야 합니다. 쿼리 부하 태그는 시간 경과에 따라 선택된 태그의 쿼리 부하를 분석합니다.
쿼리 통계는 ORM을 사용하여 빌드된 애플리케이션의 성능 문제를 진단하기 위한 애플리케이션 중심 모니터링을 제공합니다. 전체 애플리케이션 스택을 담당하는 경우 쿼리 통계는 애플리케이션 뷰에서 쿼리 모니터링을 제공합니다. 쿼리 태그 지정은 비즈니스 로직 또는 마이크로서비스 등의 상위 수준 구성에서 문제를 찾는 데 도움이 됩니다.
결제, 인벤토리, 비즈니스 분석, 배송 태그와 같은 비즈니스 로직으로 쿼리를 태그할 수 있습니다. 그런 다음 다양한 비즈니스 로직이 만드는 쿼리 부하를 찾을 수 있습니다. 예를 들어 오후 1시의 비즈니스 분석 태그 급증이나 이전 1주 동안의 비정상적인 결제 서비스 증가 추세와 같은 예기치 않은 이벤트가 관찰될 수 있습니다.
태그용 데이터베이스 부하를 계산하기 위해 쿼리 통계는 사용자가 선택한 태그를 사용하는 모든 쿼리에 걸린 시간을 사용합니다. 이 도구는 실제 경과 시간을 사용하여 분 경계에서 완료 시간을 계산합니다.
쿼리 통계 대시보드에서 태그 테이블을 보려면 태그를 선택합니다. 태그 테이블은 총 시간별 총 부하에 따라 태그를 정렬합니다.
태그 필터링에서 속성을 선택하거나 열 제목을 클릭하여 테이블을 정렬할 수 있습니다. 테이블에는 다음 속성이 표시됩니다.
- 작업, 컨트롤러, 프레임워크, 경로, 애플리케이션, DB 드라이버: 쿼리에 추가한 각 속성이 열로 표시됩니다. 태그로 필터링하려면 이러한 속성을 하나 이상 추가해야 합니다.
- 총 시간별 부하/CPU별 부하/IO 대기별 부하/잠금 대기별 부하: 특정 쿼리를 필터링하여 각 옵션의 최대 부하를 찾는 옵션입니다.
- 평균 실행 시간(밀리초): 쿼리가 실행되는 평균 시간입니다.
- 반환된 행 평균: 쿼리로 반환된 평균 행 수입니다.
- 호출된 횟수: 애플리케이션이 쿼리를 호출한 횟수입니다.
- 데이터베이스: 쿼리가 실행된 데이터베이스입니다.
특정 쿼리 또는 태그 검사
쿼리 또는 태그가 문제의 근본 원인인지 확인하려면 각각 쿼리 탭 또는 태그 탭에서 다음을 수행합니다.
- 목록을 내림차순으로 정렬하려면 총 시간별 부하 제목을 클릭합니다.
- 목록 상단에서 쿼리 또는 태그를 클릭합니다. 부하가 가장 높고 다른 것보다 시간이 오래 걸립니다.
선택한 쿼리 또는 태그의 세부정보가 표시된 대시보드가 열립니다.
특정 쿼리 부하 검사
선택한 쿼리에 대한 대시보드가 다음과 같이 표시됩니다.
데이터베이스 부하 - 특정 쿼리 그래프는 정규화된 쿼리가 시간 경과에 따라 선택된 쿼리에서 수행한 작업의 측정값(CPU-초)을 보여줍니다. 부하를 계산하기 위해 실제 경과 시간에 대한 분 경계에서 완료된 정규화된 쿼리가 걸린 총 시간을 사용합니다. 테이블 위에서 집계 및 PII 이유로 리터럴이 삭제된 상태로 정규화된 쿼리의 처음 1024 문자가 표시됩니다.
총 쿼리 그래프와 마찬가지로 데이터베이스, 사용자, 클라이언트 주소를 기준으로 특정 쿼리의 부하를 필터링할 수 있습니다. 쿼리 부하가 CPU 용량, CPU 및 CPU 대기, IO 대기 및잠금 대기로 분할됩니다.
특정 태그 지정된 쿼리 부하 검사
선택한 태그에 대한 대시보드가 다음과 같이 표시됩니다. 예를 들어 마이크로서비스 결제의 모든 쿼리가 payment
로 태그가 지정된 경우 payment
태그를 보고 쿼리 부하의 양 추세를 확인할 수 있습니다.
데이터베이스 부하 - 특정 태그 그래프에 선택한 태그와 일치하는 쿼리가 선택한 데이터베이스에서 일정 시간 동안 수행된 작업의 측정(CPU 초)이 표시됩니다. 총 쿼리 그래프와 마찬가지로 데이터베이스, 사용자, 클라이언트 주소를 기준으로 특정 태그의 부하를 필터링할 수 있습니다.
샘플링된 쿼리 계획의 작업 검사
쿼리 계획은 쿼리의 샘플을 가져와서 개별 작업으로 나눕니다. 쿼리의 각 작업을 설명하고 분석합니다.
쿼리 계획 샘플 그래프에는 특정 시간에 실행되는 모든 쿼리 계획과 각 계획을 실행하는 데 걸린 시간이 표시됩니다. 쿼리 계획 샘플이 분당 캡처되는 속도를 변경할 수 있습니다. 쿼리 통계 사용 설정을 참조하세요.
기본적으로 오른쪽 패널에는 쿼리 계획 샘플 그래프에 표시된 대로 가장 오래 걸리는 샘플 쿼리 계획의 세부정보가 표시됩니다. 다른 샘플 쿼리 계획의 세부정보를 보려면 그래프에서 관련 원을 클릭합니다. 세부정보를 펼치면 쿼리 계획의 모든 작업 모델이 표시됩니다. 각 작업에는 지연 시간, 반환된 행, 작업 비용이 표시됩니다. 작업을 선택하면 공유 적중 블록, 스키마 유형, 루프, 계획 행 등의 더 많은 세부정보를 볼 수 있습니다.
다음 질문을 확인하여 문제의 범위를 좁혀 보세요.
- 리소스 소비란 무엇인가요?
- 다른 쿼리와는 어떤 연관이 있나요?
- 시간이 지나면 소비가 달라지나요?
지연 시간 검사
지연 시간은 정규화된 쿼리에서 실제 경과 시간으로 완료하는 데 걸린 시간입니다. 지연 시간 그래프를 사용하여 쿼리 또는 태그의 지연 시간을 검사합니다. 지연 시간 대시보드에 이상점 동작을 찾기 위해 50번째, 95번째, 99번째 백분위수 지연 시간이 표시됩니다.
다음 이미지는 CPU 용량, CPU 및 CPU 대기, IO 대기, 잠금 대기에 대해 선택된 필터를 사용하여 특정 쿼리에 대한 50번째 백분위수의 데이터베이스 부하 그래프를 보여줍니다.
쿼리의 일부를 실행하는 데 사용되는 여러 코어로 인해 쿼리의 데이터베이스 부하가 높은 경우에도 병렬 쿼리의 지연 시간은 실제 경과 시간으로 측정됩니다.
다음 질문을 확인하여 문제의 범위를 좁혀 보세요.
- 부하가 높은 원인은 무엇인가요? 옵션을 선택하여 CPU 용량, CPU 및 CPU 대기, I/O 대기 또는 잠금 대기를 확인합니다.
- 부하는 얼마 동안 높은 상태였나요? 지금 현재만 높나요? 아니면 오랜 기간 동안 높은 상태였나요? 부하 성능이 저하된 날짜와 시간을 찾으려면 기간을 변경합니다.
- 지연 시간이 급증했나요? 기간을 변경하여 정규화된 쿼리의 이전 지연 시간을 조사합니다.
문제 원인 trace
부하가 가장 높은 영역과 시간을 찾았으면 trace를 사용한 추가적인 드릴다운으로 문제 원인을 파악합니다.
모델, 뷰, 컨트롤러, 경로, 호스트, 사용자와 같은 문제의 특정 원인을 식별하는 데 도움이 될 수 있도록 쿼리 통계는 컨텍스트 내 엔드 투 엔드 애플리케이션 trace 뷰를 제공합니다. 이 뷰는 특정 요청에 대해 데이터베이스 레이어에서 수행되는 작업을 이해하고, 모델, 뷰, 컨트롤러, 경로에 따라 문제가 되는 쿼리 원인을 찾는 데 도움이 됩니다.
OpenCensus 또는 OpenTelemetry를 사용 설정하면 Opencensus 스팬 정보가 SQL 주석의 태그 정보와 함께 데이터베이스로 전송됩니다. 문제의 원인을 식별하는 데 도움이 될 수 있도록 애플리케이션에서 Cloud Logging으로 전송되는 모든 trace가 데이터베이스 쿼리 계획 trace와 연결됩니다.
샘플 쿼리 화면에서 엔드 투 엔드 탭을 클릭하여 컨텍스트 내 trace를 확인합니다.
문제를 일으킨 클라이언트와 사용자를 확인하려면 상위 클라이언트 주소와 상위 사용자 테이블을 사용하여 가장 높은 부하를 찾습니다. 사용자 또는 IP 주소를 필터에 추가하면 특정 사용자 또는 클라이언트 주소를 자세히 분석할 수 있습니다. 테이블의 세부정보에는 쿼리 부하 비율, 평균 실행 시간(밀리초), 호출 횟수가 포함됩니다.
Cloud Trace를 사용하면 쿼리 계획의 단계마다 엔드 투 엔드 추적을 확인할 수 있습니다. 쿼리 통계 대시보드에서 Trace에서 보기 링크를 클릭하여 Cloud Trace 도구를 엽니다. trace 그래프에는 선택한 기간 동안 실행된 모든 trace가 표시됩니다.
자세한 내용은 trace 찾기 및 보기를 참조하세요.
SQL 쿼리에 태그 추가
SQL 쿼리에 태그를 지정하면 애플리케이션 문제 해결이 간소화됩니다. sqlcommenter를 사용하여 SQL 쿼리에 자동 또는 수동으로 태그를 추가할 수 있습니다.
ORM과 함께 sqlcommenter 사용
SQL 쿼리를 직접 작성하는 대신 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 |
|
자바 |
|
Ruby |
|
Node.js |
|
sqlcommenter 및 ORM 프레임워크에서 이를 사용하는 방법에 대한 자세한 내용은 sqlcommenter 문서를 참조하세요.
sqlcommenter를 사용하여 태그 추가
ORM을 사용하지 않는 경우에는 올바른 SQL 주석 형식으로 sqlcommenter 태그 또는 주석을 SQL 쿼리에 수동으로 추가해야 합니다. 또한 직렬화된 키-값 쌍이 포함된 주석으로 각 SQL 문을 보강해야 합니다. 다음 키 중 하나 이상을 사용하세요.
action=''
controller=''
framework=''
route=''
application=''
db driver=''
쿼리 통계는 다른 모든 키를 삭제합니다.
쿼리 통계 사용 중지
콘솔
Google Cloud Console을 사용하여 Cloud SQL 인스턴스에 대해 쿼리 통계를 사용 중지하려면 다음 단계를 수행합니다.
-
Google Cloud 콘솔에서 Cloud SQL 인스턴스 페이지로 이동합니다.
- 인스턴스의 개요 페이지를 열려면 인스턴스 이름을 클릭합니다.
- 구성 타일에서 구성 수정을 클릭합니다.
- 구성 옵션 섹션에서 쿼리 통계를 펼칩니다.
- 쿼리 통계 사용 설정 체크박스를 선택 취소합니다.
- 저장을 클릭합니다.
gcloud
gcloud
를 사용하여 Cloud SQL 인스턴스의 쿼리 통계를 사용 중지하려면 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 인스턴스에 대해 쿼리 통계를 사용 중지하려면 다음과 같이 queryInsightsEnabled
를 false
로 설정하여 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 측정항목 참조. 쿼리 통계 측정항목 유형 문자열은
database/postgresql/insights
로 시작합니다.
- 블로그: Cloud SQL Insights로 쿼리 성능 문제 해결 기술 향상
- 동영상: Cloud SQL Insights 소개
- 팟캐스트: Cloud SQL Insights
- Insights Codelab
- 블로그: Sqlcommenter 소개: 오픈소스 ORM 자동 계측 라이브러리
- 블로그: Sqlcommenter로 쿼리 태그 지정 사용 설정