Azure SQL Database

애플리케이션이 데이터를 저장하기 시작하면, 결국 데이터베이스 서버를 직접 운영해야 하는 시점이 옵니다. 그런데 데이터베이스 운영은 쿼리를 짜는 것과 전혀 다른 일입니다. OS 패치를 놓치면 보안 구멍이 생기고, 백업 스크립트가 조용히 실패하면 장애 시 복구가 불가능해집니다. 디스크 용량 예측을 빗나가면 새벽에 알림이 울리고, 고가용성 구성은 전문가 없이 세팅하기 어렵습니다. 팀이 비즈니스 로직에 쏟아야 할 시간이 인프라 관리에 빠져들면서, 정작 스키마 설계와 쿼리 최적화는 뒷전으로 밀립니다. Azure SQL Database는 이 인프라 부담을 플랫폼이 맡아 주는 방식으로 문제를 해결합니다.

온프레미스에서 SQL Server를 운영하던 팀은 DB 자체의 기능에는 만족하면서도 인프라 관리에 계속 시간을 뺏겼습니다. Windows 업데이트 적용, 스토리지 확장, 클러스터 장애 조치 테스트, 백업 검증 같은 작업이 반복됐고, 이 모든 것은 DBA 인력과 운영 예산을 요구했습니다. 클라우드로 옮기더라도 VM에 SQL Server를 직접 설치하면(IaaS) 운영 부담이 크게 줄지 않았습니다. 이 상황에서 필요했던 것은 SQL Server의 호환성은 유지하되, 패치·백업·고가용성·스케일링을 플랫폼이 대신하는 방식이었습니다. Azure SQL Database는 이 요구에 대한 응답으로, SQL Server 엔진을 PaaS로 제공하면서 운영 책임의 상당 부분을 Azure 쪽으로 옮겼습니다. 그래서 기존 SQL Server 사용자에게는 '같은 엔진, 다른 운영 모델'로 이해하는 것이 가장 정확합니다.

Azure SQL Database는 SQL Server 엔진 위에 관리 계층을 얹은 구조입니다. 사용자는 논리 서버(logical server)를 만들고 그 안에 데이터베이스를 생성하지만, 실제 VM이나 OS에는 접근하지 않습니다. 패치, 백업, 장애 조치는 플랫폼이 자동으로 수행합니다. 성능은 두 가지 모델로 선택합니다. DTU 모델은 CPU, 메모리, I/O를 하나의 묶음 단위로 제공해 단순한 선택이 가능하고, vCore 모델은 CPU와 스토리지를 독립적으로 조절해 세밀한 튜닝이 가능합니다. 여러 데이터베이스를 운영할 때는 탄력적 풀에 묶으면, 각 DB가 피크 시간대가 다를 때 전체 리소스를 효율적으로 나눠 씁니다. 자동 백업은 전체 백업(주 1회), 차등 백업(12시간마다), 트랜잭션 로그 백업(5~10분마다)으로 구성되며, 이 백업을 기반으로 원하는 시점으로 복원할 수 있습니다. 활성 지역 복제를 설정하면 다른 리전에 비동기 복제본이 유지되어, 한 리전이 장애를 겪더라도 수동 또는 자동으로 전환할 수 있습니다.

Azure SQL Database와 Azure Cosmos DB는 둘 다 Azure의 관리형 데이터베이스이지만, 데이터 모델과 설계 철학이 다릅니다. SQL Database는 관계형 모델을 바탕으로 스키마가 정해진 정형 데이터에 강합니다. ACID 트랜잭션, 복잡한 JOIN, 외래 키 제약 같은 관계형 기능이 핵심이고, 기존 SQL Server 지식을 그대로 쓸 수 있습니다. Cosmos DB는 문서, 키-값, 그래프 같은 비관계형 모델을 다루면서 글로벌 분산과 밀리초 단위 지연 시간을 우선합니다. 따라서 스키마가 자주 바뀌거나, 여러 리전에서 동시에 낮은 지연으로 읽기/쓰기가 필요하거나, 대규모 비정형 데이터를 다룬다면 Cosmos DB 쪽이 맞습니다. 반대로 트랜잭션 정합성이 우선이고 데이터 관계가 복잡하며 기존 SQL 기반 코드를 활용해야 한다면 SQL Database가 적합합니다.

Azure SQL Database는 주문 처리, 사용자 인증, 재고 관리처럼 데이터 정합성이 핵심인 트랜잭션 워크로드에 가장 자연스럽게 들어갑니다. SaaS 제품을 만드는 팀이라면 탄력적 풀로 테넌트마다 별도 DB를 두되 리소스를 공유하는 구조를 자주 씁니다. 읽기 복제본을 붙이면 대시보드나 보고서 쿼리가 운영 DB에 영향을 주지 않습니다. 반면 스키마가 아직 정해지지 않았거나 자주 바뀌는 초기 프로토타이핑 단계, 또는 수십 TB 이상의 비정형 로그를 저장해야 하는 경우에는 관계형 모델이 오히려 제약이 될 수 있습니다. 또한 SQL Server 고유 기능 중 일부(에이전트 작업, CLR 확장 등)는 PaaS에서 지원되지 않으므로 마이그레이션 전에 호환성을 확인해야 합니다.

다음에 볼 개념

함께 보면 좋은 개념