가동 중지 시간을 최소화하면서 데이터베이스 리소스 크기를 동적으로 조정 - Azure SQL 데이터베이스 및 Azure SQL Managed Instance

  • 아티클

적용 대상:Azure SQL DatabaseAzure SQL Managed Instance

Azure SQL 데이터베이스 및 Azure SQL Managed Instance를 사용하면 가동 중지 시간을 최소화하면서 데이터베이스에 더 많은 리소스를 동적으로 추가할 수 있습니다. 그러나 짧은 시간 동안 데이터베이스에 대한 연결이 끊어지는 전환 기간이 있으므로 재시도 논리를 사용하여 완화할 수 있습니다.

개요

앱에 대한 수요가 적은 상황에서 갑자기 수백만으로 늘어나면, Azure SQL 데이터베이스 및 SQL Managed Instance는 가동 중단 시간을 최소화하면서 즉각적으로 크기를 조정합니다. 확장성은 PaaS(Platform as a Service)의 가장 중요한 특성 중 하나로, 필요할 때 서비스에 더 많은 리소스를 동적으로 추가할 수 있습니다. Azure SQL Database를 사용하면 데이터베이스에 할당된 리소스(CPU 처리 능력, 메모리, IO 처리량 및 스토리지)를 쉽게 변경할 수 있습니다.

인덱싱 또는 쿼리 재작성 방법으로 해결할 수 없는, 애플리케이션 사용량 증가로 인한 성능 문제를 완화할 수 있습니다. 데이터베이스가 현재 리소스 한도에 도달하고 들어오는 워크로드를 처리하기 위해 추가 처리 능력이 필요할 때 리소스를 추가하면 빠르게 대응할 수 있습니다. 또한 Azure SQL 데이터베이스를 사용하면 필요하지 않을 때 리소스를 스케일 다운하여 비용을 낮출 수 있습니다.

하드웨어 구매 및 기본 인프라 변경에 대해 염려할 필요가 없습니다. 슬라이더를 사용하여 Azure Portal을 통해 데이터베이스 크기 조정을 쉽게 수행할 수 있습니다.

Scale database performance

Azure SQL 데이터베이스는 DTU 기반 구매 모델 및 vCore 기반 구매 모델을 제공하는 반면, Azure SQL Managed Instance는 vCore 기반 구매 모델만 제공합니다.

  • DTU 기반 구매 모델은 경량 또는 중량 데이터베이스 워크로드를 지원하기 위해 기본, 표준 및 프리미엄의 세 가지 서비스 계층으로 컴퓨팅, 메모리 및 I/O 리소스를 혼합하여 제공합니다. 각 계층 내의 성능 수준은 이러한 리소스의 다양한 조합을 제공하여 추가 스토리지 리소스를 추가할 수 있습니다.
  • vCore 기반 구매 모델을 통해 vCore 개수, 크기나 메모리 및 스토리지의 크기와 속도를 선택할 수 있습니다. 이 구매 모델은 범용, 중요 비즈니스용, 하이퍼스케일용의 세 가지 서비스 계층을 제공합니다.

데이터베이스, 탄력적 풀 또는 관리되는 인스턴스에 대한 서비스 계층, 컴퓨팅 계층 및 리소스 제한은 수시로 변경할 수 있습니다. 예를 들어 서버리스 컴퓨팅 계층을 사용하여 단일 데이터베이스에 첫 번째 앱을 빌드한 다음, 솔루션의 요구 사항을 충족하기 위해 서비스 계층을 언제든지 수동으로 또는 프로그래밍식으로, 프로비전된 컴퓨팅 계층으로 변경할 수 있습니다.

참고 항목

데이터베이스의 서비스 계층을 변경할 수 없는 예외는 다음과 같습니다.

  • 중요 비즈니스용/프리미엄 서비스 계층에서만 사용할 수 있는 기능을 사용하는 데이터베이스는 범용/표준 서비스 계층을 사용하기 위해 변경할 수 없습니다. 현재 이러한 기능은 메모리 내 OLTP뿐입니다.
  • 원래 하이퍼스케일 서비스 계층에서 만든 데이터베이스는 다른 서비스 계층으로 마이그레이션할 수 없습니다. Azure SQL Database의 기존 데이터베이스를 하이퍼스케일 서비스 계층으로 마이그레이션하는 경우 원래 하이퍼스케일로 마이그레이션한 후 45일 이내에 범용 서비스 계층으로 다시 마이그레이션할 수 있습니다. 중요 비즈니스용과 같은 다른 서비스 계층으로 데이터베이스를 마이그레이션하려면 먼저 범용 서비스 계층으로 역방향 마이그레이션한 다음 추가 마이그레이션을 수행합니다. 하이퍼스케일에서 역방향으로 마이그레이션하는 방법에 대해 자세히 알아봅니다.

워크로드 요구에 맞게 서비스 목표 또는 스케일링을 변경하여 데이터베이스에 할당된 리소스를 조정할 수 있습니다. 또한 필요한 경우 필요한 리소스에 대한 비용만 지불할 수 있습니다. 확장 작업이 애플리케이션에 미칠 수 있는 잠재적 영향에 대해서는 메모를 참조하세요.

Azure SQL Database는 데이터베이스를 동적으로 스케일링하는 기능을 제공합니다.

  • 단일 데이터베베이스를 사용하면 DTU 또는 vCore 모델을 통해 각 데이터베이스에 할당되는 최대 리소스 양을 정의할 수 있습니다.
  • Elastic Pool을 사용하면 풀의 데이터베이스 그룹당 최대 리소스 제한을 정의할 수 있습니다.

Azure SQL Managed Instance를 사용하여 스케일링할 수도 있습니다.

  • SQL Managed Instance는 vCores 모드를 사용하며, 인스턴스에 할당되는 최대 CPU 코어 수와 최대 스토리지 수를 정의할 수 있습니다. 관리되는 인스턴스 내의 모든 데이터베이스가 인스턴스에 할당된 리소스를 공유합니다.

팁

동적 크기 조정을 통해 고객은 수동으로 또는 프로그래밍 방식으로 리소스 할당을 변경할 수 있습니다. 동적 크기 조정 기능은 모든 Azure SQL 데이터베이스 및 Azure SQL Managed Instance 리소스에 사용할 수 있습니다.

동적 크기 조정을 지원하는 것 외에도 Azure SQL 데이터베이스의 서버리스 계층은 자동 크기 조정을 지원합니다. 서버리스 계층의 데이터베이스는 워크로드 수요에 따라 고객이 지정한 범위 내에서 리소스 크기를 자동으로 조정합니다. 데이터베이스 크기를 조정하기 위해 고객 작업이 필요하지는 않습니다.

스케일 업 또는 스케일 다운 작업의 영향

위에서 언급한 모든 버전에서 스케일 업 또는 스케일 다운 작업을 시작하면 데이터베이스 엔진 프로세스가 다시 시작되고 필요한 경우 다른 가상 머신으로 이동합니다. 데이터베이스 엔진 프로세스를 새 가상 머신으로 이동하는 작업은 기존 Azure SQL Database 서비스를 계속 사용할 수 있는 온라인 프로세스입니다. 대상 데이터베이스 엔진이 쿼리를 처리할 준비가 되면 현재 데이터베이스 엔진에 대해 열린 연결이 종료되고 커밋되지 않은 트랜잭션이 롤백됩니다. 대상 데이터베이스 엔진에 새 연결이 설정됩니다.

참고 항목

데이터 가져오기, 데이터 처리 작업, 인덱스 재작성 등과 같은 장기 실행 트랜잭션이 실행 중이거나 인스턴스에 활성 연결이 있는 경우 Managed Instance의 크기를 조정하지 않는 것이 좋습니다. 스케일링 완료 시간이 평소보다 오래 걸리지 않도록 하려면 장기 실행 작업이 모두 완료된 후 인스턴스를 스케일링해야 합니다.

참고 항목

스케일 업/스케일 다운 프로세스가 완료되면 짧은 연결 중단을 예측할 수 있습니다. 표준 일시적 오류에 대한 재시도 논리를 구현한 경우 장애 조치(failover)를 확인할 수 없습니다.

대체 크기 조정 방법

리소스 스케일링은 데이터베이스 또는 애플리케이션 코드를 변경하지 않고 데이터베이스의 성능을 향상시키는 가장 쉽고 효과적인 방법입니다. 경우에 따라 가장 높은 서비스 계층, 컴퓨팅 크기 및 성능 최적화조차도 워크로드를 성공적이고 비용 효율적인 방식으로 처리하지 못할 수 있습니다. 이 경우, 데이터베이스 크기를 조정하는 추가 옵션이 있습니다.

  • 읽기 확장은 데이터의 읽기 전용 복제본(replica)이 한 개 있고, 보고서 등 까다로운 읽기 전용 쿼리를 실행할 수 있는 경우에 사용할 수 있는 기능입니다. 읽기 전용 복제본(replica)이 주 데이터베이스의 리소스 사용량에 영향을 주지 않고 읽기 전용 워크로드를 처리합니다.
  • 데이터베이스 분할은 데이터를 여러 데이터베이스로 분할하고 독립적으로 크기를 조정할 수 있습니다.

다음 단계