다음을 통해 공유


확장

부하 시 크기 조정

로드 상태에서 캐시의 크기를 조정하는 동안 시스템 응답성을 개선하도록 maxmemory-reserved 설정을 구성합니다. 자세한 내용은 maxmemory-reserved 설정 구성을 참조하세요.

클러스터 크기 조정

클러스터형 캐시를 스케일 인/아웃하기 전에 캐시에서 데이터를 최대한 줄여 보세요. 데이터를 줄이면 이동해야 하는 데이터의 양이 감소하여 스케일 작업에 필요한 시간이 단축됩니다. 크기 조정 시점에 대한 자세한 내용은 크기 조정 시점을 참조하세요.

부하가 너무 높기 전에 크기 조정

서버 부하나 메모리 사용량이 너무 높아지기 전에 크기 조정을 시작합니다. 너무 높으면 Redis 서버가 사용 중임을 의미합니다. 바쁜 Redis 서버에는 데이터의 크기를 조정하고 재배포할 리소스가 충분하지 않습니다.

캐시 크기

TLS를 사용 중이고 연결 수가 많은 경우 더 많은 코어에 부하를 분산할 수 있도록 스케일 아웃을 고려합니다. 일부 캐시 크기는 코어가 네 개 이상인 VM에서 호스트됩니다. 여러 코어에 워크로드를 분산하면 캐시 VM의 전체 CPU 사용량을 줄일 수 있습니다. 자세한 내용은 VM 크기 및 코어에 대한 세부 정보를 참조하세요.

크기 조정 및 메모리

Azure Portal에서 캐시 인스턴스의 크기를 조정할 수 있습니다. 또한 PowerShell cmdlet, Azure CLI 및 MAML(Microsoft Azure 관리 라이브러리)을 사용하여 프로그래밍 방식으로 캐시를 스케일링할 수 있습니다.

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

PowerShell, CLI 또는 Rest API를 사용하여 프로그래밍 방식으로 캐시를 확장하거나 축소하는 경우 maxmemory-reserved 또는 maxfragmentationmemory-reserved는 업데이트 요청의 일부로 무시됩니다. 크기 조정 변경만 적용됩니다. 크기 조정 작업이 완료된 후 이러한 메모리 설정을 업데이트할 수 있습니다.

계층에 따라 스케일링 및 메모리에 대한 자세한 내용은 다음 중 하나를 참조하세요.

참고 항목

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

데이터를 최소화하면 크기 조정을 더 빨리 완료할 수 있습니다.

캐시에 데이터를 보존하는 것이 요구 사항이 아닌 경우 크기 조정 전에 데이터를 플러시하는 것이 좋습니다. 캐시를 플러시하면 크기 조정 작업이 더 빨리 완료되어 새 용량을 더 빨리 사용할 수 있습니다. 플러시 작업을 시작하는 방법에 대해 자세히 알아봅니다.

다음 단계