Redis CLI - 서버 터져서 멘붕일 때 쓰는 거

밤 늦게 알람 울렸다. Redis 연결 에러 ECONNREFUSED 127.0.0.1:6379. 급하게 RedisInsight 켜려고 했는데 Wine 실행 에러나고 개짜증남. 그래서 redis-cli 쳤는데 바로 들어가짐. 아 진짜 왜 처음부터 이거 안 썼나 싶었음.

Redis 깔면 redis-cli도 같이 깔린다. 터미널에서 Redis 바로 건드릴 수 있다.

CLI 쓰는 이유 - 실제 경험담

4시간 삽질하고 깨달은 교훈
작년에 Redis 6점 몇 버전에서 갑자기 OOM command not allowed when used memory > 'maxmemory' 에러가 계속 나왔다. GUI 툴로는 메모리 사용량이 80% 좀 넘는다고 나오는데 뭐가 문젠지 몰랐음. redis-cli INFO memory로 보니까 used_memory_rss가 실제로는 거의 다 먹고 있었음.

## 진짜 메모리 상태 확인 (1초)
redis-cli INFO memory | grep used_memory

## GUI 툴보다 정확함
redis-cli --bigkeys   # 큰 키들 바로 찾음

## 실시간 latency (GUI는 5초마다 업데이트)
redis-cli --latency-history

CI/CD에서 삽질한 경험
Jenkins에서 Redis health check 하려고 RedisInsight API 쓰려다가 이틀인가 삽질했음. 그냥 redis-cli PING이면 끝나는 걸 왜 복잡하게 했나 싶었다. exit code 0이면 OK, 1이면 문제 있는 거. 개간단함 ㅋㅋ

실시간 모니터링이 진짜 중요한 이유
Docker 컨테이너에서 Redis 7점 뭔가에서 갑자기 메모리가 계속 늘어났음. --stat 옵션으로 보니까 evicted_keys:0이었는데 used_memory는 계속 증가. maxmemory 설정 안 된 거였음. GUI로는 이런 실시간 변화 추적이 존나 힘들다.

실제로 써보면 알게 되는 기능들

Interactive 모드 - 주의사항 있음
그냥 redis-cli 치면 localhost:6379로 들어간다. 근데 Redis 4.x에서는 INFO 명령어 결과가 좀 다르고, 6.x부터는 ACL 기능 있어서 AUTH 먼저 해야 할 수도 있음. TAB 자동완성은 Redis 5.0부터 제대로 됨.

대량 처리 - 잘못하면 서버 죽음
--pipe 모드로 백만 개 키 넣다가 Redis 서버 메모리 터뜨린 적 있음. 한 번에 10만 개씩 나눠서 넣는 게 안전함. 그리고 파이프 형식 잘못 만들면 ERR Protocol error 나니까 주의.

모니터링 - 각각 언제 쓰는지 알아야 함

• --latency: 실시간 ping 측정. 5ms 넘으면 뭔가 문제 있는 거
• --bigkeys: 큰 키 찾기. 근데 데이터 많으면 오래 걸림 ㅋㅋ
• --memkeys: 정확한 메모리 측정. 존나 느림. production에서 쓰면 죽음
• --monitor: 모든 명령어 보기. 로그 폭탄 주의. 오래 키면 개짜증

Cluster - 삽질 포인트 많음
Redis Cluster 쓸 때 -c 옵션 안 붙이면 MOVED 에러 계속 나옴. 그리고 cluster 노드 중 하나만 죽어도 해당 slot range 접근 안 됨. 이런 건 GUI에서 잘 안 보임.

작년에 겪은 실제 장애들

메모리 90% 넘어가서 서비스 멈춘 사건
어느 날 갑자기 (error) OOM command not allowed when used memory > 'maxmemory' 에러 떴음. redis-cli --bigkeys로 보니까 user:session:* 키들이 엄청 크게 먹고 있었음. 개발자가 세션에 통째로 JSON 박아놨더라. GUI로는 큰 키 찾는데 오래 걸렸는데 CLI는 금방 끝남.

## 메모리 터지기 전에 미리 확인 (30초 소요)
redis-cli --bigkeys

## 이거는 하지 마라 (production에서 15분 걸림)
redis-cli --memkeys

새벽에 connection refused 에러로 깨어난 날
ECONNREFUSED 10.0.1.50:6379 에러로 알람 받고 일어났음. AWS ElastiCache 인스턴스가 failover 된 거였는데, 새 primary 주소로 바로 redis-cli -h new-host PING 쳐서 확인했음. GUI 켜고 connection 설정하는데 시간 엄청 걸렸을 거임.

Redis 반응 개느려서 타임아웃나는 문제
갑자기 응답속도가 엄청 느려지면서 앱에서 timeout 에러 나기 시작함. redis-cli --latency-history로 보니까 밤에부터 느려졌음. MONITOR 켜서 보니 KEYS user:* 명령어가 계속 실행되고 있었음. 어떤 개발자가 production에서 키 찾는다고 KEYS 써서 서버 블로킹 시킨 거였다. 개머리 아픔

## 언제부터 느려졌나?
redis-cli --latency-history

## 뭔 명령어가 문제인가?
redis-cli MONITOR

한국 회사에서 실제로 겪는 개짜증나는 일들

NCP에서 bastion 거쳐야 하는 지옥
네이버 클라우드 Redis는 private subnet에 있어서 매번 bastion 서버 거쳐야 함. SSH 터널링으로 포트포워딩 하고 redis-cli -h localhost -p 6379로 연결하는데, 이거를 GUI로 하려면 설정이 존나 복잡함. 그냥 터미널이 낫다.

Docker 환경에서 네트워크 개꼬인 상황

## Docker container 안에서 (항상 됨)
docker exec -it redis-container redis-cli

## 호스트에서 Docker Redis 연결 (포트 매핑 확인 필요)
docker port redis-container    # 실제 포트 확인
redis-cli -h localhost -p 32768  # 랜덤 포트일 수 있음

대기업 보안정책이 개빡센 곳들
삼성, LG, 은행 같은 곳은 GUI 프로그램 설치하려면 보안팀 승인받아야 함. 근데 redis-cli는 패키지 관리자로 깔면 승인 없이 됨. 그래서 개발자들 몰래 다 CLI 쓰고 있음 ㅋㅋ

Windows에서 WSL 쓸 때 또 다른 지옥
Windows 환경에서 Redis 쓰려면 WSL2 켜야 하는데, 여기서 redis-cli 치면 바로 됨. 근데 Windows용 GUI 프로그램은 WSL 안의 Redis 연결이 잘 안 될 때가 많음.

redis-cli 한 번 익숙해지면 새벽에 서버 터져도 5분 안에 문제 찾을 수 있다. GUI는 예쁘긴 한데 진짜 급할 때는 터미널이 생명줄임.

밤 늘게 "Redis memory usage 거의 다 찬" 알람 받고 일어났을 때, GUI 툴로는 오래 걸릴 걸 CLI로 금방 해결한 경험들이다.

성능 문제 찾기

메모리 터지기 직전에 써야 하는 것들
Redis 6점 뭔가에서 used_memory_rss가 엄청 늘어가면서 OOM 에러 나기 시작했을 때:

## 메모리 상태 정확히 확인 (금방)
redis-cli INFO memory | grep -E \"used_memory|maxmemory\"

## 큰 키들 찾기 (빠름, production에서도 안전)
redis-cli --bigkeys

## 이건 절대 쓰지 마라 (production에서 엄청 오래 걸림)
## redis-cli --memkeys

latency 100ms 넘어가서 타임아웃 나는 문제
앱에서 RedisTimeoutException: Timeout after 5000ms 에러 날 때 CLI가 제일 정확함:

## 실시간 latency (Ctrl+C로 중단)
redis-cli --latency

## 시간별 latency (언제부터 느려졌는지 확인)
redis-cli --latency-history -i 10

## 분포도 보기 (터미널 컬러 지원 필요)
redis-cli --latency-dist

시스템 자체 지연시간도 볼 수 있다:

## 5초간 시스템 고유 latency
redis-cli --intrinsic-latency 5

실제 쓰는 방법들

Cache hit rate 확인
LRU가 제대로 돌고 있는지 볼 수 있다:

## LRU 시뮬레이션 (80-20 분포로 테스트)
redis-cli --lru-test 1000000

현재 메모리 설정에서 얼마나 cache hit될지 미리 볼 수 있어서 유용함.

Cluster 상태 확인

## Cluster 정보
redis-cli CLUSTER INFO
redis-cli CLUSTER NODES

실시간 명령어 모니터링
어떤 앱이 문제인지 실시간으로 볼 수 있다:

## 모든 명령어 보기
redis-cli MONITOR

## 특정 명령어만 보기
redis-cli MONITOR | grep \"SET\"

진짜 production에서 쓰는 스크립트들

백만 개 데이터 넣다가 서버 죽인 사건
처음에는 무작정 --pipe 썼다가 Redis 서버 메모리 8GB → 16GB로 터트렸음:

## 이렇게 하지 마라 (서버 죽음)
## cat million_records.txt | redis-cli --pipe

## 이렇게 해라 (안전함)
split -l 50000 million_records.txt chunk_
for file in chunk_*; do
    echo \"Processing $file...\"
    cat $file | redis-cli --pipe
    sleep 2  # 서버 숨돌릴 시간
done

새벽에 알람 받으면 돌리는 health check 스크립트

#!/bin/bash
## 작년에 3번 수정한 Redis 응급처치 스크립트

REDIS_HOST=\"redis.prod.com\"
REDIS_PORT=\"6379\"
REDIS_AUTH=\"$PROD_REDIS_PASSWORD\"  # 환경변수에서 가져옴

## 1. 서버 살아있나? (제일 중요)
if ! redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_AUTH PING > /dev/null 2>&1; then
    echo \"🚨 Redis 완전히 죽음. 즉시 재시작 필요\"
    exit 1
fi

## 2. 메모리 90% 넘으면 위험 (경험상 95% 넘으면 OOM)
MEMORY_PCT=$(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_AUTH INFO memory | grep used_memory_percentage | cut -d: -f2 | tr -d 'r')
if (( $(echo \"$MEMORY_PCT > 90\" | bc -l) )); then
    echo \"⚠️  메모리 위험: ${MEMORY_PCT}% (90% 초과)\"
    redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_AUTH --bigkeys | head -10
fi

## 3. 클라이언트 500개 넘으면 connection pool 문제
CLIENTS=$(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_AUTH INFO clients | grep connected_clients | cut -d: -f2 | tr -d 'r')
if [ $CLIENTS -gt 500 ]; then
    echo \"⚠️  클라이언트 많음: ${CLIENTS}개 (500개 초과)\"
fi

echo \"✅ Redis 상태: 메모리 ${MEMORY_PCT}%, 클라이언트 ${CLIENTS}개\"

한국 회사에서 겪는 진짜 개짜증나는 상황들

NCP Redis에서 bastion 거쳐야 하는 지옥
네이버 클라우드는 private subnet에 Redis 박아놔서 직접 접근 불가. SSH 터널링 해야 함:

## 터널링 (포트포워딩)
ssh -L 6379:redis-internal.ncloud.com:6379 bastion-user@bastion.ncp.com

## 다른 터미널에서
redis-cli -h localhost -p 6379

AWS ElastiCache에서 CONFIG 막혀있는 개빡침
ElastiCache는 보안상 CONFIG 명령어 막아놨음. 설정 보려면 AWS 콘솔 가야 함:

## ElastiCache 정보 확인
redis-cli -h elasticache-cluster.xxxxx.cache.amazonaws.com INFO replication
redis-cli -h elasticache-cluster.xxxxx.cache.amazonaws.com INFO commandstats

Docker에서 쓰기

## Docker compose Redis 연결
docker-compose exec redis redis-cli

## 다른 네트워크 Redis 연결
docker run -it --network mynetwork redis:alpine redis-cli -h redis-server

SSL/TLS 설정

보안 때문에 TLS 쓰는 곳 많은데 설정 좀 복잡하다:

## 자체 인증서로 TLS
redis-cli --tls --cert ./client.crt --key ./client.key --cacert ./ca.crt

## SNI 있으면
redis-cli --tls --sni redis.production.com

Lua 스크립트 디버깅

Lua 디버깅도 된다. Redis Lua scripting 가이드에서 더 자세한 내용을 볼 수 있다:

## Lua 스크립트 실행
redis-cli --eval myscript.lua key1 key2 , arg1 arg2

## 디버깅 모드
redis-cli --ldb --eval myscript.lua key1 key2 , arg1 arg2

기타 유용한 팁들

여러 명령어 한번에
네트워크 왕복 줄이려면:

## 여러 명령어 한번에
(echo PING; echo PING; echo PING) | redis-cli

SCAN 최적화
KEYS * 말고 SCAN 써야 하는 건 기본:

## 안전하게 스캔
redis-cli --scan --pattern \"user:*\" | head -1000

## 속도 조절 (production 부하 줄이기)
redis-cli --scan --pattern \"session:*\" -i 0.1

CSV로 내보내기
분석용으로:

## List를 CSV로
redis-cli --csv LRANGE mylist 0 -1 > data.csv

## 여러 키 값을 CSV로
redis-cli --csv MGET key1 key2 key3 key4 > values.csv

이런 고급 기능들 알면 Redis 문제 대부분 GUI 없이도 해결됨. production에서는 command line이 더 안정적이고 빠르다.

진짜 결론:
2년간 Redis 운영하면서 배운 건, GUI 툴들은 화면 예쁘지만 정작 서버 터지면 쓸모없다는 거임. redis-cli 익히는데 3일이면 충분하고, 한 번 익히면 새벽에 서버 터져도 5분 안에 문제 찾을 수 있음.

production 환경에서는 CLI가 생명줄이다. 스크립트로 자동화하고, 모니터링하고, 문제 해결하는 게 다 CLI로 가능함. GUI는 그냥 데이터 구경용이고 ㅋㅋ