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

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

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

   

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

   

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

   

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

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

또는 Size 속성을 수정할 때 Sku 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.capacity 속성을 사용하여 계층 내에서 스케일링합니다(예: 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에 대한 설정 변경을 참조하세요.

클러스터링을 사용하여 스케일 아웃되는 새 캐시 만들기

새 Azure Cache for Redis를 만들 때 작업 창에서 캐시를 만드는 동안 클러스터링을 사용할 수 있습니다.

1. 오픈 소스 Redis 캐시 만들기 빠른 시작 가이드를 사용하여 Azure Portal에서 새 캐시 만들기를 시작합니다.

2. premium 캐시 인스턴스의 고급 탭에서 TLS가 아닌 포트, 클러스터링 및 데이터 지속성에 대한 설정을 구성합니다. 클러스터링을 사용하도록 설정하려면 사용을 선택합니다.

   

   클러스터에는 최대 30개의 분할을 포함할 수 있습니다. 사용을 선택한 후 분할 개수에서 슬라이더를 밀거나 1에서 30 사이의 숫자를 입력하고 확인을 선택합니다.

   각 분할은 Azure에서 관리하는 기본/복제본 캐시 쌍입니다. 캐시의 총 크기는 분할 수에 가격 책정 계층에서 선택한 캐시 크기를 곱하여 산출합니다.

   

   캐시가 생성되면 연결한 다음, 클러스터링되지 않은 캐시처럼 사용합니다. Redis는 분할된 캐시 데이터베이스 전체에 데이터를 배포합니다. 진단을 사용하도록 설정하면 각 샤드에 대해 메트릭이 별도로 캡처되고 리소스 메뉴를 사용하여 Azure Cache for Redis에서 확인할 수 있습니다.

3. 빠른 시작 가이드를 사용하여 캐시 만들기를 완료합니다.

캐시를 만드는 데 잠시 시간이 걸립니다. Azure Cache for Redis 개요 페이지에서 진행률을 모니터링할 수 있습니다. 상태가 실행 중으로 표시되면 캐시를 사용할 준비가 된 것입니다.

StackExchange.Redis 클라이언트를 통해 클러스터링으로 작업하는 샘플 코드의 경우 Hello World 샘플의 clustering.cs 부분을 참조하세요.

실행 중인 Premium 캐시 스케일 인 또는 스케일 아웃

이전에 만들고 클러스터링을 사용하도록 설정한 상태에서 이미 실행 중인 프리미엄 캐시의 클러스터 크기를 변경하려면 리소스 메뉴에서 클러스터 크기를 선택합니다.

클러스터 크기를 변경하려면 슬라이더를 사용하거나 분할된 데이터베이스 수 텍스트 상자에 1에서 30 사이의 수를 입력합니다. 그런 다음 확인을 선택하여 저장합니다.

클러스터 크기를 늘리면 최대 처리량 및 캐시 크기가 증가합니다. 클러스터 크기를 늘리더라도 클라이언트가 사용할 수 있는 최대 연결 수는 증가하지는 않습니다.

PowerShell을 사용하여 스케일 아웃 및 스케일 인

속성을 수정할 때 ShardCount cmdlet를 사용하여 PowerShell을 통해 Azure Cache for Redis 인스턴스를 스케일 아웃할 수 있습니다. 다음 예제에서는 세 개의 분할을 사용하도록 myCache 캐시를 스케일 아웃하는 방법을 보여 줍니다(즉, 3의 배수로 스케일 아웃).

   Set-AzRedisCache -ResourceGroupName myGroup -Name myCache -ShardCount 3

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

Azure CLI를 사용하여 스케일 아웃 및 스케일 인

Azure CLI를 사용하여 Azure Cache for Redis 인스턴스를 스케일링하려면 az redis update 명령을 호출하고 shard-count 속성을 사용합니다. 다음 예제에서는 세 개의 분할을 사용하도록 myCache 캐시를 스케일 아웃하는 방법을 보여 줍니다(즉, 3의 배수로 스케일 아웃).

az redis update --cluster-name myCache --resource-group myGroup --set shard-count=3

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

클러스터를 확장하면 비용이 많이 드는 MIGRATE 명령이 실행됩니다. 영향을 최소화하려면 사용량이 적은 시간 동안 이 작업을 실행하는 것이 좋습니다. 마이그레이션 프로세스 중에 서버 부하에 스파이크가 나타납니다. 클러스터 확장은 장기 실행 프로세스이며, 소요 시간은 키 수 및 해당 키와 관련된 값의 크기에 따라 달라집니다.

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

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

Azure Portal을 사용하여 스케일링

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

   

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

   중요합니다

   이때만 스케일 업할 수 있습니다. 규모를 축소할 수 없습니다.

   

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

   중요합니다

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

   

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

   

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 크기 조정에 대해 자주 묻는 질문과 대답이 나와 있는 목록은 다음과 같습니다.

• 프리미엄 캐시로 확장하거나, 이 캐시를 축소하거나 이 캐시 내에서 크기를 조정할 수 있나요?
• 크기를 조정한 후 내 캐시 이름 또는 액세스 키를 변경해야 하나요?
• 크기 조정은 어떻게 수행되나요?
• 스케일링하는 동안 캐시의 데이터가 손실되나요?
• 크기 조정 후 프리미엄 계층의 모든 기능을 사용할 수 있나요?
• 사용자 지정 데이터베이스 설정이 크기 조정 하는 동안에 영향을 받나요?
• 크기를 조정하는 동안 내 캐시를 사용할 수 있나요?
• 지역 복제에 크기 조정 제한 사항이 있나요?
• 지원되지 않는 작업
• 크기 조정은 시간이 얼마나 걸리나요?
• 크기 조정이 완료되었는지 어떻게 알 수 있나요?
• 클라이언트 애플리케이션에 변경 사항이 필요하여 클러스터링을 사용해야 합니까?
• 클러스터에서 키를 분산하는 방법
• 만들 수 있는 최대 캐시 크기는?
• 모든 Redis 클라이언트가 클러스터링을 지원하나요?
• 클러스터링을 사용할 때 캐시에 어떻게 연결하나요?
• 내 케시의 분할된 데이터베이스에 직접 연결할 수 있나요?
• 이전에 만든된 캐시에 대해 클러스터링을 구성할 수 있나요?
• 기본 또는 표준 캐시에 클러스터링을 구성할 수 있나요?
• Redis ASP.NET 세션 상태 및 출력 캐싱 공급자와 함께 클러스터링을 사용할 수 있나요?
• StackExchange.Redis를 사용하고 클러스터링을 수행할 때 MOVE 예외가 발생합니다. 어떻게 해야 하나요?
• OSS 클러스터링과 Enterprise 계층 캐시의 엔터프라이즈 클러스터링의 차이점은 무엇인가요?
• Enterprise 계층 캐시에서 사용하는 분할은 몇 개인가요?

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

• 프리미엄 캐시에서 기본 또는 표준 가격 책정 계층으로 축소할 수 없습니다.
• 하나의 프리미엄 캐시 가격 책정 계층에서 다른 프리미엄 캐시 가격 책정 계층으로 크기를 조정할 수 있습니다.
• 기본 캐시에서 바로 프리미엄 캐시로 확장할 수 없습니다. 먼저 크기 조정 작업을 통해 기본에서 표준으로 확장한 다음, 이후 크기 조정 작업을 통해 표준에서 프리미엄으로 확장합니다.
• 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 클라이언트가 일반적으로 해당 연결을 즉시 다시 설정할 수 있습니다.

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

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

활성 지역 복제를 구성하면 몇 가지 제한 사항으로 캐시 크기를 조정할 수 있습니다. 지역 복제 그룹의 모든 캐시는 크기와 용량이 같아야 합니다. 자세한 내용은 엔터프라이즈 Azure Cache for Redis 인스턴스에 대한 활성 지역 복제 구성을 참조하세요.

지원되지 않는 작업

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

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

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

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

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

캐시 크기 조정은 간단한 작업이 아니며 시간이 오래 걸릴 수 있습니다. 부하가 많이 들지 않는 경우 1~2개의 분할된 데이터베이스를 사용하여 캐시 크기를 조정하는 데 1~2시간이 걸릴 수 있습니다. 분할된 데이터베이스가 더 많은 경우 크기 조정 시간이 선형 방식으로 증가하지 않습니다.

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

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

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

• 클러스터링 사용하는 경우 데이터베이스 0만을 사용할 수 있습니다. 클라이언트 애플리케이션에서 여러 데이터베이스를 사용하고 0이 아닌 데이터베이스를 읽거나 쓰려고 하면 다음 예외가 발생합니다. Unhandled Exception: StackExchange.Redis.RedisConnectionException: ProtocolFailure on GET --->StackExchange.Redis.RedisCommandException: Multiple databases are not supported on this server; cannot switch to database: 6

  자세한 내용은 Redis 클러스터 사양 - 구현된 하위 집합을 참조하세요.

• StackExchange.Redis를 사용하는 경우 1.0.481 이상을 사용해야 합니다. 클러스터링을 사용하지 않는 캐시에 연결할 때와 동일한 엔드포인트, 포트 및 키를 사용하여 캐시에 연결합니다. 유일한 차이점은 데이터베이스 0에 모든 읽기 및 쓰기를 수행해야 한다는 점입니다.

  다른 고객은 다른 요구 사항을 가질 수도 있습니다. 자세한 내용은 모든 Redis 클라이언트에서 클러스터링을 지원합니까?

• 애플리케이션이 단일 명령으로 배치되는 다중 키 작업을 사용하면 동일한 분할에 모든 키가 위치해야 합니다. 동일한 분할된 데이터베이스에서 키를 찾으려면 클러스터에서 키를 배포하는 방법을 참조하세요.

• Redis ASP.NET 세션 상태 제공자를 사용하는 경우 2.0.1 이상을 사용해야 합니다. 자세한 내용은 Redis ASP.NET 세션 상태 및 출력 캐싱 공급자와 함께 클러스터링을 사용할 수 있나요?

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

키 배포 모델에 대한 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 리디렉션 예외 가 발생하거나 슬롯 간 다중 키 요청을 만드는 경우 애플리케이션이 중단될 수 있습니다.

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

클러스터링을 사용하지 않는 캐시에 연결할 때와 동일한 엔드포인트, 포트 및 키를 사용하여 캐시에 연결할 수 있습니다. 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 포트는 시간이 지남에 따라 변경되며 애플리케이션에 하드 코딩하면 안 됩니다.

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

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

모든 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 이상을 사용하고 있는지 확인합니다.

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

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

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

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

다음 단계

• 사용자의 maxmemory-reserved 설정 구성
• 스케일링에 대한 모범 사례