Azure Database for MySQL - 유연한 서버 성능 기능
세 가지 서비스 계층 중 하나를 기반으로 Azure Database for MySQL 유연한 서버를 만들 수 있습니다. 버스트 가능, 범용 및 중요 비즈니스용. 서비스 계층은 증가하는 수준의 컴퓨팅 및 스토리지 크기뿐만 아니라 지원되는 최대 연결 수 및 IOPS(초당 I/O 작업)도 제공합니다. 하나의 MySQL 유연한 서버는 여러 데이터베이스를 호스팅할 수 있습니다. CPU 및 메모리 사용량, I/O 성능, 쿼리 메트릭 등과 같은 MySQL 유연한 서버의 성능 메트릭을 모니터링하여 정보에 입각한 용량 결정을 내릴 수 있습니다.
컴퓨팅 크기: RAM 및 코어
세 가지 서비스 계층은 각각 서로 다른 기본 VM SKU를 제공합니다. 버스트 가능 계층은 B 시리즈 VM을 사용하고, 범용 계층은 D 시리즈 VM을 사용하며, 중요 비즈니스용 계층은 E 시리즈 VM을 사용합니다. 사용되는 VM 시리즈에 따라 서버에서 사용할 수 있는 vCore 및 RAM 수가 결정됩니다.
서버를 만든 후 컴퓨팅 계층, 컴퓨팅 크기 및 스토리지 크기를 변경할 수 있습니다. 컴퓨팅 계층 또는 컴퓨팅 크기를 변경하려면 다시 시작해야 하며 일반적으로 완료하는 데 1~2분 정도 걸립니다. 스토리지 크기를 변경하면 다시 시작할 필요가 없습니다.
비프로덕션(개발, 준비, 테스트 등) 워크로드의 경우 전체 CPU를 지속적으로 사용하지 않는 워크로드에 비용 효율적인 솔루션을 제공하는 버스트 가능 계층 기반 서버를 사용하는 것이 좋습니다. 사용량이 적은 기간 동안 B 시리즈 VM을 사용하는 서버는 사용량이 많은 기간에 사용할 수 있는 CPU 크레딧을 누적하여 기준보다 성능을 "버스트"할 수 있습니다. 기준이 너무 높거나 사용량 버스트가 너무 많은 경우 성능 저하를 방지하기 위해 범용 또는 중요 비즈니스용 계층으로 업그레이드하는 것이 좋습니다.
서비스 계층 컴퓨팅 크기
세 가지 서비스 계층은 각각 서로 다른 수준의 컴퓨팅 성능을 제공합니다. 버스트 가능 계층은 최대 20개의 vCore를 지원할 수 있고 범용 계층은 최대 64개의 vCore를 지원할 수 있으며 최대 96vCore를 지원할 수 있지만 중요 비즈니스용 계층은 최고 수준의 컴퓨팅 성능을 제공합니다. 중요 비즈니스용 계층은 Ev4 시리즈 VM보다 QPS가 최대 30% 더 길고 대기 시간이 50% 더 낮은 Ev5 시리즈 VM도 제공합니다.
IOPS: 사전 프로비전과 자동 크기 조정
초당 수행할 수 있는 읽기 및 쓰기 작업 수를 스토리지 IOPS(초당 I/O 작업)라고 합니다. IOPS 설정이 높을수록 스토리지 성능이 향상됩니다. 동시 읽기/쓰기 작업이 더 많아지면 데이터 검색 속도, 데이터 지속성, 인덱스 업데이트 및 전반적인 데이터베이스 효율성이 향상됩니다. IOPS 설정이 너무 낮으면 데이터베이스 처리가 지연되고 성능이 저하될 수 있습니다. 그러나 IOPS 설정이 너무 높으면 성능 개선을 실현하지 못한 채 비용이 증가할 수 있습니다.
Azure Database for MySQL – 유연한 서버를 사용하면 IOPS를 사전 프로비전하거나 IOPS 자동 크기 조정 기능을 사용할 수 있습니다.
사전 프로비전된 IOPS를 사용하면 일정하고 예측 가능한 성능을 제공하기 위해 특정 IOPS 수를 할당할 수 있습니다. 이는 로드가 I/O 작업이 제한되는 임계값에 접근하지 않는 경우에 잘 작동합니다. 워크로드 수요가 증가함에 따라 언제든지 추가 IOPS를 할당할 수 있지만 이를 위해서는 수동 개입이 필요합니다.
자동 크기 조정 IOPS 기능을 사용하도록 설정하면 워크로드 작업에 따라 필요에 따라 IOPS가 크기 조정되고 사용량에 따라 비용을 지불하게 됩니다. 워크로드가 증가함에 따라 서버는 I/O 성능을 원활하게 크기 조정하므로 트래픽이 적을 때 사용되지 않은 용량에 대한 비용을 지불하지 않고도 인스턴스가 워크로드 급증을 처리할 수 있습니다.
두 경우 모두 IOPS는 서버의 최댓값을 초과할 수 없습니다. 컴퓨팅 크기별 최대 IOPS에 대한 자세한 내용은 컴퓨팅 및 스토리지 설명서 문서를 참조하세요.
읽기 복제본
데이터베이스의 트래픽이 증가함에 따라 컴퓨팅 노드 수를 수평 또는 "스케일 아웃"하거나 컴퓨팅 노드 크기를 수직 또는 "스케일 업"할 수 있습니다. 읽기 복제본은 수평적 크기 조정을 제공합니다.
읽기 복제본은 MySQL의 이진 로그 복제(binlog)를 사용하여 동기화 상태를 유지하는 데이터베이스의 읽기 전용 복사본입니다. 애플리케이션이 성장함에 따라 컴퓨팅 및 스토리지 리소스(예: 데이터베이스)의 크기를 조정해야 합니다. AKS(Azure Kubernetes Service), Virtual Machine Scale Sets 및 App Service를 사용하여 새 VM을 프로비전함으로써 애플리케이션 구성 요소 크기 조정이 간소화됩니다. 이러한 컴퓨팅 리소스가 크기 조정되고 저장된 데이터가 증가함에 따라 데이터베이스에 대한 부담이 증가하며, 이는 종종 애플리케이션 아키텍처에서 병목 현상을 일으키게 됩니다.
읽기 복제본을 사용하면 주 서버가 읽기/쓰기 작업을 지원하도록 읽기 전용 작업을 보조 데이터베이스로 전환할 수 있습니다. Azure Database for MySQL은 관리 읽기 복제본을 제공합니다. 원본 서버를 최대 10개의 복제본으로 복제할 수 있습니다. 이는 보고 및 분석과 같이 대량의 데이터를 쿼리하는 경우가 많은 사용 사례에 도움이 될 수 있습니다.
읽기 복제본을 사용하는 것은 어떤 이유로든 또는 다른 쿼리가 인덱스를 사용할 수 없는 경우에 특히 유용합니다. 모든 쿼리 패턴에 대해 인덱스를 추가하는 것은 서버에 추가 로드(처리, 디스크 I/O, 스토리지, 트랜잭션 시간 등)를 주기 때문에 실용적이지 않거나 심지어 중단이 될 수도 있습니다. 데이터 웨어하우스를 사용할 수 없거나 새로 고침 주기보다 최신 데이터가 필요한 경우 읽기 복제본을 사용하는 것은 중요한 읽기/쓰기 작업을 중단하지 않고 "대규모" 쿼리를 실행할 수 있는 좋은 방법입니다.
읽기 복제본은 고가용성 구성과 동일한 방식으로 즉시 동기화되지 않습니다. 읽기 복제본은 HA 솔루션과 관련된 트랜잭션 대기 시간을 발생시키지 않지만 데이터가 주 데이터베이스에서 복제본에 도달할 때 약간의 대기 시간이 발생할 수 있습니다.