Azure에서 SQL Server를 배포하기 위한 PaaS 옵션 설명
PaaS(Platform as a Service)는 클라우드의 완전한 개발 및 배포 환경을 제공하며, 이 환경은 단순한 클라우드 기반 애플리케이션과 고급 엔터프라이즈 애플리케이션에 사용할 수 있습니다.
Azure SQL Database 및 Azure SQL Managed Instance는 Azure SQL용 PaaS 제품의 일부입니다.
Azure SQL Database – 클라우드에서 SQL Server 엔진을 기반으로 구축된 제품군의 일부입니다. 개발자에게 새 애플리케이션 서비스 빌드와 관련해서 뛰어난 유연성을 제공하고, 세분화된 배포 옵션을 대규모로 제공합니다. SQL Database는 특정 워크로드에 적합한 옵션이 될 수 있는 낮은 유지 관리 솔루션을 제공합니다.
Azure SQL Managed Instance – 완전 관리형 서비스 및 기능을 제공하기 때문에 클라우드로 대부분의 마이그레이션 시나리오에 가장 적합합니다.
위 이미지에서 볼 수 있듯이 각 제품은 인프라에 대한 특정 관리 수준과 비용 효율성 정도에 따라 제공됩니다.
배포 모델
Azure SQL Database는 다음과 같은 두 가지 배포 모델로 사용할 수 있습니다.
단일 데이터베이스 – 데이터베이스 수준별로 청구되고 관리되는 단일 데이터베이스 스케일링 및 데이터 크기 관점에서 각 데이터베이스를 개별적으로 관리합니다. 이 모델에 배포된 각 데이터베이스에는 동일한 논리 서버에 배포된 경우에도 고유한 전용 리소스가 있습니다.
Elastic Pool – 함께 관리되고 공통된 리소스 세트를 공유하는 데이터베이스 그룹 탄력적 풀은 리소스가 모든 데이터베이스 간에 공유되므로 SaaS(Software as a Service) 애플리케이션 모델에 대해 비용 효율적인 솔루션을 제공합니다. DTU 기반 구매 모델 또는 vCore 기반 구매 모델을 기준으로 리소스를 구성할 수 있습니다.
구매 모델
Azure에서 모든 서비스는 물리적 하드웨어에서 지원되며 두 가지 구매 모델 중에서 선택할 수 있습니다.
DTU(데이터베이스 트랜잭션 단위)
DTU는 컴퓨팅, 스토리지 및 I/O 리소스를 결합하는 수식을 기반으로 계산합니다. 간단하고 미리 구성된 리소스 옵션을 원하는 고객에게 적합합니다.
DTU 구매 모델은 기본, 표준 및 프리미엄과 같은 여러 다른 서비스 계층에서 제공됩니다. 각 계층에는 이 플랫폼을 선택할 때 사용할 수 있는 광범위한 옵션을 제공하는 다양한 기능이 있습니다.
성능 측면에서 기본 계층은 덜 까다로운 워크로드에 사용되고 프리미엄은 집중적인 워크로드 요구 사항에 사용됩니다.
컴퓨팅 및 스토리지 리소스는 DTU 수준에 따라 좌우되며, 고정 스토리지 제한, 백업 보존 및 비용으로 다양한 성능 기능을 제공합니다.
참고
DTU 구매 모델은 Azure SQL Database에서만 지원됩니다.
DTU 구매 모델에 대한 자세한 내용은 DTU 기반 구매 모델 개요를 참조하세요.
vCore
vCore 모델을 사용하면 지정된 워크로드에 따라 지정된 수의 VCore를 구매할 수 있습니다. vCore는 Azure SQL Database 리소스를 구매할 때의 기본 구매 모델입니다. vCore 데이터베이스에는 코어 수와 데이터베이스에 제공된 메모리 및 스토리지 크기 사이에 특정 관계가 있습니다. vCore 구매 모델은 Azure SQL Database 및 Azure SQL Managed Instance에서 지원됩니다.
다음과 같은 세 가지 서비스 계층에서도 vCore 데이터베이스를 구입할 수 있습니다.
범용 - 이 계층은 범용 워크로드용입니다. Azure 프리미엄 스토리지에서 지원됩니다. 중요 비즈니스용보다 대기 시간이 깁니다. 또한 다음과 같은 컴퓨팅 계층을 제공합니다.
- 프로비저닝됨 – 컴퓨팅 리소스가 미리 할당됨 구성된 vCore에 따라 시간당 청구
- 서버리스 – 컴퓨팅 리소스의 크기가 자동으로 조정됨 사용된 VCore에 따라 초당 청구
중요 비즈니스용 – 이 계층은 서비스 계층 중에서 대기 시간이 가장 짧은 고성능 워크로드용입니다. 이 계층은 Azure Blob 스토리지 대신 로컬 SSD에서 지원됩니다. 보고 워크로드를 오프로드하는 데 사용할 수 있는 기본 제공 읽기 전용 데이터베이스 복제본을 제공할 뿐만 아니라 실패의 경우 최고의 복원력을 제공합니다.
하이퍼스케일 – 하이퍼스케일 데이터베이스는 다른 Azure SQL Database 제품의 4TB 제한을 훨씬 초과하여 확장할 수 있으며 최대 100TB의 데이터베이스를 지원하는 고유한 아키텍처가 포함되어 있습니다.
서버를 사용하지 않음
연결하는 논리 서버에 여전히 Azure SQL Database를 배포하므로 "서버리스"라는 이름은 약간 혼란스러울 수 있습니다. Azure SQL Database 서버리스는 워크로드 주문형으로 지정된 데이터베이스에 맞게 리소스를 자동으로 스케일 업하거나 스케일 다운하는 컴퓨팅 계층입니다. 워크로드에 더 이상 컴퓨팅 리소스가 필요하지 않으면 데이터베이스는 “일시 중지”되고 데이터베이스가 비활성 상태에 있는 동안에는 스토리지만 청구됩니다. 연결하려고 하면 데이터베이스가 "다시 시작"되고 사용할 수 있게 됩니다.
일시 중지를 제어하는 설정은 자동 일시 중지 지연이라고 하며 최솟값은 60분이 고 최댓값은 7일입니다. 데이터베이스가 해당 기간 동안 유휴 상태이면 일시 중지됩니다.
데이터베이스가 지정된 시간 동안 비활성 상태이면 후속 연결을 시도할 때까지 일시 중지됩니다. 컴퓨팅 자동 크기 조정 범위 및 자동 일시 중지 지연 구성은 데이터베이스 성능 및 컴퓨팅 비용에 영향을 줍니다.
일시 정지된 데이터베이스에 연결하면 연결 오류가 생성되므로 서버리스를 사용하는 애플리케이션은 연결 오류를 처리하고 재시도 논리를 포함하도록 구성해야 합니다.
Azure SQL Database의 일반 vCore 모델과 서버리스 사이의 또 다른 차이점은 서버리스에서는 최소 및 최대 vCores 수를 지정할 수 있다는 것입니다. 메모리 및 I/O 한도는 지정된 범위에 비례합니다.
위 이미지는 Azure Portal의 서버리스 데이터베이스 구성 화면을 보여 줍니다. 최솟값을 vCore의 절반까지 선택하고 최댓값을 16개의 vCore까지 선택하는 옵션이 있습니다.
서버리스가 Azure SQL Database의 모든 기능과 완벽하게 호환되지는 않습니다. 그 중 일부는 백그라운드 프로세스를 항상 실행해야 하기 때문에 다음과 같습니다.
- 지역에서 복제
- 장기 백업 보존
- 탄력적 작업의 작업 데이터베이스
- SQL 데이터 동기화의 동기화 데이터베이스(데이터 동기화는 데이터베이스 그룹 간에 데이터를 복제하는 서비스임)
참고
SQL Database 서버리스는 현재 vCore 구매 모델에 대한 범용 계층에서만 지원됩니다.
Backup
PaaS(Platform as a Service) 제품의 가장 중요한 기능 중 하나는 백업입니다. 이 경우 백업이 사용자의 개입 없이 자동으로 수행됩니다. 백업은 Azure Blob GRS(지역 중복 스토리지)에 저장되며 데이터베이스의 서비스 계층을 기반으로 기본적으로 7 - 35일 동안 보존됩니다. 기본 및 vCore 데이터베이스에서는 기본적으로 7일 동안 보존되며 vCore 데이터베이스에서는 관리자가 이 값을 조정할 수 있습니다. LTR(장기 보존)을 구성하여 보존 시간을 연장하면 최대 10년 동안 백업을 보존할 수 있습니다.
중복성을 제공하기 위해 읽기 액세스 가능 지역 중복 Blob 스토리지도 사용할 수 있습니다. 이 스토리지는 데이터베이스 백업을 기본 설정 보조 지역에 복제합니다. 필요한 경우 해당 보조 지역에서 읽을 수도 있습니다. 데이터베이스의 수동 백업은 지원되지 않으며 플랫폼에서 해당 요청을 거부합니다.
데이터베이스 백업은 지정된 일정에 따라 수행됩니다.
- 전체 – 일주일에 한 번
- 차등 – 12시간마다
- 로그 – 트랜잭션 로그 활동에 따라 5-10분마다
이 백업 일정은 대부분의 복구 지점/시간 목표(RPO/RTO)의 요구 사항을 충족해야 하지만, 각 고객이 비즈니스 요구 사항을 충족하는지 평가해야 합니다.
데이터베이스를 복원하는 데 사용할 수 있는 몇 가지 옵션이 있습니다. PaaS(Platform as a Service)의 특성으로 인해 T-SQL 명령인 RESTORE DATABASE를 실행하는 등의 기존 방법을 사용하여 수동으로 데이터베이스를 복원할 수 없습니다.
구현되는 복원 방법에 상관없이 기존 데이터베이스를 통해 복원할 수 없습니다. 데이터베이스를 복원해야 하는 경우 복원 프로세스를 시작하기 전에 기존 데이터베이스를 삭제하거나 이름을 바꿔야 합니다. 또한 플랫폼 서비스 계층에 따라 복원 시간은 보장되지 않으며 변동될 수 있습니다. 복원에 소요될 수 있는 시간에 관한 기준 메트릭을 얻기 위해 복원 프로세스를 테스트하는 것이 좋습니다.
사용 가능한 복원 옵션은 다음과 같습니다.
Azure Portal을 사용하여 복원 - Azure Portal을 사용하면 데이터베이스를 동일한 Azure SQL Database 서버로 복원하는 옵션이 있습니다. 또는 복원을 사용하여 모든 Azure 지역의 새 서버에 새 데이터베이스를 만들 수 있습니다.
스크립팅 언어를 사용하여 복원 – 데이터베이스를 복원하기 위해 PowerShell과 Azure CLI를 모두 활용할 수 있습니다.
참고
Azure Blob Storage에 대한 복사 전용 백업은 SQL Managed Instance에서 사용할 수 있습니다. SQL Database는 이 기능을 지원하지 않습니다.
자동화된 백업에 대한 자세한 내용은 자동화된 백업 - Azure SQL Database 및 Azure SQL Managed Instance를 참조하세요.
활성 지리적 복제
지역 복제는 데이터베이스를 최대 4개의 보조 복제본에 비동기식으로 복제하는 비즈니스 연속성 기능입니다. 트랜잭션이 기본(및 동일한 지역 내의 복제본)에 커밋되면 재생되도록 트랜잭션을 보조로 전송합니다. 이 통신은 비동기식으로 수행되므로 SQL Server가 호출자에게 제어를 반환하기에 앞서 보조 복제본이 트랜잭션을 커밋할 때까지 호출 애플리케이션이 대기할 필요가 없습니다.
보조 데이터베이스는 읽기 가능하고 읽기 전용 워크로드를 오프로드하는 데 사용할 수 있으므로 기본에서 트랜잭션 워크로드에 사용할 리소스를 확보하거나 데이터를 최종 사용자에게 더 가깝게 배치할 수 있습니다. 또한 보조 데이터베이스는 기본 데이터베이스와 동일한 지역 또는 다른 Azure 지역에 있을 수 있습니다.
지역 복제를 사용하면 사용자 또는 애플리케이션이 수동으로 장애 조치(failover)를 시작할 수 있습니다. 장애 조치(failover)가 발생하면 현재 주 데이터베이스의 새 엔드포인트를 반영하도록 애플리케이션 연결 문자열을 업데이트해야 할 수도 있습니다.
장애 조치(failover) 그룹
장애 조치(failover) 그룹은 지역 복제에 사용되는 기술을 기반으로 빌드되지만 연결에 사용할 단일 엔드포인트를 제공합니다. 장애 조치(failover) 그룹을 사용하는 주된 이유는 이 방법이 적절한 복제본으로 트래픽을 라우팅하는 데 활용할 수 있는 엔드포인트를 제공하기 때문입니다. 그러면 연결 문자열을 변경하지 않고 장애 조치(failover) 후에 애플리케이션이 연결할 수 있습니다.