Azure Cache for Redis 및 안정성
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 데이터베이스 파일) 및 AOF(추가 전용 파일)를 포함하는 데이터 지속성.
- VNET 지원.
- 클러스터링
- 지역 복제: 보조 캐시는 다른 지역에 있으며 재해 복구를 위해 기본 캐시에서 데이터를 복제합니다. 보조 캐시로 장애 조치(failover)하려면 캐시를 수동으로 연결 해제해야 하며 보조 캐시는 쓰기에 사용할 수 있습니다. Redis에 쓰는 애플리케이션은 보조 캐시 연결 문자열로 업데이트해야 합니다.
- 가용성 영역: 가용성 영역에 캐시와 복제본을 배포합니다.
참고
기본적으로 각 배포에는 분할당 하나의 복제본이 있습니다. 둘 이상의 복제본이 있는 배포에서는 현재 지속성, 클러스터링 및 지역 복제가 모두 사용하지 않도록 설정됩니다. 노드는 모든 영역에 고르게 분산됩니다. 복제본 수
>=영역 수가 있어야 합니다. - 가져오고 내보냅니다.
Microsoft는 고객이 캐시 엔드포인트와 Microsoft의 인터넷 게이트웨이 간에 연결되는 시간 중 최소 99.9%를 보장합니다.
검사 목록
복원력을 염두에 두고 Azure Cache for Redis를 구성했나요?
- 업데이트를 예약합니다.
- 캐시를 모니터링하고 경고를 설정합니다.
- VNET 내에 캐시를 배포합니다.
- Redis Cache 내에서 분할 전략을 평가합니다.
- 비즈니스 요구 사항에 따라 Azure Storage에 캐시 사본을 저장하거나 지역 복제를 사용하도록 데이터 지속성을 구성합니다.
- Azure Redis Cache 컨텍스트에서 다시 시도 정책을 구현합니다.
- Redis에 대한 연결 멀티플렉서의 정적 또는 싱글톤 구현을 사용하고 모범 사례 가이드를 따릅니다.
- Azure Cache for Redis를 관리하는 방법을 검토합니다.
구성 권장 사항
서비스 안정성을 위해 Azure Cache for Redis 구성을 최적화하기 위한 다음 권장 사항 표를 살펴봅니다.
| 권장 | Description |
|---|---|
| 업데이트를 예약합니다. | Azure 업데이트 또는 VM 운영 체제에 대한 업데이트를 포함하지 않는 Redis 서버 업데이트가 캐시에 적용될 날짜와 시간을 예약합니다. |
| 캐시를 모니터링하고 경고를 설정합니다. | 예외, 높은 CPU, 상위 메모리 사용량, 서버 로드 및 제거된 키에 대한 경고를 설정하여 캐시 스케일링 시점에 대한 인사이트를 얻습니다. 캐시를 스케일링해야 하는 경우 데이터 마이그레이션을 위한 스케일링 이벤트 동안 CPU가 증가하므로 스케일링 시점을 이해하는 것이 중요합니다. |
| VNET 내에 캐시를 배포합니다. | 고객이 캐시에 연결할 수 있는 트래픽을 더 잘 제어할 수 있습니다. 서브넷에 캐시 노드 및 분할(클러스터)을 배포하는 데 사용할 수 있는 충분한 주소 공간이 있는지 확인합니다. |
| Redis Cache 내에서 분할 전략을 평가합니다. | Redis 데이터 저장소를 분할하려면 Redis 서버의 인스턴스 간에 데이터를 분할해야 합니다. 각 인스턴스는 단일 파티션을 구성합니다. Azure Redis Cache는 외관 뒤에서 Redis 서비스를 추상화하고 직접 노출하지 않습니다. 분할을 구현하는 가장 간단한 방법은 다수의 Azure Redis Cache 인스턴스를 만들어 데이터를 분산하는 것입니다. 각 데이터 항목은 저장할 캐시를 지정하는 식별자(파티션 키)와 연결할 수 있습니다. 클라이언트 애플리케이션 논리에 이 식별자를 사용하여 요청을 적절한 파티션으로 라우트할 수 있습니다. 이 체계는 간단하지만 분할 체계가 변경되는 경우(예: 추가 Azure Redis Cache 인스턴스가 만들어지는 경우) 클라이언트 애플리케이션을 재구성해야 할 수 있습니다. |
| 비즈니스 요구 사항에 따라 Azure Storage에 캐시 사본을 저장하거나 지역 복제를 사용하도록 데이터 지속성을 구성합니다. | 데이터 지속성: 마스터 및 복제본이 다시 부팅되면 스토리지 계정에서 데이터가 자동으로 로드됩니다. 지역 복제: 보조 캐시는 기본 캐시에서 연결 해제되어야 합니다. 이제 보조가 기본이 되어 쓰기를 수신할 수 있습니다. |
| Azure Redis Cache 컨텍스트에서 다시 시도 정책을 구현합니다. | 대부분의 Azure 서비스 및 클라이언트 SDK는 재시도 메커니즘을 제공합니다. 각 서비스에는 서로 다른 특성과 요구 사항이 있기 때문에 이러한 메커니즘이 다릅니다. 각 다시 시도 메커니즘은 특정 서비스에 맞게 조정됩니다. |
| Azure Cache for Redis를 관리하는 방법을 검토합니다. | 캐시 다시 부팅 시 데이터 손실이 발생할 수 있는 방법과 애플리케이션의 복원력을 테스트하는 방법을 이해합니다. |
원본 아티팩트
프리미엄 계층에 없는 Redis 인스턴스를 식별하려면 다음 쿼리를 사용합니다.
Resources
| where type == 'microsoft.cache/redis'
| where properties.sku.name != 'Premium'