Azure Managed Redis(미리 보기) 아키텍처

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을 "노드"라고도 합니다. 주 노드는 기본 Redis 프로세스를 보유하며 모든 쓰기를 허용합니다. 복제는 유지 관리, 크기 조정 또는 예기치 않은 실패 중에 백업 복사본을 제공하기 위해 복제본 노드에 비동기적으로 수행됩니다. 각 노드는 커뮤니티 Redis의 단일 스레드 디자인으로 인해 단일 Redis 서버 프로세스만 실행할 수 있습니다.

Azure Managed Redis의 아키텍처 개선 사항

Azure Managed Redis는 다음과 같은 고급 아키텍처를 사용합니다.

다음과 같은 몇 가지 차이점이 있습니다.

• 각 가상 머신(또는 "노드")은 여러 Redis 서버 프로세스("분할된 데이터베이스"라고 함)를 병렬로 실행합니다. 여러 분할된 데이터베이스를 사용하면 각 가상 머신에서 vCPU를 보다 효율적으로 사용하고 성능을 높일 수 있습니다.
• 모든 기본 Redis 분할된 데이터베이스가 동일한 VM/노드에 있는 것은 아닙니다. 대신 주 및 복제본 분할된 데이터베이스는 두 노드에 분산됩니다. 주 분할된 데이터베이스는 복제본 분할된 데이터베이스보다 더 많은 CPU 리소스를 사용하므로 이 방법을 사용하면 더 많은 주 분할된 데이터베이스를 병렬로 실행할 수 있습니다.
• 각 노드에는 분할된 데이터베이스를 관리하고, 연결 관리를 처리하고, 자체 복구를 트리거하는 고성능 프록시 프로세스가 있습니다.

이 아키텍처를 사용하면 활성 지역 복제와 같은 고급 기능과 고성능을 모두 사용할 수 있습니다.

Clustering

Redis Enterprise는 노드당 여러 분할된 데이터베이스를 사용할 수 있으므로 각 Azure Managed Redis 인스턴스는 내부적으로 모든 계층 및 SKU에서 클러스터링을 사용하도록 구성됩니다. 여기에는 단일 분할된 데이터베이스만 사용하도록 설정된 더 작은 인스턴스가 포함됩니다. 클러스터링은 Redis 인스턴스의 데이터를 "분할"이라고도 하는 여러 Redis 프로세스 간에 나누는 방법입니다. Azure Managed Redis는 캐시 인스턴스에 연결하기 위해 Redis 클라이언트에서 사용할 수 있는 프로토콜을 결정하는 두 가지 클러스터 정책을 제공합니다.

클러스터 정책

Azure Managed Redis는 클러스터링 정책에 대해 OSS 및 Enterprise라는 두 가지 선택 항목을 제공합니다. OSS 클러스터 정책은 더 높은 최대 처리량을 지원하므로 대부분의 애플리케이션에 권장되지만 버전마다 장단점이 있습니다.

OSS 클러스터링 정책은 커뮤니티 버전 Redis와 동일한 Redis 클러스터 API를 구현합니다. Redis 클러스터 API를 사용하면 Redis 클라이언트가 각 Redis 노드의 분할된 데이터베이스에 직접 연결하여 대기 시간을 최소화하고 네트워크 처리량을 최적화할 수 있으므로 분할된 데이터베이스 및 vCPU 수가 증가함에 따라 처리량이 거의 선형적으로 확장될 수 있습니다. OSS 클러스터링 정책은 일반적으로 최상의 대기 시간 및 처리량 성능을 제공합니다. 그러나 OSS 클러스터 정책을 사용하려면 클라이언트 라이브러리가 Redis 클러스터 API를 지원해야 합니다. 현재 거의 모든 Redis 클라이언트는 Redis 클러스터 API를 지원하지만 호환성은 이전 클라이언트 버전 또는 특수 라이브러리에 문제가 될 수 있습니다. OSS 클러스터링 정책도 RediSearch 모듈에서 사용할 수 없습니다.

Enterprise 클러스터링 정책은 모든 클라이언트 연결에 대해 단일 엔드포인트를 활용하는 좀 더 간단한 구성입니다. Enterprise 클러스터링 정책을 사용하면 모든 요청이 단일 Redis 노드로 라우팅된 다음, 프록시로 사용되고 내부적으로 요청이 클러스터의 올바른 노드로 라우팅됩니다. 이 방법의 장점은 Azure Managed Redis를 사용자에게 비클러스터형으로 보이게 한다는 것입니다. 즉, Redis 클라이언트 라이브러리는 Redis Enterprise의 성능 이점을 얻기 위해 Redis 클러스터링을 지원할 필요가 없으며 이전 버전과의 호환성을 높이고 연결을 더 간단하게 만듭니다. 단점은 단일 노드 프록시가 컴퓨팅 사용률 또는 네트워크 처리량에서 병목 상태가 될 수 있다는 것입니다. Enterprise 클러스터링 정책은 RediSearch 모듈에서 사용할 수 있는 유일한 정책입니다. 엔터프라이즈 클러스터 정책으로 인해 Azure Managed Redis 인스턴스가 사용자에게 비클러스터형으로 표시되지만 다중 키 명령에는 여전히 몇 가지 제한 사항이 있습니다.

노드 확장 또는 추가

핵심 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의 사용을 최적화하도록 매핑됩니다.

고가용성 모드를 사용하지 않고 실행

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 Storage에 항목을 추가하기 전에 사용 가능한 RAM을 채웁니다. 먼저 RAM을 채우는 것은 성능에 몇 가지 영향을 미칩니다.

• 메모리 사용량이 적은 테스트 시 성능이 향상되고 대기 시간이 짧아질 수 있습니다. 전체 캐시 인스턴스를 사용하여 테스트하면 메모리 사용량이 낮은 테스트 단계에서 RAM만 사용되므로 성능이 저하될 수 있습니다.
• 캐시에 더 많은 데이터를 쓰면 Flash 스토리지에 비해 RAM의 데이터 비율이 감소하여 일반적으로 대기 시간 및 처리량 성능도 저하됩니다.

플래시 최적화 계층에 적합한 워크로드

플래시 최적화 계층에서 잘 실행될 가능성이 있는 워크로드에는 다음과 같은 특징이 있는 경우가 많습니다.

• 읽기가 많고 쓰기 명령에 대한 읽기 명령의 비율이 높습니다.
• Access는 나머지 데이터 세트보다 훨씬 더 자주 사용되는 키의 하위 집합에 초점을 맞췄습니다.
• 키 이름에 비해 상대적으로 큰 값입니다. 키 이름은 항상 RAM에 저장되므로 큰 값은 메모리 증가에 병목 현상이 발생할 수 있습니다.

플래시 최적화 계층에 적합하지 않은 워크로드

일부 워크로드에는 플래시 최적화 계층의 디자인에 덜 최적화된 액세스 특성이 있습니다.

• 쓰기 작업이 많은 워크로드
• 대부분의 데이터 세트에서 임의 또는 균일한 데이터 액세스 패턴입니다.
• 값 크기가 상대적으로 작은 긴 키 이름입니다.

다음 단계

• Azure Managed Redis 인스턴스 크기 조정