Azure Managed Redis는 Redis Enterprise 스택에서 실행되며, Redis의 커뮤니티 버전에 비해 상당한 이점을 제공합니다. 다음 정보는 사용자에게 유용할 수 있는 정보를 포함하여 Azure Managed Redis의 설계 방식에 대해 자세히 설명합니다.
Azure Cache for Redis와의 비교
Azure Cache for Redis의 기본, 표준, 프리미엄 계층은 Redis의 커뮤니티 버전을 기반으로 빌드되었습니다. 이 Redis 커뮤니티 버전에는 단일 스레드를 포함하여 몇 가지 중요한 제한 사항이 있습니다. 이로 인해 성능이 크게 저하되고 서비스에서 더 많은 vCPU가 완전히 활용되지 않으므로 스케일링 효율성이 떨어집니다. 일반적인 Azure Cache for Redis 인스턴스는 다음과 같은 아키텍처를 사용합니다.
주 VM과 복제본 VM이라는 두 가지 VM이 사용됩니다. 이러한 VM을 '노드'라고도 합니다. 주 노드는 기본 Redis 프로세스를 보유하며 모든 쓰기를 허용합니다. 복제는 복제 노드에 비동기적으로 수행되어 유지 관리, 스케일링 또는 예기치 않은 오류 발생 시 백업 복사본을 제공합니다. 각 노드는 커뮤니티 Redis의 단일 스레드 디자인으로 인해 단일 Redis 서버 프로세스만 실행할 수 있습니다.
Azure Managed Redis의 아키텍처 개선 사항
Azure Managed Redis는 다음과 같은 고급 아키텍처를 사용합니다.
다음과 같은 몇 가지 차이점이 있습니다.
- 각 가상 머신(또는 "노드")은 여러 Redis 서버 프로세스("분할된 데이터베이스"이라고 함)를 병렬로 실행합니다. 여러 분할된 데이터베이스를 사용하면 각 가상 머신에서 vCPU를 더 효율적으로 사용하고 성능을 향상할 수 있습니다.
- 모든 기본 Redis 분할된 데이터베이스가 동일한 VM/노드에 있는 것은 아닙니다. 대신 주 분할된 데이터베이스와 복제본 분할된 데이터베이스는 두 노드에 분산됩니다. 주 분할된 데이터베이스는 복제본 분할된 데이터베이스보다 더 많은 CPU 리소스를 사용하므로 이 방법을 사용하면 더 많은 주 분할된 데이터베이스를 병렬로 실행할 수 있습니다.
- 각 노드에는 분할된 데이터베이스를 관리하고, 연결 관리를 처리하고, 자동 복구를 트리거하는 고성능 프록시 프로세스가 있습니다.
이 아키텍처는 더 높은 성능과 활성 지역 복제와 같은 고급 기능을 모두 지원합니다.
클러스터링
각 Azure Managed Redis 인스턴스는 모든 계층 및 SKU에서 클러스터링을 사용하도록 내부적으로 구성됩니다. Azure Managed Redis는 노드당 여러 분할된 데이터베이스를 사용할 수 있는 Redis Enterprise를 기반으로 합니다. 여기에는 단일 분할된 데이터베이스만 사용하도록 설정된 더 작은 인스턴스가 포함됩니다. 클러스터링은 Redis 인스턴스의 데이터를 "분할"이라고도 하는 여러 Redis 프로세스 간에 나누는 방법입니다. Azure Managed Redis는 캐시 인스턴스에 연결하기 위해 Redis 클라이언트에서 사용할 수 있는 프로토콜을 결정하는 세 가지 클러스터 정책을 제공합니다.
클러스터 정책
Azure Managed Redis는 OSS, Enterprise 및 비클러스터형(미리 보기)의 세 가지 클러스터링 정책을 제공합니다. OSS 클러스터 정책은 더 높은 최대 처리량을 지원하므로 대부분의 애플리케이션에 권장되지만 버전마다 장단점이 있습니다.
OSS 클러스터링 정책은 Azure Cache for Redis 계층과 동일한 Redis 클러스터 API를 구현합니다. Redis 클러스터 API를 사용하면 Redis 클라이언트가 각 Redis 노드의 분할된 데이터베이스에 직접 연결하여 대기 시간을 최소화하고 네트워크 처리량을 최적화할 수 있으므로 분할된 데이터베이스와 vCPU의 수가 증가함에 따라 처리량을 거의 선형적으로 스케일링할 수 있습니다. OSS 클러스터링 정책은 일반적으로 가장 우수한 대기 시간과 처리량 성능을 제공합니다. 그러나 OSS 클러스터 정책을 사용하려면 클라이언트 라이브러리가 Redis 클러스터 API를 지원해야 합니다. 현재 거의 모든 Redis 클라이언트는 Redis 클러스터 API를 지원하지만, 이전 클라이언트 버전이나 특수 라이브러리에서는 호환성이 문제가 될 수 있습니다.
OSS 클러스터링 정책은 RediSearch 모듈에서 사용할 수 없습니다.
OSS 클러스터링 프로토콜을 사용하려면 클라이언트가 올바른 분할된 연결을 설정해야 합니다. 초기 연결은 포트 10000을 통해 이루어집니다. 개별 노드 연결은 85XX 범위의 포트를 사용하여 수행됩니다. 85xx 포트는 시간이 지남에 따라 변경될 수 있으며 애플리케이션으로 하드 코딩해서는 안 됩니다. 클러스터링을 지원하는 Redis 클라이언트는 CLUSTER NODES 명령을 사용하여 주 분할된 데이터베이스와 복제본 분할된 데이터베이스에 사용되는 정확한 포트를 확인하고 분할된 연결을 만듭니다.
Enterprise 클러스터링 정책은 모든 클라이언트 연결에 대해 단일 엔드포인트를 활용하는 좀 더 간단한 구성입니다. Enterprise 클러스터링 정책을 사용하면 모든 요청이 단일 Redis 노드로 라우팅된 다음, 프록시로 사용되고 내부적으로 요청이 클러스터의 올바른 노드로 라우팅됩니다. 이 방법의 장점은 Azure Managed Redis가 사용자에게 클러스터되지 않은 것처럼 보이게 한다는 것입니다. 즉, Redis 클라이언트 라이브러리는 Redis Enterprise의 성능 이점을 얻기 위해 Redis 클러스터링을 지원할 필요가 없습니다. 단일 엔드포인트를 사용하면 이전 버전과의 호환성이 향상되고 연결이 더 간단해집니다. 단점은 단일 노드 프록시가 컴퓨팅 사용률 또는 네트워크 처리량에서 병목 상태가 될 수 있다는 것입니다.
Enterprise 클러스터링 정책은 RediSearch 모듈에서 사용할 수 있는 유일한 정책입니다. 엔터프라이즈 클러스터 정책을 사용하면 Azure Managed Redis 인스턴스가 사용자에게 클러스터되지 않은 것처럼 보이지만 다중 키 명령에는 여전히 몇 가지 제한 사항이 있습니다.
비클러스터형(미리 보기) 클러스터링 정책은 분할 없이 각 노드에 데이터를 저장합니다. 크기가 25GB 이하인 캐시에만 적용됩니다. 비클러스터형(미리 보기) 클러스터링 정책을 사용하는 시나리오는 다음과 같습니다.
- 분할되지 않은 Redis 환경에서 마이그레이션하는 경우 예를 들어 Azure Cache for Redis의 기본, 표준 및 프리미엄 SKU의 분할되지 않은 토폴로지입니다.
- 크로스 슬롯 명령을 광범위하게 실행하고 데이터를 샤드로 분할할 때 오류가 발생할 수 있습니다. 예를 들어 MULTI 명령입니다.
- Redis를 메시지 브로커로 사용하는 경우 분할이 필요하지 않습니다.
비클러스터형(미리 보기) 정책 사용에 대한 고려 사항은 다음과 같습니다.
- 이는 25GB보다 작거나 같은 Azure Managed Redis 계층에만 적용됩니다.
- CPU는 캐시가 분할될 때 Redis Enterprise 소프트웨어로만 다중 스레드를 사용할 수 있으므로 다른 클러스터링 정책만큼 성능이 좋지 않습니다.
- Azure Managed Redis 캐시를 강화하려면 먼저 클러스터 정책을 변경해야 합니다.
- 기본, 표준 또는 프리미엄 비클러스터형 토폴로지에서 이동하는 경우 OSS 클러스터를 사용하여 성능을 향상시키는 것이 좋습니다. 비클러스터형 구성은 애플리케이션이 OSS 또는 엔터프라이즈 토폴로지를 지원할 수 없는 경우에만 사용해야 합니다.
노드 스케일 아웃 또는 추가
핵심 Redis Enterprise 소프트웨어는 스케일 업(더 큰 VM 사용) 또는 스케일 아웃(더 많은 노드/VM 추가)이 가능합니다. 궁극적으로 스케일링 작업은 동일한 작업을 수행합니다. 즉, 더 많은 메모리, 더 많은 vCPU, 더 많은 분할된 데이터베이스를 추가합니다. 이러한 중복성으로 인해 Azure Managed Redis는 각 구성에서 사용되는 특정 노드 수를 제어하는 기능을 제공하지 않습니다. 구현 세부 정보는 사용자의 혼동, 복잡성, 최적이 아닌 구성을 방지할 수 있도록 추상화되어 있습니다. 대신 각 SKU는 vCPU 및 메모리를 최대화하기 위해 노드 구성으로 설계되었습니다. Azure Managed Redis의 일부 SKU는 두 개의 노드만 사용하지만, 일부는 더 많은 노드를 사용합니다.
다중 키 명령
Azure Managed Redis 인스턴스는 클러스터형 구성으로 설계되었으므로 다중 키에서 작동하는 명령에 CROSSSLOT 예외가 표시될 수 있습니다. 동작은 사용되는 클러스터링 정책에 따라 달라집니다. OSS 클러스터링 정책을 사용하는 경우 다중 키 명령을 사용하려면 모든 키를 동일한 해시 슬롯에 매핑해야 합니다.
Enterprise 클러스터링 정책에 CROSSSLOT 오류가 표시될 수도 있습니다. Enterprise 클러스터링을 사용하는 슬롯에서 DEL, MSET, MGET, EXISTS, UNLINK, TOUCH의 다중 키 명령만 허용됩니다.
활성-활성 데이터베이스에서 다중 키 쓰기 명령(DEL, MSET, UNLINK)은 동일한 슬롯에 있는 키에서만 실행할 수 있습니다. 그러나 다중 키 명령 MGET, EXISTS, TOUCH는 활성-활성 데이터베이스의 슬롯에서 허용됩니다. 자세한 내용은 데이터베이스 클러스터링을 참조하세요.
분할 구성
Azure Managed Redis의 각 SKU는 특정 수의 Redis 서버 프로세스(분할된 데이터베이스)를 병렬로 실행하도록 구성됩니다. 처리량 성능, 분할된 데이터베이스 수, 각 인스턴스에서 사용할 수 있는 vCPU 수 간의 관계는 복잡합니다. 분할된 데이터베이스를 추가하면 Redis 작업을 병렬로 실행할 수 있으므로 일반적으로는 성능이 향상됩니다. 그러나 명령을 실행할 수 있는 vCPU가 없어서 분할된 데이터베이스에서 명령을 실행할 수 없는 경우에는 성능이 오히려 저하될 수 있습니다. 다음 테이블에서는 각 Azure Managed Redis SKU에 대한 분할 구성을 보여 줍니다. 이러한 분할된 데이터베이스는 Redis Enterprise 프록시, 관리 에이전트, OS 시스템 작업을 위해 vCPU 주기를 예약하는 동시에 각 vCPU의 사용을 최적화하도록 매핑되며, 이는 성능에도 영향을 미칩니다.
비고
Azure Managed Redis는 각 SKU에서 사용되는 분할된 데이터베이스 및 vCPU 수를 변경하여 시간이 지남에 따라 성능을 최적화합니다.
중요합니다
120GB 이상의 스토리지를 사용하는 모든 메모리 내 계층은 메모리 최적화 M150 이상을 포함하여 공개 미리 보기로 제공됩니다. 균형 잡힌 B150 이상; 및 컴퓨팅 최적화 X150 이상. 이러한 모든 계층 이상은 공개 미리 보기에 있습니다.
모든 플래시 최적화 계층은 공개 미리 보기로 제공됩니다.
| 계층 | 플래시 최적화(미리 보기) | 메모리 최적화 | 균형 잡힌 | 최적화된 컴퓨팅 |
|---|---|---|---|---|
| 크기(GB) | vCPU/기본 분할된 데이터베이스 | vCPU/기본 분할된 데이터베이스 | vCPU/기본 분할된 데이터베이스 | vCPU/기본 분할된 데이터베이스 |
| 0.5 | - | - | 2월 1일 | - |
| 1 | - | - | 2월 1일 | - |
| 3 | - | - | 2/2 | 4월 2일 |
| 6 | - | - | 2/2 | 4월 2일 |
| 12 | - | 2/2 | 4월 2일 | 8월 6일 |
| 24 | - | 4월 2일 | 8월 6일 | 12월 16일 |
| 60 (육십) | - | 8월 6일 | 12월 16일 | 32/24 |
| 백이십 | - | 12월 16일 | 32/24 | 64/48 |
| 180 * | - | 24시간 내내 | 48/48 | 96/96 |
| 240 * | 8월 6일 | 32/24 | 64/48 | 128/96 |
| 360 * | - | 48/48 | 96/96 | 192/192 |
| 480 * | 12월 16일 | 64/48 | 128/96 | 256/192 |
| 720 * | 24시간 내내 | 96/96 | 192/192 | 384/384 |
| 960 * | 32/24 | 128/192 | 256/192 | - |
| 1440 * | 48/48 | 192/192 | - | - |
| 1920 * | 64/48 | 256/192 | - | - |
| 4500 * | 144/96 | - | - | - |
* 이러한 계층은 공개 미리 보기로 제공됩니다.
고가용성 모드를 사용하지 않고 실행
HA(고가용성) 모드를 사용하지 않고 실행할 수 있습니다. 즉, Redis 인스턴스에서 복제를 사용하도록 설정되지 않았으며 가용성 SLA에 액세스할 수 없습니다. 개발/테스트 시나리오 외에는 HA 모드가 아닌 모드로 실행하는 것을 권장하지 않습니다. 이미 만들어진 인스턴스에서는 고가용성을 사용하지 않도록 설정할 수 없습니다. 하지만 고가용성이 없는 인스턴스에서는 고가용성을 사용하도록 설정할 수 있습니다. 고가용성 없이 실행되는 인스턴스는 더 적은 수의 VM/노드를 사용하므로 vCPU를 효율적으로 활용할 수 없어 성능이 저하될 수 있습니다.
예약된 메모리
각 Azure Managed Redis 인스턴스에서 사용 가능한 메모리의 약 20%는 장애 조치(failover) 중 복제 및 활성 지역 복제 버퍼와 같은 캐시가 아닌 작업에 대한 버퍼로 예약됩니다. 이 버퍼는 캐시 성능을 개선하고 메모리 부족 현상을 방지하는 데 도움이 됩니다.
스케일 다운하는 중
스케일 다운은 현재 Azure Managed redis에서 지원되지 않습니다. 자세한 내용은 Azure Managed Redis 크기 조정의 제한 사항을 참조하세요.
최적화된 플래시 계층
최적화된 플래시 계층은 NVMe Flash 스토리지와 RAM을 모두 활용합니다. Flash 스토리지는 비용이 저렴하므로 최적화된 플래시 계층을 사용하면 가격 효율성을 위해 일부 성능을 낮출 수 있습니다.
최적화된 플래시 인스턴스에서는 캐시 공간의 20%가 RAM에 있고 나머지 80%는 Flash 스토리지를 사용합니다. 모든 키는 RAM에 저장되는 반면, 값은 플래시 스토리지나 RAM에 저장할 수 있습니다. Redis 소프트웨어는 값의 위치를 지능적으로 결정합니다. 자주 액세스되는 핫 값은 RAM에 저장되고 덜 일반적으로 사용되는 콜드 값은 Flash에 보관됩니다. 데이터를 읽거나 쓰기 전에 해당 데이터는 RAM으로 이동하여 핫 데이터가 되어야 합니다.
Redis는 최상의 성능을 위해 최적화되므로 인스턴스는 먼저 Flash 스토리지에 항목을 추가하기 전에 먼저 사용 가능한 RAM을 채웁니다. 먼저 RAM을 채우면 성능에 몇 가지 영향을 줍니다.
- 메모리 사용량이 적어서 테스트하면 성능이 향상되고 대기 시간이 짧아질 수 있습니다. 전체 캐시 인스턴스로 테스트하면 낮은 메모리 사용량 테스트 단계에서는 RAM만 사용되므로 성능이 저하될 수 있습니다.
- 캐시에 더 많은 데이터를 쓸수록 Flash 스토리지에 비해 RAM에 있는 데이터의 비중이 감소하여 일반적으로 대기 시간과 처리량 성능도 감소합니다.
최적화된 플래시 계층에 적합한 워크로드
최적화된 플래시 계층에서 잘 실행될 가능성이 있는 워크로드에는 다음과 같은 특징이 있는 경우가 많습니다.
- 읽기가 많고 쓰기 명령에 대한 읽기 명령의 비율이 높습니다.
- 액세스는 데이터 세트의 나머지 부분보다 훨씬 더 자주 사용되는 키 하위 집합에 중점을 둡니다.
- 키 이름에 비해 상대적으로 큰 값입니다. (키 이름은 항상 RAM에 저장되므로 큰 값은 메모리 증가에 병목 현상을 일으킬 수 있습니다.)
최적화된 플래시 계층에 적합하지 않은 워크로드
일부 워크로드에는 최적화된 플래시 계층의 디자인에 덜 최적화된 액세스 특성이 있습니다.
- 쓰기 작업이 많은 워크로드
- 대부분의 데이터 세트에서 임의 또는 균일한 데이터 액세스 패턴이 나타납니다.
- 값 크기가 상대적으로 작은 긴 키 이름입니다.