ElastiCache 클러스터에서 메모리 사용량이 많거나 증가하는 이유는 무엇입니까?

해결 방법

클러스터 및 해당 노드의 전체 메모리 사용량을 확인하려면 다음 Redis 지표를 검토합니다. 이러한 지표는 클러스터의 각 노드에 대해 Amazon CloudWatch에 게시됩니다.

• BytesUsedForCache: 데이터 세트, 버퍼 등에 대해 Redis에서 할당한 총 바이트 수입니다. 이 지표는 Redis 노드의 INFO 명령 출력에서 파생됩니다. 이 지표를 사용하여 클러스터의 메모리 사용률을 확인할 수 있습니다.
• FreeableMemory: 이 호스트 수준 지표는 호스트에서 사용 가능한 메모리의 양을 보여줍니다. 캐시 데이터 또는 오버헤드로 인해 메모리 사용량이 증가할 때 FreeableMemory의 감소를 확인할 수 있습니다. FreeableMemory가 감소하면 호스트의 사용 가능한 메모리가 부족함을 나타냅니다. FreeableMemory가 너무 낮은 경우 스왑이 발생할 수 있습니다.
• DataBaseMemoryUsagePercentage: 이 지표는 Redis INFO 명령 출력에서 파생됩니다. 이는 클러스터 노드에서 사용하는 메모리의 백분율입니다. Redis는 이 지표가 임계값의 100% 에 도달하면 Redis 최대 메모리 제거 정책을 시작합니다.

기본적으로 ElastiCache for Redis는 장애 조치 및 백업과 같은 비데이터 사용량을 위해 max-memory의 25% 를 예약합니다. 비 데이터 사용량을 위한 예약 메모리를 충분히 지정하지 않으면 스와핑 가능성이 높아집니다. 자세한 내용은 예약 메모리 관리를 참조하세요.

메모리 사용량 급증 원인

• 최근 추가된 키: 새 키-값 쌍을 추가하면 메모리 사용량이 증가합니다. 기존 키에 요소를 추가하면 메모리 사용량도 증가합니다. SetTypeCmds 지표를 확인하여 노드에 최근 데이터 변경 사항이 있는지 확인합니다. 이 지표는 쓰기 유형 명령의 총 수를 기록하며 Redis commandstats 통계에서 파생됩니다.
• 버퍼 사용량 증가: 클라이언트는 네트워크를 통해 Redis에 연결됩니다. 클라이언트가 캐시에서 충분히 빠르게 읽지 않는 경우 Redis는 클라이언트 출력 버퍼라는 메모리 공간에 응답 데이터를 보관합니다. 클라이언트는 버퍼 공간에서 계속 읽을 수 있습니다. 구독한 클라이언트가 충분히 빠르게 읽지 않는 경우 Pub 및 Sub 클라이언트의 경우에도 마찬가지입니다.
  네트워크 대역폭에 병목 현상이 발생하거나 클러스터의 부하가 지속적으로 많은 경우 버퍼 사용량이 계속 누적될 수 있습니다. 이러한 누적으로 인해 메모리가 고갈되고 성능이 저하됩니다. 기본적으로 ElastiCache for Redis는 출력 버퍼의 증가를 제한하지 않으며 각 클라이언트에는 자체 버퍼가 있습니다. client-list 명령을 사용하여 버퍼 사용량을 확인합니다.
• 많은 새 연결 수: 새 연결 수가 많으면 메모리 사용량이 증가할 수 있습니다. 모든 새 연결은 메모리를 사용하는 파일 설명자를 생성합니다. 새 연결 수가 많은 경우 메모리 사용량이 많아 데이터 제거 또는 OOM 오류가 발생할 수 있습니다. 허용된 새 연결의 총 수에 대한 NewConnections 지표를 확인합니다.
• 많은 스왑 사용량: 사용 가능한 메모리가 있을 때 캐시 노드에서 약간의 스왑 사용량이 보이는 것은 정상입니다. 하지만 스왑 사용량이 너무 많으면 성능 문제가 발생할 수 있습니다. 일반적으로 메모리 부족 상태에서 실행되는 노드에서 많은 스왑이 발생하기 시작하여 사용 가능한 메모리가 부족하게 됩니다. SwapUsage 지표를 사용하여 호스트의 스왑을 모니터링합니다.
• 많은 메모리 조각화: 많은 메모리 조각화는 운영 체제 내에서 메모리 관리의 비효율성을 나타냅니다. 키가 제거되면 Redis에서 메모리를 확보하지 못할 수 있습니다. MemoryFragmentationRatio 지표를 사용하여 조각화 비율을 모니터링합니다. 조각화 문제가 발생하는 경우 활성 메모리 조각 모음에 대해 activedefrag 파라미터 캔을 켭니다.
• 큰 키: 데이터 크기가 크거나 요소 수가 많은 키를 큰 키라고 합니다. CurrItems 지표가 낮게 유지되더라도 큰 키의 결과로 많은 메모리 사용량을 볼 수 있습니다. 데이터 세트에서 큰 키를 감지하려면 redis-cli --bigkeys 명령을 사용합니다.

많은 메모리 사용량 제어에 대한 모범 사례

• 키에 TTL 사용: 만료 시 키에 TTL을 지정할 수 있습니다. 이렇게 하면 메모리가 부족해질 때까지 기다리지 않고 만료 후 키가 제거됩니다. 이렇게 하면 불필요한 키로 인해 Redis가 복잡해지는 것을 방지합니다. 제거 수가 적더라도 문제가 되지 않지만 제거 수가 많으면 노드가 메모리 부족으로 실행되고 있음을 의미합니다.
• 제거 정책 사용: 캐시 메모리가 꽉 차기 시작하면 Redis는 maxmemory-policy에 따라 키를 제거하여 공간을 확보합니다. 기본 maxmemory-policy는 volatile_lru로 설정됩니다. 워크로드 요구 사항에 맞는 제거 정책을 선택하는 것이 가장 좋습니다.
• 예약 메모리 할당: 장애 조치 또는 백업 중에 발생하는 문제를 방지하려면 비데이터 사용에 대해 reserved_memory_percentage를 최소 25%로 설정하는 것이 좋습니다. 예약 메모리가 부족하여 장애 조치 또는 백업을 수행할 수 없는 경우 스왑 및 성능 문제가 발생합니다.
• 연결 풀링 사용: 연결 풀링은 Redis 클라이언트가 시도한 많은 수의 새 연결을 제어하는 데 도움이 됩니다. 많은 수의 새 연결을 처리하기 위한 AWS 모범 사례 지침을 검토하세요.
• 출력 버퍼 크기 제한 조정: 출력 버퍼 제한을 조정하여 버퍼 공간 사용량을 제어할 수 있습니다. ElastiCache for Redis 파라미터 그룹은 클라이언트 출력 버퍼 사용량의 무제한 증가를 방지하기 위해 client-output-buffer-limit-*로 시작하는 여러 파라미터를 제공합니다. 모든 워크로드가 고유하므로 이러한 파라미터에 대한 권장 제한은 없습니다. 적절한 값을 선택할 수 있도록 워크로드를 벤치마킹하는 것이 가장 좋습니다.
• 해시 매핑 사용 고려: Redis에서 Redis DB의 총 메모리 공간은 선형입니다. 필드 수가 적은 단일 해시 매핑 키보다 적은 개별 키로 더 많은 메모리를 사용합니다. 해시 매핑은 많은 수의 키가 있는 데이터 구조에 도움이 됩니다. 해시 매핑 외에도 해시 테이블에 비해 메모리 공간을 줄이는 ziplist 인코딩을 활용할 수 있습니다. 해시 매핑을 사용하면 세트 작업보다 많은 CPU가 필요한 복잡한 명령이므로 Redis 엔진 사용량이 급증할 수 있습니다.
• 클러스터 확장: 경우에 따라 필요한 예방 조치를 취한 후 메모리 부족이 발생할 수 있습니다. 이러한 상황이 발생하고 사용량이 예상 워크로드로 인한 것이면 메모리 병목 현상을 완화하기 위해 적절한 확장을 수행하는 것이 좋습니다.
• 메모리 사용량에 대한 경보를 설정합니다. 메모리 사용량이 사전 설정된 임계값을 초과할 때 CloudWatch 경보를 사용하여 경보를 시작할 수 있습니다. 모니터링 및 확장 목적으로 CloudWatch 콘솔에서 경보를 생성하려면 BytesUsedForCache 또는 DatabaseMemoryUsagePercentage 지표를 사용합니다.

---

관련 정보

Redis용 지표

Redis 4.0.10 파라미터 변경 사항

ElastiCache for Redis 클러스터 노드에 대한 오류 메시지 "OOM command not allowed"를 해결하려면 어떻게 해야 합니까?

키 제거

Redis를 위한 메모리 최적화