하이퍼스케일 서비스 계층Hyperscale service tier

Azure SQL Database는 인프라 오류의 경우에도 99.99%의 가용성을 보장하기 위해 클라우드 환경에 대해 조정되는 SQL Server 데이터베이스 엔진 아키텍처를 기반으로 합니다.Azure SQL Database is based on SQL Server Database Engine architecture that is adjusted for the cloud environment in order to ensure 99.99% availability even in the cases of infrastructure failures. Azure SQL Database에 사용되는 세 가지 아키텍처 모델이 있습니다.There are three architectural models that are used in Azure SQL Database:

  • 범용/표준General Purpose/Standard
  • 하이퍼스케일Hyperscale
  • 중요 비즈니스용/프리미엄Business Critical/Premium

Azure SQL Database의 하이퍼스케일 서비스 계층은 vCore 기반 구매 모델의 최신 서비스 계층입니다.The Hyperscale service tier in Azure SQL Database is the newest service tier in the vCore-based purchasing model. 이 서비스 계층은 Azure 아키텍처를 활용하여 범용 및 중요 비즈니스용 서비스 계층에 사용할 수 있는 제한을 초과하여 Azure SQL Database용 스토리지 및 컴퓨팅 리소스를 확장하는 확장성이 뛰어난 스토리지 및 컴퓨팅 성능 계층입니다.This service tier is a highly scalable storage and compute performance tier that leverages the Azure architecture to scale out the storage and compute resources for an Azure SQL Database substantially beyond the limits available for the General Purpose and Business Critical service tiers.

참고

  • VCore 기반 구매 모델의 범용 및 중요 비즈니스용 서비스 계층에 대 한 자세한 내용은 범용중요 비즈니스용 서비스 계층을 참조 하세요.For details on the General Purpose and Business Critical service tiers in the vCore-based purchasing model, see General Purpose and Business Critical service tiers. vCore 기반 구매 모델과 DTU 기반 구매 모델의 비교는 Azure SQL Database 구매 모델 및 리소스를 참조하세요.For a comparison of the vCore-based purchasing model with the DTU-based purchasing model, see Azure SQL Database purchasing models and resources.
  • Hyperscale 서비스 계층은 현재 Azure SQL Managed Instance가 아닌 Azure SQL Database에만 사용할 수 있습니다.The Hyperscale service tier is currently only available for Azure SQL Database, and not Azure SQL Managed Instance.

하이퍼스케일 기능에는 무엇이 있나요?What are the Hyperscale capabilities

Azure SQL Database의 하이퍼스케일 서비스 계층은 다음과 같은 추가 기능을 제공합니다.The Hyperscale service tier in Azure SQL Database provides the following additional capabilities:

  • 최대 100TB의 데이터베이스 크기 지원Support for up to 100 TB of database size
  • 계산 리소스에 대 한 IO 영향이 없는 크기와 관계 없이 Azure Blob storage에 저장 된 파일 스냅숏을 기반으로 하는 거의 즉각적인 데이터베이스 백업Nearly instantaneous database backups (based on file snapshots stored in Azure Blob storage) regardless of size with no IO impact on compute resources
  • 몇 시간 또는 며칠이 아닌 몇 분 내에(데이터베이스 작업의 규모가 아닌) 빠른 데이터베이스 복원(파일 스냅샷 기반)Fast database restores (based on file snapshots) in minutes rather than hours or days (not a size of data operation)
  • 데이터 볼륨에 관계없이 더 높은 로그 처리량 및 더 빠른 트랜잭션 커밋 시간이 보장되므로 전반적인 성능 개선Higher overall performance due to higher log throughput and faster transaction commit times regardless of data volumes
  • 빠른 스케일 아웃 - 읽기 워크로드를 오프로드하고 핫 대기로 사용하기 위해 하나 이상의 읽기 전용 노드를 프로비전할 수 있습니다.Rapid scale out - you can provision one or more read-only nodes for offloading your read workload and for use as hot-standbys
  • 신속한 확장-일정 한 시간에 필요한 경우 많은 워크 로드를 수용 하도록 계산 리소스를 확장 한 다음 필요 하지 않은 경우 계산 리소스를 다시 축소할 수 있습니다.Rapid Scale up - you can, in constant time, scale up your compute resources to accommodate heavy workloads when needed, and then scale the compute resources back down when not needed.

하이퍼스케일 서비스 계층은 클라우드 데이터베이스에서 기존에 확인되던 많은 실제 제한을 없애줍니다.The Hyperscale service tier removes many of the practical limits traditionally seen in cloud databases. 대부분의 다른 데이터베이스가 단일 노드에서 사용할 수 있는 리소스로 제한되지만 하이퍼스케일 서비스 계층의 데이터베이스에는 이러한 제한이 없습니다.Where most other databases are limited by the resources available in a single node, databases in the Hyperscale service tier have no such limits. 스토리지 아키텍처가 유연하기 때문에 필요에 따라 스토리지가 증가합니다.With its flexible storage architecture, storage grows as needed. 실제로는 정의 된 최대 크기로 Hyperscale 데이터베이스를 만들지 않습니다.In fact, Hyperscale databases aren't created with a defined max size. Hyperscale 데이터베이스는 필요에 따라 늘어나고 사용 하는 용량에 대해서만 요금이 청구 됩니다.A Hyperscale database grows as needed - and you're billed only for the capacity you use. 읽기 집약적 워크로드의 경우 하이퍼스케일 서비스 계층에서 읽기 워크로드를 오프로드하는 데 필요한 추가 읽기 복제본을 프로비전하여 신속한 스케일 아웃을 제공합니다.For read-intensive workloads, the Hyperscale service tier provides rapid scale-out by provisioning additional read replicas as needed for offloading read workloads.

또한 데이터베이스 백업을 만들거나 규모 확대 또는 축소에 필요한 시간이 더 이상 데이터베이스의 데이터 볼륨과 관련되지 않습니다.Additionally, the time required to create database backups or to scale up or down is no longer tied to the volume of data in the database. 하이퍼스케일 데이터베이스는 거의 동시에 백업할 수 있습니다.Hyperscale databases can be backed up virtually instantaneously. 몇 분 안에 수십 테라바이트의 데이터베이스 규모를 확대 또는 축소할 수도 있습니다.You can also scale a database in the tens of terabytes up or down in minutes. 이 기능은 초기 구성 선택에 따른 여러 가지 우려를 해소해줍니다.This capability frees you from concerns about being boxed in by your initial configuration choices.

하이퍼스케일 서비스 계층의 컴퓨팅 크기에 대한 자세한 내용은 서비스 계층 특성을 참조하세요.For more information about the compute sizes for the Hyperscale service tier, see Service tier characteristics.

하이퍼스케일 서비스 계층을 고려하면 좋은 대상Who should consider the Hyperscale service tier

하이퍼 규모 서비스 계층은 독립적으로 확장 가능한 계산 및 저장소 리소스를 통해 뛰어난 유연성과 고성능을 제공 하므로 대부분의 비즈니스 워크 로드에 적합 합니다.The Hyperscale service tier is intended for most business workloads as it provides great flexibility and high performance with independently scalable compute and storage resources. 저장소를 최대 100 TB까지 자동 크기 조정 하는 기능을 사용 하 여 다음을 수행 하는 고객에 게 적합 합니다.With the ability to autoscale storage up to 100 TB, it's a great choice for customers who:

  • 대량 데이터베이스를 온-프레미스로 설정 하 고 클라우드로 이동 하 여 응용 프로그램을 현대화 합니다.Have large databases on-premises and want to modernize their applications by moving to the cloud
  • 이미 클라우드에 있고 다른 서비스 계층의 최대 데이터베이스 크기 제한 (1-4 TB)에 의해 제한 됨Are already in the cloud and are limited by the maximum database size restrictions of other service tiers (1-4 TB)
  • 데이터베이스 크기가 작으므로 빠른 수직 및 수평 계산 크기 조정, 고성능, 즉시 백업 및 빠른 데이터베이스 복원이 필요 합니다.Have smaller databases, but require fast vertical and horizontal compute scaling, high performance, instant backup, and fast database restore.

하이퍼 규모 서비스 계층은 순수 OLTP에서 순수 분석까지 광범위 한 SQL Server 워크 로드를 지원 하지만 주로 OLTP 및 HTAP (하이브리드 트랜잭션 및 분석 처리) 워크 로드에 최적화 되어 있습니다.The Hyperscale service tier supports a broad range of SQL Server workloads, from pure OLTP to pure analytics, but it's primarily optimized for OLTP and hybrid transaction and analytical processing (HTAP) workloads.

중요

탄력적 풀은 하이퍼스케일 서비스 계층을 지원하지 않습니다.Elastic pools do not support the Hyperscale service tier.

하이퍼스케일 가격 책정 모델Hyperscale pricing model

하이퍼스케일 서비스 계층은 vCore 모델에만 사용할 수 있습니다.Hyperscale service tier is only available in vCore model. 새 아키텍처에 맞게 가격 책정 모델이 범용 또는 중요 비즈니스용 서비스 계층과 약간 다릅니다.To align with the new architecture, the pricing model is slightly different from General Purpose or Business Critical service tiers:

  • 계산:Compute:

    하이퍼스케일 컴퓨팅 단위 가격은 복제본별로 정해집니다.The Hyperscale compute unit price is per replica. Azure 하이브리드 혜택 가격은 읽기 확장 복제본에 자동으로 적용됩니다.The Azure Hybrid Benefit price is applied to read scale replicas automatically. 기본적으로 기본 복제본과 하이퍼 크기 조정 데이터베이스당 하나의 읽기 전용 복제본을 만듭니다.We create a primary replica and one read-only replica per Hyperscale database by default. 사용자가 1-5의 주 복제본을 포함 하 여 총 복제본 수를 조정할 수 있습니다.Users may adjust the total number of replicas including the primary from 1-5.

  • 스토리지:Storage:

    하이퍼스케일 데이터베이스를 구성하는 경우 최대 데이터 크기를 지정할 필요가 없습니다.You don't need to specify the max data size when configuring a Hyperscale database. 대규모 계층에서는 실제 할당을 기반으로 데이터베이스에 대 한 저장소 요금이 청구 됩니다.In the hyperscale tier, you're charged for storage for your database based on actual allocation. 저장소는 10gb 증분 단위로 40 GB와 100 TB 사이에서 자동으로 할당 됩니다.Storage is automatically allocated between 40 GB and 100 TB, in 10-GB increments. 필요한 경우 여러 데이터 파일을 동시에 확장할 수 있습니다.Multiple data files can grow at the same time if needed. 하이퍼 규모의 데이터베이스는 10gb의 시작 크기를 사용 하 여 생성 되며, 40 GB의 크기에 도달할 때까지 10 분 마다 10gb의 증가를 시작 합니다.A Hyperscale database is created with a starting size of 10 GB and it starts growing by 10 GB every 10 minutes, until it reaches the size of 40 GB.

하이퍼스케일 가격 책정에 대한 자세한 내용은 Azure SQL Database 가격 책정을 참조하세요.For more information about Hyperscale pricing, see Azure SQL Database Pricing

분산 함수 아키텍처Distributed functions architecture

모든 데이터 관리 기능을 하나의 위치/프로세스에 중앙 집중식으로 배치하는 기존 데이터베이스 엔진과 달리(소위 말하는 프로덕션의 분산 데이터베이스에도 모놀리식 데이터 엔진의 여러 복사본이 있음), 하이퍼스케일 데이터베이스는 여러 데이터 엔진의 의미 체계가 구분되어 있는 쿼리 처리 엔진을 데이터에 대한 장기 스토리지 및 지속성을 제공하는 구성 요소와 구분합니다.Unlike traditional database engines that have centralized all of the data management functions in one location/process (even so called distributed databases in production today have multiple copies of a monolithic data engine), a Hyperscale database separates the query processing engine, where the semantics of various data engines diverge, from the components that provide long-term storage and durability for the data. 이러한 방식으로 스토리지 용량을 필요한 만큼 원활하게 스케일 아웃할 수 있습니다(초기 목표는 100TB).In this way, the storage capacity can be smoothly scaled out as far as needed (initial target is 100 TB). 읽기 전용 복제본은 동일한 저장소 구성 요소를 공유 하므로 읽기 가능한 새 복제본을 실행 하기 위해 데이터를 복사할 필요가 없습니다.Read-only replicas share the same storage components so no data copy is required to spin up a new readable replica.

다음 다이어그램은 하이퍼스케일 데이터베이스에 있는 여러 유형의 노드를 보여 줍니다.The following diagram illustrates the different types of nodes in a Hyperscale database:

아키텍처

Hyperscale 데이터베이스에는 다음과 같은 다양 한 유형의 구성 요소가 포함 됩니다.A Hyperscale database contains the following different types of components:

컴퓨팅Compute

계산 노드는 관계형 엔진의 위치입니다.The compute node is where the relational engine lives. 여기에는 언어, 쿼리 및 트랜잭션 처리가 발생 합니다.This is where language, query, and transaction processing occur. 하이퍼스케일 데이터베이스와의 모든 사용자 상호 작용은 이러한 컴퓨팅 노드를 통해 발생합니다.All user interactions with a Hyperscale database happen through these compute nodes. 컴퓨팅 노드에는 데이터 페이지를 가져오는 데 필요한 네트워크 왕복 횟수를 최소화하기 위해 SSD 기반 캐시[이전 다이어그램에 나오는 RBPEX(Resilient Buffer Pool Extension)]가 있습니다.Compute nodes have SSD-based caches (labeled RBPEX - Resilient Buffer Pool Extension in the preceding diagram) to minimize the number of network round trips required to fetch a page of data. 모든 읽기/쓰기 워크로드 및 트랜잭션이 처리되는 기본 컴퓨팅 노드가 1개 있습니다.There is one primary compute node where all the read-write workloads and transactions are processed. 장애 조치(Failover)를 위해 핫 대기 노드의 역할을 할 뿐만 아니라 읽기 워크로드를 오프로드하기 위한 읽기 전용 컴퓨팅 노드(이 기능이 필요한 경우)의 역할을 하는 하나 이상의 보조 컴퓨팅 노드도 있습니다.There are one or more secondary compute nodes that act as hot standby nodes for failover purposes, as well as act as read-only compute nodes for offloading read workloads (if this functionality is desired).

하이퍼 크기 조정 계산 노드에서 실행 되는 데이터베이스 엔진은 다른 Azure SQL Database 서비스 계층의 경우와 동일 합니다.The database engine running on Hyperscale compute nodes is the same as in other Azure SQL Database service tiers. 사용자가 Wscale 계산 노드에서 데이터베이스 엔진과 상호 작용할 때 지원 되는 노출 영역 및 엔진 동작은 다른 서비스 계층의 경우와 동일 하지만 알려진 제한 사항은예외입니다.When users interact with the database engine on Hyperscale compute nodes, the supported surface area and engine behavior are the same as in other service tiers, with the exception of known limitations.

페이지 서버Page server

페이지 서버는 스케일 아웃된 스토리지 엔진을 나타내는 시스템입니다.Page servers are systems representing a scaled-out storage engine. 각 페이지 서버는 데이터베이스의 페이지 하위 집합을 담당합니다.Each page server is responsible for a subset of the pages in the database. 명목상 각 페이지 서버는 최대 128 GB 또는 최대 1tb의 데이터를 제어 합니다.Nominally, each page server controls either up to 128 GB or up to 1 TB of data. 두 개 이상의 페이지 서버 (중복성 및 가용성을 위해 유지 되는 페이지 서버 복제본 외부)에서 데이터를 공유 하지 않습니다.No data is shared on more than one page server (outside of page server replicas that are kept for redundancy and availability). 페이지 서버의 업무는 요청 시 컴퓨팅 노드에 데이터베이스 페이지를 제공하고, 트랜잭션으로 인해 데이터가 업데이트될 때 페이지를 최신 상태로 유지하는 것입니다.The job of a page server is to serve database pages out to the compute nodes on demand, and to keep the pages updated as transactions update data. 페이지 서버는 로그 서비스에서 로그 레코드를 재생 하 여 최신 상태로 유지 됩니다.Page servers are kept up to date by playing log records from the log service. 또한 페이지 서버는 성능을 향상 시키기 위해 SSD 기반 캐시에 대 한 처리를 유지 합니다.Page servers also maintain covering SSD-based caches to enhance performance. 데이터 페이지의 장기 스토리지는 추가 안정성을 위해 Azure Storage에 보관됩니다.Long-term storage of data pages is kept in Azure Storage for additional reliability.

로그 서비스Log service

로그 서비스는 기본 계산 복제본의 로그 레코드를 수락 하 고, 영구 캐시에 보관 하 고, 로그 레코드를 관련 페이지 서버 뿐만 아니라 관련 페이지 서버에 전달 하 여 데이터를 업데이트할 수 있도록 합니다.The log service accepts log records from the primary compute replica, persists them in a durable cache, and forwards the log records to the rest of compute replicas (so they can update their caches) as well as the relevant page server(s), so that the data can be updated there. 이러한 방식으로 기본 계산 복제본의 모든 데이터 변경 내용은 모든 보조 계산 복제본 및 페이지 서버로 로그 서비스를 통해 전파 됩니다.In this way, all data changes from the primary compute replica are propagated through the log service to all the secondary compute replicas and page servers. 마지막으로 로그 레코드는 거의 무한 한 저장소 저장소 인 Azure Storage의 장기 저장소로 푸시됩니다.Finally, the log records are pushed out to long-term storage in Azure Storage, which is a virtually infinite storage repository. 이 메커니즘을 통해 로그 잘림을 자주 수행 하지 않아도 됩니다.This mechanism removes the need for frequent log truncation. 로그 서비스에는 로그 레코드에 대 한 액세스를 가속화 하는 로컬 메모리 및 SSD 캐시도 있습니다.The log service also has local memory and SSD caches to speed up access to log records.

Azure StorageAzure storage

Azure Storage는 데이터베이스의 모든 데이터 파일을 포함 합니다.Azure Storage contains all data files in a database. 페이지 서버는 Azure Storage의 데이터 파일을 최신 상태로 유지 합니다.Page servers keep data files in Azure Storage up to date. 이 저장소는 백업 용도로 사용 되며 Azure 지역 간의 복제에도 사용 됩니다.This storage is used for backup purposes, as well as for replication between Azure regions. 백업은 데이터 파일의 저장소 스냅숏을 사용 하 여 구현 됩니다.Backups are implemented using storage snapshots of data files. 스냅숏을 사용한 복원 작업은 데이터 크기에 관계 없이 빠르게 수행 됩니다.Restore operations using snapshots are fast regardless of data size. 데이터베이스의 백업 보존 기간 내의 특정 시점으로 데이터를 복원할 수 있습니다.Data can be restored to any point in time within the backup retention period of the database.

백업 및 복원Backup and restore

백업은 파일-스냅숏 기반 이므로 거의 즉각적입니다.Backups are file-snapshot based and hence they're nearly instantaneous. 저장소 및 계산 분리를 사용 하면 백업/복원 작업을 저장소 계층에 푸시하여 기본 계산 복제본의 처리 부담을 줄일 수 있습니다.Storage and compute separation enables pushing down the backup/restore operation to the storage layer to reduce the processing burden on the primary compute replica. 따라서 데이터베이스 백업은 기본 계산 노드의 성능에 영향을 주지 않습니다.As a result, database backup doesn't impact performance of the primary compute node. 마찬가지로 PITR (지정 시간 복구)는 파일 스냅숏으로 되돌리고 데이터 작업의 크기가 아니라는 것입니다.Similarly, point in time recovery (PITR) is done by reverting to file snapshots, and as such is not a size of data operation. 동일한 Azure 지역에 있는 하이퍼 규모의 데이터베이스 복원은 일정 시간 작업이 며 몇 시간 또는 며칠이 아닌 몇 분 안에 여러 테라바이트 데이터베이스를 복원할 수 있습니다.Restore of a Hyperscale database in the same Azure region is a constant-time operation, and even multiple-terabyte databases can be restored in minutes instead of hours or days. 기존 백업을 복원 하 여 새 데이터베이스를 만들면이 기능을 활용할 수 있습니다. 또한 여러 테라바이트 데이터베이스를 포함 하 여 개발 또는 테스트 목적으로 데이터베이스 복사본을 만드는 작업은 몇 분 안에 심지어 됩니다.Creation of new databases by restoring an existing backup also takes advantage of this feature: creating database copies for development or testing purposes, even of multi-terabyte databases, is doable in minutes.

하이퍼 규모의 데이터베이스에 대 한 지역 복원의 경우 다른 지역으로 hyperscale 데이터베이스 복원을 참조 하세요.For geo-restore of Hyperscale databases, see Restoring a Hyperscale database to a different region.

확장 및 성능상의 이점Scale and performance advantages

추가 읽기 전용 컴퓨팅 노드를 신속하게 스핀업/스핀다운하는 기능을 사용하여 하이퍼스케일 아키텍처는 상당한 읽기 기능을 허용하며 더 많은 쓰기 요청을 제공하기 위해 기본 컴퓨팅 노드를 해제할 수도 있습니다.With the ability to rapidly spin up/down additional read-only compute nodes, the Hyperscale architecture allows significant read scale capabilities and can also free up the primary compute node for serving more write requests. 또한 하이퍼스케일 아키텍처의 공유 스토리지 아키텍처로 인해 컴퓨팅 노드 규모를 빠르게 확대/축소할 수 있습니다.Also, the compute nodes can be scaled up/down rapidly due to the shared-storage architecture of the Hyperscale architecture.

Hyperscale 데이터베이스 만들기Create a Hyperscale database

Azure Portal, t-sql, PowerShell또는 CLI를 사용 하 여 hyperscale 데이터베이스를 만들 수 있습니다.A Hyperscale database can be created using the Azure portal, T-SQL, PowerShell, or CLI. Hyperscale 데이터베이스는 Vcore 기반 구매 모델을 사용 하는 경우에만 사용할 수 있습니다.Hyperscale databases are available only using the vCore-based purchasing model.

다음 T-SQL 명령은 하이퍼스케일 데이터베이스를 생성합니다.The following T-SQL command creates a Hyperscale database. CREATE DATABASE 문에 버전 및 서비스 목표를 둘 다 지정해야 합니다.You must specify both the edition and service objective in the CREATE DATABASE statement. 유효한 서비스 목표 목록은 리소스 제한을 참조 하세요.Refer to the resource limits for a list of valid service objectives.

-- Create a Hyperscale Database
CREATE DATABASE [HyperscaleDB1] (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

그러면 4 개의 코어가 있는 Gen5 하드웨어에서 하이퍼 확장 데이터베이스를 만듭니다.This will create a Hyperscale database on Gen5 hardware with four cores.

기존 데이터베이스를 Hyperscale으로 업그레이드Upgrade existing database to Hyperscale

Azure Portal, t-sql, PowerShell또는 CLI를 사용 하 여 Azure SQL Database에서 기존 데이터베이스를 hyperscale으로 이동할 수 있습니다.You can move your existing databases in Azure SQL Database to Hyperscale using the Azure portal, T-SQL, PowerShell, or CLI. 이번에는 단방향 마이그레이션입니다.At this time, this is a one-way migration. 데이터를 내보내고 가져오는 것 외에는 Hyperscale에서 다른 서비스 계층으로 데이터베이스를 이동할 수 없습니다.You can't move databases from Hyperscale to another service tier, other than by exporting and importing data. POCs (개념 증명)의 경우 프로덕션 데이터베이스의 복사본을 만들고 복사본을 Hyperscale으로 마이그레이션하는 것이 좋습니다.For proofs of concept (POCs), we recommend making a copy of your production databases, and migrating the copy to Hyperscale. Azure SQL Database의 기존 데이터베이스를 Hyperscale 계층으로 마이그레이션하는 작업은 데이터 작업의 크기입니다.Migrating an existing database in Azure SQL Database to the Hyperscale tier is a size of data operation.

다음 T-SQL 명령은 하이퍼스케일 서비스 계층으로 데이터베이스를 이동합니다.The following T-SQL command moves a database into the Hyperscale service tier. ALTER DATABASE 문에 버전 및 서비스 목표를 둘 다 지정해야 합니다.You must specify both the edition and service objective in the ALTER DATABASE statement.

-- Alter a database to make it a Hyperscale Database
ALTER DATABASE [DB2] MODIFY (EDITION = 'Hyperscale', SERVICE_OBJECTIVE = 'HS_Gen5_4');
GO

하이퍼스케일 데이터베이스의 읽기 확장 복제본에 연결Connect to a read-scale replica of a Hyperscale database

Hyperscale 데이터베이스에서 ApplicationIntent 클라이언트가 제공 하는 연결 문자열의 인수는 연결이 쓰기 복제본 또는 읽기 전용 보조 복제본으로 라우팅되도록 할지를 결정 합니다.In Hyperscale databases, the ApplicationIntent argument in the connection string provided by the client dictates whether the connection is routed to the write replica or to a read-only secondary replica. ApplicationIntent로 설정 된 READONLY 와 데이터베이스에 보조 복제본이 없는 경우 연결이 주 복제본으로 라우팅되고 기본값은 ReadWrite 동작입니다.If the ApplicationIntent set to READONLY and the database doesn't have a secondary replica, connection will be routed to the primary replica and defaults to ReadWrite behavior.

-- Connection string with application intent
Server=tcp:<myserver>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

하이퍼 확장 보조 복제본은 주 복제본과 동일한 서비스 수준 목표를 사용 하는 모두 동일 합니다.Hyperscale secondary replicas are all identical, using the same Service Level Objective as the primary replica. 보조 복제본이 두 개 이상 있는 경우 해당 작업은 사용 가능한 모든 보조 복제본에 분산 됩니다.If more than one secondary replica is present, the workload is distributed across all available secondaries. 각 보조 복제본은 독립적으로 업데이트 됩니다.Each secondary replica is updated independently. 따라서 다른 복제본에는 주 복제본에 비해 서로 다른 데이터 대기 시간이 있을 수 있습니다.Thus, different replicas could have different data latency relative to the primary replica.

Hyperscale의 데이터베이스 고가용성Database high availability in Hyperscale

다른 모든 서비스 계층과 마찬가지로, Hyperscale은 계산 복제본 가용성에 관계 없이 커밋된 트랜잭션에 대 한 데이터 내구성을 보장 합니다.As in all other service tiers, Hyperscale guarantees data durability for committed transactions regardless of compute replica availability. 주 복제본이 사용할 수 없게 될 때 발생 하는 가동 중지 시간은 장애 조치 (failover) 유형 (계획 된 계획 또는 계획 되지 않음) 및 하나 이상의 보조 복제본이 있는지 여부에 따라 달라 집니다.The extent of downtime due to the primary replica becoming unavailable depends on the type of failover (planned vs. unplanned), and on the presence of at least one secondary replica. 계획 된 장애 조치 (failover) (예: 유지 관리 이벤트)에서 시스템은 장애 조치 (failover)를 시작 하기 전에 새 주 복제본을 만들거나 기존 보조 복제본을 장애 조치 (failover) 대상으로 사용 합니다.In a planned failover (i.e. a maintenance event), the system either creates the new primary replica before initiating a failover, or uses an existing secondary replica as the failover target. 계획 되지 않은 장애 조치 (failover) (즉, 주 복제본의 하드웨어 오류)에서 시스템은 보조 복제본을 장애 조치 (failover) 대상으로 사용 하 고 (있는 경우) 사용 가능한 계산 용량의 풀에서 새 주 복제본을 만듭니다.In an unplanned failover (i.e. a hardware failure on the primary replica), the system uses a secondary replica as a failover target if one exists, or creates a new primary replica from the pool of available compute capacity. 후자의 경우 새 주 복제본을 만드는 데 필요한 추가 단계 때문에 가동 중지 시간이 길어집니다.In the latter case, downtime duration is longer due to extra steps required to create the new primary replica.

하이퍼 확장 SLA는 Azure SQL Database에 대 한 sla를 참조 하세요.For Hyperscale SLA, see SLA for Azure SQL Database.

Hyperscale 데이터베이스에 대 한 재해 복구Disaster recovery for Hyperscale databases

다른 지역으로 Hyperscale 데이터베이스 복원Restoring a Hyperscale database to a different region

Azure SQL Database의 Hyperscale 데이터베이스를 현재 호스트 되는 지역이 아닌 다른 지역으로 복원 해야 하는 경우 재해 복구 작업 또는 드릴, 재배치 또는 기타 이유로 인해 주 방법은 데이터베이스의 지역 복원을 수행 하는 것입니다.If you need to restore a Hyperscale database in Azure SQL Database to a region other than the one it's currently hosted in, as part of a disaster recovery operation or drill, relocation, or any other reason, the primary method is to do a geo-restore of the database. 여기에는 SQL Database의 다른 데이터베이스를 다른 지역으로 복원 하는 데 사용 하는 것과 정확히 같은 단계가 포함 됩니다.This involves exactly the same steps as what you would use to restore any other database in SQL Database to a different region:

  1. 적절 한 서버가 아직 없는 경우 대상 지역에 서버 를 만듭니다.Create a server in the target region if you don't already have an appropriate server there. 이 서버는 원본 서버와 동일한 구독에서 소유 해야 합니다.This server should be owned by the same subscription as the original (source) server.
  2. 자동 백업에서 Azure SQL Database의 데이터베이스 복원에 대 한 페이지의 지역 복원 항목의 지침을 따르세요.Follow the instructions in the geo-restore topic of the page on restoring a database in Azure SQL Database from automatic backups.

참고

원본 및 대상이 별도의 지역에 있기 때문에 데이터베이스는 데이터베이스 크기에 관계 없이 빠르게 완료 되는 비-지역 복원의 원본 데이터베이스와 스냅숏 저장소를 공유할 수 없습니다.Because the source and target are in separate regions, the database cannot share snapshot storage with the source database as in non-geo restores, which complete quickly regardless of database size. 하이퍼 규모의 데이터베이스에 대 한 지역 복원의 경우 대상이 지역에서 복제 된 저장소의 쌍을 이루는 지역에 있는 경우에도 데이터 크기 조정 작업이 수행 됩니다.In the case of a geo-restore of a Hyperscale database, it will be a size-of-data operation, even if the target is in the paired region of the geo-replicated storage. 따라서 지역 복원은 복원 되는 데이터베이스의 크기에 비례하여 시간이 소요 됩니다.Therefore, a geo-restore will take time proportional to the size of the database being restored. 대상이 쌍을 이루는 지역에 있는 경우 데이터 전송은 지역 내에 있습니다 .이는 지역 간 데이터 전송 보다 훨씬 빠르지만 데이터의 크기는 여전히 작업입니다.If the target is in the paired region, data transfer will be within a region, which will be significantly faster than a cross-region data transfer, but it will still be a size-of-data operation.

사용 가능한 지역Available regions

Azure SQL Database Hyperscale 계층은 모든 지역에서 사용할 수 있지만 아래에 나열 된 다음 지역에서 기본적으로 사용 하도록 설정 되어 있습니다.The Azure SQL Database Hyperscale tier is available in all regions but enabled by default in the following regions listed below. Hyperscale이 기본적으로 사용 되지 않는 지역에서 하이퍼 확장 데이터베이스를 만들려는 경우 Azure Portal를 통해 온 보 딩 요청을 보낼 수 있습니다.If you want to create a Hyperscale database in a region where Hyperscale is not enabled by default, you can send an onboarding request via Azure portal. 지침에 대 한 자세한 내용은 Azure SQL Database에 대 한 요청 할당량 늘리기 를 참조 하세요.For instructions, see Request quota increases for Azure SQL Database for instructions. 요청을 제출 하는 경우 다음 지침을 따르십시오.When submitting your request, use the following guidelines:

  • 지역 액세스 SQL Database 할당량 유형을 사용 합니다.Use the Region access SQL Database quota type.
  • 설명에서 읽기 가능한 복제본을 포함 하 여 계산 SKU/총 코어를 추가 하 고, 하이퍼 확장 용량을 요청 하 고 있음을 표시 합니다.In the description, add the compute SKU/total cores including readable replicas, and indicate that you are requesting Hyperscale capacity.
  • 또한 시간에 따라 모든 데이터베이스의 전체 크기에 대 한 프로젝션을 TB 단위로 지정 합니다.Also specify a projection of the total size of all databases over time in TB.

사용 하도록 설정 된 영역:Enabled Regions:

  • 오스트레일리아 동부Australia East
  • 오스트레일리아 남동부Australia Southeast
  • 오스트레일리아 중부Australia Central
  • 브라질 남부Brazil South
  • 캐나다 중부Canada Central
  • 미국 중부Central US
  • 중국 동부 2China East 2
  • 중국 북부 2China North 2
  • 동아시아East Asia
  • 미국 동부East US
  • 미국 동부 2East Us 2
  • 프랑스 중부France Central
  • 독일 중서부Germany West Central
  • 일본 동부Japan East
  • 일본 서부Japan West
  • 한국 중부Korea Central
  • 한국 남부Korea South
  • 미국 중북부North Central US
  • 북유럽North Europe
  • 노르웨이 동부Norway East
  • 노르웨이 서부Norway West
  • 남아프리카 북부South Africa North
  • 미국 중남부South Central US
  • 동남아시아Southeast Asia
  • 스위스 서부Switzerland West
  • 영국 남부UK South
  • 영국 서부UK West
  • US DoD 중부US DoD Central
  • US DoD 동부US DoD East
  • 미국 Govt 애리조나Us Govt Arizona
  • 미국 Govt 텍사스US Govt Texas
  • 미국 중서부West Central US
  • 서유럽West Europe
  • 미국 서부West US
  • 미국 서부 2West US 2

알려진 제한 사항Known limitations

이는 GA를 기준으로 하는 Hyperscale 서비스 계층에 대 한 현재 제한 사항입니다.These are the current limitations to the Hyperscale service tier as of GA. 가능한 한 많은 제한 사항을 제거 하기 위해 적극적으로 노력 하 고 있습니다.We're actively working to remove as many of these limitations as possible.

문제Issue DescriptionDescription
서버에 대 한 백업 관리 창에는 Hyperscale 데이터베이스가 표시 되지 않습니다.The Manage Backups pane for a server doesn't show Hyperscale databases. 이러한 필터는 뷰에서 필터링 됩니다.These will be filtered from the view. Hyperscale에는 백업을 관리 하는 별도의 방법이 있으므로 Long-Term 보존 및 지정 시간 백업 보존 설정이 적용 되지 않습니다.Hyperscale has a separate method for managing backups, so the Long-Term Retention and Point-in-Time backup retention settings don't apply. 따라서 Hyperscale 데이터베이스는 백업 관리 창에 표시 되지 않습니다.Accordingly, Hyperscale databases don't appear in the Manage Backup pane.

다른 Azure SQL Database 서비스 계층에서 Hyperscale으로 마이그레이션된 데이터베이스의 경우 마이그레이션 전 백업은 원본 데이터베이스의 백업 보존 기간 동안 유지 됩니다.For databases migrated to Hyperscale from other Azure SQL Database service tiers, pre-migration backups are kept for the duration of backup retention period of the source database. 이러한 백업은 마이그레이션 전 시점으로 원본 데이터베이스를 복원 하는 데 사용할 수 있습니다.These backups can be used to restore the source database to a point in time before migration.
지정 시간 복원Point-in-time restore Hyperscale이 아닌 데이터베이스를 하이퍼 규모의 데이터베이스로 복원할 수 없으며 Hyperscale 데이터베이스를 비 Hyperscale 데이터베이스로 복원할 수 없습니다.A non-Hyperscale database can't be restored as a Hyperscale database, and a Hyperscale database can't be restored as a non-Hyperscale database. 서비스 계층을 변경 하 여 Hyperscale으로 마이그레이션된 비 Hyperscale 데이터베이스의 경우 마이그레이션 전 지정 시간으로 복원 하 고 데이터베이스의 백업 보존 기간 내에 프로그래밍 방식으로지원 합니다.For a non-Hyperscale database that has been migrated to Hyperscale by changing its service tier, restore to a point in time before migration and within the backup retention period of the database is supported programmatically. 복원 된 데이터베이스는 Hyperscale이 아닙니다.The restored database will be non-Hyperscale.
Azure SQL Database 서비스 계층을 Hyperscale으로 변경 하는 경우 데이터베이스에 1tb 보다 큰 데이터 파일이 있으면 작업이 실패 합니다.When changing Azure SQL Database service tier to Hyperscale, the operation fails if the database has any data files larger than 1 TB 경우에 따라 서비스 계층을 Hyperscale으로 변경 하려고 시도 하기 전에 대용량 파일을 1TB 미만으로 축소 하 여이 문제를 해결할 수 있습니다.In some cases, it may be possible to work around this issue by shrinking the large files to be less than 1 TB before attempting to change the service tier to Hyperscale. 다음 쿼리를 사용 하 여 데이터베이스 파일의 현재 크기를 확인 합니다.Use the following query to determine the current size of database files. SELECT file_id, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';SELECT file_id, name AS file_name, size * 8. / 1024 / 1024 AS file_size_GB FROM sys.database_files WHERE type_desc = 'ROWS';
SQL Managed InstanceSQL Managed Instance Azure SQL Managed Instance는 현재 Hyperscale 데이터베이스에서 지원 되지 않습니다.Azure SQL Managed Instance isn't currently supported with Hyperscale databases.
탄력적 풀Elastic Pools 탄력적 풀은 현재 Hyperscale에서 지원 되지 않습니다.Elastic Pools aren't currently supported with Hyperscale.
하이퍼스케일로 마이그레이션은 현재 단방향 작업입니다.Migration to Hyperscale is currently a one-way operation 데이터베이스를 Hyperscale으로 마이그레이션한 후에는 비-Hyperscale 서비스 계층으로 직접 마이그레이션할 수 없습니다.Once a database is migrated to Hyperscale, it can't be migrated directly to a non-Hyperscale service tier. 현재는 데이터베이스를 Hyperscale에서 비-Hyperscale 마이그레이션하는 유일한 방법은 bacpac 파일이 나 기타 데이터 이동 기술 (대량 복사, Azure Data Factory, Azure Databricks, SSIS 등)을 사용 하 여 내보내거나 가져오는 것입니다. Azure CLI에서 AzSqlDatabaseExport 또는 AzSqlDatabaseImport를 사용 하 여 PowerShell에서의 Bacpac 내보내기/Azure Portal 가져오기는 az sql db exportaz sql db import REST API 를 사용 하 여에서 지원 되지 않습니다.At present, the only way to migrate a database from Hyperscale to non-Hyperscale is to export/import using a bacpac file or other data movement technologies (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS, etc.) Bacpac export/import from Azure portal, from PowerShell using New-AzSqlDatabaseExport or New-AzSqlDatabaseImport, from Azure CLI using az sql db export and az sql db import, and from REST API is not supported. 더 작은 Hyperscale 데이터베이스 (최대 200 GB)의 Bacpac 가져오기/내보내기는 SSMS 및 SqlPackage 버전 18.4 이상을 사용 하 여 지원 됩니다.Bacpac import/export for smaller Hyperscale databases (up to 200 GB) is supported using SSMS and SqlPackage version 18.4 and later. 대형 데이터베이스의 경우에는 bacpac 내보내기/가져오기 시간이 오래 걸릴 수 있으며 여러 가지 이유로 실패할 수 있습니다.For larger databases, bacpac export/import may take a long time, and may fail for various reasons.
In-Memory OLTP 개체가 포함 된 데이터베이스 마이그레이션Migration of databases with In-Memory OLTP objects Hyperscale은 메모리 최적화 테이블 형식, 테이블 변수 및 고유 하 게 컴파일된 모듈을 포함 하 여 In-Memory OLTP 개체의 하위 집합을 지원 합니다.Hyperscale supports a subset of In-Memory OLTP objects, including memory-optimized table types, table variables, and natively compiled modules. 그러나 마이그레이션되는 데이터베이스에 In-Memory OLTP 개체의 모든 종류가 있는 경우 Premium 및 중요 비즈니스용 서비스 계층에서 Hyperscale으로의 마이그레이션은 지원 되지 않습니다.However, when any kind of In-Memory OLTP objects are present in the database being migrated, migration from Premium and Business Critical service tiers to Hyperscale is not supported. 이러한 데이터베이스를 Hyperscale으로 마이그레이션하려면 모든 In-Memory OLTP 개체와 해당 종속성을 삭제 해야 합니다.To migrate such a database to Hyperscale, all In-Memory OLTP objects and their dependencies must be dropped. 데이터베이스를 마이그레이션한 후에는 이러한 개체를 다시 만들 수 있습니다.After the database is migrated, these objects can be recreated. 내구성이 있는 메모리 최적화 테이블은 현재 Hyperscale에서 지원 되지 않으므로 디스크 테이블로 변경 해야 합니다.Durable and non-durable memory-optimized tables are not currently supported in Hyperscale, and must be changed to disk tables.
지역 복제Geo Replication Azure SQL Database Hyperscale에 대해 지역에서 복제를 구성할 수 없습니다.You can't yet configure geo-replication for Azure SQL Database Hyperscale.
데이터베이스 복사Database Copy Hyperscale의 데이터베이스 복사는 현재 공개 미리 보기로 제공 됩니다.Database copy on Hyperscale is now in public preview.
Intelligent Database 기능Intelligent Database Features "강제 계획" 옵션을 제외 하 고 다른 모든 자동 조정 옵션은 Hyperscale에서 아직 지원 되지 않습니다. 옵션은 사용 하도록 설정 된 것 처럼 보일 수 있지만 권장 사항이 나 작업은 적용 되지 않습니다.With the exception of the "Force Plan" option, all other Automatic Tuning options aren't yet supported on Hyperscale: options may appear to be enabled, but there won't be any recommendations or actions made.
Query Performance InsightQuery Performance Insights 쿼리 성능 정보는 현재 Hyperscale 데이터베이스에 대해 지원 되지 않습니다.Query Performance Insights is currently not supported for Hyperscale databases.
데이터베이스 축소Shrink Database DBCC SHRINKDATABASE 또는 DBCC SHRINKFILE는 현재 Hyperscale 데이터베이스에 대해 지원 되지 않습니다.DBCC SHRINKDATABASE or DBCC SHRINKFILE isn't currently supported for Hyperscale databases.
데이터베이스 무결성 검사Database integrity check DBCC CHECKDB는 현재 Hyperscale 데이터베이스에 대해 지원 되지 않습니다.DBCC CHECKDB isn't currently supported for Hyperscale databases. DBCC CHECKFILEGROUP 및 DBCC CHECKTABLE를 해결 방법으로 사용할 수 있습니다.DBCC CHECKFILEGROUP and DBCC CHECKTABLE may be used as a workaround. Azure SQL Database의 데이터 무결성 관리에 대 한 자세한 내용은 Azure SQL Database의 데이터 무결성 을 참조 하세요.See Data Integrity in Azure SQL Database for details on data integrity management in Azure SQL Database.

다음 단계Next steps