기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
ElastiCache를 사용한 일반적인 문제 해결 단계 및 모범 사례
다음 주제에서는 ElastiCache를 사용할 때 발생할 수 있는 오류 및 문제에 대한 문제 해결 조언을 제공합니다. 여기에 나열되지 않은 문제를 발견하는 경우 이 페이지의 피드백 버튼을 사용하여 해당 문제를 보고할 수 있습니다.
문제 해결 조언과 일반적인 지원 질문에 대한 답변은 AWS 지식 센터
주제
연결 문제
ElastiCache 캐시에 연결할 수 없는 경우 다음 중 하나를 고려하세요.
TLS 사용: ElastiCache 엔드포인트에 연결하려고 할 때 연결이 끊긴 경우 클라이언트에서 TLS를 사용하지 않을 수 있습니다. ElastiCache 서버리스를 사용하는 경우 전송 중 암호화가 항상 활성화됩니다. 클라이언트가 TLS를 사용하여 캐시에 연결하는지 확인합니다. TLS 지원 캐시에 연결하는 방법에 대해 자세히 알아보세요.
VPC: ElastiCache 캐시는 VPC 내에서만 액세스할 수 있습니다. 캐시에 액세스하는 EC2 인스턴스와 ElastiCache 캐시가 동일한 VPC에 생성되었는지 확인합니다. 또는 EC2 인스턴스가 있는 VPC와 캐시를 생성하는 VPC 간에 VPC 피어링을 활성화해야 합니다.
보안 그룹: ElastiCache는 보안 그룹을 사용하여 캐시에 대한 액세스를 제어합니다. 다음을 고려하세요.
ElastiCache 캐시에서 사용하는 보안 그룹이 EC2 인스턴스에서 인바운드 액세스를 허용하는지 확인합니다. 보안 그룹에서 인바운드 규칙을 올바르게 설정하는 방법은 여기를 참조하세요.
ElastiCache 캐시에서 사용하는 보안 그룹이 캐시 포트에 대한 액세스를 허용하는지 확인합니다(서버리스의 경우 6379 및 6380, 자체 설계된 경우 기본적으로 6379). ElastiCache는 이러한 포트를 사용하여 Valkey 또는 Redis OSS 명령을 수락합니다. 포트 액세스를 설정하는 방법에 대한 자세한 내용은 여기에서 확인하세요.
연결이 계속 어려운 경우 다른 단계는 지속적인 연결 문제 섹션을 참조하세요.
Valkey 또는 Redis OSS 클라이언트 오류
ElastiCache 서버리스는 Valkey 또는 Redis OSS 클러스터 모드 프로토콜을 지원하는 클라이언트를 통해서만 액세스할 수 있습니다. 자체 설계된 클러스터는 클러스터 구성에 따라 어느 모드에서든 클라이언트에서 액세스할 수 있습니다.
클라이언트에 오류가 발생하는 경우 다음을 고려하세요.
클러스터 모드: SELECT
명령에서 CROSSLOT 오류 또는 오류가 발생하는 경우 클러스터 프로토콜을 지원하지 않는 Valkey 또는 Redis OSS 클라이언트를 사용하여 클러스터 모드 활성화 캐시에 액세스하려고 할 수 있습니다. ElastiCache 서버리스는 Valkey 또는 Redis OSS 클러스터 프로토콜을 지원하는 클라이언트만 지원합니다. “클러스터 모드 비활성화”(CMD)에서 Valkey 또는 Redis OSS를 사용하려면 자체 클러스터를 설계해야 합니다. CROSSLOT 오류:
ERR CROSSLOT Keys in request don't hash to the same slot오류가 발생하는 경우 클러스터 모드 캐시의 동일한 슬롯에 속하지 않는 키에 액세스하려고 할 수 있습니다. ElastiCache 서버리스는 항상 클러스터 모드에서 작동합니다. 여러 키를 포함하는 다중 키 작업, 트랜잭션 또는 Lua 스크립트는 관련된 모든 키가 동일한 해시 슬롯에 있는 경우에만 허용됩니다.
Valkey 또는 Redis OSS 클라이언트 구성에 대한 추가 모범 사례는 이 블로그 게시물
ElastiCache 서버리스의 지연 시간 문제 해결
워크로드의 지연 시간이 길면 CloudWatch SuccessfulReadRequestLatency 및 SuccessfulWriteRequestLatency 지표를 분석하여 지연 시간이 ElastiCache 서버리스와 관련이 있는지 확인할 수 있습니다. 이러한 지표는 ElastiCache 서버리스의 내부인 지연 시간을 측정합니다. 클라이언트 측 지연 시간과 클라이언트와 ElastiCache 서버리스 엔드포인트 간의 네트워크 트립 시간은 포함되지 않습니다.
클라이언트 측 지연 시간 문제 해결
클라이언트 측 지연 시간은 증가했지만 서버 측 지연 시간을 측정하는 CloudWatch SuccessfulReadRequestLatency 및 SuccessfulWriteRequestLatency 지표에는 그에 상응하는 증가가 없는 경우 다음을 고려하세요.
보안 그룹이 포트 6379 및 6380에 대한 액세스를 허용하는지 확인합니다. ElastiCache 서버리스는 기본 엔드포인트에 6379 포트를 사용하고 리더 엔드포인트에 6380 포트를 사용합니다. 일부 클라이언트는 애플리케이션이 복제본에서 읽기 기능을 사용하지 않더라도 모든 새 연결에 대해 두 포트에 대한 연결을 설정합니다. 보안 그룹에서 두 포트에 대한 인바운드 액세스를 허용하지 않으면 연결 설정이 더 오래 걸릴 수 있습니다. 포트 액세스를 설정하는 방법에 대한 자세한 내용은 여기에서 확인하세요.
서버 측 지연 시간 문제 해결
일부 변동성 및 간헐적 급증은 걱정할 필요가 없습니다. 그러나 Average 통계가 급격히 증가하여 지속되면 AWS 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~12분이 걸립니다.
장기 실행 명령 검사: Lua 스크립트 또는 대규모 데이터 구조의 명령을 포함한 일부 Valkey 또는 Redis OSS 명령이 장시간 실행될 수 있습니다. 이러한 명령을 식별하기 위해 ElastiCache는 명령 수준 지표를 게시합니다. ElastiCache 서버리스를 사용하면
BasedECPUs지표를 사용할 수 있습니다.제한된 요청: ElastiCache 서버리스에서 요청이 제한되면 애플리케이션에서 클라이언트 측 지연 시간이 증가할 수 있습니다. ElastiCache 서버리스에서 요청이 제한되면
ThrottledRequestsElastiCache 서버리스 지표가 증가하는 것을 볼 수 있습니다. 제한된 요청 문제를 해결하려면 아래 섹션을 검토하세요.키 및 요청의 균일한 배포: Valkey 및 Redis OSS용 ElastiCache에서 슬롯당 키 또는 요청이 고르지 않게 배포되면 핫 슬롯이 발생하여 지연 시간이 길어질 수 있습니다. ElastiCache 서버리스는 간단한 SET/GET 명령을 실행하는 워크로드에서 단일 슬롯에서 초당 최대 30,000ECPUs(복제본에서 읽기 사용 시 초당 90,000개의 ECPU)를 지원합니다. 슬롯 간 키 및 요청 배포를 평가하고 요청 속도가 이 제한을 초과하는 경우 균일한 배포를 확인하는 것이 좋습니다.
ElastiCache 서버리스의 스로틀링 문제 해결
서비스 지향 아키텍처 및 분산 시스템에서는 다양한 서비스 구성 요소가 API 호출을 처리하는 속도를 제한하는 것을 제한이라고 합니다. 이를 통해 급증을 완화하고 구성 요소 처리량 불일치를 제어하며 예상치 못한 운영 이벤트가 발생했을 때 보다 예측 가능한 복구를 수행할 수 있습니다. ElastiCache 서버리스는 이러한 유형의 아키텍처를 위해 설계되었으며 대부분의 Valkey 또는 Redis OSS 클라이언트에는 제한된 요청에 대한 재시도가 내장되어 있습니다. 어느 정도의 제한이 애플리케이션에 반드시 문제가 되는 것은 아니지만 데이터 워크플로의 지연 시간에 민감한 부분을 지속적으로 제한하면 사용자 경험에 부정적인 영향을 미치고 시스템의 전반적인 효율성이 떨어질 수 있습니다.
ElastiCache 서버리스에서 요청이 제한되면 ThrottledRequests ElastiCache 서버리스 지표가 증가하는 것을 볼 수 있습니다. 제한된 요청 수가 많을 경우 다음을 고려하세요.
규모 조정 속도: ElastiCache 서버리스는 더 많은 데이터를 수집하거나 요청 속도를 높일 때 자동으로 규모가 조정됩니다. ElastiCache 서버리스가 규모를 조정하는 속도보다 애플리케이션이 빠르게 크기 조정되는 경우 ElastiCache 서버리스가 워크로드에 맞게 규모를 조정하는 동안 요청이 제한될 수 있습니다. ElastiCache 서버리스는 일반적으로 스토리지 크기를 빠르게 늘릴 수 있으며 캐시의 스토리지 크기를 두 배로 늘리는 데 최대 10~12분이 걸릴 수 있습니다.
키 및 요청의 균일한 배포: Valkey 및 Redis OSS용 ElastiCache에서 슬롯당 키 또는 요청이 고르지 않게 배포되면 핫 슬롯이 발생할 수 있습니다. 단일 슬롯에 대한 요청 속도가 초당 30,000 ECPUs 초과하고 간단한 SET/GET 명령을 실행하는 워크로드에 있는 경우 핫 슬롯으로 인해 요청이 제한될 수 있습니다. 마찬가지로 ElastiCache for Memcached를 사용하면 요청 속도가 초당 30,000 ECPUs.
복제본에서 읽기: 애플리케이션에서 허용하는 경우 “복제본에서 읽기” 기능을 사용하는 것이 좋습니다. 대부분의 Valkey 또는 Redis OSS 클라이언트는 “읽기 규모 조정”을 통해 읽기를 복제본 노드로 직접 전송하도록 구성할 수 있습니다. 이 기능을 사용하면 읽기 트래픽을 조정할 수 있습니다. 또한 ElastiCache 서버리스는 복제본 요청의 읽기를 애플리케이션과 동일한 가용 영역의 노드로 자동으로 라우팅하여 지연 시간을 줄입니다. 복제본에서 읽기가 활성화되면 간단한 SET/GET 명령을 사용하여 워크로드에 대해 단일 슬롯에서 초당 최대 90,000ECPU를 달성할 수 있습니다.
관련 항목
