기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
어떤 지표를 모니터링해야 합니까?
다음 CloudWatch 지표는 ElastiCache 성능에 대한 좋은 정보를 제공합니다. 대부분의 경우 이러한 지표에 대해 성능 문제가 생기기 전에 수정 조치를 취할 수 있도록 CloudWatch 경보를 설정하는 것이 좋습니다.
모니터링할 지표
CPUUtilization
이는 백분율(%)로 보고된 호스트 수준 지표입니다. 자세한 내용은 호스트 수준 지표 단원을 참조하십시오.
Valkey 및 Redis OSS
2vCPU 이하의 작은 노드 유형에는 CPUUtilization 지표를 사용하여 워크로드를 모니터링하세요.
일반적으로, 사용 가능한 CPU의 90%로 임계값을 설정하는 것이 좋습니다. Valkey 및 Redis OSS는 모두 단일 스레드이기 때문에 실제 임계값은 노드 총용량의 일부로 계산해야 합니다. 2개의 코어가 있는 노드 유형을 사용하는 경우를 예로 들어보겠습니다. 이 경우, CPUUtilization의 임계값은 90/2 또는 45%입니다.
사용 중인 캐시 노드에 있는 코어 개수에 따라 임계값을 결정해야 합니다. 이 임계값을 초과하고, 주된 워크로드가 읽기 요청에서 비롯되는 경우에는 읽기 전용 복제본을 추가하여 캐시 클러스터를 스케일 아웃합니다. 주된 워크로드가 쓰기 요청에서 비롯되는 경우에는 클러스터 구성에 따라 다음을 권장합니다.
-
Valkey 또는 Redis OSS(클러스터 모드 비활성화됨) 클러스터: 더 큰 캐시 인스턴스 유형을 사용하여 스케일 업합니다.
-
Valkey 또는 Redis OSS(클러스터 모드 활성화됨) 클러스터: 샤드를 추가하여 쓰기 워크로드를 프라이머리 노드 전체에 더 많이 배포합니다.
작은 정보
호스트 수준 지표 CPUUtilization을 사용하는 대신, Valkey 및 Redis OSS 사용자는 Valkey 또는 Redis OSS 엔진 코어의 대한 사용률을 보고하는 지표 EngineCPUUtilization을 사용할 수 있습니다. 노드에서 이 지표를 사용할 수 있는지 확인하고 자세한 내용을 보려면 Valkey 및 Redis OSS용 지표를 참조하세요.
4vCPU 이상의 대규모 노드 유형에는 Valkey 또는 Redis OSS 엔진 코어의 대한 사용률을 보고하는 EngineCPUUtilization 지표를 사용할 수 있습니다. 노드에서 이 지표를 사용할 수 있는지 확인하고 자세한 내용을 보려면 Redis OSS 지표를 참조하세요.
Memcached
Memcached는 다중 스레드이므로 이 지표가 90%에 이를 수 있습니다. 이 임계값을 초과할 경우 대형 캐시 노드 유형을 사용하여 캐시 클러스터를 스케일 업하거나 더 많은 캐시 노드를 추가하여 스케일 아웃합니다.
EngineCPUUtilization
4vCPU 이상의 대규모 노드 유형에는 Redis OSS 엔진 코어의 대한 사용률을 보고하는 EngineCPUUtilization 지표를 사용할 수 있습니다. 노드에서 이 지표를 사용할 수 있는지 확인하고 자세한 내용을 보려면 Valkey 및 Redis OSS용 지표를 참조하세요.
자세한 내용은 Amazon CloudWatch를 사용하여 Amazon ElastiCache for Redis OSS를 사용한 모범 사례 모니터링 Amazon CloudWatch
SwapUsage(Valkey 및 Redis OSS)
이는 바이트로 보고된 호스트 수준 지표입니다. 자세한 내용은 호스트 수준 지표 단원을 참조하십시오.
FreeableMemory CloudWatch 지표가 0에 가깝거나(즉, 100MB 미만) SwapUsage 지표가 FreeableMemory 지표보다 큰 경우 노드가 메모리 부족 상태임을 나타냅니다. 이러한 상황이 발생하면 다음 주제를 참조하세요.
Evictions
이것은 캐시 엔진 지표입니다. 애플리케이션 요구 사항에 따라 이 지표에 대한 경보 임계값을 결정하는 것이 좋습니다.
Memcached를 사용 중이고 선택한 임계값을 초과하는 경우 대형 노드 유형을 사용하여 클러스터를 스케일 업하거나 더 많은 노드를 추가하여 스케일 아웃합니다.
CurrConnections
이것은 캐시 엔진 지표입니다. 애플리케이션 요구 사항에 따라 이 지표에 대한 경보 임계값을 결정하는 것이 좋습니다.
CurrConnections 개수가 증가하는 것은 애플리케이션에 문제가 있음을 나타내며 이 문제를 해결하려면 애플리케이션 동작을 확인해야 합니다.
자세한 내용은 Amazon CloudWatch를 사용하여 Amazon ElastiCache for Redis OSS를 사용한 모범 사례 모니터링 Amazon CloudWatch
메모리(Valkey 및 Redis OSS)
메모리는 Valkey 및 Redis OSS의 핵심적인 측면입니다. 데이터 손실을 방지하고 데이터 집합의 향후 증가를 수용하려면 클러스터의 메모리 사용률을 파악할 필요가 있습니다. 노드의 메모리 사용률에 대한 통계는 INFO
자세한 내용은 Amazon CloudWatch를 사용하여 Amazon ElastiCache for Redis OSS를 사용한 모범 사례 모니터링 Amazon CloudWatch
Network
클러스터의 네트워크 대역폭 용량을 결정하는 요인 중 하나는 선택한 노드 유형입니다. 노드의 네트워크 용량에 대한 자세한 내용은 Amazon ElastiCache 요금
자세한 내용은 Amazon CloudWatch를 사용하여 Amazon ElastiCache for Redis OSS를 사용한 모범 사례 모니터링 Amazon CloudWatch
지연 시간
ElastiCache for Valkey 인스턴스의 응답 시간 측정은 필요한 세분화 수준에 따라 다양한 방식으로 접근할 수 있습니다. ElastiCache for Valkey의 전체 서버 측 응답 시간에 기여하는 주요 단계는 명령 사전 처리, 명령 실행 및 명령 사후 처리입니다.
GetTypeCmdsLatency 및 SetTypeCmdsLatency 지표와 같은 Valkey INFO
지연 시간 지표 SuccessfulWriteRequestLatency 및는 ElastiCache for Valkey 엔진이 요청에 응답하는 데 걸리는 총 시간을 SuccessfulReadRequestLatency 측정합니다.
참고
Valkey 클라이언트에서 클라이언트 응답이 활성화된 상태에서 Valkey 파이프라이닝을 사용할 때 SuccessfulWriteRequestLatency 및 SuccessfulReadRequestLatency 지표에 대한 값이 부풀려질 수 있습니다. Valkey 파이프라이닝은 각 개별 명령에 대한 응답을 기다리지 않고 한 번에 여러 명령을 실행하여 성능을 개선하는 기법입니다. 값이 부풀어 오르지 않도록 하려면 클라이언트 응답 꺼짐을 사용하여 명령을 파이프라인하도록 Valkey 클라이언트
자세한 내용은 Amazon CloudWatch를 사용하는 Amazon ElastiCache 모니터링 모범 사례
복제
복제되는 데이터의 볼륨은 ReplicationBytes 지표를 통해 확인할 수 있습니다. 이 지표는 복제 그룹에 대한 쓰기 로드를 나타내지만 복제 상태에 대한 자세한 정보는 제공하지 않습니다. 이 목적을 위해 ReplicationLag 지표를 사용할 수 있습니다.
자세한 내용은 Amazon CloudWatch를 사용하여 Amazon ElastiCache for Redis OSS를 사용한 모범 사례 모니터링 Amazon CloudWatch
트래픽 관리(Valkey 및 Redis OSS)
ElastiCache for Redis OSS는 Valkey 또는 Redis OSS에서 처리할 수 있는 것보다 더 많은 수신 명령이 노드로 전송될 때 노드에 대한 트래픽을 자동으로 관리합니다. 이는 엔진의 최적 운영 및 안정성을 유지하기 위한 것입니다.
노드에서 트래픽이 활발하게 관리되는 경우 TrafficManagementActive 지표는 데이터 포인트 1을 방출합니다. 이는 노드가 제공되는 워크로드에 대해 적게 크기 조정되었음을 나타냅니다. 이 지표가 1인 상태로 오래 유지되면 클러스터를 평가하여 스케일 업 또는 스케일 아웃이 필요한지 결정하세요.
자세한 내용은 지표 페이지의 TrafficManagementActive 지표를 참조하세요.
