Azure SQL Database에 대한 서버리스 컴퓨팅 계층

  • 아티클
  • 읽는 데 54분 걸림

적용 대상: Azure SQL Database

서버리스는 워크로드 수요에 따라 컴퓨팅 크기를 자동으로 조정하고 초당 사용되는 컴퓨팅 양에 대한 요금을 청구하는 Azure SQL Database의 단일 데이터베이스에 대한 컴퓨팅 계층입니다. 또한 서버리스 컴퓨팅 계층은 스토리지 비용만 청구될 때 비활성 기간 동안 데이터베이스를 자동으로 일시 중지하고 활동이 반환되면 데이터베이스를 자동으로 다시 시작합니다. 서버리스 컴퓨팅 계층은 범용 서비스 계층에서 사용할 수 있으며 현재 하이퍼스케일 서비스 계층에서 미리 보기로 제공됩니다.

참고

  • 하이퍼스케일 서비스 계층의 서버리스는 현재 미리 보기로 제공됩니다.
  • 자동 일시 중지 및 자동 다시 시작은 현재 범용 서비스 계층에서만 지원됩니다.

개요

Azure SQL Database에서 단일 데이터베이스용 서버리스 컴퓨팅 계층은 컴퓨팅 자동 크기 조정 범위와 자동 일시 중지 지연으로 매개 변수화됩니다. 이러한 매개 변수 구성을 통해 데이터베이스 성능 환경과 컴퓨팅 비용이 구체화됩니다.

서버리스 청구

성능 구성

  • 최소 vCore 수 및 최대 vCore 수는 데이터베이스에 사용할 수 있는 컴퓨팅 용량의 범위를 정의하는 구성 가능한 매개 변수입니다. 메모리 및 IO 제한은 지정된 vCore 범위에 비례합니다. 
  • 자동 일시 중지 지연은 데이터베이스가 자동으로 일시 중지되기 전에 비활성 상태로 있어야 하는 기간을 정의하는 구성 가능한 매개 변수입니다. 다음 로그인 또는 기타 활동이 발생하면 데이터베이스가 자동으로 다시 시작됩니다. 또는 자동 일시 중지를 사용하지 않을 수 있습니다.

비용

  • 서버리스 데이터베이스에 대한 비용은 컴퓨팅 비용과 스토리지 비용의 합계입니다.
  • 컴퓨팅 사용량이 구성된 최소 및 최대 한도 사이에 있으면 컴퓨팅 비용은 사용된 vCore 및 메모리를 기반으로 합니다.
  • 컴퓨팅 사용량이 구성된 최소 한도 미만이면 컴퓨팅 비용은 구성된 최소 vCore 및 최소 메모리를 기반으로 합니다.
  • 데이터베이스가 일시 중지되면 컴퓨팅 비용은 0이고 스토리지 비용만 발생합니다.
  • 스토리지 비용은 프로비저닝된 컴퓨팅 계층과 동일한 방식으로 결정됩니다.

자세한 비용 정보는 청구를 참조하세요.

시나리오

서버리스는 간헐적이고 예측 불가능한 사용 패턴이 있는 단일 데이터베이스에 최적화된 가격 대비 성능이며, 유휴 사용 기간 후 컴퓨팅 준비가 약간 지연될 수 있습니다. 반면, 프로비전된 컴퓨팅 계층 은 컴퓨팅 준비 지연을 감당할 수 없는 평균 사용량이 높은 탄력적 풀 의 단일 데이터베이스 또는 여러 데이터베이스에 최적화된 가격 성능입니다.

서버리스 컴퓨팅에 적합한 시나리오

  • 일정 기간 활동이 없고 평균 컴퓨팅 활용률도 저조하게 나타나는 등, 사용 패턴이 일정하지 않고 예측하기 어려운 단일 데이터베이스
  • 자주 재조정되는 프로비저닝된 컴퓨팅 계층의 단일 데이터베이스와 컴퓨팅 재조정을 서비스에 위임하려는 고객
  • 사용 기록이 없는 새로운 단일 데이터베이스, SQL Database에 배포하기 전에 컴퓨팅 크기를 추정하기 어렵거나 불가능함

프로비저닝된 컴퓨팅에 적합한 시나리오

  • 보다 규칙적이고, 사용 패턴을 예측할 수 있고, 시간이 지나면서 평균 컴퓨팅 사용률이 높아지는 단일 데이터
  • 일시 중지된 상태에서 메모리 조정 또는 다시 시작 지연이 자주 발생하여 성능 절충을 허용할 수 없는 데이터베이스가 있습니다.
  • 가격 대비 성능 최적화를 위해 탄력적 풀로 통합될 수 있는, 간헐적이고 예측이 불가능한 사용 패턴의 여러 데이터베이스

컴퓨팅 계층 비교

다음 표에서는 서버리스 컴퓨팅 계층과 프로비저닝된 컴퓨팅 계층 간의 차이점을 요약하고 있습니다.

서버리스 컴퓨팅 프로비저닝된 컴퓨팅
데이터베이스 사용 패턴 시간이 지나면서 평균 컴퓨팅 사용률이 낮아지는 간헐적이고 예측할 수 없는 사용량 시간이 지나면서 평균 컴퓨팅 사용률이 높아지는 보다 규칙적인 사용 패턴 또는 탄력적 풀을 사용하는 여러 데이터베이스
성능 관리 작업 더 낮음 더 높음
컴퓨팅 크기 조정 자동 수동
컴퓨팅 응답성 비활성 기간 후 낮음 직접 실행
청구 세분성 초당 시간당

구매 모델 및 서비스 계층

다음 표에서는 구매 모델, 서비스 계층 및 하드웨어를 기반으로 하는 서버리스 지원에 대해 설명합니다.

범주 지원됨 지원되지 않음
구매 모델 vCore DTU
서비스 계층 범용
하이퍼스케일 (미리 보기)		 중요 비즈니스용
하드웨어 표준 시리즈(Gen5) 기타 모든 하드웨어

자동 확장

크기 조정 응답성

일반적으로 서버리스 데이터베이스는 최대 vCore 값으로 설정된 제한 내에서 요청된 컴퓨팅 양에 대해 중단 없이 리소스 수요를 충족할 수 있는 충분한 용량을 갖춘 머신에서 실행됩니다. 머신에서 리소스 수요를 몇 분 내에 충족할 수 없는 경우 부하 분산이 자동으로 수행되는 경우가 있습니다. 예를 들어, 리소스 수요가 vCore 4개인데 vCore를 2개만 사용할 수 있으면 vCore 4개가 제공되기 전에 부하를 분산하는 데 최대 몇 분 정도 걸릴 수 있습니다. 연결이 끊어지는 경우 작업이 끝날 때의 짧은 기간을 제외하고는 데이터베이스에서 부하 분산 중에 온라인 상태를 유지합니다.

메모리 관리

범용 및 하이퍼스케일 서비스 계층 모두에서 서버리스 데이터베이스의 메모리는 프로비전된 컴퓨팅 데이터베이스보다 더 자주 회수됩니다. 이 동작은 서버리스에서 비용을 제어하는 데 중요하며 성능에 영향을 줄 수 있습니다.

캐시 재사용

프로비저닝된 컴퓨팅 데이터베이스와 달리 CPU 또는 활성 캐시 사용률이 낮으면 서버리스 데이터베이스에서 SQL 캐시의 메모리를 회수합니다.

  • 가장 최근에 사용한 캐시 항목의 전체 크기가 일정 기간 동안 임계값 미만으로 떨어지면 활성 캐시 활용도가 낮은 것으로 간주됩니다.
  • 캐시 재사용이 트리거되면 대상 캐시 크기가 이전 크기의 일부로 점차 감소하고 재사용은 사용량이 낮은 경우에만 계속됩니다.
  • 캐시 재사용이 발생하면 제거할 캐시 항목을 선택하는 정책은 메모리가 부족할 때 프로비저닝된 컴퓨팅 데이터베이스와 동일한 선택 정책입니다.
  • 캐시 크기는 구성할 수 있는 최소 vCore에 의해 정의된 최소 메모리 제한 미만으로 절대 줄어들지 않습니다.

서버리스 및 프로비저닝된 컴퓨팅 데이터베이스 모두에서 사용 가능한 메모리가 모두 사용되면 캐시 항목이 제거될 수 있습니다.

CPU 사용률이 낮은 경우 활성 캐시 사용률은 사용 패턴에 따라 높게 유지되므로 메모리 재사용을 방지할 수 있습니다. 또한 이전 사용자 활동에 응답하는 정기적인 백그라운드 프로세스로 인해 사용자 활동이 중지된 후 메모리 재사용이 발생하기 전에 다른 지연이 발생할 수 있습니다. 예를 들어 삭제 작업과 쿼리 저장소 정리 태스크는 삭제하도록 표시되지만 고스트 정리 프로세스가 실행될 때까지 물리적으로 삭제되지 않는 삭제할 레코드를 생성합니다. 고스트 정리에는 추가 데이터 페이지를 캐시로 읽어오는 작업이 포함될 수 있습니다.

캐시 하이드레이션

SQL 메모리 캐시는 프로비전된 데이터베이스와 동일한 속도로 디스크에서 데이터를 가져오면서 증가합니다. 데이터베이스가 사용 중인 경우 사용 가능한 메모리가 있는 동안 캐시가 제한 없이 증가할 수 있습니다.

디스크 캐시 관리

서버리스 및 프로비전된 컴퓨팅 계층 모두에 대한 하이퍼스케일 서비스 계층에서 각 컴퓨팅 복제본은 RBPEX(탄력적 버퍼 풀 확장) 캐시를 사용하여 로컬 SSD에 데이터 페이지를 저장하여 IO 성능을 개선합니다. 그러나 하이퍼스케일의 서버리스 컴퓨팅 계층에서 각 컴퓨팅 복제본에 대한 RBPEX 캐시는 워크로드 수요 증가 및 감소에 따라 자동으로 증가하고 축소됩니다. RBPEX 캐시가 증가할 수 있는 최대 크기는 데이터베이스에 대해 구성된 최대 메모리의 3배입니다. 서버리스의 최대 메모리 및 RBPEX 자동 크기 조정 제한에 대한 자세한 내용은 서버리스 하이퍼스케일 리소스 제한을 참조하세요.

자동 일시 중지 및 자동 다시 시작

현재 서버리스 자동 일시 중지 및 자동 재개는 범용 계층에서만 지원됩니다.

자동 일시 중지

자동 일시 중지는 자동 일시 중지 지연 기간 동안 다음 조건이 모두 참이면 트리거됩니다.

  • 세션 수 = 0
  • CPU = 0(사용자 리소스 풀에서 실행되는 사용자 워크로드의 경우)

원하는 경우 자동 일시 중지를 사용하지 않도록 설정하는 옵션이 제공됩니다.

다음 기능은 자동 일시 중지를 지원하지 않지만 자동 크기 조정은 지원합니다. 다음 기능 중 하나를 사용하는 경우 자동 일시 중지를 사용하지 않도록 설정해야 하며, 데이터베이스 비활성 기간에 관계없이 데이터베이스가 온라인 상태로 유지됩니다.

데이터베이스가 온라인 상태여야 하는 일부 서비스 업데이트를 배포하는 동안에는 자동 일시 중지가 일시적으로 차단됩니다. 이런 경우 서비스 업데이트가 완료되면 자동 일시 중지가 다시 허용됩니다.

자동 일시 중지 문제 해결

자동 일시 중지가 사용하도록 설정되었지만 지연 기간 후 데이터베이스가 자동으로 일시 중지되지 않고 위에 나열된 기능이 사용되지 않는 경우 애플리케이션 또는 사용자 세션에서 자동 일시 중지를 차단한 것일 수 있습니다. 현재 데이터베이스에 연결된 애플리케이션 또는 사용자 세션이 있는지 확인하려면 클라이언트 도구를 사용하여 데이터베이스에 연결한 후 다음 쿼리를 실행합니다.

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
      (
      wg.name like 'UserPrimaryGroup.DB%'
      AND
      TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
      )
      OR
      wg.name = 'DACGroup'
      );

팁

쿼리를 실행한 후 데이터베이스 연결을 끊어야 합니다. 그러지 않으면 쿼리에서 사용 중인 열린 세션으로 인해 자동 일시 중지가 차단됩니다.

결과 집합이 비어 있지 않으면 현재 자동 일시 중지를 차단하는 세션이 있는 것입니다.

결과 집합이 비어 있는 경우에도 이전에 자동 일시 중지 지연 기간 중 짧은 시간 동안 세션이 열렸을 수 있습니다. 지연 기간 동안 해당 활동이 발생했는지 확인하려면 Azure SQL 감사를 사용하여 관련 기간의 감사 데이터를 검사할 수 있습니다.

동시 CPU 사용률 여부에 관계없이 사용자 리소스 풀에 열린 세션이 있는 경우가 서버리스 데이터베이스가 예상대로 자동 일시 중지되지 않는 가장 일반적인 이유입니다.

자동 다시 시작

다음 조건 중 하나라도 참이면 언제든지 자동 다시 시작이 트리거됩니다.

기능 자동 다시 시작 트리거
인증 및 권한 부여 로그인
위협 탐지 데이터베이스 또는 서버 수준에서 위협 탐지 설정 사용/사용 안 함.
데이터베이스 또는 서버 수준에서 위협 탐지 설정 수정.
데이터 검색 및 분류 민감도 레이블 추가, 수정, 삭제 또는 보기
감사 감사 레코드 보기,
감사 정책 업데이트 또는 보기
데이터 마스킹 데이터 마스킹 규칙 추가, 수정, 삭제 또는 보기
투명한 데이터 암호화 투명한 데이터 암호화 상태 보기
취약점 평가 사용하도록 설정된 경우 임시 검사 및 정기 검사
쿼리(성능) 데이터 저장소 쿼리 저장소 설정 수정 또는 보기
성능 추천 사항 성능 권장 사항 보기 또는 적용
자동 튜닝 자동 인덱싱과 같은 자동 튜닝 권장 사항 적용 및 확인
데이터베이스 복사 데이터베이스를 복사본으로 만들기
BACPAC 파일로 내보내기
SQL 데이터 동기화 구성 가능한 예약에 따라 실행되거나 수동으로 수행되는 허브 및 멤버 데이터베이스 간의 동기화
특정 데이터베이스 메타데이터 수정 새 데이터베이스 태그 추가,
최대 vCore 수, 최소 vCore 수 또는 자동 일시 중지 지연 변경
SSMS(SQL Server Management Studio) 18.1 이전의 SSMS 버전을 사용하고 서버의 데이터베이스에 대한 새 쿼리 창을 열면 동일한 서버에서 자동으로 일시 중지된 데이터베이스가 다시 시작됩니다. SSMS 버전 18.1 이상을 사용하는 경우 이 문제가 발생하지 않습니다.

위에 나열된 작업을 수행하는 모니터링, 관리 또는 기타 솔루션은 자동 재개를 트리거합니다.

데이터베이스가 온라인 상태여야 하는 일부 서비스 업데이트를 배포하는 동안 자동 다시 시작도 트리거됩니다.

연결

서버리스 데이터베이스가 일시 중지되면 첫 번째 로그인에서 데이터베이스가 다시 시작되고 40613 오류 코드로 인해 데이터베이스를 사용할 수 없다는 오류가 반환됩니다. 데이터베이스가 다시 시작되면 연결을 설정하기 위해 로그인을 다시 시도해야 합니다. 연결 재시도 논리가 있는 데이터베이스 클라이언트는 수정할 필요가 없습니다. SqlClient 드라이버에 기본 제공된 연결 재시도 논리 옵션은 SqlClient의 구성 가능한 재시도 논리를 참조하세요.

대기 시간

서버리스 데이터베이스가 자동으로 다시 시작되기까지의 대기 시간과 자동으로 일시 중지되기까지의 대기 시간은 일반적으로 각각 1분, 지연 기간 만료 후 1~10분입니다.

고객 관리형 투명 데이터 암호화(BYOK)

키 삭제 또는 해지

고객 관리형 투명 데이터 암호화(BYOK)를 사용하고 키 삭제 또는 해지가 발생할 때 서버리스 데이터베이스가 자동 일시 중지된 경우에는 데이터베이스가 자동 일시 중지 상태로 유지됩니다. 이 경우 다음에 데이터베이스를 다시 시작하면 약 10분 내에 데이터베이스에 액세스할 수 없게 됩니다. 데이터베이스에 액세스할 수 없게 되면 복구 프로세스가 프로비저닝된 컴퓨팅 데이터베이스와 동일합니다. 키 삭제 또는 해지가 발생할 때 서버리스 데이터베이스가 온라인이면, 프로비저닝된 컴퓨팅 데이터베이스와 동일한 방식으로 약 10분 내에 데이터베이스에 액세스할 수 없게 됩니다.

키 회전

고객 관리형 투명한 데이터 암호화(BYOK)를 사용하고 서버리스 데이터베이스가 자동 일시 중지된 경우 데이터베이스가 자동으로 다시 시작될 때까지 자동화된 키 회전이 지연됩니다.

새 서버리스 데이터베이스 만들기

새 데이터베이스를 만들거나 기존 데이터베이스를 서버리스 컴퓨팅 계층으로 이동하는 경우 프로비저닝된 컴퓨팅 계층에서 새 데이터베이스를 만드는 것과 동일한 패턴을 따르면 다음 두 단계를 수행해야 합니다.

  1. 서비스 목표를 지정합니다. 서비스 목표는 서비스 계층, 하드웨어 구성 및 최대 vCore를 지정합니다. 서비스 목표 옵션은 서버리스 리소스 제한을 참조하세요.

  2. 필요에 따라 최소 vCore 수와 자동 일시 중지 지연을 지정하여 기본값을 변경합니다. 다음 표에는 이러한 매개 변수에 사용할 수 있는 값이 나와 있습니다.

    매개 변수 값 선택 기본값
    최소 vCore 구성된 최대 vCore에 따라 다름 - 리소스 한도를 참조하세요. 0.5개 vCore
    자동 일시 중지 지연 최소: 60분(1시간)
    최대: 10080분(7일)
    간격: 10분
    자동 일시 중지 사용 안 함: -1    		 60분

다음 예에서는 서버리스 컴퓨팅 계층에 새 데이터베이스를 만듭니다.

Azure Portal 사용

빠른 시작: Azure Portal을 사용하여 Azure SQL Database에서 단일 데이터베이스 만들기를 참조하세요.

PowerShell 사용

다음 PowerShell 예제를 사용하여 새 서버리스 범용 데이터베이스를 만듭니다.

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -ComputeModel Serverless -Edition GeneralPurpose -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720

Azure CLI 사용

다음 Azure CLI 예제를 사용하여 새 범용 서버리스 데이터베이스를 만듭니다.

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose -f Gen5 --min-capacity 0.5 -c 2 --compute-model Serverless --auto-pause-delay 720

T-SQL(Transact-SQL) 사용

T-SQL을 사용하는 경우 최소 vCore 및 자동 일시 중지 지연에 기본값이 적용됩니다. 나중에 포털에서 또는 다른 관리 API(PowerShell, Azure CLI, REST API)를 통해 변경할 수 있습니다.

자세한 내용은 CREATE DATABASE를 참조하세요.

다음 T-SQL 예제를 사용하여 새 범용 서버리스 데이터베이스를 만듭니다.

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

컴퓨팅 계층 간에 데이터베이스 이동

프로비전된 컴퓨팅 계층에서 서버리스 컴퓨팅 계층으로 데이터베이스를 다시 이동할 수 있습니다.

참고

범용 계층의 데이터베이스를 하이퍼스케일 계층으로 업그레이드할 수도 있습니다. 자세한 내용은 하이퍼스케일 데이터베이스 관리를 검토하세요 .

컴퓨팅 계층 간에 데이터베이스를 이동할 때 PowerShell 및 Azure CLI를 사용할 때 또는 Provisioned 로 Compute 모델 매개 변수 Serverless 를 제공하고 T-SQL을 사용할 때 SERVICE_OBJECTIVE 컴퓨팅 크기를 제공합니다. 리소스 제한을 검토하여 적절한 컴퓨팅 크기를 식별합니다.

이 섹션의 예제에서는 프로비전된 데이터베이스를 서버리스로 이동하는 방법을 보여 줍니다. 이러한 예제에서 최대 vCore를 4로 설정하므로 필요에 따라 서비스 목표를 수정합니다.

PowerShell 사용

다음 PowerShell 예제를 사용하여 프로비전된 컴퓨팅 범용 데이터베이스를 서버리스 컴퓨팅 계층으로 이동합니다.

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440

Azure CLI 사용

다음 Azure CLI 예제를 사용하여 프로비전된 컴퓨팅 범용 데이터베이스를 서버리스 컴퓨팅 계층으로 이동합니다.

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --min-capacity 1 --capacity 4 --family Gen5 --compute-model Serverless --auto-pause-delay 1440

T-SQL(Transact-SQL) 사용

T-SQL을 사용하는 경우 최소 vCore 및 자동 일시 중지 지연에 기본값이 적용됩니다. 나중에 포털에서 또는 다른 관리 API(PowerShell, Azure CLI, REST API)를 통해 변경할 수 있습니다. 자세한 내용은 ALTER DATABASE를 참조하세요.

다음 T-SQL 예제를 사용하여 프로비전된 컴퓨팅 범용 데이터베이스를 서버리스 컴퓨팅 계층으로 이동합니다.

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

서버리스 구성 수정

PowerShell 사용

Set-AzSqlDatabase를 사용하여 최대 또는 최소 vCore를 수정하고 지연을 자동 일시 중지합니다. , MinVcore및 인수를 MaxVcoreAutoPauseDelayInMinutes 사용합니다. 서버리스 자동 일시 중지는 현재 하이퍼스케일 계층에서 지원되지 않으므로 자동 일시 중지 지연 인수는 범용 계층에만 적용됩니다.

Azure CLI 사용

az sql db update를 사용하여 최대 또는 최소 vCore를 수정하고 지연을 자동 일시 중지합니다. , min-capacity및 인수를 capacityauto-pause-delay 사용합니다. 서버리스 자동 일시 중지는 현재 하이퍼스케일 계층에서 지원되지 않으므로 자동 일시 중지 지연 인수는 범용 계층에만 적용됩니다.

모니터링

리소스 사용 및 청구

서버리스 데이터베이스의 리소스는 앱 패키지, SQL 인스턴스 및 사용자 리소스 풀 엔터티로 캡슐화됩니다.

앱 패키지

데이터베이스가 서버리스 또는 프로비저닝된 컴퓨팅 계층에 있는지 여부에 관계없이 앱 패키지는 데이터베이스의 가장 외부에 있는 리소스 관리 경계입니다. 앱 패키지에는 SQL Database의 데이터베이스에서 사용 중인 모든 사용자 및 시스템 리소스를 검색하는 전체 텍스트 검색과 같은 외부 서비스와 SQL 인스턴스가 포함됩니다. SQL 인스턴스는 일반적으로 앱 패키지 전체의 전체 리소스 사용률을 제어합니다.

사용자 리소스 풀

데이터베이스가 서버리스 또는 프로비저닝된 컴퓨팅 계층에 있는지 여부에 관계없이 사용자 리소스 풀은 데이터베이스의 내부 리소스 관리 경계입니다. 사용자 리소스 풀은 DDL 쿼리(예: CREATE, ALTER), DML 쿼리(예: INSERT, UPDATE, DELETE, MERGE), SELECT 쿼리에서 생성된 사용자 워크로드에 대한 CPU와 IO의 범위를 지정합니다. 이러한 쿼리는 일반적으로 앱 패키지 내에서 가장 높은 사용률을 나타냅니다.

메트릭

서버리스 데이터베이스 및 지역 복제본의 앱 패키지 및 사용자 리소스 풀의 리소스 사용량을 모니터링하기 위한 메트릭은 다음 표에 나와 있습니다.

엔터티 메트릭 설명 단위
앱 패키지 app_cpu_percent 앱에 허용되는 최대 vCore 수에 대한 앱에서 사용한 vCore 수의 백분율입니다. 서버리스 하이퍼스케일의 경우 이 메트릭은 모든 주 복제본, 명명된 복제본 및 지역 복제본에 대해 노출됩니다. 백분율
앱 패키지 app_cpu_billed 보고 기간 동안 앱에 대해 요금이 청구되는 컴퓨팅의 양입니다. 이 기간 동안에 대한 지불 금액은 이 메트릭과 vCore 단가를 곱한 값입니다.

이 메트릭의 값은 시간이 지남에 따라 사용된 최대 CPU와 사용된 초당 메모리를 집계하여 결정됩니다. 사용된 양이 최소 vCore 수 및 최소 메모리로 설정된 최소 프로비저닝된 양보다 적으면 최소 프로비저닝된 양에 대한 요금이 청구됩니다. 청구의 목적으로 CPU를 메모리와 비교하기 위해 메모리는 vCore당 메모리 양(GB 단위)을 3GB로 다시 조정하여 vCore 단위로 정규화됩니다. 서버리스 하이퍼스케일의 경우 이 메트릭은 주 복제본 및 명명된 복제본에 대해 노출됩니다.		 vCore 시간(초)
앱 패키지 app_cpu_billed_HA_replicas 서버리스 하이퍼스케일에만 적용됩니다. 보고 기간 동안 HA 복제본에 대한 모든 앱에서 청구되는 컴퓨팅의 합계입니다. 이 합계는 주 복제본에 속한 HA 복제본 또는 지정된 명명된 복제본에 속한 HA 복제본으로 범위가 지정됩니다. HA 복제본에서 이 합계를 계산하기 전에 개별 HA 복제본에 대해 청구되는 컴퓨팅 양은 주 복제본 또는 명명된 복제본과 동일한 방식으로 결정됩니다. 서버리스 하이퍼스케일의 경우 이 메트릭은 모든 주 복제본, 명명된 복제본 및 지역 복제본에 대해 노출됩니다. 보고 기간 동안 지불된 금액은 이 메트릭 및 vCore 단가의 산물입니다. vCore 시간(초)
앱 패키지 app_memory_percent 앱에 허용되는 최대 메모리에 대한 앱에서 사용한 메모리의 백분율입니다. 서버리스 하이퍼스케일의 경우 이 메트릭은 모든 주 복제본, 명명된 복제본 및 지역 복제본에 대해 노출됩니다. 백분율
사용자 리소스 풀 cpu_percent 사용자 워크로드에 허용되는 최대 vCore 수에 대한 사용자 워크로드에서 사용한 vCore 수의 백분율입니다. 백분율
사용자 리소스 풀 data_IO_percent 사용자 워크로드에 허용되는 최대 데이터 IOPS에 대한 사용자 워크로드에서 사용한 데이터 IOPS의 백분율입니다. 백분율
사용자 리소스 풀 log_IO_percent 사용자 워크로드에 허용되는 최대 로그 MB/초에 대한 사용자 워크로드에서 사용한 로그 MB/초의 백분율입니다. 백분율
사용자 리소스 풀 workers_percent 사용자 워크로드에 허용되는 최대 작업자 수에 대한 사용자 워크로드에서 사용한 작업자 수의 백분율입니다. 백분율
사용자 리소스 풀 sessions_percent 사용자 워크로드에 허용되는 최대 세션 수에 대한 사용자 워크로드에서 사용한 세션 수의 백분율입니다. 백분율

일시 중지 및 다시 시작 상태

Azure Portal에서 데이터베이스 상태는 해당 상태가 포함된 데이터베이스를 나열하는 서버의 개요 창에 표시됩니다. 또한 데이터베이스 상태는 데이터베이스의 개요 창에도 표시됩니다.

다음 명령을 사용하여 데이터베이스의 일시 중지 및 다시 시작 상태를 쿼리합니다.

PowerShell 사용

Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

Azure CLI 사용

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

리소스 제한

리소스 제한은 서버리스 컴퓨팅 계층을 참조하세요.

결제

서버리스 데이터베이스에 대해 청구되는 컴퓨팅의 양은 사용되는 최대 CPU 및 매초 사용된 메모리입니다. 사용된 CPU 및 메모리 양이 각 리소스에 대해 프로비전된 최소 금액보다 작으면 프로비전된 금액이 청구됩니다. 청구를 위해 CPU와 메모리를 비교하기 위해 메모리는 vCore당 GB 수를 3GB로 다시 크기 조정하여 vCore 단위로 정규화됩니다.

  • 청구되는 리소스: CPU 및 메모리
  • 청구 금액: vCore 단가 * 최댓값(최소 vCore 수, 사용된 vCore 수, 최소 메모리 GB * 1/3, 사용된 메모리 GB * 1/3)
  • 과금 시간 단위: 초당

vCore 단가는 초당 vCore당 비용입니다. 하이퍼스케일의 경우 HA 복제본 또는 명명된 복제본의 vCore 단가가 주 복제본보다 낮습니다.

지정된 지역의 특정 단가는 Azure SQL Database 가격 페이지를 참조하세요.

범용 데이터베이스 또는 하이퍼스케일 주 복제본 또는 명명된 복제본에 대해 서버리스로 청구되는 컴퓨팅의 양은 다음 메트릭에 의해 노출됩니다.

  • 메트릭: app_cpu_billed(vCore 시간(초))
  • 정의: 최댓값(최소 vCore 수, 사용된 vCore 수, 최소 메모리 GB * 1/3, 사용된 메모리 GB * 1/3)
  • 보고 빈도: 1분 이상 집계된 초당 측정값을 기준으로 분당.

주 복제본 또는 명명된 복제본에 속하는 하이퍼스케일 HA 복제본에 대해 서버리스로 청구되는 컴퓨팅의 양은 다음 메트릭에 의해 노출됩니다.

  • 메트릭: app_cpu_billed_HA_replicas(vCore 초)
  • 정의: 부모 리소스에 속한 HA 복제본의 최대 합계(최소 vCore, 사용된 vCore, 최소 메모리 GB * 1/3, 사용된 메모리 GB * 1/3)입니다.
  • 부모 리소스 및 메트릭 엔드포인트: 주 복제본과 명명된 복제본은 연결된 HA 복제본에 대해 청구되는 컴퓨팅을 측정하는 이 메트릭을 개별적으로 노출합니다.
  • 보고 빈도: 1분 이상 집계된 초당 측정값을 기준으로 분당.

최소 컴퓨팅 청구서

서버리스 데이터베이스가 일시 중지되면 컴퓨팅 청구서는 0입니다. 서버리스 데이터베이스가 일시 중지되지 않은 경우, 최소 컴퓨팅 청구서는 최댓값(최소 vCore 수, 최소 메모리 GB * 1/3)을 기준으로 한 vCore 수에 해당합니다.

예:

  • 범용 계층의 서버리스 데이터베이스가 3.0GB 메모리에 해당하는 최대 vCore 8개 및 1분 vCore로 일시 중지되고 구성되지 않는다고 가정합니다. 그리고 최소 컴퓨팅 청구서는 최댓값(1개 vCore, 3.0GB * 1개 vCore/3GB) = 1개 vCore를 기준으로 합니다.
  • 범용 계층의 서버리스 데이터베이스가 최대 vCore 4개와 2.1GB 메모리에 해당하는 0.5분 vCore로 일시 중지되고 구성되지 않는다고 가정합니다. 그리고 최소 컴퓨팅 청구서는 최댓값(0.5개 vCore, 2.1GB * 1개 vCore/3GB) = 0.7개 vCore를 기준으로 합니다.
  • 하이퍼스케일 계층의 서버리스 데이터베이스에 HA 복제본이 하나 있고 HA 복제본이 없는 명명된 복제본이 있는 주 복제본이 있다고 가정합니다. 각 복제본이 최대 vCore 8개와 3GB 분 메모리에 해당하는 1분 vCore로 구성되어 있다고 가정합니다. 그런 다음 주 복제본, HA 복제본 및 명명된 복제본에 대한 최소 컴퓨팅 요금은 각각 최대(1 vCore, 3GB * 1 vCore/3GB) = 1 vCore를 기반으로 합니다.

서버리스용 Azure SQL Database 가격 계산기를 사용하여 구성된 최대 및 최소 vCore 수를 기준으로 구성할 수 있는 최소 메모리를 결정할 수 있습니다. 대체로 구성된 최소 vCore 수가 0.5개 vCore보다 큰 경우, 최소 컴퓨팅 청구서는 구성된 최소 메모리와 독립적이며, 구성된 최소 vCore 수에 따라서만 달라집니다.

시나리오 예제

1분 vCore 및 최대 4개의 vCore로 구성된 범용 계층의 서버리스 데이터베이스를 고려합니다. 이 구성은 약 3GB 최소 메모리와 12GB 최대 메모리에 해당합니다. 자동 일시 중지 지연이 6시간으로 설정되고 데이터베이스 워크로드는 24시간 중 처음 2시간 동안 활성 상태이고 그 외에는 비활성 상태라고 가정합니다.

이 경우 데이터베이스는 처음 8시간 동안 컴퓨팅 및 스토리지 비용이 청구됩니다. 2시간 지난 후부터는 데이터베이스가 비활성 상태이지만, 데이터베이스가 온라인 상태일 때 프로비저닝된 최소 컴퓨팅에 기반하여 나머지 6시간에 대해 컴퓨팅 비용이 청구됩니다. 데이터베이스가 일시 중지되어 있는 동안 24시간 중 나머지 시간은 스토리지 비용만 청구됩니다.

정확하게, 이 예제의 컴퓨팅 청구서는 다음과 같이 계산됩니다.

시간 간격 초당 사용된 vCore 수 초당 사용된 GB 청구된 컴퓨팅 차원 시간 간격에 따라 청구된 vCore 초
0:00-1:00 4 9 사용된 vCore 수 vCore 4개 * 3600초 = 14400 vCore 초
1:00-2:00 1 12 사용된 메모리 12GB * 1/3 * 3600초 = 14400 vCore 초
2:00-8:00 0 0 프로비저닝된 최소 메모리 3GB * 1/3 * 21600초 = 21600 vCore 초
8:00-24:00 0 0 일시 중지되어 있는 동안 청구된 컴퓨팅 없음 0 vCore 초
24시간 동안 청구된 총 vCore 초 50400 vCore 초

컴퓨팅 단가가 $0.000145/vCore/초라고 가정합니다. 그러면 24시간 기간에 대해 청구되는 컴퓨팅은 컴퓨팅 단가와 청구되는 vCore 초를 곱한 값($0.000145/vCore/second * 50400 vCore 초 ~ $7.31)입니다.

Azure 하이브리드 혜택 및 예약된 용량

서버리스 컴퓨팅 계층에는 AHB(Azure 하이브리드 혜택) 및 예약된 용량 할인이 적용되지 않습니다.

사용 가능한 지역

최대 vCore 40개를 지원하는 서버리스 컴퓨팅 계층은 중국 동부, 중국 북부, 독일 중부, 독일 북동부, US Gov 중부(아이오와) 지역을 제외한 전 세계에서 사용할 수 있습니다.

최대 vCore 80개를 지원하는 지역

현재 서버리스의 최대 vCore 80개는 오스트레일리아 동부, 오스트레일리아 남동부, 캐나다 중부, 미국 중부, 동아시아, 미국 동부, 미국 동부 2, 프랑스 중부, 프랑스 남부, 인도 중부, 일본 동부, 일본 서부, 미국 중북부, 북유럽, 노르웨이 동부, 카타르 중부, 남아프리카 공화국 북부, 미국 중남부, 스위스 북부, 영국 남부, 영국 서부, 서유럽, 미국 서부, 미국 서부 2, 미국 서부 3 지역에서 지원됩니다.

최대 vCore 80개의 가용성 영역을 지원하는 지역

현재 가용성 영역이 지원되는 서버리스의 최대 vCore 80개는 미국 동부, 서유럽, 미국 서부 2, 미국 서부 3 지역으로 제한되고 더 많은 지역이 계획되어 있습니다.

다음 단계