Azure Database for MySQL - 유연한 서버의 성능 벤치마킹 모범 사례
성능은 모든 애플리케이션의 특징이며, 애플리케이션의 다양한 워크로드 요구 사항을 처리할 때 데이터베이스에서 수행하는 방법을 분석하고 평가하기 위한 명확한 정의하는 것이 중요합니다.
이 문서에서는 Azure Database for MySQL 유연한 서버에 대한 성능 벤치마크를 실행하기 위한 고려 사항과 모범 사례를 제공합니다.
성능 테스트
관계형 데이터베이스 시스템의 성능을 가상으로 벤치마킹하는 것은 처음에는 사소한 작업처럼 보일 수 있습니다. 결국 개별 쿼리의 성능을 수동으로 평가하고 사용 가능한 벤치마킹 도구 중 하나를 사용하여 간단한 합성 테스트를 시작하는 것은 비교적 쉽습니다. 이러한 유형의 테스트는 시간이 거의 걸리지 않으며 이해하기 쉬운 결과를 빠르게 생성합니다.
그러나 실제 프로덕션 시스템의 성능을 벤치마킹하려면 많은 추가 노력이 필요합니다. 프로덕션 워크로드를 진정으로 대표하는 테스트를 디자인, 구현 및 실행하는 것은 쉽지 않습니다. 격리된 환경에서 수행되는 일련의 벤치마크 결과에 따라 프로덕션 데이터 스택에 대한 결정을 내리는 것이 훨씬 더 어렵습니다.
성능 테스트 방법론
가상 벤치마크
가상 테스트는 데이터베이스 환경에서 반복 가능한 결과를 시뮬레이션하는 인공 워크로드 샘플을 사용하여 데이터베이스 시스템에 스트레스를 가하도록 설계되었습니다. 이를 통해 고객은 여러 환경을 비교하여 프로덕션 배포에 적합한 데이터베이스 리소스를 측정할 수 있습니다.
가상 벤치마크 사용과 관련된 몇 가지 이점이 있습니다. 예를 들어 다음과 같습니다.
- 예측 가능하고 반복 가능하며 선택적 테스트(예: 쓰기 전용 테스트, 읽기 전용 테스트, 쓰기 및 읽기 테스트 혼합, 테이블에 대한 대상 테스트)를 허용합니다.
- 간단한 메트릭(예: "초당 쿼리", "초당 트랜잭션 수" 등)을 사용하여 나타낼 수 있는 전체 결과를 제공합니다.
- 빌드하고 실행하는 데 애플리케이션 또는 환경 관련 지식이 필요하지 않습니다.
- 준비 없이 빠르게 수행할 수 있습니다. 그러나 다음과 같은 관련 단점도 있습니다.
- 인공 워크로드 샘플은 실제 애플리케이션 트래픽을 대표하지 않습니다.
- 결과는 프로덕션 워크로드의 성능을 정확하게 예측하는 데 사용할 수 없습니다.
- 다른 데이터베이스 제품을 테스트하는 데 사용되는 경우 제품별 성능 특성을 노출하지 않을 수 있습니다.
- 테스트를 잘못 수행하고 대표성이 훨씬 낮은 결과를 생성하기 쉽습니다.
가상 테스트는 제품 간의 빠른 비교에 유용합니다. 또한 이러한 테스트를 사용하여 지속적인 성능 모니터링 메커니즘을 구현할 수 있습니다. 예를 들어 주말마다 테스트 제품군을 실행하여 데이터베이스 시스템의 기준 성능에 대한 유효성을 검사하고, 변칙을 검색하고, 장기적인 성능 패턴(예: 데이터 증가의 결과로 쿼리 대기 시간 저하)을 예측할 수 있습니다.
실제 벤치마크
실제 테스트를 통해 데이터베이스에는 프로덕션 트래픽과 매우 비슷한 워크로드 샘플이 제공됩니다. 이 벤치마크는 프로덕션 쿼리 로그를 재생하고 데이터베이스 성능을 측정하여 직접 달성할 수 있습니다. 또한 애플리케이션 수준에서 테스트를 실행하고 특정 데이터베이스 서버에서 애플리케이션 성능을 측정하여 간접적으로 달성할 수도 있습니다.
다음과 같이 실제 벤치마크 사용과 관련된 몇 가지 이점이 있습니다.
- 실제 프로덕션 조건에서 시스템 성능에 대한 정확한 보기를 제공합니다.
- 가상 테스트를 간소화하지 않는 애플리케이션 또는 데이터베이스별 특성을 표시할 수 있습니다.
- 애플리케이션 증가와 관련된 용량 계획을 지원합니다.
다음과 같은 특정 단점도 있습니다. 실제 벤치마크의 경우 다음과 같습니다.
- 설계와 실행이 어렵습니다.
- 애플리케이션이 발전함에 따라 관련성을 보장하기 위해 유지 관리해야 합니다.
- 특정 애플리케이션의 컨텍스트에서만 의미 있는 결과를 제공합니다.
환경에 큰 변화를 준비할 때(예: 새 데이터베이스 제품을 배포할 때) 실제 테스트를 사용하는 것이 좋습니다. 이러한 상황에서 실제 프로덕션 워크로드를 사용하는 포괄적인 벤치마크 실행은 상당한 도움이 될 수 있습니다. 신뢰할 수 있는 정확한 결과를 제공할 뿐만 아니라 시스템에 대한 "알 수 없음"의 수를 제거하거나 최소한 크게 줄일 수 있습니다.
"올바른" 테스트 방법론 선택
목적에 맞는 "올바른" 테스트 방법론은 전적으로 테스트 목표에 따라 달라집니다.
인공 데이터 및 워크로드 샘플을 사용하여 다른 데이터베이스 제품을 빠르게 비교하려는 경우 데이터를 생성하고 테스트를 실행하는 기존 벤치마크 프로그램을 안전하게 사용할 수 있습니다.
새 데이터베이스 제품에서 실행하려는 실제 애플리케이션의 성능을 정확하게 평가하려면 실제 벤치마크 테스트를 수행해야 합니다. 각 애플리케이션에는 고유한 요구 사항 및 성능 특성 집합이 있으며, 모든 성능 평가에 실제 벤치마크 테스트를 포함하는 것이 좋습니다.
가상 및 실제 벤치마크 준비 및 실행에 대한 지침은 이 게시물 뒷부분에 있는 다음 섹션을 참조하세요.
- 가상 테스트 준비 및 실행
- 실제 테스트 준비 및 실행
성능 테스트 모범 사례
서버별 권장 사항
서버 크기 조정
Azure Database for MySQL 유연한 서버 인스턴스를 시작하여 벤치마킹을 수행하는 경우 현재 데이터베이스 환경과 일치하는 Azure Database for MySQL 유연한 서버 인스턴스 계층, SKU 및 인스턴스 수를 사용합니다.
예시:
- 현재 서버에 8개의 CPU 코어와 64GB의 메모리가 있는 경우 Standard_E8ds_v4 SKU를 기반으로 인스턴스를 선택하는 것이 가장 좋습니다.
- 현재 데이터베이스 환경에서 읽기 복제본을 사용하는 경우 Azure Database for MySQL 유연한 서버 읽기 복제본을 사용합니다.
벤치마크 테스트 결과에 따라 프로덕션에서 다른 인스턴스 크기 및 개수를 사용하도록 결정할 수 있습니다. 그러나 테스트 인스턴스의 초기 사양이 현재 서버 사양에 근접하여 보다 정확한 "사과-사과" 비교를 제공하는 것이 좋습니다.
서버 구성
애플리케이션/벤치마크에서 특정 데이터베이스 기능을 사용하도록 설정해야 하는 경우 벤치마크 테스트를 실행하기 전에 이에 따라 서버 매개 변수도 조정합니다. 예를 들어, 다음을 수행해야 합니다.
- 기본이 아닌 서버 표준 시간대를 설정합니다.
- 기본값이 충분하지 않으면 사용자 지정 "max_connections" 매개 변수를 설정합니다.
- Azure Database for MySQL 유연한 서버 인스턴스에서 버전 8.0을 실행하는 경우 스레드 풀을 구성합니다.
- 병목 상태가 발생하는 쿼리를 분석할 수 있도록 프로덕션에서 느린 쿼리 로그를 사용하려는 경우 느린 쿼리 로그를 사용하도록 설정합니다.
다양한 데이터베이스 버퍼 및 캐시의 크기와 관련된 다른 매개 변수는 Azure Database for MySQL 유연한 서버에서 이미 미리 조정되어 있으며 처음에는 기본값으로 설정된 상태로 둘 수 있습니다. 이를 수정할 수 있지만 성능 벤치마크에서 지정된 변경 내용이 실제로 성능을 향상시킨다는 것을 표시하지 않는 한 서버 매개 변수를 변경하지 않는 것이 가장 좋습니다.
Azure Database for MySQL 유연한 서버를 다른 데이터베이스 제품과 비교하는 테스트를 수행하는 경우 프로덕션에서 사용하는 데 필요한 모든 기능을 테스트 데이터베이스에서 사용하도록 설정해야 합니다. 예를 들어 테스트 환경에서 영역 중복 HA, 백업 및 읽기 복제본을 사용하도록 설정하지 않으면 결과가 실제 성능을 정확하게 반영하지 못할 수 있습니다.
고객별 권장 사항
모든 성능 벤치마크에는 클라이언트 사용이 포함되므로 선택한 벤치마킹 방법론에 관계없이 다음과 같은 클라이언트 쪽 권장 사항을 고려해야 합니다.
- 클라이언트 인스턴스가 테스트하는 Azure Database for MySQL 유연한 서버 인스턴스와 동일한 Azure VNet(Virtual Network)에 있는지 확인합니다. 대기 시간에 민감한 애플리케이션의 경우 클라이언트 인스턴스를 데이터베이스 서버와 동일한 AZ(가용성 영역)에 배치하는 것이 좋습니다.
- 프로덕션 애플리케이션이 여러 인스턴스(예: Load Balancer 뒤에 있는 앱 서버 플릿)에서 실행되어야 하는 경우 벤치마크를 수행할 때 여러 클라이언트 인스턴스를 사용하는 것이 좋습니다.
- 모든 클라이언트 인스턴스에 벤치마크를 처리할 수 있는 적절한 컴퓨팅, 메모리, I/O 및 네트워크 용량이 있는지 확인합니다. 즉, 클라이언트는 데이터베이스 엔진에서 처리할 수 있는 것보다 더 빠르게 요청을 생성할 수 있어야 합니다. 모든 운영 체제는 클라이언트 인스턴스에서 리소스 사용률을 진단하는 데 도움이 되는 진단 도구(예: "top", "htop", "dstat" 또는 "iostat"on Linux)를 제공합니다. 이러한 도구를 사용하고 벤치마크가 실행되는 동안 모든 클라이언트 인스턴스에 항상 예비 CPU, 메모리, 네트워크 및 IO 용량이 있는지 확인하는 것이 좋습니다.
대규모 SKU가 있더라도 단일 클라이언트 인스턴스가 항상 데이터베이스를 포화시킬 만큼 신속하게 요청을 생성하지 못할 수 있습니다. 테스트 구성에 따라 Azure Database for MySQL 유연한 서버는 초당 수십만 개의 읽기/쓰기 요청을 처리할 수 있으며 이는 단일 클라이언트가 수용할 수 있는 것보다 많을 수 있습니다. 따라서 성능 테스트가 많은 동안 클라이언트 쪽 경합을 방지하기 위해 여러 클라이언트 인스턴스에서 벤치마크를 병렬로 실행하는 것이 일반적입니다.
Important
트래픽 생성기 스크립트 또는 타사 도구(예: Apache Benchmark, Apache JMeter 또는 Siege)를 사용하여 애플리케이션을 벤치마킹하는 경우 이전에 설명한 권장 사항을 사용하여 도구가 실행 중인 인스턴스도 평가해야 합니다.
가상 테스트 준비 및 실행
sysbench와 같은 가상 벤치마킹 도구는 설치 및 실행이 쉽지만 특정 벤치마크에서 최적의 결과를 얻으려면 일반적으로 어느 정도의 구성과 튜닝이 필요합니다.
테이블 수 및 크기
벤치마킹 전에 생성된 테이블의 수와 크기는 커야 합니다. 예를 들어 100,000개의 행이 있는 단일 테이블에서 수행된 테스트는 이러한 데이터 세트가 사실상 모든 실제 데이터베이스보다 작을 가능성이 높기 때문에 유용한 결과를 얻을 가능성이 낮습니다. 비교를 위해 각각 500만 개의 행이 있는 여러 테이블(예: 10-25)을 사용하는 벤치마크는 실시간 워크로드의 보다 현실적인 표현일 수 있습니다.
테스트 모드
인기 있는 sysbench를 포함하여 대부분의 벤치마크 도구를 사용하면 서버에 대해 실행하려는 워크로드 형식을 정의할 수 있습니다. 예를 들어 이 도구에서 생성할 수 있는 항목은 다음과 같습니다.
- 구문은 동일하지만 매개 변수가 다른 읽기 전용 쿼리
- 다양한 형식의 읽기 전용 쿼리(점 선택, 범위 선택, 정렬을 통한 선택 등)
- 개별 행 또는 행 범위를 수정하는 쓰기 전용 문
- 읽기/쓰기 문 혼합
이러한 특정 시나리오에서 데이터베이스 성능 및 확장성을 테스트하려는 경우 읽기 전용 또는 쓰기 전용 워크로드를 사용할 수 있습니다. 그러나 대부분의 OLTP 데이터베이스에서 처리해야 하는 워크로드 형식이므로 대표적인 벤치마크에는 일반적으로 읽기/쓰기 문이 적절히 혼합되어 있어야 합니다.
동시성 수준
동시성 수준은 데이터베이스에 대해 작업을 동시에 실행하는 스레드 수입니다. 대부분의 벤치마크 도구에서는 기본적으로 단일 스레드를 사용합니다. 이 스레드는 단일 클라이언트에서 데이터베이스를 한 번에 거의 사용하지 않으므로 실제 데이터베이스 환경을 대표하지 않습니다.
데이터베이스의 이론적 최고 성능을 테스트하려면 다음 프로세스를 사용합니다.
- 각 테스트마다 다른 스레드 수를 사용하여 여러 테스트를 실행합니다. 예를 들어 32개 스레드로 시작한 다음, 각 후속 테스트에 대해 스레드 수를 늘립니다(64, 128, 256 등).
- 데이터베이스 성능이 안정화될 때까지 스레드 수를 계속 늘립니다. 이는 이론적 최고 성능입니다.
- 데이터베이스 성능이 특정 동시성 수준에서 증가하지 않는 것으로 확인되면 스레드 수를 늘리려고 몇 번 더 시도할 수 있습니다. 이를 통해 성능이 안정적으로 유지되는지 아니면 저하되기 시작하는지를 보여줍니다. 자세한 내용은 Sysbench를 사용하여 Azure Database for MySQL – 유연한 서버 벤치마킹 블로그 게시물을 참조하세요.
실제 테스트 준비 및 실행
모든 애플리케이션은 데이터 특성 및 성능 요구 사항 측면에서 고유합니다. 따라서 임의 데이터베이스 환경에서 대표적이고 실제적인 벤치마크를 준비하고 실행하기에 충분한 단일 범용 단계 목록을 작성하기가 어렵습니다.
이 섹션에서 제시하는 아이디어는 성능 테스트 프로젝트를 좀 더 쉽게 만들기 위한 것입니다.
테스트 데이터 준비
Azure Database for MySQL 유연한 서버에 대한 성능 벤치마크를 수행하기 전에 서버가 프로덕션 데이터 세트의 대표 샘플로 채워져 있는지 확인합니다.
가능한 경우 프로덕션 집합의 전체 복사본을 사용합니다. 이것이 가능하지 않은 경우 다음 제안을 사용하여 항상 포함해야 하는 데이터의 부분과 제외할 수 있는 데이터를 결정하는 데 도움이 됩니다.
- 테스트 서버에는 벤치마크에서 직접 사용하는 모든 개체(즉, 스키마, 테이블, 함수 및 프로시저)가 포함되어야 합니다. 각 테이블은 완전히 채워져야 합니다. 즉, 프로덕션에 포함된 모든 행을 포함해야 합니다. 테이블이 완전히 채워지지 않은 경우(예: 행 집합의 작은 샘플만 포함) 벤치마크 결과는 대표되지 않습니다.
- 프로덕션 애플리케이션에서 사용되지만 지속적인 운영 트래픽의 일부가 아닌 테이블을 제외합니다. 예를 들어 데이터베이스에 분석에 사용되는 기록 데이터뿐만 아니라 라이브 운영 데이터 집합이 포함된 경우 벤치마크를 실행하는 데 기록 데이터가 필요하지 않을 수 있습니다.
- 테스트 서버에 복사하는 모든 테이블을 프로그래밍 방식으로 생성된 인공 샘플이 아닌 실제 프로덕션 데이터로 채웁니다.
애플리케이션 벤치마크 디자인
애플리케이션 벤치마크를 수행하는 대략적인 프로세스는 다음과 같습니다.
- Azure Database for MySQL 유연한 서버 인스턴스를 만들고, 프로덕션 데이터의 복사본으로 채웁니다.
- 애플리케이션 복사본을 Azure에 배포합니다.
- Azure Database for MySQL 유연한 서버 인스턴스를 사용하도록 애플리케이션을 구성합니다.
- 애플리케이션에 대해 부하 테스트를 실행하고 결과를 평가합니다.
이 방법은 Azure에서 애플리케이션 복사본을 쉽게 배포할 수 있는 경우에 주로 유용합니다. 이를 통해 성능 평가를 가장 철저하고 정확한 방법으로 수행할 수 있지만, 여전히 고려해야 할 특정 권장 사항이 있습니다.
- 애플리케이션 트래픽을 생성하는 데 사용되는 도구는 프로덕션 워크로드를 대표하는 요청 혼합을 생성할 수 있어야 합니다. 예를 들어 클라이언트가 실제 환경에서 애플리케이션을 사용하는 방식을 대표하지 않을 수 있으므로 동일한 애플리케이션 URL에 반복적으로 액세스하여 테스트하지 마세요.
- 클라이언트 및 애플리케이션 인스턴스 풀은 병목 상태가 발생하지 않고도 요청을 생성하고, 처리하고, 데이터베이스로부터 응답을 받을 수 있을 만큼 강력해야 합니다.
- 동시성 수준(벤치마크 도구에서 생성된 병렬 요청 수)은 애플리케이션에서 관찰된 예상 최대 동시성 수준과 일치하거나 약간 높아야 합니다.
데이터베이스 벤치마크 디자인
Azure에서 애플리케이션 복사본을 쉽게 배포할 수 없는 경우 데이터베이스에 대해 SQL 문을 직접 실행하여 벤치마크를 수행해야 합니다. 이렇게 하려면 다음과 같은 대략적인 절차를 사용합니다.
- 프로덕션 워크로드에 가장 일반적으로 나타나는 SQL 문을 식별합니다.
- 첫 번째 단계에서 수집한 정보에 따라 테스트할 큰 SQL 문 샘플을 준비합니다.
- Azure Database for MySQL 유연한 서버 노드를 만들고 프로덕션 데이터의 복사본으로 채웁니다.
- Azure에서 Azure VM(가상 머신) 클라이언트 인스턴스를 시작합니다.
- VM에서 Azure Database for MySQL 유연한 서버 인스턴스에 대해 SQL 워크로드 샘플을 실행하고 결과를 평가합니다.
테스트 페이로드(SQL 문 샘플)를 생성하는 다음 두 가지 주요 방법이 있습니다.
- 현재 데이터베이스에서 발생하는 SQL 트래픽을 관찰/기록한 다음, 해당 관찰에 따라 SQL 샘플을 생성합니다. Azure Database for MySQL 유연한 서버에서 감사 로그와 느린 쿼리 로깅의 조합을 사용하여 쿼리 트래픽을 기록하는 방법에 대한 자세한 내용입니다.
- 실제 쿼리 로그를 페이로드로 사용합니다. "Percona 재생"과 같은 타사 도구는 MySQL 느린 쿼리 로그를 기반으로 다중 스레드 워크로드를 생성할 수 있습니다.
SQL 샘플을 수동으로 생성하도록 결정하는 경우 샘플에 다음이 포함되어 있는지 확인합니다.
충분히 많은 수의 고유한 문
예: 프로덕션 워크로드에서 15개의 주요 문 형식을 사용하는 것으로 확인되면 샘플에 총 15개의 문(유형당 하나씩)이 포함되는 것만으로는 충분하지 않습니다. 이러한 작은 샘플의 경우 데이터베이스는 메모리에 필요한 데이터를 쉽게 캐시하여 벤치마크를 대표하지 않습니다. 대신 각 문 형식에 대해 큰 쿼리 샘플을 제공하고 다음 추가 권장 사항을 사용합니다.
적절한 비율로 다양한 형식의 문
예: 프로덕션 워크로드에서 12가지 유형의 문을 사용하는 것으로 확인되면 일부 유형의 문이 다른 문보다 더 자주 나타날 수 있습니다. 샘플에서 다음 비율을 반영해야 합니다. 프로덕션 워크로드에서 쿼리 A가 쿼리 B보다 10배 더 자주 나타나는 경우 샘플에서도 10배 더 자주 나타나야 합니다.
현실적으로 무작위로 추출된 쿼리 매개 변수
이전 권장 사항을 따랐고 쿼리 샘플에 동일한 형식/구문의 쿼리 그룹이 포함되면 이러한 쿼리의 매개 변수를 무작위로 추출해야 합니다. 샘플에 동일한 형식의 100만 개의 쿼리가 포함되어 있고 모두 동일한 경우(WHERE 조건의 매개 변수 포함) 필요한 데이터는 데이터베이스 메모리에 쉽게 캐시되어 벤치마크가 사용되지 않습니다.
현실적으로 무작위로 추출된 문 실행 순서
이전 권장 사항을 따르고 테스트 페이로드에 다양한 형식의 쿼리가 많이 포함되면 이러한 쿼리를 현실적인 순서로 실행해야 합니다. 예를 들어 샘플에는 1,000만 개의 SELECT 및 1백만 개의 UPDATES가 포함될 수 있습니다. 이러한 경우 애플리케이션이 실제 환경에서 쿼리를 실행하는 방법이 아닐 수 있으므로 모든 UPDATE 전에 모든 SELECT를 실행하는 것이 최선의 선택이 아닐 수 있습니다. 아마도 애플리케이션에서 SELECT와 UPDATE를 인터리브하고, 테스트에서 이를 시뮬레이션해야 합니다.
쿼리 샘플이 준비되면 명령줄 MySQL 클라이언트 또는 mysqlslapv와 같은 도구를 사용하여 서버에 대해 실행합니다.
테스트 실행
가상 벤치마크를 실행하든 실제 애플리케이션 성능 테스트를 실행하든 관계없이 더 대표적인 결과를 얻을 수 있도록 몇 가지 규칙을 따라야 합니다.
여러 인스턴스 유형에 대해 테스트 실행
db.r3.2xlarge 서버에 대해 벤치마크를 실행하도록 결정하고 애플리케이션/쿼리 성능에서 이미 요구 사항을 충족한다고 가정합니다. 또한 두 가지 이점을 제공하는 더 작은 인스턴스 유형과 더 큰 인스턴스 유형 모두에 대해 테스트를 실행하는 것이 좋습니다.
- 인스턴스 유형이 더 작은 테스트는 여전히 좋은 성능 결과를 얻을 수 있으며 잠재적인 비용 절감 기회를 표시할 수 있습니다.
- 더 큰 인스턴스 유형을 사용하여 테스트하면 향후 확장성 옵션에 대한 아이디어나 인사이트를 제공할 수 있습니다.
지속적인 성능과 최고 성능을 모두 측정
선택하는 테스트 전략은 다음과 같이 데이터베이스에서 적절한 항목을 제공하는지에 대한 답변을 제공해야 합니다.
- 지속적인 성능 - 사용자 트래픽이 원활하고 예상 수준 내에 있을 때 일반적인 워크로드에서 예상대로 작동하나요?
- 최고 성능 - 트래픽 급증 시 애플리케이션 응답성을 보장하나요?
다음 지침을 고려하세요.
- 안정적인 상태에서 데이터베이스 성능을 평가할 수 있을 만큼 테스트 실행 시간이 충분히 긴지 확인합니다. 예를 들어 데이터베이스 캐시 및 버퍼가 짧은 시간 안에 준비되지 않을 수 있으므로 10분 동안만 지속되는 복잡한 테스트는 부정확한 결과를 생성할 수 있습니다.
- 테스트 전체에서 워크로드 수준이 다양하면 벤치마크가 훨씬 더 의미 있고 유익할 수 있습니다. 예를 들어 애플리케이션에서 일반적으로 64개 동시 클라이언트로부터 트래픽을 받는 경우 64개 클라이언트를 사용하여 벤치마크를 시작합니다. 그런 다음, 테스트가 계속 실행되는 동안 64개 추가 클라이언트를 추가하여 시뮬레이션된 트래픽 급증 중에 서버의 작동 방식을 확인합니다.
벤치마크 절차에 정전/절전 테스트 포함
지속적인 서버 성능은 중요한 메트릭으로, 테스트 중에 주요 초점이 될 수 있습니다. 그러나 중요 업무용 애플리케이션의 경우 성능 테스트는 안정적인 상태의 서버 동작을 측정하는 것에서 끝나면 안 됩니다.
다음 시나리오를 테스트에 포함하는 것이 좋습니다.
- "중단" 테스트는 다시 부팅 또는 크래시 중에 데이터베이스가 작동하는 방식을 결정하도록 설계되었습니다. Azure Database for MySQL 유연한 서버는 크래시 복구 시간에서 크게 향상되었으며, 다시 부팅/크래시 테스트는 이러한 시나리오에서 Azure Database for MySQL 유연한 서버가 애플리케이션 가동 중지 시간을 줄이는 데 기여하는 방식을 이해하는 데 도움이 됩니다.
- "Brownout" 테스트는 다시 부팅 또는 충돌 후 데이터베이스가 명목 성능 수준을 얼마나 빨리 달성할 수 있는지를 측정하도록 설계되었습니다. 데이터베이스에서 최적의 성능을 달성하는 데 시간이 필요한 경우가 많으며, Azure Database for MySQL 유연한 서버는 이 영역에서도 향상되었습니다.
데이터베이스에 영향을 주는 안정성 문제가 발생하는 경우 성능 벤치마크 중에 수집된 정보는 병목 상태를 식별하거나 워크로드 요구 사항에 맞게 애플리케이션을 추가로 조정하는 데 도움이 됩니다.