DevOps 지식 허브
DevOps 지식 허브

SLOWLOG 명령어를 사용하여 느린 Redis 쿼리 진단 및 해결

Redis의 SLOWLOG 명령 기능을 활용하여 데이터베이스 병목 현상을 정확히 찾아내고 해결하세요. 이 포괄적인 가이드는 `slowlog-log-slower-than` 및 `slowlog-max-len` 구성, 느린 쿼리 항목 검색 및 해석, 그리고 파이프라이닝 및 데이터 구조 튜닝과 같은 실용적인 최적화 전략 적용 방법을 안내합니다. 성능 저하를 효과적으로 진단하고, 비용이 많이 드는 명령어를 식별하며, Redis 배포가 빠르고 효율적으로 유지되도록 보장하여 궁극적으로 애플리케이션의 응답성과 안정성을 향상시키는 방법을 배우게 됩니다.

42 조회수

느린 Redis 쿼리 진단 및 해결을 위한 SLOWLOG 명령어 활용

Redis는 캐싱, 실시간 분석, 세션 관리 및 메시지 브로커링에 널리 사용되는 매우 빠른 인메모리 데이터 저장소입니다. Redis의 성능은 이를 기반으로 구축된 애플리케이션의 응답성에 매우 중요합니다. 하지만 Redis의 속도에도 불구하고, 잘못 최적화된 명령어 또는 예기치 않은 부하는 느린 쿼리를 유발하여 전반적인 애플리케이션 성능을 저하시키는 병목 현상을 초래할 수 있습니다.

이러한 성능 문제의 근본 원인을 식별하는 것이 해결을 위한 첫걸음입니다. 여기서 Redis의 내장 기능인 SLOWLOG가 매우 유용한 도구가 됩니다. 개발팀과 운영팀은 이를 통해 지정된 실행 시간을 초과하는 명령어를 세밀하게 기록하고 분석하여 잠재적인 데이터베이스 병목 현상과 비용이 많이 드는 작업에 대한 중요한 통찰력을 얻을 수 있습니다. 이 글에서는 Redis 배포에서 성능 저하를 진단하고 해결하기 위해 SLOWLOG 명령어를 이해하고, 구성하고, 활용하는 방법에 대해 안내합니다.

Redis SLOWLOG 기능 이해하기

SLOWLOG는 지정된 실행 시간을 초과하는 쿼리를 기록하는 시스템입니다. 이는 본질적으로 구성된 임계값보다 오래 걸린 명령어들의 인메모리 로그입니다. 기존의 파일 기반 로그와 달리 SLOWLOG는 Redis 메모리에 직접 저장되므로 디스크 I/O 오버헤드 없이 빠르게 액세스하고 관리할 수 있습니다.

SLOWLOG의 각 항목에는 여러 가지 정보가 포함됩니다. 고유한 순차 ID, 명령어가 기록된 Unix 타임스탬프, 명령의 총 실행 시간(마이크로초 단위), 명령어 자체(및 인수), 명령을 실행한 클라이언트의 IP 주소 및 포트, 클라이언트 이름(설정된 경우)입니다. 이러한 항목을 검토하면 특정 명령어를 정확히 파악하고, 패턴을 식별하며, 궁극적으로 Redis와의 애플리케이션 상호 작용을 최적화할 수 있습니다.

SLOWLOG 작동 방식: 구성 매개변수

SLOWLOG를 효과적으로 사용하기 전에 두 가지 주요 매개변수를 이해하고 구성하는 것이 중요합니다. 이 매개변수들은 어떤 항목이 기록되고 몇 개의 항목이 유지되는지를 제어합니다.

slowlog-log-slower-than

이 매개변수는 기록될 명령어의 실행 시간 임계값(마이크로초 단위)을 정의합니다. 이 지정된 값보다 오래 걸리는 명령어만 SLOWLOG에 기록됩니다. 이 값을 너무 낮게 설정하면 너무 많은 명령어가 기록되어 상당한 메모리를 소비하고 분석을 어렵게 만들 수 있습니다. 너무 높게 설정하면 실제로 느린 쿼리를 놓칠 수 있습니다.

  • 기본값: 10000 (10밀리초)
  • 권장 사항: 기본값으로 시작하고 애플리케이션의 성능 요구 사항에 따라 조정하십시오. 고성능 시스템의 경우 1000 마이크로초(1밀리초) 또는 100 마이크로초로 낮출 수 있습니다.
  • 특수 값: 0으로 설정하면 모든 명령어가 기록됩니다. 음수 값으로 설정하면 SLOWLOG가 완전히 비활성화됩니다.

현재 이 매개변수의 값을 볼 수 있습니다:

redis-cli config get slowlog-log-slower-than

새 값을 설정하려면(예: 5000 마이크로초 또는 5밀리초):

redis-cli config set slowlog-log-slower-than 5000

이 변경 사항을 영구적으로 적용하려면 redis.conf 파일을 업데이트하거나 Redis 버전 및 설정에서 지원하는 경우 CONFIG REWRITE를 사용해야 합니다.

slowlog-max-len

이 매개변수는 Redis가 SLOWLOG에 유지할 최대 항목 수를 지정합니다. 로그가 최대 길이에 도달하면 새 항목이 추가될 때 가장 오래된 항목이 자동으로 제거됩니다(FIFO - First In, First Out).

  • 기본값: 128개 항목
  • 권장 사항: 바쁜 프로덕션 시스템에는 기본값이 너무 작은 경우가 많습니다. 철저한 분석을 위해 충분한 기록을 확보하려면 1024 또는 4096으로 늘리는 것을 고려하되 메모리 사용량을 염두에 두어야 합니다.

현재 값을 볼 수 있습니다:

redis-cli config get slowlog-max-len

새 값을 설정하려면(예: 1024개 항목):

redis-cli config set slowlog-max-len 1024

마찬가지로 이 변경 사항을 redis.conf 파일에 영구적으로 저장해야 합니다.

SLOWLOG 항목 검색 및 분석

SLOWLOG가 구성되면 일련의 명령어를 사용하여 상호 작용할 수 있습니다.

SLOWLOG GET

이 명령어는 SLOWLOG에서 항목을 검색하는 데 사용됩니다. 선택적으로 count를 지정하여 가장 최근의 특정 수의 항목을 검색할 수 있습니다.

  • SLOWLOG GET: 현재 로그의 모든 항목을 검색합니다.
  • SLOWLOG GET <count>: 최신 <count> 개의 항목을 검색합니다.

예시:

# 최근 10개의 느린 로그 항목 검색
redis-cli slowlog get 10

예시 출력(명확성을 위해 간략화됨):

1) 1) (integer) 12345        # 로그 항목의 고유 ID
   2) (integer) 1678886400   # Unix 타임스탬프 (예: 2023년 3월 15일, UTC 기준 12:00:00 PM)
   3) (integer) 25000        # 실행 시간 (마이크로초 단위, 25 ms)
   4) 1) "LRANGE"           # 명령어
      2) "mybiglist"       # 인수 1
      3) "0"               # 인수 2
      4) "-1"              # 인수 3
   5) "127.0.0.1:54321"  # 클라이언트 IP 및 포트
   6) "client-name-app" # 클라이언트 이름 (설정된 경우)
...

SLOWLOG LEN

이 명령어는 SLOWLOG의 현재 항목 수를 반환합니다.

redis-cli slowlog len

출력:

(integer) 5

SLOWLOG RESET

이 명령어는 SLOWLOG에서 모든 항목을 지웁니다. 기존 항목을 분석한 후 새로운 성능 데이터를 캡처하기 위해 신선한 로그로 시작하려는 경우 유용합니다.

redis-cli slowlog reset

출력:

OK

SLOWLOG 출력 해석

각 항목은 중요한 정보를 제공합니다:

  1. 고유 ID: 순차적 식별자. 특정 이벤트를 추적하는 데 유용합니다.
  2. 타임스탬프: 명령어가 실행된 시점. 느린 쿼리를 애플리케이션 배포 변경 또는 특정 부하 기간과 연관시키는 데 도움이 됩니다.
  3. 실행 시간 (마이크로초): 가장 중요한 지표. 명령이 완료되는 데 걸린 시간을 정확히 알려줍니다. 높은 값은 잠재적인 병목 현상을 나타냅니다.
  4. 명령어 및 인수: 정확한 Redis 명령어와 매개변수. 느린 작업이 무엇인지 이해하는 데 중요합니다(예: KEYS *, 매우 큰 목록에 대한 LRANGE 0 -1, LIMIT이 없는 SORT).
  5. 클라이언트 주소: 명령을 실행한 클라이언트의 IP 주소 및 포트. 소스 애플리케이션 또는 서비스로 추적하는 데 도움이 됩니다.
  6. 클라이언트 이름: 애플리케이션에서 CLIENT SETNAME을 설정한 경우(더 나은 가시성을 위해 강력히 권장됨), 이 필드는 느린 쿼리를 실행한 애플리케이션의 특정 부분을 나타내는 추가적인 컨텍스트를 제공합니다.

느린 명령어 식별을 위한 실제 예시

느린 명령어를 시뮬레이션하고 SLOWLOG가 이를 어떻게 캡처하는지 살펴보겠습니다.

먼저 시연을 위해 slowlog-log-slower-than을 낮은 값(예: 1000 마이크로초, 즉 1밀리초)으로 설정합니다:

redis-cli config set slowlog-log-slower-than 1000

다음으로, 큰 데이터셋에 적용될 때 잠재적으로 느릴 수 있는 작업(예: KEYS * 또는 많은 요소를 가진 목록에 대한 LRANGE)을 수행합니다.

큰 목록을 만들어 봅시다:

for i in {1..100000}; do redis-cli LPUSH mybiglist $i; done

이제 이 큰 목록의 모든 요소를 검색하는 LRANGE 명령어를 실행합니다:

redis-cli LRANGE mybiglist 0 -1

이 명령어는 1밀리초 이상 걸릴 가능성이 높습니다.

마지막으로 SLOWLOG를 확인합니다:

redis-cli slowlog get 1

다음과 유사한 출력을 볼 수 있습니다(값은 달라질 수 있습니다):

1) 1) (integer) 12346
   2) (integer) 1678886450
   3) (integer) 15432 # 이것이 마이크로초 단위의 느린 실행 시간입니다.
   4) 1) "LRANGE"
      2) "mybiglist"
      3) "0"
      4) "-1"
   5) "127.0.0.1:54322"
   6) ""

출력에는 LRANGE mybiglist 0 -1 명령어, 실행 시간(15432 마이크로초 또는 15.432ms) 및 발생 시간이 명확하게 표시됩니다. 이는 전체 큰 목록을 가져오는 데 상당한 시간이 소요된다는 것을 즉시 알려줍니다.

느린 쿼리 해결 전략

SLOWLOG를 사용하여 느린 쿼리를 식별한 후에는 다음 단계는 이를 최적화하는 것입니다. 일반적인 전략은 다음과 같습니다.

  1. 데이터 구조 및 액세스 패턴 최적화:

    • 대규모 데이터셋에 대한 O(N) 명령어 피하기: LRANGE 0 -1(모든 요소 가져오기), SMEMBERS(모든 세트 멤버 가져오기), HGETALL(모든 해시 필드/값 가져오기), SORT(LIMIT 없음)와 같은 명령어는 느릴 수 있습니다. 대규모 컬렉션을 처리해야 하는 경우, 모든 것을 한 번에 가져오는 대신 SCAN, SSCAN, HSCAN, ZSCAN을 사용하여 반복하는 것을 고려하십시오.
    • 적절한 데이터 구조 사용: 예를 들어, 객체의 속성을 자주 가져와야 하는 경우 각 속성에 대한 개별 키를 저장하는 대신 해시를 사용하십시오.
    • 결과 제한: 목록 또는 정렬된 세트의 경우 전체 구조를 가져오는 대신 합리적인 제한이 있는 LRANGE <start> <end> 또는 ZRANGE <start> <end>를 사용하십시오.

  2. 파이프라이닝: 명령어를 하나씩 보내는 대신, 파이프라이닝을 사용하여 여러 명령어를 단일 요청으로 묶습니다. 이렇게 하면 네트워크 왕복 시간(RTT) 오버헤드가 줄어들어 개별 명령어가 빠르더라도 애플리케이션 속도를 크게 높일 수 있습니다.

    ```python

    파이프라이닝 없음 (여러 RTT로 인해 느림)

    r.set('key1', 'value1')
    r.set('key2', 'value2')

    파이프라이닝 사용 (더 빠름, 단일 RTT)

    pipe = r.pipeline()
    pipe.set('key1', 'value1')
    pipe.set('key2', 'value2')
    pipe.execute()
    ```

  3. Lua 스크립팅 (EVAL): 여러 Redis 명령어를 포함하는 복잡한 작업이 원자적으로 또는 최소한의 RTT로 실행되어야 하는 경우 Lua 스크립트 사용을 고려하십시오. 스크립트는 Redis 서버에서 직접 실행되어 네트워크 지연 시간을 줄이고 원자성을 보장합니다. 그러나 실행 시간이 긴 Lua 스크립트는 Redis를 차단할 수 있으므로 신중하게 최적화해야 합니다.

  4. 프로덕션에서 KEYS 사용 피하기: KEYS 명령어는 O(N)(N은 데이터베이스의 키 개수)이며, 특히 대규모 데이터베이스에서는 Redis 서버를 장시간 차단할 수 있습니다. 프로덕션 환경에서 키를 반복하려면 SCAN을 사용하십시오. SCAN은 일시 중지하고 다시 시작할 수 있는 이터레이터와 유사한 기능을 제공하여 장시간 차단 작업을 피합니다.

    ```bash

    프로덕션에서 비권장

    redis-cli KEYS *

    반복을 위해 프로덕션에서 권장

    redis-cli SCAN 0 MATCH user:* COUNT 100
    ```

  5. 연결 풀링: 애플리케이션이 Redis에 대한 연결을 효율적으로 관리하기 위해 적절한 연결 풀링을 사용하는지 확인하십시오. 각 명령에 대해 연결을 열고 닫는 것은 리소스 집약적일 수 있습니다.

  6. 샤딩 및 클러스터링: 데이터셋 또는 워크로드가 단일 Redis 인스턴스가 처리할 수 있는 용량을 초과하여 성장하는 경우, 여러 Redis 인스턴스에 데이터를 샤딩하거나 Redis 클러스터를 채택하는 것을 고려하십시오. 이렇게 하면 부하와 데이터가 분산되어 단일 인스턴스가 병목 현상이 되는 것을 방지할 수 있습니다.

  7. 읽기 복제본: 읽기 집약적인 워크로드의 경우, 읽기 복제본으로 읽기 쿼리를 오프로드하십시오. 이렇게 하면 읽기 처리량이 확장되고 기본 인스턴스의 부하가 줄어들어 쓰기에 집중할 수 있습니다.

SLOWLOG 사용 모범 사례

  • 정기적인 모니터링: 설정하고 잊지 마십시오. 특히 배포 후 또는 최대 부하 시간 동안 SLOWLOG 항목을 정기적으로 확인하십시오.
  • 적절한 임계값: 애플리케이션에서 허용 가능한 지연 시간을 기준으로 slowlog-log-slower-than을 조정하십시오. 어떤 앱에게는 느린 것이 다른 앱에게는 정상일 수 있습니다.
  • 충분한 로그 길이: 의미 있는 기록을 유지할 만큼 slowlog-max-len을 길게 설정하되, 과도한 메모리를 소비할 만큼 크지 않게 설정하십시오.
  • 정기적으로 비우기: 항목을 분석한 후 SLOWLOG RESET을 사용하여 새 데이터를 얻거나, SLOWLOG를 모니터링 시스템과 통합하는 경우 이 프로세스를 자동화하는 것을 고려하십시오.
  • 클라이언트 이름 지정: 애플리케이션 코드에서 CLIENT SETNAME <name>을 사용하십시오. 이렇게 하면 SLOWLOG 항목에 유용한 컨텍스트가 추가되어 느린 명령어를 애플리케이션의 특정 부분으로 추적하는 것이 더 쉬워집니다.

결론

Redis SLOWLOG 명령어는 Redis 기반 애플리케이션의 성능과 안정성을 유지하는 데 필수적인 도구입니다. SLOWLOG를 효과적으로 구성하고 정기적으로 그 출력을 분석함으로써, 그렇지 않으면 간과될 수 있는 느린 쿼리를 선제적으로 식별, 진단 및 해결하여 애플리케이션 응답성을 개선하고 사용자 경험을 향상시킬 수 있습니다. Redis 성능 최적화는 애플리케이션의 데이터 액세스 패턴을 이해하고, 올바른 Redis 명령어와 데이터 구조를 선택하며, 지속적인 모니터링을 포함하는 지속적인 프로세스임을 기억하십시오. SLOWLOG는 정보에 입각한 최적화 결정을 내리는 데 필요한 중요한 가시성을 제공합니다.