다음을 통해 공유

Azure Cache for Redis 인스턴스 스케일링

  • 아티클

Azure Cache for Redis에는 캐시 크기와 기능을 유연하게 선택할 수 있는 다양한 계층 제안이 있습니다. 스케일링을 통해 애플리케이션 요구 사항에 맞게 캐시 인스턴스 만든 후 노드의 크기, 계층 및 수를 변경할 수 있습니다. 이 문서에서는 Azure Portal과 Azure PowerShell 및 Azure CLI와 같은 도구를 사용하여 캐시 크기를 조정하는 방법을 보여 줍니다.

크기 조정 유형

기본적으로 다음 두 가지 방법으로 Azure Cache for Redis 인스턴스를 스케일링할 수 있습니다.

  • 스케일 업하면 Redis 서버를 실행하는 VM(Virtual Machine)의 크기가 증가하여 메모리, vCPU(가상 CPU) 및 네트워크 대역폭이 추가됩니다. 스케일 업은 수직 스케일링이라고도 합니다. 스케일 업의 반대는 스케일 다운입니다.

  • 스케일 아웃하면 캐시 인스턴스가 동일한 크기의 더 많은 노드로 나뉘며 병렬화를 통해 메모리, vCPU 및 네트워크 대역폭이 증가합니다. 스케일 아웃을 수평 스케일링 또는 분할이라고도 합니다. 스케일 아웃의 반대는 스케일 인입니다. Redis 커뮤니티에서는 스케일 아웃을 클러스터링이라고도 합니다.

가용성 범위

서비스 계층 기본 및 표준 Premium Enterprise 및 Enterprise Flash
강화 예 예 예(미리 보기)
스케일 다운 예 예 아니요
규모 확장 예 예 예(미리 보기)
스케일 인 예 네 아니요

크기를 조정하는 경우

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

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

  • Redis 서버 부하
    • Redis 서버 부하가 높으면 서버가 모든 클라이언트의 요청을 계속해서 수행할 수 없습니다. Redis 서버는 단일 스레드 프로세스이므로 일반적으로 ‘스케일 업’보다는 ‘스케일 아웃’하는 것이 더 유용합니다. 클러스터링을 사용하도록 설정하여 스케일 아웃하면 여러 Redis 프로세스에 오버헤드 함수를 분산하는 데 도움이 됩니다. 스케일 아웃하면 TLS 암호화/암호 해독 및 연결/연결 끊기를 분산하여 TLS로 캐시 인스턴스의 속도를 높일 수도 있습니다.
    • 스케일 업은 백그라운드 작업이 더 많은 vCPU를 활용하고 기본 Redis 서버 프로세스에 대한 스레드를 확보할 수 있기 때문에 서버 부하를 줄이는 데 도움이 될 수 있습니다.
    • Enterprise 및 Enterprise Flash 계층은 오픈 소스 redis 대신 Redis Enterprise를 사용합니다. 이러한 계층의 장점 중 하나는 Redis 서버 프로세스가 여러 vCPU를 활용할 수 있다는 것입니다. 여러 vCPU를 사용하는 경우 이러한 계층에서 크기 조정 및 축소하는 것은 서버 부하를 줄이는 데 도움이 될 수 있습니다. 자세한 내용은 Azure Cache for Redis의 Enterprise 및 Enterprise Flash 계층에 대한 모범 사례를 참조하세요.
  • 메모리 사용량
    • 높은 메모리 사용량은 데이터 크기가 현재 캐시 크기에 비해 너무 큰 것을 나타냅니다. 더 큰 메모리를 사용하는 캐시 크기로 크기를 조정하는 것을 고려합니다. 여기서는 ‘스케일 업’ 또는 ‘스케일 아웃’이 효과적입니다.
  • 클라이언트 연결
    • 각 캐시 크기에는 지원할 수 있는 클라이언트 연결 수에 대한 제한이 있습니다. 클라이언트 연결이 캐시 크기 제한에 근접한 경우 더 큰 계층으로 ‘스케일 업’하는 것이 좋습니다. ‘스케일 아웃’을 수행해도 지원되는 클라이언트 연결 수가 늘어나지는 않습니다.
    • 캐시 크기별 연결 제한에 대한 자세한 내용은 Azure Cache for Redis 가격 책정을 참조하세요.
  • 네트워크 대역폭
    • Redis 서버에서 사용 가능한 대역폭을 초과하는 경우 서버에서 클라이언트에 데이터를 충분히 빠르게 푸시할 수 없기 때문에 클라이언트 요청 시간이 초과될 수 있습니다. 사용 중인 서버 쪽 대역폭의 양을 확인하려면 "캐시 읽기" 및 "캐시 쓰기" 메트릭을 확인합니다. Redis 서버에서 사용 가능한 네트워크 대역폭을 초과하는 경우 더 높은 네트워크 대역폭을 사용하는 더 큰 캐시 크기로 스케일 아웃 또는 스케일 업하는 것을 고려해야 합니다.
    • Enterprise 클러스터 정책을 사용하는 Enterprise 계층 캐시의 경우 스케일 아웃해도 네트워크 대역폭이 증가하지 않습니다.
    • 캐시 크기별로 네트워크에서 사용 가능한 대역폭에 대한 자세한 내용은 Azure Cache for Redis 계획 FAQ를 참조하세요.
  • 내부 Defender 검사
    • C0 및 C1 표준 캐시에서 내부 Defender 검사가 VM에서 실행되는 동안 캐시 요청 증가로 인해 발생하지 않은 서버 부하가 일시적으로 급증할 수 있습니다. 이러한 계층에서 내부 Defender 검사가 하루에 두 번 정도 실행되므로 요청에 대한 대기 시간이 길어집니다. C0 및 C1 계층의 캐시는 멀티태스킹을 위한 코어가 하나뿐이므로 내부 Defender 검사 및 Redis 요청을 처리하는 작업을 분할합니다. C2와 같이 여러 CPU 코어가 있는 상위 계층 제공 사항으로 크기 조정하면 영향을 줄일 수 있습니다.
    • 상위 계층에서 캐시 크기를 늘리면 대기 시간 문제를 해결하는 데 도움이 됩니다. 또한 C2 수준에서는 최대 2,000개의 클라이언트 연결을 지원합니다.

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

참고 항목

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

Azure Cache for Redis 스케일링의 필수 구성 요소/제한 사항

다른 가격 책정 계층으로 스케일 업/다운할 수 있지만 다음과 같은 제한 사항이 있습니다.

  • 높은 가격 책정 계층에서 낮은 가격 책정 계층으로 크기를 조정할 수 없습니다.
    • Enterprise 또는 Enterprise Flash 캐시에서 다른 계층으로 스케일 다운할 수 없습니다.
    • 프리미엄 캐시에서 표준 또는 기본 캐시로 축소할 수 없습니다.
    • 표준 캐시에서 기본 캐시로 축소할 수 없습니다.
  • 기본 캐시에서 표준 캐시로 크기를 조정할 수 있지만 동시에 크기를 변경할 수는 없습니다. 다른 크기가 필요한 경우 나중에 원하는 크기로 크기 조정 작업을 수행할 수 있습니다.
  • 기본 캐시에서 바로 프리미엄 캐시로 확장할 수 없습니다. 먼저 크기 조정 작업을 통해 기본에서 표준으로 확장한 다음, 이후 크기 조정 작업을 통해 표준에서 프리미엄으로 확장합니다.
  • 더 큰 크기에서 C0(250MB) 크기로 크기 조정할 수 없습니다. 하지만 동일한 가격 책정 계층 내에서 다른 크기로 스케일 인할 수 있습니다. 예를 들어, C5 Standard에서 C1 Standard로 스케일 인할 수 있습니다.
  • Premium, Standard 또는 Basic 캐시에서 Enterprise 또는 Enterprise Flash 캐시로 스케일 업할 수 없습니다.
  • Enterprise와 Enterprise Flash 간에는 스케일링할 수 없습니다.

다음 제한 사항으로 스케일 아웃/스케일 인할 수 있습니다.

  • 스케일 아웃은 Premium, Enterprise 및 Enterprise Flash 계층에서만 지원됩니다.
  • 스케일 인은 Premium 계층에서만 지원됩니다.
  • Premium 계층에서 스케일 인 또는 스케일 아웃하기 전에 먼저 클러스터링을 사용하도록 설정해야 합니다.
  • 프리미엄 계층에서는 최대 10개의 분할 스케일 아웃이 일반적으로 지원됩니다. 최대 30개의 분할에 대한 지원은 미리 보기로 제공됩니다. (복제본이 2개 있는 캐시의 경우 분할 제한은 20입니다. 복제본이 3개인 경우 분할 제한은 15입니다.)
  • Enterprise 및 Enterprise Flash 계층만 동시에 스케일 업 및 스케일 아웃할 수 있습니다.

스케일링 방법 - Basic, Standard 및 Premium 계층

Azure Portal을 사용하여 스케일 업 및 다운

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

    리소스 메뉴의 스케일링을 보여 주는 스크린샷.

  2. 작업 창에서 가격 책정 계층을 선택한 다음, 선택을 선택합니다.

    Azure Cache for Redis 계층을 보여 주는 스크린샷.

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

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

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

참고 항목

Portal에서 캐시를 스케일 업 또는 다운할 때 maxmemory-reserved 및 maxfragmentationmemory-reserved 설정은 모두 캐시 크기에 비례하여 자동으로 스케일링합니다. 예를 들어 6GB 캐시에서 3GB로 maxmemory-reserved가 설정되고 12GB 캐시로 크기를 조정하는 경우 크기 조정 중에 설정이 자동으로 6GB로 업데이트됩니다. 축소하면 반대 현상이 일어납니다.

PowerShell을 사용하여 스케일 업 및 다운

Size 또는 Sku 속성을 수정할 때 Set-AzRedisCache cmdlet를 사용하여 PowerShell을 통해 Azure Cache for Redis 인스턴스의 스케일링할 수 있습니다. 다음 예제에서는 myCache라는 캐시를 동일한 계층의 6GB 캐시로 스케일링하는 방법을 보여 줍니다.

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -Size 6GB

PowerShell을 사용하여 스케일링하는 방법에 대한 자세한 내용은 PowerShell을 사용하여 Azure Cache for Redis 스케일링을 참조하세요.

Azure CLI를 사용하여 스케일 업 및 다운

Azure CLI를 사용하여 Azure Cache for Redis 인스턴스를 스케일링하려면 az redis update 명령을 호출합니다. sku.capcity 속성을 사용하여 계층 내에서 스케일링합니다(예: Standard C0에서 Standard C1 캐시로).

az redis update --cluster-name myCache --resource-group myGroup --set "sku.capacity"="2"

'sku.name' 및 'sku.family' 속성을 사용하여 다른 계층으로 스케일 업합니다(예: Standard C1 캐시에서 Premium P1 캐시로).

az redis update --cluster-name myCache --resource-group myGroup --set "sku.name"="Premium" "sku.capacity"="1" "sku.family"="P"

Azure CLI를 사용하여 크기를 조정하는 방법에 대한 자세한 내용은 기존 Azure Cache for Redis에 대한 설정 변경을 참조하세요.

참고 항목

프로그래밍 방식으로 캐시를 스케일 업하거나 스케일 다운하는 경우(예: PowerShell 또는 Azure CLI 사용) maxmemory-reserved 또는 maxfragmentationmemory-reserved는 업데이트 요청의 일부로 무시됩니다. 크기 조정 변경만 적용됩니다. 크기 조정 작업이 완료된 후 이러한 메모리 설정을 업데이트할 수 있습니다.

스케일 업 및 스케일 아웃하는 방법 - Enterprise 및 Enterprise Flash 계층

Enterprise 및 Enterprise Flash 계층은 한 번의 작업으로 스케일 업 및 스케일 아웃할 수 있습니다. 다른 계층에는 각 작업에 대해 별도의 작업이 필요합니다.

주의

Enterprise 및 Enterprise Flash 계층은 아직 ‘스케일 다운’ 또는 ‘스케일 인’ 작업을 지원하지 않습니다.

Azure Portal을 사용하여 스케일링

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

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

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

    Important

    이때만 스케일 업할 수 있습니다. 스케일 다운할 수 없습니다.

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

  3. 스케일 아웃하려면 용량 슬라이더를 늘립니다. 용량이 2씩 증가합니다. 이 수치는 추가되는 기본 Redis Enterprise 노드 수를 반영합니다. 이 수치는 항상 주 분할과 복제본 분할 모두에 대해 추가되는 노드를 반영하는 2의 배수입니다.

    Important

    지금은 스케일 아웃하여 용량을 늘릴 수만 있습니다. 스케일 인할 수 없습니다.

    작업 창의 용량 주위에 빨간색 상자가 있는 것을 보여 주는 스크린샷.

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

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

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

PowerShell을 사용하여 크기 조정

PowerShell에서 Update-AzRedisEnterpriseCache cmdlet을 사용하여 Azure Cache for Redis 인스턴스를 스케일링할 수 있습니다. Sku 속성을 수정하여 인스턴스를 스케일 업할 수 있습니다. Capacity 속성을 수정하여 인스턴스를 스케일 아웃할 수 있습니다. 다음 예제에서는 myCache라는 캐시를 용량이 4인 Enterprise E20(25GB) 인스턴스로 스케일링하는 방법을 보여 줍니다.

   Update-AzRedisEnterpriseCache -ResourceGroupName myGroup -Name myCache -Sku Enterprise_E20 -Capacity 4

Azure CLI를 사용한 크기 조정

Azure CLI를 사용하여 Azure Cache for Redis 인스턴스를 스케일링하려면 az redisenterprise update 명령을 호출합니다. sku 속성을 수정하여 인스턴스를 스케일 업할 수 있습니다. capacity 속성을 수정하여 인스턴스를 스케일 아웃할 수 있습니다. 다음 예제에서는 myCache라는 캐시를 용량이 4인 Enterprise E20(25GB) 인스턴스로 스케일링하는 방법을 보여 줍니다.

az redisenterprise update --cluster-name "myCache" --resource-group "myGroup" --sku "Enterprise_E20" --capacity 4

크기 조정 FAQ

Azure Cache for Redis 크기 조정에 대해 자주 묻는 질문과 대답이 나와 있는 목록은 다음과 같습니다.

프리미엄 캐시로 확장하거나, 이 캐시를 축소하거나 이 캐시 내에서 크기를 조정할 수 있나요?

  • 프리미엄 캐시에서 기본 또는 표준 가격 책정 계층으로 축소할 수 없습니다.
  • 하나의 프리미엄 캐시 가격 책정 계층에서 다른 프리미엄 캐시 가격 책정 계층으로 크기를 조정할 수 있습니다.
  • 기본 캐시에서 바로 프리미엄 캐시로 확장할 수 없습니다. 먼저 크기 조정 작업을 통해 기본에서 표준으로 확장한 다음, 이후 크기 조정 작업을 통해 표준에서 프리미엄으로 확장합니다.
  • Premium 캐시에서 Enterprise 또는 Enterprise Flash 캐시로 스케일링할 수 없습니다.
  • 프리미엄 캐시를 만들 때 클러스터링을 사용하도록 설정했으면 클러스터 크기를 변경할 수 있습니다. 클러스터를 사용하지 않고 캐시를 만든 경우 나중에 클러스터링를 구성할 수 있습니다.

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

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

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

  • 기본 캐시를 다른 크기로 조정하면 캐시가 종료되고 새 크기를 사용하여 새 캐시가 프로비전됩니다. 이 시간 동안에는 캐시를 사용할 수 없으며 캐시의 모든 데이터가 손실됩니다.
  • 기본 캐시 크기를 표준 캐시로 조정하는 경우 복제본 캐시가 프로비전되며 데이터가 주 캐시에서 복제본 캐시로 복사됩니다. 크기를 조정하는 동안 캐시를 계속 사용할 수 있습니다.
  • Standard, Premium, Enterprise 또는 Enterprise Flash 캐시를 다른 크기로 스케일링하는 경우 복제본 중 하나가 종료되고 새 크기로 다시 프로비전되며 데이터가 전송됩니다. 그런 다음, 나머지 복제본이 장애 조치를 수행한 후 다시 프로비전됩니다. 이는 캐시 노드 중 하나에 장애가 발생하면 수행되는 프로세스와 비슷합니다.
  • 클러스터형 캐시를 스케일 아웃하는 경우 새 분할이 프로비저닝되고 Redis 서버 클러스터에 추가됩니다. 그러면 모든 분할에 걸쳐 데이터가 재분할됩니다.
  • 클러스터형 캐시에서 크기를 조정하는 경우 데이터를 먼저 재분할한 다음, 클러스터 크기를 필요한 분할로 줄입니다.
  • 캐시를 다른 클러스터로 크기 조정하거나 마이그레이션하는 것과 같은 일부 경우에는 캐시의 기본 IP 주소가 변경될 수 있습니다. 캐시에 대한 DNS 레코드는 변경되며 대부분의 애플리케이션에 투명합니다. 그러나 IP 주소를 사용하여 캐시에 대한 연결을 구성하거나 NSG 또는 캐시에 대한 트래픽을 허용하는 방화벽을 구성하는 경우 DNS 레코드가 업데이트된 후 애플리케이션 연결에 문제가 발생할 수 있습니다.

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

  • 기본 캐시 크기를 새 크기로 조정하는 경우 모든 데이터가 손실되고 크기 조정 작업을 수행하는 동안 캐시를 사용할 수 없습니다.
  • 기본 캐시 크기를 표준 캐시로 조정하는 경우 일반적으로 캐시의 데이터가 유지됩니다.
  • Standard, Premium, Enterprise 또는 Enterprise Flash 캐시를 더 큰 크기로 스케일링하면 일반적으로 모든 데이터가 보존됩니다. 표준 또는 프리미엄 캐시 크기를 더 작은 크기로 조정하는 경우 캐시가 스케일 다운될 때 더 작은 새 크기를 초과하면 데이터가 손실될 수 있습니다. 크기를 축소하는 경우 데이터가 손실되면 allkeys-lru 제거 정책을 사용하여 키를 제거합니다.

크기 조정 후 프리미엄 계층의 모든 기능을 사용할 수 있나요?

아니요, 일부 기능은 프리미엄 계층에서 캐시를 만들 때만 설정할 수 있으며 스케일링 후에는 사용할 수 없습니다.

프리미엄 캐시를 만든 후에는 다음 기능을 추가할 수 없습니다.

  • 가상 네트워크 삽입
  • 영역 중복 추가
  • 기본당 여러 복제본 사용

이러한 기능을 사용하려면 프리미엄 계층에서 새 캐시 인스턴스를 만들어야 합니다.

사용자 지정 데이터베이스 설정이 크기 조정 하는 동안에 영향을 받나요?

캐시 생성 중에 databases 설정에 대한 사용자 지정 값을 구성한 경우 일부 가격 책정 계층에 서로 다른 데이터베이스 제한이 있습니다. 이 시나리오를 확장할 때 몇 가지 고려 사항이 있습니다.

  • 현재 계층보다 databases 한도가 낮은 가격 책정 계층으로 확장하는 경우:
    • 모든 가격 책정 계층에 대해 기본값이 16개인 databases를 사용하는 경우에는 데이터 손실이 전혀 없습니다.
    • 크기 조정하는 계층에 대한 제한 내에 포함되는 databases의 사용자 지정 수를 사용하는 경우, 이 databases 설정은 유지되고 데이터 손실은 전혀 없습니다.
    • 새 계층의 제한을 초과하는 databases의 사용자 지정 수를 사용하는 경우, databases 설정은 새 계층의 제한까지 낮춰지고 제거된 데이터베이스의 모든 데이터는 손실됩니다.
  • 현재 계층과 같거나 더 높은 databases 한도를 가진 가격 책정 계층으로 확장하면 databases 설정이 유지되고 데이터가 손실되지 않습니다.

Standard, Premium, Enterprise 및 Enterprise Flash 캐시에 가용성에 대한 SLA가 있는 경우 데이터 손실에 대한 SLA는 없습니다.

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

  • Standard, Premium, Enterprise 및 Enterprise Flash 캐시는 스케일링 작업 중에 계속 사용할 수 있습니다. 그러나 이러한 캐시를 스케일링하는 동안과 Basic에서 Standard 캐시로 스케일링하는 동안 연결 블립이 발생할 수 있습니다. 이러한 연결 블립은 작을 것으로 예상되며 redis 클라이언트가 일반적으로 해당 연결을 즉시 다시 설정할 수 있습니다.
  • 활성 지역 복제를 사용하는 Enterprise 및 Enterprise Flash 캐시의 경우 연결된 캐시의 하위 집합만 스케일링하면 시간이 지남에 따라 문제가 발생할 수 있습니다. 가능하면 지역 복제 그룹의 모든 캐시를 함께 스케일링하는 것이 좋습니다.
  • 작업을 다른 크기로 확장하는 동안 기본 캐시는 오프라인 상태입니다. 기본에서 표준으로 크기를 조정하는 동안 기본 캐시를 그대로 사용할 수 있지만 작은 연결 블립이 발생할 수도 있습니다. 연결 블립이 발생하는 경우 Redis 클라이언트가 일반적으로 해당 연결을 즉시 다시 설정할 수 있습니다.

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

수동 지역 복제를 구성하면 캐시 크기를 스케일링하거나 클러스터의 분할을 변경할 수 없다는 것을 알 수 있습니다. 두 캐시 간의 지역 복제 링크를 사용하면 작업 크기를 조정하거나 클러스터의 분할 수를 변경할 수 없게 됩니다. 캐시의 연결을 해제하여 이러한 명령을 실행해야 합니다. 자세한 내용은 지역 복제 구성을 참조하세요.

활성 지역 복제가 구성된 경우 캐시를 스케일링할 수 없습니다. 지역 복제 그룹의 모든 캐시는 크기와 용량이 동일해야 합니다.

지원되지 않는 작업

  • 높은 가격 책정 계층에서 낮은 가격 책정 계층으로 크기를 조정할 수 없습니다.
    • 프리미엄 캐시에서 표준 또는 기본 캐시로 축소할 수 없습니다.
    • 표준 캐시에서 기본 캐시로 축소할 수 없습니다.
  • 기본 캐시에서 표준 캐시로 크기를 조정할 수 있지만 동시에 크기를 변경할 수는 없습니다. 다른 크기가 필요한 경우 나중에 원하는 크기로 조정 작업을 수행할 수 있습니다.
  • 기본 캐시에서 바로 프리미엄 캐시로 확장할 수 없습니다. 먼저 크기 조정 작업을 통해 기본에서 표준으로 크기를 조정한 다음, 이후 작업을 통해 표준에서 프리미엄으로 크기를 조정합니다.
  • Premium 캐시에서 Enterprise 또는 Enterprise Flash 캐시로 스케일링할 수 없습니다.
  • 더 큰 크기에서 C0(250MB) 크기로 축소할 수 없습니다.

크기 조정 작업이 실패하면 서비스는 작업을 되돌리려고 시도하고, 캐시는 원래 크기로 돌아갑니다.

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

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

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

일반적으로 데이터가 없는 캐시 크기를 조정하는 경우 약 20분이 소요됩니다. 클러스터형 캐시의 경우 크기 조정은 최소 데이터로 분할당 약 20분이 소요됩니다.

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

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

클라이언트 애플리케이션에 변경 사항이 필요하여 클러스터링을 사용해야 합니까?

Important

Enterprise 또는 Enterprise Flash 계층을 사용하는 경우 OSS 클러스터 모드 또는 Enterprise 클러스터 모드를 선택할 수 있습니다. OSS 클러스터 모드는 Premium 계층의 클러스터링과 동일하며 오픈 소스 클러스터링 사양을 따릅니다. Enterprise 클러스터 모드는 성능이 낮을 수 있지만 클라이언트를 변경할 필요가 없는 Redis Enterprise 클러스터링을 사용합니다. 자세한 내용은 Enterprise의 클러스터링을 참조하세요.

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

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

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

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

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

StackExchange.Redis 클라이언트를 통해 동일한 분할된 데이터베이스에서 키를 클러스터링하고 찾아서 작업하는 샘플 코드의 경우 Hello World 샘플의 clustering.cs 부분을 참조하세요.

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

사용할 수 있는 가장 큰 캐시 크기는 4.5TB입니다. 이 결과는 용량이 9인 클러스터형 F1500 캐시입니다. 자세한 내용은 Azure Cache for Redis 가격을 참조하세요.

모든 Redis 클라이언트가 클러스터링을 지원하나요?

많은 클라이언트 라이브러리에서 Redis 클러스터링을 지원하지만, 모두 지원하는 것은 아닙니다. 사용 중인 라이브러리의 설명서를 확인하여 클러스터링을 지원하는 라이브러리와 버전을 사용하고 있는지 확인하세요. StackExchange.Redis는 최신 버전에서 클러스터링을 지원하는 라이브러리 중 하나입니다. 다른 클라이언트에 대한 자세한 내용은 Redis 클러스터 자습서의 클러스터 작업 섹션을 참조하세요.

Redis 클러스터링 프로토콜은 각 클라이언트가 클러스터링 모드에서 각 분할에 직접 연결하도록 요구하고 MOVED na CROSSSLOTS와 같은 새로운 오류 응답도 정의합니다. 클러스터 모드 캐시를 사용한 클러스터링을 지원하지 않는 클라이언트 라이브러리를 사용하려고 하면 MOVED 리디렉션 예외가 많이 발생하거나, 교차 슬롯 다중 키 요청을 수행하는 경우 애플리케이션을 중단해야 할 수 있습니다.

참고 항목

StackExchange.Redis를 클라이언트로 사용하는 경우 클러스터링이 제대로 작동할 수 있게 StackExchange.Redis 1.0.481 이상의 최신 버전을 사용합니다. move 예외에 문제가 있을 경우 자세한 내용은 move 예외를 참조하세요.

클러스터링을 사용할 때 캐시에 어떻게 연결하나요?

클러스터링을 사용하지 않는 캐시에 연결할 때와 동일한 엔드포인트, 포트 및 키를 사용하여 캐시에 연결할 수 있습니다. Redis가 백엔드에서 클러스터링을 관리하므로 클라이언트에서의 관리가 필요하지 않습니다.

내 케시의 분할된 데이터베이스에 직접 연결할 수 있나요?

클러스터링 프로토콜을 사용하려면 클라이언트가 올바른 분할된 데이터베이스를 만들어야 하므로 클라이언트가 공유 연결을 설정해야 합니다. 즉 각각의 분할된 데이터베이스는 캐시 인스턴스로 통칭되는 주/복제본 캐시로 구성됩니다. GitHub에서 Redis 리포지토리의 불안정한 분기에서 Redis-CLI 유틸리티를 사용하여 이러한 캐시 인스턴스에 연결할 수 있습니다. 이 버전에는 -c 스위치로 시작한 경우 기본 지원을 구현합니다. 자세한 내용은 Redis 클러스터 자습서에서 https://redis.io에 대한 클러스터 작업을 참조하세요.

-p 스위치를 사용하여 연결할 올바른 포트를 지정해야 합니다. CLUSTER NODES 명령을 사용하여 주 노드 및 복제본 노드에 사용되는 정확한 포트를 확인합니다. 사용되는 포트 범위는 다음과 같습니다.

  • TLS Premium 계층이 아닌 캐시의 경우 130XX 범위의 포트를 사용할 수 있습니다.
  • TLS 지원 Premium 계층 캐시의 경우 150XX 범위의 포트를 사용할 수 있습니다.
  • OSS 클러스터링을 사용하는 Enterprise 및 Enterprise Flash 캐시의 경우 초기 연결은 포트 10000을 통해 설정됩니다. 85XX 범위의 포트를 사용하여 개별 노드에 연결할 수 있습니다. 85xx 포트는 시간이 지남에 따라 변경되며 애플리케이션에 하드 코딩하면 안 됩니다.

이전에 만든된 캐시에 대해 클러스터링을 구성할 수 있나요?

예. 먼저 캐시를 스케일 업하여 캐시가 프리미엄 계층에 있도록 합니다. 다음으로, 클러스터를 사용하도록 설정하는 옵션을 포함하여 클러스터 구성 옵션을 확인할 수 있습니다. 캐시가 만들어진 후 또는 처음으로 클러스터링을 사용하도록 설정한 후 클러스터 크기를 변경합니다.

Important

클러스터링을 사용하도록 설정하면 실행 취소할 수 없습니다. 클러스터링이 사용하도록 설정되고 분할된 데이터베이스가 하나뿐인 프리미엄 캐시는 클러스터링이 '없는' 동일한 크기의 프리미엄 캐시와는 '다르게' 동작합니다.

모든 Enterprise 및 Enterprise Flash 계층 캐시는 항상 클러스터링됩니다.

기본 또는 표준 캐시에 클러스터링을 구성할 수 있나요?

클러스터링은 Premium, Enterprise 및 Enterprise Flash 캐시에만 사용할 수 있습니다.

Redis ASP.NET 세션 상태 및 출력 캐싱 공급자와 함께 클러스터링을 사용할 수 있나요?

  • Redis 출력 캐시 공급자 - 변경이 필요하지 않습니다.
  • Redis 세션 상태 제공자 -클러스터링을 사용하기 위해 RedisSessionStateProvider 2.0.1 이상을 사용하지 않으면 예외가 발생합니다. 이는 호환성이 손상되는 변경입니다. 자세한 내용은 v2.0.0 Breaking Change Details(v2.0.0 호환성이 손상되는 변경 세부 사항)를 참조하세요.

StackExchange.Redis를 사용하고 클러스터링을 수행할 때 MOVE 예외가 발생합니다. 어떻게 해야 하나요?

StackExchange.Redis를 사용하고 있으며 클러스터링을 사용할 때 MOVE 예외가 발생하는 경우 StackExchange.Redis 1.1.603 이상을 사용하고 있는지 확인합니다. StackExchange.Redis를 사용하도록 .NET 애플리케이션을 구성하는 방법에 대한 자세한 내용은 캐시 클라이언트 구성을 참조하세요.

OSS 클러스터링과 Enterprise 계층 캐시의 엔터프라이즈 클러스터링의 차이점은 무엇인가요?

OSS 클러스터 모드는 Premium 계층의 클러스터링과 동일하며 오픈 소스 클러스터링 사양을 따릅니다. Enterprise 클러스터 모드는 성능이 낮을 수 있지만 클라이언트를 변경할 필요가 없는 Redis Enterprise 클러스터링을 사용합니다. 자세한 내용은 Enterprise의 클러스터링을 참조하세요.

Enterprise 계층 캐시에서 사용하는 분할은 몇 개인가요?

기본, 표준 및 프리미엄 계층 캐시와 달리 엔터프라이즈 및 Enterprise Flash 캐시는 단일 노드에서 여러 분할을 활용할 수 있습니다. 자세한 내용은 분할 및 CPU 사용률을 참조하세요.

다음 단계