Azure SQL Database 하이퍼스케일 FAQ

적용 대상:Azure SQL Database

이 문서에서는 이 FAQ의 나머지 부분에서 간단히 하이퍼스케일이라고 하는 Azure SQL Database 하이퍼스케일 서비스 계층의 데이터베이스를 고려하는 고객을 위해 질문과 대답을 제공합니다. 이 문서에서는 하이퍼스케일에서 지원하는 시나리오와 하이퍼스케일과 호환되는 기능에 대해 설명합니다.

  • 이 FAQ는 하이퍼스케일 서비스 계층에 대해 간략히 이해하고 있으며 특정 질문 및 문제에 대한 답변을 원하는 독자를 대상으로 합니다.
  • 이 FAQ는 하이퍼스케일 데이터베이스를 사용하는 방법에 대한 가이드북이나 질문과 대답이 아닙니다. 하이퍼스케일에 대한 소개는 Azure SQL Database 하이퍼스케일 설명서를 참조하는 것이 좋습니다.

일반적인 질문

하이퍼스케일 데이터베이스란 무엇인가요?

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

하이퍼스케일을 지원하는 리소스 종류 및 구매 모델은 무엇인가요?

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

하이퍼스케일 서비스 계층과 범용 및 중요 비즈니스용 서비스 계층 간의 차이점은 무엇인가요?

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

하이퍼스케일 서비스 계층을 사용해야 하는 사용자는 누구인가요?

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

  • 데이터베이스 크기는 최대 100TB입니다.
  • 데이터베이스 크기에 관계없이 빠른 데이터베이스 백업(백업은 스토리지 스냅샷 기반).
  • 데이터베이스 크기에 관계없이 빠른 데이터베이스 복원(복원은 스토리지 스냅샷)입니다.
  • 데이터베이스 크기 및 vCore 수에 관계없이 로그 처리량이 높습니다.
  • 읽기 전용 워크로드를 오프로드하거나 활성 대기 데이터베이스로 사용하는 하나 이상의 읽기 전용 복제본(replica) 사용하여 스케일 아웃을 읽습니다.
  • 일정 시간에 컴퓨팅 스케일링이 신속하게 확장되어, 강력한 기능으로 과도한 워크로드를 수용하고 일정 시간에 규모를 축소할 수 있습니다. 크기 조정 작업은 프로비전된 컴퓨팅의 경우 한 자릿수 분, 데이터베이스 크기에 관계없이 서버리스 컴퓨팅의 경우 1초 미만이 걸립니다.

현재 하이퍼스케일을 지원하는 지역은 어디인가요?

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

서버당 여러 개의 하이퍼스케일 데이터베이스를 만들 수 있나요?

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

하이퍼스케일 데이터베이스의 성능 특성은 무엇인가요?

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

하이퍼스케일 데이터베이스의 확장성은 어떻게 되나요?

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

  • 강화/축소

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

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

  • 규모 감축/확장

    하이퍼스케일을 사용하면 세 가지 종류의 보조 복제본(replica) 사용하여 스케일 아웃, 고가용성 및 지역 복제본(replica) 요구 사항을 읽을 수 있습니다. 다음 내용이 포함됩니다.

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

심층적인 질문

단일 서버에서 하이퍼스케일과 단일 데이터베이스를 혼합할 수 있나요?

예, 할 수 있습니다.

하이퍼스케일을 사용하려면 내 애플리케이션 프로그래밍 모델을 변경해야 하나요?

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

하이퍼스케일 데이터베이스의 기본 트랜잭션 격리 수준은 어떻게 되나요?

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

온-프레미스 또는 IaaS SQL Server 라이선스를 하이퍼스케일로 가져올 수 있나요?

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

하이퍼스케일은 어떤 종류의 워크로드를 위해 설계되었나요?

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

Azure Synapse Analytics와 Azure SQL Database 하이퍼스케일 중에서 선택하려면 어떻게 해야 하나요?

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

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

하이퍼스케일 컴퓨팅 질문

언제든지 컴퓨팅을 일시 중지할 수 있나요?

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

메모리 사용량이 많은 워크로드를 위해 추가 RAM이 있는 컴퓨팅 복제본을 프로비전할 수 있나요?

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

크기가 다른 여러 개의 컴퓨팅 복제본을 프로비전할 수 있나요?

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

지원되는 읽기 확장 복제본의 수는 얼마인가요?

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

고가용성을 위해 추가 컴퓨팅 복제본을 프로비전해야 하나요?

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

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

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

데이터 크기 및 스토리지 질문

하이퍼스케일에서 지원되는 최대 데이터베이스 크기는 얼마인가요?

100TB입니다.

하이퍼스케일의 트랜잭션 로그 크기는 얼마인가요?

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

데이터베이스가 커지면 ‘tempdb’가 스케일링되나요?

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

데이터베이스 크기가 자동으로 확장되나요? 아니면 데이터 파일의 크기를 관리해야 하나요?

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

하이퍼스케일에서 지원하는 최소 데이터베이스 크기는 얼마인가요?

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

내 데이터베이스가 확장하는 증분의 크기는 얼마인가요?

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

하이퍼스케일의 스토리지는 로컬인가요? 아니면 원격인가요?

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

하이퍼스케일을 사용하여 파일 또는 파일 그룹을 관리하거나 정의할 수 있나요?

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

내 데이터베이스의 데이터 증가에 대한 하드 캡을 프로비전할 수 있나요?

아니요.

데이터베이스 축소가 지원되나요?

지금은 없습니다.

데이터 압축이 지원되나요?

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

매우 큰 테이블이 있는 경우 테이블 데이터가 여러 데이터 파일에 분산되나요?

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

데이터 마이그레이션 질문

Azure SQL Database의 기존 데이터베이스를 하이퍼스케일 서비스 계층으로 이동할 수 있나요?

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

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

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

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

하이퍼스케일 데이터베이스를 다른 서비스 계층으로 이동할 수 있나요?

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

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

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

하이퍼스케일 서비스 계층으로 마이그레이션하면 기능이 손실되나요?

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

온-프레미스 SQL Server 데이터베이스 또는 클라우드 가상 머신의 SQL Server 데이터베이스를 하이퍼스케일로 이동할 수 있나요?

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

온-프레미스 또는 가상 머신 환경에서 하이퍼스케일로 마이그레이션하는 동안 가동 중지 시간은 얼마이며, 최소화하려면 어떻게 해야 하나요?

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

X 크기의 데이터를 하이퍼스케일로 가져오는 데 걸리는 시간은 얼마인가요?

하이퍼스케일은 100MB/s의 새 데이터 또는 변경된 데이터를 사용할 수 있지만, 데이터를 Azure SQL Database의 데이터베이스로 이동하는 데 필요한 시간은 사용 가능한 네트워크 처리량, 원본 읽기 속도 및 대상 데이터베이스 서비스 수준 목표의 영향도 받습니다.

Blob Storage에서 데이터를 읽고 빠른 로드(예: Azure Synapse Analytics의 Polybase)를 수행할 수 있나요?

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(대규모 병렬 처리) 또는 다중 마스터 아키텍처가 아닙니다. 여러 개의 복제본을 만들어서 읽기 전용 워크로드 규모 확장할 수만 있습니다.

하이퍼스케일에서 Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2 및 기타 데이터베이스 플랫폼과 같은 다른 데이터 원본으로부터의 마이그레이션을 지원하나요?

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

비즈니스 연속성 및 재해 복구 질문

하이퍼스케일 데이터베이스에 어떤 SLA가 제공되나요?

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

내 Azure SQL Database에서 데이터베이스 백업을 관리하나요?

예.

하이퍼스케일은 가용성 영역을 지원하나요?

예, 하이퍼스케일은 영역 중복 구성을 지원합니다. 하이퍼스케일에 대해 영역 중복 구성을 사용하도록 설정하려면 하나 이상의 HA 보조 복제본(replica) 영역 중복 또는 지역 영역 중복 스토리지를 사용해야 합니다. 영역 중복 하이퍼스케일 이름 복제본(replica) 대한 지원은 현재 미리 보기로 제공됩니다.

하이퍼스케일은 탄력적 풀을 지원하나요?

예. 하이퍼스케일 탄력적 풀은 현재 미리 보기로 제공됩니다. 영역 중복 하이퍼스케일 탄력적 풀도 현재 미리 보기로 제공됩니다.

데이터베이스 백업이 얼마나 자주 수행되나요?

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

하이퍼스케일에서 특정 시점 복원을 지원하나요?

예.

하이퍼스케일에서 데이터베이스 복원에 대한 RPO(복구 지점 목표)/RTO(복구 시간 목표)는 무엇인가요?

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

데이터베이스 백업이 주 또는 보조 복제본의 컴퓨팅 성능에 영향을 주나요?

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

하이퍼스케일 데이터베이스를 사용하여 지역 복원을 수행할 수 있나요?

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

하이퍼스케일 데이터베이스를 사용하여 지역 복제를 설정할 수 있나요?

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

하이퍼스케일 데이터베이스 백업을 가져와서 온-프레미스 서버 또는 VM의 SQL Server에 복원할 수 있나요?

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

하이퍼스케일의 백업 스토리지 비용에 대한 요금이 청구되나요?

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

하이퍼스케일 데이터베이스에서 백업 스토리지 크기를 측정하려면 어떻게 해야 하나요?

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

백업 청구서가 얼마나 나올지를 어떻게 알 수 있나요?

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

워크로드가 백업 스토리지 비용에 어떤 영향을 주나요?

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

백업 스토리지 비용을 최소화하려면 어떻게 해야 하나요?

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

성능 질문

하이퍼스케일 데이터베이스에서 푸시할 수 있는 쓰기 처리량은 얼마인가요?

트랜잭션 로그 처리량 상한은 하이퍼스케일 컴퓨팅 크기에 대해 100MB/s로 설정됩니다. 이 속도를 달성하는 기능은 워크로드 유형, 클라이언트 구성 및 성능, 이 속도로 로그 레코드를 생성할 수 있는 기본 컴퓨팅 복제본(replica) 충분한 컴퓨팅 용량을 포함하지만 이에 국한되지 않는 여러 요인에 따라 달라집니다.

가장 큰 컴퓨팅에서 달성할 수 있는 IOPS는 얼마인가요?

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

내 처리량이 백업의 영향을 받나요?

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

추가 컴퓨팅 복제본을 프로비전하면 내 처리량에 영향을 주나요?

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

하이퍼스케일은 리소스 집약적이고 장기 실행 쿼리 및 트랜잭션에 적합합니까?

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

하이퍼스케일 데이터베이스의 성능 문제를 진단하고 해결하려면 어떻게 할까요?

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

서버리스의 최대 메모리 제한은 프로비전된 컴퓨팅과 어떻게 비교됩니까?

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

확장성 질문

컴퓨팅 복제본을 스케일 업 및 스케일 다운하는 데 얼마나 걸리나요?

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

스케일 업 또는 스케일 다운 작업을 진행하는 동안 내 데이터베이스는 오프라인 상태인가요?

아니요. 데이터베이스를 다시 기본 스케일 업 또는 스케일 다운 작업 중에 온라인 상태입니다.

크기 조정 작업이 진행 중일 때 연결이 끊어질 것으로 예상해야 하나요?

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

컴퓨팅 복제본의 스케일 업 및 스케일 다운은 자동인가요? 아니면 최종 사용자가 트리거하는 작업인가요?

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

컴퓨팅이 스케일 업되면 ‘tempdb’ 데이터베이스와 RBPEX 캐시의 크기도 증가하나요?

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

여러 주 컴퓨팅 헤드에서 더 높은 수준의 동시성을 구동할 수 있는 다중 마스터 시스템과 같은 여러 주 컴퓨팅 복제본을 프로비전할 수 있나요?

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

읽기 확장 질문

하이퍼스케일에서 사용할 수 있는 보조(읽기 확장) 복제본의 종류는 무엇인가요?

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

프로비저닝할 수 있는 HA 보조 복제본의 수는 얼마인가요?

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

HA 보조 복제본에 어떻게 연결하나요?

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

SSMS(SQL Server Management Studio) 또는 기타 클라이언트 도구를 사용하여 보조 컴퓨팅 복제본(replica) 성공적으로 연결했는지 어떻게 할까요? 확인하시겠습니까?

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

HA 보조 복제본에 대한 전용 엔드포인트를 만들 수 있나요?

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

시스템이 HA 보조 복제본(replica) 읽기 전용 워크로드의 지능형 부하 분산을 수행하나요?

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

주 복제본과 별도로 HA 보조 복제본을 스케일 업/스케일 다운할 수 있나요?

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

주 컴퓨팅과 HA 보조 복제본에 대한 `tempdb` 크기 조정이 다른가요?

아니요. tempdb 데이터베이스는 프로비전된 컴퓨팅 크기에 따라 구성됩니다. HA 보조 복제본(replica) 기본 컴퓨팅과 같은 tempdb크기입니다. 명명된 복제본(replica)tempdb 복제본(replica) 컴퓨팅 크기에 따라 크기가 조정되므로 주 복제본(replica) 크기보다 tempdb 작거나 클 수 있습니다.

인덱스와 보기를 보조 컴퓨팅 복제본에 추가할 수 있나요?

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

주 컴퓨팅 복제본과 보조 컴퓨팅 복제본 사이의 지연 시간은 얼마인가요?

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

명명된 복제본을 장애 조치(failover) 대상으로 사용할 수 있나요?

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

읽기 전용 워크로드를 명명된 복제본 간에 분산하려면 어떻게 해야 하나요?

명명된 모든 복제본(replica) 다른 서비스 수준 목표를 가질 수 있으므로 다른 사용 사례에 사용할 수 있으므로 기본으로 전송되는 읽기 전용 트래픽을 명명된 복제본(replica) 집합으로 보내는 기본 제공 방법은 없습니다. 예를 들어 8개의 명명된 복제본(replica) 가질 수 있으며, OLTP 워크로드를 명명된 복제본(replica)s 1에서 4로만 지정하는 반면, Power BI 분석 워크로드는 명명된 복제본(replica)s 5와 6을 사용하고 데이터 과학 워크로드는 복제본(replica)s 7과 8을 사용합니다. 사용하는 도구 또는 프로그래밍 언어에 따라 이러한 워크로드를 배포하는 전략이 달라질 수 있습니다. REST 백 엔드를 스케일 아웃할 수 있도록 워크로드 라우팅 솔루션을 만드는 예제는 OLTP 스케일 아웃 샘플을 검토합니다.

명명된 복제본이 주 복제본의 지역과 다른 지역에 있을 수 있나요?

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

명명된 복제본에서 주 복제본의 가용성 또는 성능에 영향을 줄 수 있나요?

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

예를 들어 계획된 기본 테넌트 때문에 기본 복제본(replica) 사용할 수 없는 경우 명명된 복제본(replica) 어떻게 되나요?

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

명명된 복제본의 가용성을 향상시키려면 어떻게 해야 하나요?

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

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