Azure SQL Database

팀이 처음 서버에 데이터베이스를 올릴 때는 쿼리만 잘 짜면 된다고 생각합니다. 그런데 실제 운영이 시작되면 다른 일이 기다리고 있습니다. OS 패치 주기를 지키지 않으면 보안 취약점이 쌓이고, 백업 스크립트가 조용히 실패하면 장애 당일에야 복구 불가 상태를 알게 됩니다. 스토리지가 차서 새벽 두 시에 알림이 오고, 고가용성 구성은 전문 DBA 없이는 제대로 검증하기 어렵습니다. 개발팀이 스키마 설계와 쿼리 최적화에 써야 할 시간이 인프라 유지보수로 새어 나가면서, 이 비용은 서비스 규모에 비례해 커집니다.

SQL Server를 온프레미스에서 운영하던 팀들은 오랫동안 Windows 업데이트, 스토리지 확장, 클러스터 장애 조치 테스트, 백업 검증을 반복했습니다. 이 작업들은 DBA 인력과 운영 예산을 꾸준히 소모했고, 클라우드로 이전해도 VM에 직접 설치하는 방식(IaaS)은 이 부담을 그대로 가져갔습니다. 기업들이 클라우드 전환을 가속하면서 SQL Server 호환성은 유지하되 패치, 백업, 고가용성, 스케일링을 플랫폼이 처리해 주는 방식에 대한 수요가 생겼습니다. Azure SQL Database는 SQL Server 엔진을 PaaS로 제공해 이 운영 책임의 상당 부분을 플랫폼 쪽으로 옮겼고, 기존 SQL Server 사용자에게는 같은 엔진, 다른 운영 모델로 받아들여집니다.

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

Azure SQL Database와 Cosmos DB는 둘 다 Azure의 관리형 데이터베이스이지만 설계 목표가 다릅니다. SQL Database는 관계형 스키마가 정해진 정형 데이터에 강하며, ACID 트랜잭션, 복잡한 JOIN, 외래 키 제약이 기본 기능입니다. 기존 SQL Server 지식과 코드를 그대로 가져올 수 있습니다. Cosmos DB는 스키마 유연성과 글로벌 분산 저지연을 우선합니다. 데이터 구조가 자주 바뀌거나 여러 리전에서 밀리초 단위 응답이 필요하다면 그쪽이 맞고, 데이터 간 관계가 복잡하고 트랜잭션으로 묶어야 하는 범위가 넓다면 SQL Database가 맞습니다. SQL Database가 맞지 않는 경우도 있습니다. 수십 TB 이상의 비정형 데이터, 스키마가 아직 확정되지 않은 프로토타이핑, SQL Server 에이전트 작업이나 CLR 확장처럼 PaaS에서 지원하지 않는 기능에 의존하는 워크로드는 이 서비스의 범위 밖입니다.

주문, 결제, 재고, 사용자 인증처럼 데이터 정합성이 핵심인 트랜잭션 워크로드를 운영하는 팀에서 자주 등장합니다. SaaS 제품을 만드는 팀이라면 탄력적 풀로 테넌트마다 독립된 DB를 두되 리소스를 공유하는 구조를 씁니다. 읽기 복제본을 붙이면 대시보드나 보고서 쿼리가 운영 DB 성능에 영향을 주지 않습니다. 도입을 검토할 신호는 이렇습니다. 팀이 DB 인프라 유지보수에 들이는 시간이 늘고 있거나, 온프레미스 SQL Server를 클라우드로 옮기면서 운영 부담을 줄이려는 상황이거나, 복수의 소형 DB가 각각 피크 시간대가 달라 리소스 낭비가 생기고 있다면 SQL Database와 탄력적 풀 조합을 살펴볼 시점입니다.