Redis 메모리·영속화·고가용성

Overview

Redis 운영은 “메모리니까 빠르다”에서 끝나지 않는다. 메모리 상한에 도달했을 때의 행동, 재시작 후 복구할 데이터, Primary 장애 시 허용할 유실 구간을 서비스 요구사항으로 결정해야 한다.

한 문장 설명: Redis 고가용성은 무중단과 무손실을 자동 보장하는 기능이 아니라 복구 시간과 데이터 손실 가능성을 줄이는 선택들의 조합이다.

왜 필요한가

메모리 제한이 없으면 OS OOM으로 Process가 종료될 수 있고, 정책이 부적절하면 중요한 Key가 축출된다. 복제본이 있어도 비동기 복제 지연 구간의 쓰기는 Failover 때 사라질 수 있다. 캐시인지 원본성 데이터인지에 따라 허용 수준이 다르다.

핵심 원리

maxmemory와 Eviction 정책을 함께 설정한다. Cache 전용이면 LRU/LFU 계열 정책을 검토하고, 중요한 상태와 캐시를 한 Instance에 섞지 않는다. RDB는 시점 Snapshot, AOF는 쓰기 명령 로그다. RDB는 복구 파일이 작지만 Snapshot 사이 변경을 잃을 수 있고 AOF는 더 촘촘하지만 파일과 Rewrite 비용이 있다.

내부 동작

Primary는 변경을 Replica에 비동기로 전달한다. Sentinel 구성은 장애를 감지해 Replica를 승격하고, Cluster는 Slot을 여러 Primary에 분산해 확장과 Failover를 함께 다룬다. 장애 감지에는 합의와 시간이 필요하며, Network Partition에서는 옛 Primary와 새 Primary가 잠시 엇갈리는 조건을 고려한다.

flowchart TB; C[Client] --> P[Primary]; P -->|복제 스트림| R1[Replica 1]; P -->|복제 스트림| R2[Replica 2]; S[Sentinel/Cluster Control] -->|감지·투표·승격| R1; P --> D[(RDB/AOF)]

쉬운 비유

RDB는 주기적으로 찍는 장부 사진이고 AOF는 거래 내역을 계속 적는 일지다. 대리점인 Replica는 본점 기록을 전달받으므로 전달 직전 본점이 끊기면 마지막 몇 건을 못 받았을 수 있다.

Example

캐시 서비스라면 maxmemory를 명시하고 축출을 허용할 수 있다. 세션이나 작업 상태를 Redis에만 둔다면 영속화 주기, 복제 지연, Failover 유실이 사용자 경험과 보안에 미치는 영향을 먼저 계산해야 한다. 장애 후에는 새 Primary 확인과 Client 재연결, Warm-up을 검증한다.

실무에서 발생하는 문제

Fork 기반 Snapshot/Rewrite 때 Copy-on-write로 메모리가 순간 증가할 수 있다. 큰 Key 삭제는 지연을 만들고, Fragmentation으로 논리 사용량보다 RSS가 커질 수 있다. Replica의 오래된 값을 읽거나, Failover 후 옛 연결이 남거나, Cluster Slot 이동 중 Redirect가 발생한다.

Trade-off

영속성을 강화할수록 Disk I/O와 지연 비용이 늘고, Replica를 늘리면 읽기와 복구 선택지는 늘지만 비용과 지연 관측이 필요하다. Cluster는 수평 확장을 주지만 Multi-key 제약과 운영 복잡성을 추가한다.

흔한 오해

Replica가 있으면 승인된 쓰기가 절대 유실되지 않는 것은 아니다.
RDB와 AOF는 Backup 정책을 완전히 대신하지 않는다.
메모리 사용량은 값 크기의 합과 같지 않다. 자료구조 Overhead와 Fragmentation이 있다.
Eviction은 장애가 아니라 정책 실행이지만, 예상 밖 Eviction은 용량 설계 실패 신호다.

Production Considerations

used_memory, used_memory_rss, fragmentation ratio, fork 시간, Persistence 실패, replication offset/lag, Failover 횟수, Eviction을 경보화한다. 실제 데이터 크기로 복구 시간을 재고, Zone 장애와 Client 재연결을 훈련한다. Backup 복원도 별도로 시험한다.

Interview Questions / Follow-up Questions

RDB와 AOF의 복구 범위와 비용 차이는?
Sentinel과 Cluster의 목적 차이는?
후속: 복제본이 있는데도 데이터가 유실될 수 있는 이유는?
후속: Redis RSS가 갑자기 커졌을 때 무엇을 확인할 것인가?

Redis 운영 지도, Observability, Incident Response와 연결해 장애 경로를 준비한다.