다음을 통해 공유

Azure Managed Redis(미리 보기) 인스턴스 크기 조정

  • 아티클

Azure Managed Redis(미리 보기)에는 캐시 크기 및 성능을 유연하게 선택할 수 있는 다양한 SKU 및 계층 제품이 있습니다. 더 큰 메모리 크기로 확장하거나 더 많은 컴퓨팅 성능을 가진 계층으로 변경할 수 있습니다. 이 문서에서는 Azure Portal과 Azure PowerShell 및 Azure CLI와 같은 도구를 사용하여 캐시 크기를 조정하는 방법을 보여 줍니다.

참고 항목

Azure Managed Redis의 각 계층에는 거의 동일한 기능이 있으므로 크기 조정은 일반적으로 메모리 및 성능 특성을 변경하는 데만 사용됩니다.

Important

현재는 더 큰 메모리 크기 또는 더 높은 성능 계층으로 확장만 지원됩니다. 메모리 크기를 축소하거나 성능이 낮은 계층으로 축소하는 것은 아직 지원되지 않습니다.

크기 조정 유형

Azure Managed Redis는 다음 두 차원의 크기 조정을 지원합니다.

  • 메모리 를 늘리면 Redis 인스턴스의 크기가 증가하므로 더 많은 데이터를 저장할 수 있습니다.

  • vCPU Azure Managed Redis는 각 메모리 수준에 대한 vCPU 수가 증가하는 세 가지 계층(메모리 최적화, 분산 및 컴퓨팅 최적화)을 제공합니다. vCPU가 더 많은 계층으로 확장하면 메모리를 늘릴 필요 없이 인스턴스의 성능이 향상됩니다. 단일 vCPU만 활용할 수 있는 Redis의 커뮤니티 버전과 달리 Azure Managed Redis는 여러 vCPU를 사용할 수 있는 Redis Enterprise 스택을 사용합니다. 즉, Redis 인스턴스에서 사용하는 vCPU 수는 처리량 및 대기 시간 성능과 직접 상관 관계가 있습니다.

성능 계층

Azure Managed Redis에는 각각 성능 특성과 가격 수준이 서로 다른 4개의 계층을 사용할 수 있습니다.

세 가지 계층은 메모리 내 데이터에 대한 것입니다.

  • 메모리 최적화. 높은 메모리 대 vCPU 비율(8:1)이 필요하지만 가장 높은 처리량 성능이 필요하지 않은 메모리 집약적 사용 사례에 적합합니다. 더 적은 처리 능력 또는 처리량이 필요한 시나리오에 대해 더 낮은 가격점을 제공하여 개발 및 테스트 환경에 적합한 선택입니다.
  • 균형(메모리 + 컴퓨팅). 균형 잡힌 메모리 대 vCPU(4:1) 비율을 제공하여 표준 워크로드에 적합합니다. 메모리 및 컴퓨팅 리소스의 정상 균형을 제공합니다.
  • 컴퓨팅 최적화. 메모리 대 vCPU(2:1) 비율이 낮은 최대 처리량이 필요한 성능 집약적 워크로드용으로 설계되었습니다. 가장 높은 성능을 요구하는 애플리케이션에 이상적입니다.

한 계층은 메모리 내 및 디스크의 데이터를 모두 저장합니다.

  • 플래시 최적화. Redis 클러스터가 메모리(RAM)에서 NVMe 스토리지로 덜 자주 액세스하는 데이터를 자동으로 이동할 수 있도록 합니다. 이렇게 하면 성능이 저하되지만 큰 데이터 세트를 사용하여 캐시를 비용 효율적으로 스케일링할 수 있습니다.

계층 및 SKU 한눈에 보기

Azure Managed Redis의 각 SKU 및 계층에 대한 다양한 메모리 및 vCPU 구성을 보여 주는 표입니다.

성능(처리량 및 대기 시간)

성능 벤치마크 및 각 SKU 및 계층의 성능을 측정하는 방법에 대한 자세한 내용은 Azure Managed Redis를 사용한 성능 테스트를 참조하세요 .

크기를 조정하는 경우

Azure Managed Redis의 모니터링 기능을 사용하여 캐시의 상태 및 성능을 모니터링할 수 있습니다. 이 정보를 사용하여 캐시 크기 조정 시기를 결정합니다.

다음 메트릭을 모니터링하면 크기를 조정해야 하는지 결정하는데 도움이 될 수 있습니다.

  • CPU
    • 높은 CPU 사용량은 Redis 서버가 모든 클라이언트의 요청과 보조를 맞추지 못했음을 의미합니다. 더 많은 vCPU로 확장하면 여러 Redis 프로세스에 요청을 분산하는 데 도움이 됩니다. 또한 크기를 조정하면 TLS 암호화/암호 해독 및 연결/연결 끊김을 분산하여 TLS를 사용하여 캐시 인스턴스의 속도를 높일 수 있습니다.
  • 메모리 사용량
    • 높은 메모리 사용량은 데이터 크기가 현재 캐시 크기에 비해 너무 큰 것을 나타냅니다. 더 큰 메모리를 사용하는 캐시 크기로 크기를 조정하는 것을 고려합니다.
  • 클라이언트 연결
    • 각 캐시 크기에는 지원할 수 있는 클라이언트 연결 수에 대한 제한이 있습니다. 클라이언트 연결이 캐시 크기 제한에 근접한 경우 더 큰 메모리 크기 또는 더 높은 성능 계층으로 크기를 조정하는 것이 좋습니다.
    • 캐시 크기별 연결 제한에 대한 자세한 내용은 Azure Managed Redis를 사용한 성능 테스트를 참조하세요.
  • 네트워크 대역폭
    • Redis 서버에서 사용 가능한 대역폭을 초과하는 경우 서버에서 클라이언트에 데이터를 충분히 빠르게 푸시할 수 없기 때문에 클라이언트 요청 시간이 초과될 수 있습니다. 사용 중인 서버 쪽 대역폭의 양을 확인하려면 "캐시 읽기" 및 "캐시 쓰기" 메트릭을 확인합니다. Redis 서버가 사용 가능한 네트워크 대역폭을 초과하는 경우 더 높은 성능 계층 또는 더 큰 캐시 크기로 확장하는 것이 좋습니다.
    • 클러스터 정책 선택은 사용 가능한 네트워크 대역폭에 영향을 줍니다. 일반적으로 OSS 클러스터 정책은 엔터프라이즈 클러스터 정책보다 네트워크 대역폭이 높습니다. 자세한 내용은 클러스터 정책을 참조하세요 .
    • 캐시 크기별 네트워크 사용 가능한 대역폭에 대한 자세한 내용은 Azure Managed Redis를 사용한 성능 테스트를 참조하세요.

사용할 캐시 가격 책정 계층을 결정하는 방법에 대한 자세한 내용은 올바른 계층 선택을 참조 하세요.

참고 항목

스케일링 프로세스를 최적화하는 방법에 대한 자세한 내용은 스케일링 모범 사례 가이드를 참조하세요.

Azure Managed Redis 크기 조정의 필수 구성 요소/제한 사항

  • 메모리 최적화, 분산 또는 컴퓨팅 최적화 계층에서 플래시 최적화 계층으로 확장하거나 그 반대로 확장할 수 없습니다.
  • vCPU 수가 적은 SKU로 축소할 수 없습니다. (계층 간 또는 계층 내에서)
  • vCPU가 동일하거나 더 많은 경우에도 더 작은 메모리 크기로 축소할 수 없습니다.
  • 크기 조정 시 Redis 인스턴스의 기본 IP 주소가 변경될 수 있는 경우도 있습니다. 인스턴스에 대한 DNS 레코드가 변경되고 대부분의 애플리케이션에 투명합니다. 그러나 IP 주소를 사용하여 캐시에 대한 연결을 구성하거나 NSG 또는 캐시에 대한 트래픽을 허용하는 방화벽을 구성하는 경우 DNS 레코드가 업데이트된 후 애플리케이션 연결에 문제가 발생할 수 있습니다.
  • 지역에서 복제 그룹의 인스턴스 크기를 조정하는 데는 몇 가지 제한 사항이 있습니다. 자세한 내용은 지역 복제에 대한 크기 조정 제한이 있나요?

확장 방법

팁

하나의 작업에서 메모리 크기와 성능 계층을 모두 변경할 수 있습니다.

Azure Portal을 사용하여 스케일링

  1. 캐시 크기를 조정하려면 Azure Portal에서 캐시를 찾은 다음, 리소스 메뉴에서 스케일링을 선택합니다.

    Enterprise 캐시의 리소스 메뉴에서 선택한 스케일링을 보여 주는 스크린샷.

  2. 스케일 업하려면 다른 캐시 유형을 선택한 다음, 저장을 선택합니다.

    Important

    크기를 조정할 수 없는 SKU를 선택하면 저장 옵션을 사용할 수 없습니다. 크기 조정 옵션이 허용되는 자세한 내용은 Azure Managed Redis 크기 조정의 필수 구성 요소/제한 사항을 검토합니다.

    작업 창의 Enterprise 계층을 보여 주는 스크린샷.

  3. 캐시가 새 계층으로 크기 조정되는 동안 Redis Cache 크기 조정 알림이 표시됩니다.

    Enterprise 캐시 스케일링 알림을 보여 주는 스크린샷.

  4. 크기 조정이 완료되면 상태가 Scaling(크기 조정 중)에서 실행 중으로 변경됩니다.

PowerShell을 사용하여 크기 조정

Update-AzRedisEnterpriseCache cmdlet을 사용하여 PowerShell을 사용하여 Azure Managed Redis 인스턴스의 크기를 조정할 수 있습니다. 필요한 계층 및 SKU를 선택하도록 속성을 수정 Sku 할 수 있습니다. 다음 예제에서는 컴퓨팅 최적화 X20(24GB) 인스턴스로 명명 myCache 된 캐시의 크기를 조정하는 방법을 보여 줍니다.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku ComputeOptimized_X20

Azure CLI를 사용한 크기 조정

Azure CLI를 사용하여 Azure Managed Redis 인스턴스의 크기를 조정하려면 az redisenterprise update 명령을 호출합니다. 필요한 계층 및 SKU를 선택하도록 속성을 수정 sku 할 수 있습니다. 다음 예제에서는 컴퓨팅 최적화 X20(24GB) 인스턴스로 명명 myCache 된 캐시의 크기를 조정하는 방법을 보여 줍니다.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "ComputeOptimized_X20"

크기 조정 FAQ

다음 목록에는 Azure Managed Redis 크기 조정에 대한 일반적인 질문에 대한 답변이 포함되어 있습니다.

계층 내에서 또는 계층 간에 크기를 조정할 수 있나요?

동일한 메모리 크기 또는 동일한 성능 계층 내에서 더 큰 메모리 크기로 항상 더 높은 성능 계층으로 확장할 수 있습니다. 낮은 성능 계층 또는 더 작은 메모리 크기로 크기를 조정하려면 Azure Managed Redis 크기 조정의 필수 구성 요소/제한 사항을 참조하세요.

크기를 조정한 후 내 캐시 이름 또는 액세스 키를 변경해야 하나요?

아니요, 캐시 이름 및 키는 크기 조정 작업을 수행하는 동안 변경되지 않습니다.

크기 조정은 어떻게 수행되나요?

  • Redis 인스턴스의 크기를 조정하면 Redis 클러스터의 노드 중 하나가 종료되고 새 크기로 다시 프로비전됩니다. 그런 다음 데이터가 전송된 다음 다른 노드가 다시 프로비전되기 전에 유사한 장애 조치(failover)를 수행합니다. 이는 캐시 노드 중 하나의 패치 또는 실패 중에 발생하는 프로세스와 유사합니다.
  • vCPU가 더 많은 인스턴스로 스케일링하는 경우 새 분할된 데이터베이스가 프로비전되어 Redis 서버 클러스터에 추가됩니다. 그러면 모든 분할에 걸쳐 데이터가 재분할됩니다.

Azure Managed Redis에서 분할을 처리하는 방법에 대한 자세한 내용은 분할 구성을 참조하세요.

스케일링하는 동안 캐시의 데이터가 손실되나요?

  • 고가용성 모드를 사용하는 경우 크기 조정 작업 중에 모든 데이터를 보존해야 합니다.
  • 더 작은 메모리 수준으로 축소하는 경우 캐시가 축소될 때 데이터 크기가 새 작은 크기를 초과하면 데이터가 손실될 수 있습니다. 크기를 축소하는 경우 데이터가 손실되면 allkeys-lru 제거 정책을 사용하여 키를 제거합니다.
  • 고가용성 모드를 사용하지 않도록 설정하면 모든 데이터가 손실되고 크기 조정 작업 중에 캐시를 사용할 수 없습니다.

크기를 조정하는 동안 내 캐시를 사용할 수 있나요?

  • 고가용성 모드가 설정된 Azure Managed Redis 인스턴스는 크기 조정 작업 중에 계속 사용할 수 있습니다. 그러나 이러한 캐시의 크기를 조정하는 동안 연결 블립이 발생할 수 있습니다. 이러한 연결 블립은 일반적으로 짧으며 Redis 클라이언트는 일반적으로 즉시 연결을 다시 설정할 수 있습니다.
  • 고가용성 모드를 사용하지 않도록 설정하면 크기 조정 작업 중에 Azure Managed Redis 인스턴스가 오프라인 상태가 됩니다.

지역 복제에 크기 조정 제한 사항이 있나요?

활성 지역 복제가 구성된 경우 지역 복제 그룹의 캐시 크기를 혼합하고 일치시킬 수 없습니다. 따라서 지역 복제 그룹의 캐시 크기를 조정하려면 몇 가지 단계가 더 필요합니다. 지침은 지역 복제 그룹의 인스턴스 크기 조정을 참조하세요.

크기 조정은 시간이 얼마나 걸리나요?

크기 조정 시간은 몇 가지 요인에 따라 달라집니다. 크기 조정 시간에 영향을 줄 수 있는 몇 가지 요인은 다음과 같습니다.

  • 데이터 양: 많은 양의 데이터를 복제하는 데 시간이 더 오래 소요됩니다.
  • 높은 쓰기 요청: 쓰기 수가 많으면 노드 또는 분할 간에 더 많은 데이터가 복제됩니다.
  • 높은 CPU 사용량: CPU 사용량이 높으면 Redis 서버가 사용 중이며 제한된 CPU 주기를 사용하여 데이터 재배포를 완료할 수 있음을 의미합니다.

일반적으로 데이터가 없는 인스턴스의 크기를 조정하는 경우 약 10분이 걸립니다.

크기 조정이 완료되었는지 어떻게 알 수 있나요?

Azure Portal에서 진행 중인 크기 조정 작업을 볼 수 있습니다. 크기 조정이 완료되면 캐시 상태가 실행 중으로 변경됩니다.

Azure Managed Redis는 클러스터링을 사용하나요?

Azure Cache for Redis와 달리 Azure Managed Redis는 모든 계층 및 SKU에서 클러스터링을 사용합니다. 클러스터링을 사용하면 상당한 성능 최적화가 가능합니다. Azure Managed Redis의 각 SKU는 사용 가능한 vCPU 수에 대해 최적화된 분할된 데이터베이스 수에 대해 구성됩니다. 분할된 데이터베이스 수는 사용자가 구성할 수 없습니다.

각 Azure Managed Redis SKU에서 사용하는 분할된 데이터베이스는 몇 개입니까?

Azure Managed Redis는 Redis Enterprise 소프트웨어에서 실행되므로 커뮤니티 Redis보다 조밀한 구성에서 분할된 데이터베이스를 사용할 수 있습니다. 각 SKU에 사용되는 특정 분할된 데이터베이스 수에 대해 알아보려면 분할 구성을 참조하세요.

클러스터에서 키를 분산하는 방법

키 배포 모델에 대한 Redis 설명서에 따르면 키 공간은 16384개 슬롯으로 분할됩니다. 각 키는 이러한 슬롯 중 하나에 해시되고 할당되며 클러스터의 노드에 분산됩니다. 키의 어느 부분이 해시되는지 구성하여 여러 키가 해시 태그를 사용하여 동일한 분할에 위치하도록 합니다.

  • 해시 태그가 있는 키 - 키의 모든 부분이 { 및 }로 묶인 경우 키의 해당 부분에만 키의 해시 슬롯을 결정하는 용도로 해시됩니다. 예를 들어 {key}1, {key}2, {key}3 키는 동일한 분할된 데이터베이스에 위치합니다. 이름의 key 부분만 해시되기 때문입니다. 키 해시 태그 사양의 전체 목록은 키 해시 태그를 참조하세요.
  • 해시 태그가 없는 키 - 전체 키 이름이 해시에 사용되므로 캐시의 분할된 데이터베이스 전체에 통계적으로 균등하게 분포됩니다.

최상의 성능 및 처리량의 경우 키를 고르게 분산하는 것이 좋습니다. 해시 태그로 키를 사용하는 경우 키가 균등하게 분산되도록 하는 것은 애플리케이션이 담당합니다.

자세한 내용은 키 배포 모델, Redis 클러스터 데이터 분할 및 키 해시 태그를 참조하세요.

만들 수 있는 최대 캐시 크기는?

사용할 수 있는 가장 큰 캐시 크기는 플래시 최적화 A4500 인스턴스라고 하는 4.5TB입니다. Azure Cache for Redis 가격 책정

OSS와 엔터프라이즈 클러스터 정책의 차이점은 무엇인가요?

OSS 클러스터 정책은 커뮤니티 버전 Redis에서 사용되는 클러스터링 방식과 동일합니다. 일반적으로 OSS 클러스터 정책은 성능이 더 높습니다. 엔터프라이즈 클러스터 정책은 비클러스터형 Redis 인스턴스로 클라이언트에 표시되도록 클러스터링을 구현합니다. 이 방법은 성능이 낮을 수 있지만 클라이언트 호환성 문제를 방지할 수 있습니다. 현재 실행 중인 인스턴스에서 클러스터 정책 간에 전환할 수 없습니다. 자세한 내용은 클러스터 정책을 참조하세요.

다음 단계