Redis에 대한 오해

Redis는 싱글스레드?

Redis는 데이터 처리를 담당하는 메인 이벤트 루프가 싱글스레드로 동작하는 것

-> redis-client 와 싱글스레드로 동작함

-> 싱글스레드이기 때문에 간섭, lock 없이도 빠르게 작동 가능함

 

하지만 백그라운드에서 동작하는 작업은 멀티스레드로 작동

-> 그렇기 때문에 우리가 redis prod 상황에서도 백업이 가능함

더군다나  6.0부터 도입된 I/O 멀티스레딩: 클라이언트 요청을 처리할 때의 네트워크 I/O를 멀티스레드로 병렬 처리 가능

 

 

Redis는 Replica로 하면 다 된다?

Replica(슬레이브)를 두면 읽기 부하를 분산할 수 있고, 장애 발생 시 failover도 가능한 것이 사실

하지만 쓰기 부하는 절대 분산되지 않음 -> 쓰기는 여전히 Master에만 가능

replication은 비동기: 데이터 유실 가능성 존재 -> 하지만 유실되어선 안되는 것을 Redis에 사용하지 않음

Replica의 데이터는 잠시동안 지연될 수 있음 -> replication lag 이 일정 이상이라면 서비스에 장애가 생길 수도

 

 

 

Redis는 Sentinel로 하면 다 된다?

Sentinel은 Redis의 고가용성을 지원하기 위한 모니터링 및 자동 failover 도구지만

CPA에서 Partition Tolerance, 네트워크 파티션 문제에 취약함

실제로는 failover 후 클라이언트 리커넥션 로직도 구현되어야 함.

정확한 quorum 설정과 안정적인 Sentinel 구성은 뒷받침 되어야함

 

 

Redis Cluster로 쓰면 다 된다?

샤딩을 redis에서 하느냐? 또는 Application에서 하느냐 의 차이가 있음

Redis에서 관리

Redis Cluster는 데이터를 여러 노드에 sharding하여 저장

각 노드는 전체 key 공간(0~16383 hash slot)의 일부만 담당

쓰기 작업도 분산되며, 각 노드는 자신이 담당하는 슬롯의 key에 대한 읽기/쓰기를 처리

쓰기 부하를 수평으로 분산 가능

클러스터 확장 시 새 노드 추가 후 resharding 가능

간단한 HA 기능 내장 (슬롯마다 replica 지정 가능)

새로운 노드를 추가해도 슬롯을 자동으로 재배치하지 않음

직접 resharding 명령어를 사용해서 슬롯을 재할당 필요

-> 순간적으로 리소스를 많이 사용해야 하므로 부하 증가 예상

마찬가지로, 노드를 제거할 경우에도 슬롯을 다른 노드로 수동으로 옮긴 후 제거

이렇게 운영자는 Cluster 운영 시 항상 염두해두어야 함

 

Application에서 관리

노드 추가 제거 시, 유용한 해싱방법 - Consistent Hashing

• 해시 공간을 고리형으로 구성
• Redis 노드를 일정한 간격으로 이 고리에 배치
• 키를 해시한 값을 기반으로 가장 가까운 노드에 매핑
• 노드 추가/제거 시에도 키 이동이 최소화됨 (~1/N)
• 일부 키만 새 노드로 이동하므로 운영 중에도 가능

 

 

Redis에서 중요한건 메모리 크기뿐?

메모리 중요함 하지만

 

RDB/AOF 설정: 저장 주기나 방식이 장애 복구 시 영향

maxmemory 정책: 메모리가 다 찼을 때 어떤 키를 제거할지 결정.

key eviction 정책: LRU/LFU/random 등 정책에 따라 결과가 크게 달라짐

key TTL 관리: 만료되지 않은 key가 계속 쌓이면 Out-of-Memory(OOM) 발생 가능

key 디자인: 너무 큰 key나 너무 많은 key 수는 성능에 악영향

-> key 하나에 value 길이가 너무 길면 힘듦

 

 

Redis 장애 미리 탐지할 수 없다?

 

많은 지표가 존재하고 서비스 성능에 직접적인 영향을 주는 지표도 많음

• latency spikes
• replication lag
• memory usage 증가 추이
• keyspace hits/misses
• client connection 수
• eviction count 증가

 

 

 

 

큰 key 하나 저장하는 게 낫다?

• 오히려 큰 key 하나는 삭제, 만료, 복제 등의 작업 시 병목을 유발할 수 있음.
• 적절한 사이즈의 여러 key로 쪼개는 게 좋음.

 

 

무조건 maxmemory 설정하면 안전하다?

• eviction 정책을 잘못 설정하면 중요 데이터가 먼저 날아갈 수 있음.
• noeviction 설정 시 OOM으로 전체 서비스가 죽을 수도 있음.