Azure SQL Database 하이퍼스케일 FAQ

하이퍼스케일 데이터베이스는 하이퍼스케일 스케일 아웃 스토리지 기술로 지원되는 SQL Database의 데이터베이스입니다. 하이퍼스케일 데이터베이스는 최대 128TB의 데이터를 지원하며 높은 처리량과 성능뿐만 아니라 워크로드 요구 사항에 맞게 신속하게 크기를 조정합니다. 연결, 쿼리 처리, 데이터베이스 엔진 기능 등은 Azure SQL 데이터베이스의 다른 데이터베이스와 마찬가지로 작동합니다.

하이퍼스케일 서비스 계층은 Azure SQL Database의 vCore 기반 구매 모델을 사용하는 단일 데이터베이스에만 사용할 수 있습니다. DTU 기반 구매 모델에서는 사용할 수 없습니다.

vCore 기반 서비스 계층은 리소스 제한 비교에 설명된 데이터베이스 가용성 및 스토리지 형식, 성능 및 최대 스토리지 크기에 따라 차별화됩니다.

하이퍼스케일 서비스 계층은 더 높은 성능 및 가용성, 빠른 백업 및 복원, 빠른 스토리지 및 컴퓨팅 스케일링 성능이 필요한 모든 고객을 위한 것입니다. 여기에는 소규모로 시작하여 성장하는 고객, 대규모 중요 업무용 데이터베이스를 실행하는 고객, 애플리케이션을 현대화하기 위해 클라우드로 이동하는 고객과 이미 Azure SQL 데이터베이스의 다른 서비스 계층을 사용하고 있는 고객이 포함됩니다. 하이퍼스케일을 통해 얻을 수 있는 사항:

• 10GB에서 128TB까지 확장할 수 있는 데이터베이스 크기입니다.
• 2개의 vCore에서 최대 128개의 vCore에 이르는 vCore 리소스 컴퓨팅.
• 데이터베이스 크기에 관계없이 빠른 데이터베이스 백업(백업은 스토리지 스냅샷을 기반으로 함).
• 데이터베이스 크기에 관계없이 빠른 데이터베이스 복원(복원은 스토리지 스냅샷에서 수행됨).
• 데이터베이스 크기 및 vCore 수에 관계없이 더 높은 로그 처리량.
• 읽기 전용 워크로드 오프로드 또는 상시 대기 데이터베이스로 사용되는 읽기 전용 복제본을 하나 이상 사용하여 읽기 확장합니다.
• 일정 시간에 컴퓨팅 스케일링이 신속하게 확장되어, 강력한 기능으로 과도한 워크로드를 수용하고 일정 시간에 규모를 축소할 수 있습니다. 크기 조정 작업은 프로비전된 컴퓨팅의 경우 한 자릿수 분, 데이터베이스 크기에 관계없이 서버리스 컴퓨팅의 경우 1초 미만이 걸립니다.
• 사용량에 따라 컴퓨팅 요금이 청구되는 서버리스 컴퓨팅에 사용하는 비용을 지불하는 옵션.

하이퍼스케일 서비스 계층은 Azure SQL Database를 사용할 수 있는 모든 지역에서 사용할 수 있습니다.

예. 서버별 데이터베이스 수에 대한 제한과 자세한 내용은 서버의 단일 및 풀링된 데이터베이스에 대한 SQL Database 리소스 제한을 참조하세요.

하이퍼스케일 아키텍처는 대규모 데이터베이스 크기를 지원하는 동시에 높은 성능과 처리량을 제공합니다.

하이퍼스케일은 워크로드 요구 사항에 따라 빠른 확장성을 제공합니다.

• 강화/축소

  하이퍼스케일을 사용하면 CPU, 메모리 등의 리소스 측면에서 기본 컴퓨팅 크기를 스케일 업한 다음, 일정 시간 내에 스케일 다운할 수 있습니다. 스토리지가 원격이기 때문에 강화와 축소는 데이터 작업의 크기가 아닙니다.

  서버리스 컴퓨팅 지원은 스케일 업 및 스케일 다운을 제공하며 컴퓨팅 요금은 사용량에 따라 청구됩니다.

• 규모 감축/확장

  하이퍼스케일을 사용하면 세 가지 종류의 보조 복제본을 사용하여 읽기 확장, 고가용성 및 지역 복제 요구 사항을 충족할 수 있습니다. 다음 내용이 포함됩니다.

  • 주 복제본과 동일한 컴퓨팅 크기를 갖는 최대 4개의 고가용성 복제본. 이는 주 복제본에서 신속하게 장애 조치(failover)를 하는 상시 대기 복제본(replica) 역할을 합니다. 기본 워크로드에서 읽기 워크로드를 오프로드하는 데 사용할 수도 있습니다.
  • 주 복제본과 동일하거나 다른 컴퓨팅 크기를 갖는 최대 30개의 명명된 복제본(replica)을 통해 다양한 읽기 확장 시나리오를 충족합니다.
  • 지역적 중단으로부터 보호하고 지리적 읽기 스케일 아웃을 사용하도록 설정하는 다른 Azure 지역의 지역 복제본 입니다.

예, 할 수 있습니다.

아니요. 애플리케이션 프로그래밍 모델은 다른 MSSQL 데이터베이스와 동일하게 유지됩니다. 평소와 같이 연결 문자열을 사용하고, 하이퍼스케일 데이터베이스와 상호 작용하는 다른 일반적인 방법을 사용합니다. 애플리케이션에서 하이퍼스케일 데이터베이스를 사용하면 보조 복제본과 같은 기능을 활용할 수 있습니다.

주 복제본에서 기본 트랜잭션 격리 수준은 RCSI(Read Committed 스냅샷 격리)입니다. 읽기 확장 보조 복제본에서 기본 격리 수준은 스냅샷입니다. 이는 다른 Azure SQL DB 데이터베이스와 동일합니다.

2023년 12월 15일부터 새로운 간소화된 가격 책정이 적용되어 새로 만든 하이퍼스케일 데이터베이스, 모든 서버리스 하이퍼스케일 데이터베이스 및 모든 하이퍼스케일 Elastic Pool에 대한 컴퓨팅 가격이 인하되었습니다. 새롭고 간소화된 가격 책정을 사용하면 동등한 절감액을 얻기 위해 AHB(Azure 하이브리드 혜택)를 적용할 필요가 없습니다. AHB(Azure 하이브리드 혜택)는 프로비전된 컴퓨팅을 사용하여 이전(2023년 12월 15일 이전에 생성) 하이퍼스케일 단일 데이터베이스에만 적용할 수 있습니다. 이전 데이터베이스의 경우 AHB는 2026년 12월까지만 적용되며, 그 후에는 간소화된 새로운 가격 책정에 따라 해당 데이터베이스도 요금이 청구됩니다. 자세한 내용은 하이퍼스케일 가격 책정 블로그 및 Azure SQL 데이터베이스 하이퍼스케일 – 더 낮고 간소화된 가격 책정!을 참조하세요.

하이퍼스케일은 OLTP, 하이브리드(HTAP) 및 분석(데이터 마트) 워크로드를 포함한 모든 워크로드 유형에 잘 작동합니다.

현재 SQL Server를 데이터 웨어하우스로 사용하여 대화형 분석 쿼리를 실행하는 경우 하이퍼스케일은 더 저렴한 비용으로 중소 규모의 데이터 웨어하우스(예: 몇 TB에서 최대 128TB)를 호스트할 수 있고 최소한의 T-SQL 코드 변경으로 SQL Server 데이터 웨어하우스 워크로드를 하이퍼스케일로 마이그레이션할 수 있기 때문에 좋은 옵션입니다.

복잡한 쿼리 및 지속적인 수집 속도가 100MB/s보다 높거나 PDW(병렬 데이터 웨어하우스), Teradata 또는 Azure Synapse Analytics와 같은 기타 MPP(대규모 병렬 처리) 데이터 웨어하우스를 사용하여 대규모로 데이터 분석을 실행하는 경우 Microsoft Fabric이 가장 적합한 선택이 될 수 있습니다.

150MB/s의 수집 또는 로그 생성 속도는 옵트인 미리 보기 기능으로 사용할 수 있습니다. 자세한 내용 및 150MB/s에 옵트인하려면 블로그: 2024년 11월 하이퍼스케일 개선 사항을 참조 하세요.

현재는 불가능합니다. 그러나 컴퓨팅 및 복제본(replica) 수를 줄여 불필요한 시간 동안 비용을 줄이거나 서버리스를 사용하여 사용량에 따라 컴퓨팅 크기를 자동으로 조정할 수 있습니다.

읽기 워크로드의 경우 주 복제본보다 더 큰 컴퓨팅 크기(더 많은 코어 및 메모리)를 사용하여 명명된 복제본(replica)을 만들 수 있습니다. 사용 가능한 컴퓨팅 크기에 대한 자세한 내용은 하이퍼스케일 스토리지 및 컴퓨팅 크기를 참조하세요.

읽기 워크로드의 경우 명명된 복제본을 사용하여 이 작업을 수행할 수 있습니다.

Azure Portal 또는 REST API를 사용하여 HA 보조 복제본 수를 0~4에서 스케일링할 수 있습니다. 또한 많은 읽기 스케일 아웃 시나리오에 대해 최대 30개의 명명된 복제본을 만들 수 있습니다.

하이퍼스케일 데이터베이스에서 데이터 복원력은 스토리지 수준에서 제공됩니다. 복원력을 제공하려면 하나의 복제본(주 복제본)만 있으면 됩니다. 컴퓨팅 복제본이 다운되면 데이터가 손실되지 않고 새로운 복제본이 자동으로 생성됩니다.

그러나 주 복제본만 있는 경우 장애 조치(failover) 후 새 복제본(replica)을 만드는 데 1~2분이 걸리지만, HA 보조 복제본을 사용할 수 있는 경우는 몇 초면 가능합니다. 새 복제본에는 처음에 콜드 캐시가 있으므로 장애 조치(failover) 직후 스토리지 대기 시간이 늘어나고 쿼리 성능이 저하될 수 있습니다.

장애 조치(failover) 영향의 최소화와 고가용성을 요구하는 중요 업무용 앱의 경우 상시 대기 복제본(replica)을 장애 조치(failover) 대상으로 사용할 수 있도록 하려면 하나 이상의 HA 보조 복제본을 프로비저닝해야 합니다.

단일 하이퍼스케일 데이터베이스의 최대 크기는 현재 128TB입니다. 하이퍼스케일 탄력적 풀에 있는 데이터베이스의 최대 크기는 현재 100TB입니다.

하이퍼스케일에서 트랜잭션 로그는 실질적으로 무한하며, 로그의 활성 부분이 1TB를 초과할 수 없다는 제한이 있습니다. 장기 실행 트랜잭션 또는 변경 데이터 캡처 처리가 데이터 변경 속도를 따라가지 않기 때문에 로그의 활성 부분이 증가할 수 있습니다. 이 제한을 초과하지 않도록 불필요하게 길고 큰 트랜잭션을 사용하지 마세요. 이 제한 이외에 로그 처리량이 많은 시스템에서는 로그 공간 부족을 걱정할 필요가 없습니다. 그러나 지속적이고 공격적인 쓰기 워크로드의 경우 로그 생성 속도가 제한될 수 있습니다. 최대 지속 로그 생성 속도는 100MB/s입니다.

로그 생성 속도 150MB/s는 옵트인 미리 보기 기능으로 사용할 수 있습니다. 자세한 내용 및 150MB/s에 옵트인하려면 블로그: 2024년 11월 하이퍼스케일 개선 사항을 참조 하세요.

tempdb 데이터베이스는 로컬 SSD 스토리지에 있으며 프로비저닝하는 컴퓨팅 크기(코어 수)에 비례하여 크기가 조정됩니다. tempdb 크기는 구성할 수 없으며 사용자를 대신하여 관리됩니다. 데이터베이스의 최대 tempdb 크기를 결정하려면 tempdb를 참조하세요.

데이터베이스 크기는 데이터를 추가로 삽입/수집하면 자동으로 커집니다.

10GB. 하이퍼스케일 데이터베이스는 시작 크기가 10GB로 만들어지고 필요에 따라 10GB 청크 단위로 증가합니다.

각 데이터 파일은 10GB씩 증가합니다. 여러 데이터 파일이 동시에 늘릴 수 있습니다.

하이퍼스케일에서 데이터 파일은 Azure 표준 스토리지에 저장됩니다. 데이터는 컴퓨팅 복제본에 원격인 페이지 서버의 로컬 SSD 스토리지에 완전히 캐시됩니다. 또한 원격 페이지 서버에서 데이터를 가져오는 빈도를 줄이기 위해 컴퓨팅 복제본에는 데이터 캐시가 로컬 SSD와 메모리에 있습니다.

아니요. 데이터 파일은 PRIMARY 파일 그룹에 자동으로 추가됩니다. 추가 파일 그룹을 만드는 일반적인 이유는 하이퍼스케일 스토리지 아키텍처나 더 넓게는 Azure SQL Database에 적용되지 않습니다.

아니요.

예, 데이터베이스 및 파일 축소 작업은 현재 프리뷰로 제공됩니다. 미리 보기에 대한 자세한 내용은 Azure SQL Database 하이퍼스케일에 대한 축소를 참조하세요.

예. 다른 Azure SQL DB 데이터베이스와 같습니다. 행, 페이지, columnstore 압축 등이 포함됩니다.

예. 주어진 테이블과 연결된 데이터 페이지는 모두 동일한 파일 그룹에 속하는 여러 데이터 파일에 분산될 수 있습니다. MSSQL 데이터베이스 엔진은 비례하여 채우기 전략을 사용하여 여러 데이터 파일에 데이터를 분산합니다.

예. Azure SQL Database의 기존 데이터베이스를 하이퍼스케일로 이동할 수 있습니다. POC(개념 증명)의 경우 데이터베이스의 복사본을 만들고, 이 복사본을 하이퍼스케일로 마이그레이션하는 것이 좋습니다.

기존 데이터베이스를 하이퍼스케일로 이동하는 데 필요한 시간은 데이터를 복사하는 시간과 데이터를 복사하는 동안 원본 데이터베이스의 변경 내용을 재생하는 시간으로 구성됩니다. 데이터 복사 시간은 데이터 크기에 비례합니다. 쓰기 작업이 적은 기간 동안 이동이 수행되면 변경 내용을 재생하는 시간이 짧아집니다.

기존 데이터베이스를 하이퍼스케일로 마이그레이션할 때 Azure Portal, Azure CLI, PowerShell 및 Transact-SQL에서 기존 Azure SQL Database를 하이퍼스케일로 마이그레이션하는 샘플 코드를 가져옵니다.

범용 서비스 계층으로의 역방향 마이그레이션을 사용하면 하이퍼스케일이 요구 사항을 충족하지 않을 경우 최근에 Azure SQL Database 기존 데이터베이스를 하이퍼스케일 서비스 계층으로 마이그레이션한 고객이 다시 이동할 수 있습니다. 역방향 마이그레이션은 서비스 계층 변경에 의해 시작되지만 기본적으로 서로 다른 아키텍처 간에 데이터 크기 작업입니다. 하이퍼스케일로 마이그레이션하는 것과 마찬가지로 쓰기 작업이 적은 기간 동안 수행하면 역방향 마이그레이션이 더 빨라집니다. 역방향 마이그레이션에 대한 제한 사항에 대해 알아봅니다.

이전에 기존 Azure SQL Database를 하이퍼스케일 서비스 계층으로 마이그레이션한 경우 원래 하이퍼스케일로 마이그레이션한 후 45일 이내에 이를 범용 서비스 계층으로 역방향 마이그레이션할 수 있습니다. 데이터베이스를 중요 비즈니스용과 같은 다른 서비스 계층으로 마이그레이션하려면 먼저 범용 서비스 계층으로 역방향 마이그레이션한 다음 서비스 계층을 수정합니다. 역방향 마이그레이션은 데이터 작업의 크기입니다.

하이퍼스케일 서비스 계층에서 만든 데이터베이스는 다른 서비스 계층으로 이동할 수 없습니다.

역방향 마이그레이션에 대한 제한 사항 및 영향을 받는 백업 정책을 포함하여 하이퍼스케일에서 역방향 마이그레이션하는 방법을 알아보세요.

예. 일부 Azure SQL Database 기능은 하이퍼스케일에서 아직 지원되지 않습니다. 이러한 기능 중 일부를 데이터베이스에 사용하도록 설정하면 하이퍼스케일로의 마이그레이션이 차단되거나 마이그레이션 후 이러한 기능이 작동하지 않을 수 있습니다. 이러한 제한은 일시적일 것으로 간주됩니다. 자세한 내용은 알려진 제한 사항을 참조하세요.

예. 트랜잭션 복제와 기타 데이터 이동 기술(대량 복사, Azure Data Factory, Azure Databricks, SSIS)을 비롯한 많은 기존 마이그레이션 기술을 사용하여 하이퍼스케일로 마이그레이션할 수 있습니다. 다양한 마이그레이션 시나리오를 지원하는 Azure Database Migration Service도 참조하세요.

하이퍼스케일로 마이그레이션하기 위한 가동 중지 시간은 데이터베이스를 다른 Azure SQL Database 서비스 계층으로 마이그레이션할 때의 가동 중지 시간과 동일합니다. 트랜잭션 복제를 사용하면 크기가 최대 몇 TB에 이르는 데이터베이스의 마이그레이션 가동 중지 시간을 최소화할 수 있습니다. 매우 큰 데이터베이스(10 TB 이상)의 경우 ADF, Spark 또는 기타 대량 데이터 이동 기술을 사용하여 마이그레이션 프로세스를 구현하는 것이 좋습니다.

하이퍼스케일은 100MB/s의 새 데이터 또는 변경된 데이터를 사용할 수 있지만, 데이터를 Azure SQL Database의 데이터베이스로 이동하는 데 필요한 시간은 사용 가능한 네트워크 처리량, 원본 읽기 속도 및 대상 데이터베이스 서비스 수준 목표의 영향도 받습니다. 로그 생성 속도 150MB/s는 옵트인 미리 보기 기능으로 사용할 수 있습니다. 자세한 내용 및 150MB/s에 옵트인하려면 블로그: 2024년 11월 하이퍼스케일 개선 사항을 참조 하세요.

Azure SQL Database의 다른 데이터베이스와 마찬가지로 클라이언트 애플리케이션에서 Azure Storage로부터 데이터를 읽고 데이터 로드를 하이퍼스케일 데이터베이스로 로드하도록 할 수 있습니다. Polybase는 현재 Azure SQL Database에서 지원되지 않습니다. 빠른 로드를 제공하는 대신, Azure Data Factory를 사용하거나 SQL용 Spark 커넥터를 사용하여 Azure Databricks에서 Spark 작업을 사용할 수 있습니다. SQL에 대한 Spark 커넥터는 대량 삽입을 지원합니다.

또한 BULK INSERT 또는 OPENROWSET(Azure Blob Storage 데이터에 대한 대량 액세스 예제)를 사용하여 Azure Blob Storage에서 데이터를 대량으로 읽을 수도 있습니다.

하이퍼스케일에서는 단순 복구 또는 대량 로깅 모델이 지원되지 않습니다. 고가용성 및 지정 시간 복구를 제공하려면 전체 복구 모델이 필요합니다. 그러나 하이퍼스케일 로그 아키텍처는 다른 Azure SQL Database 서비스 계층에 비해 더 나은 데이터 수집 속도를 제공합니다.

아니요. 하이퍼스케일은 SMP(대칭 다중 처리) 아키텍처이며, MPP(대규모 병렬 처리) 또는 다중 마스터 아키텍처가 아닙니다. 여러 개의 복제본을 만들어서 읽기 전용 워크로드 규모 확장할 수만 있습니다.

예. Azure Database Migration Service는 다양한 마이그레이션 시나리오를 지원합니다.

Azure SQL Database에 대한 SLA를 참조하세요. 중요한 워크로드에는 HA 보조 복제본을 추가하는 것이 좋습니다. 이렇게 하면 더 빠른 장애 조치(failover)가 제공되고 장애 조치 직후에 잠재적인 성능 영향을 줄일 수 있습니다.

예.

예, 하이퍼스케일은 영역 중복 구성을 지원합니다. 하이퍼스케일의 영역 중복 구성을 사용하도록 설정하려면 1개 이상의 HA 보조 복제본이 필요하며 영역 중복 또는 지역 영역 중복 스토리지를 사용해야 합니다.

예. 자세한 내용은 하이퍼스케일 Elastic Pool 및 블로그: 하이퍼스케일 Elastic Pool 일반 공급 을 참조하세요.

하이퍼스케일 데이터베이스에는 기존의 전체, 차등 및 트랜잭션 로그 백업이 없습니다. 대신 데이터 파일의 일반 스토리지 스냅샷이 있으며 각 파일에 대해 별도의 스냅샷 주기가 있습니다. 생성된 트랜잭션 로그는 구성된 보존 기간 동안 그대로 보존됩니다. 복원 시 관련 트랜잭션 로그 레코드가 복원된 스토리지 스냅샷에 적용됩니다. 스냅샷 주기에 관계없이 보존 기간 내에 특정 시점을 기준으로 데이터 손실 없이 트랜잭션 측면에서 일관된 데이터베이스를 유지할 수 있습니다. 실제로 하이퍼스케일의 데이터베이스 백업은 연속됩니다.

예.

특정 시점 복원에 대한 RPO는 0분입니다. 대부분의 특정 시점 복원 작업은 데이터베이스 크기와 관계없이 60분 이내에 완료됩니다. 더 큰 데이터베이스의 경우 복원 시간이 더 길어질 수 있으며, 복원 시점 이전 및 복원 시점까지 데이터베이스에서 상당한 쓰기 작업이 발생했을 수 있습니다. 복원을 실행할 때 스토리지 중복성을 변경하면 복원이 데이터 크기이므로 복원 시간이 데이터베이스 크기에 비례하여 복원 시간이 길어질 수 있습니다.

아니요. 백업은 스토리지 하위 시스템에서 관리하며, 스토리지 스냅샷을 사용합니다. 사용자 워크로드에는 영향을 주지 않습니다.

예. 지역 중복 스토리지를 사용하는 경우 지역 복원이 완전히 지원됩니다. 이것은 새 데이터베이스의 기본값입니다. 특정 시점 복원과 달리 지역 복원에는 데이터 크기 작업이 필요합니다. 데이터 파일은 병렬로 복사되므로 이 작업의 기간은 주로 전체 데이터베이스 크기가 아니라 데이터베이스에서 가장 큰 파일의 크기에 따라 달라집니다. 원본 데이터베이스의 지역과 쌍을 이루는 Azure 지역에서 데이터베이스를 복원하는 경우 지역 복원 시간이 훨씬 짧아집니다.

예. 하이퍼스케일 데이터베이스에 대해 지역 복제를 설정할 수 있습니다.

아니요. 하이퍼스케일 데이터베이스의 스토리지 형식은 SQL Server의 릴리스 버전과 다르며 백업을 제어하거나 액세스할 수 없습니다. 하이퍼스케일 데이터베이스에서 데이터를 가져오기 위해 Azure Data Factory, Azure Databricks, SSIS 등과 같은 데이터 이동 기술을 사용하여 데이터를 추출할 수 있습니다.

예. 2022년 5월 4일부터 모든 새 데이터베이스에 대한 백업은 Azure SQL 데이터베이스 가격 책정 페이지에 나와 있는 요율로 사용된 백업 스토리지 및 선택한 스토리지 중복성에 따라 요금이 청구됩니다. 2022년 5월 4일 이전에 만든 하이퍼스케일 데이터베이스의 경우 백업 보존 기간이 7일보다 큰 경우에만 백업 요금이 청구됩니다. 자세한 내용은 하이퍼스케일 백업 및 스토리지 중복성을 참조하세요.

백업 스토리지 크기를 측정하는 방법에 대한 세부 정보는 자동화된 백업에 나와 있습니다.

백업 스토리지 요금을 결정하는 방법은 백업 스토리지 크기를 주기적으로 계산하고, 여기에 백업 스토리지 요율과 마지막 계산 이후의 시간 수를 곱하는 것입니다. 일정 기간 동안 백업 요금을 예측하려면 해당 기간의 매시간 청구 가능한 백업 스토리지 크기에 백업 스토리지 요율을 곱하고 모든 시간당 금액을 더합니다. 프로그래밍 방식으로 여러 시간 간격에 대한 관련 Azure Monitor 메트릭을 쿼리하려면 Azure Monitor REST API를 사용합니다. 서버리스 컴퓨팅 계층의 백업 청구는 프로비전된 컴퓨팅 계층과 동일합니다.

데이터베이스에서 대량의 데이터를 추가, 수정 또는 삭제하는 워크로드의 경우 백업 비용이 더 높습니다. 반대로 대부분 읽기 전용인 워크로드의 백업 비용은 더 적을 수 있습니다.

백업 스토리지 비용을 최소화하는 방법에 대한 자세한 내용은 자동화된 백업에 나와 있습니다.

현재 하이퍼스케일이 아닌 서비스 계층(표준/프리미엄/범용/중요 비즈니스용) 백업은 하이퍼스케일 서비스 계층으로 지역 복원할 수 없으며 그 반대의 경우도 마찬가지입니다. 하이퍼스케일이 아닌 데이터베이스를 하이퍼스케일 데이터베이스로 변환하려면 복원 후 서비스 계층을 변경합니다.

트랜잭션 로그 처리량 상한은 하이퍼스케일 컴퓨팅 크기에 대해 100MB/s로 설정됩니다. 이 속도의 달성 여부는 여러 요인에 따라 달라집니다. 워크로드 유형, 클라이언트 구성 및 성능, 이 속도로 로그 기록을 생성할 수 있는 주 컴퓨팅 복제본(replica)의 충분한 컴퓨팅 용량이 포함되지만 이에 국한되지 않습니다. 로그 생성 속도 150MB/s는 옵트인 미리 보기 기능으로 사용할 수 있습니다. 자세한 내용 및 150MB/s에 옵트인하려면 블로그: 2024년 11월 하이퍼스케일 개선 사항을 참조 하세요.

IOPS 및 IO 대기 시간은 워크로드 패턴에 따라 달라집니다. 액세스 중인 데이터가 컴퓨팅 복제본의 RBPEX에 캐시되는 경우 중요 비즈니스용 또는 프리미엄 서비스 계층에서와 유사한 IO 성능을 볼 수 있습니다.

아니요. 컴퓨팅은 스토리지 계층에서 분리됩니다. 이렇게 하면 백업의 성능 영향이 제거됩니다.

스토리지가 공유되고 주 및 보조 컴퓨팅 복제본 간에 직접적인 물리적 복제가 발생하지 않으므로 보조 복제본을 추가해도 주 복제본의 처리량에 직접적인 영향을 주지 않습니다. 하지만 주 복제본에 대한 지속적이며 공격적인 쓰기 워크로드를 제한하여 보조 복제본과 페이지 서버에서 로그 적용이 따라잡도록 할 수 있습니다. 이렇게 하면 보조 복제본에서 읽기 성능이 저하되고 장애 조치(failover) 후 HA 보조 복제본으로 복구되는 시간이 길어지는 것을 방지할 수 있습니다.

예. 그러나 다른 Azure SQL DB 데이터베이스와 마찬가지로 매우 드문 일시적인 오류로 인해 연결이 종료되어 장기 실행 쿼리를 중단하고 트랜잭션을 롤백하게 될 수 있습니다. 일시적인 오류의 한 가지 원인은 시스템이 지속적인 컴퓨팅 및 스토리지 리소스 가용성을 보장하거나 계획된 유지 관리를 수행하기 위해 데이터베이스를 다른 컴퓨팅 노드로 신속하게 이동할 때 입니다. 이러한 재구성 이벤트는 10초 이내에 완료됩니다. 데이터베이스에 연결하는 애플리케이션은 재시도 로직을 구현하여 이러한 드문 일시적인 오류를 예상하고 허용하도록 빌드해야 합니다. 또한 계획된 유지 관리로 인한 일시적인 오류를 방지하기 위해 워크로드 일정과 일치하는 유지 관리 기간을 구성하는 것이 좋습니다.

대부분의 성능 문제, 특히 스토리지 성능과 관련이 없는 문제에는 일반적인 SQL 진단 및 문제 해결 단계가 적용됩니다. 하이퍼스케일과 관련된 스토리지 진단은 SQL 하이퍼스케일 성능 문제 해결 진단을 참조하세요.

서버리스 데이터베이스가 확장할 수 있는 최대 메모리 양은 프로비전된 컴퓨팅에서 동일한 수의 vCore 수보다 5GB/vCore를 초과하는 경우와 비교하여 구성된 최대 vCore 수의 3GB/vCore 배입니다. 자세한 내용은 서버리스 하이퍼스케일 리소스 제한을 검토하세요.

데이터 크기에 관계없이 프로비전된 컴퓨팅에서 스케일 업 또는 스케일 다운하는 데 일반적으로 최대 2분이 걸립니다. 워크로드 수요에 따라 컴퓨팅의 크기가 자동으로 조정되는 서버리스 컴퓨팅 계층에서 크기 조정 시간은 일반적으로 1초 미만이지만 프로비전된 컴퓨팅의 크기를 조정하는 데는 시간이 오래 걸릴 수 있습니다.

아니요. 데이터베이스는 스케일 업 또는 스케일 다운 작업 중에 온라인 상태로 유지됩니다.

프로비전된 컴퓨팅을 스케일링 업 또는 다운하면 스케일링 작업이 끝날 때 장애 조치(failover)가 발생하는 경우 기존 연결이 끊깁니다. 서버리스 컴퓨팅에서 자동 크기 조정은 일반적으로 연결을 삭제하지 않지만 가끔 발생할 수 있습니다. 보조 복제본을 추가하거나 제거해도 주 복제본에서 연결이 끊어지지 않습니다.

프로비전된 컴퓨팅의 크기 조정은 최종 사용자가 수행합니다. 서버리스 컴퓨팅의 자동 크기 조정은 서비스에서 수행됩니다.

예. 컴퓨팅 노드의 tempdb 데이터베이스 및 RBPEX 캐시 크기는 코어 수가 증가함에 따라 자동으로 스케일 업됩니다. 자세한 내용은 하이퍼스케일 스토리지 및 컴퓨팅 크기를 참조하세요.

아니요. 주 컴퓨팅 복제본만 읽기/쓰기 요청을 수락합니다. 보조 컴퓨팅 복제본은 읽기 전용 요청만 수락합니다.

하이퍼스케일은 HA(고가용성) 복제본, 명명된 복제본 및 지역 복제본을 지원합니다. 자세한 내용은 하이퍼스케일 보조 복제본을 참조하세요.

0에서 4 사이 복제본 수를 조정하려면 Azure Portal 또는 REST API를 사용하여 조정할 수 있습니다.

연결 문자열의 ApplicationIntent 속성을 ReadOnly로 설정하여 이러한 추가 읽기 전용 컴퓨팅 복제본에 연결할 수 있습니다. ReadOnly로 표시된 모든 연결이 있는 경우 HA 보조 복제본 중 하나로 자동으로 라우팅됩니다. 자세한 내용은 읽기 전용 복제본을 사용하여 읽기 전용 쿼리 워크로드 오프로드를 참조하세요.

SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability') T-SQL 쿼리를 실행할 수 있습니다. 결과는 읽기 전용 보조 복제본에 연결된 경우 READ_ONLY이고, 주 복제본에 연결된 경우 READ_WRITE입니다. 데이터베이스 컨텍스트는 master 데이터베이스가 아니라 데이터베이스의 이름으로 설정해야 합니다.

아니요. ApplicationIntent=ReadOnly를 지정하는 경우에만 HA 보조 복제본에 연결할 수 있습니다. 그러나 전용 엔드포인트는 명명된 복제본에 사용할 수 있습니다.

아니요. 읽기 전용 의도가 있는 새 연결은 임의의 HA 보조 복제본으로 리디렉션됩니다.

프로비전된 컴퓨팅 계층에 없습니다. HA 보조 복제본은 고가용성 장애 조치(failover) 대상으로 사용되므로 장애 조치(failover) 후 필요한 성능을 제공하려면 주 복제본과 동일한 구성을 사용해야 합니다. 서버리스에서 컴퓨팅은 개별 워크로드 수요에 따라 각 HA 복제본(replica)에 대해 자동으로 크기가 조정됩니다. 각 HA 보조 복제본은 장애 조치(failover) 후 역할을 수용하기 위해 구성된 최대 코어로 자동 크기 조정할 수 있습니다. 명명된 복제본은 각 복제본의 크기를 독립적으로 조정할 수 있는 기능을 제공합니다.

아니요. tempdb 데이터베이스는 프로비저닝된 컴퓨팅 크기에 따라 구성되며, HA 보조 복제본은 tempdb를 포함하여 주 컴퓨팅과 동일한 크기입니다. 명명된 복제본(replica)에서 tempdb는 복제본(replica)의 컴퓨팅 크기에 따라 크기가 조정되므로 주 복제본의 tempdb보다 작거나 클 수 있습니다.

아니요. 하이퍼스케일 데이터베이스 컴퓨팅 복제본(replica)은 스토리지를 공유하므로 모든 컴퓨팅 복제본(replica)이 동일한 테이블, 인덱스 및 기타 데이터베이스 개체를 볼 수 있습니다. 보조 복제본에 대한 읽기에 최적화된 추가 인덱스를 원하는 경우 주 복제본에서 해당 인덱스를 추가해야 합니다. 임시 데이터를 저장하기 위해 각 보조 복제본에 임시 테이블(#또는 ## 접두사가 붙은 테이블 이름)을 계속 만들 수 있습니다. 임시 테이블은 읽기/쓰기 테이블입니다.

트랜잭션이 주 복제본에서 커밋된 시간부터 보조 복제본에서 읽을 수 있는 시간까지의 데이터 대기 시간은 현재 로그 생성 속도, 트랜잭션 크기, 복제본의 로드 및 기타 요인에 따라 달라집니다. 소규모 트랜잭션의 일반적인 데이터 대기 시간은 수십 밀리초이지만, 데이터 대기 시간의 상한이 없습니다. 지정된 보조 복제본의 데이터는 항상 트랜잭션 면에서 일관되므로 트랜잭션이 클수록 전파되는 데 더 오래 걸립니다. 그러나 특정 시점의 데이터 대기 시간 및 데이터 상태는 보조 복제본마다 다를 수 있습니다. 커밋된 데이터를 즉시 읽어야 하는 워크로드는 주 복제본에서 실행해야 합니다.

아니요, 명명된 복제본은 주 복제본의 장애 조치(failover) 대상으로 사용할 수 없습니다. 이러한 용도에는 HA 복제본을 추가합니다.

명명된 복제본마다 서비스 수준 목표가 다를 수 있고 이에 따라 서로 다른 사용 사례에 사용될 수 있으므로 주 복제본에 보낸 읽기 전용 트래픽을 명명된 복제본 집합으로 전달하는 기본 제공 방법이 없습니다. 예를 들어 8개의 명명된 복제본이 있을 수 있고, OLTP 워크로드를 1~4의 명명된 복제본으로만 전달하려고 할 수 있습니다. 한편 모든 Power BI 분석 워크로드에서 5 및 6의 명명된 복제본을 사용하고, 데이터 과학 워크로드에서 7 및 8의 복제본을 사용합니다. 사용하는 도구 또는 프로그래밍 언어에 따라 이러한 워크로드를 분산하는 전략이 달라질 수 있습니다. REST 백 엔드에서 스케일 아웃할 수 있도록 워크로드 라우팅 솔루션을 만드는 한 가지 예는 OLTP 스케일 아웃 샘플입니다.

아니요, 명명된 복제본은 주 복제본의 동일한 페이지 서버를 사용하므로 동일한 지역에 있어야 합니다.

명명된 복제본은 주 복제본의 가용성에 영향을 줄 수 없습니다. 명명된 복제본은 정상적인 상황에서 주 복제본의 성능에 영향을 줄 가능성이 거의 없지만, 리소스를 많이 사용하는 워크로드가 실행되는 경우에는 영향을 줄 수 있습니다. HA 복제본과 마찬가지로 명명된 복제본은 트랜잭션 로그 서비스를 통해 주 복제본과 동기화된 상태로 유지됩니다. 어떤 이유로든 명명된 복제본에서 트랜잭션 로그를 충분히 빠르게 사용할 수 없는 경우 주 복제본에서 로그 생성 속도를 늦추도록(제한) 요청하기 시작합니다. 그러면 주 복제본에서 캐치업할 수 있습니다. 이 동작은 기본 가용성에 영향을 주지만 주 복제본에서 쓰기 워크로드의 성능에 영향을 줄 수 있습니다. 이러한 상황을 방지하려면 트랜잭션 로그를 지연 없이 처리할 수 있도록 사용 가능한 리소스 위쪽 공간(주로 CPU)이 명명된 복제본에 충분히 있는지 확인합니다. 예를 들어 주 복제본에서 많은 데이터 변경 내용을 처리하는 경우 복제본의 CPU 포화 상태를 방지하고 이에 따라 주 복제본이 느려지지 않도록 적어도 서비스 수준 목표가 주 복제본과 동일한 명명된 복제본을 사용하는 것이 좋습니다.

명명된 복제본은 평소와 같이 읽기 전용 액세스에 계속 사용할 수 있습니다.

기본적으로 명명된 복제본에는 자체 HA 복제본이 없습니다. 명명된 복제본의 장애 조치(failover)를 수행하려면 먼저 새 복제본을 만들어야 하며, 이는 일반적으로 약 1~2분이 걸립니다. 그러나 명명된 복제본은 HA 복제본에서 제공하는 더 높은 가용성 및 짧은 장애 조치(failover)를 통해 이점을 받을 수 있습니다. 명명된 복제본에 대한 HA 복제본을 추가하기 위해 AZ CLI에서 ha-replicas 매개 변수를 사용하거나, PowerShell에서 HighAvailabilityReplicaCount 매개 변수를 사용하거나, REST API에서 highAvailabilityReplicaCount 속성을 통해 사용할 수 있습니다. HA 복제본 수는 명명된 복제본을 만드는 동안 설정할 수 있으며, 명명된 복제본이 만들어지면 언제든지 AZ CLI, PowerShell 또는 REST API를 통해서만 변경할 수 있습니다. 명명된 복제본에 대한 HA 복제본의 가격 책정은 일반 하이퍼스케일 데이터베이스에 대한 HA 복제본과 동일합니다.

예. 열 마스터 키는 사용자 데이터베이스에 저장되며 쿼리SELECT * FROM sys.column_master_keys를 실행하여 유효성을 검사할 수 있습니다. 명명된 복제본(replica) 및 고가용성 보조 복제본은 기본 하이퍼스케일 데이터베이스와 동일한 페이지 서버/스토리지 계층에서 데이터를 읽습니다. 두 유형의 복제본은 로그 서비스를 통해 기본 하이퍼스케일 데이터베이스와 동기화됩니다. 키 변경은 트랜잭션으로 간주되며 명명된 복제본과 고가용성 보조 복제본에 자동으로 복제됩니다.

DATABASEPROPERTYEX() 함수는 명명된 복제본의 컨텍스트 내에서 실행될 때 replica_id를 해당 명명된 복제본에 매핑할 수 있습니다. 그러나 현재 주 복제본에서 쿼리할 때 sys.dm_database_replica_states 동적 관리 뷰의 각 레코드에 대해 replica_id를 해당 명명된 복제본에 연결하는 것은 불가능합니다. 다음 예제 쿼리는 명명된 복제본 컨텍스트 내에서 실행하여 복제본 이름, 복제본 ID 및 동기화 세부 정보를 식별할 수 있습니다.

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

관련 콘텐츠

하이퍼스케일 서비스 계층에 대한 자세한 내용은 하이퍼스케일 서비스 계층을 참조하세요.