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는 두 가지 배포 모델에서 사용할 수 있습니다.

• 단일 데이터베이스 – 데이터베이스당 수준에서 청구되고 관리되는 단일 데이터베이스입니다. 스케일링 및 데이터 크기 관점에서 각 데이터베이스를 개별적으로 관리합니다. 이 모델에 배포된 각 데이터베이스에는 동일한 논리 서버에 배포된 경우에도 고유한 전용 리소스가 있습니다.

• 탄력적 풀 – 함께 관리되고 공통 리소스 집합을 공유하는 데이터베이스 그룹입니다. 탄력적 풀은 리소스가 모든 데이터베이스 간에 공유되기 때문에 서비스 애플리케이션 모델로서의 소프트웨어에 대한 비용 효율적인 솔루션을 제공합니다. DTU 기반 구매 모델 또는 vCore 기반 구매 모델을 기준으로 리소스를 구성할 수 있습니다.

구매 모델

Azure에서 모든 서비스는 물리적 하드웨어를 지원하며 두 가지 구매 모델 중에서 유연하게 선택할 수 있습니다.

DTU(데이터베이스 트랜잭션 단위)

DTU 기반 구매 모델은 컴퓨팅, 스토리지 및 I/O 리소스를 결합한 수식을 기반으로 계산됩니다. 간단하고 미리 구성된 리소스 옵션을 원하는 고객에게 적합합니다.

DTU 구매 모델은 기본, 표준 및 프리미엄과 같은 여러 서비스 계층으로 제공됩니다. 각 계층에는 이 플랫폼을 선택할 때 다양한 옵션을 제공하는 다양한 기능이 있습니다.

성능 측면에서 기본 계층은 덜 까다로운 워크로드에 사용되고 프리미엄 계층은 집중적인 워크로드 요구 사항에 사용됩니다.

컴퓨팅 및 스토리지 리소스는 DTU 수준에 따라 좌우되며, 고정 스토리지 제한, 백업 보존 및 비용으로 다양한 성능 기능을 제공합니다.

DTU 구매 모델에 대한 자세한 내용은 DTU 기반 구매 모델 개요를 참조하세요.

vCore

vCore 기반 구매 모델을 사용하면 지정된 워크로드에 따라 지정된 수의 vCore를 구매할 수 있습니다. vCore는 Azure SQL Database 리소스를 구매할 때 기본 구매 모델입니다. vCore 데이터베이스는 코어 수와 데이터베이스에 제공된 메모리 및 스토리지 양 간에 특정 관계를 갖습니다. vCore 구매 모델은 Azure SQL Database와 Azure SQL Managed Instance 모두에서 지원됩니다.

세 가지 서비스 계층에서 vCore 데이터베이스를 구입할 수도 있습니다.

범용 서비스 계층은 프로비전 및서버리스라는 두 가지 컴퓨팅 옵션을 제공합니다. 프로비전된 리소스는 구성된 vCore에 따라 매시간 미리 할당되고 요금이 청구되며 일관된 워크로드에 적합합니다. 서버리스 리소스는 수요에 따라 자동 크기 조정되며 초당 요금이 청구되므로 가변 워크로드에 비용 효율적입니다.

서버를 사용하지 않음

"서버리스"라는 용어는 연결을 위해 Azure SQL Database를 여전히 논리 서버에 배포하기 때문에 오해의 소지가 있습니다. 서버리스는 워크로드 수요에 따라 리소스를 자동으로 확장 또는 축소하는 컴퓨팅 계층입니다. 워크로드에 컴퓨팅 리소스가 더 이상 필요하지 않으면 데이터베이스가 일시 중지되고 비활성 기간 동안 스토리지만 요금이 청구됩니다. 연결이 시도되면 데이터베이스가 다시 시작되고 사용할 수 있게 됩니다.

일시 중지를 제어하는 설정을 자동 일시 중지 지연이라고 하며, 최소값은 60분, 최대값은 7일입니다. 데이터베이스가 해당 기간 동안 유휴 상태로 유지되면 일시 중지됩니다.

지정된 시간 동안 데이터베이스가 비활성 상태이면 후속 연결 시도까지 일시 중지됩니다. 컴퓨팅 자동 크기 조정 범위 및 자동 일시 중지 지연을 구성하면 데이터베이스 성능 및 컴퓨팅 비용에 영향을 줍니다.

일시 중지된 데이터베이스에 연결하면 연결 오류가 생성되기 때문에 서버리스를 사용하는 애플리케이션은 연결 오류를 처리하고 재시도 논리를 포함하도록 구성해야 합니다.

서버리스 모델과 Azure SQL Database의 표준 vCore 모델 간의 또 다른 차이점은 서버리스를 사용하면 최소 및 최대 vCore 수를 지정할 수 있다는 점입니다. 메모리 및 I/O 제한은 지정된 범위에 비례합니다.

이미지는 Azure Portal에서 서버리스 데이터베이스에 대한 구성 화면을 보여 줍니다. vCore의 절반 이하의 최소값과 최대 16개의 vCore를 선택할 수 있습니다.

서버리스가 Azure SQL Database의 모든 기능과 완전히 호환되지는 않습니다. 그 중 일부는 다음과 같이 백그라운드 프로세스를 지속적으로 실행해야 하기 때문에 다음과 같습니다.

• 지리적 복제
• 장기 백업 보존
• 탄력적 작업의 작업 데이터베이스
• SQL 데이터 동기화의 동기화 데이터베이스(데이터 동기화는 데이터베이스 그룹 간에 데이터를 복제하는 서비스)

백업

Platform as a Service 제품의 가장 중요한 기능 중 하나는 백업입니다. 이 경우 시스템은 개입 없이 자동으로 백업을 수행합니다. Azure Blob 지역 중복 스토리지는 이러한 백업을 저장하며, 기본적으로 데이터베이스의 서비스 계층에 따라 7~35일 동안 유지됩니다. 기본 및 vCore 데이터베이스는 기본적으로 보존 기간이 7일이며 관리자는 vCore 데이터베이스에 대해 이 값을 조정할 수 있습니다. 최대 10년 동안 백업을 유지할 수 있도록 LTR(장기 보존)을 구성하여 보존 시간을 연장할 수 있습니다.

중복성을 제공하기 위해 읽기 액세스 가능한 지역 중복 Blob Storage를 사용할 수도 있습니다. 이 스토리지는 기본 설정의 보조 지역에 데이터베이스 백업을 복제합니다. 또한 필요한 경우 해당 보조 지역에서 읽을 수 있습니다. 데이터베이스의 수동 백업은 지원되지 않으며 플랫폼은 이를 위한 요청을 거부합니다.

데이터베이스 백업은 지정된 일정에 따라 수행됩니다.

• 전체 – 일주일에 한 번
• 차등 – 12시간마다
• 로그– 트랜잭션 로그 활동에 따라 5-10분마다

이 백업 일정은 대부분의 RPO/RTO(복구 지점/시간 목표)의 요구 사항을 충족해야 하지만 각 고객은 비즈니스 요구 사항을 충족하는지 평가해야 합니다.

데이터베이스를 복원하는 데 사용할 수 있는 몇 가지 옵션이 있습니다. Platform as a Service의 특성상 T-SQL 명령 RESTORE DATABASE실행과 같은 기존 메서드를 사용하여 데이터베이스를 수동으로 복원할 수 없습니다.

구현되는 복원 방법에 관계없이 기존 데이터베이스를 통해 복원할 수 없습니다. 데이터베이스를 복원해야 하는 경우 복원 프로세스를 시작하기 전에 기존 데이터베이스를 삭제하거나 이름을 바꿔야 합니다. 또한 플랫폼 서비스 계층에 따라 복원 시간이 보장되지 않으며 변동될 수 있습니다. 복원 프로세스를 테스트하여 복원에 소요될 수 있는 기간에 대한 기준 메트릭을 가져오는 것이 좋습니다.

• Azure Portal을 사용하여 복원 – Azure Portal을 사용하면 Azure SQL Database에 대해 동일한 논리 서버로 데이터베이스를 복원하거나 복원을 사용하여 모든 Azure 지역의 새 서버에 새 데이터베이스를 만들 수 있습니다.

• 스크립팅 언어를 사용하여 복원 – 데이터베이스를 복원하기 위해 PowerShell과 Azure CLI를 모두 사용할 수 있습니다.

자동화된 백업에 대한 자세한 내용은 자동화된 백업 - Azure SQL Database 및 Azure SQL Managed Instance를 참조하세요.

활성 지리적 복제

지역 복제 는 최대 4개의 보조 복제본에 데이터베이스를 비동기적으로 복제하는 비즈니스 연속성 기능입니다. 트랜잭션이 주 노드(및 동일한 지역 내의 복제본)에 커밋되면 트랜잭션이 보조 노드로 전송되어 재생됩니다. 이 통신은 비동기적으로 수행되므로 호출 애플리케이션은 SQL Server가 호출자에게 컨트롤을 반환하기 전에 보조 복제본이 트랜잭션을 커밋할 때까지 기다릴 필요가 없습니다.

보조 데이터베이스는 읽을 수 있으며 읽기 전용 워크로드를 오프로드하는 데 사용할 수 있으므로 주 데이터베이스의 트랜잭션 워크로드에 대한 리소스를 확보하거나 데이터를 최종 사용자에게 더 가깝게 배치할 수 있습니다. 또한 보조 데이터베이스는 주 데이터베이스와 동일한 지역 또는 다른 Azure 지역에 있을 수 있습니다.

사용자가 수동으로 또는 애플리케이션에서 프로그래밍 방식으로 장애 조치(failover)를 시작할 수 있습니다. 장애 조치(failover)가 발생하는 경우 현재 주 데이터베이스의 새 엔드포인트를 반영하도록 애플리케이션 연결 문자열을 업데이트할 수 있습니다.

장애 조치(failover) 그룹

장애 조치(failover) 그룹은 지역 복제에 사용되는 기술을 기반으로 빌드되지만 연결에 사용할 단일 엔드포인트를 제공합니다. 장애 조치(failover) 그룹을 사용하는 주된 이유는 트래픽을 적절한 복제본으로 라우팅하는 데 사용할 수 있는 엔드포인트를 제공하기 때문입니다. 그러면 연결 문자열이 변경되지 않고 장애 조치(failover) 후에 애플리케이션을 연결할 수 있습니다.