Share via


Azure Cache for Redis 및 안정성

Azure Cache for RedisRedis(원격 사전 서버) 소프트웨어를 기반으로 하는 메모리 내 데이터 저장소를 제공합니다. 애플리케이션용 데이터에 대한 높은 처리량과 짧은 대기 시간 액세스를 제공하는 안전한 데이터 캐시 및 메시징 브로커입니다.

안정성을 지원하는 주요 개념 및 모범 사례는 다음과 같습니다.

다음 섹션에는 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'

다음 단계