활동 추적
데이터베이스 유지 관리의 많은 부분을 차지하는 것은 성능 튜닝입니다. 온-프레미스 데이터베이스에서 검토하는 데 사용하는 것과 동일한 로그 파일을 Azure Database for MySQL/PostgreSQL에서도 계속 사용할 수 있습니다.
Azure로 마이그레이션된 데이터베이스의 경우 계속해서 로그 파일을 검토하여 데이터베이스의 성능이 유지되도록 해야 합니다.
이 단원에서는 PostgreSQL 및 MySQL의 로그 파일이 Azure에서 저장되는 위치와 해당 파일에 어떤 수준의 세부 정보가 포함되어 있는지 알아봅니다.
서버 로그를 사용하여 데이터베이스 활동 추적
Azure Database for MySQL/PostgreSQL에서는 서버 로그에 진단 정보도 기록합니다. 서버 로그는 MySQL 및 PostgreSQL의 네이티브 메시지 로그 파일입니다(Azure Database for MySQL/PostgreSQL에서 액세스할 수 없는 트랜잭션 로그 파일이 아님). 이러한 파일에는 데이터베이스 문제를 디버그하는 데 사용하는 메시지, 서버 상태 및 기타 오류 정보가 포함되어 있습니다. 서버 로그는 최대 7일 동안 보존됩니다(서버 로그 파일의 총 크기가 7GB를 초과하는 경우 이 기간이 더 짧음).
Azure Database for MySQL 및 Azure Database for PostgreSQL은 서로 다른 세부 정보를 서버 로그에 기록합니다. 다음 섹션에서는 각 서비스의 서버 로그를 개별적으로 설명합니다.
Azure Database for MySQL의 서버 로그
Azure Database for MySQL에서는 서버 로그가 MySQL 서버의 ‘느린 쿼리 로그’ 및 ‘감사 로그’에서 일반적으로 사용할 수 있는 정보를 제공합니다.
느린 쿼리 로그의 정보를 사용하면 느리게 실행되는 쿼리를 식별하는 데 도움이 됩니다. 기본적으로 느린 쿼리 로그는 사용하지 않도록 설정되어 있습니다. 사용하도록 설정하려면 slow_query_log 서버 매개 변수를 ON으로 설정합니다. 느린 쿼리 로그를 구성하면 다음 서버 매개 변수를 사용하여 ‘느린 쿼리’를 판별합니다.
- log_queries_not_using_indexes. 이 매개 변수는 ON 또는 OFF입니다. 인덱스 조회가 아니라 전체 테이블 검색을 수행할 가능성이 큰 쿼리를 모두 기록하려면 으로 설정합니다.
- log_throttle_queries_not_using_indexes. 분당 로그될 수 있는 인덱스를 사용하지 않는 느린 쿼리의 최대 수를 지정합니다.
- log_slow_admin_queries. 느리게 실행되는 관리 쿼리를 로그에 포함하려면 이 매개 변수를 ON으로 설정합니다.
- long_query_time. ‘느린 실행’으로 간주되는 쿼리의 임계값(초)입니다.
느린 쿼리 로그 및 감사 로그를 사용하도록 설정하면 해당 서버의 서버 로그 페이지에 로그 파일이 표시되기 시작합니다. 새 느린 쿼리 로그는 매일 생성됩니다. 로그 파일을 다운로드하려면 해당 로그 파일을 클릭합니다.
감사 로깅을 사용하도록 설정하려면 audit_log_enabled 서버 매개 변수를 ON으로 설정합니다. 다음 매개 변수를 사용하여 감사 로깅을 구성합니다.
- audit_log_events. 감사할 이벤트를 지정합니다. Azure Portal에서 이 매개 변수는 CONNECTION, DDL, DML, ADMIN 등의 이벤트 드롭다운 목록을 제공합니다.
- audit_log_exclude_users. 이 매개 변수는 해당 활동이 감사 로그에 포함되지 않는 사용자의 쉼표로 구분된 목록입니다.
느린 쿼리 로그 및 감사 로그를 7일 넘게 보존해야 하는 경우 Azure 스토리지로 전송되도록 지정합니다. 해당 서버의 진단 설정 페이지에서 + 진단 설정 추가를 선택합니다. 진단 설정 페이지에서 스토리지 계정에 보관을 선택하고, 로그 파일을 저장할 스토리지 계정(이 스토리지 계정은 이미 존재해야 함)을 선택하고, MySqlSlowLogs 및 MySqlAuditLogs를 선택하고, 최대 365일의 보존 기간을 지정합니다. 이 기간 중에는 언제든 Azure 스토리지에서 로그 파일을 다운로드할 수 있습니다. 저장을 선택합니다.
느린 쿼리 로그 데이터는 insights-logs-mysqlslowlogs라는 컨테이너의 Blob에 JSON 형식으로 기록됩니다. 로그 파일이 Azure 스토리지에 표시되는 데는 최대 10분이 걸릴 수 있습니다. 감사 레코드는 insights-logs-mysqlslowlogs blob 컨테이너에 마찬가지로 JSON 형식으로 저장됩니다.
Azure Database for PostgreSQL의 서버 로그
Azure Database for PostgreSQL에서는 서버 로그에 오류 로그와 쿼리 로그 파일이 포함됩니다. 이러한 파일의 정보를 사용하면 오류 및 비효율적인 쿼리 원본을 찾는 데 도움이 됩니다.
다양한 log_ 서버 구성 매개 변수를 ON으로 설정하여 로깅을 사용하도록 설정합니다. 해당 매개 변수는 다음과 같습니다.
- log_checkpoints. 검사점은 모든 데이터 파일이 트랜잭션 로그의 최신 정보로 업데이트될 때마다 발생합니다. 서버 오류가 있는 경우 이 검사점에서는 트랜잭션 로그에서 롤포워드하여 복구를 시작해야 하는 시간을 표시합니다.
- log_connection 및 log_disconnections. 이러한 설정은 성공한 각 연결 및 각 세션의 끝을 기록합니다.
- log_duration. 이 설정은 완료된 각 SQL 문의 기간이 기록되도록 합니다.
- log_lock_waits. 이 설정은 잠금 대기 이벤트가 기록되도록 합니다. 잠금 대기는 애플리케이션 코드의 잘못 구현된 트랜잭션으로 인해 발생할 수 있습니다.
- log_statement_stats. 이 설정은 서버 성능에 대한 누적 정보를 로그에 기록합니다.
Azure Database for PostgreSQL은 기록된 정보를 미세 조정할 추가 매개 변수도 제공합니다.
- log_error_verbosity. 이 설정은 로그된 각 메시지에 대해 기록되는 세부 정보의 수준을 지정합니다.
- log_retention_days. 서버가 각 로그 파일을 제거하기 전에 보존하는 일수입니다. 기본값은 3일이며 최대 7일로 설정할 수 있습니다.
- log_min_messages 및 log_min_error_statement. 이러한 매개 변수를 사용하여 기록 문에 대한 경고 및 오류 수준을 지정할 수 있습니다.
Azure Database for MySQL과 마찬가지로 Azure Database for PostgreSQL에서 생성되는 로그 파일은 서버 로그 페이지에서 사용할 수 있습니다. 진단 설정 페이지를 사용하여 Azure 스토리지에 로그를 복사할 수도 있습니다.
쿼리 성능 추적
쿼리 저장소는 비효율적으로 실행되는 쿼리를 식별하고 추적하는 데 도움이 되도록 Azure에서 제공하는 추가 기능입니다. Azure Database for MySQL 및 Azure Database for PostgreSQL에서 사용할 수 있습니다.
쿼리 성능 추적 사용
쿼리 저장소는 Azure Database for MySQL의 mysql 스키마 그리고 Azure Database for PostgreSQL의 azure_sys라는 데이터베이스에 정보를 기록합니다. 쿼리 저장소는 쿼리 실행에 대한 데이터와 대기 통계에 대한 정보라는 두 가지 유형의 정보를 캡처할 수 있습니다. 쿼리 저장소는 기본적으로 사용하지 않도록 설정되어 있습니다. 포커스 표시를 사용하도록 설정하려면
- Azure Database for MySQL을 사용하는 경우 서버 매개 변수 query_store_capture_mode 및 query_store_wait_sampling_capture_mode를 ALL로 설정합니다.
- Azure Database for PostgreSQL을 사용하는 경우 서버 매개 변수 pg_qs.query_capture_mode를 ALL 또는 TOP으로 설정하고 pgms_wait_sampling.query_capture_mode 매개 변수를 ALL로 설정합니다.
쿼리 성능 데이터 분석
쿼리 저장소에서 사용하는 테이블을 직접 쿼리할 수 있습니다. Azure Database for MySQL을 실행하는 경우 서버에 연결하고 다음 쿼리를 실행합니다.
SELECT * FROM mysql.query_store;
SELECT * FROM mysql.query_store_wait_stats;
Azure Database for PostgreSQL을 사용하는 경우 다음 쿼리를 실행합니다.
SELECT * FROM query_store.qs_view;
SELECT * FROM query_store.pgms_wait_sampling_view;
이 경우 둘 다 첫 번째 쿼리는 최근에 실행된 각 쿼리에 대한 텍스트와 쿼리를 컴파일하고 실행하는 데 걸린 시간에 대한 여러 통계를 표시합니다. 두 번째 쿼리는 대기 이벤트에 대한 정보를 표시합니다. 한 쿼리가 다른 쿼리에서 보유한 리소스를 사용해야 해서 실행되지 않는 경우 대기 이벤트가 발생합니다.
쿼리 저장소를 직접 검토하는 경우 고유한 사용자 지정 보고서를 생성하고 시스템 작동 방식에 대한 자세한 인사이트를 얻을 수 있습니다. 하지만 제공되는 데이터의 양 때문에 무슨 일이 일어나고 있는지 이해하기 어려울 수 있습니다. Azure Database for MySQL/PostgreSQL에서는 이러한 데이터를 살펴보는 데 도움이 되도록 두 가지 추가 도구 Query Performance Insight 및 쿼리 권장 사항을 제공합니다.
Query Performance Insight는 해당 서버의 쿼리 성능 Insight 페이지에서 사용할 수 있는 그래픽 유틸리티입니다. 장기 실행 쿼리 탭은 가장 오래 실행되는 쿼리에 대한 통계를 표시합니다. 기간을 지정하고 몇 분 범위로 확대합니다. 범례는 각 쿼리의 텍스트와 쿼리 실행 기간 및 횟수를 보여 줍니다. 그래프는 각 쿼리의 기간에 대한 비교 보기를 제공합니다. 각 쿼리에 대한 평균 시간 기준 데이터가 표시되지만 각 쿼리에 대한 총 시간(‘기간’ * ‘실행’ 수)을 표시하는 것도 유용합니다. 다음은 예를 보여 주는 이미지입니다.
대기 통계 탭에는 각 쿼리의 대기 이벤트 정보가 표시됩니다. 쿼리가 다양한 리소스를 기다리는 데 걸린 시간을 확인할 수 있습니다.
대기 이벤트는 일반적으로 다음과 같은 세 가지 범주로 나뉩니다.
- 잠금 대기. 쿼리가 다른 쿼리에서 잠근 데이터를 읽거나 수정하려고 하면 이러한 이벤트가 발생합니다. 잠금 대기 수가 매우 많으면 장기 실행 트랜잭션 또는 매우 제한적인 격리 수준을 사용하는 작업을 확인하세요.
- IO 대기. 이 유형의 대기는 쿼리가 상당한 양의 IO를 수행하는 경우 발생합니다. 이러한 대기가 발생하는 것은 잘못 설계된 쿼리(WHERE 절 확인), 비효율적인 조인 작업 또는 누락된 인덱스로 인해 발생한 전체 테이블 검색 때문일 수 있습니다.
- 메모리 대기. 메모리 대기는 쿼리 처리에 사용할 수 있는 메모리가 부족한 경우 발생합니다. 쿼리가 많은 양의 데이터를 읽으려고 했거나 메모리를 많이 사용하고 있는 다른 쿼리에 의해 차단되었을 수 있습니다. 인덱스가 누락되어 쿼리가 전체 테이블을 메모리로 읽어 오게 된 것을 나타낼 수도 있습니다.
한 가지 형태의 대기가 또 다른 대기를 트리거할 가능성이 매우 크므로 이러한 이슈를 개별적으로 검사하는 것이 어려울 수 있습니다. 예를 들어 다양한 테이블의 데이터를 읽고 업데이트하는 한 트랜잭션에는 메모리 대기가 발생하기 쉽습니다. 그러면 이 트랜잭션은 다시 다른 트랜잭션에 잠금 대기를 야기하는 데이터를 잠글 수 있습니다.
서버의 성능 권장 사항 페이지에서는 쿼리 저장소에 보관된 정보를 사용하여 발생하는 워크로드에 맞게 데이터베이스 튜닝 권장 사항을 제공합니다.