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