Azure SQL 서비스 계층과 컴퓨팅 모델

DTU 모델과 vCore 모델의 차이, General Purpose·Business Critical·Hyperscale 계층, Serverless와 Elastic Pool을 비교합니다.

DP-300 시험에서 서비스 계층 파트는 '이 워크로드에 어떤 계층이 가장 적합한가'를 묻습니다. 단순히 이름을 외우는 게 아니라, 각 계층이 어떤 트레이드오프를 갖는지 알아야 합니다. 구매 모델(DTU vs vCore)부터 컴퓨팅 계층(Provisioned vs Serverless), 그리고 Elastic Pool까지, 선택지 하나하나에 의미가 있습니다.

DTU 모델과 vCore 모델: 번들 요금제 vs 부품 선택

마트에서 장 볼 때 '가정간편식 세트'를 사는 사람도 있고, 재료를 하나씩 골라 담는 사람도 있습니다. DTU 모델은 세트에 가깝습니다. CPU·메모리·I/O가 하나의 숫자(DTU)로 묶여 있어서 설정이 간단하고 가격도 예측하기 쉽습니다. Basic, Standard, Premium 세 계층이 있고, 숫자가 올라갈수록 번들 자원이 커집니다.

vCore 모델은 부품 선택입니다. CPU 코어 수, 메모리, 스토리지를 각각 독립적으로 고를 수 있어서 "CPU는 많이, 스토리지는 적게"처럼 세밀한 조정이 가능합니다. Azure Hybrid Benefit을 통해 기존 SQL Server 라이선스를 가져올 수도 있어서 비용을 줄일 여지도 있습니다. General Purpose, Business Critical, Hyperscale 세 계층을 모두 vCore 모델에서 선택할 수 있습니다.

DP-300에서 이 둘을 구분하는 핵심 키워드는 '라이선스 이동 가능 여부'와 '리소스 독립 제어'입니다. Azure Hybrid Benefit이 나오면 vCore, 단순하고 예측 가능한 청구가 필요하면 DTU입니다.

 

General Purpose: 범용 창고

물류 회사가 새 창고를 구할 때, 특수 냉동 시설이나 위험물 보관소가 없어도 되는 일반 화물이라면 '범용 창고'를 임대합니다. 비용 대비 충분한 공간이 목표입니다. Azure SQL Database의 General Purpose 계층이 딱 그런 역할입니다.

General Purpose는 vCore 모델의 기본 계층입니다. 스토리지는 Azure Premium Storage(원격 SSD)를 사용하고, 최대 8,000 IOPS까지 지원합니다. 고가용성은 내부적으로 스토리지 복제로 구현합니다. 장애 발생 시 자동 페일오버가 되지만, 페일오버 완료까지 20~30초 정도 소요될 수 있습니다.

In-Memory OLTP 지원이 없다는 점도 기억해두세요. 대부분의 OLTP·OLAP 워크로드에는 충분하지만, 초당 트랜잭션이 매우 높은 금융 거래 처리 같은 시나리오에서는 Business Critical이 더 적합합니다.

 

Business Critical: 로컬 SSD와 AlwaysOn

공항 관제탑은 네트워크가 느려지는 순간을 허용하지 않습니다. 레이더 데이터, 이착륙 정보는 항상 즉각 응답해야 합니다. Business Critical 계층은 데이터베이스에서 그런 역할을 합니다.

Business Critical의 스토리지는 로컬 SSD입니다. 원격 스토리지를 거치지 않으므로 지연이 낮고 IOPS가 훨씬 높습니다. 내부적으로 AlwaysOn Availability Group(AG) 기반의 4개 노드 클러스터를 구성합니다. 이 중 하나를 Read Scale-Out용 읽기 전용 replica로 활용할 수 있습니다.

추가 비용 없이 읽기 쿼리를 secondary replica로 분산시킬 수 있다는 점이 중요합니다. 리포팅 워크로드가 많은 환경에서는 이 기능만으로도 주 데이터베이스 부하를 줄일 수 있습니다. 또한 In-Memory OLTP도 지원합니다. 고성능 OLTP, 고가용성, 낮은 읽기 지연이 모두 필요하다면 Business Critical이 선택지입니다.

 

Hyperscale: 사실상 무한 확장

전통적인 데이터베이스는 창고 크기가 정해져 있어서, 가득 차면 이사를 가야 합니다. Hyperscale은 창고 벽이 스스로 늘어납니다. 최대 100TB까지, 데이터가 늘어나면 스토리지가 자동으로 확장됩니다.

Hyperscale은 고유한 아키텍처를 사용합니다. 페이지 서버(Page Server) 계층이 스토리지를 관리하고, 컴퓨팅 노드는 필요에 따라 추가하거나 줄입니다. 스케일 업(컴퓨팅 증가)은 몇 분 안에 완료되고, 백업도 스냅샷 기반이라 데이터 크기에 관계없이 빠릅니다. 복구 역시 snapshot restore로 빠르게 가능합니다.

단, 주의할 점이 있습니다. Hyperscale에서 General Purpose나 Business Critical로 다운그레이드하는 것은 현재 지원되지 않습니다. 한번 올라가면 내려오는 길이 없습니다. 정말 대용량 데이터가 필요한 경우에만 선택해야 하는 이유입니다.

!Azure SQL 서비스 계층

Serverless vs Provisioned: 사용한 만큼만

사무실 에어컨을 24시간 켜두는 회사도 있고, 직원이 있을 때만 자동으로 켜지는 회사도 있습니다. Provisioned 컴퓨팅은 항상 켜진 에어컨이고, Serverless는 자동 온오프 에어컨입니다.

Serverless는 General Purpose vCore 계층에서만 사용할 수 있습니다. 자동 일시 중지(auto-pause)와 자동 재개(auto-resume)를 지원합니다. 트래픽이 없는 시간에는 데이터베이스가 멈추고, 접속이 들어오면 자동으로 깨어납니다. 비용은 활성 상태일 때 초 단위로 청구됩니다.

장점은 간헐적으로 사용하는 개발·테스트 데이터베이스에서 비용 절감 효과가 큽니다. 단점은 cold start 지연입니다. 일시 중지 상태에서 첫 요청이 들어올 때 몇 초에서 수십 초 대기가 발생합니다. 24시간 안정적인 응답이 필요한 프로덕션 워크로드에는 Provisioned이 적합합니다.

 

Elastic Pool: 여러 DB가 함께 쓰는 리소스 풀

호텔 수영장을 생각해봅시다. 투숙객 각자가 개인 수영장을 갖는 것보다, 다 같이 하나의 큰 수영장을 나눠 쓰는 게 효율적입니다. 투숙객마다 사용 시간이 다르기 때문입니다. Elastic Pool이 바로 그 방식입니다.

Elastic Pool은 여러 데이터베이스가 하나의 리소스 풀(DTU 또는 vCore)을 공유하는 구조입니다. 각 데이터베이스가 피크 시간이 서로 다르거나, 워크로드 패턴이 불규칙할 때 효과적입니다. SaaS 애플리케이션처럼 수십~수백 명의 테넌트가 각각 별도 DB를 갖는 경우, 모두를 Elastic Pool에 넣으면 전체 비용을 줄일 수 있습니다.

풀 내 각 데이터베이스에는 최소 보장 리소스(min)와 최대 한도(max)를 설정할 수 있어서 하나의 DB가 풀 전체를 독점하는 것을 막을 수 있습니다.

 

계층 선택의 함정: 나중에 바꾸면 되지

여행 짐을 쌀 때 필요하면 현지에서 사면 되지라고 생각하다가 낭패를 보는 경우가 있습니다. Azure SQL Database도 마찬가지로, 나중에 바꾸기 어려운 선택이 있습니다.

가장 중요한 함정은 Hyperscale로의 마이그레이션은 단방향이라는 점입니다. Hyperscale에서 General Purpose로 돌아갈 수 없습니다. 또한 Serverless와 geo-replication은 함께 사용할 수 없습니다. 재해 복구가 필요한 프로덕션에 Serverless를 선택하면 geo-replication을 붙일 수 없어 결국 Provisioned으로 다시 바꿔야 합니다.

DTU 모델에서 vCore 모델로 전환은 가능하지만, 반대(vCore to DTU)는 불가능합니다. Business Critical의 Read Scale-Out은 추가 비용 없이 사용 가능하지만, General Purpose에는 이 기능이 없습니다. 처음에 계층을 선택할 때 향후 요구사항을 충분히 고려해야 하는 이유입니다.

 

시험 핵심 정리

"CPU와 스토리지를 각각 독립 조정" -- vCore 모델 "Azure Hybrid Benefit으로 라이선스 가져오기" -- vCore 모델 "단순한 번들 요금, Basic/Standard/Premium" -- DTU 모델 "페타바이트급 데이터, 즉각 스케일" -- Hyperscale "Hyperscale에서 다운그레이드" -- 불가능 "로컬 SSD, AlwaysOn AG 4노드, In-Memory OLTP" -- Business Critical "추가 비용 없는 읽기 replica" -- Business Critical Read Scale-Out "auto-pause / auto-resume, 초 단위 과금" -- Serverless "Serverless + geo-replication" -- 함께 사용 불가 "여러 DB가 리소스 공유, 변동 워크로드, SaaS" -- Elastic Pool "원격 Premium Storage, 범용 OLTP" -- General Purpose

DTU = 번들 심플, vCore = 세밀 제어; GP = 범용, BC = 고성능+로컬SSD, Hyperscale = 초대용량(단방향)

블로그 목록으로 돌아가기