

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# 어떤 지표를 모니터링해야 합니까?
<a name="CacheMetrics.WhichShouldIMonitor"></a>

다음 CloudWatch 지표는 ElastiCache 성능에 대한 좋은 정보를 제공합니다. 대부분의 경우 이러한 지표에 대해 성능 문제가 생기기 전에 수정 조치를 취할 수 있도록 CloudWatch 경보를 설정하는 것이 좋습니다.

**Topics**
+ [CPUUtilization](#metrics-cpu-utilization)
+ [EngineCPUUtilization](#metrics-engine-cpu-utilization)
+ [SwapUsage(Valkey 및 Redis OSS)](#metrics-swap-usage)
+ [Evictions](#metrics-evictions)
+ [CurrConnections](#metrics-curr-connections)
+ [메모리(Valkey 및 Redis OSS)](#metrics-memory)
+ [Network](#metrics-network)
+ [Latency](#metrics-latency)
+ [복제](#metrics-replication)
+ [트래픽 관리(Valkey 및 Redis OSS)](#traffic-management)

## CPUUtilization
<a name="metrics-cpu-utilization"></a>

이는 백분율(%)로 보고된 호스트 수준 지표입니다. 자세한 내용은 [호스트 수준 지표](CacheMetrics.HostLevel.md) 단원을 참조하십시오.

**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용 지표](CacheMetrics.Redis.md)를 참조하세요.

4vCPU 이상의 대규모 노드 유형에는 Valkey 또는 Redis OSS 엔진 코어의 대한 사용률을 보고하는 `EngineCPUUtilization` 지표를 사용할 수 있습니다. 노드에서 이 지표를 사용할 수 있는지 확인하고 자세한 내용을 보려면 [Redis OSS 지표](CacheMetrics.Redis.md)를 참조하세요.

**Memcached**

Memcached는 다중 스레드이므로 이 지표가 90%에 이를 수 있습니다. 이 임곗값을 초과할 경우 대형 캐시 노드 유형을 사용하여 클러스터를 스케일 업하거나 더 많은 캐시 노드를 추가하여 스케일 아웃합니다.

## EngineCPUUtilization
<a name="metrics-engine-cpu-utilization"></a>

4vCPU 이상의 대규모 노드 유형에는 Redis OSS 엔진 코어의 대한 사용률을 보고하는 `EngineCPUUtilization` 지표를 사용할 수 있습니다. 노드에서 이 지표를 사용할 수 있는지 확인하고 자세한 내용을 보려면 [Valkey 및 Redis OSS용 지표](CacheMetrics.Redis.md)를 참조하세요.

자세한 내용은 [Amazon CloudWatch를 사용하는 Amazon ElastiCache for Redis OSS 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)의 **CPU** 섹션을 참조하세요.

## SwapUsage(Valkey 및 Redis OSS)
<a name="metrics-swap-usage"></a>

이는 바이트로 보고된 호스트 수준 지표입니다. 자세한 내용은 [호스트 수준 지표](CacheMetrics.HostLevel.md) 단원을 참조하십시오.

`FreeableMemory` CloudWatch 지표가 0에 가깝거나(즉, 100MB 미만) `SwapUsage` 지표가 `FreeableMemory` 지표보다 큰 경우 노드가 메모리 부족 상태임을 나타냅니다. 이러한 상황이 발생하면 다음 주제를 참조하세요.
+ [충분한 메모리를 확보하여 Valkey 또는 Redis OSS 스냅샷 생성](BestPractices.BGSAVE.md)
+ [Valkey 및 Redis OSS에 대한 예약된 메모리 관리](redis-memory-management.md)

## Evictions
<a name="metrics-evictions"></a>

이것은 캐시 엔진 지표입니다. 애플리케이션 요구 사항에 따라 이 지표에 대한 경보 임계값을 결정하는 것이 좋습니다.

Memcached를 사용 중이고 선택한 임계값을 초과하는 경우 대형 노드 유형을 사용하여 클러스터를 스케일 업하거나 더 많은 노드를 추가하여 스케일 아웃합니다.

## CurrConnections
<a name="metrics-curr-connections"></a>

이것은 캐시 엔진 지표입니다. 애플리케이션 요구 사항에 따라 이 지표에 대한 경보 임계값을 결정하는 것이 좋습니다.

*CurrConnections* 개수가 증가하는 것은 애플리케이션에 문제가 있음을 나타내며 이 문제를 해결하려면 애플리케이션 동작을 확인해야 합니다.

자세한 내용은 [Amazon CloudWatch를 사용하는 Amazon ElastiCache for Redis OSS 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)의 **연결** 섹션을 참조하세요.

## 메모리(Valkey 및 Redis OSS)
<a name="metrics-memory"></a>

메모리는 Valkey 및 Redis OSS의 핵심적인 측면입니다. 데이터 손실을 방지하고 데이터 집합의 향후 증가를 수용하려면 클러스터의 메모리 사용률을 파악할 필요가 있습니다. 노드의 메모리 사용률에 대한 통계는 [INFO](https://valkey.io/commands/info) 명령의 메모리 섹션에서 확인할 수 있습니다.

자세한 내용은 [Amazon CloudWatch를 사용하는 Amazon ElastiCache for Redis OSS 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)의 **메모리** 섹션을 참조하세요.

## Network
<a name="metrics-network"></a>

클러스터의 네트워크 대역폭 용량을 결정하는 요인 중 하나는 선택한 노드 유형입니다. 노드의 네트워크 용량에 대한 자세한 내용은 [Amazon ElastiCache 요금](https://aws.amazon.com/elasticache/pricing/) 섹션을 참조하세요.

자세한 내용은 [Amazon CloudWatch를 사용하는 Amazon ElastiCache for Redis OSS 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)의 **네트워크** 섹션을 참조하세요.

## Latency
<a name="metrics-latency"></a>

ElastiCache for Valkey 인스턴스의 응답 시간 측정은 필요한 세분화 수준에 따라 다양한 방식으로 접근할 수 있습니다. ElastiCache for Valkey의 전체 서버 측 응답 시간에 기여하는 주요 단계는 명령 사전 처리, 명령 실행 및 명령 사후 처리입니다.

 GetTypeCmdsLatency 및 SetTypeCmdsLatency 지표와 같은 Valkey [INFO](https://valkey.io/commands/info) 명령에서 파생된 명령별 지연 시간 지표는 특히 Valkey 명령에 대한 코어 명령 로직을 실행하는 데 중점을 둡니다. 이러한 지표는 사용 사례가 데이터 구조당 명령 실행 시간 또는 집계된 지연 시간을 결정하는 경우 유용합니다.

지연 시간 지표 `SuccessfulWriteRequestLatency` 및 `SuccessfulReadRequestLatency`는 ElastiCache for Valkey 엔진이 요청에 응답하는 데 걸리는 총 시간을 측정합니다.

**참고**  
Valkey 클라이언트에서 CLIENT REPLY가 활성화된 상태에서 Valkey 파이프라이닝을 사용할 때 `SuccessfulWriteRequestLatency` 및 `SuccessfulReadRequestLatency` 지표에 대한 팽창된 값이 발생할 수 있습니다. Valkey 파이프라이닝은 각 개별 명령에 대한 응답을 기다리지 않고 한 번에 여러 명령을 실행하여 성능을 개선하는 기법입니다. 값이 부풀어 오르지 않도록 하려면 [CLIENT REPLY OFF](https://valkey.io/commands/client-reply/)를 사용하여 명령을 파이프라인하도록 Valkey 클라이언트를 구성하는 것이 좋습니다.

자세한 내용은 [Amazon CloudWatch를 사용하는 Amazon ElastiCache 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)의 **대기 시간** 섹션을 참조하세요.

## 복제
<a name="metrics-replication"></a>

복제되는 데이터의 볼륨은 `ReplicationBytes` 지표를 통해 확인할 수 있습니다. 이 지표는 복제 그룹에 대한 쓰기 로드를 나타내지만 복제 상태에 대한 자세한 정보는 제공하지 않습니다. 이 목적을 위해 `ReplicationLag` 지표를 사용할 수 있습니다.

자세한 내용은 [Amazon CloudWatch를 사용하는 Amazon ElastiCache for Redis OSS 모니터링 모범 사례](https://aws.amazon.com/blogs/database/monitoring-best-practices-with-amazon-elasticache-for-redis-using-amazon-cloudwatch/)의 **복제** 섹션을 참조하세요.

## 트래픽 관리(Valkey 및 Redis OSS)
<a name="traffic-management"></a>

 ElastiCache for Redis OSS는 Valkey 또는 Redis OSS에서 처리할 수 있는 것보다 더 많은 수신 명령이 노드로 전송되는 경우 노드에 대해 자동으로 트래픽을 관리합니다. 이는 엔진의 최적 운영 및 안정성을 유지하기 위한 것입니다.

 노드에서 트래픽이 활발하게 관리되는 경우 `TrafficManagementActive` 지표는 데이터 포인트 1을 방출합니다. 이는 노드가 제공되는 워크로드에 대해 적게 크기 조정되었음을 나타냅니다. 이 지표가 1인 상태로 오래 유지되면 클러스터를 평가하여 스케일 업 또는 스케일 아웃이 필요한지 결정하세요.

 자세한 내용은 [지표](CacheMetrics.Redis.md) 페이지의 `TrafficManagementActive` 지표를 참조하세요.