Azure Database for MySQL - 유연한 서버 서비스 계층
적용 대상:
Azure Database for MySQL - 유연한 서버
버스트 가능, 범용, 중요 비즈니스의 세 가지 서비스 계층 중 하나에서 Azure Database for MySQL 유연한 서버 인스턴스를 만들 수 있습니다. 서비스 계층은 B 시리즈, D 시리즈 및 E 시리즈를 사용하는 기본 VM SKU로 구분됩니다. 컴퓨팅 계층과 크기를 선택하면 서버에서 사용할 수 있는 메모리 및 vCore가 결정됩니다. 모든 서비스 계층에서 동일한 스토리지 기술이 사용됩니다. 모든 리소스는 Azure Database for MySQL 유연한 서버 인스턴스 수준에서 프로비전됩니다. 서버는 하나 이상의 데이터베이스를 갖출 수 있습니다.
| 리소스/계층 | 버스터 가능 | 범용 | 중요 비즈니스용 |
|---|---|---|---|
| VM 시리즈 | B 시리즈 | Dadsv5 시리즈Ddsv4 시리즈 | Edsv4/Edsv5 시리즈*/Eadsv5 시리즈 |
| vCore 수 | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| vCore 메모리 | 변수 | 4GiB | 8GiB ** |
| 스토리지 크기 | 20GiB~16TiB | 20GiB~16TiB | 20GiB~16TiB |
| 데이터베이스 백업 보존 기간 | 1~35일 | 1~35일 | 1~35일 |
** 각각 메모리가 504GiB, 504GiB, 672GiB인 64 vCore, 80 vCore, 96 vCore는 제외됩니다.
* Ev5 컴퓨팅은 QPS 및 대기 시간 측면에서 다른 VM 시리즈 중 최고의 성능을 제공합니다. 여기에서 Ev5 컴퓨팅의 성능 및 지역 가용성에 관해 자세히 알아보세요.
컴퓨팅 계층을 선택하려면 시작 지점으로 다음 표를 사용합니다.
| 컴퓨팅 계층 | 대상 워크로드 |
|---|---|
| 버스트 가능 | 전체 CPU가 지속적으로 필요하지 않은 워크로드에 적합합니다. |
| 범용 | 확장 가능한 I/O 처리량을 갖춘 부하 분산된 컴퓨팅 및 메모리가 필요한 대부분의 비즈니스 워크로드. 예를 들어 웹 및 모바일 앱을 호스트하는 서버와 기타 엔터프라이즈 애플리케이션이 있습니다. |
| 중요 비즈니스용 | 빠른 트랜잭션 처리와 높은 동시성을 위해 메모리 내 성능이 필요한 고성능 데이터베이스 워크로드. 예를 들어 실시간 데이터를 처리하는 서버 및 고성능 트랜잭션 또는 분석 앱이 있습니다. |
서버를 만든 후에 컴퓨팅 계층, 컴퓨팅 크기, 스토리지 크기를 변경할 수 있습니다. 컴퓨팅 크기 조정에는 다시 시작이 필요하고 60-120초 정도 걸리며, 스토리지 크기 조정을 다시 시작하지 않아도 됩니다. 백업 보존 기간을 개별적으로 늘리거나 줄일 수 있습니다. 자세한 내용은 리소스 크기 조정 섹션을 참조하세요.
서비스 계층, 크기 및 서버 유형
계층 및 크기에 따라 컴퓨팅 리소스를 선택할 수 있습니다. vCore 및 메모리 크기를 결정합니다. vCore는 기본 하드웨어의 논리 CPU를 나타냅니다.
버스트 가능에 대한 사용 가능한 서버 유형의 세부 사양은 다음과 같습니다.
| 컴퓨팅 크기 | vCore 수 | 실제 메모리 크기(GiB) | 총 메모리 크기(GiB) | 지원되는 최대 IOPS | 최대 연결 | 임시 스토리지(SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_B1s | 1 | 1 | 1.1 | 320 | 171 | 0 |
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35.2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52.8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
범용에 대한 사용 가능한 서버 유형의 세부 사양은 다음과 같습니다.
| 컴퓨팅 크기 | vCore 수 | 실제 메모리 크기(GiB) | 총 메모리 크기(GiB) | 지원되는 최대 IOPS | 최대 연결 | 임시 스토리지(SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
중요 비즈니스용에 대한 사용 가능한 서버 유형의 세부 사양은 다음과 같습니다.
| 컴퓨팅 크기 | vCore 수 | 실제 메모리 크기(GiB) | 총 메모리 크기(GiB) | 지원되는 최대 IOPS | 최대 연결 | 임시 스토리지(SSD) GiB |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v4 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ids_v4 | 80 | 504 | 693 | 72000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Azure Database for MySQL 유연한 서버의 메모리 관리
MySQL에서 메모리는 쿼리 처리 및 캐싱을 비롯한 다양한 작업에서 중요한 역할을 합니다. Azure Database for MySQL 유연한 서버는 MySQL 서버 프로세스(mysqld)에 대한 메모리 할당을 최적화하여 MySQL이 효율적인 쿼리 처리, 캐싱, 클라이언트 연결 관리 및 스레드 처리를 위한 충분한 메모리 리소스를 받도록 합니다. MySQL이 메모리를 사용하는 방법 자세히 알아보기.
실제 메모리 크기(GB)
아래 표의 실제 메모리 크기(GB)는 Azure Database for MySQL 유연한 서버에서 사용 가능한 RAM(임의 액세스 메모리)(GB)을 나타냅니다.
총 메모리 크기(GB)
Azure Database for MySQL 유연한 서버는 총 메모리 크기(GB)를 제공합니다. 이는 실제 메모리와 임시 스토리지 SSD 구성 요소의 집합 양의 조합인 서버에서 사용할 수 있는 총 메모리를 나타냅니다. 이 통합 보기는 리소스 관리를 간소화하도록 설계되어 있어 사용자는 Azure MySQL Server(mysqld) 프로세스에서만 사용할 수 있는 총 메모리에 집중할 수 있습니다. 메모리 백분율(memory_percent) 메트릭은 Azure MySQL 서버 프로세스(mysqld)가 차지하는 메모리의 백분율을 나타냅니다. 이 메트릭은 총 메모리 크기(GB)에서 계산됩니다. 예를 들어 메모리 비율 메트릭에 값 60이 표시되면 이는 Azure MySQL 서버 프로세스가 Azure Database for MySQL 유연한 서버에서 사용할 수 있는 총 메모리 크기(GB)의 60%를 활용하고 있음을 의미합니다.
MySQL 서버(mysqld)
MySQL 서버 프로세스인 mysqld는 데이터베이스 작업의 핵심 엔진 역할을 합니다. 시작 시 구성과 워크로드 요구에 따라 메모리를 활용하여 InnoDB 버퍼 풀 및 스레드 캐시와 같은 총 구성 요소를 초기화합니다. 예를 들어 InnoDB 버퍼 풀은 자주 액세스하는 데이터와 인덱스를 캐시하여 쿼리 실행 속도를 향상하는 반면 스레드 캐시는 클라이언트 연결 스레드를 관리합니다. 자세히 알아보기.
InnoDB 스토리지 엔진
MySQL의 기본 스토리지 엔진인 InnoDB는 메모리를 사용하여 자주 액세스하는 데이터를 캐시하고 innodb 버퍼 풀 및 로그 버퍼같은 내부 구조를 관리합니다. InnoDB 버퍼 풀은 테이블 데이터와 인덱스를 메모리에 보관하여 디스크 I/O를 최소화해 성능을 향상합니다. InnoDB 버퍼 풀 크기 매개 변수는 서버에서 사용할 수 있는 실제 메모리 크기(GB)를 기반으로 계산됩니다. Azure Database for MySQL 유연한 서버에서 사용 가능한 InnoDB 버퍼 풀 크기에 관해 자세히 알아보세요.
스레드
클라이언트 연결은 연결 관리자가 처리하는 전용 스레드를 통해 관리됩니다. 이러한 스레드는 클라이언트 상호 작용에 대한 인증, 쿼리 실행 및 결과 검색을 처리합니다. 자세히 알아보기.
사용 가능한 컴퓨팅 시리즈에 대한 자세한 내용을 보려면 버스트 가능(B 시리즈), 범용 Dadsv5 시리즈Ddsv4 시리즈 및 중요 비즈니스용 Edsv4/Edsv5 시리즈/Eadsv5 시리즈에 대한 Azure VM 설명서를 참조하세요.
버스트 가능한 시리즈 인스턴스의 성능 제한 사항
참고 항목
VM을 시작/중지하거나 다시 시작하는 경우 버스트 가능(B 시리즈) 컴퓨팅 계층의 경우 크레딧이 손실될 수 있습니다. 자세한 내용은 버스트 가능(B 시리즈) FAQ를 참조하세요.
버스트 가능한 컴퓨팅 계층은 전체 CPU를 지속적으로 필요로 하지 않은 워크로드에 비용 효율적인 솔루션을 제공하기 위해 설계되었습니다. 이 계층은 개발이나 스테이징, 테스트 환경 등의 비프로덕션 워크로드에 적합합니다. 버스트 가능한 컴퓨팅 계층만의 고유 기능은 워크로드에 필요할 때 vCPU의 최대 100%를 사용하여 기본 CPU 성능을 초과하는 수준으로 활용하는 "버스트" 기능입니다. 이는 CPU 사용량이 적을 때 B 시리즈 인스턴스가 "CPU 크레딧"을 누적할 수 있도록 하는 CPU 크레딧 모델을 통해 가능합니다. 이렇게 하면 이렇게 모은 크레딧을 CPU 사용량이 많은 기간 동안 사용할 수 있으므로 인스턴스가 기본 CPU 성능 이상으로 버스트할 수 있습니다.
그러나 버스트 가능한 인스턴스라도 CPU 크레딧을 소진하면 기본 CPU 성능으로 작동한다는 점에 유의해야 합니다. 예를 들어 Standard_B1ms의 기본 CPU 성능은 20%, 즉 0.2 Vcore입니다. 버스트 가능 계층 서버가 CPU 성능을 기본 수준 이상으로 요구하는 워크로드를 실행하여 CPU 크레딧이 소진된 경우 서버에 성능 제한이 발생할 수 있으며 결국 해당 서버의 중지/시작/다시 시작과 같은 다양한 시스템 작업에 영향을 줄 수 있습니다.
참고 항목
Standard_B1s/Standard_B1ms/Standard_B2s와 같은 버스트 가능(B 시리즈) 컴퓨팅 계층에 있는 서버의 경우 상대적으로 작은 호스트 메모리 크기는 memory_percent 메트릭이 100%에 도달하지 않은 경우에도 연속 워크로드에서 충돌(메모리 부족)을 일으킬 수 있습니다.
이러한 제한으로 인해 서버에서 연결 문제가 발생할 수 있으며 시스템 작업이 영향을 받을 수 있습니다. 이러한 상황에서 권장되는 작업은 B 시리즈 크레딧 뱅킹 모델에 따라 크레딧을 누적하도록 서버 워크로드를 일시 중지하거나 범용 또는 중요 비즈니스용 계층과 같은 상위 계층으로 서버를 확장하는 것을 고려하는 것입니다.
따라서 버스트 가능 컴퓨팅 계층은 특정 유형의 워크로드에 비용이나 유연성에서 상당한 이점을 제공하지만 일관된 CPU 성능이 필요한 프로덕션 워크로드에는 바람직하지 않습니다. 버스트 가능 계층은 읽기 복제본 만들기 및 고가용성 기능을 지원하지 않습니다. 이러한 워크로드 및 기능의 경우 범용 또는 중요 비즈니스용과 같은 다른 컴퓨팅 계층이 더 적합합니다.
Azure의 B 시리즈 CPU 크레딧 모델에 대한 자세한 내용은 B 시리즈 버스트 가능 인스턴스 및 B 시리즈 CPU 크레딧 모델을 참조하세요.
버스트 가능 계층의 CPU 크레딧 모니터링
잔여 CPU 크레딧을 모니터링하는 것은 버스트 가능 컴퓨팅 계층의 성능을 최적으로 유지하는 데 중요합니다. Azure Database for MySQL 유연한 서버는 CPU 크레딧과 관련된 두 가지 주요 메트릭을 제공합니다. 경고 트리거를 위한 이상적인 임계값은 구체적인 워크로드 및 성능 요구 사항에 따라 달라집니다.
사용 CPU 크레딧: 이 메트릭은 인스턴스에서 사용하는 CPU 크레딧의 양을 나타냅니다. 이 메트릭을 모니터링하면 인스턴스의 CPU 사용 패턴을 이해하고 성능을 효과적으로 관리하는 데 도움이 될 수 있습니다.
잔여 CPU 크레딧: 이 메트릭은 인스턴스에 남아 있는 CPU 크레딧의 양을 보여 줍니다. 이 메트릭을 계속 살펴보면 CPU 크레딧이 소진되어 인스턴스의 성능이 저하되는 것을 예방할 수 있습니다. 잔여 CPU 크레딧 메트릭이 특정 수준(예: 사용 가능한 총 크레딧의 30% 미만) 아래로 떨어지는 경우는 현재 수준의 CPU 부하가 계속되면 인스턴스가 CPU 크레딧을 소진할 위험이 있음을 나타냅니다.
메트릭에 대한 경고 설정 방법에 대해서는 이 가이드를 참조하여 자세한 내용을 확인하세요.
스토리지
프로비전하는 스토리지는 유연한 서버에 사용할 수 있는 스토리지 용량입니다. 스토리지는 데이터베이스 파일, 임시 파일, 트랜잭션 로그 및 MySQL 서버 로그에 사용됩니다. 모든 서비스 계층에서 지원되는 최소 스토리지는 20GiB이고 최대 스토리지는 16TiB입니다. 스토리지는 1GiB 증분 단위로 크기 조정되며 서버를 만든 후에 스케일 업할 수 있습니다.
참고 항목
스토리지는 스케일 다운이 아닌 스케일 업만 가능합니다.
스토리지 제한, 스토리지 비율 및 스토리지 사용 메트릭을 사용하여 Azure Portal(Azure Monitor와 함께)에서 스토리지 사용량을 모니터링할 수 있습니다. 메트릭에 대한 자세한 내용은 모니터링 문서를 참조하세요.
스토리지 제한에 도달
서버에서 사용되는 스토리지가 프로비전된 한도에 거의 도달하면 서버에서 읽기 전용 모드로 전환하여 서버에서 손실되는 쓰기를 보호합니다. 프로비전된 스토리지가 100GiB 이하인 서버는 사용 가능한 스토리지가 프로비전된 스토리지 크기의 5% 미만인 경우 읽기 전용으로 표시됩니다. 프로비전된 스토리지가 100GiB보다 큰 서버는 사용 가능한 스토리지가 5GiB 미만인 경우에만 읽기 전용으로 표시됩니다.
예를 들어 110GiB의 스토리지를 프로비전하고 실제 활용이 105GiB를 넘어서는 경우 서버는 읽기 전용으로 표시됩니다. 또는 5GiB 스토리지를 프로비전하는 경우 서버는 여유 저장 공간이 256MB 미만이 되면 읽기 전용으로 표시됩니다.
서비스가 서버를 읽기 전용으로 만들려고 하는 동안 모든 새 쓰기 트랜잭션 요청이 차단되며 기존 활성 트랜잭션은 계속 실행됩니다. 서버가 읽기 전용으로 설정되면 모든 후속 쓰기 작업 및 트랜잭션 커밋은 실패합니다. 읽기 쿼리는 중단 없이 계속 작동합니다.
서버를 읽기 전용 모드로 설정하려면 서버에서 프로비전된 스토리지를 늘려야 합니다. 이 작업은 Azure Portal 또는 Azure CLI를 사용하여 수행할 수 있습니다. 늘어난 후 서버는 다시 쓰기 트랜잭션을 허용할 준비를 갖춥니다.
서버 스토리지가 임계값에 근접하는 경우 읽기 전용 상태로 들어가는 것을 방지할 수 있도록 알림 경고를 설정하는 것이 좋습니다. 자세한 내용은 경고 설명서 경고 설정 방법의 설명서를 참조하세요.
스토리지 자동 증가
스토리지 자동 증가는 서버가 스토리지가 부족해지고 읽기 전용이 되지 않도록 방지합니다. 스토리지 자동 증가를 사용하도록 설정하면 워크로드에 영향을 주지 않고 스토리지가 자동으로 증가합니다. 스토리지 자동 증가는 모든 새 서버 생성에 대해 기본적으로 활성화됩니다. 프로비전된 스토리지가 100GB보다 작거나 같은 서버의 경우, 사용 가능한 스토리지 공간이 프로비전된 스토리지 크기의 10% 미만이면 프로비전된 스토리지 크기가 5GB씩 증가합니다. 프로비전된 스토리지가 100GB를 초과하는 서버의 경우, 사용 가능한 스토리지 공간이 10GB의 프로비전된 스토리지 크기 미만이면 프로비전된 스토리지 크기가 5%씩 증가합니다. 위에 지정된 대로 최대 스토리지 제한이 적용됩니다. 서버 인스턴스를 새로 고쳐 컴퓨팅 + 스토리지 페이지의 설정에서 프로비전되는 업데이트된 스토리지를 확인합니다.
예를 들어 1,000GB의 스토리지를 프로비전하고 실제 사용률이 990GB를 넘으면 서버 스토리지 크기가 1,050GB로 증가합니다. 또는 20GB의 스토리지를 프로비전한 경우 사용 가능한 스토리지가 2GB 미만이면 스토리지 크기가 25GB로 증가합니다.
자동 스케일 업된 스토리지는 스케일 다운할 수 없습니다.
참고 항목
스토리지 자동 증가는 고가용성 구성 서버에 대해 기본적으로 사용하도록 설정되며 사용하지 않도록 설정할 수 없습니다.
IOPS
Azure Database for MySQL 유연한 서버는 미리 프로비전된 IOPS와 자동 크기 조정 IOPS를 지원합니다. 자세히 알아보기. 최소 IOPS는 모든 컴퓨팅 크기에서 360이고, 최대 IOPS는 선택한 컴퓨팅 크기로 결정됩니다. 컴퓨팅 크기별 최대 IOPS에 대한 자세한 내용은 표를 참조하세요.
Important
**최소 IOPS는 모든 컴퓨팅 크기에서 360입니다.
**최대 IOPS는 선택한 컴퓨팅 크기로 결정됩니다.
IO 백분율 메트릭을 사용하여 Azure Portal(Azure Monitor와 함께)에서 I/O 사용량을 모니터링할 수 있습니다. 컴퓨팅을 기반으로 하는 최대 IOPS보다 더 많은 IOPS가 필요한 경우 서버 컴퓨팅을 스케일링해야 합니다.
미리 프로비전된 IOPS
Azure Database for MySQL 유연한 서버는 미리 프로비전된 IOPS를 제공하므로 Azure Database for MySQL 유연한 서버 인스턴스에 IOPS 수량을 구체적으로 할당할 수 있습니다. 이 설정은 워크로드에 대한 성능을 일관적으로 유지하고 예측 가능하도록 보장합니다. 미리 프로비전된 IOPS를 사용하면 스토리지 볼륨에 대한 구체적인 IOPS 제한을 정의하여 초당 일부 요청을 처리하는 기능을 보장할 수 있습니다. 이는 안정적이고 확실한 성능 수준으로 이어집니다. 미리 프로비전된 IOPS를 사용하면 IOPS 제한을 초과하는 추가 IOPS를 프로비전할 수 있습니다. 이 기능을 사용하여 언제든지 워크로드 요구 사항에 따라 프로비저닝된 IOPS 수를 늘리거나 줄일 수 있습니다.
IOPS 자동 크기 조정
Azure Database for MySQL 유연한 서버의 초석은 서버가 워크로드 요구 사항에 따라 데이터베이스 서버의 IO(자동 크기 조정 성능)를 사용하도록 설정하여 개선할 수 있는 계층 1 워크로드에 대한 최상의 성능을 달성하는 기능입니다. 사용자가 초당 특정 양의 IO를 미리 프로비전하지 않고도 요청 시 IOPS를 확장할 수 있는 옵트인 기능입니다. 자동 크기 조정 IOPS 기능을 사용하도록 설정하면 이제 워크로드 요구 사항에 따라 서버가 IOP를 자동으로 확장 또는 축소하기 때문에 Azure Database for MySQL 유연한 서버에서 쾌적하게 IO를 관리할 수 있습니다.
자동 크기 조정 IOPS를 사용하면 서버에서 사용하는 IO에 대해서만 비용을 지불하고 더 이상 완전히 사용하지 않는 리소스를 프로비전하고 비용을 지불할 필요가 없으므로 시간과 비용 모두 절약할 수 있습니다. 또한 중요 업무용 계층 1 애플리케이션은 언제든지 워크로드에서 추가 IO를 사용할 수 있도록 하여 일관된 성능을 달성할 수 있습니다. 자동 크기 조정 IOPS를 사용하면 관리 없이도 Azure Database for MySQL 유연한 서버 고객에게 최소 비용으로 최상의 성능을 제공할 수 있습니다.
동적 크기 조정: 자동 크기 조정 IOPS는 사용 중인 워크로드의 실제 수요에 따라 데이터베이스 서버의 IOPS 제한을 동적으로 조정합니다. 이렇게 하면 수동으로 개입하거나 구성하지 않아도 최적의 성능을 보장합니다.
워크로드 급증 처리: 자동 크기 조정 IOPS를 사용하면 애플리케이션의 성능을 손상시키지 않으면서 데이터베이스가 워크로드 급증이나 급격한 변동을 원활하게 처리할 수 있습니다. 이 기능은 사용량이 많은 기간 중에도 일관된 응답성을 보장합니다.
비용 절감: 사용량에 관계없는 고정 IOPS 제한을 지정하고 지불하는 미리 프로비전된 IOPS와 달리, 자동 크기 조정 IOPS를 사용하면 사용한 I/O 작업 수량에 맞게 비용을 지불할 수 있습니다.
Backup
서비스에서 서버 백업을 자동으로 수행합니다. 보존 기간은 1~35일 사이의 범위로 선택할 수 있습니다. 백업 및 복원 개념 문서에서 백업에 대해 자세히 알아보세요.
리소스 스케일링
서버를 만든 후 컴퓨팅 계층, 컴퓨팅 크기(vCore 및 메모리), 스토리지의 양 및 백업 보존 기간을 독립적으로 변경할 수 있습니다. 컴퓨팅 크기를 스케일 업하거나 다운할 수 있습니다. 백업 보존 기간은 1~35일 범위에서 늘리거나 줄일 수 있습니다. 스토리지 크기는 늘릴 수 있습니다. 리소스의 크기 조정은 포털 또는 Azure CLI를 통해 수행할 수 있습니다.
참고 항목
스토리지 크기는 늘릴 수 있습니다. 증가한 후에는 더 작은 스토리지 크기로 다시 이동할 수 없습니다.
컴퓨팅 계층 또는 컴퓨팅 크기를 변경하면 새 서버 유형을 적용하기 위해 서버가 다시 시작됩니다. 시스템이 새 서버로 전환되면 잠시 동안 새 연결을 설정할 수 없으며, 커밋되지 않은 모든 트랜잭션이 롤백됩니다. 이 창은 다르지만 대부분의 경우는 60-120초 사이입니다.
스토리지 크기 조정 및 백업 보존 기간 변경은 온라인 작업이며 서버를 다시 시작하지 않아도 됩니다.
가격 책정
최신 가격 책정 정보는 서비스 가격 책정 페이지를 참조하세요. 원하는 구성 비용을 확인하려면 Azure Portal에서 선택한 옵션에 따라 컴퓨팅 + 스토리지 탭에 월별 비용이 표시됩니다. Azure 구독이 없는 경우 Azure 가격 책정 계산기를 사용하여 예상 가격을 구할 수 있습니다. Azure 가격 책정 계산기 웹 사이트에서 항목 추가를 선택하고, 데이터베이스 범주를 확장하고, Azure Database for MySQL을 선택하고, 옵션을 사용자 지정할 배포 유형으로 유연한 서버를 선택합니다.
서버 비용을 최적화하려면 다음 팁을 고려하세요.
- 컴퓨팅의 사용률이 낮은 경우 컴퓨팅 계층 또는 컴퓨팅 크기(vCore)를 스케일 다운합니다.
- 워크로드에 범용 및 중요 비즈니스용 계층에서 전체 컴퓨팅 용량이 지속적으로 필요하지 않은 경우 버스트 가능한 컴퓨팅 계층으로 전환하는 것이 좋습니다.
- 사용하지 않을 때 서버를 중지합니다.
- 더 긴 백업 보존 기간이 필요하지 않은 경우 백업 보존 기간을 줄입니다.
관련 콘텐츠
- 포털에서 Azure Database for MySQL 유연한 서버 인스턴스를 만드는 방법을 알아봅니다.
- 서비스 제한에 대해 알아봅니다.