배포 옵션 설명
PaaS(서비스 제공 플랫폼)인 Azure SQL Database는 높은 확장성과 최소 유지 관리가 가능하므로 특정 워크로드에 적합한 탁월한 솔루션입니다. 새로운 애플리케이션 개발에 적합하여 개발자가 새로운 서비스를 빌드하는 데 상당한 유연성을 제공하고 규모에 맞춰 세부적인 배포 옵션을 제공합니다. 유지 관리가 간편한 이 솔루션은 다양한 워크로드에 적합하며 효율적이고 효과적인 애플리케이션 개발을 보장합니다.
배포 모델 이해
Azure SQL Database를 배포할 때 는 단일 데이터베이스 및 탄력적 풀이라는 두 가지 기본 배포 모델이 있습니다. 탄력적 풀 모델에서 리소스는 동일한 풀 내의 여러 데이터베이스에서 공유되는 반면, 단일 데이터베이스 모델에서는 리소스가 각 데이터베이스에서 독립적으로 관리됩니다.
SQL Database는 가상 머신과 마찬가지로 PowerShell, Azure CLI 또는 Azure Portal을 포함한 다양한 방법을 사용하여 배포할 수 있습니다.
단일 데이터베이스
단일 데이터베이스 배포 모델은 Azure SQL Database를 사용하는 가장 간단한 방법입니다. 이 모델에서는 규모와 데이터 크기 측면에서 각 데이터베이스를 개별적으로 관리합니다. 여러 데이터베이스가 동일한 논리 서버에 배포되어 있더라도 각 데이터베이스는 자체 전용 리소스를 갖습니다.
Azure Portal을 통해 각 데이터베이스의 리소스 사용률을 모니터링할 수 있습니다. 이 기능을 사용하면 데이터베이스 성능을 쉽게 추적하고 평가할 수 있습니다.
탄력적 풀
탄력적 풀을 사용하면 스토리지와 컴퓨팅 리소스를 데이터베이스 그룹에 할당하여 각 데이터베이스를 개별적으로 처리하는 것보다 관리가 간소화됩니다. 단일 데이터베이스보다 크기 조정하기가 더 쉽습니다. 탄력적 풀을 변경하면 포함된 모든 데이터베이스의 리소스가 자동으로 조정되기 때문입니다.
이 모델은 모든 데이터베이스에서 리소스를 공유하므로 서비스 제공 소프트웨어 애플리케이션에 비용 효율적입니다. DTU 기반 또는 vCore 기반 구매 모델을 사용하여 리소스를 구성할 수 있습니다.
풀에 있는 다른 데이터베이스에 영향을 줄 수 있는 성능 급증을 파악하기 위해 리소스를 지속적으로 모니터링해야 합니다. 정기적으로 할당 전략을 재검토하면 모든 데이터베이스에 충분한 리소스가 확보됩니다.
탄력적 풀은 각 테넌트가 자체 데이터베이스 복사본을 갖는 평균 사용률이 낮은 다중 테넌트 아키텍처에 이상적입니다.
구매 모델 이해
SQL Database에 적절한 배포 모델을 선택한 후 다음 단계는 워크로드와 예산 요구 사항에 가장 적절한 구매 모델을 선택하는 것입니다. Azure SQL Database는 vCore 모델과 DTU 기반 모델의 두 가지 구매 모델을 제공합니다. 각 모델마다 장점이 있으므로 워크로드 요구 사항과 비용 고려 사항에 가장 적합한 모델이 무엇인지 이해해야 합니다.
vCore 기반
이는 컴퓨팅 및 스토리지 리소스가 분리되는 권장 구매 모델입니다. 즉, 스토리지 및 컴퓨팅 리소스를 서로 독립적으로 스케일링할 수 있습니다. 이러한 유연성 덕분에 다른 구성 요소에 영향을 주지 않고 특정 요구 사항에 맞게 리소스를 조정할 수 있습니다.
vCore 기반 구매 모델에서 비용은 서비스 계층, 하드웨어 구성, vCore 수와 메모리 양, 예약된 데이터베이스 스토리지, 실제 백업 스토리지를 포함한 여러 가지 요인에 따라 달라집니다.
참고
가격 책정 세부 정보는 Azure SQL Database 가격 책정 페이지를 참조하세요.
서비스 계층은 데이터베이스의 성능, 스토리지 유형, 고가용성, 재해 복구 옵션, 특정 기능의 가용성을 결정하는 미리 정의된 구성입니다.
vCore 구매 모델은 세 가지 서비스 계층 옵션을 제공합니다.
| 서비스 계층 | 기능 |
|---|---|
| 범용 | 이 서비스 계층은 덜 집중적인 작업을 위해 설계되었으며 컴퓨팅 및 스토리지 옵션의 비용 효율적인 균형을 제공합니다. 여기에는 프로비저닝된 컴퓨팅 계층과 서버리스 컴퓨팅 계층이 모두 포함되어 있어 예산을 최적화하면서 다양한 워크로드 요구를 유연하게 충족할 수 있습니다. |
| 비즈니스에 중요한 | 이 계층은 낮은 대기 시간과 고성능 스토리지를 요구하는 애플리케이션에 이상적입니다. In-Memory OLTP를 지원하고 기본 제공 읽기 전용 복제본을 포함합니다. 또한 코어당 더 많은 메모리를 제공하고 로컬 SSD 스토리지를 사용하므로 성능이 중요한 워크로드에 이상적입니다. |
| 하이퍼스케일 | 이 계층은 대규모 데이터베이스와 높은 처리량 요구 사항이 있는 애플리케이션에 맞게 설계되었습니다. 하이퍼스케일 인은 고급 수평적 스케일 인 기능을 도입하여 데이터 크기가 증가함에 따라 컴퓨팅 노드를 추가할 수 있도록 합니다. 이 기능은 단일 SQL 데이터베이스에서만 지원되며 범용 및 중요 비즈니스용 서비스 계층의 제한을 넘어 스토리지 및 컴퓨팅 리소스를 크게 크기 조정할 수 있습니다. |
DTU 기반
DTU 모델에는 세 가지 서비스 계층 기본인 표준 및 프리미엄이 있습니다. 컴퓨팅 및 스토리지 리소스는 DTU 수준에 따라 달라지며, 고정된 저장 한도, 백업 보존 및 비용과 함께 다양한 성능 기능을 제공합니다.
예를 들어, 데이터베이스가 최대 저장 한도에 도달하면 컴퓨팅 사용률이 낮더라도 DTU 용량을 늘려야 합니다. 또한 Azure SQL Database에서 작업 크기를 조정하면 프로세스가 끝날 때 잠시 연결이 중단될 수 있습니다. 이 문제는 다음 두 가지 기본 시나리오에서 발생할 수 있습니다.
- 내부 장애 조치(failover)가 필요한 크기 조정 작업을 시작합니다.
- 탄력적 풀에 데이터베이스를 추가하거나 제거합니다.
참고
연결 오류를 처리하려면 애플리케이션에서 적절한 재시도 논리 를 구현합니다.
성능과 비용 효율성을 최적화하려면 배포와 구매 모델 간의 상호 작용을 이해해야 합니다. 올바른 조합을 신중하게 선택하면 예산 내에서 애플리케이션의 요구 사항을 충족하는 Azure SQL Database 배포가 가능합니다.
예를 들어, 단일 데이터베이스 배포 모델을 선택하는 경우 컴퓨팅 및 스토리지 리소스를 독립적으로 크기 조정할 수 있는 유연성을 갖춘 vCore 구매 모델을 선호할 수 있습니다. 반면, 탄력적 풀 배포 모델을 선택하는 경우 DTU 기반 구매 모델이 더 비용 효율적일 수 있습니다. 풀 내의 여러 데이터베이스에서 리소스를 공유할 수 있기 때문입니다.
백업 및 복원 수행
Azure는 SQL Database에 대한 원활한 백업 및 복원 기능을 제공합니다. 주요 기능은 다음과 같습니다.
지속적인 백업
Azure SQL Database는 정기적인 백업을 보장하고 이를 RA-GRS(읽기 액세스 지역 중복 스토리지)에 지속적으로 복사합니다. 전체 백업은 매주 수행되고, 차등 백업은 12~24시간마다 수행되며, 트랜잭션 로그 백업은 5~10분마다 수행됩니다.
지리적 복원
기본적으로 지역 중복 백업을 사용하면 데이터베이스를 다른 지역으로 쉽게 복원할 수 있으며, 이는 덜 엄격한 재해 복구 시나리오에 유용합니다. 백업 스토리지는 별도로 청구되지만 선택한 데이터 계층의 최대 크기로 추가 비용 없이 만들어집니다. 지역 복원 기간은 데이터베이스 크기, 트랜잭션 로그, 동시 복원 요청에 따라 달라집니다.
참고
지역 복원은 백업 스토리지 중복 속성이 지역 중복 백업 스토리지로 설정된 경우 사용할 수 있습니다.
PITR(특정 시점 복원)
각 데이터베이스에 대해 1~35일(기본값은 7일)까지 특정 시점 보존 정책을 구성할 수 있습니다. Azure Portal, PowerShell, CLI 또는 REST API를 사용하여 동일한 서버 내에서 특정 시점으로 데이터베이스를 복원할 수도 있습니다.
LTR(장기 보존)
장기 보존은 Azure에서 제공하는 기간 이상으로 보존 정책을 설정해야 하는 시나리오에 유용합니다. 최대 10년 동안 보존 정책을 설정할 수 있으며 이 옵션은 기본적으로 사용하지 않도록 설정되어 있습니다.
자동화된 백업에 대한 자세한 내용은 자동화된 백업 - Azure SQL Database 및 Azure SQL Managed Instance를 참조하세요.
자동 튜닝 사용
자동 튜닝은 기계 학습을 적용하여 쿼리 성능을 최적화하는 강력한 기본 제공 기능입니다. 이 기능은 자동으로 튜닝 기회를 식별하고 이를 구현하여 데이터베이스의 효율성을 향상합니다.
현재 자동 튜닝에는 다음과 같은 기능이 포함되어 있습니다.
- 비용이 많이 드는 쿼리 식별
- 마지막 유용한 실행 계획 강제 적용
- 인덱스 추가
- 인덱스 제거
Azure 서비스는 고급 알고리즘을 사용하여 쿼리 패턴에 가장 적합한 인덱스를 결정합니다. 이러한 인덱스는 실제 환경에 적용하기 전에 데이터베이스 복사본에서 먼저 테스트되므로 중단이 최소화됩니다.
모든 데이터베이스는 부모 서버로부터 구성을 상속받으며, 필요한 경우 이 기능을 쉽게 사용하지 않도록 설정할 수 있습니다. 이러한 유연성 덕분에 개발자는 자동화된 성능 향상의 이점을 누리는 동시에 제어력을 유지할 수 있습니다.
탄력적 쿼리 사용
탄력적 쿼리를 사용하면 SQL Database의 여러 데이터베이스에서 T-SQL 쿼리를 실행할 수 있습니다. 이 기능은 변경할 수 없는 세 부분과 네 부분으로 구성된 이름을 사용하는 애플리케이션에 유용하며, 마이그레이션을 용이하게 하여 이식성을 높여줍니다.
탄력적 쿼리는 다음과 같은 분할 시나리오를 지원합니다.
| 서비스 계층 | 기능 |
|---|---|
| 수직 분할 | 데이터베이스 간 쿼리라고도 합니다. 데이터는 서로 다른 스키마를 가진 여러 데이터베이스에 수직으로 분할됩니다. 예를 들어, 고객 데이터를 위한 데이터베이스가 하나 있고, 결제 정보를 위한 데이터베이스가 또 하나 있을 수 있습니다. 수직 분할을 사용하면 이러한 데이터베이스 간에 데이터베이스 간 쿼리를 실행할 수 있습니다. |
| 가로 분할 | 분할이라고도 불립니다. 데이터는 행으로 분할되어 여러 개의 크기 조정된 데이터베이스에 행이 분산되며, 모두 동일한 스키마를 공유합니다. 이 토폴로지는 단일 테넌트 및 다중 테넌트 모델을 모두 지원합니다. |
이러한 유연성 덕분에 탄력적 쿼리는 여러 데이터베이스에서 데이터를 관리하고 쿼리하는 강력한 도구가 됩니다.
탄력적 작업 구성
탄력적 작업 기능은 온-프레미스 SQL Server 인스턴스의 다중 서버 관리 기능과 유사하게 Azure SQL Database에 대한 SQL Server 에이전트 대체 기능으로 사용됩니다.
탄력적 작업을 사용하면 SQL Database, SQL Database 탄력적 풀, 분할 맵의 SQL Database 등 다양한 대상 배포에서 T-SQL 명령을 실행할 수 있습니다. 이러한 데이터베이스 리소스는 여러 Azure 구독 및 지역에 걸쳐 있을 수 있습니다. 병렬 실행 기능은 데이터베이스 유지 관리 작업을 자동화하고 배포 전반에서 효율성과 일관성을 보장하는 데 유용합니다.
SQL 데이터 동기화를 사용하여 데이터 이동
SQL 데이터 동기화 를 사용하면 SQL Database 또는 온-프레미스 SQL Server에서 실행 중이든 간에 여러 데이터베이스에서 데이터를 증분 동기화할 수 있습니다. 이 기능은 분석이나 계획되지 않은 작업을 위해 집약적인 프로덕션 워크로드를 별도의 데이터베이스로 오프로드하는 데 유용합니다.
데이터 동기화는 허브 토폴로지에서 작동합니다. 즉, 동기화 그룹의 한 데이터베이스가 허브로 지정됩니다. 동기화 그룹에는 여러 개의 멤버 데이터베이스가 포함될 수 있으며, 허브와 개별 멤버 데이터베이스 간에 동기화가 수행됩니다. 변경 내용은 사용자 데이터베이스에 만들어진 기록 테이블을 통해 삽입, 업데이트 및 삭제 트리거를 사용하여 추적됩니다.
동기화 그룹을 만들 때 동기화 그룹 메타데이터를 저장할 데이터베이스를 지정해야 합니다. 이 메타데이터 데이터베이스는 동기화 그룹과 동일한 지역에 있는 한 새 것이거나 기존 것이 될 수 있습니다.
SQL 데이터 동기화를 구성하는 방법에 대한 자세한 내용은 자습서: Azure SQL Database와 SQL Server의 데이터베이스 간에 SQL 데이터 동기화 설정 자습서를 참조하세요.