Azure Managed Redis를 사용한 성능 테스트(미리 보기)
Redis 인스턴스 성능 테스트는 복잡한 작업일 수 있습니다. Redis 인스턴스의 성능은 클라이언트 수, 데이터 값의 크기, 파이프라인 사용 여부와 같은 매개 변수에 따라 달라질 수 있습니다. 또한 처리량 최적화 또는 대기 시간 간에 적절한 균형을 유지할 수 있습니다.
다행히 Redis를 더 쉽게 벤치마킹할 수 있는 도구가 몇 가지 있습니다. 최고 인기 도구 두 가지는 redis-benchmark와 memtier-benchmark입니다. 이 문서에서는 종종 memtier라고 하는 memtier_benchmark 중점을 둡니다.
memtier_benchmark 유틸리티를 사용하는 방법
테스트에 사용할 수 있는 클라이언트 VM(가상 머신)에 memtier를 설치합니다. 오픈 소스 이미지를 설치하는 방법에 대한 지침은 Memtier 설명서를 따릅니다.
테스트에 사용되는 클라이언트 VM(가상 머신)은 AMR(Azure Managed Redis) 인스턴스와 동일한 지역에 있어야 합니다.
사용하는 클라이언트 VM의 컴퓨팅 및 대역폭 수준이 적어도 테스트 중인 캐시 인스턴스 만큼인지 확인합니다.
클라이언트 VM이 Azure Managed Redis 인스턴스에 액세스할 수 있도록 네트워크 격리 및 VM 방화벽 설정을 구성합니다.
캐시 인스턴스에서 TLS/SSL을 사용하는 경우 memtier_benchmark 명령에 매개 변수와
--tls-skip-verify매개 변수를 추가--tls해야 합니다.memtier_benchmark는 기본적으로 포트 6379를 사용합니다. AMR이-p 10000포트 10000을 대신 사용하므로 매개 변수를 사용하여 이 설정을 재정의합니다.OSS 클러스터 정책을 사용하는 모든 Azure Managed Redis 인스턴스의 경우 memtier 명령에 매개 변수를 추가
--cluster-mode해야 합니다. 엔터프라이즈 클러스터 정책을 사용하는 AMR 인스턴스는 비클러스터형 캐시로 처리할 수 있으며 이 설정이 필요하지 않습니다.VM의 CLI 또는 셸에서
memtier_benchmark를 시작합니다. 도구를 구성하고 실행하는 방법에 대한 지침은 Memtier 설명서를 참조 하세요.
벤치마킹 권장 사항
필요한 성능을 얻지 못하는 경우 고급 계층으로 확장해 보세요. 분산 계층은 일반적으로 메모리 최적화 계층보다 두 배 많은 vCPU를 가지고 있으며, 컴퓨팅 최적화 계층에는 일반적으로 분산 계층보다 두 배 많은 vCPU가 있습니다. Azure Managed Redis는 커뮤니티 Redis가 아닌 Redis Enterprise를 기반으로 하므로 핵심 Redis 프로세스는 여러 vCPU를 활용할 수 있습니다. 따라서 vCPU가 더 많은 인스턴스의 처리량 성능이 훨씬 향상됩니다.
더 큰 메모리 크기로 확장하면 더 많은 vCPU가 추가되고 성능이 향상됩니다. 그러나 더 큰 메모리 크기로 확장하는 것은 일반적으로 성능이 더 뛰어난 계층을 사용하는 것보다 덜 효과적입니다. 각 크기 및 계층에 사용할 수 있는 vCPU에 대한 자세한 내용은 계층 및 SKU를 한눈에 참조하세요.
일부 키는 DRAM에 저장되고 일부는 NVMe 플래시 디스크에 저장되기 때문에 플래시 최적화 계층을 벤치마킹하기 어려울 수 있습니다. DRAM 벤치마크의 키는 다른 Azure Managed Redis 인스턴스만큼 빠르지만 NVMe 플래시 디스크의 키는 속도가 느립니다. 플래시 최적화 계층은 가장 자주 사용되는 키를 DRAM에 지능적으로 배치하므로 벤치마크 구성이 예상한 실제 사용량과 일치하는지 확인합니다.
TLS/SSL을 사용하면 처리량 성능이 저하되지만 프로덕션 모범 사례로 권장됩니다.
벤치마킹하기 전에 먼저 Redis 인스턴스를 데이터로 채우는 것이 중요합니다. 빈 캐시에 대한 벤치마킹은 실제로 볼 수 있는 것보다 훨씬 더 나은 결과를 생성합니다.
사용되는 연결 수는 벤치마크에 상당한 영향을 미칩니다. 너무 많은 연결을 사용하면 캐시 성능이 저하됩니다. 연결이 너무 적어 캐시의 전체 성능이 표시되지는 않습니다. 실제 애플리케이션 요구 사항에 따라 연결 수를 구성하는 것이 좋습니다. 클라이언트 수를 스레드 수와 곱하여 총 연결 수를 결정합니다.
파이프라인 구성은 성능 테스트에 상당한 영향을 줍니다. 파이프라인 설정을 더 크게 설정하면 처리량이 더 많지만 대기 시간이 더 짧아질 수 있습니다. 자세한 내용은 파이프라닝을 참조 하세요.
memtier_benchmark 예제
참고 항목
이 예제에서는 OSS 클러스터 정책 및 TLS를 사용하여 컴퓨팅 최적화 X3 인스턴스에 대한 벤치마킹을 보여 줍니다.
사전 테스트 설정: 테스트에 필요한 데이터를 사용하여 캐시 인스턴스를 준비합니다. 데이터를 사용하여 인스턴스를 로드하면 결과가 실제 조건을 보다 정확하게 반영할 수 있습니다. 매개 변수는 {number-of-keys} AMR 인스턴스의 크기와 각 키의 크기에 따라 결정되어야 합니다. 미리 보기의 좋은 규칙은 버퍼를 고려하여 인스턴스를 약 75% 가득 채우는 것입니다. 다음 수식을 numberOfKeysToSet = (<TotalCacheSizeInBytes> * 0.75) / (1024 + 300)사용할 수 있습니다. 예를 들어 컴퓨팅 최적화 X3 인스턴스에서 벤치마킹하는 경우 앞에서 {number-of-keys} = (3 * 1000000000 * 0.75) / (1024 + 300)설명한 대로 1,024 바이트 키 크기를 사용합니다. 결과는 약 1,699,396개의 키와 같습니다.
memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 --key-maximum=1699396 -n allkeys --key-pattern=P:P --ratio=1:0 -data-size=1024 --tls --cluster-mode
참고 항목
이 예제에서는 , --tls-skip-verify및 플래그를 --cluster-mode --tls사용합니다. TLS가 아닌 모드에서 Azure Managed Redis를 사용하거나 엔터프라이즈 클러스터 정책을 각각 사용하는 경우에는 필요하지 않습니다.
처리량을 테스트하려면: 이 명령은 1k 페이로드를 사용하여 파이프라인된 GET 요청을 테스트합니다. 이 명령을 사용하여 캐시 인스턴스에서 예상할 읽기 처리량을 테스트합니다. 이 예제에서는 TLS 및 OSS 클러스터 정책을 사용 중이라고 가정합니다. 매개 변수는 --key-pattern=R:R 키에 임의로 액세스하여 벤치마크의 리얼리즘을 높입니다. 이 테스트는 5분 동안 실행됩니다.
memtier_benchmark -h {your-cache-name}.{region}.redis.azure.net -p 10000 -a {your-access-key} --hide-histogram --pipeline=10 -clients=50 -threads=6 -d 1024 --key-maximum=1699396 --key-pattern=R:R --ratio=0:1 --distinct-client-seed --test-time=300 --json-out-file=test_results.json --tls --tls-skip-verify --cluster-mode
성능 벤치마크 데이터 예제
다음 표에서는 다양한 크기의 Azure Managed Redis 인스턴스를 테스트하는 동안 관찰된 최대 처리량 값을 보여 줍니다. Memtier_benchmark 예제 섹션에 표시된 memtier 명령을 활용하여 Azure Managed Redis 엔드포인트에 대해 IaaS Azure VM에서 사용 memtier_benchmark 했습니다. 처리량 수치는 GET 명령에만 해당합니다. 일반적으로 SET 명령은 처리량이 더 적습니다. 실제 성능은 Redis 구성 및 명령에 따라 달라집니다. 이러한 숫자는 보장이 아닌 참조 지점으로 제공됩니다.
주의
이러한 값은 보장되지 않으며 이러한 수치에 대한 SLA는 없습니다. 애플리케이션에 적합한 캐시 크기를 확인하려면 자체 성능 테스트를 수행하는 것이 좋습니다. 이러한 수치는 새 결과가 주기적으로 게시됨에 따라 변경될 수 있습니다.
Important
Microsoft는 캐시 인스턴스에 사용되는 기본 VM을 주기적으로 업데이트합니다. 그러면 성능 특성을 캐시에서 캐시로, 지역에서 지역으로 변경할 수 있습니다. 이 페이지의 벤치마킹 값 예제는 단일 지역의 이전 세대 캐시 하드웨어를 반영합니다. 특히 네트워크 대역폭에서 실제로 더 좋거나 다른 결과를 볼 수 있습니다.
Azure Managed Redis는 클러스터 정책 (엔터프라이즈 및 OSS)을 제공합니다. Enterprise 클러스터 정책은 클라이언트가 클러스터링 지원할 필요가 없는 간단한 구성입니다. 반면 OSS 클러스터 정책은 Redis 클러스터 프로토콜을 사용하여 더 높은 처리량을 지원합니다. 대부분의 경우 OSS 클러스터 정책을 사용하는 것이 좋습니다. 자세한 내용은 클러스터링을 참조 하세요.
다음 표에는 두 클러스터 정책의 벤치마크가 나와 있습니다. OSS 클러스터 정책 테이블의 경우 다음 두 가지 벤치마킹 구성이 제공됩니다.
- 연결 300개(클라이언트 50개 및 스레드 6개)
- 2,500개의 연결(클라이언트 50개 및 스레드 50개)
두 번째 벤치마크는 300개의 연결이 더 큰 캐시 인스턴스의 성능을 완전히 입증하기에 충분하지 않기 때문에 제공됩니다.
다음은 벤치마킹에 사용되는 클라이언트 연결 수에 따라 AMR 인스턴스에 대한 1kB 페이로드에 대한 초당 GET 작업의 처리량입니다. 모든 숫자는 SSL 연결이 있는 AMR 인스턴스에 대해 계산되었으며 네트워크 대역폭은 Mbps로 기록됩니다.
OSS 클러스터 정책
| 크기(GB) | vCPU/네트워크 BW/메모리 최적화 | vCPU/네트워크 BW/Balanced | vCPU/네트워크 BW/컴퓨팅 최적화 |
|---|---|---|---|
| 1 | - | 2/5,000/103,500 | - |
| 3 | - | 2/2,000/104,500 | 4/10,000/221,100 |
| 6 | - | 2/2,000/106,500 | 4/10,000/210,850 |
| 12 | 2/2,000/106,000 | 4/4,000/223,900 | 8/12,500/499,900 |
| 24 | 4/4,000/227,800 | 8/8,000/495,300 | 16/12,500/485,920 |
| 60 | 8/8,000/496,000 | 16/10,000/476,500 | 32/16,000/454,200 |
| 120 | 16/10,000/476,200 | 32/16,000/462,200 | 64/28,000/463,800 |
Enterprise 클러스터 정책
| 크기(GB) | vCPU/네트워크 BW/메모리 최적화 | vCPU/네트워크 BW/Balanced | vCPU/네트워크 BW/컴퓨팅 최적화 |
|---|---|---|---|
| 1 | - | 2/5,000/56,900 | - |
| 3 | - | 2/2,000/56,900 | 4/10,000/118,900 |
| 6 | - | 2/2,000/59,200 | 4/10,000/111,950 |
| 12 | 2/2,000/55,800 | 4/4,000/118,500 | 8/12,500/206,500 |
| 24 | 4/4,000/122,000 | 8/8,000/205,500 | 16/12,500/294,700 |
| 60 | 8/8,000/208,100 | 16/10,000/293,400 | 32/16,000/441,400 |
| 120 | 16/10,000/285,600 | 32/16,000/451,700 | 64/28,000/516,200 |