Azure Database for MySQL - 단일 서버 서비스 계층
적용 대상: 
Azure Database for MySQL - 단일 서버
Important
Azure Database for MySQL 단일 서버는 사용 중지를 향한 여정에 있습니다. Azure Database for MySQL 유연한 서버로 업그레이드하는 것이 좋습니다. Azure Database for MySQL 유연한 서버로 마이그레이션하는 방법에 대한 자세한 내용은 Azure Database for MySQL 단일 서버에 대한 현재 상황을 참조하세요.
Azure Database for MySQL 서버는 기본, 범용 및 메모리 최적화의 세 가지 서비스 계층 중 하나에서 만들 수 있습니다. 서비스 계층은 프로비전할 수 있는 컴퓨팅의 vCore 수, vCore당 메모리 및 데이터를 저장하는 데 사용되는 스토리지 기술로 구분됩니다. 모든 리소스는 MySQL 서버 수준에서 프로비전됩니다. 서버는 하나 이상의 데이터베이스를 갖출 수 있습니다.
| Attribute | 기본 | 범용 | 메모리 최적화 |
|---|---|---|---|
| 컴퓨팅 세대 | 4세대, 5세대 | 4세대, 5세대 | 5세대 |
| vCore 수 | 1, 2 | 2, 4, 8, 16, 32, 64 | 2, 4, 8, 16, 32 |
| vCore 메모리 | 2GB | 5GB | 10 GB |
| 스토리지 크기 | 5GB-1TB | 5GB~16TB | 5GB~16TB |
| 데이터베이스 백업 보존 기간 | 7-35일 | 7-35일 | 7-35일 |
가격 책정 계층을 선택하려면 시작 지점으로 다음 표를 사용합니다.
| 서비스 계층 | 대상 워크로드 |
|---|---|
| Basic | 간단한 컴퓨팅 및 I/O 성능이 필요한 워크로드. 예를 들어 개발 또는 시험, 또는 자주 사용하지 않는 소규모 애플리케이션에 사용되는 서버가 이에 해당합니다. |
| 범용 | 확장 가능한 I/O 처리량을 갖춘 부하 분산된 컴퓨팅 및 메모리가 필요한 대부분의 비즈니스 워크로드. 예를 들어 웹 및 모바일 앱을 호스트하는 서버와 기타 엔터프라이즈 애플리케이션이 있습니다. |
| 메모리 최적화 | 빠른 트랜잭션 처리와 높은 동시성을 위해 메모리 내 성능이 필요한 고성능 데이터베이스 워크로드. 예를 들어 실시간 데이터를 처리하는 서버 및 고성능 트랜잭션 또는 분석 앱이 있습니다. |
참고 항목
기본 서비스 계층 간의 동적 크기 조정은 현재 지원되지 않습니다. 기본 계층 SKU 서버는 범용 또는 메모리 최적화 계층으로 스케일 업할 수 없습니다.
범용 또는 메모리 최적화 서버를 만들면 vCore 수, 하드웨어 생성 및 가격 책정 계층을 몇 초 이내로 늘리거나 줄일 수 있습니다. 또한 애플리케이션 중단 시간 없이 독립적으로 스토리지 용량을 늘리거나 백업 보존 기간을 늘리거나 줄일 수 있습니다. 서버가 만들어진 후 백업 스토리지 유형은 변경할 수 없습니다. 자세한 내용은 리소스 크기 조정 섹션을 참조하세요.
컴퓨팅 세대 및 vCore
컴퓨팅 리소스는 기본 하드웨어의 논리적 CPU를 나타내는 vCore 수로 제공됩니다. 중국 동부 1, 중국 북부 1, US DoD 중부 및 US DoD 동부는 Intel E5-2673 v3(Haswell) 2.4GHz 프로세서를 기반으로 하는 Gen 4 논리 CPU를 활용합니다. 다른 모든 지역은 Intel E5-2673 v4(Broadwell) 2.3GHz 프로세서를 기반으로 하는 Gen 5 논리 CPU를 활용합니다.
스토리지
프로비전하는 스토리지는 Azure Database for MySQL 서버에 사용할 수 있는 스토리지 용량입니다. 스토리지는 데이터베이스 파일, 임시 파일, 트랜잭션 로그 및 MySQL 서버 로그에 사용됩니다. 프로비전하는 총 스토리지 용량도 서버에 사용할 수 있는 I/O 용량을 정의합니다.
Azure Database for MySQL – 단일 서버는 서버에 대해 다음 백 엔드 스토리지를 지원합니다.
| 저장소 유형 | Basic | 범용 v1 | 범용 v2 |
|---|---|---|---|
| 스토리지 크기 | 5GB-1TB | 5GB-4TB | 5GB~16TB |
| 스토리지 증분 크기 | 1GB | 1GB | 1GB |
| IOPS | 변수 | 3IOPS/GB 최소 100IOPS 최대 6000IOPS |
3IOPS/GB 최소 100IOPS 최대 20,000IOPS |
참고 항목
기본 스토리지는 IOPS 보장을 제공하지 않습니다. 범용 스토리지에서 IOPS의 규모는 프로비저닝된 스토리지 크기와 3:1 비율로 조정됩니다.
기본 스토리지
기본 스토리지는 기본 가격 책정 계층 서버를 지원하는 백 엔드 스토리지입니다. 기본 스토리지는 프로비저닝된 IOPS가 보장되지 않고 대기 시간이 가변적인 백 엔드의 Azure 표준 스토리지를 사용합니다. 기본 계층은 개발 또는 자주 사용되지 않는 소규모 애플리케이션을 위한 I/O 성능, 가벼운 컴퓨팅, 저렴한 비용이 필요한 워크로드에 가장 적합합니다.
범용 스토리지
범용 스토리지는 범용 및 메모리 최적화 계층 서버를 지원하는 백 엔드 스토리지입니다. 범용 스토리지에서 IOPS의 규모는 프로비저닝된 스토리지 크기와 3:1 비율로 조정됩니다. 아래에 설명된 대로 두 세대의 범용 스토리지가 있습니다.
범용 스토리지 v1(최대 4TB 지원)
범용 스토리지 v1은 서버당 최대 4TB 스토리지 및 6000 IOPS를 지원할 수 있는 레거시 스토리지 기술을 기반으로 합니다. 범용 스토리지 v1은 로컬 캐싱 및 백업을 위해 MySQL 엔진을 실행하는 컴퓨팅 노드의 메모리를 활용하도록 최적화됩니다. 범용 스토리지 v1의 백업 프로세스는 컴퓨팅 노드의 메모리에 있는 데이터 및 로그 파일을 읽고 최대 35일 동안 보존하기 위해 대상 백업 스토리지에 복사합니다. 따라서 백업하는 동안 스토리지의 메모리 및 IO 사용량이 상대적으로 높습니다.
모든 Azure 지역에서 범용 스토리지 v1을 지원합니다.
범용 스토리지 v1의 범용 또는 메모리 최적화 서버의 경우 다음을 고려하는 것이 좋습니다.
- 스토리지 캐싱 및 백업 버퍼에 대해 10~30%의 초과 메모리를 차지하는 컴퓨팅 SKU 계층 계획
- 백업 IO를 처리하기 위해 데이터베이스 워크로드에 필요한 것보다 10% 더 높은 IOPS 프로비저닝
- 또는 기본 스토리지 인프라를 아래에 공유된 원하는 Azure 지역에서 사용할 수 있는 경우 최대 16TB 스토리지를 지원하는 아래에 설명된 범용 스토리지 v2로 마이그레이션합니다.
범용 스토리지 v2(최대 16TB 스토리지 지원)
범용 스토리지 v2는 최대 16TB 및 20000 IOP를 지원할 수 있는 최신 스토리지 인프라를 기반으로 합니다. 인프라를 사용할 수 있는 Azure 지역의 하위 집합에서 새로 프로비저닝된 모든 서버는 기본적으로 범용 스토리지 v2에 위치합니다. 범용 스토리지 v2는 MySQL의 컴퓨팅 노드에서 메모리를 소비하지 않으며 범용 v1 스토리지에 비해 더 나은 예측 가능한 IO 대기 시간을 제공합니다. 범용 v2 스토리지 서버의 백업은 스냅샷 기반이며 추가 IO 오버헤드가 없습니다. 범용 스토리지 v1에 비해 범용 v2 스토리지에서 MySQL 서버 성능은 프로비저닝된 동일한 스토리지 및 IOPS에 대해 더 높을 것으로 예상됩니다. 최대 16TB 스토리지를 지원하는 범용 스토리지에 대해 추가 비용이 없습니다. 16TB 스토리지로의 마이그레이션 지원이 필요하면 Azure Portal에서 지원 티켓을 엽니다.
범용 스토리지 v2는 다음 Azure 지역에서 지원됩니다.
| 지역 | 범용 스토리지 v2 가용성 |
|---|---|
| 오스트레일리아 동부 | ✔️ |
| 오스트레일리아 남동부 | ✔️ |
| 브라질 남부 | ✔️ |
| 캐나다 중부 | ✔️ |
| 캐나다 동부 | ✔️ |
| 미국 중부 | ✔️ |
| 미국 동부 | ✔️ |
| 미국 동부 2 | ✔️ |
| 동아시아 | ✔️ |
| 일본 동부 | ✔️ |
| 일본 서부 | ✔️ |
| 한국 중부 | ✔️ |
| 대한민국 남부 | ✔️ |
| 북유럽 | ✔️ |
| 미국 중북부 | ✔️ |
| 미국 중남부 | ✔️ |
| 동남 아시아 | ✔️ |
| 영국 남부 | ✔️ |
| 영국 서부 | ✔️ |
| 미국 중서부 | ✔️ |
| 미국 서부 | ✔️ |
| 미국 서부 2 | ✔️ |
| 서유럽 | ✔️ |
| 인도 중부 | ✔️ |
| 프랑스 중부* | ✔️ |
| 아랍에미리트 북부* | ✔️ |
| 남아프리카 북부* | ✔️ |
참고 항목
* Azure Database for MySQL에 퍼블릭 미리 보기로 제공되는 범용 스토리지 v2가 있는 지역입니다.
*이러한 Azure 지역의 경우 범용 스토리지 v1 및 v2 모두에서 서버를 만들 수 있는 옵션이 있습니다. 퍼블릭 미리 보기에서 범용 스토리지 v2를 사용하여 만든 서버의 경우 다음 제한 사항이 적용됩니다.
- 지역 중복 백업은 지원되지 않습니다.
- 복제본 서버는 범용 스토리지 v2를 지원하는 지역에 있어야 합니다.
내 서버가 실행 중인 스토리지 유형을 확인하려면 어떻게 해야 하나요?
설정>Compute + 스토리지 페이지로 이동하여 서버의 스토리지 유형을 찾을 수 있습니다.
- 기본 SKU를 사용하여 서버를 프로비저닝하는 경우 스토리지 유형은 기본 스토리지입니다.
- 범용 또는 메모리 최적화 SKU를 사용하여 서버를 프로비저닝하는 경우 스토리지 유형은 범용 스토리지입니다.
- 서버에서 프로비저닝할 수 있는 최대 스토리지가 최대 4TB인 경우 스토리지 유형은 범용 스토리지 v1입니다.
- 서버에서 프로비저닝할 수 있는 최대 스토리지가 최대 16TB인 경우 스토리지 유형은 범용 스토리지 v2입니다.
범용 스토리지 v1에서 범용 스토리지 v2로 이동할 수 있나요? 그렇다면 방법은 무엇이며 추가 비용이 있나요?
예, 기본 스토리지 인프라를 원본 서버의 Azure 지역에서 사용할 수 있는 경우 범용 스토리지 v1에서 v2로의 마이그레이션이 지원됩니다. 마이그레이션 및 v2 스토리지는 추가 비용 없이 사용할 수 있습니다.
서버를 프로비저닝한 후 스토리지 크기를 늘릴 수 있나요?
서버를 만드는 동안과 만든 후에 추가 스토리지 용량을 추가하고 시스템에서 워크로드의 스토리지 사용량에 따라 스토리지를 자동으로 늘리도록 허용할 수 있습니다.
Important
스토리지는 스케일 다운이 아닌 스케일 업만 가능합니다.
IO 소비 모니터링
Azure Portal 또는 Azure CLI 명령을 사용하여 I/O 사용량을 모니터링할 수 있습니다. 모니터링할 관련 메트릭은 스토리지 제한, 스토리지 비율, 사용된 스토리지, IO 백분율입니다. 범용 스토리지 v1이 있는 MySQL 서버에 대한 모니터링 메트릭은 MySQL 엔진이 소비한 메모리와 IO를 보고하지만 제한 사항인 스토리지 레이어의 메모리와 IO 소비를 캡처하지 못할 수 있습니다.
스토리지 제한에 도달
프로비저닝된 스토리지가 100GB 이하인 서버는 사용 가능한 스토리지가 프로비저닝된 스토리지 크기의 5% 미만인 경우 읽기 전용으로 표시됩니다. 프로비전된 스토리지가 100GB보다 큰 서버는 사용 가능한 스토리지가 5GB 미만인 경우에만 읽기 전용으로 표시됩니다.
예를 들어 110GB의 스토리지를 프로비전하고 실제 활용이 105GB를 넘어서는 경우 서버는 읽기 전용으로 표시됩니다. 또는 5GB 스토리지를 프로비전하는 경우 서버는 여유 저장 공간이 256MB 미만이 되면 읽기 전용으로 표시됩니다.
서비스가 서버를 읽기 전용으로 만들려고 하는 동안 모든 새 쓰기 트랜잭션 요청은 차단되고 기존 활성 트랜잭션은 계속 실행됩니다. 서버가 읽기 전용으로 설정되면 모든 후속 쓰기 작업 및 트랜잭션 커밋은 실패합니다. 읽기 쿼리는 중단 없이 계속 작동합니다. 프로비전된 스토리지를 늘린 후 서버는 다시 쓰기 트랜잭션을 허용할 준비를 갖춥니다.
서버 스토리지가 임계값에 근접하는 경우 읽기 전용 상태로 들어가는 것을 방지할 수 있도록 스토리지 자동 증가를 설정하거나 알림 경고를 설정하는 것이 좋습니다. 자세한 내용은 경고 설정 방법에 관한 설명서를 참조하세요.
스토리지 자동 증가
스토리지 자동 증가는 서버가 스토리지가 부족해지고 읽기 전용이 되지 않도록 방지합니다. 스토리지 자동 증가를 사용하도록 설정하면 워크로드에 영향을 주지 않고 스토리지가 자동으로 증가합니다. 프로비전된 스토리지가 100GB 이하인 서버의 경우, 사용 가능한 스토리지 공간이 프로비전된 스토리지의 10% 미만이면 프로비전된 스토리지 크기가 5GB씩 증가합니다. 프로비전된 스토리지가 100GB를 초과하는 서버의 경우, 사용 가능한 스토리지 공간이 10GB의 프로비전된 스토리지 크기 미만이면 프로비전된 스토리지 크기가 5%씩 증가합니다. 위에 지정된 대로 최대 스토리지 제한이 적용됩니다.
예를 들어 1000GB의 스토리지를 프로비전하고 실제 활용이 990GB를 넘어서는 경우 서버는 1050GB로 증가합니다. 또는 10GB의 스토리지를 프로비전한 경우 사용 가능한 스토리지가1GB 미만이면 스토리지 크기가 15GB로 증가합니다.
스토리지는 스케일 다운이 아닌 스케일 업만 가능합니다.
백업 스토리지
Azure Database for MySQL은 추가 비용 없이 최대 100%의 프로비전된 서버 스토리지를 백업 스토리지로 제공합니다. 이 용량을 초과해서 사용하는 백업 스토리지는 매달 GB 단위로 요금이 청구됩니다. 예를 들어 250GB의 스토리지로 서버를 프로비저닝하는 경우 추가 비용 없이 250GB의 추가 스토리지를 서버 백업에 사용할 수 있게 됩니다. 250GB를 초과하는 백업용 스토리지는 가격 책정 모델에 따라 비용이 청구됩니다. 백업 스토리지 사용, 백업 스토리지 비용 모니터링 및 제어에 영향을 주는 요소를 이해하려면 백업 설명서를 참조할 수 있습니다.
리소스 스케일링
서버를 만든 후 vCore 수, 하드웨어 생성, 가격 책정 계층(기본 제외), 스토리지 크기 및 백업 보존 기간을 독립적으로 변경할 수 있습니다. 서버가 만들어진 후 백업 스토리지 유형은 변경할 수 없습니다. vCore 수는 늘리거나 줄일 수 있습니다. 백업 보존 기간은 7~35일 범위에서 늘리거나 줄일 수 있습니다. 스토리지 크기는 늘릴 수 있습니다. 리소스의 크기 조정은 포털 또는 Azure CLI를 통해 수행할 수 있습니다. Azure CLI를 사용하는 크기 조정의 예제는 Azure CLI를 사용하여 Azure Database for MySQL 서버 모니터링 및 크기 조정을 참조하세요.
vCore 수, 하드웨어 생성 또는 가격 책정 계층을 변경하면 새 컴퓨팅 할당을 사용하여 원본 서버의 복사본이 만들어집니다. 새 서버가 시작되고 실행된 후 새 서버에 대한 연결로 전환됩니다. 시스템이 새 서버로 전환되면 잠시 동안 새 연결을 설정할 수 없으며, 커밋되지 않은 모든 트랜잭션이 롤백됩니다. 크기를 조정하는 동안 이러한 가동 중지 시간은 60-120초 정도입니다. 크기 조정 중 가동 중지 시간은 데이터베이스 복구 시간에 따라 달라지므로 크기 조정 작업 시 서버에 트랜잭션 작업이 많은 경우 데이터베이스가 온라인 상태가 되는 데 더 오래 걸릴 수 있습니다. 다시 시작 시간이 길어지지 않도록 하려면 서버에서 트랜잭션 작업량이 낮은 기간에 크기 조정 작업을 수행하는 것이 좋습니다.
스토리지 크기 조정 및 백업 보존 기간 변경은 온라인 작업입니다. 가동 중지 시간이 없으며 애플리케이션은 영향을 받지 않습니다. IOPS가 프로비전된 스토리지 크기로 조정되면 스토리지를 확장하여 서버에서 사용할 수 있는 IOPS를 늘릴 수 있습니다.
가격 책정
최신 가격 책정 정보는 서비스 가격 책정 페이지를 참조하세요. 원하는 구성 비용을 확인하려면 Azure Portal에서 선택한 옵션에 따라 가격 책정 계층 탭에 월별 비용이 표시됩니다. Azure 구독이 없는 경우 Azure 가격 책정 계산기를 사용하여 예상 가격을 구할 수 있습니다. Azure 가격 책정 계산기 웹 사이트에서 항목 추가를 선택하고, 데이터베이스 범주를 확장하고, Azure Database for MySQL을 선택하여 옵션을 사용자 지정합니다.
다음 단계
- 포털에서 MySQL 서버를 만드는 방법을 알아봅니다.
- 서비스 제한에 대해 알아봅니다.
- 읽기 복제본으로 스케일 아웃하는 방법을 알아봅니다.