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

적용 대상:Azure SQL Database

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

개요

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

서버리스 청구가 비활성으로 인한 컴퓨팅 요금 발생을 중지하는 시기를 나타내는 다이어그램

성능 구성

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

비용

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

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

시나리오

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

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

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

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

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

컴퓨팅 계층 비교

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

구매 모델 및 서비스 계층

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

자동 확장

크기 조정 응답성

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

메모리 관리

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

캐시 재사용

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

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

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

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

캐시 하이드레이션

SQL 메모리 캐시는 프로비저닝된 데이터베이스와 동일한 방식과 동일한 속도로 디스크에서 데이터를 가져올 때 증가합니다. 데이터베이스를 사용 중이면 캐시는 사용 가능한 메모리가 있는 동안 제한 없이 증가할 수 있습니다.

디스크 캐시 관리

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

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

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

자동 일시 중지

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

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

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

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

• 지역 복제(활성 지역 복제 및 장애 조치(failover) 그룹)
• LTR(장기 백업 보존)
• SQL 데이터 동기화에서 사용되는 동기화 데이터베이스. 동기화 데이터베이스와 달리 허브 및 구성원 데이터베이스는 자동 일시 중지를 지원합니다.
• 서버리스 데이터베이스가 포함된 논리 서버에 대해 생성된 DNS 별칭
• 탄력적 작업, 자동 일시 중지 사용 서버리스 데이터베이스는 작업 데이터베이스로 지원되지 않습니다. 탄력적 작업의 대상이 되는 서버리스 데이터베이스는 자동 일시 중지를 지원합니다. 작업 연결은 데이터베이스를 다시 시작합니다.

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

자동 일시 중지 문제 해결

자동 일시 중지를 사용하도록 설정하고 자동 일시 중지를 차단하는 기능이 사용되지 않지만 지연 기간 후에 데이터베이스가 자동 일시 중지되지 않는 경우 애플리케이션 또는 사용자 세션이 자동 일시 중지를 방지할 수 있습니다.

현재 데이터베이스에 연결된 애플리케이션 또는 사용자 세션이 있는지 확인하려면 클라이언트 도구를 사용하여 데이터베이스에 연결한 후 다음 쿼리를 실행합니다.

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 Database 및 Azure Synapse Analytics 대한 감사를 사용하고 관련 기간 동안 감사 데이터를 검사할 수 있습니다.

자동 다시 시작

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

이러한 작업을 수행하는 모니터링, 관리 또는 기타 솔루션은 자동 재개를 트리거합니다. 데이터베이스가 온라인 상태여야 하는 일부 서비스 업데이트를 배포하는 동안 자동 다시 시작도 트리거됩니다.

연결

서버리스 데이터베이스가 일시 중지되면 첫 번째 연결 시도에서 데이터베이스가 다시 시작되고 40613 오류 코드로 인해 데이터베이스를 사용할 수 없다는 오류가 반환됩니다. 데이터베이스가 다시 시작되면 로그인을 다시 시도하여 연결을 설정할 수 있습니다. 연결 재시도 논리 권장 사항을 따르는 데이터베이스 클라이언트는 수정할 필요가 없습니다. 연결 다시 시도 논리 옵션 및 권장 사항은 다음을 참조하세요.

• SqlClient의 연결 다시 시도 논리
• Entity Framework Core를 사용하는 SQL Database의 연결 재시도 논리
• Entity Framework 6을 사용하는 SQL Database의 연결 재시도 논리
• ADO.NET 사용하는 SQL Database의 연결 재시도 논리

대기 시간

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

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

키 삭제 또는 해지

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

키 회전

BYOK(고객 관리형 투명한 데이터 암호화)를 사용하고 서버리스 자동 일시 중지를 사용하도록 설정한 경우 키가 회전될 때마다 데이터베이스가 자동으로 다시 시작됩니다. 그러면 자동 일시 중지 조건이 충족되면 데이터베이스가 자동으로 일시 중지됩니다.

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

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

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

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

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

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

Azure Portal 사용

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

PowerShell 사용

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

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

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition Hyperscale -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 `
  -HighAvailabilityReplicaCount 1 -BackupStorageRedundancy Zone -ZoneRedundant

Azure CLI 사용

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

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

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e Hyperscale --compute-model Serverless -f Gen5 `
  --min-capacity 0.5 -c 2 `
  --ha-replicas 1 --backup-storage-redundancy Zone --zone-redundant

T-SQL(Transact-SQL) 사용

T-SQL을 사용하여 새 서버리스 데이터베이스를 만드는 경우 최소 vCore 수 및 자동 일시 중지 지연에 기본값이 적용됩니다. 해당 값은 나중에 Azure Portal에서 또는 PowerShell, Azure CLI 및 REST를 포함한 API를 통해 변경할 수 있습니다.

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

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

CREATE DATABASE testdb
( EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_S_Gen5_2') ; 

컴퓨팅 계층 또는 서비스 계층 간에 데이터베이스 이동

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

서버리스 데이터베이스를 범용 서비스 계층에서 하이퍼스케일 서비스 계층으로 이동할 수도 있습니다. 자세한 내용은 하이퍼스케일 데이터베이스 관리를 검토하세요.

컴퓨팅 계층 간에 데이터베이스를 이동할 때 PowerShell 또는 Azure CLI를 사용하는 경우 컴퓨팅 모델 매개 변수를 Serverless 또는 Provisioned(으)로 지정하고, T-SQL을 사용하는 경우 SERVICE_OBJECTIVE를 지정합니다. 리소스 제한을 검토하여 적절한 서비스 목표를 식별합니다.

다음 예제는 기존 데이터베이스를 프로비전된 컴퓨팅에서 서버리스 컴퓨팅으로 이동하는 예제입니다.

PowerShell 사용

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

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

Azure CLI 사용

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

az sql db update -g $resourceGroupName -s $serverName -n $databaseName ` 
  --edition Hyperscale --compute-model Serverless --family Gen5 `
  --min-capacity 1 --capacity 4 

T-SQL(Transact-SQL) 사용

T-SQL을 사용하여 컴퓨팅 계층 간에 데이터베이스를 이동하는 경우 최소 vCore 수 및 자동 일시 중지 지연에 기본값이 적용됩니다. 이후에 해당 값은 Azure Portal에서 또는 PowerShell, Azure CLI 및 REST를 포함한 API를 통해 변경할 수 있습니다. 자세한 내용은 ALTER DATABASE를 참조하세요.

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

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

서버리스 구성 수정

PowerShell 사용

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

Azure CLI 사용

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

Monitor

리소스 사용 및 청구

서버리스 데이터베이스의 리소스에는 앱 패키지, SQL 인스턴스 및 사용자 리소스 풀 엔터티가 포함됩니다.

앱 패키지

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

사용자 리소스 풀

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

메트릭

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

일시 중지 및 다시 시작 상태

자동 일시 중지를 사용하도록 설정된 서버리스 데이터베이스의 경우, 해당 데이터베이스가 보고하는 상태에는 다음 값이 포함됩니다.

Azure Portal 사용

Azure Portal에서 데이터베이스 상태는 해당 데이터베이스의 개요 페이지와 해당 서버의 개요 페이지에 표시됩니다. Azure Portal에서도 서버리스 데이터베이스의 일시 중지 및 다시 시작 이벤트 기록을 활동 로그에서 볼 수 있습니다.

PowerShell 사용

다음 PowerShell 예시를 사용하여 현재 데이터베이스 상태를 확인합니다.

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

Azure CLI 사용

다음 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당 비용입니다.

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

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

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

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

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

최소 컴퓨팅 청구서

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

예:

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

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

시나리오 예제

Azure 하이브리드 혜택 및 예약

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

사용 가능한 지역

최대 40개의 최대 vCore를 지원하는 범용 및 하이퍼스케일 계층용 서버리스는 다음 지역을 제외하고 전 세계적으로 사용할 수 있습니다.

• 중국 동부
• 중국 북부
• 독일 중부
• 독일 북동부
• US Gov 중부(아이오와)

범용 및 하이퍼스케일을 위한 가용성 영역이 없는 최대 vCore 80개를 지원하는 지역

현재 범용 및 하이퍼스케일 계층에 대한 서버리스의 최대 vCore 80개는 현재 다음 지역에서 지원됩니다.

• 오스트레일리아 중부 1
• 오스트레일리아 중부 2
• 오스트레일리아 동부
• 오스트레일리아 남동부
• 브라질 남부
• 브라질 남동부
• 캐나다 중부
• 캐나다 동부
• 미국 중부
• 중국 동부 2
• 중국 동부 3
• 중국 북부 2
• 중국 북부 3
• 동아시아
• 미국 동부
• 미국 동부 2
• 프랑스 중부
• 프랑스 남부
• 독일 북부
• 독일 중서부
• 인도 중부
• 인도 남부
• 이스라엘 중부
• 이탈리아 북부
• 일본 동부
• 일본 서부
• Jio 인도 중부
• Jio 인도 서부
• 한국 중부
• 한국 남부
• 말레이시아 남부
• 멕시코 중부
• 미국 중북부
• 북유럽
• 노르웨이 동부
• 노르웨이 서부
• 폴란드 중부
• 카타르 중부
• 남아프리카 북부
• 남아프리카 공화국 서부
• 미국 중남부
• 동남 아시아
• 스페인 중부
• 스웨덴 중부
• 스웨덴 남부
• 스위스 북부
• 스위스 서부
• 대만 북부
• 대만 북서부
• 아랍에미리트 중부
• 아랍에미리트 북부
• 영국 남부
• 영국 서부
• US Gov 동부
• 미국 정부 남중부
• US Gov 남서부
• 서유럽
• 미국 중서부
• 미국 서부
• 미국 서부 2
• 미국 서부 3

범용 및 하이퍼스케일을 위한 가용성 영역이 있는 최대 vCore 80개를 지원하는 지역

현재 범용 및 하이퍼스케일 계층에 대한 서버리스에서 가용성 영역이 지원되는 최대 vCore 80개는 더 많은 지역이 계획된 다음 지역에 제공됩니다.

• 오스트레일리아 동부
• 브라질 남부
• 캐나다 중부
• 미국 중부
• 동아시아
• 미국 동부
• 미국 동부 2
• 프랑스 중부
• 독일 중서부
• 인도 중부
• 일본 동부
• 한국 중부
• 북유럽
• 남아프리카 북부
• 미국 중남부
• 동남 아시아
• 스웨덴 중부
• 아랍에미리트 북부
• 영국 남부
• US Gov 동부
• 서유럽
• 미국 서부 2
• 미국 서부 3

관련 콘텐츠

• 시작하려면 빠른 시작: 단일 데이터베이스 만들기 - Azure SQL 데이터베이스를 참조하세요.
• 서버리스 서비스 계층 선택은 범용 및 하이퍼스케일을 참조하세요.