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

  • 아티클

적용 대상:Azure SQL Database

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

참고 항목

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

개요

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

Diagram indicating when serverless billing would stop incurring compute charges due to inactivity.

성능 구성

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

비용

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

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

시나리오

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

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

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

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

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

컴퓨팅 계층 비교

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

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

구매 모델 및 서비스 계층

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

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

자동 확장

크기 조정 응답성

서버리스 데이터베이스는 최대 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 감사를 사용하여 관련 기간의 감사 데이터를 검사할 수 있습니다.

Important

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

자동 다시 시작

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

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

연결

서버리스 데이터베이스가 일시 중지되면 첫 번째 로그인 활동에서 데이터베이스가 다시 시작되고 40613 오류 코드로 인해 데이터베이스를 사용할 수 없다는 오류가 반환됩니다. 데이터베이스가 다시 시작되면 연결을 설정하기 위해 로그인을 다시 시도할 수 있습니다. 권장 연결 재시도 논리가 있는 데이터베이스 클라이언트는 수정할 필요가 없습니다. 연결 재시도 논리에 권장되는 패턴은 다음을 검토합니다.

대기 시간

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

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

키 삭제 또는 해지

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

키 회전

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

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

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

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

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

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

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

Azure Portal 사용

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

PowerShell 사용

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

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -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 --compute-model Serverless -f Gen5 `
  --min-capacity 0.5 -c 2 --auto-pause-delay 720

T-SQL(Transact-SQL) 사용

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

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

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

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

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

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

참고 항목

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

컴퓨팅 계층 간에 데이터베이스를 이동할 때 PowerShell 및 Azure CLI를 사용하는 경우 컴퓨팅 모델 매개 변수를 Serverless 또는 Provisioned로 제공하고 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 --compute-model Serverless --family Gen5 `
  --min-capacity 1 --capacity 4 --auto-pause-delay 1440

T-SQL(Transact-SQL) 사용

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

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

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

서버리스 구성 수정

PowerShell 사용

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

Azure CLI 사용

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

Monitor

리소스 사용 및 청구

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

앱 패키지

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

사용자 리소스 풀

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

메트릭

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

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

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

시나리오 예제

최소 vCore 1개와 최대 vCore 4개로 구성된 범용 계층의 서버리스 데이터베이스를 고려합니다. 이 구성은 약 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 초 50,400 vCore초

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

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

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

사용 가능한 지역

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

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

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

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

  • 오스트레일리아 동부
  • 오스트레일리아 남동부
  • 브라질 남부
  • 캐나다 중부
  • 미국 중부
  • 동아시아
  • 미국 동부
  • 미국 동부 2
  • 프랑스 중부
  • 프랑스 남부
  • 독일 중서부
  • 인도 중부
  • 인도 남부
  • 일본 동부
  • 일본 서부
  • 미국 중북부
  • 북유럽
  • 노르웨이 동부
  • 카타르 중부
  • 남아프리카 북부
  • 미국 중남부
  • 스위스 북부
  • 영국 남부
  • 영국 서부
  • 서유럽
  • 미국 중서부
  • 미국 서부
  • 미국 서부 2
  • 미국 서부 3

범용을 위한 가용성 영역이 있는 최대 vCores 80개를 지원하는 지역

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

  • 미국 동부
  • 북유럽
  • 서유럽
  • 미국 서부 2

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

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

  • 미국 중부
  • 미국 동부
  • 북유럽
  • 서유럽
  • 미국 서부 2
  • 미국 서부 3

관련 콘텐츠