CHAPTER 06 트러블슈팅 [PART 02 실전]

CHAPTER 06 트러블슈팅은 실전 환경에서 Redis 성능 저하나 장애 발생 시 원인을 진단하고 해결하는 방법을 소개하는 장이다.

I. INFO 명령어로 서버 정보 읽기

1. INFO 명령어 개요

• Redis에서 INFO 명령어를 사용하면 서버 내부 상태를 확인할 수 있음
• redis-cli에서 실행하면 여러 항목의 정보를 출력하며 트러블슈팅 시 가장 먼저 활용되는 명령어임

127.0.0.1:6379> INFO

(1) 명령어 기본 구조 및 옵션

• INFO [SECTION] 형태로 실행 가능하며 출력 범위를 좁혀서 확인할 수 있음

INFO all           # 전체 정보 출력
INFO memory        # 메모리 정보
INFO cpu           # CPU 관련 정보
INFO stats         # 통계 정보
INFO keyspace      # 키 공간 관련 정보

1) 주요 섹션 설명

• Server
  Redis 버전, 운영체제, 실행 시간, 실행 모드 등 서버 기본 정보 제공
• Clients
  클라이언트 수, 차단된 클라이언트 수 등 접속 관련 정보 확인 가능
• Memory
  전체 메모리 사용량, RSS, 메모리 단편화 비율 등 메모리 사용 상태 확인 가능
• Persistence
  RDB나 AOF 설정 상태, 마지막 저장 시각 등 영속화 관련 정보 제공
• Stats
  명령어 처리 수, 키 히트/미스 수, 만료 수, 제거 수 등 통계 정보 확인 가능
• Replication
  레플리케이션 구성 및 상태 정보 제공
• CPU
  Redis 프로세스가 사용한 사용자 및 시스템 CPU 시간 확인 가능
• Keyspace
  데이터베이스별 키 개수, 만료 설정된 키 개수, 평균 TTL 확인 가능

II. 지연 시간 조사

1. 지연 시간의 의미

• Redis는 싱글 스레드 기반으로 동작하므로 하나의 요청이 오래 걸리면 그만큼 전체 지연이 발생할 수 있음
• redis-cli에서 실행한 명령어가 평소보다 늦게 끝나는 경우나 실제 서비스에서 느려지는 경우는 지연이 발생하고 있다는 신호임
• 이럴 때는 Redis 서버 자체의 문제인지 애플리케이션 또는 네트워크의 문제인지 확인해야 함

(1) 지연 시간 확인 명령어

• Redis에는 지연 시간을 확인할 수 있는 여러 도구가 내장되어 있음
• 명령어별로 각기 다른 관점에서 지연 원인을 확인할 수 있음

1) SLOWLOG

• SLOWLOG는 Redis 서버가 처리하는 명령어 중 특정 시간 이상 소요된 명령어의 정보를 기록함
• 지연 시간 기준은 slowlog-log-slower-than 지시자로 설정 가능함
• 기본값은 10000마이크로초로 0으로 설정하면 모든 명령어가 기록됨
• 저장할 수 있는 최대 항목 수는 slowlog-max-len으로 설정함

127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 10000
127.0.0.1:6379> CONFIG SET slowlog-max-len 128
127.0.0.1:6379> SLOWLOG GET 5

• SLOWLOG 항목에는 ID, 타임스탬프, 실행 시간, 명령어가 포함됨
• 오래 걸리는 명령어가 실제로 어떤 것인지 확인할 수 있음
• 느린 명령어가 전체 지연을 유발하고 있는지 확인할 때 사용함

2) LATENCY

• Redis는 지연 시간을 수집하는 전용 기능도 제공함
• latency-monitor-threshold를 설정하면 지정한 시간 이상 지연이 발생한 이벤트를 자동으로 기록함
• ASCII 그래프로 표시할 수도 있어서 시각적으로 확인 가능함

127.0.0.1:6379> CONFIG SET latency-monitor-threshold 100
127.0.0.1:6379> LATENCY DOCTOR
127.0.0.1:6379> LATENCY GRAPH command
127.0.0.1:6379> LATENCY HISTORY fork

• 이벤트 종류로는 command, fork, aof-write, expire-cycle 등이 있음
• 예를 들어 fork 이벤트의 지연이 발생했다면 RDB나 AOF 저장 작업에서 병목이 생겼을 수 있음

---

III. 메모리 문제

1. 메모리 사용량 확인

• 메모리 문제가 발생하면 가장 먼저 INFO memory와 MEMORY 계열 명령어를 확인함
• used_memory와 used_memory_rss를 비교해서 단편화 여부나 jemalloc 관련 문제를 확인할 수 있음
• mem_fragmentation_ratio는 메모리 단편화율로 1보다 크면 단편화가 발생하고 있다는 뜻임
  일반적으로 1.1 이하가 바람직하며 1.5를 넘으면 비정상으로 판단할 수 있음

127.0.0.1:6379> INFO memory

(1) MEMORY 명령어 계열

• Redis 4.0 이후에는 메모리 사용 상황을 더 자세히 확인할 수 있는 MEMORY 계열 명령어가 도입됨

1) MEMORY USAGE

• 특정 키가 얼마나 메모리를 점유하고 있는지를 바이트 단위로 확인할 수 있음

127.0.0.1:6379> MEMORY USAGE mykey

2) MEMORY STATS

• Redis 전체 메모리 사용 현황을 다양한 카테고리로 출력함
• allocator 별 분배 현황, keyspace overhead, peak memory, lua 사용량 등 다양한 정보를 포함함

127.0.0.1:6379> MEMORY STATS

3) MEMORY PURGE

• jemalloc은 기본적으로 사용이 끝난 메모리를 즉시 반환하지 않음
• 이로 인해 RSS는 높지만 실제 Redis가 사용하는 메모리는 적은 경우가 발생함
• Redis 4.0 이후에는 MEMORY PURGE 명령어로 jemalloc의 더티 페이지를 수동 회수할 수 있음
• 메모리를 확보해야 하는 상황에서 유용하게 사용할 수 있음

127.0.0.1:6379> MEMORY PURGE

4) 기타 확인 포인트

• evicted_keys가 증가하고 있다면 LRU 정책에 따라 강제로 키가 제거되고 있는 상태임
• maxmemory 설정값을 초과하면 eviction 정책에 따라 키가 삭제되므로, 예상치 못한 데이터 손실로 이어질 수 있음
• lazyfree-lazy-eviction 등을 활용하면 메모리 해제를 비동기로 처리할 수 있음