ElastiCache for Redis 사용 시 지연 시간이 긴 문제를 해결하려면 어떻게 해야 합니까?

6분 분량

Amazon ElastiCache for Redis 사용 시 지연 시간이 긴 문제를 해결하려면 어떻게 해야 합니까?

간략한 설명

ElastiCache for Redis에서 지연 시간이 증가하거나 시간 초과 문제가 발생하는 일반적인 이유는 다음과 같습니다.

느린 명령으로 인한 지연입니다.
메모리 사용량이 많아 스와핑이 증가합니다.
네트워크 문제로 인한 지연입니다.
클라이언트 측 지연 문제입니다.
ElastiCache 클러스터 이벤트입니다.

해결 방법

느린 명령으로 인한 지연

Redis는 대부분 단일 스레드입니다. 따라서 요청이 느리게 처리되면 다른 모든 클라이언트는 처리될 때까지 기다려야 합니다. 이렇게 하면 명령 대기 시간이 늘어납니다. Redis 명령에는 Big O 표기법을 사용하여 정의한 시간 복잡도도 있습니다.

ElastiCache에서 제공하는 Amazon CloudWatch 지표를 사용하여 다양한 명령 클래스에 대한 평균 지연 시간을 모니터링할 수 있습니다. 일반적인 Redis 작업은 마이크로초 단위의 지연 시간으로 계산된다는 점에 유의해야 합니다. CloudWatch 지표는 1분마다 샘플링되며, 지연 시간 지표는 여러 명령의 집계를 보여줍니다. 따라서 단일 명령으로 지표 그래프에 큰 변화가 나타나지 않는 시간 초과 등의 예기치 않은 결과가 발생할 수 있습니다. 이러한 상황에서는 SLOWLOG 명령을 사용하여 완료하는 데 더 오래 걸리는 명령을 확인할 수 있습니다. 클러스터에 연결하고 redis-cli에서 slowlog get 128 명령을 실행하여 목록을 검색합니다. 자세한 내용은 Redis용 ElastiCache 캐시 클러스터에서 Redis 슬로우 로그를 켜려면 어떻게 해야 합니까?를 참조하십시오.

또한 Redis 엔진을 차단하는 느린 명령으로 인해 CloudWatch에서 EngineCPUUtilization 지표가 증가하는 것을 볼 수 있습니다. 자세한 정보는 ElastiCache for Redis 클러스터에서 CPU 사용량이 많거나 증가하는 이유는 무엇입니까?를 참조하십시오.

복잡한 명령의 예시는 다음과 같습니다.

생산 환경의 KEYS는 지정 패턴을 검색하는 전체 키 공간을 청소하기 때문에, 대규모 데이터 세트 전반의 운영 환경에서 사용합니다.
장기 실행 LUA 스크립트입니다.

높은 메모리 사용량으로 스와핑 증가

Redis는 사용 가능한 수준보다 많은 메모리를 사용하여 클러스터의 메모리 압력이 증가하면 페이지를 교체하기 시작합니다. 메모리 페이지가 스왑 영역으로 전송되거나, 스왑 영역에서 전송될 때, 지연 시간 및 시간 초과 문제가 증가합니다. 다음은 CloudWatch 지표에서 스왑이 증가했다는 표시입니다.

SwapUsage가 증가합니다.
FreeableMemory가 매우 낮습니다.
BytesUsedForCache 및 DatabaseMemoryUsagePercentage 지표가 높습니다.

SwapUsage는 스왑된 메모리의 양을 나타내는 호스트 수준 지표입니다. 이 지표는 기본 운영 체제가 제어하며, 많은 동적 요소의 영향을 받을 수 있으므로, 보통 0이 아닌 값을 표시합니다. 이러한 요소는 OS 버전, 활동 패턴 등을 포함합니다. Linux는 자주 사용하는 키의 메모리 공간을 확보하기 위한 최적화 기법으로 유휴 키(클라이언트가 거의 액세스하지 않음)를 사전 예방적으로 디스크로 스왑합니다.

사용 가능한 메모리가 충분하지 않으면 스와핑이 문제가 됩니다. 이 경우 시스템은 디스크와 메모리 간에 페이지를 앞뒤로 이동하기 시작합니다. 특히 수백 메가바이트 미만의 SwapUsage는 Redis 성능에 부정적인 영향을 미치지 않습니다. SwapUsage가 높고, 적극적으로 변경되며, 클러스터에 사용 가능한 메모리가 충분하지 않은 경우 성능에 영향을 미칠 수 있습니다. 자세한 내용은 다음을 참조하세요.

네트워크로 인한 지연

클라이언트와 ElastiCache 클러스터 간의 네트워크 지연 시간

클라이언트와 클러스터 노드 간 네트워크 대기 시간을 분리하려면 애플리케이션 환경에서 TCP traceroute 또는 mtr 테스트를 사용합니다. 또는 AWSSupport-SetupIPMonitoringFromVPC AWS Systems Manager 문서(SSM 문서)와 같은 디버깅 도구를 사용하여 클라이언트 서브넷에서 시작하는 연결을 테스트합니다.

클러스터가 네트워크 한계에 도달

ElastiCache 노드는 해당 유형의 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스와 동일한 네트워크 제한을 공유합니다. 예를 들어 cache.m6g.large의 노드 유형은 m6g.large EC2 인스턴스와 동일한 네트워크 제한을 포함합니다. 대역폭 기능, 초 당 패킷(PPS) 성능 및 추적한 연결의 세 가지 주요 네트워크 성능 구성 요소를 확인하는 방법에 대한 자세한 내용은 EC2 인스턴스 네트워크 성능 모니터링을 참조하십시오.

ElastiCache 노드의 네트워크 제한 문제를 해결하려면 문제 해결 - 네트워크 관련 제한을 참조하십시오.

TCP/SSL 핸드셰이크 지연 시간

클라이언트는 TCP 연결을 사용하여 Redis 클러스터에 연결합니다. TCP 연결 생성에는 몇 밀리초가 소요됩니다. 추가 밀리초가 발생하면 애플리케이션에서 실행하는 Redis 작업에 추가 오버헤드가 발생하고 Redis CPU에 부담이 가중됩니다. 클러스터가 ElastiCache 전송 중 암호화 기능을 사용할 때는 TLS 핸드셰이크에 필요한 추가 시간과 CPU 사용률로 인해 새 연결의 볼륨을 제어하는 것이 중요합니다. 많은 양의 연결이 빠르게 열리고 (NewConnections) 닫히면 노드의 성능에 영향을 줄 수 있습니다. 연결 풀링을 사용하여 설정된 TCP 연결을 풀에 캐시할 수 있습니다. 그런 다음, 새 클라이언트가 클러스터에 연결을 시도할 때마다 연결이 재사용됩니다. 애플리케이션 환경에 사용할 수 있는 프레임워크와 함께 Redis 클라이언트 라이브러리(지원하는 경우)를 사용하여 연결 풀링을 구현하거나, 또는 처음부터 구축할 수 있습니다. 또한 MSET/MGET 등의 집계한 명령을 최적화 기법으로 사용할 수도 있습니다.

ElastiCache 노드에는 많은 수의 연결이 있음

CurrConnections 및 NewConnections CloudWatch 지표를 추적하는 것이 가장 좋습니다. 이러한 지표는 Redis에서 허용하는 TCP 연결 수를 모니터링합니다. TCP 연결 수가 많으면 maxclients 제한인 65,000개가 소진될 수 있습니다. 이 제한은 노드당 가질 수 있는 최대 동시 연결입니다. 65,000 한도에 도달하면 ERR 최대 클라이언트 수에 도달함 오류가 발생합니다. Linux 서버의 제한 또는 추적되는 최대 연결 수를 초과하여 더 많은 연결을 추가하면, 클라이언트 연결을 추가하는 경우 연결 시간 초과 오류가 발생합니다. 많은 수의 연결을 예방하는 방법에 대한 정보는 모범 사례: Redis 클라이언트 및 Amazon ElastiCache for Redis를 참조하십시오.

클라이언트 측 지연 문제

지연 시간 및 시간 초과는 클라이언트 자체에서 발생할 수 있습니다. 클라이언트 측의 메모리, CPU 및 네트워크 사용률을 확인하여 이러한 리소스가 그들의 제한에 도달하는지 확인합니다. 애플리케이션이 EC2 인스턴스에서 실행 중인 경우 앞서 설명한 내용과 동일한 CloudWatch 지표를 활용하여 병목 현상을 확인합니다. 기본 CloudWatch 지표로는 철저하게 모니터링할 수 없는 운영 체제에서 지연 시간이 발생할 수 있습니다. EC2 인스턴스 내부에 atop 또는 CloudWatch 에이전트 등의 모니터링 도구를 설치하는 것이 좋습니다.

애플리케이션 측에서 설정한 시간 초과 구성 값이 너무 작으면 불필요한 시간 초과 오류가 발생할 수 있습니다. 서버가 요청을 처리하고 응답을 생성할 수 있는 충분한 시간을 허용하도록 클라이언트측 시간 제한을 적절히 구성합니다. 자세한 내용은 모범 사례: Redis 클라이언트 및 Amazon ElastiCache for Redis를 참조하십시오.

애플리케이션에서 수신한 시간 초과 오류로 인해 추가 세부 정보가 표시됩니다. 이러한 세부 정보는 특정 노드의 관련 여부, 시간 초과를 유발하는 Redis 데이터 유형 이름, 시간 초과가 발생한 정확한 타임스탬프 등을 포함합니다. 이 정보는 문제의 패턴을 찾는 데 도움이 됩니다. 이 정보를 사용하여 다음과 같은 질문에 답할 수 있습니다.

하루 중 특정 시간에 시간 초과가 자주 발생합니까?
하나 이상의 클라이언트에서 시간 초과가 발생했습니까?
한 Redis 노드 또는 여러 노드에서 시간 초과가 발생했습니까?
하나 이상의 클러스터에서 시간 초과가 발생했습니까?

이러한 패턴을 사용하여 가장 가능성이 높은 클라이언트 또는 ElastiCache 노드를 조사할 수 있습니다. 애플리케이션 로그 및 VPC 흐름 로그를 사용하여 클라이언트 측, ElastiCache 노드 또는 네트워크에서 지연 시간이 발생했는지 확인할 수도 있습니다.

Redis 동기화

Redis의 동기화는 백업, 교체 및 크기 조정 이벤트 중에 시작됩니다. 이는 지연 시간을 유발할 수 있는 컴퓨팅 집약적 워크로드입니다. SaveInProgress CloudWatch 지표를 사용하여 동기화가 진행 중인지 확인할 수 있습니다. 자세한 내용은 동기화 및 백업 구현 방법을 참조하십시오.

ElastiCache 클러스터 이벤트

ElastiCache 콘솔의 이벤트 섹션에서 지연 시간이 관찰된 기간을 확인합니다. ElastiCache 관리형 유지 보수 및 서비스 업데이트로 인해 발생할 수 있는 노드 교체 또는 장애 조치 이벤트 등의 백그라운드 작업이나 예기치 않은 하드웨어 오류를 확인합니다. PHD 대시보드 및 이메일을 통해 예약 이벤트에 대한 알림을 받습니다.

다음은 샘플 이벤트 로그입니다.

Finished recovery for cache nodes 0001
Recovering cache nodes 0001
Failover from master node <cluster_node> to replica node <cluster_node> completed