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

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

크기 조정 유형

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 한눈에 보기

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

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

크기를 조정하는 경우

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

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

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

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

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

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

확장 방법

Azure Portal을 사용하여 스케일링

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

   

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

   Important

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

   

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

   

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는 클러스터링을 사용하나요?각 Azure Managed Redis SKU에서 사용하는 분할 데이터베이스는 몇 개인가요?
• 클러스터에서 키를 분산하는 방법
• 만들 수 있는 최대 캐시 크기는?
• OSS와 엔터프라이즈 클러스터 정책의 차이점은 무엇이 있나요?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

일반적으로 데이터가 없는 인스턴스 크기를 조정하는 경우, 약 20분이 소요됩니다.

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

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 인스턴스로 클라이언트에 표시될 수 있도록 클러스터링을 구현합니다. 이는 성능이 낮을 수 있지만, 클라이언트 호환성 문제를 방지할 수 있습니다. 현재 실행 중인 인스턴스에서는 클러스터 정책 간에 전환할 수 없습니다. 자세한 내용은, 클러스터 정책을 참조하세요.

다음 단계

• 스케일링에 대한 모범 사례