다음을 통해 공유

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이고 스토리지 비용만 발생합니다.

자세한 비용 정보를 보려면 청구를 참조하십시오.

시나리오

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

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

  • 일정 기간 활동이 없고 평균 컴퓨팅 활용률도 저조하게 나타나는 등, 사용 패턴이 일정하지 않고 예측하기 어려운 단일 데이터베이스
  • 자주 재조정되는 프로비저닝된 컴퓨팅 계층의 단일 데이터베이스와 컴퓨팅 재조정을 서비스에 위임하려는 고객
  • 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(사용자 리소스 풀에서 실행되는 사용자 워크로드의 경우)

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

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

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

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

자동 일시 정지 문제 해결

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

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

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

중요함

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

자동 재개

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

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

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

연결

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

  • SqlClient에서의 연결 재시도 로직
  • Entity Framework Core를 사용하여 SQL 데이터베이스에서 연결 재시도 논리
  • Entity Framework 6을 사용하는 SQL Database의 연결 재시도 논리
  • ADO.NET을 사용한 SQL 데이터베이스의 연결 시도 재시도 로직

대기 시간

서버리스 데이터베이스가 자동으로 다시 시작되기까지의 대기 시간과 자동으로 일시 중지되기까지의 대기 시간은 일반적으로 각각 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 사용

  • 범용
  • 하이퍼스케일

다음 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에서 또는 PowerShell, Azure CLI 및 REST를 포함한 API를 통해 변경할 수 있습니다.

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

  • 범용
  • 하이퍼스케일

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

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

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

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

서버리스 데이터베이스를 범용 서비스 계층에서 하이퍼스케일 서비스 계층으로 이동할 수도 있습니다. 자세한 내용은 기존 데이터베이스를 하이퍼스케일변환을 참조하세요.

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

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

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에서 또는 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 인수를 사용합니다. 서버리스 자동 일시 중지는 현재 하이퍼스케일 계층에서 지원되지 않으므로 자동 일시 중지 지연 인수는 범용 계층에만 적용됩니다.

모니터

리소스 사용 및 청구

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

앱 패키지

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

사용자 리소스 풀

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

측정지표

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

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

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

일시 중지 및 다시 시작 상태

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

상태 설명
온라인 데이터베이스가 온라인 상태입니다.
일시 중지 중 데이터베이스가 온라인에서 일시 중지 상태로 전환되고 있습니다.
일시 중지됨 데이터베이스가 일시 중지되었습니다.
재개 중 데이터베이스가 일시 중지에서 온라인 상태로 전환되고 있습니다.

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 복제본 또는 명명된 복제본에 대해 서버리스로 청구되는 컴퓨팅의 양은 다음 메트릭을 통해 확인할 수 있습니다.

  • 메트릭: app_cpu_billed_HA_replicas (vCore 시간(초))
  • 정의: 부모 리소스에 속하는 HA 복제본(replica)에 대한 최대값(최소 vCore, 사용된 vCore, 최소 메모리 GB * 1/3, 사용된 메모리 GB * 1/3)의 합계입니다.
  • 부모 리소스 및 메트릭 엔드포인트: 기본 복제본과 명명된 복제본 각각이 개별적으로 이 메트릭을 제공하여 관련된 모든 고가용성(HA) 복제본에 대해 청구된 계산을 측정합니다.
  • 보고 빈도: 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개로 구성되어 있다고 가정해 보겠습니다. 그런 다음 주 복제본, HA 복제본 및 명명된 복제본 각각에 대한 최소 컴퓨팅 비용은 최대값(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의 수 4개 vCore * 3,600초 = 14,400 vCore 초단위
1:00-2:00 1 12 사용된 메모리 12GB * 1/3 * 3,600초 = 14,400 vCore 초
2:00-8:00 0 0 프로비저닝된 최소 메모리 3GB * 1/3 * 21,600초 = 21,600 vCore 초
8:00-24:00 0 0 일시 중지 중에는 비용이 청구되지 않습니다 0 vCore 초
24시간 동안 청구된 총 vCore 초 50,400 vCore 초

컴퓨팅 단가가 $0.000145/vCore/초라고 가정합니다. 그런 다음 이 24시간 동안 청구되는 컴퓨팅 비용은 계산 단가와 vCore 초의 곱으로 계산됩니다: $0.000145/vCore/초 * 50,400 vCore 초 ~ $7.31.

Azure 하이브리드 혜택 및 예약

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

사용 가능한 지역

지역별 가용성은 Azure SQL Database 대한 지역별 서버리스 가용성참조하세요.

관련 콘텐츠