Data Science Lab

Azure SQL에서 선택할 수 있는 다양한 배포 옵션

·       Version : Azure SQL

Microsoft Azure SQL은 다양한 배포 옵션을 제공한다. 리프트 앤 시프트 마이그레이션에서 기존 애플리케이션 현대화, 최신 클라우드 서비스 구축에 이르기 까지 Microsoft SQL Server 엔진으로 구동되는 여러 배포 옵션을 제공한다. Azure SQL은 단일 통합 관리 환경을 제공하여 다양한 SQL Server 기반 응용 프로그램 모음을 대규모로 관리하는 복잡성을 제거한다. 배포에 옵션에 관한 자세한 내용은 아래 링크를 참고 한다.

·       (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-paas-vs-sql-server-iaas?WT.mc_id=DP-MVP-4039834

·       (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-paas-vs-sql-server-iaas?WT.mc_id=DP-MVP-4039834

Microsoft의 데이터 플랫폼은 SQL Server 기술을 활용하며 물리적 온-프레미스 컴퓨터, 사설 클라우드 환경, 타사 호스팅 사설 클라우드 환경 및 공용 클라우드에 걸쳐 사용할 수 있도록 한다. Azure virtual machine ( SQL virtual machines)에 대한 SQL Server를 사용하면 동일한 서버 제품, 개발 도구 및 전문 지식 집합을 사용하는 동시에 온-프레미스 및 클라우드 호스팅 배포를 조합하여 고유하고 다양한 비즈니스 요구사항을 충족할 수 있다. 아래 그림에 표시된 것처럼 각 제품은 인프라를 통해 보유하고 있는 관리 수준 및 비용 효울성을 기준으로 지정할 수 있다.

[SQL Database ]

안정적인 최신 SQL Server 기능을 사용하고 개발 및 마케팅에 시간 제한이 있는 최신 클라우드 응용 프로그램에 가장 적합하다. 안정적인 최신 SQL Server Enterprise Edition을 기준으로 하는 완전 관리형 SQL 데이터베이스 엔진은PaaS(Platform as a Service) 범주로 분류되며, Azure 클라우드에서 호스트되는 관계형 DBaaS(Database as a Service)이다. SQL 데이터베이스는 여러 배포 옵션을 제공하며, 각 배포 옵션은 Microsoft에서 소유하고 호스트하고 유지 관리하는 표준화된 하드웨어 및 소프트웨어를 기반으로 한다. SQL Server를 사용하면 광범위한 구성 (온-프레미스 또는 Azure 가상 컴퓨터)을 필요로 하는 기본 제공기능 및 기능을 사용할 수 있다. SQL Database를 사용할 경우 추가 성능에 맞게 중단 없이 강화 및 확장하는 옵션을 통해 사용량에 따라 지불한다. SQL Database에는 기본 제공 고가용성, 인텔리전스 및 관리와 같이 SQL Server에서 사용할 수 없는 몇 가지 추가 기능이 있다.

·       데이터베이스 서버를 통해 관리되는 자체 리소스 집합이 포함 된 단일 데이터베이스는 SQL Server의 포함 된 데이터베이스와 비슷하다. 이 옵션은 새로운 클라우드 기반 애플리케이션의 최신 애플리케이션 개발에 맞게 최적화되어 있다. Hyperscale 및 서버 리스 옵션을 사용할 수 있다.

·       데이터베이스 서버를 통해 관리 되는 리소스의 공유 집합이 있는 데이터베이스를 Elastic Pool로 이동하거나 Elastic Pool에서 제거할 수 있다. 이 옵션은 다중 테넌트 SaaS 응용 프로그램 패턴을 사용하여 새로운 클라우드를 사용 하는 응용 프로그램의 최신 응용 프로그램 개발에 최적화 되어 있다. Elastic Pool은 변수 사용 패턴이 있는 여러 데이터베이스의 성능을 관리 하는 비용 효율적인 솔루션을 제공한다.

·       단일 데이터베이스 및 Elastic Pool의 그룹을 관리하는 데 사용되는 데이터베이스 서버입니다. 데이터베이스 서버는 여러 단일 데이터베이스 또는 풀링된 데이터베이스, 로그인, 방화벽 규칙, 감사 규칙, 위협 검색 정책및 장애조치 (failover) 그룹에 대한 중앙 관리 지점 역할을 한다.

[SQL Managed Instance]

클라우드로의 대부분 마이그레이션에 적합 하다.Managed Instance는 리프트 앤 시프트 준비가 된 리소스의 공유 집합을 사용하는 시스템 및 사용자 데이터베이스의 컬렉션이다. 안정적인 최신 SQL Server 기능을 사용하고 최소한의 변경으로 클라우드로 마이그레이션되는 새 응용 프로그램 또는 기존 온-프레미스 응용 프로그램에 가장 적합하다. Managed Instance는 데이터베이스의 공유 리소스 및 추가 인스턴스 범위 기능을 제공 하는 Microsoft SQL Server 데이터베이스 엔진의 인스턴스와 비슷하다. Managed Instance는 데이터베이스 변경없이 또는 최소한의 변경으로 온-프레미스에서 데이터베이스를 마이그레이션할 수 있도록 지원한다. 이 옵션은 Azure SQL Database의 모든 PaaS 혜택을 제공하지만 이전에 SQL VM에서만 사용할 수 있었던 기능을 추가한다. 여기에는 기본 가상 네트워크(VNet) 및 온-프레미스 SQL Server와의 거의 100% 호환성이 포함된다. Managed Instance는 SQL Server를 Azure로 마이그레이션하기 위한 전체 SQL Server 액세스 및 기능 호환성을 제공한다.

[SQL virtual machines]

OS 수준 액세스를 필요로 하는 마이그레이션 및 응용 프로그램에 가장 적합하다. SQL 가상 머신은 변경 내용을 최소화 하거나 변경 하지 않고 클라우드로 신속하게 마이그레이션해야 하는 기존 응용 프로그램에 대해 리프트 앤 시프트가 준비된다. SQL 가상 머신은 Azure로의 마이그레이션을 위해 SQL Server 인스턴스 및 기본 OS에 대 한 모든 관리 권한을 제공한다. SQL 가상 머신은 IaaS (Infrastructure as a Service )에 포함 되며, Azure 클라우드의 완전히 관리 되는 VM (가상 머신) 내에서 SQL Server를 실행할 수 있다. SQL 가상 머신은 Microsoft에서 소유하고 호스트 하며 유지관리하는 표준화된 하드웨어에서도 실행된다. SQL 가상 컴퓨터를 사용하는경우 이미 SQL Server 이미지에 포함 된 SQL Server 라이선스를 지불하거나 기존 라이선스를 쉽게 사용할 수 있다. 필요에 따라 VM을 중지하거나 다시 시작할 수도 있다. 클라우드에 설치 되 고 호스트 되는 SQL Server는 Azure에서 실행 되는 Windows Server 또는 Linux 가상 컴퓨터 (IaaS (infrastructure as a service) 라고도 함)에서 실행된다. SQL 가상 머신은 데이터베이스를 변경 하지않고 온-프레미스 SQL Server 데이터베이스 및 응용 프로그램을 마이그레이션하는데 적합한 옵션이다. 모든 최신 버전의 SQL Server를 IaaS 가상 머신에 설치할 수 있다. SQL database와 SQL Managed Instance의 가장 중요한 차이점은 SQL Server VM이 데이터베이스 엔진에 대한 모든 권한을 허용 한다는 것이다. 유지 관리/패치를 시작할 시기를 선택하고, 복구 모델을 단순 또는 대량 로그로 변경하거나, 필요에 따라 서비스를 일시 중지 하거나 시작 하 고, SQL Server 데이터베이스 엔진을 완벽하게 사용자 지정할 수 있다. 이 추가 컨트롤을 사용 하면 가상 머신을 관리하는 추가 책임이 있다.

Azure Portal에서는 SQL 가상 머신을 비롯 한 모든 Azure SQL 리소스 를 관리할 수 있는 단일 페이지를 제공 한다. Azure SQL 리소스 페이지에 액세스 하려면 Azure Portal의 왼쪽 메뉴에서 Azure SQL을 선택한. Azure SQL이 목록에 없는 경우 모든 서비스를 선택한 다음 검색 상자에 Azure SQL 을 입력 합니다.기존 리소스를 관리 하려면 목록에서 원하는 항목을 선택한다. 새 Azure SQL 리소스를 만들려면 [+ Add]를 선택한다.

[+ Add]를 선택한 후 여러 옵션에 대한 추가 정보를 확인할 수 있다.

[참고자료]

·       (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-paas-vs-sql-server-iaas?WT.mc_id=DP-MVP-4039834

·       (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-paas-vs-sql-server-iaas?WT.mc_id=DP-MVP-4039834

2019-10-10 / Sungwook Kang / http://sungwookkang.com/

Azure SQL, Managed Instance, Azure SQL Database, Azure Virtual Machine

Azure SQL Database의 vCore 모델과 DTU 모델에서 마이그레이션

l  Version : Azure SQL

Azure SQL Database에서 vCore(가상코어) 구매 모델은 컴퓨팅 및 스토리지 리소스를 독립적으로 확장하고 온-프레미스 성능을 조정하며 가격을 최적화할 수 있다. 또한 하드웨어 세대(Generation)을 선택할 수 있다. 하드웨어 세대는 시간 및 지역에 따라 지원되는 세대가 다르므로, 항상 Microsoft의 공식 문서를 참고할 수 있도록 한다.

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-vcore/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-service-tiers-vcore/?WT.mc_id=DP-MVP-4039834

vCore 기반 구매 모델은 범용, 중요 비스니스, 하이퍼 규모의 세 계층을 제공한다. 이러한 서비스 계층은 다양한 계산 크기, 고가용성 디자인, 내결함성 방법, 저장소의 형식 및 크기, I/O 범위로 구분된다. 백업에 필요한 스토리지와 보존 기간을 개별적으로 구성해야 한다. 백업 보존 기간을 설정하려면 Azure Portal에서 백업 관리에서 할 수 있다.  아래 표는 세 계층 간의 차이점을 설명한다.

vCore 기반 구매 모델의 프로비전 된 계산 계층에서는 SQL Server에 대한 Azure 하이브리드 혜택을 사용하여 SQL Database에 대한 할인된 요금으로 기존 라이선스를 교환할 수 있다. 이 Azure 혜택을 통해 소프트웨어 보증이 있는 온-프레미스 SQL Server 라이선스를 사용하여 Azure SQL Database 최대 30%까지 절약할 수 있다.

Azure 하이브리드 혜택을 사용하면 SQL database 엔진 자체 (기본 계산 가격 책정)에 기존 SQL Server 라이선스를 사용하여 기본 Azure 인프라에 대해서만 비용을 지불하도록 선택하거나 기본 인프라와 SQL Server에 대해 비용을 지불할 수 있다.

DTU 기반 모델에서 vCore 기반 구매 모델로 마이그레이션하는 것은 standard 및 premium 서비스 계층에 있는 데이터베이스 간의 지역에서 복제 관계를 업그레이드하거나 다운그레이드 하는 것과 비슷하다. 마이그레이션 중에 지역에서 복제를 중지할 필요는 없지만 아래 규칙을 따라야 한다.

l  업그레이드하는 경우 보조 데이터베이스를 먼저 업그레이드한 다음, 주 데이터베이스를 업그레이드해야 한다.

l  다운그레이드하는 경우 반대 순서로 주 데이터베이스를 먼저 다운그레이드한 다음, 보조 데이터베이스를 다운그레이드 해야 한다.

l  Elastic Pool 복제를 사용하는 경우 하나의 풀을 기본 풀로 지정하고 다른 풀을 보조 데이터베이스로 지정하는 것이 좋다. 이 경우 Elastic Pool을 마이그레이션하는 경우 동일한 순서의 지침을 사용해야 한다.

l  주 데이터베이스와 보조 데이터베이스를 모두 포함하는 Elastic Pool을 사용하는 경우 사용률이 높은 풀을 주 데이터베이스로 처리하고 그에 따라 시퀀싱 규칙을 따른다.

아래 표는 특정 마이그레이션 시나리오에 대한 지침을 제공한다.

여러 데이터베이스가 있는 장애 조치 그룹을 마이그레이션하려면 주 데이터베이스와 보조 데이터베이스를 개별적으로 마이그레이션해야 한다. 이 과정에서 동일한 고려사항과 순서지정 규칙이 적용된다. 데이터베이스를 vCore 기반 구매 모델로 변환한 후에는 장애 조치 (failover) 그룹이 동일한 정책 설정에 계속 적용된다.

주 데이터베이스에 사용한 것과 동일한 서비스 계층을 사용하여 지역에서 복제 보조 데이터베이스 (지역 보조 데이터베이스)를 만들 수 있다. 로그 생성 비율이 높은 데이터베이스의 경우 주 데이터베이스와 동일한 계산 크기로 지역 보조 데이터베이스를 만드는 것이 좋다.

단일 주 데이터베이스에 대한 Elastic Pool에서 지역 보조 데이터베이스를 만드는 경우 풀에 대 한 maxVCore 설정이 주 데이터베이스의 계산 크기와 일치하는지 확인한다. 다른 Elastic Pool에서 주 데이터베이스에 대 한 지역 보조 데이터베이스를 만드는 경우 풀에 동일한 @no__t 0 설정을 갖는 것이 좋다.

[참고자료]

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-vcore/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-service-tiers-vcore/?WT.mc_id=DP-MVP-4039834

2019-10-09 / Sungwook Kang / http://sungwookkang.com/

Azure SQL, Managed Instance, Azure vCore

Azure SQL Database의 서비스 계층에 따른 DTU 구매 모델

l  Version : Azure SQL

이전 포스트에서 Azure SQL Database 의 전반적인 내용에 대해서 살펴 보았다. Azure SQL의 Overview에 대해서 자세히 알고 싶으면 아래 링크를 참고한다.

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-technical-overview/?WT.mc_id=DP-MVP-4039834

Azure SQL Database의 구매 모델에는 vCore 기반, DTU 기반, 서버리스 등 몇 가지 모델이 있지만 이번 포스트에서는 DTU 기반 구매 모델에 대해서 살펴본다. DTU 기반 구매 모델에 대한 자세한 정보는 아래 링크를 통해서 확인할 수 있다.

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-dtu/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-service-tiers-dtu/?WT.mc_id=DP-MVP-4039834

DTU 기반 구매 모델에서 서비스 계층은 포함된 스토리지의 고정된 양, 고정된 백업 보존 기간 및 고정 가격을 갖춘 다양한 컴퓨팅 크기로 구분된다. DTU 기반 구매 모델의 모든 서비스 계층은 가동 중지 시간을 최소화하면서 계산 크기를 유연하게 변경할 수 있다. Single Database 및 Elastic Pool은 서비스 계층 및 컴퓨팅 크기에 따라 시간 단위로 청구된다. 단, Managed Instance는 DTU 구매 모델을 지원하지 않는다.

서비스 계층을 선택하는 방법은 비즈니스의 연속성, 스토리지 및 성능 요구사항에 따라 다르다. 아래 표는 서비스 계층에 따른 특징을 간략히 표로 정리한 것이다.

컴퓨팅 크기는 단일 데이터베이스에 대해서는 DTU(데이터베이스 트랜잭션 단위), Elastic Pool에 대해서는 eDTU(Elastic 데이터베이스 트랜잭션 단위)로 표현된다. DTU 및 eDTU에 대한 내용은 아래 링크에서 자세히 확인할 수 있다.

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-purchase-models#dtu-based-purchasing-model/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-purchase-models#dtu-based-purchasing-model/?WT.mc_id=DP-MVP-4039834

아래 표는 Single Database 대한 최대 스토리지 및 DUT 크기를 나타낸다.

아래 표는 Elastic Pool의 최대 스토리지 및 eDTU 크기를 나타낸다.

[참고자료]

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-dtu/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-service-tiers-dtu/?WT.mc_id=DP-MVP-4039834

2019-10-09 / Sungwook Kang / http://sungwookkang.com/

Azure SQL, Managed Instance, Azure DTU

Azure SQL Database 서비스

·       Version : Azure SQL

Azure SQL Database는 관리 서비스로 제공되는 범용 관계형 데이터베이스 이며, Azure Portal에서 응용 프로그램 및 솔루션에 대한 고가용성 및 고성능 데이터 저장소 계층을 만들 수 있다. 데이터 또한graph, JSON, spatial(공간), XML등 관계형 데이터와 비관계형 구조 모두 처리할 수있다. Azure SQL Database는 Microsoft SQL Server 데이터베이스 엔진을 기반으로 하며, high-performance In-Memory Optimize 기능및 지능형 쿼리 같은 고급 처리 기술을 사용할 수 있다. 실제 Microsoft에서는 최신 기능은  Azure SQL Database로 출시한 다음 SQL Server로 출시한다.

Azure SQL Database에 대한 자세한 내용은 아래 링크를 참고 한다.

·       What is the Azure SQL Database service? : https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview/?WT.mc_id=DP-MVP-4039834

SQL Database를 사용하면 vCore 기반 구매 모델 및 DTU 기반 구매 모델이라는 두 가지 구매 모델 내에서 성능을 쉽게 정의하고 확장할 수 있다. (vCore 및 DTU에 대한 내용은 다른 포스트에서 자세히 다루도록 한다.) SQL Database는 고가용성, 백업 및 기타 일반적인 유지 관리 작업을 기본 제공하는 완전히 관리되는 서비스이다. Microsoft는 SQL 및 운영체제 코드의 모든 패치 및 업데이트를 처리한다. 사용자는 기본 인프라를 관리할 필요가 없다.

[Deployment models]

Azure SQL Database는 Azure SQL 데이터베이스에 다음과 같은 옵션을 제공한다.

·       Single Database는 완전히 관리되는 격리된 데이터베이스를 나타낸다. 안정적인 단일 데이터 원본이 필요한 경우 최신 클라우드 응용프로그램 및 마이크로 서비스를 사용하는 경우 이 옵션을 사용할 수 있다. 단일 데이터베이스는 Microsoft SQL Server 데이터베이스 엔진의 포함된 데이터베이스와 비슷하다.

·       Managed instance는 Microsoft SQL Server 데이터베이스 엔진의 완전히 관리되는 인스턴스이다. 함께 사용할 수 있는 데이터베이스 집합이 포함되어 있다. 온-프레미스 SQL Server 데이터베이스를 Azure 클라우드로 쉽게 마이그레이션할 수 있으며, 데이터베이스 엔서 제공하는 SQL Server 데이터베이스 기능을 사용해야하는 경우 이 옵션을 선택한다.

·       Elastic Pool은 CPU, 메모리등의 공유 리소스 집합을 포함하는 단일 데이터베이스 컬렉션이다. 단일 데이터베이스를 Elastic Pool로 이동하거나 Elastic Pool에서 제거할 수 있다.

[Scalable performance and pools]

할당된 리소스의 양을 정의할 수 있다.

·       Single Database를 사용하는 경우 각 데이터베이스는 다른 데이터베이스와 격리 되며 이식 가능하다. 각 데이터베이스에는 자체 보장된 컴퓨팅, 메모리 및 스토리지 리소스가 있다.  데이터베이스에 할당된 리소스양은 해당 데이터베이스 전용이며 Azure의 다른 데이터베이스와 공유되지 않는다. 단일 데이터베이스 리소스를 동적으로 확장 및 축소 할 수 있다. 또한 hyperscale service tier를 사용하면 빠른 백업 및 복원기능을 통해 100TB 까지 확장할 수 있다.

·       Elastic Pool을 사용하면 풀에 있는 모든 데이터베이스에서 공유하는 리소스를 할당할 수 있다. 새 데이터베이스를 만들거나 기존 단일 데이터베이스를 리소스 풀로 이동하여 리소스 사용을 최대화 하고 비용을 절감할 수 있다. 또한 이 옵션을 사용하면 Elastic Pool 리소스를 동적으로 확장 및 축소할 수 있다.

·       Managed Instance를 사용할 경우 각각의 관리되는 인스턴스가 다른 인스턴스에서 격리되고 리소스가 보장된다. Managed Instance 내에서 데이터베이스 인스턴스는 리소스 집합을 공유한다. Managed Instance는 리소스를 동적으로 확장 및 축소할 수 있다.

동적확장성과 자동 크기 조정은 의미가 조금 다르다. 자동 크기 조정은 서비스가 조건에 따라 자동으로 크기를 조정하는 경인 반면, 동적 확장성은 가동 중지 시간 없이 수동 크기 조정을 허용한다. Single Database 옵션은 수동 동적확장성을 지원하지만 자동 크기 조정 기능은 지원하지 않는다. 더 많은 자동 환경을 위해 데이터베이스에서 개별 요구 사항에 따라 풀의 리소스를 공유할 수 있도록 하는 Elastic Pool을 사용하는 것이 좋다.

[Purchasing models]

SQL Database는 다음과 같은 구매 모델을 제공한다.

·       vCore 기반 구매 모델 : vCore 수, 메모리 양, 스토리지 양 및 속도를 선택할 수 있다. vCore 기반 구매 모델을 사용하면 SQL Server 용 Azure 하이브리드 혜택을 사용하여 비용을 절감 할 수 있다.

·       DTU 기반 구매 모델 : DTU 기반 구매 모델은 3 가지 서비스 계층에 컴퓨팅, 메모리 및 I / O 리소스를 혼합하여 다양한 워크로드를 지원합니다. 각 계층 내의 컴퓨팅 크기는 이러한 리소스를 다르게 혼합하여 추가 스토리지 리소스를 추가 할 수 있다.

·       서버리스 모델은 워크로드 요구를 기반으로 계산을 자동으로 조정하고 초당 사용 된 계산량을 청구한다. 또한 서버리스 컴퓨팅 계층은 스토리지만 청구될 때 비활성 기간 동안 데이터베이스를 자동으로 일시 중지하고 활동이 반환되면 데이터베이스를 자동으로 다시 시작한다.

 [Elastic pools to maximize resource utilization]

사용 패턴이 비교적 예측 가능한 경우 많은 비즈니스 및 애플리케이션에서 단일 데이터베이스를 만들고 필요에 따라 충분히 성능을 확정하거나 축소할 수 있다. 예측할 수 없는 경우 비즈니스 모델을 관리하기 어려운데 Elastic Pool은 이 문제를 해결하도록 설계되어 있다. 개별 데이터베이스 대신 풀에 성능 리소스를 할당한다. 단일 테이터베이스 성능이 아닌 풀의 집합적 성능 리소스에 대해 비용을 지불한다.

Elastic Pool을 사용하면 리소스에 대한 요구가 변동함에 따라 데이터베이스 성능을 높이거나 낮추는데 집중할 필요가 없다. 풀링된 데이터베이스는 필요에 따라 탄력적 풀의 성능 리소스를 사용한다. 풀링된 데이터베이스는 풀의 한도를 사용하지만 초과하지 않으므로 개별 데이터베이스 사용량을 예측할 수 없는 경우에도 비용을 계속 예측할 수 있다.

[Extensive monitoring and alerting capabilities]

Azure SQL Database는 고급 모니터링 및 문제 해결 기능을 제공한다. 최신 버전의 SQL Server 데이터베이스 엔진에서 제공하는 기본 모니터링 뿐만 아니라 Azure에서 제공되는 PassS 모니터링 기능을 통해 수 많은 데이터베이스 인스턴스를 모니터링하고 문제를 해결 할 수 있다.

·       Azure  Storage : 적은 비용으로 방대한 양의 원격 분석을 보관

·       Azure Event Hubs : SQL Database 원격 분석을 사용자 지정 모니터링 솔루션 또는 핫 파이프 라인과 통합한다.

·       Azure Monitor logs : 보고, 경고 및 완화 기능이있는 기본 제공 모니터링 솔루션.

[Availability capabilities]

Azure 가용 영역은 단일 지역 내 단일 데이터 센터 건물의 중단을 방지하려고한다. 건물의 전력 또는 네트워크 손실을 방지한다. SQL Database에서는 서로 다른 가용 영역 (다른 건물, 효과적으로)에 서로 다른 복제본을 배치한다. SQL Database는 기본 제공 비즈니스 영속성 및 글로벌 확장성 기능을 제공한다.

·       Automatic backups : SQL Database는 SQL 데이터베이스의 전체, 차등 및 트랜잭션 로그 백업을 자동으로 수행하여 특정 시점으로 복원할 수 있도록 한다. 단일 데이터베이스 및 풀링된 데이터베이스의 경우 장기 백업 보존을 위해 Azure Storage에 전체 데이터베이스 백업을 저장하도록 SQL Database를 구성할 수 있다. Managed Instance의 경우 장기 백업 보존을 위해 복사 전용 백업도 수행할 수 있다.

·       Point-in-time restores : 모든 SQL Database 배포 옵션은 SQL 데이터베이스에 대해 자동 백업 보존기간내의 특정 시점으로 복구를 지원한다.

·       Active get-replication : 단일 데이터베이스 및 풀링된 데이터베이스 옵션을 사용하여 동일하거나 전 세계적으로 분산된 Azure 데이터센터에서 최대 4개의 읽기 가능한 보조 데이터베이스를 구성할 수 있다.

·       Auto-failover groups : 모든 SQL Database 배포 옵션을 사용하면 장애 조치 그룹을 사용하여 글로벌 규모로 고가용성 및 부하 분산을 사용하도록 설정할 수 있다. 여기에는 데이터베이스, Elastic Pool 및 Managed Instance의 지역 복제 및 장애조치가 포함된다.

·       Zone-redundant database :  SQL Database를 사용하면 여러 가용 영역에 걸쳐 프리미엄 또는 비즈니스 크리티컬 데이터베이스 또는 Elastic Pool을 프로비저닝 할 수 있다. 이러한 데이터베이스와 Elastic Pool에는 고 가용성을위한 중복 복제본이 여러 개 있으므로 이러한 복제본을 여러 가용 영역에 배치하면 복원력이 향상된다. 여기에는 데이터 손실없이 데이터 센터 스케일 오류에서 자동으로 복구하는 기능이 포함된다.

[참고자료]

·       What is the Azure SQL Database service? : https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview/?WT.mc_id=DP-MVP-4039834

2019-10-09 / Sungwook Kang / http://sungwookkang.com

Azure SQL, Managed Instance, Azure overview

SQL Server 2019 temp table을 사용한 워크로드에서 recompile 감소

·       Version : SQL Server 2019

SQL Server 2019에는 응용프로그램 코드에 필요한 변경을 최소화 하면서 성능을 향상시키는 몇 가지 성능 최적화가 도입 되었다. 이번 포스트에서는 SQL Server 2019 성능 개선 사항 중 하나인 temp 테이블을 사용한 작업 부하에 대해 리컴파일 감소로 인한 성능 향상을 설명한다.

·       Intelligent query processing in SQL databases : https://docs.microsoft.com/en-us/sql/relational-databases/performance/intelligent-query-processing?view=sql-server-2017

이 개선 사항을 이해하기 위해 먼저 SQL Server 2017 및 그 이전의 동작을 살펴본다. DML 문 (SELECT, INSERT, UPDATE, DELETE)을 사용하여 임시 테이블을 참조할 때 임시 테이블이 외부 범위 배치에 의해 생성된 경우에는 실행 될 때 마다 DML 문을 다시 컴파일 힌다.

아래 스크립트는 실습를 사용하여 재현할 수 있다. OuterProc 프로시저에서는 아래와 같은 기능을 한다.

1. 임시테이블 만들기

2. InnerProc 저장 프로시저 호출

InnerProc 저장 프로시저의 경우 OuterProc에서 생성된 임시 테이블을 참조하는 두 개의 DML 문이 있다.

3. 임시 테이블에 행을 삽입

4. 임시 테이블에서 행을 리턴

우리는 임시 테이블을 DML문과 다른 범위로 만들었으며 기존 구현(SQL Server 2019 이전)에 대해 이 임시 테이블 스키마가 실질적으로 변경되지 않음을 “신뢰”하지 않으므로 실행될 때마다 연관된 DML문이 추가 리컴파일 활동을 하여 CPU 사용률을 높이고 전체 워크로드 성능 및 처리량을 줄여 성능 저하로 이어질 수 있다.

SQL Server 2019 부터는 불필요한 리컴파일을 피하기 위해 추가 검사를 수행한다.

·       컴파일 타임에 임시 테이블을 생성하는데 사용된 외부 범위 모듈이 연속 실행에 사용된 것과 동일한지 확인한다.

·       초기 컴파일시 변경 한 DDL (Data Definition Language) 변경 사항을 추적하고 이를 연속 시행을 위한 DDL작업과 비교한다.

결과적으로 보증하지 않은 리컴파일 및 관련  CPU 오버헤드가 줄어든다.

아래 그림은 각 “OuterProc“ 저장 프로시저를 1,000번 (in a loop) 실행하는 16개의 동시 스레드의 테스트 결과를 보여준다. Y축은 발생횟수를 나타내며 파란색 선은 Batch Requests/sec 를 나타내고 녹색 선은 SQL Re-Compilations/sec를 나타낸다.

이 예제에서 기능이 활성화 되면 다음과 같은 결과가 나타난다.

·       Batch Requests/sec (파란색 선, 두 번째 혹)로 표시되는 처리량 개선

·       전체 작업 시간 단축

·       SQL Re-Compilations/sec (녹색선)로 표시되는 리컴파일 감소. (두 번째 테스트 시작시 약간의 증가가 발생하였음)

이 기능은 모든 데이터베이스 호환성 수준에서 SQL Server 2019에서 기본적으로 사용된다. 이 글을 쓰는 시점에서 이 기능은 데이터베이스 호환성 수준 150에서 Azure SQL Database에서도 사용할 수 있지만, 향후 다른 호환성 수준에서도 적용될 수 있다.

2019-09-24/ Sungwook Kang / http://sungwookkang.com

Azure SQL, SQL Server 2019, temp table, SQL Re-compilations, Batch Requests, Intelligent query processing in SQL databases

Azure SQL Managed Instance 및 SQL Server 2016 Later에서 대기 통계 분석

·       Version : Azure SQL, SQL Server 2016 Later

대기 통계(Wait Statistics)는데이터베이스 엔진에서 무언가를 기다리는 쿼리를 식별하는데 도움이 되며 쿼리 지속시간이 긴 이유를 분석할 수 있는 정보를 나타낸다. 이번 포스트에서는 워크로드가 대기하는 이유와 일부 리소스에서 대기중인 쿼리를 식별하는 방법에 대해서 살펴본다.

Azure SQL Managed Instance를 사용하면 아래 DMV를 사용하여 쿼리가 리소스를 대기하는 이유를 찾을 수 있다.

·       sys.dm_os_wait_stats : 인스턴스 레벨에서  대기 정보 반환

·       sys.query_store_wait_stats : 데이터베이스 레벨에서 대기중인 쿼리의 실행계획 반환

이러한 정보는 DMO/Query Store를 사용하여 찾을 수 있다. 그러나 분석을 쉽게 하기 위해 무료 오픈소스인 QPI 라이브러리를 사용할 수 있다.

·       QPI  : https://github.com/JocaPC/qpi

QPI 라이브러리를 설치하려면 아래 링크에서 SQL Server 버전에 대한 SQL 스크립트를 다운로드 할 수 있다. Query Store에 의존하기 때문에 SQL Server 2016 이상, Azure SQL 에서 가능하다.

·       QPI Installation : https://github.com/JocaPC/qpi#installation

sys.dm_os_wait_stats 는 인스턴스 시작 이후 또는 통계를 마지막으로 재설정 한 이후에 대기 통계를 수집하므로 대기 통계의 스냅샷을 작성하거나 최소한 재설정을 해야한다. 아래 스크립트를 실행하여 QPI에서대기 통계를 재설정 할 수 있다.

이 절차는 인스턴스의 대기 통계를 재설정하고 관리형 인스턴스는 새 대기 통계를 수집을  시작한다. 워크로드가 실행되는 동안 qpi.wait_stats보기에서 대기 통계 정보를 읽을 수 있다. 결과를 보면 인스턴스의 기본 대기 통계는 INSTANCE_LOG_RATE_GOVERNON이며 Log Rate Governor로 분류 된다. 대기 유형의 영향을 받는 쿼리를 찾으려면 실제 대기 유형 이름이 아닌 쿼리 저정소에서 Category를 사용해야 하므로 Category가 중요하다. 쿼리 저장소의 대기 통계는 대기 유형별로 기록되지 않는다.

대기가 발생한 Category의 영향을 받는 상위 쿼리를 보려면 qpi.db_query_wait_stats 보기를 사용하여 Category에 해당하는 대기 통계를 필터링 할 수 있다.

예제의 경우 관리형 인스턴스에서 로그 속도 제한에 도달하고 있으며, 원인은 인덱스 재구축으로 인한것일 수 있다. 데이터베이스가 여러개인 경우 데이터베이스마다 쿼리 저장소가 구성되므로 각 데이터베이스에서 이 쿼리를 실행해야한다.

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2019/03/05/analyzing-wait-statistics-on-managed-instance/

2019-09-23/ Sungwook Kang / http://sungwookkang.com

Azure SQL, SQL Server Managed Instance, Query Store, QPI, sys.dm_os_wait_stats, sys.query_store_wait_stats

QPI(Query Performance Insights) 라이브러리를 사용하여 Azure SQL Managed Instance의 로그쓰기 사용량 확인

·       Version : Azure SQL

Azure SQL Managed Instance는 Azure 클라우드에서 호스팅되는 완전히 관리되는 SQL Server 인스턴스이다. 관리형 인스턴스에는 최대 로그쓰기 처리량 성능에 일부 제한이 있어 워크로드 속도가 느려질 수 있다. 이번 포스트에서는 관리형 인스턴스에서 쓰기 로그 처리량 문제를 식별하는 방법에 대해서 살펴본다.

Azure SQL Managed Instance에는 최대 로그 쓰기 속도와 같은 몇 가지 기본 제공 리소스 제한이 있다. 로그 쓰기 제한을 도입한 이유는 로그 백업이 들어오는 데이터를 포착할 수 있어야 하기 때문이다.

·       Overview Azure SQL Database managed instance resource limits : https://docs.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-resource-limits#service-tier-characteristics

이번 포스트에서는 QPI 라이브러리를 사용하여 관리형 인스턴의 대기 통계를 쉽게 분석하고 있다.  QPI 라이브러리를 설치하려면 아래 링크로 이동하여 SQL Server 버전에 대한 SQL 스크립트를 다운로드 한다. QPI 라이브러리는 Query Store 보기에 의존하기 때문에 SQL Server 2016이상, Azure SQL 에서 사용이 가능하다.

·       Download QPI(Query Performance Insights) : https://github.com/JocaPC/qpi#installation

이 라이브러리를 사용하면 대기 통계의 스냅샷을 쉽게 작성하고 잠시 기다렸다가 대기 통계 값을 읽을 수 있다.

위 결과를 살펴보면, 관리 인스턴스의 태스크가 INSTANCE_LOG_RATE_GOVERNOR 대기 유형을 기다리고 있음을 알 수 있다. 위 스크립트를 주기적으로 실행하여 이러한 문제쿼리를 식별할 수 있다.  또한 qpi에서 제공하는 다양한 명령어를 사용하여 관리형 인스턴스의 IO 성능을 분석하여 병목 현상을 식별할 수 있다.

·       qpi.snapshot_file_stats 프로시저는 sys.dm_io_virtual_file_stats DMV 함수에서 I/O 통계 스냅샷을 작성한다. sys.dm_io_virtual_stats에는 누적 정보가 포함되어 있으며 최근 시간 간격으로 샘플을 계산해야 하므로 스냅샷을 작성해야 한다.

·       qpi.file_stats보기는 마지막 스냅샷 이후 파일 통계를 가져온다. 이 qpi는 sys.dm_io_virtual_file_stats의 데이터를 기반으로 하는 IOPS 처리량등 여러 계산이 포함된다.

아래 스크립트는 파일 유형(LOG/DATA)별로 분류된 인스턴스의 쓰기 처리량(MB/s)및 IOPS를 요약한다.

결과를 살펴보면 현재 인스턴스에서는 47.5MB/s 의 로그파일 쓰기와 총 1226 IOPS를 사용하고 있음을 알 수 있다. Azure 설명서에서 리소스 제한에 대한 설명을 보면  ~48MB/s가 현재 사용되는 인스턴스의 리밋이며, 이러한 리밋으로 인해서 INSTNACE_LOG_RATE_GOVERNOR 대기 통계가 발생하는 것이다. 인스턴스의 최대 사용량 리밋으로 인해서 성능 저하가 발생하지 않도록QPI 스크립트를 주기적으로 실행하여, 인스턴스의 리밋과 QPI결과값을 비교하여,모니터링 할 수 있도록 한다.

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2019/03/11/identify-log-write-limits-on-azure-sql-managed-instance-using-qpi-library/

2019-09-10 / Sungwook Kang / http://sungwookkang.com

Azure SQL, QPI, Query Performance Insights, SQL Server 2016, Query Store

Azure SQL Managed Instance 에서 SQL Agent의 Job history 기록 보관하기

·         Version : Azure SQL

Azure SQL Managed Instance는 Azure 클라우드에서 호스트되는 완전히 관리되는 SQL Server 이다. Managed Instance는 많은 SQL Server기능을 제공하지만 몇 가지 제약이 있다. 제약사항 중 하나는 SQL Agent작업 실행의 히스토리 기록을 변경할 수 없다는 것이다. 이번 포트스에서는 이 제약 사항을 다른 방법으로 우회하여 해결하는 방법 중 하나를 소개한다.

Managed Instance의 SQL Agent는 각 작업당 100개의 히스토리를 기록하며,  총 1000개의  히스토리 기록을 유지할 수 있다. 아래 프로시저를 실행하면 jobhistory_max_rows_per_job열에서 이 정보를 확인할 수 있다.

Azure SQL Managed Instance는 SQL Agent의 히스토리를 기록하는 정보 값을 기본 레지스트리 값에 저장하므로 SQL Agent등록 정보를 변경할 수 없다. 그래서 SQL Agent 작업 히스토리에 대한 보존 정책 (작업 당 100개의 히스토리 또는  전체 히스토리 최대 1000개의 기록)을 고정시켯다. 즉 일부 직업의 경우 더 오래된 작업 기록을 확인하지 못 할 수 있다. 따라서 이러한 작업 히스토리 정보를 장기적으로 또는 삭제되기 이전에 이 정보를 보존하려면 sysjobhistory 테이블에서 정보를 다른 테이블에 저장해야 한다.  아래 예제를 통해서 어떻게 저장하는지 살펴본다.