성능 테스트
Redis 인스턴스 성능 테스트는 복잡한 작업일 수 있습니다. Redis 인스턴스의 성능은 클라이언트 수, 데이터 값의 크기, 파이프라인 사용 여부와 같은 매개 변수에 따라 달라질 수 있습니다. 또한 처리량 최적화 또는 대기 시간 간에 적절한 균형을 유지할 수 있습니다.
다행히 Redis를 더 쉽게 벤치마킹할 수 있는 도구가 몇 가지 있습니다. 최고 인기 도구 두 가지는 redis-benchmark와 memtier-benchmark입니다. 이 문서에서는 redis-benchmark를 중점적으로 살펴봅니다.
redis-benchmark 유틸리티 사용 방법
테스트에 사용할 수 있는 클라이언트 VM에 오픈 소스 Redis 서버를 설치합니다. redis-benchmark 유틸리티는 오픈 소스 Redis 배포에 기본 제공됩니다. 오픈 소스 이미지를 설치하는 방법에 대한 지침은 Redis 설명서를 따릅니다.
테스트에 사용되는 클라이언트 VM은 Azure Cache for Redis 인스턴스와 동일한 지역에 있어야 합니다.
사용하는 클라이언트 VM의 컴퓨팅 및 대역폭 수준이 적어도 테스트 중인 캐시 인스턴스 만큼인지 확인합니다.
클라이언트 VM이 Azure Cache for Redis 인스턴스에 액세스할 수 있도록 네트워크 격리 및 방화벽 설정을 구성합니다.
캐시 인스턴스에서 TLS/SSL을 사용하는 경우
--tls매개 변수를 redis-benchmark 명령에 추가하거나, stunnel 같은 프록시를 사용해야 합니다.Redis-benchmark는 기본적으로 포트 6379를 사용합니다.-p매개 변수를 사용하여 이 설정을 재정의합니다. SSL/TLS(포트 6380)를 사용하거나 엔터프라이즈 계층(포트 10000)을 사용하는 경우-p를 사용해야 합니다.클러스터링을 사용하는 Azure Cache for Redis 인스턴스를 사용하는 경우
redis-benchmark명령에--cluster매개 변수를 추가해야 합니다. 엔터프라이즈 클러스터링 정책을 사용하는 엔터프라이즈 계층 캐시는 비클러스터형 캐시로 처리할 수 있으며 이 설정이 필요하지 않습니다.VM의 CLI 또는 셸에서
redis-benchmark를 시작합니다. 도구를 구성하고 실행하는 방법에 대한 지침은 redis-benchmark 설명서 및 redis-benchmark 예제 섹션을 참조하세요.
벤치마킹 권장 사항
안정적인 상태 조건에서만 캐시의 성능을 테스트하지 않는 것이 중요합니다. 장애 조치 조건에서도 테스트하고 해당 시간 동안 캐시에서 CPU/서버 부하를 측정합니다. 주 노드를 다시 부팅하여 장애 조치를 시작할 수 있습니다. 장애 조치 조건에서 테스트하면 장애 조치 상태 중 애플리케이션의 처리량과 대기 시간을 확인할 수 있습니다. 장애 조치는 업데이트 중 또는 계획되지 않은 이벤트 중에 발생할 수 있습니다. 이상적으로는 성능에 영향을 줄 수 있는 장애 조치(failover) 중에도 CPU/서버 로드 최대치가 80%를 넘지 않는 것이 좋습니다.
Enterprise 및 Premium 계층 Azure Cache for Redis 인스턴스를 사용하는 것이 좋습니다. 이러한 캐시 크기는 더 나은 하드웨어에서 실행되기 때문에 네트워크 대기 시간과 처리량이 더 우수합니다.
Redis Enterprise는 핵심 Redis 프로세스에서 여러 vCPU를 활용할 수 있으므로, 보통 Enterprise 계층이 최고의 성능을 제공합니다. Standard와 Premium 같은 오픈 소스 Redis 기반 계층은 분할된 데이터베이스별로 Redis 프로세스에 하나의 vCPU만 활용할 수 있습니다.
키 일부는 DRAM에 저장되고 일부는 NVMe 플래시 디스크에 저장되기 때문에 Enterprise Flash 계층을 벤치마킹하기가 어려울 수 있습니다. DRAM 벤치마크의 키는 거의 Enterprise 계층 인스턴스만큼 빠르지만 NVMe 플래시 디스크의 키는 더 느립니다. Enterprise Flash 계층은 가장 자주 사용되는 키를 DRAM에 지능적으로 배치하므로 벤치마크 구성이 예상한 실제 사용량과 일치하는지 확인합니다.
-r매개 변수를 사용하여 액세스되는 키를 임의로 지정하는 것이 좋습니다.TLS/SSL을 사용하면 처리량 성능이 저하됩니다. 이는 다음 표의 데이터 벤치마킹 예제에서 명확하게 확인할 수 있습니다.
Redis 서버는 단일 스레드임에도 스케일 업하면 처리량 성능이 개선되는 경향이 있습니다. 시스템 프로세스는 Redis 프로세스에서 사용되는 vCPU를 공유하는 대신 추가 vCPU를 사용할 수 있습니다. Redis Enterprise는 단일 스레드로 제한되지 않기 때문에 스케일 업은 Enterprise 및 Enterprise Flash 계층에서 특히 유용합니다. 자세한 내용은 Enterprise 계층 모범 사례를 참조하세요.
Premium 계층에서는 일반적으로 스케일 업하기 전에 클러스터링 스케일 아웃하는 것이 좋습니다. 클러스터링하면 Redis 서버에서 데이터를 분할하여 vCPU를 더 많이 사용할 수 있습니다. 이 경우 분할된 데이터베이스를 추가하면 처리량이 대략 선형적으로 증가해야 합니다.
Redis 벤치마크 예제
사전 테스트 설정: 대기 시간 및 처리량 테스트에 필요한 데이터를 사용하여 캐시 인스턴스를 준비합니다.
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t SET -n 10 -d 1024
대기 시간 테스트 방법: 1k 페이로드를 사용하여 GET 요청을 테스트합니다.
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -d 1024 -P 50 -c 4
처리량 테스트 방법: 1k 페이로드를 사용하여 GET 요청을 파이프라인으로 연결합니다.
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
TLS를 사용한 Basic, Standard, Premium 계층 캐시의 처리량을 테스트하는 방법: 1k 페이로드를 사용하여 GET 요청을 파이프라인으로 연결합니다.
redis-benchmark -h yourcache.redis.cache.windows.net -p 6380 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --tls
OSS 클러스터 모드를 사용하여 TLS 없이 Enterprise 또는 Enterprise Flash 캐시의 처리량을 테스트하는 방법: 1k 페이로드를 사용하여 GET 요청을 파이프라인으로 연결합니다.
redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50 --cluster
성능 벤치마크 데이터 예제
다음 표에는 Standard, Premium, Enterprise, Enterprise Flash 캐시의 다양한 크기를 테스트하는 동안 관찰된 최대 처리량 값이 나와 있습니다. Azure Cache for Redis 엔드포인트에서 IaaS Azure VM의 redis-benchmark를 사용했습니다. 처리량 수치는 GET 명령에만 해당합니다. 일반적으로 SET 명령은 처리량이 더 적습니다. 이러한 수치는 처리량에 최적화되어 있습니다. 허용되는 대기 시간 조건에서 실제 처리량이 더 적을 수 있습니다.
다음 구성은 Basic, Standard, Premium 계층의 처리량을 벤치마킹하는 데 사용되었습니다.
redis-benchmark -h yourcache.redis.cache.windows.net -a yourAccesskey -t GET -n 1000000 -d 1024 -P 50 -c 50
주의
이러한 값은 보장되지 않으며 이러한 수치에 대한 SLA는 없습니다. 애플리케이션에 적합한 캐시 크기를 확인하려면 자체 성능 테스트를 수행하는 것이 좋습니다. 이러한 수치는 새 결과가 주기적으로 게시됨에 따라 변경될 수 있습니다.
Important
Microsoft는 캐시 인스턴스에 사용되는 기본 VM을 주기적으로 업데이트합니다. 그러면 성능 특성을 캐시에서 캐시로, 지역에서 지역으로 변경할 수 있습니다. 이 페이지의 벤치마킹 값 예제는 단일 지역의 이전 세대 캐시 하드웨어를 반영합니다. 실제로 더 좋거나 다른 결과를 볼 수도 있습니다.
표준 계층
| 인스턴스 | 크기 | vCPU | 예상 네트워크 대역폭(Mbps) | SSL을 사용하지 않은 초당 GET 요청(1kB 값 크기) | SSL을 사용하는 초당 GET 요청(1kB 값 크기) |
|---|---|---|---|---|---|
| C0 | 250MB | 공유됨 | 100 | 15,000 | 7,500 |
| C1 | 1GB | 1 | 500 | 38,000 | 20,720 |
| C2 | 2.5GB | 2 | 500 | 41,000 | 37,000 |
| C3 | 6GB | 4 | 1000 | 100,000 | 90,000 |
| C4 | 13GB | 2 | 500 | 60,000 | 55,000 |
| C5 | 26GB | 4 | 1,000 | 102,000 | 93,000 |
| C6 | 53GB | 8 | 2,000 | 126,000 | 120,000 |
프리미엄 계층
| 인스턴스 | 크기 | vCPU | 예상 네트워크 대역폭(Mbps) | SSL을 사용하지 않은 초당 GET 요청(1kB 값 크기) | SSL을 사용하는 초당 GET 요청(1kB 값 크기) |
|---|---|---|---|---|---|
| P1 | 6GB | 2 | 1,500 | 180,000 | 172,000 |
| P2 | 13GB | 4 | 3,000 | 350,000 | 341,000 |
| P3 | 26GB | 4 | 3,000 | 350,000 | 341,000 |
| P4 | 53GB | 8 | 6,000 | 400,000 | 373,000 |
| P5 | 120GB | 32 | 6,000 | 400,000 | 373,000 |
Important
중국 동부 및 중국 북부 지역의 P5 인스턴스는 32개 코어가 아닌 20개의 코어를 사용합니다.
Enterprise 및 Enterprise Flash 계층
Enterprise 및 Enterprise Flash 계층은 클러스터 정책(Enterprise, OSS)을 선택할 수 있습니다. Enterprise 클러스터 정책은 클라이언트가 클러스터링 지원할 필요가 없는 간단한 구성입니다. 반면 OSS 클러스터 정책은 Redis 클러스터 프로토콜을 사용하여 더 많은 처리량을 지원합니다. 대부분의 경우 OSS 클러스터 정책을 사용하는 것이 좋습니다. 자세한 내용은 Enterprise의 클러스터링을 참조하세요. 다음 표에는 두 클러스터 정책의 벤치마크가 나와 있습니다.
다음 구성은 Enterprise 및 Enterprise Flash 계층의 처리량을 벤치마킹하는 데 사용되었습니다.
redis-benchmark -h yourcache.region.redisenterprise.cache.azure.net -p 10000 -a yourAccesskey -t GET -n 10000000 -d 1024 -P 50 -c 50 --threads 32
참고 항목
이 구성은 Basic, Standard, Premium 계층을 벤치마킹하는 데 사용되는 구성과 거의 동일합니다. 그러나 이전 구성은 Enterprise 계층의 더 큰 컴퓨팅 성능을 완전히 활용하지 못했습니다. 전체 성능을 보여주기 위해 이 구성에 추가 요청과 스레드가 추가되었습니다.
Enterprise 클러스터 정책
| 인스턴스 | 크기 | vCPU | 예상 네트워크 대역폭(Mbps) | SSL을 사용하지 않은 초당 GET 요청(1kB 값 크기) | SSL을 사용하는 초당 GET 요청(1kB 값 크기) |
|---|---|---|---|---|---|
| E10 | 12GB | 4 | 4,000 | 300,000 | 207,000 |
| E20 | 25GB | 4 | 4,000 | 680,000 | 480,000 |
| E50 | 50GB | 8 | 8,000 | 1,200,000 | 900,000 |
| E100 | 100GB | 16 | 10,000 | 1,700,000 | 1,650,000 |
| F300 | 384 GB | 8 | 3,200 | 500,000 | 390,000 |
| F700 | 715GB | 16 | 6,400 | 500,000 | 370,000 |
| F1500 | 1455GB | 32 | 12,800 | 530,000 | 390,000 |
OSS 클러스터 정책
| 인스턴스 | 크기 | vCPU | 예상 네트워크 대역폭(Mbps) | SSL을 사용하지 않은 초당 GET 요청(1kB 값 크기) | SSL을 사용하는 초당 GET 요청(1kB 값 크기) |
|---|---|---|---|---|---|
| E10 | 12GB | 4 | 4,000 | 1,400,000 | 1,000,000 |
| E20 | 25GB | 4 | 4,000 | 1,200,000 | 900,000 |
| E50 | 50GB | 8 | 8,000 | 2,300,000 | 1,700,000 |
| E100 | 100GB | 16 | 10,000 | 3,000,000 | 2,500,000 |
| F300 | 384 GB | 8 | 3,200 | 1,500,000 | 1,200,000 |
| F700 | 715GB | 16 | 6,400 | 1,600,000 | 1,200,000 |
| F1500 | 1455GB | 32 | 12,800 | 1,600,000 | 1,110,000 |
Enterprise 및 Enterprise Flash 계층 - 스케일 아웃
더 큰 캐시 크기로 이동하여 스케일 업하는 것 외에 스케일 아웃하여 성능을 높일 수 있습니다. Enterprise 계층의 스케일 아웃을 캐시 인스턴스의 용량 증가라고 합니다. 기본적으로 캐시 인스턴스에는 두 가지 용량, 즉 주 노드와 복제본 노드가 있습니다. 용량이 네 가지인 Enterprise 캐시 인스턴스는 인스턴스가 두 배로 스케일 아웃되었음을 나타냅니다. 스케일 아웃하면 더 많은 메모리와 vCPU에 액세스할 수 있습니다. 각 캐시 크기와 용량의 핵심 Redis 프로세스에서 사용되는 vCPU 수에 대한 자세한 내용은 Enterprise 계층 모범 사례 페이지에서 확인할 수 있습니다. 스케일 아웃은 OSS 클러스터 정책을 사용할 때 가장 효과적입니다.
다음 표에는 SSL과 1kB의 값 크기를 사용하는 서로 다른 용량의 초당 GET 요청이 나와 있습니다.
스케일 아웃 - Enterprise 클러스터 정책
| 인스턴스 | 용량 2 | 용량 4 | 용량 6 |
|---|---|---|---|
| E10 | 200,000 | 830,000 | 930,000 |
| E20 | 480,000 | 710,000 | 950,000 |
| E50 | 900,000 | 1,110,000 | 1,200,000 |
| E100 | 1,600,000 | 1,120,000 | 1,200,000 |
| 인스턴스 | 용량 3 | 용량 9 |
|---|---|---|
| F300 | 390,000 | 640,000 |
| F700 | 370,000 | 610,000 |
| F1500 | 390,000 | 670,000 |
스케일 아웃 - OSS 클러스터 정책
| 인스턴스 | 용량 2 | 용량 4 | 용량 6 |
|---|---|---|---|
| E10 | 1,000,000 | 1,900,000 | 2,500,000 |
| E20 | 900,000 | 1,700,000 | 2,300,000 |
| E50 | 1,700,000 | 3,000,000 | 3,900,000 |
| E100 | 2,500,000 | 4,400,000 | 4,900,000 |
| 인스턴스 | 용량 3 | 용량 9 |
|---|---|---|
| F300 | 1,200,000 | 2,600,000 |
| F700 | 1,200,000 | 2,600,000 |
| F1500 | 1,100,000 | 2,800,000 |