Azure Cache for Redis 및 운영 우수성

아티클
11/14/2023

Azure Cache for Redis는 Redis(원격 사전 서버) 소프트웨어를 기반으로 하는 메모리 내 데이터 저장소를 제공합니다. Azure Redis Cache는 애플리케이션의 데이터에 대한 많은 처리량을 짧은 대기 시간 동안 처리할 수 있는 보안 데이터 캐시이자 메시지 broker입니다.

운영 우수성을 지원하는 모범 사례는 다음과 같습니다.

다음 섹션에는 Azure Cache for Redis와 관련된 설계 고려 사항, 구성 검사 목록 및 권장 구성 옵션이 포함되어 있습니다.

디자인 고려 사항

Azure Cache for Redis SLA(서비스 수준 계약)는 표준 및 프리미엄 계층 캐시에만 적용됩니다. 기본 계층은 적용되지 않습니다.

Redis는 키 값 쌍을 위한 메모리 내 캐시이며 기본 계층을 제외하고 기본적으로 HA(고가용성)가 있습니다. Azure Cache for Redis에는 세 가지 계층이 있습니다.

기본: 프로덕션 워크로드에는 권장되지 않습니다. 기본 계층은 다음에 적합합니다.
- 단일 노드
- 다양한 크기
- 개발
- 테스트
- 중요도가 낮은 워크로드
표준: 고가용성 SLA를 사용하여 Microsoft에서 관리하는 2노드 기본 및 보조 구성의 복제된 캐시입니다.
프리미엄: 모든 표준 계층 기능과 다음과 같은 기타 기능이 포함됩니다.
- 기본 또는 표준 계층에 비해 하드웨어 및 성능이 더 빠름.
- 더 큰 캐시 크기(최대 120GB).
- RDB(Redis 데이터베이스 파일) 및 AOF(추가 전용 파일)를 포함하는 데이터 지속성.
- VNET 지원.
- 클러스터링
- 지역 복제: 보조 캐시는 다른 지역에 있으며 재해 복구를 위해 기본 캐시에서 데이터를 복제합니다. 보조 캐시로 장애 조치(failover)하려면 캐시를 수동으로 연결 해제해야 하며 보조 캐시는 쓰기에 사용할 수 있습니다. Redis에 쓰는 애플리케이션은 보조 캐시 연결 문자열로 업데이트해야 합니다.
- 가용성 영역: 가용성 영역에 캐시와 복제본을 배포합니다.
  
  참고
  
  기본적으로 각 배포에는 분할당 하나의 복제본이 있습니다. 둘 이상의 복제본이 있는 배포에서는 현재 지속성, 클러스터링 및 지역 복제가 모두 사용하지 않도록 설정됩니다. 노드는 모든 영역에 고르게 분산됩니다. 복제본 수 >= 영역 수가 있어야 합니다.
- 가져오고 내보냅니다.

Microsoft는 고객이 캐시 엔드포인트와 Microsoft의 인터넷 게이트웨이 간에 연결되는 시간 중 최소 99.9%를 보장합니다.

검사 목록

운영 우수성을 염두에 두고 Azure Cache for Redis를 구성했나요?

업데이트를 예약합니다.
캐시를 모니터링하고 경고를 설정합니다.
VNET 내에 캐시를 배포합니다.
솔루션 내에서 올바른 캐싱 형식(로컬, 역할 내, 관리형, redis)을 사용합니다.
비즈니스 요구 사항에 따라 Azure Storage에 캐시 사본을 저장하거나 지역 복제를 사용하도록 데이터 지속성을 구성합니다.
Redis에 대한 정적 또는 싱글톤 연결 멀티플렉서를 구현하고 모범 사례 가이드를 따릅니다.
Azure Cache for Redis를 관리하는 방법을 검토합니다.

구성 권장 사항

Azure Cache for Redis 구성을 최적화하여 운영 우수성을 달성하기 위한 다음 권장 사항 표를 살펴보세요.

권장	Description
업데이트를 예약합니다.	Azure 업데이트 또는 VM 운영 체제에 대한 업데이트를 포함하지 않는 Redis 서버 업데이트가 캐시에 적용될 날짜와 시간을 예약합니다.
캐시를 모니터링하고 경고를 설정합니다.	예외, 높은 CPU, 상위 메모리 사용량, 서버 로드 및 제거된 키에 대한 경고를 설정하여 캐시 스케일링 시점에 대한 인사이트를 얻습니다. 캐시를 스케일링해야 하는 경우 데이터 마이그레이션을 위한 스케일링 이벤트 동안 CPU가 증가하므로 스케일링 시점을 이해하는 것이 중요합니다.
VNET 내에 캐시를 배포합니다.	고객이 캐시에 연결할 수 있는 트래픽을 더 잘 제어할 수 있습니다. 서브넷에 캐시 노드 및 분할된 데이터베이스(클러스터)를 배포하기에 충분한 주소 공간이 있는지 확인합니다.
솔루션 내에서 올바른 캐싱 형식(로컬, 역할 내, 관리형, redis)을 사용합니다.	분산된 애플리케이션은 데이터를 캐시할 때 일반적으로 다음 전략 중 하나 또는 모두를 구현합니다. - 데이터가 애플리케이션 또는 서비스의 인스턴스를 실행하는 머신에서 로컬로 유지되는 프라이빗 캐시를 사용합니다. - 여러 프로세스와 머신에서 액세스할 수 있는 일반적인 소스 역할로 공유 캐시를 사용합니다. 두 경우 모두 클라이언트 쪽과 서버 쪽에서 캐싱이 수행될 수 있습니다. 클라이언트 쪽 캐싱은 웹 브라우저 또는 데스크톱 애플리케이션과 같이 시스템의 사용자 인터페이스를 제공하는 프로세스에서 수행됩니다. 서버 쪽 캐싱은 원격으로 실행되는 비즈니스 서비스를 제공하는 프로세스에서 수행됩니다.
비즈니스 요구 사항에 따라 Azure Storage에 캐시 사본을 저장하거나 지역 복제를 사용하도록 데이터 지속성을 구성합니다.	데이터 지속성: 마스터 및 복제본이 다시 부팅되면 스토리지 계정에서 데이터가 자동으로 로드됩니다. 지역 복제: 보조 캐시는 기본 캐시에서 연결 해제되어야 합니다. 이제 보조가 기본이 되어 쓰기를 수신할 수 있습니다.
Azure Cache for Redis를 관리하는 방법을 검토합니다.	캐시 다시 부팅 시 데이터 손실이 발생할 수 있는 방법과 애플리케이션의 복원력을 테스트하는 방법을 이해합니다.

원본 아티팩트

프리미엄 계층에 없는 Redis 인스턴스를 식별하려면 다음 쿼리를 사용합니다.

Resources 
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'

다음 단계

Azure Databricks 및 보안

다음을 통해 공유