AWS 기술 블로그
Valkey용 Amazon ElastiCache의 서버 측 지연 시간 모니터링
이 글은 AWS Database Blog에 게시된 Monitor server-side latency for Amazon ElastiCache for Valkey by Yasha Jayaprakash을 한국어 번역 및 편집하였습니다.
Amazon ElastiCache는 Valkey 및 Redis OSS (Open Source Software)와 호환되는 인 메모리(in-memory) 캐시로, 마이크로초 지연 시간으로 실시간 애플리케이션을 지원합니다. ElastiCache는 캐싱, 게임 리더보드, 미디어 스트리밍, 세션 스토어 등 마이크로초 단위로 계산되는 까다로운 워크로드와 지연 시간에 민감한 사용 사례에 자주 사용됩니다.
최신 애플리케이션은 마이크로서비스 그룹으로 구축되며, 한 구성 요소의 지연 시간은 전체 시스템의 성능에 영향을 미칠 수 있습니다. 지연 시간 모니터링은 최적의 성능을 유지하고 사용자 경험을 향상하며, 시스템 안정성을 유지하는 데 중요합니다. 이 게시물에서는 자체 설계(노드 기반)된 ElastiCache 클러스터에 대해 지연 시간을 모니터링하고, 이상 현상을 감지하고, 지연 시간이 긴 문제를 효과적으로 해결하는 방법을 살펴봅니다.
Amazon ElastiCache에서 지연 시간 모니터링
일관된 성능을 달성하려면 Valkey 클라이언트와 ElastiCache 엔진 간의 왕복 지연 시간을 측정하여 종단 간 클라이언트 측 지연 시간을 모니터링해야 합니다. 이는 스택 전체에서 병목 현상을 식별하는 데 도움이 될 수 있습니다. 클러스터에서 높은 엔드투엔드 지연이 관찰되면 서버 측, 클라이언트 측 작업으로 인해 지연이 발생하거나, 또는 네트워크 지연 시간 증가로 인해 발생할 수 있습니다. 다음 다이어그램은 클라이언트에서 측정된 왕복 지연 시간과 서버 측 지연 시간 간의 차이를 보여줍니다.
서버 측 지연 시간을 관찰하기 위해 Valkey용 ElastiCache 엔진이 성공적으로 실행된 요청에 응답하는 데 걸리는 시간(마이크로초)을 정확하게 측정할 수 있는, SuccessReadRequestLatency 및 SuccessWriteRequestLatency CloudWatch 지표를 도입했습니다. 이 새로운 지표는 Valkey용 ElastiCache 버전 7.2 이상 또는 최신 버전 자체 설계 클러스터에서 사용할 수 있습니다. 이러한 지표는 각 노드에 대해 분당 한 번씩 계산되고 게시됩니다. Average, Sum, Min, Max, SampleCount 및 p0과 p100 사이의 백분위수와 같은 다양한 CloudWatch 통계를 사용하여, 지정된 기간 동안 지표 데이터 포인트를 집계할 수 있습니다. 샘플 수에는 ElastiCache 서버에서 성공적으로 실행된 명령만 포함됩니다. 또한 ErrorCount
지표는 실행에 실패한 명령의 집계된 개수입니다.
SuccessfulReadRequestLatency
및 SuccessfulWriteRequestLatency
지표는 Valkey용 ElastiCache 엔진 내의 사전 처리, 명령 실행, 사후 처리 단계를 포함하여 명령 처리의 다양한 단계에서 지연 시간을 측정합니다. ElastiCache 엔진은 향상된 I/O 스레드를 사용하여 동시 클라이언트 연결의 네트워크 I/O 처리를 처리합니다. 그런 다음 명령은 메인 스레드에 의해 순차적으로 실행되도록 대기열에 추가됩니다. 다음 다이어그램에 설명된 것처럼 응답은 I/O 쓰기 스레드를 통해 클라이언트로 다시 전송됩니다. 요청 지연 시간 지표는 이러한 다양한 단계를 통해 요청을 완전히 처리하는 데 걸리는 시간을 캡처합니다. GetTypeCmdsLatency
및 SetTypeCmdsLatency
와 같은 기존 명령별 대기 지연 시간 지표는 핵심 명령 논리를 실행하는 데 소요되는 CPU 시간만 측정합니다.
SuccessfulReadRequestLatency
및 SuccessfulWriteRequestLatency
지표는 ElastiCache 클러스터를 사용하여 애플리케이션의 성능 문제를 해결할 때 유용합니다. 이 섹션에서는 이러한 지표를 활용하는 방법에 대한 실제적인 예를 제시합니다.
ElastiCache 클러스터를 사용하여 애플리케이션에 데이터를 쓰는 동안 높은 쓰기 지연 시간이 관찰된다고 가정해 보겠습니다. 성공적으로 실행된 모든 쓰기 요청을 1분 간격으로 처리하는 데 걸리는 시간을 제공하는 SuccessfulWriteRequestLatency
지표를 검사하는 것이 좋습니다. 클라이언트 측에서 지연 시간이 증가했지만 SuccessfulWriteRequestLatency
지표가 증가하지 않은 경우, Valkey용 ElastiCache 엔진이 높은 지연 시간의 주요 원인이 아닐 가능성이 높다는 것을 나타내는 좋은 지표입니다. 이 시나리오에서는 메모리, CPU, 네트워크 사용률 등 클라이언트 측 리소스를 검사하여 원인을 진단합니다. SuccessfulWriteRequestLatency
지표 값이 증가한 경우 다음 섹션의 단계에 따라 문제를 해결하는 것이 좋습니다.
대부분의 사용 사례에서는 SuccessfulReadRequestLatency
및 SuccessfulWriteRequestLatency
지표의 p50 통계를 모니터링하는 것이 좋습니다. 애플리케이션이 꼬리 지연 시간(tail latency)에 민감한 경우 p99 또는 p99.99 통계를 모니터링하는 것이 좋습니다.
다음 스크린샷은 1분 동안 Valkey용 ElastiCache 클러스터에 대한 SetTypeCmdsLatency
지표의 최대 통계와 SuccessfulWriteRequestLatency
지표의 p99(마이크로초)를 비교한 것입니다. SuccessfulWriteRequestLatency
지표를 통해 표시된 쓰기 요청의 버스트를 실행하는 데 걸리는 시간은 UTC 15:41에서 15:43 사이에 증가하는 것을 알 수 있습니다. 왜냐하면 해당 요청은 기본 스레드에 의해 순차적으로 실행되기 위해 대기열에 추가되어 있기 때문입니다. SetTypeCmdsLatency
메트릭으로 표시되는 명령은 안정적으로 유지됩니다.
ElastiCache의 높은 지연 시간 문제 해결
자체 설계(노드 기반) Valkey 클러스터용 ElastiCache에서 높은 읽기/쓰기 지연 시간 문제를 해결하려면 클러스터의 다음 측면을 검사해 보세요.
장기 실행 명령
Valkey 엔진용 오픈 소스 Valkey 및 ElastiCache는 단일 스레드에서 명령을 실행합니다. 애플리케이션이 HGETALL
또는 SUNION
과 같은 대규모 데이터 구조에서 비용이 많이 드는 명령을 실행하는 경우, 이러한 명령의 실행 속도가 느려지면 다른 클라이언트의 후속 요청이 대기하게 되어, 애플리케이션 지연 시간이 늘어날 수 있습니다.
GetTypeCmdsLatency
및 SetTypeCmdsLatency
와 같은 기존 명령별 지연 시간 지표는 핵심 명령 논리를 실행하는 데 소요된 CPU 시간만 측정하며, 명령이 우선 순위가 지정되기를 기다리는 시간은 반영하지 않습니다. 그러나 SuccessfulWriteRequestLatency
및 SuccessfulReadRequestLatency
지표에는 소켓에서 읽는 데 걸리는 시간, 큐잉 시간, 명령 처리, 소켓에 다시 쓰는 데 걸리는 시간 등 전체 서버 측 지연 시간이 포함됩니다. p99/p100 통계 값이 높은 경우(아마도 GetTypeCmdsLatency
또는 SetTypeCmdsLatency
에 비해) Valkey SLOWLOG 명령을 사용하거나, ElastiCache 로그 전달 대상으로 스트리밍된 클러스터의 SLOWLOG
를 조사하여, 완료하는 데 더 오래 걸린 명령을 파악하는 데 도움을 받을 수 있습니다. Valkey SLOWLOG
에는 지정된 런타임을 초과하는 쿼리에 대한 세부 정보가 포함되며, 이 런타임에는 명령 처리 시간만 포함됩니다. SLOWLOG
에 이상이 없으면 명령 처리 지연 시간 이외의 요인으로 인해 서버 측 지연 시간이 급증했음을 나타냅니다.
대기(Queuing) 시간
Valkey용 ElastiCache는 고객 트래픽을 적극적으로 관리하여 최적의 성능과 복제 안정성을 유지합니다. ElastiCache 엔진에서 처리할 수 있는 것보다 더 많은 명령이 노드에 전송되면, 높은 트래픽이 조절되며 이는 TrafficManagementActive
지표로 표시됩니다. TrafficManagementActive
지표가 활성 상태로 유지되고 지연 시간 지표가 장기간 높은 상태로 유지되는 경우, 클러스터를 평가하여 확장 또는 확장이 필요한지 결정합니다. 때로는 일시적인 트래픽 급증으로 인해 대기 시간이 길어지고 결과적으로 꼬리 지연 시간이 길어질 수도 있습니다.
메모리 활용도
메모리가 부족한 Valkey용 ElastiCache 노드는 사용 가능한 인스턴스 메모리보다 더 많은 메모리를 사용할 수 있습니다. 이 상황에서 Valkey는 들어오는 쓰기 작업을 위한 공간을 확보하기 위해 데이터를 메모리에서 디스크로 교환합니다. 노드의 메모리 부족 여부를 확인하려면 FreeableMemory
지표가 낮은지 또는 SwapUsage
지표가 FreeableMemory
보다 큰지 검토하세요. 노드의 스왑 활동이 높으면 요청 지연 시간이 길어집니다. 메모리 부족으로 인해 노드가 교체되는 경우 더 큰 노드 유형으로 확장하거나 샤드를 추가하여 확장하세요. 또한 트래픽 버스트를 수용할 수 있도록 클러스터에 충분한 메모리를 사용할 수 있는지 확인해야 합니다.
데이터 계층화
Valkey용 ElastiCache는 데이터가 메모리와 로컬 SSD 사이에 계층화되는, Valkey 워크로드에 대한 가격 대비 성능 옵션으로 데이터 계층화를 제공합니다. 데이터 계층화는 전체 데이터 세트의 최대 20%에 정기적으로 액세스하는 워크로드와 SSD의 데이터에 액세스할 때의 추가 지연 시간을 허용할 수 있는 애플리케이션에 이상적입니다.
SSD 계층에서 읽고 쓰는 데이터의 양을 나타내는 BytesReadFromDisk
및 BytesWrittenToDisk
지표를 SuccessfulWriteRequestLatency
및 SuccessfulReadRequestLatency
지표와 함께 사용하여 계층화된 작업과 관련된 처리량을 확인할 수 있습니다. 예를 들어, SuccessfulReadRequestLatency
및 BytesReadFromDisk
지표의 값이 높으면 SSD가 메모리에 비해 더 자주 액세스되고 있음을 나타낼 수 있으며, 더 큰 노드 유형으로 확장하거나 더 많은 RAM이 확보되도록 샤드를 추가하여 확장하고, 활성 데이터 세트를 제공하는 데 사용할 수 있습니다.
Valkey의 수평 확장
ElastiCache에 대한 온라인 리샤딩 및 샤드 재분배를 사용하면 가동 중지 시간 없이 클러스터를 동적으로 확장할 수 있습니다. 이는 확장 또는 재조정이 진행되는 동안에도 클러스터가 계속해서 요청을 처리할 수 있음을 의미합니다. 클러스터가 용량에 거의 도달하면 조정 작업이 진행될 수 있도록 클라이언트 쓰기 요청이 제한되어 요청 처리 시간이 늘어납니다. 이 지연 시간은 새 지표에도 반영됩니다. 사용량이 적은 시간에 리샤딩을 시작하는 등 온라인 클러스터 크기 조정에 대한 모범 사례를 따르고 크기 조정 중에는 비용이 많이 드는 명령을 피하는 것이 좋습니다.
클라이언트 연결 수 증가
Valkey용 ElastiCache 노드는 최대 65,000개의 클라이언트 연결을 지원할 수 있습니다. 동시 연결 수가 많으면 CPU 사용량이 크게 증가하여 애플리케이션 지연 시간이 길어질 수 있습니다. 이러한 오버헤드를 줄이려면 연결 풀 사용 또는 기존 Valkey 연결 재사용과 같은 모범 사례를 따르는 것이 좋습니다.
결론
Valkey용 ElastiCache 인스턴스에 대한 지연 시간 측정은 필요한 세분성 수준에 따라 다양한 방식으로 접근할 수 있습니다. 클라이언트 측에서 엔드투엔드 지연을 모니터링하면, 데이터 경로 전체의 문제를 식별하는 데 도움이 되며, 요청 지연 시간 지표는 명령 전처리, 명령 실행, 명령 후처리를 포함한 명령 처리의 다양한 단계에서 소요되는 시간을 캡처합니다.
새로운 요청 지연 시간 지표는 Valkey용 ElastiCache 엔진이 요청에 응답하는 데 걸리는 시간을 보다 정확하게 측정합니다. 이 게시물에서는 이러한 지연 시간 지표가 ElastiCache 클러스터의 지연 시간 급증 문제를 해결하는 데 도움이 될 수 있는 몇 가지 시나리오에 대해 논의했습니다. 이 게시물의 세부 정보를 사용하면 정상적인 Valkey용 ElastiCache 클러스터를 감지, 진단 및 유지 관리할 수 있습니다. 이 게시물에서 논의된 지표에 대해는 설명서에서 더 확인하실 수 있습니다.