느린 Redis 명령어 문제 해결: 성능 체크리스트

느린 Redis 명령어는 일반적으로 정상적인 명령어가 예상을 벗어나면서 시작됩니다. SMEMBERS 호출은 집합에 200개의 멤버가 있을 때는 문제가 없었습니다. 대시보드 쿼리는 50개의 키를 로드할 때는 괜찮았습니다. Lua 스크립트는 한 고객이 다른 모든 사람보다 훨씬 큰 데이터 형태를 생성할 때까지 빠르게 작동했습니다.

유용한 질문은 단순히 "어떤 명령어가 느린가?"가 아닙니다. "어떤 데이터 형태가 이 명령어를 느리게 만들었으며, 왜 애플리케이션이 Redis에게 한 번에 그렇게 많은 작업을 요청하는가?"입니다.

Redis 성능 이해

Redis의 성능은 일반적으로 인메모리 특성으로 인해 뛰어납니다. 그러나 여러 요인이 명령어 지연 시간에 기여할 수 있습니다:

명령어 복잡도: 특정 명령어는 다른 명령어보다 본질적으로 더 많은 리소스를 사용합니다 (예: 대규모 데이터셋의 KEYS vs GET).
데이터 크기 및 구조: 큰 리스트, 집합, 정렬된 집합 또는 복잡한 데이터 구조는 이를 대상으로 하는 명령어의 성능에 영향을 미칠 수 있습니다.
네트워크 지연 시간: 직접적인 명령어 문제는 아니지만, 클라이언트와 서버 간의 높은 네트워크 지연 시간은 명령어를 느리게 보이게 할 수 있습니다.
서버 부하: 높은 CPU 사용률, 메모리 부족 또는 Redis 서버의 다른 프로세스는 성능을 저하시킬 수 있습니다.
블로킹 명령어: 특정 작업은 Redis 이벤트 루프를 차단하여 이후의 모든 명령어에 영향을 미칠 수 있습니다.

`SLOWLOG`로 느린 명령어 식별

SLOWLOG 명령어는 지정된 실행 시간을 초과하는 명령어를 기록하는 Redis의 내장 메커니즘입니다. 이는 문제가 있는 명령어를 사전에 식별하는 주요 도구입니다.

`SLOWLOG` 작동 방식

Redis는 구성된 slowlog-log-slower-than 임계값(마이크로초 단위)보다 오래 걸린 명령어에 대한 정보를 저장하는 순환 버퍼를 유지합니다. 기본 임계값은 일반적으로 10밀리초(10000마이크로초)입니다. 이 버퍼가 가득 차면 오래된 항목이 삭제됩니다.

주요 `SLOWLOG` 하위 명령어

SLOWLOG GET [count]: 느린 로그에서 마지막 count 항목을 검색합니다. count가 생략되면 모든 항목을 검색합니다.
SLOWLOG LEN: 느린 로그의 현재 길이(항목 수)를 반환합니다.
SLOWLOG RESET: 느린 로그 항목을 지웁니다. 이 명령어는 로그된 데이터를 영구적으로 제거하므로 주의해서 사용하십시오.

`SLOWLOG` 사용 예

일부 명령어가 너무 오래 걸린다고 의심된다고 가정해 보겠습니다. 다음과 같이 느린 로그를 확인할 수 있습니다:

# Redis 인스턴스에 연결
redis-cli

# 마지막 5개의 느린 명령어 가져오기
127.0.0.1:6379> SLOWLOG GET 5

출력은 다음과 같습니다:

1) 1) (integer) 18
   2) (integer) 1678886400
   3) (integer) 15000
   4) 1) "KEYS"
      2) "*"

2) 1) (integer) 17
   2) (integer) 1678886390
   3) (integer) 12000
   4) 1) "SMEMBERS"
      2) "my_large_set"

...

출력 설명:

항목 ID: 느린 로그 항목의 고유 식별자.
타임스탬프: 명령어가 실행된 Unix 타임스탬프.
실행 시간: 명령어 실행에 걸린 시간(마이크로초).
명령어 및 인수: 명령어 자체와 그 인수.

위 예에서 KEYS *는 15000마이크로초(15ms)가 걸렸고 SMEMBERS my_large_set은 12000마이크로초(12ms)가 걸렸습니다. slowlog-log-slower-than이 10000마이크로초로 설정된 경우 이는 느린 것으로 간주됩니다.

`slowlog-log-slower-than` 구성

CONFIG SET 명령어를 사용하여 slowlog-log-slower-than 임계값을 동적으로 변경할 수 있습니다:

127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 50000  # 50ms보다 느린 명령어 기록

이 변경 사항을 Redis 재시작 후에도 유지하려면 redis.conf 파일을 수정하고 Redis 서버를 다시 시작하거나 CONFIG REWRITE를 사용하여 구성 파일에 변경 사항을 저장해야 합니다.

`MONITOR`를 사용한 실시간 명령어 모니터링

SLOWLOG가 과거 기록을 제공하는 반면, MONITOR는 Redis 서버에서 실행되는 모든 명령어의 실시간 스트림을 제공합니다. 이는 특정 기간의 느린 성능을 디버깅하거나 명령어 트래픽 패턴을 이해하는 데 매우 유용합니다.

`MONITOR` 작동 방식

MONITOR를 활성화하면 Redis는 수신하고 처리하는 모든 명령어에 대한 응답을 MONITOR 클라이언트에 보냅니다. 특히 사용량이 많은 Redis 인스턴스에서는 매우 많은 양의 출력을 생성할 수 있습니다. 따라서 일반적으로 MONITOR는 신중하게, 그리고 적극적으로 디버깅할 때만 사용하는 것이 좋습니다.

`MONITOR` 사용 예

별도의 redis-cli 세션에서 MONITOR 명령어를 실행합니다:

# *별도의* 터미널에서 Redis 인스턴스에 연결
redis-cli

# 모니터링 시작
127.0.0.1:6379> MONITOR

이제 다른 redis-cli 세션이나 애플리케이션에서 실행된 모든 명령어가 MONITOR 출력에 나타납니다. 예를 들어, 다른 클라이언트에서 SET mykey myvalue를 실행하면 다음과 같이 표시됩니다:

1678887000.123456 [0 127.0.0.1:54321] "SET" "mykey" "myvalue"

디버깅을 위한 `MONITOR` 사용

문제 재현: 속도 저하를 발견하면 즉시 전용 redis-cli 세션에서 MONITOR를 시작합니다.
느린 작업 트리거: 애플리케이션이 속도 저하를 일으키는 것으로 의심되는 작업을 수행하도록 합니다.
출력 분석: MONITOR 스트림에서 명령어를 관찰합니다. 다음을 찾으십시오:
- 나타나는 데 오래 걸리는 명령어 (MONITOR 자체는 실행 시간을 표시하지 않지만 수동으로 시간을 측정하거나 지연을 관찰하여 유추할 수 있습니다).
- 비정상적이거나 예상치 못한 명령어 실행.
- 서버에 과부하를 줄 수 있는 많은 양의 명령어.
모니터링 중지: Ctrl+C를 눌러 MONITOR 명령어를 종료합니다.

중요: 모든 명령어를 클라이언트에 보내는 오버헤드로 인해 Redis 성능에 상당한 영향을 미칠 수 있으므로 프로덕션 환경에서 장시간 MONITOR를 실행하지 마십시오.

느린 명령어의 일반적인 원인 및 해결 방법

SLOWLOG 및 MONITOR에서 수집한 정보를 바탕으로 일반적인 원인과 해결 방법은 다음과 같습니다:

1. `KEYS` 명령어

문제: KEYS 명령어는 패턴과 일치하는 키를 찾기 위해 전체 키 공간을 반복합니다. 수백만 개의 키가 있는 데이터베이스에서는 매우 오래 걸리고 Redis 서버를 차단하여 다른 모든 클라이언트에 영향을 미칠 수 있습니다.
해결 방법: 대규모 프로덕션 키 공간에서 KEYS를 사용하지 마십시오. 증분 키 반복이 필요한 경우 SCAN을 사용하십시오. SCAN은 각 호출에서 패턴과 일치하는 키의 하위 집합을 반환하여 서버를 장시간 차단할 가능성을 줄입니다.
```
  # KEYS user:* 대신
  redis-cli -h <host> -p <port> SCAN 0 MATCH user:* COUNT 100
```
커서가 0으로 돌아올 때까지 이전 호출에서 반환된 커서를 사용하여 SCAN을 여러 번 호출해야 합니다.

2. 복잡한 스크립팅 (Lua 스크립트)

문제: EVAL 또는 EVALSHA를 통해 실행되는 장기 실행 또는 비효율적인 Lua 스크립트는 서버를 차단할 수 있습니다. Redis는 스크립트를 원자적으로 실행하지만, 단일 긴 스크립트가 이벤트 루프를 독점할 수 있습니다.
해결 방법: Lua 스크립트를 최적화하십시오. 복잡한 로직을 더 작고 관리하기 쉬운 스크립트로 분할하십시오. 스크립트 성능을 분석하십시오. 스크립트 내의 루프가 효율적이고 올바르게 종료되는지 확인하십시오. 스크립트를 벤치마킹하여 실행 시간을 이해하십시오.

3. 대규모 데이터 구조에 대한 작업

문제: 수백만 개의 멤버가 있는 집합에 대한 SMEMBERS, 매우 긴 리스트에 대한 LRANGE 또는 거대한 정렬된 집합에 대한 ZRANGE와 같은 명령어는 느릴 수 있습니다.
해결 방법: 전체 대규모 데이터 구조를 가져오지 마십시오. 대신 반복 명령어를 사용하거나 데이터를 청크 단위로 처리하십시오:
- 집합: SMEMBERS 대신 SSCAN을 사용하십시오.
- 리스트: 더 작은 start 및 stop 값으로 LRANGE를 사용하여 데이터를 페이지 단위로 검색하십시오.
- 정렬된 집합: LIMIT가 있는 ZRANGE 또는 ZSCAN을 사용하십시오.

4. 키 반복이 필요한 명령어 (덜 일반적이지만 가능)

문제: 덜 일반적이지만, 특성상 키를 암시적으로 반복할 수 있는 명령어는 키 공간이 큰 경우 느릴 수 있습니다.
해결 방법: 특정 명령어에 대한 Redis 명령어 참조를 검토하고 복잡성을 이해하십시오. 특정 명령어가 병목 현상으로 판명되면 대체 데이터 구조나 접근 방식을 고려하십시오.

5. 블로킹 명령어 (최신 Redis에서는 드물게)

문제: 이전 Redis 버전에는 서버를 차단할 수 있는 일부 명령어가 있었습니다. 대부분은 해결되었거나 대체되었습니다.
해결 방법: 최신 버전의 Redis를 사용하고 있는지 확인하십시오. 특정 버전의 알려진 블로킹 작업에 대해서는 Redis 문서를 참조하십시오.

먼저 Redis가 느린지 아니면 클라이언트가 기다리고 있는지 결정하십시오

누군가 "Redis가 느리다"고 말할 때, 그들은 여러 가지 다른 것을 의미할 수 있습니다. 서버가 명령어를 실행하는 데 너무 오래 걸릴 수 있습니다. 클라이언트가 네트워크에서 기다리고 있을 수 있습니다. 연결 풀이 소진되었을 수 있습니다. TLS 프록시에 과부하가 걸렸을 수 있습니다. 큰 응답이 명령어 실행 시간보다 전송에 더 오래 걸릴 수 있습니다.

SLOWLOG는 Redis 내부의 명령어 실행 시간만 기록합니다. 네트워크 전송 시간, 클라이언트 대기 시간 또는 애플리케이션 풀에서 연결을 기다리는 시간은 포함하지 않습니다. 이것이 깨끗한 느린 로그가 항상 사용자가 지연 시간을 상상하고 있음을 증명하지 않는 이유입니다.

세 가지 보기를 비교하십시오:

redis-cli --latency -h <host> -p <port>
redis-cli --latency-history -h <host> -p <port>
redis-cli SLOWLOG GET 10

지연 시간이 높지만 SLOWLOG가 비어 있으면 네트워크, 클라이언트 풀, 서버 CPU 포화, 포크 활동, 지속성 또는 큰 응답을 살펴보십시오. SLOWLOG에 반복되는 비용이 많이 드는 명령어가 표시되면 명령어 및 데이터 구조 설계부터 시작하십시오.

애플리케이션에서 클라이언트 경계에서 Redis 호출 주변에 타이밍을 추가하십시오. 명령어 패밀리, 키 패턴, 경과 시간 및 클라이언트가 풀 연결을 기다렸는지 여부를 기록하십시오. 비밀 또는 전체 페이로드를 기록하지 마십시오. 소량의 구조화된 타이밍은 일반적으로 지연이 Redis 내부에 있는지 아니면 명령어가 Redis에 도달하기 전인지 답변합니다.

명령어 복잡도를 냄새 테스트로 사용하십시오

Redis 명령어는 소량의 제한된 데이터를 다룰 때 빠릅니다. 대규모 키 공간을 스캔하거나, 거대한 컬렉션을 반환하거나, 큰 값에 비례하는 작업을 수행할 때 위험해집니다.

하드웨어를 비난하기 전에 해당 버전의 Redis 명령어 참조에서 명령어의 복잡성을 확인하십시오. 모든 복잡성 레이블을 외울 필요는 없지만, 형태가 중요합니다:

GET user:123은 하나의 값 크기에 의해 제한됩니다.
HGET profile:123 email은 하나의 해시 조회에 의해 제한됩니다.
SMEMBERS followers:celebrity는 전체 집합을 반환합니다.
KEYS *는 전체 키 공간을 스캔합니다.
LRANGE queue 0 -1은 전체 리스트를 반환합니다.
ZREMRANGEBYSCORE는 많은 수의 정렬된 집합 멤버를 제거할 수 있습니다.

위험한 패턴은 일반적으로 "모든 것을 주세요"입니다. 몇 달 동안 작동하다가 집합이 수백 개의 멤버에서 수백만 개로 성장하면 실패할 수 있습니다. Redis가 갑자기 느려진 것이 아닙니다. 데이터가 무제한 명령어가 눈에 띄게 되는 지점을 넘어선 것입니다.

일반적인 느린 패턴에 대한 더 안전한 대체 방법

전체 키 공간 및 전체 컬렉션 명령어를 증분 패턴으로 대체하십시오.

키 검색에는 SCAN을 사용하십시오:

redis-cli --scan --pattern 'user:*'

집합에는 SSCAN을 사용하십시오:

SSCAN active_users 0 COUNT 500

해시에는 HSCAN을 사용하십시오:

HSCAN user:123:settings 0 COUNT 200

정렬된 집합의 경우 명시적 범위와 제한이 있는 범위를 선호하십시오:

ZRANGE leaderboard 0 99 WITHSCORES
ZRANGEBYSCORE events 1716600000 1716686400 LIMIT 0 500

리스트의 경우 제한된 범위로 페이지를 매기십시오:

LRANGE recent_jobs 0 99

SCAN은 증분식이지만 마법처럼 무료 작업은 아닙니다. 중복을 반환할 수 있으며 키가 변경되는 동안 완벽하게 일관된 스냅샷을 제공하지 않습니다. 유지 관리, 마이그레이션 및 백그라운드 검색에 적합합니다. 일반적으로 정확한 실시간 목록이 필요한 사용자 대면 요청 경로에 적합한 기본 요소는 아닙니다.

큰 응답이 실제 비용일 수 있습니다

명령어가 빠르게 실행되더라도 너무 많은 데이터를 반환하면 애플리케이션에 해를 끼칠 수 있습니다. 거대한 집합에 대한 SMEMBERS, 큰 해시에 대한 HGETALL 또는 수천 개의 큰 값에 대한 MGET은 응답을 직렬화하고 네트워크를 통해 보내는 데 시간을 소비할 수 있습니다. 이 비용은 명령어 실행 시간만으로는 명확하게 나타나지 않을 수 있습니다.

느린 작업 중에 네트워크 출력과 클라이언트 메모리를 관찰하십시오. 단일 요청이 수십 또는 수백 메가바이트를 반환하는 경우 액세스 패턴을 재설계하십시오. 요약 데이터를 별도로 저장하십시오. 결과를 페이지로 나누십시오. 정렬된 집합 인덱스를 사용하고 표시되는 조각만 가져오십시오. 애플리케이션이 일반적으로 하나의 필드만 필요할 때 Redis에 큰 문서를 배치하지 마십시오.

실용적인 예: 대시보드에 최신 50개의 작업이 표시되는 경우 모든 작업 ID를 리스트에 저장하고 앱에서 슬라이스하기 전에 LRANGE jobs 0 -1을 호출하지 마십시오. 리스트를 최신순으로 저장하고 페이지에 필요한 것만 요청하십시오:

LRANGE jobs:recent 0 49

이 작은 변경으로 놀라운 양의 지연 시간과 메모리 압력을 제거할 수 있습니다.

`MONITOR`는 메스이지 대시보드가 아닙니다

MONITOR는 클라이언트가 보내는 명령어를 정확히 확인해야 할 때, 특히 애플리케이션이 코드 검토에서 제안하는 것과 다른 작업을 수행하고 있다고 의심될 때 유용합니다. 그러나 사용량이 많은 Redis 서버에서는 MONITOR가 오버헤드를 생성하고 엄청난 양의 출력을 생성합니다.

짧고 통제된 기간 동안 사용하십시오:

redis-cli MONITOR | head -n 200

그런 다음 중지하십시오. 프로덕션에서는 가능한 경우 애플리케이션 로그, Redis 명령어 통계 또는 짧은 유지 관리 기간에서 샘플링하는 것을 선호하십시오.

광범위한 보기를 위해서는 INFO commandstats가 종종 더 안전합니다:

redis-cli INFO commandstats

명령어별 호출 횟수와 누적 마이크로초를 표시합니다. 어떤 키가 느린지 알려주지는 않지만 애플리케이션이 예상보다 훨씬 많은 HGETALL, KEYS 또는 EVAL 호출을 발행하고 있음을 밝힐 수 있습니다.

Lua 스크립트에는 경계가 필요합니다

Lua 스크립트는 Redis 내부에서 원자적으로 실행되기 때문에 강력합니다. 동일한 원자적 동작은 긴 스크립트가 실행되는 동안 다른 명령어를 차단한다는 것을 의미합니다. 느린 스크립트는 종종 대규모 컬렉션에 대한 루프, 무제한 키 검색 또는 작은 도우미에서 미니 애플리케이션으로 성장한 로직에서 비롯됩니다.

동일한 질문으로 스크립트를 검토하십시오:

이 스크립트가 얼마나 많은 키를 다룰 수 있습니까?
이 스크립트가 얼마나 많은 요소를 반복할 수 있습니까?
입력 키에 백만 개의 멤버가 있으면 어떻게 됩니까?
작업을 더 작은 청크로 분할할 수 있습니까?
스크립트가 큰 페이로드를 반환합니까?

스크립트가 SLOWLOG에 나타나면 slowlog-log-slower-than만 높이고 싶은 유혹을 참으십시오. 로그는 하나의 원자 블록이 다른 클라이언트에 영향을 미칠 만큼 오래 걸리고 있음을 알려줍니다.

지속성, 포크 및 증상인 "느린 명령어"

때로는 Redis가 백그라운드 작업으로 바쁘기 때문에 명령어가 느립니다. RDB 스냅샷 및 AOF 다시 쓰기 작업은 CPU, 메모리 압력 및 디스크 I/O를 증가시킬 수 있습니다. Linux에서 큰 Redis 프로세스를 포크하면 특히 메모리 오버커밋, 거대한 페이지 또는 느린 스토리지가 관련된 경우 지연 시간 스파이크를 생성할 수도 있습니다.

확인:

redis-cli INFO persistence
redis-cli INFO stats
redis-cli INFO memory
redis-cli LATENCY LATEST

지연 시간 스파이크가 백그라운드 저장 또는 AOF 다시 쓰기와 일치하면 지속성을 신중하게 조정하십시오. 더 빠른 스토리지, 조정된 저장 정책, AOF 다시 쓰기 임계값 또는 메모리 설정이 필요할 수 있습니다. Redis가 순전히 일회용 캐시이고 비즈니스에서 데이터 손실을 수락하지 않는 한 벤치마크를 더 좋게 보이게 하기 위해 지속성을 비활성화하지 마십시오.

클라이언트 동작이 하나의 나쁜 명령어 없이 Redis에 과부하를 줄 수 있습니다

Redis 서버는 하나의 명백히 느린 명령어만큼이나 수백만 개의 작은 비효율적인 호출로 인해 손상될 수 있습니다. 200개의 순차적 GET 호출을 만드는 페이지는 개별 GET이 모두 빠르더라도 느리게 느껴질 것입니다.

애플리케이션이 많은 독립적인 명령어를 필요로 하고 함께 응답을 수신할 수 있는 경우 파이프라이닝을 사용하십시오:

GET user:1
GET user:2
GET user:3

파이프라인으로 전송하면 명령어당 왕복 시간을 피할 수 있습니다. 파이프라이닝은 좋은 데이터 모델링을 대체하지 않으며 배치가 너무 크면 메모리 사용량이 증가할 수 있습니다. 적당한 배치 크기로 시작하고 측정하십시오.

또한 연결 풀을 검사하십시오. 애플리케이션 로그에 Redis 호출이 500ms가 걸리지만 Redis에 느린 명령어가 표시되지 않으면 앱이 사용 가능한 연결을 기다리고 있을 수 있습니다. 기존 연결이 왜 바쁜지 확인한 후에만 풀을 늘리십시오. 더 큰 풀은 Redis에 대한 압력을 증가시키면서 증상을 숨길 수 있습니다.

실용적인 인시던트 체크리스트

Redis 지연 시간이 사용자에게 피해를 주는 경우 다음 순서로 사실을 수집하십시오:

date -u
redis-cli PING
redis-cli --latency -i 1
redis-cli SLOWLOG GET 20
redis-cli INFO commandstats
redis-cli INFO clients
redis-cli INFO memory
redis-cli INFO persistence
redis-cli LATENCY LATEST

그런 다음 무엇이 변경되었는지 질문하십시오: 배포, 새 엔드포인트, 데이터 성장 이벤트, 배치 작업, 마이그레이션, 대시보드 쿼리, 새 캐시 키 패턴 또는 지속성 다시 쓰기. Redis 속도 저하는 종종 인기 있게 된 단일 액세스 패턴이나 예상보다 훨씬 커진 키와 관련이 있습니다.

각 느린 명령어에 대해 키 패턴과 소유자를 기록하십시오. "느린 SMEMBERS"로는 충분하지 않습니다. "추천 서비스가 제한 없이 성장할 수 있는 집합에서 SMEMBERS product:123:viewers를 호출합니다"는 실행 가능합니다.

성능 튜닝 체크리스트 요약

SLOWLOG 활성화 및 모니터링: 주기적으로 SLOWLOG GET을 검토하여 반복되는 느린 명령어를 식별하십시오. 필요한 경우 slowlog-log-slower-than을 조정하십시오.
MONITOR를 신중하게 사용: 속도 저하가 의심되는 동안 실시간 디버깅에 사용하되, 즉시 비활성화하십시오.
대규모 프로덕션 키 공간에서 KEYS 사용 금지: 키 검색이 실제로 필요한 경우 증분 반복을 위해 SCAN을 사용하십시오.
Lua 스크립트 최적화: EVAL 및 EVALSHA 스크립트가 효율적이고 과도하게 오래 실행되지 않는지 확인하십시오.
대규모 데이터 구조를 반복적으로 처리: 전체 컬렉션을 가져오는 대신 SSCAN, ZSCAN, 제한이 있는 LRANGE 또는 SCAN을 사용하십시오.
명령어 인수 분석: 명령어에 전달된 인수가 예기치 않은 동작(예: 매우 큰 카운트, 복잡한 패턴)을 유발하지 않는지 확인하십시오.
서버 리소스 모니터링: Redis 서버 CPU, 메모리 및 네트워크 사용량을 주시하십시오. 느린 명령어는 때때로 서버 부하의 증상일 수 있습니다.
클라이언트 측 최적화: 애플리케이션이 명령어를 너무 빠르게 또는 비효율적인 배치로 보내지 않는지 확인하십시오. 적절한 경우 여러 명령어에 파이프라이닝을 고려하십시오.

최종 확인

SLOWLOG를 사용하여 Redis 내부에서 느린 명령어를 찾고, 지연 도구를 사용하여 서버 측 스파이크를 포착하고, 애플리케이션 타이밍을 사용하여 클라이언트 대기를 포착하십시오. 그런 다음 임계값뿐만 아니라 액세스 패턴을 수정하십시오. 제한된 명령어, 더 작은 응답, 합리적인 배치 및 큰 키의 명확한 소유권은 일회성 튜닝 변경을 추적하는 것보다 Redis 성능에 더 많은 도움이 됩니다.