Azure Cache for Redis의 서버 로드 관리
값 크기
클라이언트 애플리케이션의 디자인에 따라 많은 작은 값을 저장해야 하는지 또는 더 적은 수의 큰 값을 저장해야 하는지 여부가 결정됩니다. Redis 서버 관점에서는 값이 작을수록 성능이 향상됩니다. 값 크기를 100kB 보다 작게 유지하는 것이 좋습니다.
디자인 상 Azure Cache for Redis에 더 큰 값을 저장해야 하는 경우 서버 로드가 높아집니다. 이 경우 CPU 사용량이 처리량을 제한하지 않도록 높은 캐시 계층을 사용해야 할 수 있습니다.
캐시에 CPU 용량이 충분한 경우에도 값이 클수록 대기 시간이 증가하므로 적절한 시간 제한 구성의 참고 자료를 따르세요.
값이 클수록 메모리 조각화의 가능성이 증가하므로 maxmemory-reserved 설정 구성의 참고 자료를 따라야 합니다.
클라이언트 연결 급증 방지
Redis 서버에 대한 연결을 만들고 닫는 작업은 많은 비용을 필요로 합니다. 클라이언트 애플리케이션이 짧은 시간에 너무 많은 연결을 만들거나 닫으면 Redis 서버에 부담을 줄 수 있습니다.
여러 클라이언트 인스턴스를 인스턴스화하여 한 번에 Redis에 연결하는 경우에는 연결된 클라이언트 수가 급증하지 않도록 새 연결 만들기에 시차를 두는 것을 고려하십시오.
메모리 부족
서버에서 메모리 사용량이 높으면 시스템에서 데이터를 디스크로 페이징해야 하므로 페이지 폴트가 발생하여 시스템의 속도가 상당히 느려질 수 있습니다.
장기 실행 명령 방지
Redis 서버는 단일 스레드 시스템입니다. 장기 실행 명령을 실행하는 동안에는 서버에서 다른 요청에 응답할 수 없으므로 클라이언트 측에서 대기 시간이나 시간 초과가 발생할 수 있습니다. 더 자세한 정보는 Azure Cache for Redis 서버측 문제 해결을 참조하세요.
모니터 서버 로드
서버 부하 모니터링을 추가하여 높은 서버 부하가 발생하는 경우 알림을 받을 수 있도록 합니다. 모니터링을 통해 애플리케이션의 제약 조건을 이해할 수 있습니다. 그 후 문제를 완화하기 위해 사전에 자동 관리할 수 있습니다. 성능 저하를 방지하려면 서버 로드를 80% 미만으로 유지하는 것이 좋습니다. 80% 이상의 지속적인 서버 로드로 인해 계획되지 않은 장애 조치(failover)가 발생할 수 있습니다. 현재 Azure Cache For Redis는 포털 왼쪽의 리소스 메뉴에 있는 모니터링 아래의Insights에서 CPU 및 서버 부하라는 두 가지 메트릭을 노출합니다. 서버 부하를 모니터링할 때 각 메트릭으로 측정되는 내용을 이해하는 것이 중요합니다.
CPU 메트릭은 캐시를 호스트하는 노드의 CPU 사용량을 나타냅니다. CPU 메트릭에는 엄격하게 Redis 서버 프로세스가 아닌 프로세스도 포함됩니다. CPU에는 맬웨어 방지 및 기타에 대한 백그라운드 프로세스가 포함됩니다. 따라서 CPU 메트릭이 급증할 수 있으며 Redis 서버에 대한 CPU 사용량의 완벽한 지표가 아닐 수 있습니다.
서버 부하 메트릭은 Redis Server에서만 부하를 나타냅니다. CPU 대신 서버 부하 메트릭을 모니터링하는 것이 좋습니다.
서버 부하를 모니터링할 때는 짧은 급증이라도 장애 조치(failover) 및 명령 시간 제한을 트리거할 수 있으므로 평균이 아닌 서버 로드의 최대 급증을 검사하는 것이 좋습니다.
서버 유지 관리 계획
캐시 서버가 유지 관리 중인 동안 최대 로드를 처리할 수 있는 충분한 서버 용량이 있는지 확인 합니다. 최대 로드 상태에서 노드를 다시 부팅하여 시스템을 테스트 합니다. 패치의 배포를 시뮬레이션 하는 방법에 대한 자세한 정보는 재부팅을 참조하세요.
장애 조치(failover) 후 서버 부하 증가 테스트
표준 및 프리미엄 SKU의 경우 각 캐시는 두 노드에서 호스트됩니다. 부하 분산 장치는 클라이언트 연결을 두 노드에 분산합니다. 주 노드에서 계획되거나 계획되지 않은 유지 관리가 발생하면 노드는 모든 클라이언트 연결을 닫습니다. 이러한 상황에서는 모든 클라이언트 연결이 단일 노드에 배치되어 서버 부하가 나머지 노드에서 증가할 수 있습니다. 주 노드를 다시 부팅하고 서버 부하가 너무 높지 않으면서 한 노드가 모든 클라이언트 연결을 처리할 수 있는지 확인하여 이 시나리오를 테스트하는 것이 좋습니다.