기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# ElastiCache를 사용한 일반적인 문제 해결 단계 및 모범 사례
다음 주제에서는 ElastiCache를 사용할 때 발생할 수 있는 오류 및 문제에 대한 문제 해결 조언을 제공합니다. 여기에 나열되지 않은 문제를 발견하는 경우 이 페이지의 피드백 버튼을 사용하여 해당 문제를 보고할 수 있습니다.
문제 해결 조언과 일반적인 지원 질문에 대한 답변은 [AWS지식 센터](https://aws.amazon.com/premiumsupport/knowledge-center/)를 참조하세요.
**Topics**
+ [
## 연결 문제
](#wwe-troubleshooting.connection)
+ [
## Valkey 또는 Redis OSS 클라이언트 오류
](#wwe-troubleshooting.clienterrors)
+ [
## ElastiCache 서버리스의 지연 시간 문제 해결
](#wwe-troubleshooting.latency)
+ [
## ElastiCache 서버리스의 스로틀링 문제 해결
](#wwe-troubleshooting.throttling)
+ [
# 지속적인 연결 문제
](TroubleshootingConnections.md)
+ [
## 관련 항목
](#wwe-troubleshooting.related)
## 연결 문제
ElastiCache 캐시에 연결할 수 없는 경우 다음 중 하나를 고려하세요.
1. **TLS 사용: **ElastiCache 엔드포인트에 연결하려고 할 때 연결이 끊긴 경우 클라이언트에서 TLS를 사용하지 않을 수 있습니다. ElastiCache 서버리스를 사용하는 경우 전송 중 암호화가 항상 활성화됩니다. 클라이언트가 TLS를 사용하여 캐시에 연결하는지 확인합니다. [TLS 지원 캐시에 연결하는 방법에 대해 자세히 알아보세요](connect-tls.md).
1. **VPC:** ElastiCache 캐시는 VPC 내에서만 액세스할 수 있습니다. 캐시에 액세스하는 EC2 인스턴스와 ElastiCache 캐시가 동일한 VPC에 생성되었는지 확인합니다. 또는 EC2 인스턴스가 있는 VPC와 캐시를 생성하는 VPC 간에 [VPC 피어링](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html)을 활성화해야 합니다.
1. **보안 그룹: **ElastiCache는 보안 그룹을 사용하여 캐시에 대한 액세스를 제어합니다. 다음을 고려하세요.
1. ElastiCache 캐시에서 사용하는 보안 그룹이 EC2 인스턴스에서 인바운드 액세스를 허용하는지 확인합니다. 보안 그룹에서 인바운드 규칙을 올바르게 설정하는 방법은 [여기](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html)를 참조하세요.
1. ElastiCache 캐시에서 사용하는 보안 그룹이 캐시 포트에 대한 액세스를 허용하는지 확인합니다(서버리스의 경우 6379 및 6380, 노드 기반인 경우 기본적으로 6379). ElastiCache는 이러한 포트를 사용하여 Valkey 또는 Redis OSS 명령을 수락합니다. 포트 액세스를 설정하는 방법에 대한 자세한 내용은 [여기](set-up.md#elasticache-install-grant-access-VPN)에서 확인하세요.
연결이 계속 어려운 경우 다른 단계는 [지속적인 연결 문제](TroubleshootingConnections.md) 섹션을 참조하세요.
## Valkey 또는 Redis OSS 클라이언트 오류
ElastiCache 서버리스는 Valkey 또는 Redis OSS 클러스터 모드 프로토콜을 지원하는 클라이언트를 통해서만 액세스할 수 있습니다. 노드 기반 클러스터는 클러스터 구성에 따라 어느 모드에서든 클라이언트에서 액세스할 수 있습니다.
클라이언트에 오류가 발생하는 경우 다음을 고려하세요.
1. **클러스터 모드: **[SELECT](https://valkey.io/commands/select/) 명령에서 CROSSLOT 오류 또는 오류가 발생하는 경우 클러스터 프로토콜을 지원하지 않는 Valkey 또는 Redis OSS 클라이언트를 사용하여 클러스터 모드 활성화 캐시에 액세스하려고 할 수 있습니다. ElastiCache 서버리스는 Valkey 또는 Redis OSS 클러스터 프로토콜을 지원하는 클라이언트만 지원합니다. ‘클러스터 모드 비활성화’(CMD)에서 Valkey 또는 Redis OSS를 사용하려면 노드 기반 클러스터를 설계해야 합니다.
1. **CROSSLOT 오류: **`ERR CROSSLOT Keys in request don't hash to the same slot` 오류가 발생하는 경우 클러스터 모드 캐시의 동일한 슬롯에 속하지 않는 키에 액세스하려고 할 수 있습니다. ElastiCache 서버리스는 항상 클러스터 모드에서 작동합니다. 여러 키를 포함하는 다중 키 작업, 트랜잭션 또는 Lua 스크립트는 관련된 모든 키가 동일한 해시 슬롯에 있는 경우에만 허용됩니다.
Valkey 또는 Redis OSS 클라이언트 구성에 대한 추가 모범 사례는 이 [블로그 게시물](https://aws.amazon.com/blogs/database/best-practices-redis-clients-and-amazon-elasticache-for-redis/)을 참조하세요.
## ElastiCache 서버리스의 지연 시간 문제 해결
워크로드의 지연 시간이 길면 CloudWatch `SuccessfulReadRequestLatency` 및 `SuccessfulWriteRequestLatency` 지표를 분석하여 지연 시간이 ElastiCache 서버리스와 관련이 있는지 확인할 수 있습니다. 이러한 지표는 ElastiCache 서버리스의 내부인 지연 시간을 측정합니다. 클라이언트 측 지연 시간과 클라이언트와 ElastiCache 서버리스 엔드포인트 간의 네트워크 트립 시간은 포함되지 않습니다.
**클라이언트 측 지연 시간 문제 해결**
클라이언트 측 지연 시간은 증가했지만 서버 측 지연 시간을 측정하는 ``CloudWatch `SuccessfulReadRequestLatency` 및 `SuccessfulWriteRequestLatency` 지표에는 그에 상응하는 증가가 없는 경우 다음을 고려하세요.
+ **보안 그룹이 포트 6379 및 6380에 대한 액세스를 허용하는지 확인합니다.** ElastiCache 서버리스는 기본 엔드포인트에 6379 포트를 사용하고 리더 엔드포인트에 6380 포트를 사용합니다. 일부 클라이언트는 애플리케이션이 복제본에서 읽기 기능을 사용하지 않더라도 모든 새 연결에 대해 두 포트에 대한 연결을 설정합니다. 보안 그룹에서 두 포트에 대한 인바운드 액세스를 허용하지 않으면 연결 설정이 더 오래 걸릴 수 있습니다. 포트 액세스를 설정하는 방법에 대한 자세한 내용은 [여기](set-up.md#elasticache-install-grant-access-VPN)에서 확인하세요.
**서버 측 지연 시간 문제 해결**
일부 변동성 및 간헐적 급증은 걱정할 필요가 없습니다. 그러나 `Average` 통계에서 급격한 증가가 나타나고 지속되면Health Dashboard및 Personal Health Dashboard에서 자세한 내용을 확인해야 합니다. 필요한 경우를 사용하여 지원 사례를 여는 것이 좋습니다지원.
지연 시간을 줄이기 위해 다음 모범 사례와 전략을 고려하세요.
+ **복제본에서 읽기 활성화: **애플리케이션에서 허용하는 경우 Valkey 또는 Redis OSS 클라이언트에서 “복제본에서 읽기” 기능을 활성화하여 읽기를 확장하고 지연 시간을 줄이는 것이 좋습니다. 활성화되면 ElastiCache 서버리스는 클라이언트와 동일한 가용 영역(AZ)에 있는 복제본 캐시 노드로 읽기 요청을 라우팅하려고 시도하므로 AZ 간 네트워크 지연 시간을 방지합니다. 클라이언트의 복제본에서 읽기 기능을 활성화하면 애플리케이션이 데이터의 최종 일관성을 수락한다는 의미입니다. 키에 쓴 후 읽기를 시도하는 경우 애플리케이션이 일정 시간 동안 이전 데이터를 수신할 수 있습니다.
+ **애플리케이션이 캐시와 동일한 AZ에 배포되었는지 확인합니다. **애플리케이션이 캐시와 동일한 AZ에 배포되지 않은 경우 클라이언트 측 지연 시간이 더 길어질 수 있습니다. 서버리스 캐시를 생성할 때 애플리케이션이 캐시에 액세스할 서브넷을 제공할 수 있으며 ElastiCache 서버리스는 해당 서브넷에 VPC 엔드포인트를 생성합니다. 애플리케이션이 동일한 AZ에 배포되어 있는지 확인합니다. 그렇지 않으면 애플리케이션이 캐시에 액세스할 때 AZ 사이에 홉이 발생하여 클라이언트 측 지연 시간이 길어질 수 있습니다.
+ **연결 재사용: **ElastiCache 서버리스 요청은 RESP 프로토콜을 사용하여 TLS 지원 TCP 연결을 통해 이루어집니다. 연결(구성된 경우 연결 인증 포함)을 시작하는 데 시간이 걸리므로 첫 번째 요청의 지연 시간이 일반적인 요청보다 깁니다. 이미 초기화된 연결을 통한 요청은 ElastiCache의 일관되고 짧은 지연 시간을 제공합니다. 따라서 연결 풀링을 사용하거나 기존 Valkey 또는 Redis OSS 연결을 재사용하는 것이 좋습니다.
+ **확장 속도: **ElastiCache 서버리스는 요청 속도가 증가함에 따라 자동으로 확장됩니다. ElastiCache 서버리스가 확장하는 속도보다 빠른 요청 속도가 갑자기 크게 증가하면 일정 시간 동안 지연 시간이 늘어날 수 있습니다. ElastiCache 서버리스는 일반적으로 지원되는 요청 속도를 빠르게 높일 수 있으며, 요청 속도를 두 배로 높이는 데 최대 10\$112분이 걸립니다.
+ **장기 실행 명령 검사: **Lua 스크립트 또는 대규모 데이터 구조의 명령을 포함한 일부 Valkey 또는 Redis OSS 명령이 장시간 실행될 수 있습니다. 이러한 명령을 식별하기 위해 ElastiCache는 명령 수준 지표를 게시합니다. [ElastiCache 서버리스](serverless-metrics-events-redis.md#serverless-metrics)를 사용하면 `BasedECPUs` 지표를 사용할 수 있습니다.
+ **제한된 요청: ** ElastiCache 서버리스에서 요청이 제한되면 애플리케이션에서 클라이언트 측 지연 시간이 증가할 수 있습니다. ElastiCache 서버리스에서 요청이 제한되면 `ThrottledRequests` [ElastiCache 서버리스](serverless-metrics-events-redis.md#serverless-metrics) 지표가 증가하는 것을 볼 수 있습니다. 제한된 요청 문제를 해결하려면 아래 섹션을 검토하세요.
+ **키 및 요청의 균일한 배포: **ElastiCache for Valkey 및 Redis OSS에서 슬롯당 키 또는 요청이 고르지 않게 배포되면 핫 슬롯이 발생하여 지연 시간이 늘어날 수 있습니다. ElastiCache 서버리스는 간단한 SET/GET 명령을 실행하는 워크로드에서 단일 슬롯에서 초당 최대 30,000ECPUs(복제본에서 읽기 사용 시 초당 90,000개의 ECPU)를 지원합니다. 슬롯 간 키 및 요청 배포를 평가하고 요청 속도가 이 제한을 초과하는 경우 균일한 배포를 확인하는 것이 좋습니다.
## ElastiCache 서버리스의 스로틀링 문제 해결
서비스 지향 아키텍처 및 분산 시스템에서는 다양한 서비스 구성 요소가 API 호출을 처리하는 속도를 제한하는 것을 제한이라고 합니다. 이를 통해 급증을 완화하고 구성 요소 처리량 불일치를 제어하며 예상치 못한 운영 이벤트가 발생했을 때 보다 예측 가능한 복구를 수행할 수 있습니다. ElastiCache 서버리스는 이러한 유형의 아키텍처를 위해 설계되었으며 대부분의 Valkey 또는 Redis OSS 클라이언트에는 제한된 요청에 대한 재시도가 내장되어 있습니다. 어느 정도의 제한이 애플리케이션에 반드시 문제가 되는 것은 아니지만 데이터 워크플로의 지연 시간에 민감한 부분을 지속적으로 제한하면 사용자 경험에 부정적인 영향을 미치고 시스템의 전반적인 효율성이 떨어질 수 있습니다.
ElastiCache 서버리스에서 요청이 제한되면 `ThrottledRequests` [ElastiCache 서버리스](serverless-metrics-events-redis.md#serverless-metrics) 지표가 증가하는 것을 볼 수 있습니다. 제한된 요청 수가 많을 경우 다음을 고려하세요.
+ **규모 조정 속도: **ElastiCache 서버리스는 더 많은 데이터를 수집하거나 요청 속도를 높일 때 자동으로 규모가 조정됩니다. ElastiCache 서버리스가 규모를 조정하는 속도보다 애플리케이션이 빠르게 크기 조정되는 경우 ElastiCache 서버리스가 워크로드에 맞게 규모를 조정하는 동안 요청이 제한될 수 있습니다. ElastiCache 서버리스는 일반적으로 스토리지 크기를 빠르게 늘릴 수 있으며 캐시의 스토리지 크기를 두 배로 늘리는 데 최대 10\$112분이 걸릴 수 있습니다.
+ **키 및 요청의 균일한 배포: **ElastiCache for Valkey 및 Redis OSS에서 슬롯당 키 또는 요청이 고르지 않게 배포되면 핫 슬롯이 발생할 수 있습니다. 핫 슬롯은 간단한 SET/GET 명령을 실행하는 워크로드에서 단일 슬롯에 대한 요청 속도가 초당 30,000ECPU를 초과하는 경우 요청을 스로틀링할 수 있습니다. 마찬가지로 ElastiCache for Memcached를 사용하면 요청 속도가 초당 30,000 ECPU는 경우 핫 키를 스로틀링할 수 있습니다.
+ **복제본에서 읽기: **애플리케이션에서 허용하는 경우 “복제본에서 읽기” 기능을 사용하는 것이 좋습니다. 대부분의 Valkey 또는 Redis OSS 클라이언트는 “읽기 규모 조정”을 통해 읽기를 복제본 노드로 직접 전송하도록 구성할 수 있습니다. 이 기능을 사용하면 읽기 트래픽을 조정할 수 있습니다. 또한 ElastiCache 서버리스는 복제본 요청의 읽기를 애플리케이션과 동일한 가용 영역의 노드로 자동으로 라우팅하여 지연 시간을 줄입니다. 복제본에서 읽기가 활성화되면 간단한 SET/GET 명령을 사용하여 워크로드에 대해 단일 슬롯에서 초당 최대 90,000ECPU를 달성할 수 있습니다.
# 지속적인 연결 문제
ElastiCache와의 지속적인 연결 문제를 해결하려면 다음 항목을 확인해야 합니다.
**Topics**
+ [
## 보안 그룹
](#Security_groups)
+ [
## 네트워크 ACL
](#Network_ACLs)
+ [
## 라우팅 테이블
](#Route_tables)
+ [
## DNS 확인
](#DNS_Resolution)
+ [
## 서버 측 진단을 사용하여 문제 식별
](#Diagnostics)
+ [
## 네트워크 연결 검증
](#Connectivity)
+ [
## 네트워크 관련 제한 사항
](#Network-limits)
+ [
## CPU 사용량
](#CPU-Usage)
+ [
## 서버 측에서 연결이 종료되는 경우
](#Connections-server)
+ [
## Amazon EC2 인스턴스에 대한 클라이언트 측 문제 해결
](#Connections-client)
+ [
## 단일 요청을 완료하는 데 걸리는 시간 분석
](#Dissecting-time)
## 보안 그룹
보안 그룹은 ElastiCache 클라이언트(EC2 인스턴스, AWS Lambda 함수, Amazon ECS 컨테이너 등) 및 ElastiCache 캐시를 보호하는 가상 방화벽입니다. 보안 그룹은 상태 유지(stateful) 방식으로 작동합니다. 즉, 들어오거나 나가는 트래픽이 허용되면 해당 트래픽에 대한 응답이 관련 보안 그룹의 컨텍스트에서 자동으로 승인됩니다.
상태 유지 기능을 사용하려면 보안 그룹이 권한이 부여된 모든 연결을 추적해야 하며, 이렇게 추적되는 연결에는 제한이 있습니다. 이 제한에 도달하면 새 연결이 실패합니다. 클라이언트 또는 ElastiCache 측에서 이 제한에 도달했는지 여부를 확인하는 방법에 대한 도움말은 문제 해결 섹션을 참조하세요.
클라이언트 및 ElastiCache 클러스터에 단일 보안 그룹을 동시에 할당하거나 각각에 대해 개별 보안 그룹을 할당할 수 있습니다.
두 경우 모두 소스에서 ElastiCache 포트에 대한 TCP 아웃바운드 트래픽과 동일한 포트의 ElastiCache에 대한 인바운드 트래픽을 허용해야 합니다. 기본 포트는 Memcached의 경우 11211, Valkey 또는 Redis OSS의 경우 6379입니다. 기본적으로 보안 그룹은 모든 아웃바운드 트래픽을 허용합니다. 이 경우 대상 보안 그룹의 인바운드 규칙만 필요합니다.
자세한 내용은 [Amazon VPC에 있는 ElastiCache 클러스터에 액세스하기 위한 액세스 패턴](elasticache-vpc-accessing.md) 섹션을 참조하세요.
## 네트워크 ACL
네트워크 액세스 제어 목록(ACL)은 무상태 규칙입니다. 트래픽이 성공하려면 양방향(인바운드 및 아웃바운드)으로 허용되어야 합니다. 네트워크 ACL은 특정 리소스가 아닌 서브넷에 할당됩니다. ElastiCache 및 클라이언트 리소스에 동일한 ACL을 할당할 수 있습니다(특히 동일한 서브넷에 있는 경우).
기본적으로 네트워크 ACL은 모든 트래픽을 허용합니다. 그러나 트래픽을 거부하거나 허용하도록 네트워크 ACL을 사용자 지정할 수 있습니다. 또한 ACL 규칙의 평가는 순차적입니다. 즉, 트래픽과 일치하는 가장 빠른 번호의 규칙이 트래픽을 허용하거나 거부합니다. Valkey 또는 Redis OSS 트래픽을 허용하는 최소 구성은 다음과 같습니다.
클라이언트 측 네트워크 ACL:
+ **인바운드 규칙:**
+ 규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
+ 유형: 사용자 지정 TCP 규칙
+ 프로토콜: TCP
+ 포트 범위: 1024-65535
+ 소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷에 대한 개별 규칙 생성)
+ 허용/거부: 허용
+ **아웃바운드 규칙:**
+ 규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
+ 유형: 사용자 지정 TCP 규칙
+ 프로토콜: TCP
+ 포트 범위: 6379
+ 소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷. 특정 IP를 사용하면 장애 조치 또는 클러스터 조정 시 문제가 발생할 수 있다는 것에 유념하세요.)
+ 허용/거부: 허용
ElastiCache 네트워크 ACL:
+ **인바운드 규칙:**
+ 규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
+ 유형: 사용자 지정 TCP 규칙
+ 프로토콜: TCP
+ 포트 범위: 6379
+ 소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷에 대한 개별 규칙 생성)
+ 허용/거부: 허용
+ **아웃바운드 규칙:**
+ 규칙 번호: 모든 거부 규칙보다 번호가 작아야 합니다.
+ 유형: 사용자 지정 TCP 규칙
+ 프로토콜: TCP
+ 포트 범위: 1024-65535
+ 소스: 0.0.0.0/0(또는 ElastiCache 클러스터 서브넷. 특정 IP를 사용하면 장애 조치 또는 클러스터 조정 시 문제가 발생할 수 있다는 것에 유념하세요.)
+ 허용/거부: 허용
자세한 내용은 [네트워크 ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)을 참조하세요.
## 라우팅 테이블
네트워크 ACL과 마찬가지로 각 서브넷에는 서로 다른 라우팅 테이블이 있을 수 있습니다. 클라이언트와 ElastiCache 클러스터가 서로 다른 서브넷에 있는 경우 각각의 라우팅 테이블에서 서로 연결할 수 있도록 허용해야 합니다.
여러 VPC, 동적 라우팅 또는 네트워크 방화벽이 관련된 복잡한 환경에서는 문제 해결이 어려울 수 있습니다. [네트워크 연결 검증](#Connectivity) 섹션을 참조하여 네트워크 설정이 적절한지 확인하세요.
## DNS 확인
ElastiCache는 DNS 이름에 기반한 서비스 엔드포인트를 제공합니다. 사용 가능한 엔드포인트는 `Configuration`, `Primary`, `Reader` 및 `Node` 엔드포인트입니다. 자세한 내용은 [연결 엔드포인트 찾기](Endpoints.md)를 참조하세요.
장애 조치 또는 클러스터 수정의 경우 엔드포인트 이름에 연결된 주소가 변경될 수 있으며 자동으로 업데이트됩니다.
사용자 지정 DNS 설정(예: VPC DNS 서비스를 사용하지 않음)은 ElastiCache에서 제공한 DNS 이름을 인식하지 못할 수 있습니다. `dig`(다음에 표시되어 있음) 또는 `nslookup` 같은 시스템 도구를 사용하여 시스템이 ElastiCache 엔드포인트를 성공적으로 확인할 수 있는지 확인합니다.
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4
```
VPC DNS 서비스를 통해 이름 확인을 강제할 수도 있습니다.
```
$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4
```
## 서버 측 진단을 사용하여 문제 식별
ElastiCache 엔진의 CloudWatch 지표 및 런타임 정보는 연결 문제의 잠재적인 원인을 파악하기 위한 일반적인 소스 또는 정보입니다. 좋은 분석은 일반적으로 다음과 같은 항목으로 시작됩니다.
+ CPU 사용량: Valkey 및 Redis OSS는 다중 스레드 애플리케이션입니다. 그러나 각 명령의 실행은 단일(주) 스레드에서 발생합니다. 이러한 이유로 ElastiCache는 `CPUUtilization` 및 `EngineCPUUtilization` 지표를 제공합니다. `EngineCPUUtilization`은 Valkey 또는 Redis OSS 프로세스 전용 CPU 사용률을 제공하고 `CPUUtilization`은 모든 vCPU에 대한 사용량을 제공합니다. 두 개 이상의 vCPU가 있는 노드는 대개 `CPUUtilization` 및 `EngineCPUUtilization`의 값이 서로 다르며, 일반적으로 두 번째 값이 더 큽니다. 높은 `EngineCPUUtilization` 값은 많은 수의 요청이나 완료하는 데 상당한 양의 CPU 시간이 필요한 복잡한 작업으로 인해 발생할 수 있습니다. 다음을 사용하여 둘 모두를 식별할 수 있습니다.
+ 많은 수의 요청: `EngineCPUUtilization` 패턴과 일치하는 다른 지표의 증가 여부를 확인합니다. 유용한 지표는 다음과 같습니다.
+ `CacheHits` 및 `CacheMisses`: 성공한 요청 또는 캐시에서 유효한 항목을 찾지 못한 요청의 수입니다. 적중률에 비해 누락률이 높으면 애플리케이션에서 무의미한 요청에 시간과 리소스를 낭비하고 있는 것입니다.
+ `SetTypeCmds` 및 `GetTypeCmds`: `EngineCPUUtilization`과 상관 관계가 있는 이 두 지표는 `SetTypeCmds`에 의해 측정되는 쓰기 요청 또는 `GetTypeCmds`에 의해 측정되는 읽기 요청에 대한 로드가 얼마나 높은지 파악하는 데 도움이 될 수 있습니다 로드가 주로 읽기인 경우 여러 읽기 전용 복제본을 사용하면 여러 노드에 요청을 분산시켜 균형을 유지하고 프라이머리 노드를 쓰기용으로 할당할 수 있습니다. 클러스터 모드가 비활성화된 클러스터에서는 ElastiCache 리더 엔드포인트를 사용하여 애플리케이션에 추가적인 연결 구성을 생성하여 읽기 전용 복제본을 사용할 수 있습니다. 자세한 내용은 [연결 엔드포인트 찾기](Endpoints.md)를 참조하세요. 읽기 작업은 이 추가 연결에 제출되어야 합니다. 쓰기 작업은 일반적인 기본 엔드포인트를 통해 수행됩니다. 클러스터 모드가 활성화된 클러스터에서는 기본적으로 읽기 전용 복제본을 지원하는 라이브러리를 사용하는 것이 좋습니다. 올바른 플래그를 사용하면 라이브러리가 클러스터 토폴로지와 복제본 노드를 자동으로 검색하고, [READONLY](https://valkey.io/commands/readonly) Valkey 또는 Redis OSS 명령을 통해 읽기 작업을 활성화하고, 복제본에 읽기 요청을 제출할 수 있습니다.
+ 많은 수의 연결:
+ `CurrConnections` 및 `NewConnections`: `CurrConnection`은 데이터 포인트 컬렉션 순간에 설정된 연결 수이고, `NewConnections`는 이 기간에 생성된 연결 수를 보여줍니다.
연결 생성 및 처리에서는 상당한 CPU 오버헤드가 발생합니다. 또한 새 연결을 생성하는 데 필요한 TCP 3방향 핸드셰이크는 전체 응답 시간에 부정적인 영향을 미칩니다.
분당 수천 개의 `NewConnections`가 있는 ElastiCache 노드는 몇 가지 명령에 의해 연결이 생성되고 사용된다는 것을 나타내며, 이는 최적화되지 않은 것입니다. 설정된 연결을 유지하고 새 작업에 이 연결을 다시 사용하는 것이 모범 사례입니다. 이것이 가능하려면 클라이언트 애플리케이션이 연결 풀링이나 영구 연결을 지원하고 적절하게 구현해야 합니다. 연결 풀링을 사용하는 경우 `currConnections` 수에는 큰 변화가 없으며 `NewConnections`는 가능한 낮아야 합니다. Valkey 또는 Redis OSS는 작은 수의 currConnections에서 최적의 성능을 제공합니다. currConnections를 대략 수십 개나 수백 개로 유지하면 클라이언트 버퍼와 같은 개별 연결을 지원하기 위한 리소스 사용량과 연결을 제공하기 위한 CPU 사이클을 최소화할 수 있습니다.
+ 네트워크 처리량:
+ 대역폭 결정: ElastiCache 노드의 네트워크 대역폭은 노드 크기에 비례합니다. 애플리케이션마다 특성이 다르기 때문에 워크로드에 따라 결과가 달라질 수 있습니다. 예를 들어 크기가 작은 요청의 비율이 높은 애플리케이션은 네트워크 처리량보다 CPU 사용량에 더 많은 영향을 미치는 경향이 있으며, 키가 커질수록 네트워크 사용률도 높아집니다. 그러므로 제한을 보다 정확하게 이해하기 위해 실제 워크로드로 노드를 테스트하는 것이 좋습니다.
애플리케이션의 로드를 시뮬레이션하면 보다 정확한 결과를 얻을 수 있습니다. 그러나 벤치마크 도구가 제한에 대한 좋은 아이디어를 줄 수 있습니다.
+ 요청이 주로 읽기인 경우 읽기 작업에 복제본을 사용하면 프라이머리 노드의 로드가 줄어듭니다. 사용 사례가 주로 쓰기인 경우 많은 복제본을 사용하면 네트워크 사용량이 크게 늘어납니다. 프라이머리 노드에 한 바이트가 쓰여질 때마다 N바이트가 복제본으로 전송됩니다. 여기서 N은 복제본 수입니다. 쓰기 집약적인 워크로드에 대한 모범 사례는 클러스터 모드가 활성화된 ElastiCache for Redis OSS를 사용하여 여러 샤드에 걸쳐 쓰기를 분산시키거나 더 많은 네트워크 용량이 있는 노드 유형으로 스케일 업할 수 있도록 하는 것입니다.
+ CloudWatchmetrics `NetworkBytesIn` 및 `NetworkBytesOut`는 각각 노드의 들어오고 나가는 데이터의 양을 제공합니다. `ReplicationBytes`는 데이터 복제 전용 트래픽입니다.
자세한 내용은 [네트워크 관련 제한 사항](#Network-limits) 섹션을 참조하세요.
+ 복잡한 명령: Redis OSS 명령은 단일 스레드에서 제공되므로 요청이 순차적으로 제공됩니다. 단일 느린 명령은 다른 요청 및 연결에 영향을 줄 수 있으며 시간 초과로 이어질 수 있습니다. 여러 값, 키 또는 데이터 유형에 작동하는 명령을 사용할 때 신중하게 사용해야 합니다. 연결은 파라미터의 수나 입력 또는 출력 값의 크기에 따라 차단되거나 종료될 수 있습니다.
악명 높은 예는`KEYS` 명령입니다. 이 명령은 전체 키스페이스에 걸쳐 주어진 패턴을 검색하며, 실행 중에 다른 명령의 실행을 차단합니다. Redis OSS는 “Big O” 표기법을 사용하여 명령의 복잡도를 설명합니다.
Keys 명령은 O(N) 시간 복잡도를 가지며 N은 데이터베이스의 키 수입니다. 따라서 키 수가 클수록 명령 속도가 느려집니다. `KEYS`는 여러 방식으로 문제를 일으킬 수 있습니다. 검색 패턴을 사용하지 않으면 이 명령은 사용 가능한 모든 키 이름을 반환합니다. 수 천개나 수 백만 개의 항목이 있는 데이터베이스에서는 엄청난 출력이 생성되어 네트워크 버퍼가 가득 차게 됩니다.
검색 패턴을 사용하는 경우 패턴과 일치하는 키만 클라이언트로 반환됩니다. 그러나 엔진은 여전히 전체 키스페이스에 걸쳐 키를 검색하며 명령을 완료하는 데 걸리는 시간은 동일합니다.
`KEYS` 명령의 대안은 `SCAN` 명령입니다. 이 명령은 키스페이스를 반복해서 처리하고 특정 수의 항목으로 반복을 제한하여 엔진의 장기적인 차단을 방지합니다.
Scan에는 반복 블록의 크기를 설정하는 데 사용되는 `COUNT` 파라미터가 있습니다. 기본값은 10(반복당 10개 항목)입니다.
데이터베이스의 항목 수에 따라, 작은 `COUNT` 값 블록이 전체 스캔을 완료하는 데 더 많은 반복을 필요로 하며 값이 클수록 각 반복마다 엔진을 더 오래 사용할 수 있습니다. 작은 count 값은 큰 데이터베이스에서 `SCAN` 속도를 느리게 만들며, 값이 클수록 `KEYS`에서 언급한 동일한 문제가 발생할 수 있습니다.
예를 들어, `SCAN` 명령을 count 값 10으로 실행하면 1백만 개의 키가 있는 데이터베이스에서 100,000번의 반복이 필요합니다. 평균 네트워크 왕복 시간이 0.5밀리초인 경우 요청을 전송하는 데 약 50,000밀리초(50초)가 소비됩니다.
반면에 count 값이 100,0000인 경우 단일 반복으로 충분하며 요청을 전송하는 데 단지 0.5밀리초가 소비됩니다. 그러나 명령이 모든 키스페이스의 처리를 마칠 때까지 엔진이 다른 작업에 대해 완전히 차단됩니다.
`KEYS` 외에도, 올바르게 사용하지 않으면 잠재적인 문제를 일으킬 수 있는 여러 다른 명령이 있습니다. 모든 명령의 목록과 각각의 시간 복잡도를 보려면 [Valkey 및 Redis OSS 명령](https://valkey.io/commands)으로 이동하세요.
잠재적 문제의 예:
+ Lua 스크립트: Valkey 및 Redis OSS는 서버 측에서 스크립트를 실행할 수 있도록 임베디드 Lua 인터프리터를 제공합니다. Valkey 및 Redis OSS의 Lua 스크립트는 엔진 수준에서 실행되며 정의에 따라 원자적입니다. 즉, 한 스크립트가 실행되는 동안 다른 명령이나 스크립트가 실행될 수 없습니다. Lua 스크립트는 엔진에서 직접 다중 명령, 의사 결정 알고리즘, 데이터 구문 분석 등을 실행할 수 있는 길을 열어줍니다. 스크립트의 원자성과 애플리케이션을 오프로드할 수 있는 기능은 유혹적이지만 스크립트는 작은 작업에 신중하게 사용해야 합니다. ElastiCache에서 Lua 스크립트의 실행 시간은 5초로 제한됩니다. 키스페이스에 기록되지 않은 스크립트는 5초 후에 자동으로 종료됩니다. 데이터 손상 및 불일치를 방지하기 위해 스크립트 실행이 5초 내에 완료되지 않았고 실행 중에 쓰기가 있는 경우 노드가 장애 조치됩니다. [트랜잭션](https://valkey.io/topics/transactions)은 Redis OSS에서 여러 관련 키 수정 사항의 일관성을 보장하는 다른 방법입니다. 트랜잭션을 사용하면 명령 블록을 실행하여 기존 키의 수정을 감시할 수 있습니다. 트랜잭션이 완료되기 전에 감시된 키가 변경되면 모든 수정 사항이 무시됩니다.
+ 항목의 일괄 삭제: `DEL` 명령에는 삭제할 키 이름에 해당하는 파라미터 여러 개를 사용할 수 있습니다. 삭제 작업은 동기식이며 파라미터 목록이 크거나 큰 목록, 집합, 정렬된 집합 또는 해시(여러 하위 항목을 포함하는 데이터 구조)가 포함된 경우 상당한 CPU 시간을 소비합니다. 즉, 단일 키를 삭제하는 경우에도 요소가 많은 경우 상당한 시간이 걸릴 수 있습니다. `DEL`의 대안은 Redis OSS 4부터 사용할 수 있는 비동기 명령인 `UNLINK`입니다. 가능한 경우 항상 `DEL` 대신 `UNLINK`를 사용해야 합니다. ElastiCache for Redis OSS 6.x부터 `lazyfree-lazy-user-del` 파라미터를 사용하면 `DEL` 명령이 `UNLINK`(활성화된 경우)처럼 작동합니다. 자세한 내용은 [Redis OSS 6.0 파라미터 변경 사항](ParameterGroups.Engine.md#ParameterGroups.Redis.6-x) 섹션을 참조하세요.
+ 여러 키에 작동하는 명령: `DEL`은 이전에 여러 인수를 허용하는 명령으로 언급되었으며 실행 시간은 이에 직접적으로 비례합니다. 그러나 Redis OSS는 유사하게 작동하는 많은 다른 명령을 제공합니다. 예를 들면 `MSET` 및 `MGET`를 사용하면 한 번에 여러 문자열 키를 삽입하거나 검색할 수 있습니다. 이러한 명령을 사용하면 개별 `SET` 또는 `GET` 명령을 여러 번 사용할 때 발생하는 네트워크 대기 시간을 줄일 수 있습니다. 그러나 파라미터의 광범위한 목록은 CPU 사용량에 영향을 미칩니다.
CPU 사용률만으로는 연결 문제의 원인이라고 할 수 없지만 여러 키에 대해 하나 또는 몇 개의 명령을 처리하는 데 너무 많은 시간이 소비되면 다른 요청이 실패하고 전반적인 CPU 사용률이 높아질 수 있습니다.
키의 수와 해당 크기는 명령의 복잡도, 결과적으로 완료 시간에 영향을 미칩니다.
여러 키에 작동할 수 있는 다른 명령의 예에는 `HMGET`, `HMSET`, `MSETNX`, `PFCOUNT`, `PFMERGE`, `SDIFF`, `SDIFFSTORE`, `SINTER`, `SINTERSTORE`, `SUNION`, `SUNIONSTORE`, `TOUCH`, `ZDIFF`, `ZDIFFSTORE`, `ZINTER`, `ZINTERSTORE` 등이 있습니다.
+ 여러 데이터 유형에 작동하는 명령: Redis OSS는 데이터 유형에 관계없이 하나 이상의 키에 작동하는 명령도 제공합니다. ElastiCache for Redis OSS는 이러한 명령을 모니터링하는 `KeyBasedCmds` 지표를 제공합니다. 이 지표는 선택한 기간 동안 다음과 같은 명령의 실행을 합산합니다.
+ O(N) 복잡도:
+ `KEYS`
+ O(1)
+ `EXISTS`
+ `OBJECT`
+ `PTTL`
+ `RANDOMKEY`
+ `TTL`
+ `TYPE`
+ `EXPIRE`
+ `EXPIREAT`
+ `MOVE`
+ `PERSIST`
+ `PEXPIRE`
+ `PEXPIREAT`
+ `UNLINK (O(N)`를 사용하여 메모리를 회수합니다. 그러나 메모리 회수 작업은 분리된 스레드에서 발생하며 엔진을 차단하지 않습니다.
+ 데이터 유형에 따라 복잡도 시간이 다릅니다.
+ `DEL`
+ `DUMP`
+ `RENAME`은 복잡도가 O(1)인 명령으로 간주되지만 내부적으로 `DEL`을 실행합니다. 실행 시간은 이름이 바뀐 키의 크기에 따라 달라집니다.
+ `RENAMENX`
+ `RESTORE`
+ `SORT`
+ 큰 해시: 해시는 여러 키-값 하위 항목이 있는 단일 키를 허용하는 데이터 유형입니다. 각 해시는 4,294,967,295개 항목을 저장할 수 있으며 큰 해시에 대한 작업은 비용이 많이 들 수 있습니다. `KEYS`와 유사하게, 해시에는 O(N) 시간 복잡도를 갖는 `HKEYS` 명령이 있으며, N은 해시의 항목 수입니다. 장기 실행 명령을 방지하려면 `HKEYS` 대신 `HSCAN`을 사용해야 합니다. `HDEL`, `HGETALL`, `HMGET`, `HMSET` 및 `HVALS`는 큰 해시에서 주의해서 사용해야 하는 명령입니다.
+ 기타 빅 데이터 구조: 해시 외에도 다른 데이터 구조가 CPU 집약적일 수 있습니다. 집합, 목록, 정렬된 집합 및 Hyperloglog는 크기와 사용된 명령에 따라 처리하는 데 상당한 시간이 걸릴 수 있습니다. 이러한 명령에 대한 자세한 내용은 [Valkey 및 Redis OSS 명령](https://valkey.io/commands)을 참조하세요.
## 네트워크 연결 검증
DNS 확인, 보안 그룹, 네트워크 ACL 및 라우팅 테이블과 관련된 네트워크 구성을 검토한 후 VPC Reachability Analyzer 및 시스템 도구를 사용하여 연결을 검증할 수 있습니다.
Reachability Analyzer는 네트워크 연결을 테스트하고 모든 요구 사항 및 권한이 충족되는지 확인합니다. 아래 테스트를 수행하려면 VPC에서 사용 가능한 ElastiCache 노드 중 하나의 탄력적 네트워크 인터페이스 ID(ENI ID)가 필요합니다. 다음을 수행하여 이 ID를 찾을 수 있습니다.
1. [https://console.aws.amazon.com/ec2/v2/home?\$1NIC](https://console.aws.amazon.com/ec2/v2/home?#NIC)로 이동합니다.
1. ElastiCache 클러스터 이름 또는 이전에 DNS 유효성 검사에서 얻은 IP 주소를 기준으로 인터페이스 목록을 필터링합니다.
1. ENI ID를 적어 두거나 따로 저장하세요. 여러 인터페이스가 표시되는 경우 설명을 검토하여 해당 인터페이스가 올바른 ElastiCache 클러스터에 속하는지 확인하고 그 중 하나를 선택합니다.
1. 다음 단계를 진행합니다.
1. [https://console.aws.amazon.com/vpc/home?\$1ReachabilityAnalyzer](https://console.aws.amazon.com/vpc/home?#ReachabilityAnalyzer)에서 분석 경로를 생성하고 다음 옵션을 선택합니다.
+ **소스 유형**: ElastiCache 클라이언트가 Amazon EC2 인스턴스에서 실행되는 경우 **인스턴스**를 선택하고, AWS Fargate Amazon ECS와 awsvpc 네트워크, AWS Lambda 등과 같은 다른 서비스를 사용하는 경우 **네트워크 인터페이스** 및 해당 리소스 ID(EC2 인스턴스 또는 ENI ID)를 선택합니다.
+ **대상 유형**: **네트워크 인터페이스**를 선택하고 목록에서 **ElastiCache ENI**를 선택합니다.
+ **대상 포트**: ElastiCache for Redis OSS의 경우 6379 또는 ElastiCache for Memcached의 경우 11211을 입력합니다. 이러한 포트는 기본 구성으로 정의된 포트이며 이 예에서는 포트가 변경되지 않는다고 가정합니다.
+ **프로토콜**: TCP
분석 경로를 생성하고 결과를 몇 분 정도 기다립니다. 상태가 연결할 수 없음인 경우 분석 세부 정보를 열고 **분석 탐색기**에서 요청이 차단된 위치에 대한 자세한 정보를 검토합니다.
연결성 테스트가 통과되면 OS 수준에서 확인을 진행합니다.
Amazon Linux에서 ElastiCache 서비스 포트의 TCP 연결성을 검증하려면 `nmap` 패키지에서 사용할 수 있는 `Nping`을 사용하여 ElastiCache 포트에서 TCP 연결성을 테스트할 수 있을 뿐만 아니라 연결 설정에 걸리는 네트워크 왕복 시간도 얻을 수 있습니다. 다음과 같이 이 명령을 사용하여 ElastiCache 클러스터에 대한 네트워크 연결성 및 현재 대기 시간을 검증합니다.
```
$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )
Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds
```
기본적으로, `nping`은 5개의 프로브를 사이에 1초의 지연 시간을 두어 전송합니다. “-c” 옵션을 사용하여 프로브 수를 늘리고 “--delay“ 옵션을 사용하여 새 테스트를 전송하는 시간을 변경할 수 있습니다.
`nping`을 사용하는 테스트는 실패하고 *VPC Reachability Analyzer* 테스트는 통과한다면 시스템 관리자에게 가능한 호스트 기반 방화벽 규칙, 비대칭 라우팅 규칙 또는 운영 체제 수준의 다른 모든 가능한 제한을 검토하도록 요청하세요.
ElastiCache 콘솔을 통해 ElastiCache 클러스터 세부 정보에서 **전송 중 데이터 암호화**가 활성화되어 있는지 확인합니다. 전송 중 암호화가 활성화되어 있으면 다음 명령을 사용하여 TLS 세션을 설정할 수 있는지 확인합니다.
```
openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379
```
연결 및 TLS 협상이 성공하면 많은 출력이 나타날 수 있습니다. 마지막 줄에서 사용할 수 있는 반환 코드를 확인하세요. 값이 `0 (ok)`여야 합니다. openssl이 다른 값을 반환하면 [https://www.openssl.org/docs/man1.0.2/man1/verify.html\$1DIAGNOSTICS](https://www.openssl.org/docs/man1.0.2/man1/verify.html#DIAGNOSTICS)에서 오류의 원인을 확인하세요.
모든 인프라 및 운영 체제 테스트를 통과했지만 애플리케이션이 여전히 ElastiCache에 연결할 수 없는 경우 애플리케이션 구성이 ElastiCache 설정을 준수하는지 확인합니다. 일반적인 실수는 다음과 같습니다.
+ 애플리케이션이 ElastiCache 클러스터 모드를 지원하지 않으며 ElastiCache는 클러스터 모드가 활성화되어 있습니다.
+ 애플리케이션이 TLS/SSL을 지원하지 않으며 ElastiCache는 전송 중 데이터 암호화가 활성화되어 있습니다.
+ 애플리케이션은 TLS/SSL을 지원하지만 올바른 구성 플래그 또는 신뢰할 수 있는 인증 기관이 없습니다.
## 네트워크 관련 제한 사항
+ 최대 연결 수: 동시 연결에 대한 하드 제한이 있습니다. 각 ElastiCache 노드는 모든 클라이언트에서 최대 65,000개의 동시 연결을 허용합니다. 이 제한은 CloudWatch에서 `CurrConnections` 지표를 통해 모니터링할 수 있습니다. 그러나 클라이언트에는 아웃바운드 연결에 대한 제한이 있습니다. Linux의 경우 다음 명령을 사용하여 허용된 휘발성 포트 범위를 확인하세요.
```
# sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999
```
이전 예에서 동일한 소스에서 동일한 대상 IP(ElastiCache 노드) 및 포트로 28231개 연결이 허용됩니다. 다음 명령은 특정 ElastiCache 노드(IP 1.2.3.4)에 존재하는 연결 수를 보여 줍니다.
```
ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l
```
숫자가 너무 높으면 연결 요청을 처리하는 동안 시스템에 과부하가 걸릴 수 있습니다. 연결 처리를 개선하려면 연결 풀링이나 지속적인 연결과 같은 기술을 구현하는 것이 좋습니다. 가능한 경우 항상 연결 풀을 구성하여 최대 연결 수를 수백 개로 제한합니다. 또한 문제가 발생할 경우 연결 이탈을 방지하려면 시간 초과 또는 기타 연결 예외를 처리하는 백오프 로직이 필요합니다.
+ 네트워크 트래픽 제한: 다음과 같은 [Redis OSS의 CloudWatch 지표](CacheMetrics.Redis.md)를 확인하여 ElastiCache 노드에서 발생할 수 있는 네트워크 제한을 식별합니다.
+ `NetworkBandwidthInAllowanceExceeded`/`NetworkBandwidthOutAllowanceExceeded`: 처리량이 집계된 대역폭 제한을 초과하여 형성된 네트워크 패킷입니다.
프라이머리 노드에 한 바이트가 쓰여질 때마다 N개 복제본으로 복제됩니다. 여기서 N은 복제본 수입니다. 노드 유형이 작고, 여러 개의 복제본이 있으며 많은 쓰기 요청이 있는 클러스터는 복제 백로그를 처리하지 못할 수 있습니다. 이러한 경우 확장(노드 유형 변경), 스케일 아웃(클러스터 모드가 활성화된 클러스터에 샤드 추가), 복제본 수를 줄이기 또는 쓰기 수 최소화를 수행하는 것이 모범 사례입니다.
+ `NetworkConntrackAllowanceExceeded`: 노드에 할당된 모든 보안 그룹에서 추적되는 최대 연결 수를 초과했기 때문에 형성되는 패킷입니다. 이 기간 동안 새 연결이 실패할 가능성이 높습니다.
+ `NetworkPackets PerSecondAllowanceExceeded`: 초당 최대 패킷 수를 초과했습니다. 매우 크기가 작은 요청의 비율이 높은 워크로드는 최대 대역폭 전에 이 제한에 도달할 수 있습니다.
위의 지표는 네트워크 제한에 도달한 노드를 확인하는 이상적인 방법입니다. 그러나 제한은 네트워크 지표의 안정기로 식별할 수도 있습니다.
안정기가 오랜 기간 동안 관찰되면 이후에 복제 지연, 캐시에 사용되는 바이트 수 증가, 여유 메모리 하락, 높은 스왑 및 CPU 사용량이 뒤따를 가능성이 높습니다. 또한 Amazon EC2 인스턴스에는 [ENA 드라이버 지표](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html)를 통해 추적할 수 있는 네트워크 제한이 있습니다. 향상된 네트워킹 지원과 ENA 드라이버 2.2.10 이상을 사용하는 Linux 인스턴스에서는 다음 명령을 사용하여 제한 카운터를 검토할 수 있습니다.
```
# ethtool -S eth0 | grep "allowance_exceeded"
```
## CPU 사용량
CPU 사용량 지표는 조사의 시작점이며, 다음과 같은 항목은 ElastiCache 측에서 발생할 수 있는 문제의 범위를 좁히는 데 도움이 될 수 있습니다.
+ Redis OSS SlowLogs: ElastiCache 기본 구성은 완료하는 데 10밀리초 이상 걸린 마지막 128개 명령을 유지합니다. 느린 명령의 기록은 엔진 런타임 중에 유지되며 실패나 재시작 시 손실됩니다. 목록이 128개 항목에 도달하면 새 이벤트를 위한 공간을 확보하기 위해 이전 이벤트가 제거됩니다. 느린 이벤트 목록의 크기와 느린 것으로 간주되는 실행 시간은 [사용자 지정 파라미터 그룹](ParameterGroups.md)에서 `slowlog-max-len` 및 `slowlog-log-slower-than` 파라미터를 통해 수정할 수 있습니다. 슬로우 로그 목록을 검색하려면 엔진에 대해 `SLOWLOG GET 128`을 실행합니다. 여기서 128은 마지막 128개의 느린 명령을 보고합니다. 각 항목에는 다음과 같은 필드가 있습니다.
```
1) 1) (integer) 1 -----------> Sequential ID
2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
3) (integer) 4823378 -----> Time in microseconds to complete the command.
4) 1) "keys" -------------> Command
2) "*" ----------------> Arguments
5) "1.2.3.4:57004"-> Source
```
위의 이벤트는 UTC 기준으로 12월 26일 19:26:07에 발생했고 완료하는 데 4.8초(4,823밀리초)가 걸렸으며 클라이언트 1.2.3.4에서 요청된 `KEYS` 명령에 의해 발생했습니다.
Linux에서 타임스탬프를 date 명령으로 변환할 수 있습니다.
```
$ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020
```
Python 사용:
```
>>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)
```
또는 PowerShell 사용하여 Windows에서:
```
PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime : 12/26/2020 7:26:07 PM
UtcDateTime
: 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date : 12/26/2020 12:00:00 AM
Day : 26
DayOfWeek
: Saturday
DayOfYear : 361
Hour : 19
Millisecond : 0
Minute : 26
Month
: 12
Offset : 00:00:00Ticks : 637446075670000000
UtcTicks
: 637446075670000000
TimeOfDay : 19:26:07
Year : 2020
```
짧은 시간(1분 이하) 동안 발생한 많은 느린 명령이 우려의 이유입니다. 명령의 특성과 명령을 최적화할 수 있는 방법을 검토합니다(이전 예제 참조). O(1) 시간 복잡도가 있는 명령이 자주 보고되는 경우 앞서 언급한 높은 CPU 사용량에 대한 다른 요인을 확인하세요.
+ 대기 시간 지표: ElastiCache for Redis OSS는 다양한 종류의 명령에 대한 평균 대기 시간을 모니터링하는 CloudWatch 지표를 제공합니다. 데이터 포인트는 한 범주에 속하는 명령의 총 실행 횟수를 해당 기간의 총 실행 시간으로 나누어 계산합니다. 대기 시간 지표의 결과는 여러 명령의 집계임을 이해하는 것이 중요합니다. 단일 명령을 사용하면 지표에 큰 영향을 주지 않으며 시간 초과와 같은 예기치 않은 결과가 발생할 수 있습니다. 이러한 경우 느리 로그 이벤트가 보다 정확한 정보 소스가 될 수 있습니다. 다음 목록에는 사용 가능한 대기 시간 지표와 이에 영향을 주는 각 명령이 나와 있습니다.
+ EvalBasedCmdsLatency: Lua 스크립트 명령 `eval`, `evalsha`와 관련이 있습니다.
+ GeoSpatialBasedCmdsLatency:`geodist` ,`geohash` ,`geopos` ,`georadius` ,`georadiusbymember` ,`geoadd`
+ GetTypeCmdsLatency: 데이터 유형이 관계없이 읽기 명령
+ HashBasedCmdsLatency:`hexists` ,`hget` ,`hgetall` ,`hkeys` ,`hlen` ,`hmget` ,`hvals` ,`hstrlen` ,`hdel` ,`hincrby` ,`hincrbyfloat` ,`hmset` ,`hset` ,`hsetnx`
+ HyperLogLogBasedCmdsLatency:`pfselftest` ,`pfcount` ,`pfdebug` ,`pfadd` ,`pfmerge`
+ KeyBasedCmdsLatency: 서로 다른 데이터 유형에서 작동할 수 있는 명령:`dump` ,`exists` ,`keys` ,`object` ,`pttl` ,`randomkey` ,`ttl` ,`type` ,`del` ,`expire` ,`expireat` ,`move` ,`persist` ,`pexpire` ,`pexpireat` ,`rename` ,`renamenx` ,`restoreK` ,`sort` ,`unlink`
+ ListBasedCmdsLatency: lindex, llen, lrange, blpop, brpop, brpoplpush, linsert, lpop, lpush, lpushx, lrem, lset, ltrim, rpop, rpoplpush, rpush, rpushx
+ PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe
+ SetBasedCmdsLatency:`scard` ,`sdiff` ,`sinter` ,`sismember` ,`smembers` ,`srandmember` ,`sunion` ,`sadd` ,`sdiffstore` ,`sinterstore` ,`smove` ,`spop` ,`srem` ,`sunionstore`
+ SetTypeCmdsLatency: 데이터 유형에 관계없이 쓰기 명령
+ SortedSetBasedCmdsLatency:`zcard` ,`zcount` ,`zrange` ,`zrangebyscore` ,`zrank` ,`zrevrange` ,`zrevrangebyscore` ,`zrevrank` ,`zscore` ,`zrangebylex` ,`zrevrangebylex` ,`zlexcount` ,`zadd` .`zincrby` ,`zinterstore` ,`zrem` ,`zremrangebyrank` ,`zremrangebyscore` ,`zunionstore` ,`zremrangebylex` ,`zpopmax` ,`zpopmin` ,`bzpopmin` ,`bzpopmax`
+ StringBasedCmdsLatency:`bitcount` ,`get` ,`getbit` ,`getrange` ,`mget` ,`strlen` ,`substr` ,`bitpos` ,`append` ,`bitop` ,`bitfield` ,`decr` ,`decrby` ,`getset` ,`incr` ,`incrby` ,`incrbyfloat` ,`mset` ,`msetnx` ,`psetex` ,`set` ,`setbit` ,`setex` ,`setnx` ,`setrange`
+ StreamBasedCmdsLatency:`xrange` ,`xrevrange` ,`xlen` ,`xread` ,`xpending` ,`xinfo` ,`xadd` ,`xgroup` ,`readgroup` ,`xack` ,`xclaim` ,`xdel` ,`xtrim` ,`xsetid`
+ Redis OSS 런타임 명령:
+ info commandstats: 엔진이 시작된 이후 실행된 명령, 누적 실행 횟수, 총 실행 시간 및 명령당 평균 실행 시간으로 구성된 목록을 제공합니다.
+ client list: 현재 연결된 클라이언트와 버퍼 사용량, 마지막으로 실행된 명령 등과 같은 관련 정보의 목록을 제공합니다.
+ 백업 및 복제: 2.8.22 이전 버전의 ElastiCache for Redis OSS에서는 forked 프로세스를 사용하여 백업을 생성하고 복제본과의 전체 동기화를 처리합니다. 이 방법은 쓰기 집약적인 사용 사례에서 상당한 메모리 오버헤드가 발생시킬 수 있습니다.
ElastiCache Redis OSS 2.8.22부터, AWS에 forkless 백업 및 복제 방법이 도입되었습니다. 새로운 방법은 실패를 방지하기 위해 쓰기를 지연시킬 수 있습니다. 두 방법 모두 CPU 사용률을 높일 수 있고 응답 시간이 길어지게 만들 수 있으므로 실행 중에 클라이언트 시간 초과가 발생할 수 있습니다. 백업 기간 중에 클라이언트 장애가 발생하거나 이 기간 중에 `SaveInProgress` 지표가 1이었는지 항상 확인하세요. 클라이언트 문제 또는 백업 실패의 가능성을 최소화하기 위해 사용률이 낮은 기간으로 백업 기간을 예약하는 것이 좋습니다.
## 서버 측에서 연결이 종료되는 경우
기본 ElastiCache for Redis OSS 구성은 클라이언트 연결을 무기한 유지합니다. 그러나 경우에 따라 연결 종료가 필요할 수 있습니다. 예:
+ 클라이언트 애플리케이션의 버그로 인해 연결이 손실되고 유휴 상태로 설정이 유지될 수 있습니다. 이것을 “연결 누수“라고 하며 결과적으로 `CurrConnections` 지표에서 관찰되는 설정된 연결의 수가 지속적으로 증가합니다. 이 동작으로 인해 클라이언트 또는 ElastiCache 측에서 포화가 발생할 수 있습니다. 클라이언트 측에서 즉시 수정할 수 없는 경우 일부 관리자는 ElastiCache 파라미터 그룹에 ”시간 초과“ 값을 설정합니다. 시간 초과는 유휴 연결이 지속되도록 허용된 기간(초)입니다. 클라이언트가 이 기간 동안 요청을 제출하지 않으면 엔진은 연결이 시간 초과 값에 도달하는 즉시 연결을 종료합니다. 시간 초과 값이 작으면 불필요한 연결 끊기가 발생할 수 있으며 클라이언트가 연결을 올바르게 처리하고 다시 연결해야 하므로 지연이 발생합니다.
+ 키를 저장하는 데 사용되는 메모리는 클라이언트 버퍼와 공유됩니다. 크기가 큰 요청이나 응답이 있는 느린 클라이언트는 버퍼를 처리하기 위해 상당한 양의 메모리를 요구할 수 있습니다. 기본 ElastiCache for Redis OSS 구성은 일반 클라이언트 출력 버퍼의 크기를 제한하지 않습니다. `maxmemory` 제한에 도달하면 엔진은 버퍼 사용량을 충족하기 위해 항목을 제거하려고 시도합니다. 메모리 극히 부족한 상황에서 ElastiCache for Redis OSS는 메모리를 확보하고 클러스터의 상태를 유지하기 위해 선택적으로 대용량 클라이언트 출력 버퍼를 사용하는 클라이언트의 연결을 끊을 수 있습니다.
사용자 지정 구성으로 클라이언트 버퍼의 크기를 제한할 수 있으며 이 제한에 도달한 클라이언트는 연결이 끊어집니다. 그러나 클라이언트는 예기치 않은 연결 해제를 처리할 수 있어야 합니다. 일반 클라이언트의 버퍼 크기를 처리하는 파라미터는 다음과 같습니다.
+ client-query-buffer-limit: 단일 입력 요청의 최대 크기
+ client-output-buffer-limit-normal-soft-limit: 클라이언트 연결에 대한 소프트 제한. 연결이 client-output-buffer-limit-normal-soft-seconds에 정의된 시간(초)보다 오래 소프트 제한을 초과하거나 하드 제한에 도달하는 경우 연결이 종료됩니다.
+ client-output-buffer-limit-normal-soft-seconds: 연결이 client-output-buffer-limit-normal-soft-limit을 초과하도록 허용되는 시간
+ client-output-buffer-limit-normal-hard-limit: 이 제한에 도달하는 연결은 즉시 종료됩니다.
일반 클라이언트 버퍼 외에도, 다음 옵션은 복제본 노드 및 Pub/Sub(게시/구독) 클라이언트에 대한 버퍼를 제어합니다.
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-replica-soft-seconds;
+ client-output-buffer-limit-replica-hard-limit;
+ client-output-buffer-limit-pubsub-soft-limit;
+ client-output-buffer-limit-pubsub-soft-seconds;
+ client-output-buffer-limit-pubsub-hard-limit;
## Amazon EC2 인스턴스에 대한 클라이언트 측 문제 해결
클라이언트 측의 로드 및 응답성은 ElastiCache에 대한 요청에도 영향을 줄 수 있습니다. 간헐적인 연결성 또는 시간 초과 문제를 해결하는 동안 EC2 인스턴스 및 운영 체제 제한을 신중하게 검토해야 합니다. 관찰할 몇 가지 핵심 사항:
+ CPU:
+ EC2 인스턴스 CPU 사용량: CPU가 포화되거나 100%에 가까워지지 않았는지 확인합니다. 기간별 분석은 CloudWatch를 통해 수행할 수 있지만 데이터 포인터의 세분성은 1분(세부 모니터링이 활성화된 경우) 또는 5분입니다.
+ [버스트 가능 EC2 인스턴스](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html)를 사용하는 경우 CPU 크레딧 밸런스가 고갈되지 않았는지 확인하세요. 이 정보는 `CPUCreditBalance` CloudWatch 지표에서 사용할 수 있습니다.
+ 짧은 기간 동안의 높은 CPU 사용량이 CloudWatch에서 100% 사용률을 표시하지 않고 시간 초과를 발생시킬 수 있습니다. 이러한 경우에는 `top`, `ps` 및 `mpstat` 같은 운영 체제 도구를 사용하여 실시간 모니터링을 수행해야 합니다.
+ Network
+ 네트워크 처리량이 인스턴스 용량에 따라 허용 가능한 값 이하인지 확인합니다. 자세한 내용은 [Amazon EC2인스턴스 유형](https://aws.amazon.com/ec2/instance-types/) 참조
+ `ena` Enhanced Network 드라이버를 사용하는 인스턴스의 경우 [ena statistics](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/troubleshooting-ena.html#statistics-ena)에서 시간 초과 또는 제한 초과를 확인합니다. 다음 통계는 네트워크 제한 도달 상태를 확인하는 데 유용합니다.
+ `bw_in_allowance_exceeded`/`bw_out_allowance_exceeded`: 과도한 인바운드 또는 아웃바운드 처리량으로 인해 형성된 패킷 수
+ `conntrack_allowance_exceeded`: 보안 그룹 [연결 추적 제한](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html#connection-tracking-throttling)으로 인해 삭제된 패킷 수. 이 제한에 도달하면 새 연결이 실패합니다.
+ `linklocal_allowance_exceeded`: 인스턴스 메타 데이터, VPC DNS를 통한 NTP에 대한 과도한 요청으로 인해 손실된 패킷 수. 이 제한은 모든 서비스에 대해 초당 1024패킷입니다.
+ `pps_allowance_exceeded`: 과도한 초당 패킷 수 비율로 인해 손실된 패킷 수. 네트워크 트래픽이 초당 수천 또는 수백만 개의 매우 작은 요청으로 구성된 경우 PPS 제한에 도달할 수 있습니다. ElastiCache 트래픽은 `GET`이 아니라 `MGET` 같이 여러 작업을 동시에 수행하는 파이프라인 또는 명령을 통해 네트워크 패킷을 효율적으로 사용하도록 최적화할 수 있습니다.
## 단일 요청을 완료하는 데 걸리는 시간 분석
+ 네트워크에서 `Tcpdump` 및 `Wireshark`(명령줄의 tshark)는 요청이 네트워크를 이동하여 ElastiCache 엔진에 도달하고 반환되는 데 걸리는 시간을 파악할 수 있는 편리한 도구입니다. 다음 예제에서는 다음과 같은 명령을 사용하여 생성한 단일 요청을 강조 표시합니다.
```
$ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG
```
위의 명령과 병행하여 tcpdump가 실행 중이었고 반환되었습니다.
```
$ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
> 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
```
위의 출력에서 TCP 3방향 핸드셰이크가 완료되는 데 222마이크로초(918091 - 917869)가 걸렸고 ping 명령이 제출되어 반환되는 데 173마이크로초(918295 - 918122)가 걸렸음을 확인할 수 있습니다.
요청부터 연결을 닫는 데까지 438마이크로초(918307 - 917869)가 걸렸습니다. 이러한 결과를 통해 네트워크 및 엔진 응답 시간이 양호하다고 확신할 수 있으며 조사를 다른 구성 요소에 집중할 수 있습니다.
+ 운영 체제에서 `Strace`를 사용하여 OS 수준의 시간 간격을 식별할 수 있습니다. 실제 애플리케이션의 분석에는 보다 광범위하고 전문화된 애플리케이션 프로파일러 또는 디버거를 사용하는 것이 좋습니다. 다음 예제에서는 기본 운영 체제 구성 요소가 예상대로 작동하는지 여부만 보여 주며, 예상대로 작동하지 않는 경우 추가 조사가 필요할 수 있습니다. `strace`와 함께 동일한 Redis OSS `PING` 명령을 사용하여 얻은 결과:
```
$ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
(+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
(+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
(+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
(Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
(+ 0.003569) +++ exited with 0 +++
```
위의 예제에서 명령을 완료하는 데 54밀리초 이상이 걸렸습니다(752110 - 697712 = 54398마이크로초).
nc를 인스턴스화하고 이름을 확인하는 데 약 20밀리초(697712에서 717890)의 상당한 시간이 걸렸으며, 그 후에 TCP 소켓을 생성하는 데 2밀리초(745659에서 747858), 요청을 제출하고 응답을 받는 데 0.4밀리초(747858에서 748330)가 필요했습니다.
## 관련 항목
+ [ElastiCache 모범 사례 및 캐싱 전략](BestPractices.md)