Redis 고가용성 구성¶

Redis 단일 노드, replica, Sentinel, Cluster 검토 기준을 정리함.

1. 고가용성 구성 기준¶

단일 Redis 노드는 SPOF임. Redis 장애가 서비스 장애로 이어지는 경우 고가용성 구성을 검토해야 함.

1.1 단일 노드가 허용되는 경우¶

다음 조건을 모두 만족하면 단일 노드 Redis를 사용할 수 있음.

Redis가 순수 캐시임
Redis 데이터 유실이 허용됨
Redis 장애 시 애플리케이션이 graceful degradation 가능함
Redis 재시작 또는 재배포가 수분 내 가능함
모니터링과 알람이 있음

1.2 replica 구성 기준¶

읽기 부하 분산 또는 장애 대응 준비를 위해 replica를 구성할 수 있음.

master 예시:

requirepass CHANGE_ME_TO_LONG_RANDOM_PASSWORD

replica 예시:

replicaof 192.168.1.50 6379
masterauth CHANGE_ME_TO_LONG_RANDOM_PASSWORD
requirepass CHANGE_ME_TO_LONG_RANDOM_PASSWORD

Redis 6 이상 ACL 환경에서는 replication용 사용자와 권한을 별도 설계함.

1.3 write safety 설정¶

Redis replication은 기본적으로 비동기임. master 장애 시 최근 write가 replica에 반영되지 않았을 수 있음.

write loss 위험을 줄이려면 다음 설정을 검토함.

min-replicas-to-write 1
min-replicas-max-lag 10

의미:

최소 1개 replica가 정상 lag 범위 내에 있어야 write 허용
replica lag가 10초를 초과하면 master write를 거부할 수 있음

주의 이 설정은 데이터 유실 위험을 줄일 수 있지만, replica 장애 또는 network partition 상황에서 write availability를 낮출 수 있음. 서비스 요구사항에 따라 consistency와 availability 사이의 trade-off를 결정함.

1.4 Sentinel 구성 기준¶

Sentinel은 Redis master를 감시하고 장애 발생 시 replica를 master로 승격하는 고가용성 구성 요소임.

운영 기준:

Sentinel은 최소 3개 이상 구성함.
Sentinel은 서로 다른 서버 또는 장애 도메인에 배치함.
quorum은 보통 2로 시작함.
애플리케이션 Redis client가 Sentinel discovery를 지원해야 함.
Sentinel 자체도 모니터링해야 함.
failover 리허설을 정기적으로 수행함.

1.4.1 requirepass 환경 Sentinel 예시¶

다음 예시는 Redis 인스턴스가 legacy requirepass 기반 인증을 사용하는 경우임.

port 26379
sentinel monitor mymaster 192.168.1.50 6379 2
sentinel auth-pass mymaster CHANGE_ME_TO_LONG_RANDOM_PASSWORD
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 60000

sentinel auth-pass만 사용하는 예시는 requirepass 기반 인증을 전제로 함.

1.4.2 ACL 환경 Sentinel 예시¶

Redis 6 이상 ACL 환경에서는 Sentinel 전용 사용자를 만들고, Sentinel 설정에 auth-user와 auth-pass를 함께 지정함.

Redis 인스턴스 ACL 예시:

ACL SETUSER sentinel-user on >CHANGE_ME_TO_LONG_RANDOM_PASSWORD allchannels +multi +slaveof +ping +exec +subscribe +config|rewrite +role +publish +info +client|setname +client|kill +script|kill

주의
위 ACL command 목록은 예시이며 Redis/Sentinel 버전에 따라 필요한 command가 달라질 수 있음.
Redis 7 이상에서는 SLAVEOF보다 REPLICAOF 명령명을 기준으로 검토해야 하며, Sentinel 내부 동작에 필요한 command도 버전별로 차이가 있을 수 있음.
운영 반영 전에는 사용 중인 Redis/Sentinel 버전의 공식 Sentinel ACL 문서를 기준으로 최소 권한을 재검증함.

Sentinel 설정 예시:

port 26379
sentinel monitor mymaster 192.168.1.50 6379 2
sentinel auth-user mymaster sentinel-user
sentinel auth-pass mymaster CHANGE_ME_TO_LONG_RANDOM_PASSWORD
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 60000

주의
sentinel auth-pass만 있는 예시는 requirepass 기반 인증을 전제로 함.
ACL 환경에서는 sentinel auth-user와 sentinel auth-pass를 함께 사용해야 함.
Sentinel 인스턴스 자체에 대한 client 인증도 별도로 구성할 수 있으며, Sentinel 간 인증과 Redis master/replica 인증을 혼동하지 않음.

1.4.3 Sentinel 운영 주의 사항¶

Sentinel 구성에서는 다음을 반드시 확인함.

Redis master/replica 인증 방식과 Sentinel 인증 방식이 일치하는지 확인함
ACL 환경에서는 Sentinel 전용 사용자의 command 권한이 충분한지 확인함
Sentinel 설정 파일은 failover 과정에서 자동으로 rewrite될 수 있으므로 파일 권한과 디스크 쓰기 권한을 확인함
애플리케이션 client가 Sentinel master name 기반 discovery를 지원하는지 확인함
Sentinel quorum과 실제 majority 조건을 혼동하지 않음
failover 후 이전 master가 복구될 때 replica로 재합류하는지 검증함

1.5 Redis Cluster 검토 기준¶

Redis Cluster는 sharding과 high availability를 함께 제공함. 단순 failover만 필요한 경우 Sentinel이 더 단순할 수 있음.

Cluster를 검토해야 하는 경우:

단일 Redis 인스턴스 메모리 한계를 초과함
write/read 처리량을 수평 확장해야 함
keyspace를 shard로 분산해야 함
애플리케이션 client가 Redis Cluster를 지원함

Cluster는 hash slot, resharding, multi-key command 제약, key tag, failover, backup/restore 절차가 복잡하므로 별도 운영 문서로 분리하는 것이 좋음.