Enterprise 및 Enterprise Flash 계층에 대한 모범 사례
다음은 Azure Cache for Redis의 Enterprise 및 Enterprise Flash 계층을 사용할 때의 모범 사례입니다.
영역 중복
영역 중복 구성에 새 캐시를 배포하는 것이 좋습니다. 영역 중복을 통해 Redis Enterprise 노드가 세 개의 가용성 영역에 분산되어 데이터 센터 수준 중단 시 중복성이 향상됩니다. 영역 중복을 사용하면 가용성이 향상됩니다. 자세한 내용은 온라인 서비스에 대한 SLA(서비스 수준 계약)를 참조하세요.
캐시 인스턴스가 항상 3개 이상의 노드를 사용하기 때문에 Enterprise 계층에서 영역 중복이 중요합니다. 두 노드는 데이터를 보유하는 데이터 노드와 쿼럼 노드입니다. 용량을 늘리면 데이터 노드 수가 짝수 단위로 증가합니다.
쿼럼 노드라는 다른 노드도 있습니다. 이 노드는 데이터 노드를 모니터링하고 장애 조치(failover)가 있는 경우 새 기본 노드를 자동으로 선택합니다. 영역 중복을 사용하면 노드가 3개의 가용성 영역에 균등하게 분산되므로 쿼럼 손실 가능성이 최소화됩니다. 고객에게는 쿼럼 노드에 대한 요금이 부과되지 않으며 영역 내 대역폭 요금 외에 영역 중복 사용에 따른 요금은 없습니다.
확장
Azure Cache for Redis Enterprise 및 Enterprise Flash 계층에서는 스케일 아웃보다 스케일 업에 우선 순위를 두는 이 좋습니다. Enterprise 계층은 대규모 VM에서 더 많은 CPU 코어를 활용할 수 있는 Redis Enterprise를 기준으로 하기 때문에 스케일 업에 우선 순위를 둡니다.
반대로 오픈 소스 Redis를 기준으로 하는 기본, 표준 및 프리미엄 계층에는 반대의 방식이 권장됩니다. 이러한 계층에서는 대부분의 경우 스케일 업보다 스케일 아웃에 우선 순위를 두는 것이 좋습니다.
분할 및 CPU 사용률
Azure Cache for Redis 기본, 표준 및 프리미엄 계층에서 사용된 vCPU(가상 CPU) 수를 확인하는 것은 간단합니다. 각 Redis 노드는 전용 VM에서 실행됩니다. Redis 서버 프로세스는 단일 스레드로, 각 기본 노드와 각 복제본 노드에서 하나의 vCPU를 활용합니다. VM의 다른 vCPU는 다른 작업, 상태 모니터링 및 TLS 로드에 대한 워크플로 조정 등의 다른 활동에 계속 사용됩니다.
클러스터링 사용하면 노드당 하나의 분할된 데이터베이스를 사용하여 더 많은 노드에 데이터를 분산하는 효과가 있습니다. 분할된 데이터베이스 수를 늘리면 클러스터의 분할된 데이터베이스 수에 따라 사용하는 vCPU 수가 선형적으로 증가합니다.
반면 Redis Enterprise는 Redis 인스턴스 자체에 여러 vCPU를 사용할 수 있습니다. 즉, 모든 Azure Cache for Redis 계층은 백그라운드 및 모니터링 작업에 여러 vCPU를 사용할 수 있지만 Enterprise 및 Enterprise Flash 계층만 Redis 분할된 데이터베이스용 VM당 여러 vCPU를 활용할 수 있습니다. 이 표에서는 각 SKU 및 용량(즉, 스케일 아웃) 구성에 사용되는 유효 vCPU의 수를 보여 줍니다.
이 표에는 분할된 데이터베이스 복제본이 아닌 기본 분할된 데이터베이스에 사용되는 vCPU 수가 표시됩니다. 분할된 데이터베이스는 vCPU 수에 일대일로 매핑되지 않습니다. 이 표는 분할된 데이터베이스가 아닌 vCPU만 보여 줍니다. 일부 구성은 일부 사용 시나리오에서 사용 가능한 vCPU보다 더 많은 분할된 데이터베이스를 사용하여 성능을 향상시킵니다.
E5
| 용량 | 유효 vCPU |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| 용량 | 유효 vCPU |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| 용량 | 유효 vCPU |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| 용량 | 유효 vCPU |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| 용량 | 유효 vCPU |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| 용량 | 유효 vCPU |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| 용량 | 유효 vCPU |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| 용량 | 유효 vCPU |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| 용량 | 유효 vCPU |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| 용량 | 유효 vCPU |
|---|---|
| 3 | 30 |
| 9 | 90 |
Enterprise의 클러스터링
Enterprise 및 Enterprise Flash 계층은 기본적으로 기본, 표준 및 프리미엄 계층과 다르게 클러스터링됩니다. 해당 구현은 선택한 클러스터링 정책에 따라 달라집니다. Enterprise 계층에서는 클러스터링 정책으로 OSS 및 엔터프라이즈 중 하나를 선택할 수 있습니다. OSS 클러스터 정책은 더 높은 최대 처리량을 지원하므로 대부분의 애플리케이션에 권장되지만 버전마다 장단점이 있습니다.
OSS 클러스터링 정책은 오픈 소스 Redis와 동일한 Redis 클러스터 API를 구현합니다. Redis 클러스터 API를 사용하면 Redis 클라이언트가 각 Redis 노드에 직접 연결할 수 있으므로 대기 시간이 최소화되고 네트워크 처리량이 최적화됩니다. 따라서 노드가 더 많은 클러스터를 스케일 아웃할 때 거의 선형 스케일링 성능이 확보됩니다. OSS 클러스터링 정책은 일반적으로 최상의 대기 시간 및 처리량 성능을 제공하지만 Redis Clustering을 지원하려면 클라이언트 라이브러리가 필요합니다. OSS 클러스터링 정책도 RediSearch 모듈에서 사용할 수 없습니다.
Enterprise 클러스터링 정책은 모든 클라이언트 연결에 대해 단일 엔드포인트를 활용하는 좀 더 간단한 구성입니다. Enterprise 클러스터링 정책을 사용하면 모든 요청이 단일 Redis 노드로 라우팅된 다음, 프록시로 사용되고 내부적으로 요청이 클러스터의 올바른 노드로 라우팅됩니다. 이 접근 방법의 장점은 Redis 클라이언트 라이브러리가 여러 노드를 활용하기 위해 Redis Clustering을 지원할 필요가 없다는 것입니다. 단점은 단일 노드 프록시가 컴퓨팅 사용률 또는 네트워크 처리량에서 병목 상태가 될 수 있다는 것입니다. Enterprise 클러스터링 정책은 RediSearch 모듈에서 사용할 수 있는 유일한 정책입니다.
다중 키 명령
Enterprise 계층은 클러스터형 구성을 사용하므로 여러 키에서 작동하는 명령에 CROSSSLOT 예외가 표시될 수 있습니다. 동작은 사용되는 클러스터링 정책에 따라 달라집니다. OSS 클러스터링 정책을 사용하는 경우 다중 키 명령을 사용하려면 모든 키를 동일한 해시 슬롯에 매핑해야 합니다.
Enterprise 클러스터링 정책에 CROSSSLOT 오류가 표시될 수도 있습니다. Enterprise 클러스터링을 사용하는 슬롯에서 DEL, MSET, MGET, EXISTS, UNLINK 및 TOUCH의 다중 키 명령만 허용됩니다.
활성-활성 데이터베이스에서 다중 키 쓰기 명령(DEL, MSET, UNLINK)은 동일한 슬롯에 있는 키에서만 실행할 수 있습니다. 그러나 다중 키 명령 MGET, EXISTS 및 TOUCH는 활성-활성 데이터베이스의 슬롯에서 허용됩니다. 자세한 내용은 데이터베이스 클러스터링을 참조하세요.
Enterprise Flash 모범 사례
Enterprise Flash 계층은 NVMe 플래시 스토리지와 RAM을 모두 활용합니다. 플래시 스토리지는 비용이 저렴하므로 Enterprise Flash 계층을 사용하면 가격 효율성을 위해 일부 성능을 절충할 수 있습니다.
Enterprise Flash 인스턴스에서는 캐시 공간의 20%가 RAM에 있고 나머지 80%는 Flash 스토리지를 사용합니다. 모든 키는 RAM에 저장되는 반면, 값은 플래시 스토리지나 RAM에 저장할 수 있습니다. 값의 위치는 Redis 소프트웨어에 의해 지능적으로 결정됩니다. 자주 액세스되는 "핫" 값은 RAM에 저장되고, 덜 일반적으로 사용되는 "콜드" 값은 플래시에 보관됩니다. 데이터를 읽거나 쓰기 전에 RAM으로 이동하여 "핫" 데이터가 되어야 합니다.
Redis는 최상의 성능을 최적화하기 때문에 인스턴스는 플래시 스토리지에 항목을 추가하기 전에 먼저 사용 가능한 RAM을 채웁니다. 이는 성능에 몇 가지 영향을 미칩니다.
- 낮은 메모리 사용량으로 테스트할 경우 RAM만 사용되므로 전체 캐시 인스턴스를 사용할 때보다 성능과 대기 시간이 훨씬 더 좋을 수 있습니다.
- 캐시에 더 많은 데이터를 쓰면 플래시 스토리지에 비해 RAM의 데이터 비율이 줄어들고 일반적으로 대기 시간과 처리량 성능도 저하됩니다.
Enterprise Flash 계층에 적합한 워크로드
Enterprise Flash 계층에서 원활하게 실행될 수 있는 워크로드는 다음과 같은 특징을 갖는 경우가 많습니다.
- 읽기가 많고 쓰기 명령에 대한 읽기 명령의 비율이 높습니다.
- 액세스는 데이터 세트의 나머지 부분보다 훨씬 더 자주 사용되는 키 하위 집합에 중점을 둡니다.
- 키 이름에 비해 상대적으로 큰 값입니다. (키 이름은 항상 RAM에 저장되므로 메모리 증가에 병목 현상이 발생할 수 있습니다.)
Enterprise Flash 계층에 적합하지 않은 워크로드
일부 워크로드에는 플래시 계층 디자인에 덜 최적화된 액세스 특성이 있습니다.
- 쓰기 작업이 많은 워크로드
- 대부분의 데이터 세트에서 임의 또는 균일한 데이터 액세스 패턴입니다.
- 값 크기가 상대적으로 작은 긴 키 이름입니다.
활성 지역 복제를 사용하여 지역 가동 중단 시나리오 처리
활성 지역 복제는 Azure Cache for Redis용 Enterprise 계층을 사용할 때 가용성을 크게 높일 수 있는 강력한 기능입니다. 그러나 지역 가동 중단이 있는 경우 캐시 준비 단계를 수행해야 합니다.
예를 들어 다음 팁을 고려해 보세요.
- 한 지역이 가동 중단되면 전환할 지역 복제 그룹의 다른 캐시를 미리 식별합니다.
- 모든 애플리케이션과 클라이언트가 식별된 백업 캐시에 액세스할 수 있도록 방화벽이 설정되어 있는지 확인합니다.
- 지역 복제 그룹의 각 캐시에는 자체 액세스 키가 있습니다. 백업 캐시를 대상으로 지정할 때 애플리케이션이 다른 액세스 키로 전환하는 방법을 결정합니다.
- 지역 복제 그룹의 캐시가 가동 중단되면 지역 복제 그룹의 모든 캐시에서 메타데이터가 증가하기 시작합니다. 쓰기를 모든 캐시에 다시 동기화할 수 있을 때까지 메타데이터를 삭제할 수 없습니다. 다운된 캐시를 강제로 연결 해제하여 메타데이터가 커지는 것을 방지할 수 있습니다. 특히 쓰기가 많은 워크로드의 경우 캐시에서 사용 가능한 메모리를 모니터링하고 메모리 압력이 있는 경우 연결을 해제하는 것이 좋습니다.
회로 차단기 패턴을 사용할 수도 있습니다. 이 패턴을 사용하여 지역 중단이 발생한 캐시에서 동일한 지역 복제 그룹의 백업 캐시로 트래픽을 자동으로 리디렉션합니다. Azure Traffic Manager 또는 Azure Load Balancer와 같은 Azure 서비스를 사용하여 리디렉션을 사용하도록 설정합니다.
데이터 지속성 및 데이터 백업
Enterprise 및 Enterprise Flash 계층의 데이터 지속성 기능은 캐시가 다운되면 데이터에 대한 빠른 복구 지점을 자동으로 제공하도록 설계되었습니다. 캐시 인스턴스에 탑재된 관리 디스크에 RDB 또는 AOF 파일을 저장하여 빠른 복구를 가능하게 합니다. 디스크의 지속성 파일은 사용자가 액세스할 수 없습니다.
많은 고객이 지속성을 사용하여 캐시에 있는 데이터를 주기적으로 백업하려고 합니다. 이러한 방식으로 데이터 지속성을 사용하지 않는 것이 좋습니다. 대신 Import/Export 기능을 사용합니다. RDB 형식의 캐시 데이터 복사본을 선택한 스토리지 계정으로 직접 내보내고 필요한 만큼 자주 데이터 내보내기를 트리거할 수 있습니다. 내보내기는 포털에서 또는 CLI, PowerShell 또는 SDK 도구를 사용하여 트리거할 수 있습니다.