Azure Cache for Redis 는 Redis(원격 사전 서버) 소프트웨어를 기반으로 메모리 내 데이터 저장소를 제공합니다. 애플리케이션의 데이터에 대한 높은 처리량과 짧은 대기 시간 액세스를 제공하는 보안 데이터 캐시 및 메시징 브로커입니다.
운영 우수성을 지원하는 모범 사례는 다음과 같습니다.
다음 섹션에는 디자인 고려 사항, 구성 검사 목록 및 Azure Cache for Redis와 관련된 권장 구성 옵션이 포함됩니다.
디자인 고려 사항
Azure Cache for Redis SLA(서비스 수준 계약)는 표준 및 프리미엄 계층 캐시만 포함합니다. 기본 계층은 적용되지 않습니다.
Redis는 키 값 쌍에 대한 메모리 내 캐시이며 기본 계층을 제외하고 기본적으로 HA(고가용성)를 가집니다. Azure Cache for Redis에는 다음 세 가지 계층이 있습니다.
기본: 프로덕션 워크로드에는 권장되지 않습니다. 기본 계층은 다음 작업에 적합합니다.
- 단일 노드
- 여러 크기
- 발달
- 테스트
- 중요하지 않은 워크로드
표준: 고가용성 SLA를 사용하여 Microsoft에서 관리하는 2노드 주 및 보조 구성의 복제된 캐시입니다.
프리미엄: 모든 표준 계층 기능을 포함하며 다음과 같은 다른 기능을 포함합니다.
- 기본 또는 표준 계층에 비해 하드웨어 및 성능이 더 빠릅니다.
- 더 큰 캐시 크기, 최대
120GB. - RDB(Redis Database File) 및 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 구성을 최적화하려면 다음 권장 사항 표를 살펴보세요.
| 추천 | 설명 |
|---|---|
| 업데이트 일정을 잡습니다. | Azure 업데이트 또는 VM 운영 체제에 대한 업데이트를 포함하지 않는 Redis Server 업데이트가 캐시에 적용되는 날짜 및 시간을 예약합니다. |
| 캐시를 모니터링하고 경고를 설정합니다. | 캐시 크기를 조정하는 시기에 대한 인사이트를 위해 예외, 높은 CPU, 높은 메모리 사용량, 서버 부하 및 제거된 키에 대한 경고를 설정합니다. 캐시의 크기를 조정해야 하는 경우 크기 조정 이벤트 중에 데이터를 마이그레이션하는 동안 CPU가 증가하므로 크기를 조정해야 하는 시기를 이해하는 것이 중요합니다. |
| VNET 내에 캐시를 배포합니다. | 고객에게 캐시에 연결할 수 있는 트래픽에 대한 더 많은 제어를 제공합니다. 서브넷에 캐시 노드 및 분할된 데이터베이스(클러스터)를 배포하는 데 사용할 수 있는 충분한 주소 공간이 있는지 확인합니다. |
| 솔루션 내에서 올바른 캐싱 형식(로컬, 역할, 관리형, redis)을 사용합니다. | 분산 애플리케이션은 일반적으로 데이터를 캐싱할 때 다음 전략 중 하나 또는 둘 다를 구현합니다. - 애플리케이션 또는 서비스의 인스턴스를 실행하는 컴퓨터에서 데이터가 로컬로 유지되는 프라이빗 캐시 사용 - 공유 캐시를 사용하여 여러 프로세스 및 컴퓨터에서 액세스할 수 있는 공통 소스 역할을 합니다. 두 경우 모두 캐싱은 클라이언트 쪽 및 서버 쪽에서 수행할 수 있습니다. 클라이언트 쪽 캐싱은 웹 브라우저 또는 데스크톱 애플리케이션과 같은 시스템에 대한 사용자 인터페이스를 제공하는 프로세스에 의해 수행됩니다. 서버 쪽 캐싱은 원격으로 실행되는 비즈니스 서비스를 제공하는 프로세스에 의해 수행됩니다. |
| 비즈니스 요구 사항에 따라 캐시 복사본을 Azure Storage에 저장하거나 지역에서 복제를 사용하도록 데이터 지속성을 구성합니다. | 데이터 지속성: 마스터 및 복제본이 다시 부팅되면 스토리지 계정에서 데이터가 자동으로 로드됩니다. 지리적 복제: 보조 캐시를 주 캐시에서 연결 해제해야 합니다. 이제 보조 데이터베이스가 주 복제본이 되며 쓰기를 받을 수 있습니다. |
| Azure Cache for Redis를 관리하는 방법을 검토합니다. | 캐시 재부팅으로 데이터 손실이 발생할 수 있는 방법과 복원력을 위해 애플리케이션을 테스트하는 방법을 이해합니다. |
원본 아티팩트
프리미엄 계층에 없는 Redis 인스턴스를 식별하려면 다음 쿼리를 사용합니다.
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'