운영에서는 빠른 명령보다 안전한 경계가 먼저다
개발 환경에서 Redis는 SET, GET, HSET 같은 명령을 빠르게 실행하는 도구처럼 보인다. 하지만 실서비스에 배포되는 순간 Redis는 중요한 운영 자산이 된다. 세션, 캐시, 랭킹, 큐, 이벤트 로그가 Redis에 들어가면 Redis 장애는 곧 로그인 장애, 주문 지연, 알림 누락, 데이터베이스 과부하로 이어질 수 있다.
운영 Redis의 기본 원칙은 단순하다.
아무나 접속할 수 없어야 한다.
접속하더라도 필요한 명령만 실행할 수 있어야 한다.
문제가 생기기 전에 지표로 이상 징후를 봐야 한다.
장애가 나면 누가, 어떤 순서로, 무엇을 확인할지 정해져 있어야 한다.
Redis 공식 문서도 Redis는 신뢰할 수 있는 내부 네트워크에서 신뢰할 수 있는 클라이언트가 접근한다는 전제를 가진다고 설명한다. 즉 Redis 포트를 인터넷에 직접 노출하는 구성은 피해야 한다1. 보안은 비밀번호 하나로 끝나는 일이 아니다. 네트워크, 인증, 권한, 암호화, 비밀 정보 관리가 함께 맞물려야 한다.
AI 생성 이미지
접근 범위 제한: bind와 protected-mode
가장 먼저 확인할 것은 Redis가 어느 네트워크 인터페이스에서 요청을 받는지다. redis.conf의 bind 설정은 Redis가 수신할 IP를 제한한다.
bind 127.0.0.1 10.0.1.15
protected-mode yes
port 6379bind 127.0.0.1만 설정하면 같은 서버 안의 애플리케이션만 Redis에 접속할 수 있다. 애플리케이션 서버가 분리되어 있다면 사설망 IP만 열어야 한다. 0.0.0.0처럼 모든 인터페이스에 바인딩하는 설정은 방화벽과 접근 제어가 확실히 준비된 경우가 아니라면 피하는 편이 안전하다.
protected-mode는 Redis가 아무 비밀번호 없이 외부 인터페이스에 노출되는 위험한 상황을 막기 위한 안전장치다. 기본 설정에서 비밀번호 없이 모든 인터페이스를 열면 Redis는 보호 모드로 동작해 로컬 요청만 허용하고, 외부 주소에서 들어온 요청에는 설정을 바로잡으라는 오류를 반환한다1. 하지만 protected mode는 마지막 방어선일 뿐 운영 정책이 아니다. 운영에서는 반드시 명시적으로 네트워크 접근 범위를 제한해야 한다.
실무 점검 기준은 다음과 같다.
Redis 포트가 인터넷에서 접근 가능한지 확인한다.
클라우드 보안 그룹, 방화벽, 네트워크 ACL에서 애플리케이션 서버만 허용한다.
운영 Redis는 사설 서브넷에 둔다.
Bastion, VPN, PrivateLink 같은 통제된 경로 없이 직접 접속하지 않는다.
Redis 프로세스는 가능하면
root가 아닌 전용 저권한 사용자로 실행한다.
인증과 권한: requirepass보다 ACL을 기준으로 생각하기
예전 Redis 구성에서는 requirepass로 공용 비밀번호를 설정하는 방식이 흔했다.
requirepass very-long-random-password이 설정을 사용하면 클라이언트는 AUTH 후 명령을 실행할 수 있다. 하지만 requirepass는 모든 클라이언트가 같은 권한을 갖는 구조에 가깝다. 애플리케이션 서버, 배치 서버, 운영자, 모니터링 도구가 모두 같은 비밀번호를 공유하면 문제가 생겼을 때 누가 어떤 명령을 실행했는지 구분하기 어렵다.
Redis 6 이후에는 ACL(Access Control List)을 기준으로 권한을 나누는 방식이 권장된다. ACL은 사용자별로 실행 가능한 명령과 접근 가능한 키 패턴을 제한한다. Redis 6.2부터는 Pub/Sub 채널 패턴도 제한할 수 있다2. 예를 들어 API 서버가 캐시와 세션 키만 다루게 만들 수 있다.
ACL SETUSER app-api reset on >strong-password-1 ~cache:* ~session:* +get +set +del +expire +ttl여기서 reset은 기존에 남아 있던 권한을 먼저 지우고 새 규칙을 적용하겠다는 뜻이다. 운영 스크립트나 배포 자동화에서 ACL을 다시 적용할 때 이전 권한이 의도치 않게 남는 일을 줄일 수 있다. 위 사용자는 cache:*, session:* 키에 대해서만 지정된 명령을 실행할 수 있다. 랭킹을 갱신하는 워커라면 Sorted Set 관련 명령만 허용할 수 있다.
ACL SETUSER ranking-worker reset on >strong-password-2 ~rank:* +zadd +zincrby +zrange +zrevrange +zrem +expire운영자는 더 넓은 권한이 필요할 수 있지만, 그렇다고 모든 명령을 무조건 허용하면 위험하다. FLUSHALL, CONFIG, SHUTDOWN 같은 명령은 실수 한 번으로 전체 서비스 장애를 만들 수 있다. Redis는 과거의 명령 이름 변경 방식보다 ACL을 통한 제한을 권장한다1.
운영 환경에서는 최소한 다음 원칙을 적용한다.
기본 사용자
default를 그대로 열어 두지 않는다.서비스별 Redis 사용자를 분리한다.
사용자마다 접근 가능한 키 패턴을 제한한다.
읽기 전용 모니터링 계정과 쓰기 가능한 애플리케이션 계정을 분리한다.
위험 명령은 운영자 계정에서도 별도 절차 없이 실행하지 못하게 한다.
비밀번호는 충분히 길고 무작위로 생성한다.
ACL 변경이 재시작 후에도 유지되는지 설정 파일, ACL 파일, 배포 방식을 함께 확인한다.
ACL을 바꿀 때는 기존 연결에도 주의해야 한다. Redis에서 사용자를 off로 바꾸면 새 인증은 막히지만, 이미 그 사용자로 인증된 연결은 계속 동작할 수 있다. 즉시 끊어야 한다면 CLIENT KILL의 user 옵션을 사용하거나, 상황에 따라 ACL DELUSER로 사용자를 삭제하는 절차를 검토해야 한다2. 권한 변경은 운영 중 즉흥적으로 하기보다 스테이징에서 먼저 검증하고 배포 절차에 포함해야 한다.
TLS와 비밀 정보 관리
AUTH는 인증일 뿐 암호화가 아니다. 평문 네트워크에서 비밀번호를 보내면 중간에서 탈취될 수 있다. 그래서 Redis가 서로 다른 서버 사이에서 통신하거나, 관리형 Redis에 접속하거나, 규정상 암호화가 필요한 환경이라면 TLS를 검토해야 한다.
Redis는 TLS 포트를 별도로 열 수 있으며, 평문 포트를 끄고 TLS만 사용할 수도 있다3. 대표 설정은 다음과 같다.
port 0
tls-port 6379
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crtTLS를 켜면 클라이언트 라이브러리도 TLS 접속을 지원해야 한다. 직접 Redis를 빌드해 운영한다면 TLS 지원이 포함된 빌드인지도 확인해야 한다. 복제나 Cluster 통신에도 TLS를 적용하려면 tls-replication, tls-cluster 같은 설정까지 함께 확인해야 한다. 인증서 만료일, 갱신 절차, 롤백 방법도 운영 문서에 포함해야 한다.
비밀번호와 인증서 파일은 코드 저장소에 넣지 않는다. 다음 중 하나를 사용해 관리한다.
클라우드 Secret Manager 또는 KMS
Kubernetes Secret과 외부 시크릿 연동 도구
배포 시스템의 암호화된 환경 변수
접근 권한이 제한된 설정 파일
중요한 것은 비밀 값의 위치보다 교체 절차다. Redis 비밀번호가 유출되었다고 가정했을 때 새 사용자 생성, 애플리케이션 설정 교체, 기존 사용자 비활성화, 접속 확인까지 순서가 정해져 있어야 한다.
관측성: 무엇을 계속 봐야 하는가
Redis 모니터링은 단순히 서버가 살아 있는지 보는 수준으로는 부족하다. 캐시 적중률이 떨어지면 데이터베이스가 먼저 아플 수 있고, 복제 지연이 커지면 장애 조치 후 데이터 손실 가능성이 커질 수 있다. 다음 지표는 운영 대시보드에 반드시 포함하는 것이 좋다.
| 영역 | 주요 지표 | 확인 이유 |
|---|---|---|
| 메모리 | used_memory, maxmemory, mem_fragmentation_ratio | 메모리 한계, 단편화, eviction 위험 확인 |
| 연결 | connected_clients, blocked_clients, rejected_connections | 연결 폭증, 블로킹 명령, 접속 실패 확인 |
| 처리량 | instantaneous_ops_per_sec, command stats | 평소 대비 트래픽 변화와 특정 명령 집중 확인 |
| 캐시 | keyspace_hits, keyspace_misses, hit ratio | 캐시 효율과 DB fallback 위험 확인 |
| 만료·퇴거 | expired_keys, evicted_keys | TTL 정책과 메모리 부족으로 인한 삭제 확인 |
| 지연 | SLOWLOG, LATENCY DOCTOR | 느린 명령과 지연 spike 원인 확인 |
| 복제 | master_link_status, replication offset, lag | Replica 상태와 failover 위험 확인 |
| 영속성 | RDB/AOF 마지막 저장 시각, rewrite 상태 | 백업 가능성과 디스크 부하 확인 |
INFO는 이 지표들을 확인하는 출발점이다. 하지만 운영에서는 사람이 터미널에서 가끔 확인하는 방식으로는 부족하다. Prometheus exporter, 클라우드 모니터링, APM 연동 등을 사용해 대시보드와 알림을 구성해야 한다.
알림은 너무 많아도 무시된다. 처음에는 다음처럼 장애로 이어지기 쉬운 조건부터 잡는다.
메모리 사용률이 일정 시간 80~90% 이상 유지된다.
evicted_keys가 증가한다.rejected_connections가 발생한다.캐시 hit ratio가 평소보다 급격히 낮아진다.
replication lag가 기준치를 넘는다.
SLOWLOG에 큰 컬렉션 조회나 위험 명령이 반복된다.AOF rewrite 실패 또는 RDB 저장 실패가 발생한다.
절대적인 임계값은 서비스마다 다르다. 중요한 것은 평소 기준선이다. 평일 오전, 점심 피크, 배치 시간, 이벤트 시간대의 정상 패턴을 알고 있어야 이상을 빠르게 구분할 수 있다.
장애 대응 Runbook 만들기
장애가 난 뒤에 원인을 생각하기 시작하면 늦다. Runbook은 장애 유형별로 첫 10분 동안 할 일을 정리한 문서다. Redis 운영에서는 최소한 다음 시나리오를 준비한다.
Redis 접속 불가
애플리케이션 오류가 인증 실패인지, 타임아웃인지, 연결 거부인지 구분한다.
Redis 프로세스 상태와 포트 리스닝 상태를 확인한다.
보안 그룹, 방화벽, DNS, Sentinel 또는 Cluster 엔드포인트 변경 여부를 확인한다.
최근 배포에서 비밀번호, ACL, TLS 설정이 바뀌었는지 확인한다.
필요하면 읽기 전용 기능 축소, 캐시 우회, DB fallback 같은 서비스 완화 모드로 전환한다.
메모리 부족 또는 eviction 발생
used_memory,maxmemory,evicted_keys증가 여부를 확인한다.최근 새로 추가된 키 패턴이나 TTL 누락을 찾는다.
Big Key와 Hot Key를 점검한다.
임시로 불필요한 캐시 키를 점진적으로 삭제한다. 운영에서
KEYS와 대량DEL은 피하고SCAN과 배치 삭제를 사용한다.재발 방지를 위해 TTL,
maxmemory-policy, 용량 계획을 수정한다.
복제 지연 또는 failover
Primary와 Replica의 연결 상태를 확인한다.
replication lag와 offset 차이를 확인한다.
Sentinel 또는 Cluster가 새 Primary를 정상 선출했는지 확인한다.
애플리케이션 클라이언트가 새 Primary로 연결을 갱신했는지 확인한다.
장애 시간대의 쓰기 손실 가능성을 애플리케이션 로그와 대조한다.
느린 응답
Redis CPU, 네트워크, 메모리 사용량을 확인한다.
SLOWLOG GET으로 느린 명령을 확인한다.큰 범위 조회, 큰 Hash/List/Set/Sorted Set 접근, Lua 스크립트 장시간 실행 여부를 본다.
최근 배포된 코드가 반복 단건 요청이나 무제한 조회를 만들지 않았는지 확인한다.
필요하면 해당 기능을 제한하거나 캐시 키를 분산한다.
Runbook에는 담당자, 연락 순서, 점검 명령, 대시보드 링크, 롤백 방법, 고객 공지 기준까지 포함하는 것이 좋다.
백업 검증, 용량 계획, 업그레이드 절차
백업은 존재보다 복원이 중요하다. RDB나 AOF 파일이 저장되고 있어도 실제로 복원해 본 적이 없다면 백업 체계가 완성되었다고 보기 어렵다. 운영에서는 정기적으로 별도 환경에 백업을 복원하고, 데이터 개수와 주요 키 패턴을 확인해야 한다.
용량 계획은 현재 메모리 사용량에 약간의 여유를 더하는 일이 아니다. 다음 요소를 함께 본다.
키 수 증가 속도
평균 값 크기와 큰 키 비율
TTL이 없는 키 비율
이벤트나 프로모션 기간의 피크 트래픽
복제, AOF rewrite, 백업 중 추가 메모리 사용 가능성
Cluster라면 노드별 슬롯과 트래픽 불균형
업그레이드는 작은 장애 조치 훈련과 같다. 버전 변경 전에는 릴리스 노트, 클라이언트 호환성, ACL/TLS 설정, persistence 파일 호환성을 확인한다. 가능하면 Replica 또는 스테이징 환경에서 먼저 올리고, 백업을 확보한 뒤, 롤백 기준을 정한다. 관리형 Redis를 사용하더라도 자동 업그레이드 시간, 재시작 영향, TLS 정책 변경, 클라이언트 최소 버전은 반드시 확인해야 한다.
운영 체크리스트
마지막으로 Redis를 운영에 배포하기 전 다음 목록을 점검하자.
보안
Redis 포트가 인터넷에 직접 노출되지 않는다.
bind가 필요한 사설 IP로 제한되어 있다.protected-mode yes가 유지되어 있다.방화벽 또는 보안 그룹이 애플리케이션 서버만 허용한다.
default사용자를 그대로 사용하지 않거나 강하게 제한했다.서비스별 ACL 사용자를 분리했다.
위험 명령 실행 권한을 제한했다.
비밀번호와 인증서는 Secret Manager 등으로 관리한다.
필요한 구간에 TLS를 적용했고 인증서 갱신 절차가 있다.
관측성
메모리 사용량과 eviction을 모니터링한다.
연결 수, 거부된 연결, 블로킹 클라이언트를 본다.
ops/sec와 명령별 사용량을 본다.
캐시 hit ratio를 추적한다.
replication lag와 failover 이벤트를 알림으로 받는다.
SLOWLOG와 latency spike를 확인한다.RDB/AOF 저장 실패를 알림으로 받는다.
장애 대비
Redis 접속 불가 Runbook이 있다.
메모리 부족 대응 절차가 있다.
failover 후 애플리케이션 재연결 절차를 검증했다.
정기적으로 백업 복원 리허설을 한다.
용량 증가 추세를 월 단위로 검토한다.
업그레이드 전 테스트, 백업, 롤백 기준이 정해져 있다.
Redis 운영의 목표는 장애가 절대 나지 않는 상태가 아니다. 장애가 나도 피해 범위를 줄이고, 빠르게 감지하고, 정해진 절차로 복구하는 상태다. 명령어를 잘 아는 것만으로는 부족하다. 접근 제어, 관측성, Runbook이 갖춰질 때 Redis는 실서비스에서 믿고 사용할 수 있는 기반이 된다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.