Azure SQL (SQL Database, Managed Instance, VM 의 SQL Server)
Azure SQL 제품군 세 가지의 차이, 구매 모델(vCore, DTU)과 서비스 계층(General Purpose, Business Critical, Hyperscale), 서버리스와 자동 일시 중지, 무료 제공(매달 10개 DB), 고가용성과 장애 조치 그룹, Entra 인증과 네트워크 보안, 성능 문제 확인 방법을 정리합니다.
세 가지 제품
| 제품 | 관리 범위 | 고르는 경우 |
|---|---|---|
| Azure SQL Database | 데이터베이스 단위 PaaS. OS, 패치, 백업 모두 Azure | 새 앱, 클라우드 네이티브 |
| Azure SQL Managed Instance | 인스턴스 단위 PaaS. SQL Agent, 교차 DB 쿼리, CLR 등 SQL Server 호환성 높음 | 온프레미스 SQL Server 이전 (lift and shift) |
| SQL Server on Azure VM | IaaS. OS 와 SQL 을 직접 관리 | OS 접근, 특정 버전, 서드파티 에이전트 필요 |
SQL Database 에서 "서버" 는 로그인, 방화벽, 감사 설정을 묶는 논리 서버일 뿐 실제 VM 이 아닙니다. 데이터베이스마다 따로 크기와 요금이 정해집니다. 여러 DB 의 사용량이 들쭉날쭉하면 탄력적 풀(elastic pool) 에 넣어 자원을 나눠 씁니다.
구매 모델과 서비스 계층
새 설계는 vCore 모델을 기준으로 합니다(DTU 는 CPU, 메모리, IO 를 묶은 예전 단위).
| 계층 | 저장소 구조 | 특징 |
|---|---|---|
| General Purpose | 원격 저장소 (Premium 스토리지) | 일반 업무. 가장 많이 씀. 서버리스 가능 |
| Business Critical | 로컬 SSD, Always On 가용성 그룹 4개 복제본 | 낮은 지연, 읽기 전용 복제본 하나 무료, 메모리 내 OLTP |
| Hyperscale | 분산 페이지 서버 + 로그 서비스 | 최대 128 TB, 빠른 백업과 복원, 읽기 복제본 여럿, 서버리스 가능 |
Hyperscale 은 큰 DB 만을 위한 계층이 아니라 일반 OLTP 의 기본 선택지로도 쓰입니다. 계층 간 이동이 가능하지만 Hyperscale 에서 다른 계층으로 되돌리는 데는 조건이 있으니 문서를 확인합니다.
서버리스
General Purpose 와 Hyperscale 에는 서버리스 컴퓨트가 있습니다. 최소, 최대 vCore 사이에서 자동으로 늘고 줄며 초 단위로 과금합니다. General Purpose 서버리스는 일정 시간 활동이 없으면 자동 일시 중지되어 저장소 요금만 남습니다. 대신 재개할 때 첫 연결이 실패하거나 느릴 수 있으므로 앱에 재시도 로직이 있어야 합니다.
무료 제공 (Free offer)
학습이나 작은 앱에는 SQL Database 무료 제공이 좋습니다.
| 항목 | 값 |
|---|---|
| 대상 | 구독 종류와 상관없이 구독당 General Purpose DB 10개까지 |
| DB 당 매달 | 서버리스 컴퓨트 100,000 vCore 초, 데이터 32 GB, 백업 32 GB |
| 한도에 닿으면 | 다음 달까지 자동 일시 중지(과금 없음) 또는 계속 쓰고 초과분 과금 중 선택 |
탄력적 풀, 장애 조치 그룹에는 넣을 수 없고, 구독의 첫 무료 DB 를 만든 리전으로 나머지 무료 DB 리전이 고정됩니다.
고가용성과 재해 복구
- 영역 중복: General Purpose, Business Critical, Hyperscale 모두 지원 리전에서 영역 중복을 켤 수 있습니다. Korea Central 운영 DB 는 켜는 것을 기본으로 합니다.
- 자동 백업: 전체, 차등, 로그 백업이 자동이고 특정 시점 복원(PITR) 기간은 1~35일(계층에 따라 다름)입니다. 장기 보존(LTR)으로 주, 월, 년 단위 백업을 최대 10년 보관합니다.
- 장애 조치 그룹: 다른 리전(예: Korea South)에 지역 복제본을 두고, 읽기 쓰기용 리스너 주소(
<그룹>.database.windows.net)를 앱에 주면 장애 조치 뒤에도 연결 문자열을 바꾸지 않아도 됩니다.
보안
| 영역 | 권장 |
|---|---|
| 인증 | Microsoft Entra 전용 인증. SQL 로그인 끄기. 앱은 관리 ID |
| 네트워크 | 공용 액세스 끄고 Private Endpoint. 필요하면 서버 방화벽에서 최소 IP 만 |
| 암호화 | TDE 기본 켜짐. 규제가 있으면 고객 관리 키 |
| 감사, 위협 탐지 | 감사 로그를 Log Analytics 로, Defender for SQL |
| 데이터 보호 | Always Encrypted, 동적 데이터 마스킹, 행 수준 보안 |
-- 앱의 관리 ID 를 DB 사용자로 만들고 권한 주기 (Entra 관리자로 접속해서)
CREATE USER [app-shop-prod] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [app-shop-prod];
ALTER ROLE db_datawriter ADD MEMBER [app-shop-prod];성능 확인
- 쿼리 저장소(Query Store) 가 기본으로 켜져 있습니다. 가장 많이 자원을 쓴 쿼리, 계획이 바뀌어 느려진 쿼리를 찾습니다.
- 대기 통계로 병목 종류(CPU, IO, 잠금)를 봅니다.
SELECT TOP 10 wait_type, wait_time_ms, waiting_tasks_count
FROM sys.dm_db_wait_stats
ORDER BY wait_time_ms DESC;
SELECT TOP 10 end_time, avg_cpu_percent, avg_data_io_percent, avg_log_write_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC;- 자동 튜닝의 계획 강제(FORCE_LAST_GOOD_PLAN)는 기본으로 켜 두고, 인덱스 만들기와 지우기 권고는 검토 뒤 적용합니다.
- 로그 쓰기 비율이 100% 에 붙으면 계층의 로그 처리량 한도입니다. 배치 크기를 키우거나 Hyperscale, Business Critical 을 검토합니다.
Fabric 과 연결
운영 DB 를 분석에 쓰려면 Microsoft Fabric 의 미러링으로 OneLake 에 거의 실시간 복제본을 만들 수 있습니다. 운영 DB 에 무거운 분석 쿼리를 날리지 않아도 됩니다 (Fabric 과 분석).