영업: 1-800-867-1380

Azure SQL 데이터베이스 성능 지침

업데이트 날짜: 2014년 9월

저자: Conor Cunningham, Kun Cheng, Jan Engelsberg

기술 검토자: Morgan Oslake, Joanne Marone, Keith Elmore, José Batista-Neto, Rohit Nayak

Microsoft Azure SQL 데이터베이스에는 Basic, Standard, Premium의 세 가지 서비스 계층이 있습니다. Premium 서비스 계층은 Azure SQL 데이터베이스 및 해당 보조 복제본의 리소스 크기를 엄격하게 제어함으로써 클라우드 응용 프로그램 성능을 더욱 잘 예측할 수 있습니다. Azure SQL 데이터베이스는 이러한 개념을 Standard 서비스 계층으로 확장하여, Premium 서비스 계층이 제공하는 것보다 낮은 성능 요구 사항으로 데이터베이스 성능을 매우 정확하게 예측할 수 있습니다. Basic 서비스 계층은 저렴한 데이터베이스에 대한 성능 요구 사항을 수행하도록 디자인되었습니다.

이 문서에서는 서비스 계층이 사용자의 응용 프로그램에 적합한지 여부를 확인하는 데 도움이 되는 지침과, Azure SQL 데이터베이스를 최대한 활용할 수 있도록 응용 프로그램을 튜닝하는 방법에 대한 권장 사항을 제공합니다. 여기에 포함된 섹션은 다음과 같습니다.

Azure SQL 데이터베이스 배경

서비스 계층의 차이점

서비스 계층을 사용하는 이유

리소스 사용 이해

응용 프로그램 튜닝

결론

Basic, Standard 및 Premium 서비스 계층을 통해 Azure SQL 데이터베이스 서비스를 향상시키는 방법을 이해하려면 Azure SQL 데이터베이스에 대한 전반적인 지식이 도움이 될 수 있습니다. 여러 가지 이유로 인해 Azure SQL 데이터베이스를 선택할 수 있습니다. 그러한 이유 중 하나는 시간이 오래 걸리는 하드웨어 구입 및 설치 과정을 방지하기 위해서입니다. Azure SQL 데이터베이스를 사용하면 구매 주문 승인, 컴퓨터 도착, 전원 및 냉각 업그레이드, 설치 수행 등의 과정을 기다릴 필요 없이 즉석에서 데이터베이스를 만들고 삭제할 수 있습니다. Microsoft는 각 데이터 센터에서 집계된 요구 사항을 기반으로 하드웨어를 미리 프로비전함으로써 이러한 어려움을 해결하고 아이디어를 솔루션으로 전환하는 데 필요한 시간을 크게 줄여 줍니다. 이렇게 하면 하드웨어를 직접 구입하고 배포하는 방법에 비해 업무 시간을 몇 주 또는 몇 개월까지 절약할 수 있습니다.

또한 Microsoft는 자동 HA, 부하 분산 및 기본 제공 관리와 같은 다양한 자동 관리 기능을 Azure SQL 데이터베이스에 포함시켰습니다.

  • 자동 고가용성(HA)

    Azure SQL 데이터베이스는 각 사용자 데이터베이스에 대해 세 개 이상의 복제본을 유지 관리하며, 각 변경 사항을 복제본의 쿼럼에 동기적으로 자동 커밋하는 논리를 포함합니다. 이를 통해 어떠한 단일 시스템 오류라도 데이터 손실로 이어지지 않도록 보장합니다. 또한 각 복제본은 서로 다른 하드웨어 랙에 배치되므로 전원 또는 네트워크 스위치 오류가 발생하더라도 데이터베이스에는 영향을 주지 않습니다. 마지막으로 컴퓨터가 손상되더라도 복제본을 자동으로 재구축하는 논리가 있어서 컴퓨터가 정상 상태가 아니어도 시스템에서 필요한 상태 속성이 자동으로 보존됩니다. 이러한 메커니즘은 오늘날 고가용성 솔루션을 설치하고 구성하는 데 필요한 시간이 오래 걸리는 프로세스를 방지합니다. 사용자의 데이터에 맞게 미리 구성된 HA 솔루션을 사용함으로써 기존의 기술을 사용해서 중요 업무용 데이터베이스 솔루션을 구축해야 하는 또 다른 어려운 문제를 겪을 필요가 없습니다.

  • 부하 분산

    또한 기존의 가상 컴퓨터와 달리 Azure SQL 데이터베이스에는 여러 컴퓨터 간에 자동으로 부하를 분산하는 메커니즘도 포함되어 있습니다. 부하 분산 장치는 클러스터의 리소스 사용을 동적으로 감시하면서 여러 사용자 간에 부하를 동적으로 공평하게 공유하기 위해 데이터베이스 복제본을 클러스터에 있는 컴퓨터로 이동합니다. 따라서 부하 분산 장치가 사용량이 많은 데이터베이스를 서로 다른 위치로 마이그레이션할 수 있기 때문에 데이터베이스의 요청 시 용량 조정 기능을 확장하고 사용자가 각 데이터베이스의 용량 요구 사항을 독립적으로 고려할 수 있게 해줍니다. 여러 데이터베이스가 포함된 솔루션을 만들 때, 이 논리는 가상 컴퓨터의 특정 크기 제한 대신 각 데이터베이스의 용량 요구 사항에 집중할 수 있게 해주는 추상화 계층을 제공합니다.

  • 기본 제공 관리

    Azure SQL 데이터베이스는 서비스로 실행됩니다. 즉, 각 데이터베이스에 대한 가동 시간 목표가 정의되어 오래 걸리는 유지 관리 작동 시간을 방지합니다. 이 서비스는 Microsoft에서 단일 공급업체 솔루션으로 제공됩니다. 따라서 어떤 문제가 발생하더라도 문제 해결을 위해 여러 공급업체에 문의할 필요가 없습니다. Microsoft는 또한 지속적인 서비스 업데이트를 통해, 기능 및 용량을 추가하고, 사용 환경을 개선하고자 노력하고 있습니다. 업데이트는 일반 HA 장애 조치(failover) 메커니즘에 통합되어 투명한 방식으로 수행되고, 시스템 작동을 중지할 필요가 없습니다. 따라서 이후에도 서버 업그레이드를 기다리느라 시스템 작동을 중지할 필요 없이 업데이트가 발표될 때마다 즉시 새로운 기능을 활용할 수 있습니다.

이러한 모든 기능은 매달 몇 달러의 저렴한 초기 비용부터 시작하여 모든 서비스 계층에 제공됩니다. 이러한 비용은 고유 서버를 구입하고 실행하는 것과 비교할 때 매우 저렴하기 때문에 아주 작은 규모의 프로젝트라도 많은 비용을 지불할 필요 없이 Azure를 활용할 수 있습니다.

Microsoft는 Azure SQL 데이터베이스를 처음 출시할 때 고객의 서비스 사용 방식을 이해하고 엔지니어링 팀에서 이후 기능을 계획하는 기반이 될 수 있도록 일부 고객들과 긴밀하게 협력했습니다. 이러한 고객 참여를 통해 Microsoft는 이 기능 집합이 어떤 고객들에게 적합한지 확인할 수 있었습니다. 예를 들어 새로운 클라우드 서비스를 개발하는 신생 기업에서 요청 시 용량 제공 기능과 줄어든 관리 부담을 통해 업무를 간소화하고 자신의 핵심 업무에 보다 많은 시간을 집중할 수 있다는 것이 자주 발견되었습니다. 대규모의 다중 계층 데이터베이스 솔루션에서 제공되는 중앙 API 서비스와 같이 일부 다른 고객들의 경우에는 현재까지 Azure SQL 데이터베이스 서비스로 충족되지 않은 까다로운 성능 요구 사항과 관련된 부문에서 문제가 노출되었습니다. 고객의 의견을 종합해보면 일부 고객은 비용 절감을 위해 성능 차이를 충분히 수용할 수 있었지만, 다른 고객들은 이러한 데이터베이스를 기반으로 더욱 뛰어난 가치를 쉽게 구축할 수 있도록 구체적인 성능 보장에 더 많은 관심을 가졌습니다.

모든 요구 사항을 충족할 수 있도록 Microsoft는 Basic, Standard, Premium의 세 가지 서비스 계층을 제공합니다. 각 서비스 계층에는 예측 가능한 방식으로 데이터베이스를 실행할 수 있는 기능을 제공하는 성능 수준이 한 개 이상 있습니다. 이 기능에 대한 설명은 DTU(Database Throughput Unit)에 나와 있습니다. 다음 표에는 서비스 계층, 성능 수준 및 DTU가 나와 있습니다.

 

Уровень обслуживания

Уровень производительности

DTU

기본

기본

5

Standard

S0

10

Standard

S1

20

Standard

S2

50

프리미엄

P1

100

프리미엄

P2

200

프리미엄

P3

800

Basic 서비스 계층은 시간별로 각 데이터베이스에 대한 정확한 성능을 예측하도록 디자인되었습니다. Basic 데이터베이스의 DTU는 성능에 대한 여러 개의 동시 요청이 없어도 작은 데이터베이스에 충분한 리소스를 제공하도록 디자인되었습니다.

Standard 서비스 계층은 성능 예측 가능성을 향상시키고 작업 그룹 및 웹 응용 프로그램 같은 동시 요청이 여러 개인 데이터베이스를 늘려 줍니다. Standard 서비스 계층 데이터베이스를 사용함으로써 분별로 예측 가능한 성능을 기반으로 데이터베이스 응용 프로그램 크기를 지정할 수 있습니다.

Premium 서비스 계층의 성능에 대한 핵심 용량은 각 Premium 데이터베이스에 대해 초별로 예측 가능한 성능입니다. Premium 서비스 계층을 사용하면 해당 데이터베이스의 최대 부하를 기반으로 해당 데이터베이스 응용 프로그램 크기를 지정할 수 있고, 대기 시간에 민감한 작업 수행 시 성능 차이 때문에 작은 쿼리가 예상보다 오랜 시간이 소요되는 문제가 제거됩니다. 이 모델은 최대 리소스 요구, 성능 차이 또는 쿼리 대기 시간해 대한 강력한 조건을 설정해야 하는 응용 프로그램에서 필요한 개발 및 제품 유효성 검사 주기를 크게 간소화할 수 있습니다. 또한 일부 온-프레미스 응용 프로그램의 경우 이 모델은 이러한 응용 프로그램이 원래 작성될 때 전제 조건으로 사용된 기존의 격리된 환경과도 상당히 비슷한 환경이기 때문에 이러한 응용 프로그램을 중요 변경 없이 마이그레이션할 수 있습니다.

Standard 서비스 계층과 마찬가지로 Premium 서비스 계층은 고객이 원하는 격리 수준에 따라 다양한 성능 수준을 선택할 수 있습니다.

Standard 및 Premium의 성능 수준 설정에 따라 필요한 용량에 대해서만 비용을 지불하고 작업의 변동에 따라 용량을 늘리거나 줄일 수 있습니다. 예를 들어 신학기 쇼핑 시즌 중에 데이터베이스 작업이 늘어난다고 가정할 경우 이 기간 중 데이터베이스의 성능 수준을 늘리고, 최대 사용 기간이 지나면 예약 용량을 다시 줄일 수 있습니다. 따라서 업무 시즌에 맞게 클라우드 환경을 최적화하여 지불해야 할 비용을 최소화할 수 있습니다. 이 모델은 소프트웨어 제품 출시 주기에도 효과적입니다. 테스트 팀은 테스트 실행 기간 중 용량을 할당하고 테스트가 완료되면 할당된 용량을 해제할 수 있습니다. 이러한 용량 요청 방식은 필요한 용량에 대해서만 비용을 지불하고 자주 사용되지 않는 전용 리소스에 대한 소비를 방지하는 모델에 적합합니다. 이 방식은 많은 Microsoft 고객들이 SQL Server에 사용한 것과 같은 기존의 전용 하드웨어 모델과 상당히 비슷한 성능 환경을 제공합니다. 이 방식에서는 훨씬 많은 응용 프로그램을 Azure SQL 데이터베이스에서 쉽게 실행할 수 있습니다.

각 작업이 다를 수 있지만 서비스 계층의 목적은 다양한 성능 수준에서 높은 성능 예측 가능성을 제공하는 것입니다. 따라서 해당 데이터베이스에 대한 리소스 요구 사항이 높은 고객이 전용 컴퓨팅 환경에서 작업할 수 있습니다.

Basic 서비스 계층 기능이 적용될 수 있는 일반적인 사례는 다음과 같습니다.

  • Azure SQL 데이터베이스 시작하기 – 개발 중인 응용 프로그램은 높은 성능 수준이 필요하지 않습니다. Basic 데이터베이스는 저렴한 가격으로 이상적인 데이터베이스 개발 환경을 제공합니다.

  • 단일 사용자 데이터베이스 – 단일 사용자를 데이터베이스에 정상적으로 연결하는 응용 프로그램에는 높은 요구 사항 동시성 및 성능이 없습니다. 이러한 요구 사항이 있는 응용 프로그램은 Basic 서비스 계층 후보로 적합합니다.

Standard 서비스 계층 기능이 적용될 수 있는 일반적인 사례는 다음과 같습니다.

동시 요청이 여러 개 있는 데이터베이스 - 많은 양의 리소스를 필요로 하는 적절한 트래픽이나 부서 응용 프로그램을 사용하는 웹 사이트처럼 한 번에 두 명 이상의 사용자를 지원하는 응용 프로그램은 Standard 서비스 계층 후보로 적합합니다.

Premium 서비스 계층 기능이 적용될 수 있는 일반적인 사례는 다음과 같습니다.

  • 높은 최대 부하 – 작업 수행을 위해 대량의 CPU, 메모리 또는 IO가 필요한 응용 프로그램. 예를 들어 데이터베이스 작업이 긴 시간 동안 여러 CPU 코어를 소비하는 것으로 알려진 경우, Premium 데이터베이스가 적합할 수 있습니다.

  • 다수의 동시 요청 - 일부 데이터베이스 응용 프로그램 서비스는 많은 수의 동시 요청을 처리해야 합니다(예: 트래픽이 많은 웹 사이트를 처리할 때). Basic 및 Standard 서비스 계층은 동시 요청 크기에 제한이 있습니다. 이보다 많은 연결이 필요한 응용 프로그램에서는 필요한 최대 요청 수를 처리할 수 있도록 적합한 예약 크기를 선택해야 합니다.

  • 낮은 대기 시간 – 일부 응용 프로그램에서는 데이터베이스의 응답에 대해 최소 시간을 보장해야 합니다. 대규모 고객 작업 중 특정 저장 프로시저가 호출된다고 가정할 때 해당 호출이 전체 중 99% 이상에서 20밀리초 내에 반환되어야 할 수 있습니다. 이러한 종류의 응용 프로그램에는 컴퓨팅 성능 가용성을 보장하기 위해 Premium 데이터베이스가 적합할 수 있습니다.

Azure SQL 데이터베이스를 사용할 때 성능 문제가 발생할 수 있는 일반적인 시나리오에 대한 자세한 내용은 Azure SQL 데이터베이스 및 SQL Server -- 성능과 확장성 비교 및 대조를 참조하세요.

필요한 정확한 수준은 각 리소스 차원에서의 최대 부하 요구 사항에 따라 달라집니다. 응용 프로그램에 따라 한 가지 리소스가 조금만 사용될 수도 있고 다른 리소스에 대한 요구 사항이 매우 높을 수도 있습니다.

아래 표에 서비스 계층 구조에 대한 설명이 나와 있습니다.

 

서비스 계층/성능 수준 DTU 최대 DB 크기 최대 작업자 스레드 최대 세션 예측 가능성

기본

5

2 GB

30

300

좋음

Standard/S0

10

250 GB

60

600

우수함

Standard/S1

20

250 GB

90

900

우수함

Standard/S2

50

250 GB

120

1,200

우수함

Premium/P1

100

500 GB

200

2,400

최상

Premium/P2

200

500 GB

400

4,800

최상

Premium/P3

800

500 GB

1,600

19,200

최상

다음 그래프는 한 주 동안 매 시간 P2 성능 수준의 Premium 데이터베이스에 대한 CPU 리소스 사용률을 보여줍니다. 이 그래프에서는 월요일부터 시작해서 5일 간 사용량을 보여주며, 주말에 응용 프로그램의 리소스 사용량이 줄어드는 것을 알 수 있습니다.

SQL_DB

데이터에서 이 데이터베이스의 현재 최대 CPU 부하는 P2 성능 수준에 비해 50% CPU 사용률을 약간 넘은 값입니다(화요일 정오 무렵). 응용 프로그램의 리소스 프로필에서 CPU가 가장 중요한 요소라고 가정할 때 작업이 항상 부합되는 적합한 성능 수준이 되도록 하기 위해 P2를 선택해야 할 수 있습니다. 응용 프로그램이 시간 경과에 따라 증가할 것으로 예상되는 경우에는 응용 프로그램이 한계에 도달하지 않도록 추가 리소스 여유를 두는 것이 합리적입니다. 이렇게 하면 데이터베이스 호출 결과를 기반으로 웹 페이지를 표시하는 응용 프로그램을 지원하는 데이터베이스와 같이, 특히 대기 시간이 중요한 환경에서 요청을 효과적으로 처리하는 데 필요한 기능 부족으로 인해 발생하는 데이터베이스 오류가 고객에게 직접적으로 표시되지 않도록 방지할 수 있습니다.

동일한 그래프라도 응용 프로그램 유형에 따라 서로 다르게 해석될 수 있습니다. 예를 들어 매일 급여 데이터를 처리하는 응용 프로그램에서 위와 동일한 차트가 표시되었다고 가정할 때, 이러한 종류의 "일괄 작업" 모델은 P1 성능 수준으로도 충분할 수 있습니다. P1 성능 수준에는 100개의 DTU가 있고 P2 성능 수준에는 200개의 DTU가 있습니다. 즉, P1 성능 수준은 P2 성능 수준의 절반 성능을 제공합니다. 따라서 P2 CPU 사용률의 50%가 P1 CPU 사용률의 100%와 같습니다. 응용 프로그램에 제한 시간만 없으면, 큰 작업을 수행할 때 오늘 중으로만 처리되는 한 실행 시간이 2시간이 걸리든, 2.5시간이 걸리든 문제가 되지 않을 수 있습니다. 이 범주의 응용 프로그램에서는 P1 성능 수준을 사용할 수 있을 것입니다. 이 경우 하루 중 리소스 사용량이 낮아지는 기간이 있다는 사실을 활용할 수 있습니다. 즉, "큰 최대 부하"를 하루 중 사용량이 낮은 시간대로 지연시킬 수 있습니다. 작업을 하루 중 지정된 시간에 완료할 수만 있다면, P1 성능 수준이 이러한 응용 프로그램에 적합하며, 비용을 절감하는 데에도 도움이 될 것입니다.

Azure SQL 데이터베이스는 각 서버에 있는 master 데이터베이스의 sys.resource_stats 뷰에서 각 활성 데이터베이스에 대해 소비된 리소스 정보를 제공합니다. 테이블의 데이터는 5분 간격으로 집계됩니다. Basic, Standard 및 Premium 서비스 계층 사용 시 데이터가 테이블에 표시되는데 5분 이상 걸릴 수 있습니다. 즉, 이 데이터는 거의 실시간에 가까운 분석용으로 보다는 기록 확인용으로 더 효과적이라고 볼 수 있습니다. sys.resource_stats 뷰를 쿼리하면 데이터베이스의 최근 기록이 표시되어 선택된 예약에 따라 필요할 때 원하는 성능이 제공되었는지 여부를 확인할 수 있습니다. 다음 예제에서는 이 뷰의 데이터가 표시되는 방법을 보여줍니다.

SELECT TOP 10 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

SQL_DB

참고: 테이블의 일부 열은 공간 문제로 인해 잘려서 표시되었습니다. 출력에 대한 전체 설명은 sys.resource_stats 항목을 참조하십시오.

이 섹션에서는 Azure SQL 데이터베이스 사용을 모니터링하고 현재 리소스 사용률을 다른 성능 수준과 비교하는 방법을 설명합니다.

  1. sys.resource_stats 카탈로그 뷰는 데이터베이스 수준에서 더욱 많은 이전 리소스 사용 정보를 제공하도록 향상되었습니다. 예를 들어 "userdb1" 데이터베이스에 대해 이전 한 주의 리소스 사용량을 보려면 다음과 같이 쿼리를 실행할 수 있습니다.

    SELECT * 
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND 
          start_time > DATEADD(day, -7, GETDATE())
    ORDER BY start_time DESC;
    
    
  2. 작업이 성능 수준에 얼마나 잘 부합되는지 평가하려면 리소스 메트릭의 여러 가지 측면을 자세히 살펴봐야 합니다. 이러한 메트릭에는 CPU, 읽기, 쓰기, 작업자 수 및 세션 수 등이 포함됩니다. 다음은 평균 값 외에도 이러한 리소스 메트릭의 최대값을 보고하도록 수정된 sys.resource_stats를 사용한 쿼리입니다.

    SELECT 
        avg(avg_cpu_percent) AS 'Average CPU Utilization In Percent',
        max(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent',
        avg(avg_physical_data_read_percent) AS 'Average Physical Data Read Utilization In Percent',
        max(avg_physical_data_read_percent) AS 'Maximum Physical Data Read Utilization In Percent',
        avg(avg_log_write_percent) AS 'Average Log Write Utilization In Percent',
        max(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent',
        avg(active_session_count) AS 'Average # of Sessions',
        max(active_session_count) AS 'Maximum # of Sessions',
        avg(active_worker_count) AS 'Average # of Workers',
        max(active_worker_count) AS 'Maximum # of Workers'
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
  3. 위의 각 리소스 메트릭의 평균 및 최대값 정보를 사용하여 작업이 선택한 정보 수준에 얼마나 잘 부합되는지 평가할 수 있습니다. 대부분의 경우 sys.resource_stats의 평균 값은 목표 크기를 정하는 기준으로 사용될 수 있습니다. 이 값은 사용자의 주요 측정 기준으로 사용되어야 합니다. 예를 들어 S2 성능 수준에서 Standard 서비스 계층을 사용하는 경우 CPU, 읽기 및 쓰기에 대한 평균 사용률이 20%이하이고, 평균 작업자 수가 50 이하이며, 평균 세션 수가 200 이하이면 작업이 S1 성능 수준에 부합될 수 있습니다. 데이터베이스가 작업자 및 세션 제한을 벗어나지 않는지 쉽게 확인할 수 있습니다. 데이터베이스가 CPU, 읽기 및 쓰기에 대한 낮은 성능 수준에 부합되는지 확인하려면 낮은 성능 수준의 DTU 수를 현재 성능 수준의 DTU 수로 나눈 다음 그 결과에 100을 곱합니다.

    S1 DTU / S2 DTU * 100 = 5 / 25 * 100 = 20

    이 결과는 두 성능 수준의 상대적인 성능 차이(백분율)입니다. 사용률이 이 백분율을 초과하지 않으면 작업이 낮은 성능 수준에 부합할 수 있습니다. 하지만 모든 범위의 리소스 사용 값도 함께 확인하고 데이터베이스 작업이 낮은 성능 수준에 얼마나 자주 부합하는지에 대한 비율도 확인할 필요가 있습니다. 다음 쿼리는 위에 계산된 20%의 임계값에 따라 리소스 차원별로 맞춤 백분율을 출력합니다.

    SELECT 
        (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
    데이터베이스 SLO(서비스 수준 목표)를 기준으로 하여 작업이 낮은 성능 수준에 부합하는지 판단할 수 있습니다. 데이터베이스 작업 SLO가 99.9%이고 위의 쿼리가 세 리소스 차원 모두에 대해 99.9 이상의 값을 반환하는 경우 작업은 낮은 성능 수준에 거의 부합합니다.

    맞춤 백분율을 보면 SLO를 충족하기 위해 다음으로 높은 성능 수준으로 이동해야 하는지 여부를 알 수 있습니다. 예를 들어 "userdb1"은 지난 주에 대한 다음과 같은 사용률을 보여줍니다.

     

    평균 CPU 비율

    최대 CPU 비율

    24.5

    100.00

    평균 CPU는 성능 수준 제한의 1/4 정도이므로 데이터베이스 성능 수준에 충분히 적합합니다. 하지만 최대값은 데이터베이스가 성능 수준의 제한에 도달했음을 보여줍니다. 다음으로 높은 성능 수준으로 이동해야 합니까? 즉, 작업이 100%에 도달하는 빈도를 살펴보고 데이터베이스 작업 SLO와 비교해야 합니다.

    SELECT 
    (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
    ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent’
    ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    위의 쿼리가 세 개의 리소스 차원에 대해 99.9 이하의 값을 반환하면 다음으로 높은 성능 수준으로 이동하거나 응용 프로그램 튜닝 기법을 사용하여 Azure SQL 데이터베이스에서 부하를 줄여야 합니다.

  4. 또한 여기에서는 미래에 예상되는 작업 부하 증가량도 고려해야 합니다.

기존의 온-프레미스 SQL Server에서는 초기 용량 계획 과정이 프로덕션에서의 응용 프로그램 실행 과정과 분리된 경우가 많았습니다. 즉, SQL Server 실행을 위한 하드웨어 및 관련 라이선스 구입이 먼저 미리 수행된 다음 성능 튜닝은 나중에 수행되었습니다. Azure SQL 데이터베이스를 사용할 때는 사용 요금이 매월 청구되기 때문에 일반적으로 응용 프로그램의 실행 과정과 튜닝 과정을 하나로 묶는 것이 좋습니다. 요청 시 용량에 대한 비용 지급 모델을 통해 응용 프로그램에 대해 정확하지 않은 추측성 미래 증가 계획을 기반으로 하드웨어를 대량으로 과도하게 프로비전하는(그러면서도 너무 먼 미래를 예측해야 하기 때문에 종종 잘못된 예측으로 이어지는) 대신 지금 당장 필요한 최소한의 리소스만 사용할 수 있도록 응용 프로그램을 튜닝할 수 있습니다. 일부 고객의 경우에는 응용 프로그램을 튜닝하는 대신 하드웨어 리소스를 과도하게 프로비전하도록 선택할 수도 있습니다. 응용 프로그램 사용량이 많은 기간 중에 주요 응용 프로그램이 변경되지 않도록 하기 위해서는 이러한 방식도 합리적인 선택일 수 있습니다. Azure SQL 데이터베이스에서 서비스 계층을 사용할 때 응용 프로그램을 튜닝하면 리소스 요구 사항을 최소화하고 월간 비용을 낮출 수 있습니다.

서비스 계층은 응용 프로그램의 성능 안정성 및 예측성을 향상시킬 수 있도록 디자인되었지만 응용 프로그램 튜닝에 대한 몇 가지 모범 사례를 통해 이 기능을 더욱 효과적으로 활용할 수 있습니다. 많은 응용 프로그램의 경우 단순히 높은 성능 수준이나 서비스 계층으로 전환만 해도 상당한 성능 이점을 얻을 수 있지만, 추가적인 튜닝 없이 모든 응용 프로그램에서 큰 이점을 얻을 수 있는 것은 아닙니다. 다음과 같은 특성을 갖는 응용 프로그램은 Azure SQL 데이터베이스를 사용할 때 성능을 더욱 향상시킬 수 있도록 추가적인 응용 프로그램 튜닝도 고려해야 합니다.

  • "잦은" 동작으로 인해 성능이 느려지는 응용 프로그램

    여기에는 네트워크 대기 시간에 민감한 데이터 액세스 작업을 과도하게 수행하는 응용 프로그램들이 포함됩니다. 이러한 응용 프로그램은 Azure SQL 데이터베이스에 대한 데이터 액세스 작업 횟수를 줄일 수 있도록 수정해야 할 수도 있습니다. 예를 들어 임시 쿼리를 한 번에 일괄 처리하거나 쿼리를 저장 프로시저로 이동하는 등의 기법을 사용해서 응용 프로그램을 향상시킬 수 있습니다. 자세한 내용은 이어지는 '쿼리 일괄 처리' 섹션을 참조하십시오.

  • 전체 단일 시스템에서 지원할 수 없는 집중적인 작업 부하를 갖는 데이터베이스

    가장 높은 Premium 성능 수준의 리소스를 초과하는 데이터베이스는 적합한 후보가 아닙니다. 이러한 데이터베이스는 작업 부하를 스케일 아웃(scale out)하여 성능 이점을 얻을 수 있습니다. 자세한 내용은 이어지는 '데이터베이스 간 분할' 및 '기능 분할' 섹션을 참조하십시오.

  • 비최적 쿼리를 포함하는 응용 프로그램

    특히 데이터 액세스 계층에서 제대로 튜닝되지 않은 쿼리가 포함된 응용 프로그램은 높은 성능 수준 선택의 이점을 예상한 대로 얻기 어렵습니다. 이러한 쿼리에는 WHERE 절이 부족하거나, 인덱스가 누락되었거나, 통계가 오래된 쿼리를 예로 들 수 있습니다. 이러한 응용 프로그램은 표준 쿼리 성능 튜닝 기법의 이점을 얻을 수 있습니다. 자세한 내용은 이어지는 '누락된 인덱스' 및 '쿼리 튜닝/힌트' 섹션을 참조하십시오.

  • 비최적 데이터 액세스 설계가 포함된 응용 프로그램

    교착 상태와 같이 본질적으로 데이터 액세스의 동시성 문제가 있는 응용 프로그램은 높은 성능 수준 선택의 이점을 얻을 수 없습니다. 응용 프로그램 개발자는 Azure 캐싱 서비스 또는 기타 캐싱 기술을 사용해서 클라이언트 쪽에 데이터를 캐싱하여 Azure SQL 데이터베이스에 대한 왕복 횟수를 줄이는 것이 좋습니다. 이어지는 응용 프로그램 계층 캐싱 섹션을 참조하십시오.

이 섹션에서는 응용 프로그램의 성능을 최적화하고 가능한 한 최소한의 성능 수준으로 실행할 수 있도록 Azure SQL 데이터베이스를 튜닝하기 위해 사용할 수 있는 몇 가지 기법에 대해 설명합니다. 많은 기법이 기존의 SQL Server 튜닝 모범 사례와 일치하지만 일부 기법은 Azure SQL 데이터베이스에만 해당됩니다. 일부 경우에는 데이터베이스의 소비된 리소스에서 추가로 튜닝할 수 있는 영역을 조사하여 Azure SQL 데이터베이스에서 활용할 수 있도록 기존의 SQL Server 기법을 확대할 수 있습니다.

OLTP 데이터베이스 성능에서 한 가지 공통된 문제는 물리적 데이터베이스 디자인과 관련이 있습니다. 데이터베이스 스키마는 종종 부하 또는 데이터 볼륨 크기에 대한 테스트 없이 디자인되고 제공되는 경우가 많습니다. 작은 크기에서는 쿼리 계획 성능이 적합하더라도 프로덕션 수준의 데이터 볼륨에서는 성능이 크게 저하될 수도 있습니다. 이러한 문제의 가장 일반적인 원인은 쿼리에서 필터 또는 다른 제한 사항을 충족시킬 수 있는 적합한 인덱스가 부족하기 때문입니다. 이러한 쿼리는 종종 인덱스 검색만으로 충분한 상황에서 테이블 스캔을 수행합니다.

다음 예에서는 인덱스 검색으로도 충분한 상황에서 선택한 쿼리 계획에 테이블 스캔이 포함된 경우를 보여 줍니다.

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO dbo.missingindex(col2) VALUES (@a);
    SET @a += 1;
END
COMMIT TRANSACTION;
GO
SELECT m1.col1 
FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1) 
WHERE m1.col2 = 4;


SQL_DB

Azure SQL 데이터베이스에는 공통적인 누락 인덱스 조건을 찾아서 수정하는 방법에 대한 힌트를 데이터베이스 관리자에게 제공하는 기능이 포함되어 있습니다. Azure SQL 데이터베이스에 기본 제공되는 DMV(동적 관리 뷰)는 쿼리 컴파일 중 인덱스를 사용해서 쿼리 실행 예상 비용을 크게 줄일 수 있는지 검토합니다. DMV는 쿼리 실행 중 각 쿼리 계획의 실행 빈도를 추적하고 실행 중인 쿼리 계획과 인덱스를 사용할 경우의 쿼리 계획 간의 예상 격차를 추적합니다. 이를 통해 데이터베이스 관리자는 물리적 데이터베이스 디자인 변경을 통해 특정 데이터베이스 및 실제 작업 부하에 대해 향상될 수 있는 전반적인 작업 부하 비용 효과를 빠르게 추측할 수 있습니다.

다음 쿼리는 잠재적으로 누락된 인덱스를 평가하는 데 사용할 수 있습니다.

SELECT CONVERT (varchar, getdate(), 126) AS runtime, 
    mig.index_group_handle, mid.index_handle, 
    CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * 
            (migs.user_seeks + migs.user_scans)) AS improvement_measure, 
    'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + 
              CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + ' 
              (' + ISNULL (mid.equality_columns,'') 
              + CASE WHEN mid.equality_columns IS NOT NULL 
                          AND mid.inequality_columns IS NOT NULL 
                     THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '')
              + ')' 
              + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
    migs.*, 
    mid.database_id, 
    mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
INNER JOIN sys.dm_db_missing_index_group_stats AS migs 
    ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid 
    ON mig.index_handle = mid.index_handle
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

이 예에서는 다음 인덱스가 제안되었습니다.

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])

인덱스를 만든 후에는 동일한 SELECT 문을 실행해도 이제는 테이블 스캔 대신 인덱스 검색을 사용하는 다른 계획이 선택되어, 다음 쿼리 계획에 표시된 것처럼 훨씬 효율적으로 실행됩니다.

SQL_DB

여기서 중요한 것은 공유되는 상용 시스템의 IO 용량이 전용 서버 시스템보다 일반적으로 훨씬 제한적이라는 사실입니다. 따라서 Azure SQL 데이터베이스에서 서비스 계층의 각 성능 수준의 DTU 내에서 시스템을 최대한 활용할 수 있도록 불필요한 IO를 최소화하는 것이 매우 중요합니다. 적합한 물리적 데이터베이스 디자인을 선택할 경우 개별 쿼리의 대기 시간을 크게 향상시키고 크기 단위별로 처리할 수 있는 동시 요청의 처리량을 높이고, 쿼리를 충족시키는 데 필요한 비용을 최소화할 수 있습니다. 누락된 인덱스 DMV에 대한 자세한 내용은 sys.dm_db_missing_index_details를 참조하십시오.

Azure SQL 데이터베이스에 포함된 쿼리 최적화 프로그램은 기존의 SQL Server 쿼리 최적화 프로그램과 매우 비슷합니다. 쿼리 최적화 프로그램에 대한 쿼리 튜닝 및 추론 모델 제한 사항에 대한 이해를 돕기 위한 많은 모범 사례가 Azure SQL 데이터베이스에도 적용될 수 있습니다. Azure SQL 데이터베이스에서 쿼리를 튜닝하면 집계 리소스 요구를 줄이는 추가적인 이점을 얻을 수 있으며, 더 낮은 성능 수준에서 실행할 수 있기 때문에 튜닝되지 않은 응용 프로그램에 비해 더 적은 비용으로 응용 프로그램을 실행할 수 있습니다.

Azure SQL 데이터베이스에도 적용되는 SQL Server의 한 가지 공통적인 예는 컴파일 중 더욱 최적화된 계획을 만들기 위해 매개 변수를 "스니핑"하는 방법과 관련이 있습니다. 매개 변수 스니핑은 보다 최적화된 쿼리 계획을 생성하기 위해 쿼리를 컴파일할 때 쿼리 최적화 프로그램이 매개 변수의 현재 값을 고려하는 과정입니다. 이러한 전략을 사용하면 매개 변수 값을 인식하지 않은 상태에서 컴파일된 계획보다 상당히 빠른 쿼리 계획이 생성될 수 있지만 현재의 SQL Server/Azure SQL 데이터베이스의 동작은 아직까지 완벽하지 않습니다. 일부 경우에는 매개 변수가 스니핑되지 않을 수 있으며, 매개 변수가 스니핑되더라도 작업의 전체 매개 변수 값 집합을 고려할 때 생성된 계획이 최적화된 계획이 아닐 수도 있습니다. Microsoft는 보다 세밀하게 목적을 지정하고 매개 변수 스니핑의 기본 동작을 재정의할 수 있도록 쿼리 힌트(지시문)를 포함했습니다. 힌트를 사용하면 특정 고객의 작업에서 기본 SQL Server/Azure SQL 데이터베이스 동작이 완벽하지 않을 때의 문제를 해결할 수 있는 경우가 많습니다.

다음 예에서는 쿼리 프로세서가 성능 및 리소스 요구 사항 면에서 모두 최적이 아닌 계획을 생성할 수 있는 경우 및 쿼리 힌트를 사용해서 Azure SQL 데이터베이스에 대해 쿼리 런타임 및 리소스 요구 사항을 줄일 수 있는 방법을 보여줍니다.

설정의 예는 다음과 같습니다.

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));

DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO psptest1(col2) values (1);
    INSERT INTO psptest1(col2) values (@a);
    SET @a += 1;
END
COMMIT TRANSACTION
CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 
    WHERE col2 = @param1
    ORDER BY col2;
END
GO

CREATE PROCEDURE psp2 (@param2 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
    ORDER BY col2
    OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
END
GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

설정된 코드는 사선형 데이터 배포가 포함된 테이블을 만듭니다. 최적의 쿼리 계획은 선택한 매개 변수에 따라 달라집니다. 계획 캐싱 동작이 항상 가장 공통적인 매개 변수 값을 기반으로 쿼리를 다시 컴파일하는 것은 아닙니다. 즉, 다른 계획이 보다 효율적인 평균 계획으로 선택될 수 있더라도 최적이 아닌 계획이 캐시되고 여러 값에 대해 사용될 수 있습니다. 그런 다음 한 항목에 특별 쿼리 힌트(아래 설명된 추론)가 포함된 것을 제외하고는 서로 동일한 두 개의 저장 프로시저를 만듭니다.

예제(1부)

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp1 @param1=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END

예제(2부 – 2부를 시도하기 전에 원격 측정 데이터 결과를 확실하게 구분할 수 있도록 10분 정도 기다리십시오.)

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp2 @param2=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END


이 예제의 각 부분에서는 (테스트 데이터 집합에서 필요한 부하를 충분히 생성하기 위해) 매개 변수가 있는 삽입 문을 1000번 실행합니다. 저장 프로시저를 실행할 때 쿼리 프로세서는 첫 번째 컴파일을 수행하는 동안 프로시저에 전달된 매개 변수 값을 조사합니다(매개 변수 "스니핑"). 결과 계획이 캐시되고 매개 변수 값이 다르더라도 이후 호출에 사용됩니다. 따라서 모든 경우에 항상 최적화된 계획이 사용되지 않을 수 있습니다. 일부 경우에는 쿼리를 처음 컴파일할 때의 특정 사례보다 평균적인 사례에 더 효과적인 계획을 선택하도록 고객이 최적화 프로그램을 지정해야 합니다. 이 예에서 초기 계획은 매개 변수와 일치하는 각 값을 찾기 위해 모든 행을 읽는 "scan" 계획을 생성합니다.

SQL_DB

이 프로시저는 값 1을 사용해서 실행했기 때문에 결과 계획은 1에 대해 최적이지만 테이블의 다른 모든 값에 대해서는 최적이 아닙니다. 각 계획을 무작위로 선택할 경우 계획 수행이 더 오래 걸리고 실행 시 더 많은 리소스가 사용되기 때문에 결과 동작은 원하는 동작이 아닐 수 있습니다.

"SET STATISTICS IO ON"을 사용해서 테스트를 실행하면 이 예에서 수행된 논리적 스캔 작업이 표시됩니다. 여기에서는 이 계획으로 1148번의 읽기 작업이 수행된 것을 확인할 수 있습니다. 이는 평균적인 사례가 행을 하나만 반환하기 위한 것일 경우 비효율적인 동작입니다.

SQL_DB

예제의 두 번째 부분에서는 쿼리 힌트를 사용해서 최적화 프로그램이 컴파일 프로세스 중 특정 값을 사용하도록 지정합니다. 이 경우에는 쿼리 프로세서가 매개 변수로 전달된 값을 무시하도록 지정하고 대신 해당 값을 "UNKNOWN”으로 가정하도록 지정합니다. 즉 테이블에서 평균적인 빈도를 갖는 값(기울기 무시)이 사용됩니다. 결과 계획은 예제의 1부에서 만든 계획보다 평균적으로 보다 빠르고 보다 적은 수의 리소스를 사용하는 검색 기반 계획입니다.

SQL_DB

이로 인한 결과는 sys.resource_stats 테이블을 조사하여 확인할 수 있습니다(참고: 테스트를 실행하는 시간과 테이블에 데이터가 채워지는 시간 사이에는 지연이 발생할 수 있습니다.) 이 예에서 1부는 22:25:00에 실행되었고 2부는 22:35:00에 실행되었습니다. 계획 효율성 향상으로 인해 이전 시간대에는 이후 시간대보다 해당 시간대에서 더 많은 리소스가 사용되었습니다.

SELECT TOP 1000 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

SQL_DB

Important중요
여기에 사용된 예제는 일부러 작게 만들었지만 대규모 데이터베이스의 경우 비최적 매개 변수로 인한 영향은 상당할 수 있습니다. 극단적인 경우에는 빠른 경우와 느린 경우 사이에 몇 초에서 몇 시간까지 차이가 발생할 수 있습니다.

sys.resource_stats를 조사하여 특정 테스트에 대한 리소스가 다른 테스트에 비해 리소스를 많거나 적게 사용하는지 확인할 수 있습니다. 데이터를 비교할 때는 충분한 시간을 들여서 sys.resource_stats 뷰에서 각 테스트 결과가 5분 간격 내에 포함되지 않도록 테스트를 분리하세요. 또한 이 연습의 목표는 se당 최대 리소스를 최소화하는 것이 아니라 사용되는 전체 리소스를 최소화하기 위한 것이라는 점에 주의해야 합니다. 일반적으로 한 코드 조각의 대기 시간을 최적화하면 리소스 소비도 줄어듭니다. 어떠한 응용 프로그램에서든 고려 중인 변경 사항이 실제로 필요한지 확인하고 쿼리 힌트를 사용할 때는 응용 프로그램을 사용 중인 어떤 사용자의 고객 환경에도 성능 영향을 주지 않는지 확인해야 합니다.

작업 부하에 반복되는 쿼리 집합이 포함된 경우에는 데이터베이스를 호스팅하는 데 필요한 최소 리소스 크기 단위에 영향을 줄 수 있기 때문에 이러한 계획 선택에 대한 최적성을 캡처하고 유효성을 검사하는 것이 합리적인 경우가 많습니다. 유효성이 확인된 다음에는 해당 계획을 때때로 다시 조사하여 성능이 저하되지 않았는지 확인할 수 있습니다. 쿼리 힌트에 대한 자세한 내용은 쿼리 힌트(Transact-SQL)를 참조하십시오.

Azure SQL 데이터베이스는 상용 하드웨어에서 실행되기 때문에 기존의 온-프레미스 SQL Server 설치에 비해 단일 데이터베이스에 대한 용량 제한이 일반적으로 더 낮습니다. 따라서 Azure SQL 데이터베이스에서 단일 데이터베이스의 제한 사항에 맞지 않을 경우 많은 고객들이 분할 기법을 사용하여 여러 데이터베이스로 데이터베이스 작업을 분산하고자 합니다. Azure SQL 데이터베이스에서 현재 분할 기법을 사용하는 많은 고객들은 단일 차원의 데이터를 여러 데이터베이스로 분할합니다. 이러한 방식을 사용하기 위해서는 OLTP 응용 프로그램의 경우 스키마 내에서 한 개의 행 또는 소규모 행 그룹에만 적용되는 트랜잭션이 자주 수행된다는 것을 이해해야 합니다. 예를 들어 데이터베이스에 고객, 주문 및 주문 세부 정보가 포함된 경우(SQL Server에 제공되는 기존 예제 Northwind 데이터베이스 참조), 고객을 관련 주문 및 주문 세부 정보와 그룹화하고 단일 데이터베이스 내에 유지되도록 보장하여 이 데이터를 여러 데이터베이스로 분할할 수 있습니다. 이 응용 프로그램은 데이터베이스 간에 여러 고객을 분할하여 부하를 여러 데이터베이스로 효과적으로 분산시킬 수 있습니다. 이렇게 하면 고객이 최대 데이터베이스 크기 제한을 피할 수 있지만 Azure SQL 데이터베이스에서도 각 개별 데이터베이스가 해당 DTU에 적합하면 다른 성능 수준의 제한보다 훨씬 많은 작업을 처리할 수 있습니다.

데이터베이스 분할이 특정 솔루션의 집계 리소스 용량을 줄여 주지는 않지만 이 기법은 여러 데이터베이스 간에 분산된 매우 큰 솔루션을 지원하는 데 상당히 효율적이며, 다른 성능 수준에서 실행할 각 데이터베이스에서 리소스 요구 사항이 높은 매우 큰 "효율적인" 데이터베이스를 지원할 수 있습니다.

SQL Server 사용자는 단일 데이터베이스 내에 종종 여러 기능을 조합해서 사용합니다. 예를 들어 응용 프로그램에 특정 매장에 대한 재고를 관리하는 논리가 포함된 경우 해당 데이터베이스에는 재고와 관련된 논리, 구매 주문 추적, 저장 프로시저, 월말 보고를 관리하는 인덱싱된/구체화된 뷰 및 기타 기능이 포함될 수 있습니다. 이 기법은 백업과 같은 작업을 위해 데이터베이스를 쉽게 관리할 수 있는 이점이 있지만 이를 위해서는 응용 프로그램의 모든 기능에서 최대 부하를 처리할 수 있도록 하드웨어 크기를 조정해야 합니다.

Azure SQL 데이터베이스 내에 사용되는 확장 아키텍처에서는 응용 프로그램의 여러 기능을 서로 다른 데이터베이스로 분할하는 것이 효과적인 경우가 많습니다. 이렇게 하면 각각의 기능을 독립적으로 확장할 수 있습니다. 이렇게 하면 응용 프로그램이 점점 더 많이 사용될 경우(그리고 데이터베이스에 대한 부하가 점점 더 늘어날 경우) 관리자가 응용 프로그램 내의 각 기능에 대해 독립적으로 성능 수준을 선택할 수 있습니다. 최소한 이 아키텍처에서는 부하를 여러 시스템에 분산함으로써 단일 상용 시스템에서 처리할 수 있는 것보다 훨씬 크게 응용 프로그램을 확장시킬 수 있습니다.

자주 수행되는 임시 쿼리 방식으로 데이터에 액세스하는 응용 프로그램의 경우 응용 프로그램 계층과 Azure SQL 데이터베이스 계층 사이의 네트워크 통신에 대량의 응답 시간이 소비됩니다. 응용 프로그램과 Azure SQL 데이터베이스가 모두 동일한 데이터 센터에 있더라도 데이터 액세스 작업 수가 많으면 둘 사이의 네트워크 대기 시간이 늘어날 수 있습니다. 이러한 데이터 액세스 작업의 네트워크 왕복을 줄이기 위해서는 응용 프로그램 개발자가 임시 쿼리를 일괄 처리로 묶거나 이를 저장 프로시저로 컴파일하는 등의 옵션을 고려해야 합니다. 임시 쿼리를 일괄 처리로 묶으면 여러 쿼리를 하나의 큰 일괄 처리로 묶어서 Azure SQL 데이터베이스에 단일 작업으로 전송할 수 있습니다. 임시 쿼리를 저장 프로시저로 컴파일하면 일괄 처리와 동일한 결과를 얻을 수 있습니다. 저장 프로시저를 사용하면 나중에 동일한 저장 프로시저를 실행할 수 있도록 Azure SQL 데이터베이스에서 쿼리 계획을 캐싱할 수 있는 이점이 있습니다.

일부 응용 프로그램에는 쓰기 작업이 많이 수행됩니다. 일부 경우에는 쓰기를 일괄 처리로 묶어서 데이터베이스에 대한 전체 IO 부하를 줄일 수 있습니다. 이러한 방식은 저장 프로시저 및 임시 일괄 처리 내에서 트랜잭션을 자동 커밋하는 대신 명시적 트랜잭션을 사용하는 것만큼 간단합니다. 사용할 수 있는 여러 기법들에 대한 자세한 내용은 Azure에서 SQL 데이터베이스 응용 프로그램에 대한 일괄 처리 기법을 참조하십시오. 사용자 고유의 작업 부하를 사용해서 각 기법을 실험하여 일괄 처리에 적합한 모델을 찾고, 특정 모델마다 트랜잭션 일관성 보증이 조금씩 다르다는 것을 이해해야 합니다. 리소스 사용을 최소화하는 올바른 작업 부하를 찾기 위해서는 일관성과 성능 사이의 올바른 균형점을 찾아야 합니다.

일부 데이터베이스 응용 프로그램에는 읽기에 집중된 작업 부하가 포함됩니다. 캐싱 계층을 사용하면 데이터베이스에 대한 부하를 줄이고 Azure SQL 데이터베이스를 사용하는 데이터베이스를 지원하는 데 필요한 성능 수준을 줄일 수 있습니다. Azure 캐싱(캐싱)을 사용하면 읽기 작업이 많은 고객이 데이터 읽기를 한 번(또는 시스템 구성 방법에 따라 응용 프로그램 계층 시스템 당 한 번)만 수행하고 이 데이터를 Azure SQL 데이터베이스 외부에 저장할 수 있습니다. 이 방법은 데이터베이스 부하(CPU 및 읽기 IO)를 줄일 수 있지만 캐시에서 읽어오는 데이터가 데이터베이스에 있는 데이터와 달라질 수 있으므로 트랜잭션 일관성에 영향을 줄 수 있습니다. 비일관성이 어느 정도까지는 수락되는 응용 프로그램도 많이 있기 때문에 이러한 비일관성 문제가 모든 작업 부하에 해당되는 것은 아닙니다. 응용 프로그램 계층 캐싱 전략을 사용하기 위해서는 먼저 모든 응용 프로그램의 요구 사항을 완전히 이해해야 합니다.

Azure SQL 데이터베이스의 서비스 계층을 사용하면 클라우드에서 구축하는 응용 프로그램 유형을 더 늘릴 수 있습니다. 효과적인 응용 프로그램 튜닝과 함께 사용될 경우 응용 프로그램에 강력하고 예측 가능한 성능을 제공할 수 있습니다. 이 문서에서는 성능 수준 중 하나에 맞도록 데이터베이스의 리소스 사용을 최적화하는 몇 가지 권장 기법에 대해 설명합니다. 튜닝은 클라우드 모델에서도 지속적으로 사용되고 있는 기법이며, 서비스 계층과 해당 성능 수준을 통해 관리자는 Microsoft Azure 플랫폼에 대한 비용을 최소화하면서 성능을 극대화할 수 있습니다.

참고 항목

이 정보가 도움이 되었습니까?
(1500자 남음)
의견을 주셔서 감사합니다.
표시:
© 2014 Microsoft