연습 - 워크로드의 성능 조정 - Training

10분

이 연습에서는 첫 번째 연습에서 발생한 문제를 해결하고 Azure SQL Database를 위해 더 많은 CPU를 확장하여 성능을 향상시킵니다. 이전 연습에서 배포한 데이터베이스를 사용합니다.

이 연습에 대한 모든 스크립트는 복제한 GitHub 리포지토리의 04-Performance\monitor_and_scale 폴더 또는 다운로드한 Zip 파일에서 찾을 수 있습니다.

Azure SQL 성능 스케일 업

CPU 용량 문제로 표시되는 문제를 해결하기 위해 성능을 스케일링하려면 옵션을 결정한 다음, Azure SQL에 제공된 인터페이스를 사용하여 CPU 크기를 조정해야 합니다.

성능을 스케일링하는 방법을 결정합니다. 워크로드는 CPU에 따라 좌우되므로 성능을 향상시키는 한 가지 방법은 CPU 용량 또는 속도를 높이는 것입니다. SQL Server 사용자는 다른 머신으로 전환하거나 VM을 다시 구성하여 더 많은 CPU 용량을 확보해야 합니다. 어떤 경우에는 SQL Server 관리자라도 이러한 크기 조정 변경을 수행할 권한이 없을 수 있습니다. 프로세스에 시간이 걸리고 데이터베이스 마이그레이션이 필요할 수도 있습니다.

Azure의 경우 ALTER DATABASE, Azure CLI 또는 Azure Portal을 사용하여 사용자 측의 데이터베이스 마이그레이션 없이 CPU 용량을 늘릴 수 있습니다.
Azure Portal을 사용하여 더 많은 CPU 리소스를 위해 스케일링할 수 있는 방법에 대한 옵션을 볼 수 있습니다. 데이터베이스의 개요 창에서 현재 배포에 대한 가격 책정 계층을 선택합니다. 가격 책정 계층을 사용하여 서비스 계층 및 vCore 수를 변경할 수 있습니다.
여기서 컴퓨팅 리소스를 변경하거나 크기를 조정하는 옵션을 볼 수 있습니다. 범용의 경우 8개 vCore 등으로 쉽게 스케일 업할 수 있습니다.

다른 방법을 사용하여 워크로드 크기를 스케일링할 수도 있습니다.
이 연습에서는 보고서에서 적절한 차이를 확인할 수 있도록 먼저 쿼리 저장소를 플러시해야 합니다. SSMS(SQL Server Management Studio)에서 AdventureWorks 데이터베이스를 선택하고, 파일>열기>파일 메뉴를 사용합니다. AdventureWorks 데이터베이스 컨텍스트의 SSMS에서 flushhquerystore.sql 스크립트를 엽니다. 쿼리 편집기 창은 다음 텍스트와 같이 표시됩니다.
```
EXEC sp_query_store_flush_db;
```
이 T-SQL 일괄 처리를 실행하려면 실행을 선택합니다.

참고 항목

이전 쿼리를 실행하면 쿼리 저장소 데이터의 메모리 내 부분이 디스크로 플러시됩니다.
SSMS에서 스크립트 get_service_objective.sql을 엽니다. 쿼리 편집기 창은 다음 텍스트와 같이 표시됩니다.
```
SELECT database_name,slo_name,cpu_limit,max_db_memory, max_db_max_size_in_mb, primary_max_log_rate,primary_group_max_io, volume_local_iops,volume_pfs_iops
FROM sys.dm_user_db_resource_governance;
GO
SELECT DATABASEPROPERTYEX('AdventureWorks', 'ServiceObjective');
GO
```
T-SQL을 사용하여 서비스 계층을 확인하는 방법입니다. 가격 책정 또는 서비스 계층을 서비스 목표라고도 합니다. T-SQL 일괄 처리를 실행하려면 실행을 선택합니다.

현재 Azure SQL Database 배포의 경우 결과는 다음 이미지와 같이 표시됩니다.

용어 slo_name은 서비스 목표에도 사용됩니다. slo는 서비스 수준 목표를 나타냅니다.

다양한 slo_name 값은 문서화되어 있지 않지만 문자열 값에서 이 데이터베이스가 다음과 같은 2개 vCore를 포함하는 범용 서비스 계층을 사용한다는 것을 알 수 있습니다.

참고 항목

SQLDB_OP_...는 중요 비즈니스용 서비스 계층에 사용되는 문자열입니다.

ALTER DATABASE 문서를 보면 대상 SQL Server 배포를 선택하여 올바른 구문 옵션을 표시할 수 있다는 사실을 알 수 있습니다. SQL Database 단일 데이터베이스/탄력적 풀을 선택하여 Azure SQL Database에 대한 옵션을 표시합니다. 포털에서 찾은 컴퓨팅 크기 조정과 일치시키기 위해 서비스 목표 'GP_Gen5_8'이 필요합니다.
데이터베이스의 서비스 목표를 수정하여 더 많은 CPU를 확장합니다. SSMS에서 modify_service_objective.sql 스크립트를 열고 T-SQL 일괄 처리를 실행합니다. 쿼리 편집기 창은 다음 텍스트와 같이 표시됩니다.
```
ALTER DATABASE AdventureWorks MODIFY (SERVICE_OBJECTIVE = 'GP_Gen5_8');
```
이 문으로 즉시 다시 돌아와 백그라운드에서 컴퓨팅 리소스의 크기 조정이 수행됩니다. 이러한 작은 크기 스케일링에는 1분 미만의 시간이 소요되며, 짧은 기간 동안 데이터베이스가 오프라인 상태가 되고 변경 내용이 적용됩니다. Azure Portal을 사용하여 이 크기 조정 작업의 진행률을 모니터링할 수 있습니다.

개체 탐색기의 시스템 데이터베이스 폴더에서 master 데이터베이스를 마우스 오른쪽 단추로 클릭하고 새 쿼리를 선택합니다. SSMS 쿼리 편집기 창에서 다음 쿼리를 실행합니다.

SELECT * FROM sys.dm_operation_status;

이 편집기는 Azure SQL Database에 대한 서비스 목표 변경 진행 과정을 모니터링하는 또 다른 방법입니다. 이 DMV(동적 관리 뷰)는 서비스 목표에 따른 ALTER DATABASE를 사용한 데이터베이스에 대한 변경 기록을 노출합니다. 변경의 진행 상태를 표시합니다.

이전 ALTER DATABASE 문을 실행한 후 이 DMV의 출력 예제를 테이블 형식으로 표시한 결과는 다음과 같습니다.

항목	값
session_activity_id	97F9474C-0334-4FC5-BFD5-337CDD1F9A21
resource_type	0
resource_type_desc	Database
major_resource_id	AdventureWorks
minor_resource_id
operation	ALTER DATABASE
state	1
state_desc	IN_PROGRESS
percent_complete	0
error_code	0
error_desc
error_severity	0
error_state	0
start_time	[date time]
last_modify_time	[date time]

서비스 목표를 변경하는 동안 최종 변경이 구현될 때까지 데이터베이스에 대한 쿼리가 허용됩니다. 애플리케이션이 매우 짧은 시간 동안 연결할 수 없습니다. Azure SQL Managed Instance의 경우 계층의 변경으로 인해 쿼리 및 연결이 허용되지만 새 데이터베이스 만들기와 같은 모든 데이터베이스 작업은 허용되지 않습니다. 이러한 경우 다음과 같은 오류 메시지가 표시됩니다. “관리되는 인스턴스 ‘[server]’에 대한 서비스 계층 변경이 진행 중이므로 작업을 완료할 수 없습니다. 진행 중인 작업이 완료될 때까지 기다렸다가 다시 시도하세요.”

이 작업이 완료되면 SSMS의 get_service_objective.sql에서 나열된 이전 쿼리를 사용하여 새 서비스 목표 또는 8개 vCore의 서비스 계층이 영향을 받았는지 확인합니다.

스케일 업 후 워크로드 실행

이제 데이터베이스에 더 많은 CPU 용량이 있으므로 이전 연습에서 수행한 워크로드를 실행하여 성능 향상이 있는지 여부를 확인합니다.

이제 확장이 완료되었으므로 워크로드 기간이 더 단축되는지와 CPU 리소스의 대기 시간이 감소했는지 확인합니다. 이전 연습에서 실행한 sqlworkload.cmd 명령을 사용하여 워크로드를 다시 실행합니다.
SSMS를 사용하여 이 모듈의 첫 번째 연습에서 사용한 동일한 쿼리를 실행하여 dmdbresourcestats.sql 스크립트의 결과를 확인합니다.
```
SELECT * FROM sys.dm_db_resource_stats;
```
이전 연습의 100%에 가까운 사용량 평균 CPU 리소스 사용량보다 더 낮게 감소했음을 확인할 수 있습니다. 일반적으로 sys.dm_db_resource_stats는 1시간의 작업을 표시합니다. 데이터베이스 크기를 조정하면 sys.dm_db_resource_stats가 다시 설정됩니다.
SSMS를 사용하여 이 모듈의 첫 번째 연습에서 사용한 동일한 쿼리를 실행하여 dmexecrequests.sql 스크립트의 결과를 확인합니다.
```
SELECT er.session_id, er.status, er.command, er.wait_type, er.last_wait_type, er.wait_resource, er.wait_time
FROM sys.dm_exec_requests er
INNER JOIN sys.dm_exec_sessions es
ON er.session_id = es.session_id
AND es.is_user_process = 1;
```
상태가 RUNNING인 더 많은 쿼리가 표시됩니다. 즉, 작업자가 실행에 사용할 수 있는 더 많은 CPU 용량이 있음을 의미합니다.
새 워크로드 기간을 확인합니다. sqlworkload.cmd의 워크로드 기간이 훨씬 짧으며 약 25~30초입니다.

쿼리 저장소 보고서 확인

이전 연습에서 수행한 것과 동일한 쿼리 저장소 보고서를 살펴보겠습니다.

이 모듈의 첫 번째 연습과 동일한 기술을 사용하여 SSMS의 리소스 사용량 상위 쿼리 보고서를 확인합니다.

이제 두 개의 쿼리(query_id)가 표시됩니다. 이러한 쿼리는 동일한 쿼리이지만 크기 스케일링 작업을 수행하려면 다시 시작해야 하고 쿼리를 다시 컴파일해야 했으므로 쿼리 저장소에 다른 query_id 값으로 표시됩니다. 보고서에서 전체 및 평균 기간이 훨씬 더 짧았다는 것을 알 수 있습니다.
또한 쿼리 대기 통계 보고서를 살펴보고 CPU 대기 표시줄을 선택합니다. 쿼리의 전체 평균 대기 시간이 감소하고, 전체 기간 중에서 일부만 차지한다는 것을 확인할 수 있습니다. 이 사실은 데이터베이스의 vCore 수가 적은 경우 CPU에서 리소스 병목 현상이 많이 발생하지 않는다는 사실을 잘 나타내는 지표입니다.
모든 보고서와 쿼리 편집기 창을 닫을 수 있습니다. 다음 연습에서 필요하므로 SSMS를 연결된 상태로 둡니다.

Azure 메트릭의 변경 내용 확인

Azure Portal의 AdventureWorks 데이터베이스로 이동하고 개요 창의 모니터링 탭에서 컴퓨팅 사용률을 다시 살펴봅니다.

높은 CPU 사용률에 대한 기간이 더 짧다는 것은 워크로드를 실행하는 데 필요한 CPU 리소스가 전반적으로 감소한다는 사실을 의미합니다.
이 차트는 약간 잘못된 것일 수 있습니다. 모니터링 메뉴에서 메트릭을 사용한 다음 메트릭을 CPU 한도로 설정합니다. CPU 비교 차트는 다음과 비슷합니다.

팁

이 데이터베이스에 대한 vCore 수를 계속 늘리면 모든 쿼리에 충분한 CPU 리소스를 사용할 수 있는 임계값까지 성능을 향상시킬 수 있습니다. 그렇다고 해서 vCore의 수를 워크로드의 동시 사용자 수와 일치시켜야 할 필요는 없습니다. 또한 프로비전 대신 서버리스 컴퓨팅 계층을 사용하도록 가격 책정 계층을 변경할 수 있습니다. 이를 통해 워크로드에 대해 보다 강력한 자동 스케일링 방식을 구현할 수 있습니다. 예를 들어 이 워크로드의 경우 최소 vCore 값 2와 최대 vCore 값 8을 선택한 경우 워크로드는 즉시 8개 vCore로 스케일링됩니다.

다음 연습에서 성능 문제를 확인하고 애플리케이션 성능 개선을 위한 모범 사례를 적용하여 해결해 봅니다.

계속

연습 - 워크로드의 성능 조정

Azure SQL 성능 스케일 업

스케일 업 후 워크로드 실행

쿼리 저장소 보고서 확인

Azure 메트릭의 변경 내용 확인

피드백