DevOps 지식 허브
DevOps 지식 허브

Redis 성능 병목 현상 상위 5가지 및 해결 방법

일반적인 병목 현상에 대한 이 필수 가이드로 Redis 배포의 최고 성능을 발휘하세요. 느린 O(N) 명령, 과도한 네트워크 왕복, 메모리 압박 및 비효율적인 제거 정책, 지속성 오버헤드, CPU 바운드 작업과 같은 문제를 식별하고 해결하는 방법을 배우세요. 이 문서는 파이프라이닝 및 `SCAN` 활용부터 데이터 구조 및 지속성 최적화에 이르기까지 모든 캐싱, 메시징 및 데이터 스토리지 요구 사항에 대해 Redis 인스턴스를 빠르고 안정적으로 유지하기 위한 실행 가능한 단계, 실용적인 예제 및 모범 사례를 제공합니다.

68 조회수

Redis 성능 병목 현상 Top 5 및 해결 방법

Redis는 매우 빠른 인메모리 데이터 구조 스토어로, 캐시, 데이터베이스 및 메시지 브로커로 널리 사용됩니다. 단일 스레드 방식과 효율적인 데이터 처리 방식은 인상적인 성능에 기여합니다. 그러나 다른 강력한 도구와 마찬가지로, Redis도 올바르게 구성되거나 사용되지 않으면 성능 병목 현상을 겪을 수 있습니다. 이러한 일반적인 문제점들을 이해하고 해결 방법을 아는 것은 응답성이 뛰어나고 신뢰할 수 있는 애플리케이션을 유지하는 데 중요합니다.

이 글에서는 Redis 환경에서 발생하는 상위 5가지 일반적인 성능 병목 현상에 대해 자세히 설명합니다. 각 병목 현상에 대해 근본적인 원인을 설명하고, 식별 방법을 시연하며, 문제를 즉시 해결하기 위한 실행 가능한 단계, 코드 예제 및 모범 사례를 제공할 것입니다. 이 가이드를 마치면 가장 흔한 Redis 성능 문제를 진단하고 해결하는 방법에 대한 포괄적인 이해를 얻게 되어, 애플리케이션이 Redis를 최대한 활용할 수 있도록 할 것입니다.

1. 느린 명령 및 O(N) 연산

Redis는 매우 빠른 O(1) 연산으로 알려져 있지만, 특히 전체 데이터 구조에 대해 작동하는 많은 명령은 O(N) 복잡도를 가질 수 있습니다 (여기서 N은 요소의 수). N이 클 경우, 이러한 연산은 Redis 서버를 상당한 시간 동안 차단하여 다른 모든 들어오는 명령에 대한 지연 시간을 증가시킬 수 있습니다.

일반적인 문제 유발자:
* KEYS: 데이터베이스의 모든 키를 순회합니다. 프로덕션 환경에서 매우 위험합니다.
* FLUSHALL/FLUSHDB: 전체 데이터베이스(또는 현재 데이터베이스)를 지웁니다.
* HGETALL, SMEMBERS, LRANGE: 각각 매우 큰 해시, 세트 또는 리스트에 사용될 때.
* SORT: 큰 리스트에서 CPU 사용량이 매우 높을 수 있습니다.
* 큰 컬렉션을 순회하는 Lua 스크립트.

식별 방법:

  • SLOWLOG GET <count>: 이 명령은 구성 가능한 실행 시간(slowlog-log-slower-than)을 초과한 명령을 기록하는 슬로우 로그에서 항목을 검색합니다.
  • LATENCY DOCTOR: 느린 명령으로 인한 것을 포함하여 Redis의 지연 시간 이벤트에 대한 분석을 제공합니다.
  • 모니터링: 모니터링 시스템을 통해 redis_commands_latency_microseconds_total 또는 유사한 메트릭을 주시하십시오.

해결 방법:

  • 프로덕션에서 KEYS 사용 피하기: 대신 SCAN을 사용하십시오. SCAN은 한 번에 소수의 키를 반환하는 반복자이며, Redis가 반복 사이에 다른 요청을 처리할 수 있도록 합니다.
    bash # 예시: SCAN으로 순회 redis-cli SCAN 0 MATCH user:* COUNT 100
  • 데이터 구조 최적화: 매우 큰 해시/세트/리스트를 저장하는 대신, 더 작고 관리하기 쉬운 조각으로 분해하는 것을 고려하십시오. 예를 들어, 100,000개의 필드를 가진 user:100:profile 해시가 있다면, 프로필의 일부만 한 번에 필요한 경우 user:100:contact_info, user:100:preferences 등으로 분할하는 것이 더 효율적일 수 있습니다.
  • 범위 쿼리를 현명하게 사용하기: LRANGE의 경우, 전체 리스트를 검색하는 것을 피하십시오. 더 작은 덩어리를 가져오거나 고정 크기 리스트의 경우 TRIM을 사용하십시오.
  • DEL 대신 UNLINK 활용: 큰 키를 삭제할 때, UNLINK는 실제 메모리 회수를 비블로킹 백그라운드 스레드에서 수행하며 즉시 반환됩니다.
    bash # 큰 키를 비동기적으로 삭제 UNLINK my_large_key
  • Lua 스크립트 최적화: 스크립트가 간결하고 큰 컬렉션을 순회하지 않도록 보장하십시오. 복잡한 로직이 필요한 경우, 일부 처리를 클라이언트 또는 외부 서비스로 오프로드하는 것을 고려하십시오.

2. 네트워크 지연 시간 및 과도한 왕복 통신

Redis의 놀라운 속도에도 불구하고, 애플리케이션과 Redis 서버 간의 네트워크 왕복 시간(RTT)은 심각한 병목 현상이 될 수 있습니다. 작고 개별적인 명령을 많이 보내는 것은 Redis 처리 시간이 최소화되더라도 각 명령에 대해 RTT 페널티를 발생시킵니다.

식별 방법:

  • 높은 전반적인 애플리케이션 지연 시간: Redis 명령 자체는 빠르지만 전체 작업 시간이 높을 경우.
  • 네트워크 모니터링: ping 및 traceroute와 같은 도구는 RTT를 보여줄 수 있지만, 애플리케이션 수준 모니터링이 더 좋습니다.
  • Redis INFO clients 섹션: 연결된 클라이언트를 보여줄 수 있지만, RTT 문제를 직접적으로 나타내지는 않습니다.

해결 방법:

  • 파이프라이닝: 이것이 가장 효과적인 해결책입니다. 파이프라이닝을 사용하면 클라이언트가 각 명령에 대한 응답을 기다리지 않고 단일 TCP 패킷으로 여러 명령을 Redis에 보낼 수 있습니다. Redis는 이를 순차적으로 처리하고 모든 응답을 단일 응답으로 다시 보냅니다.
    ```python
    # Python Redis 클라이언트 파이프라이닝 예제
    import redis
    r = redis.Redis(host='localhost', port=6379, db=0)

    pipe = r.pipeline()
    pipe.set('key1', 'value1')
    pipe.set('key2', 'value2')
    pipe.get('key1')
    pipe.get('key2')
    results = pipe.execute()
    print(results) # [True, True, b'value1', b'value2']
    `` * **트랜잭션 (MULTI/EXEC)**: 파이프라이닝과 유사하지만, 원자성을 보장합니다 (모든 명령이 실행되거나 아무것도 실행되지 않음).MULTI/EXEC`는 본질적으로 명령을 파이프라인으로 처리하지만, 그 주된 목적은 원자성입니다. 순수한 성능 향상을 위해서는 기본적인 파이프라이닝으로 충분합니다.
    * Lua 스크립팅: 중간 로직이나 조건부 실행이 필요한 복잡한 다중 명령 연산의 경우, Lua 스크립트는 Redis 서버에서 직접 실행됩니다. 이는 전체 일련의 연산을 단일 서버 측 실행으로 묶어 여러 RTT를 제거합니다.

3. 메모리 압박 및 축출 정책

Redis는 인메모리 데이터베이스입니다. 물리적 메모리가 부족하면 성능이 크게 저하됩니다. 운영 체제가 디스크로 스와핑을 시작할 수 있으며, 이는 극도로 높은 지연 시간으로 이어집니다. Redis가 축출 정책으로 구성된 경우, maxmemory에 도달하면 키를 제거하기 시작하며, 이는 CPU 사이클도 소비합니다.

식별 방법:

  • INFO memory: used_memory, used_memory_rss, maxmemory를 확인하십시오. maxmemory_policy를 찾으십시오.
  • 높은 축출 비율: evicted_keys 카운트가 빠르게 증가하는 경우.
  • 시스템 수준 모니터링: Redis 호스트에서 높은 스왑 사용량 또는 낮은 사용 가능 RAM을 주시하십시오.
  • OOM (메모리 부족) 오류: 로그 또는 클라이언트 응답에서.

해결 방법:

  • maxmemory 및 maxmemory-policy 설정: redis.conf에서 OOM 오류를 방지하기 위해 합리적인 maxmemory 제한을 구성하고 적절한 maxmemory-policy (예: allkeys-lru, volatile-lru, noeviction)를 지정하십시오. noeviction은 일반적으로 캐시에 권장되지 않습니다. 메모리가 가득 찼을 때 쓰기 오류가 발생하기 때문입니다.
    ini # redis.conf maxmemory 2gb maxmemory-policy allkeys-lru
  • 키에 TTL (Time-To-Live) 설정: 임시 데이터가 자동으로 만료되도록 보장하십시오. 이는 특히 캐싱 시나리오에서 메모리 관리에 필수적입니다.
    bash SET mykey "hello" EX 3600 # 1시간 후 만료
  • 데이터 구조 최적화: 가능한 경우 Redis의 메모리 효율적인 데이터 유형(예: ziplist로 인코딩된 해시, intset으로 인코딩된 세트/정렬된 세트)을 사용하십시오. 작은 해시, 리스트 및 세트는 더 압축적으로 저장될 수 있습니다.
  • 스케일 업: Redis 서버의 RAM을 늘리십시오.
  • 스케일 아웃 (샤딩): 클라이언트 측 샤딩 또는 Redis Cluster를 사용하여 데이터를 여러 Redis 인스턴스(마스터)에 분산시키십시오.

4. 영속성 오버헤드 (RDB/AOF)

Redis는 RDB 스냅샷 및 AOF(Append Only File)와 같은 영속성 옵션을 제공합니다. 데이터 내구성에 중요하지만, 이러한 작업은 특히 디스크 I/O가 느리거나 제대로 구성되지 않은 시스템에서 성능 오버헤드를 유발할 수 있습니다.

식별 방법:

  • INFO persistence: rdb_last_save_time, aof_current_size, aof_last_bgrewrite_status, aof_rewrite_in_progress, rdb_bgsave_in_progress를 확인하십시오.
  • 높은 디스크 I/O: 영속성 이벤트 중에 디스크 사용량 급증을 보여주는 모니터링 도구.
  • BGSAVE 또는 BGREWRITEAOF 차단: 특히 큰 데이터셋에서 긴 포크 시간은 Redis를 일시적으로 차단할 수 있습니다 (최신 Linux 커널에서는 덜 일반적임).

해결 방법:

  • AOF에 appendfsync 튜닝: 이는 AOF가 디스크에 동기화되는 빈도를 제어합니다.
    • appendfsync always: 가장 안전하지만 가장 느립니다 (모든 쓰기 시 동기화).
    • appendfsync everysec: 안전성과 성능의 좋은 균형 (매초 동기화, 기본값).
    • appendfsync no: 가장 빠르지만 가장 안전하지 않습니다 (OS가 동기화 시기를 결정). 대부분의 프로덕션 환경에서는 everysec을 선택하십시오.
      ```ini

    redis.conf

    appendfsync everysec
    ```

  • RDB에 save 포인트 최적화: 너무 자주 또는 너무 드문 스냅샷을 피하기 위해 save 규칙 (save <seconds> <changes>)을 구성하십시오. 종종 하나 또는 두 개의 규칙이면 충분합니다.
  • 전용 디스크 사용: 가능하다면, AOF 및 RDB 파일을 별도의 빠른 SSD에 배치하여 I/O 경합을 최소화하십시오.
  • 영속성을 복제본으로 오프로드: 복제본을 설정하고 주 서버의 영속성을 비활성화하여 복제본이 마스터의 성능에 영향을 주지 않고 RDB 스냅샷 또는 AOF 재작성을 처리하도록 합니다. 이는 데이터 손실 시나리오를 신중하게 고려해야 합니다.
  • vm.overcommit_memory = 1: 이 Linux 커널 매개변수가 1로 설정되어 있는지 확인하십시오. 이는 큰 Redis 프로세스를 포크할 때 메모리 과다 할당 문제로 인해 BGSAVE 또는 BGREWRITEAOF가 실패하는 것을 방지합니다.

5. 단일 스레드 방식 및 CPU 바운드 연산

Redis는 주로 단일 스레드(명령 처리를 위해)에서 실행됩니다. 이는 잠금을 단순화하고 컨텍스트 전환 오버헤드를 줄이지만, 동시에 모든 다른 클라이언트 요청을 차단하는 단일 장기 실행 명령 또는 Lua 스크립트를 의미하기도 합니다. Redis 서버의 CPU 사용량이 지속적으로 높다면, 이는 CPU 바운드 연산의 강력한 지표입니다.

식별 방법:

  • 높은 CPU 사용량: 서버 수준 모니터링에서 Redis 프로세스가 CPU 코어의 100%를 소비하는 것을 보여줍니다.
  • 지연 시간 증가: INFO commandstats에서 특정 명령의 평균 지연 시간이 비정상적으로 높은 것을 보여줍니다.
  • SLOWLOG: CPU 집약적인 명령도 강조 표시합니다.

해결 방법:

  • 대규모 연산 분해: 섹션 1에서 논의했듯이, 대규모 데이터셋에 대한 O(N) 명령을 피하십시오. 대량의 데이터를 처리해야 하는 경우 SCAN을 사용하고 클라이언트 측에서 청크를 처리하거나 작업을 분산하십시오.
  • Lua 스크립트 최적화: Lua 스크립트가 고도로 최적화되어 있고 대규모 데이터 구조에 대한 장기 실행 루프 또는 복잡한 계산을 포함하지 않도록 보장하십시오. Lua 스크립트는 원자적으로 실행되며 완료될 때까지 서버를 차단한다는 것을 기억하십시오.
  • 읽기 전용 복제본: 읽기 작업이 많은 연산을 하나 이상의 읽기 전용 복제본으로 오프로드하십시오. 이는 읽기 부하를 분산하여 마스터가 쓰기 및 중요한 읽기에 집중할 수 있도록 합니다.
  • 샤딩 (Redis Cluster): 단일 인스턴스의 용량을 초과하는 극도로 높은 처리량 또는 대규모 데이터셋의 경우, Redis Cluster를 사용하여 데이터를 여러 Redis 마스터 인스턴스에 샤딩하십시오. 이는 CPU 및 메모리 부하를 모두 분산합니다.
  • client-output-buffer-limit: 잘못 구성된 클라이언트 출력 버퍼(예: pub/sub 클라이언트용)는 Redis가 느린 클라이언트에 대해 많은 양의 데이터를 버퍼링하게 하여 메모리 및 CPU를 소비할 수 있습니다. 느린 클라이언트로 인한 리소스 고갈을 방지하기 위해 이 제한을 조정하십시오.

결론

Redis 성능 최적화는 신중한 모니터링, 애플리케이션의 접근 패턴 이해, 사전 예방적 구성을 포함하는 지속적인 프로세스입니다. 느린 명령, 네트워크 지연 시간, 메모리 압박, 영속성 오버헤드, CPU 바운드 연산과 같은 이 다섯 가지 일반적인 병목 현상을 해결함으로써 Redis 배포의 응답성 및 안정성을 크게 향상시킬 수 있습니다.

SLOWLOG, LATENCY DOCTOR, INFO 명령과 같은 도구를 정기적으로 사용하십시오. 이를 CPU, 메모리, 디스크 I/O에 대한 강력한 시스템 수준 모니터링과 결합하십시오. 잘 작동하는 Redis 인스턴스는 많은 고성능 애플리케이션의 중추이며, 이를 적절히 튜닝하는 데 시간을 투자하는 것이 전체 시스템에 상당한 이점을 가져다줄 것입니다.