Redis 리드·아키텍트 프레임워크 면접

RDB는 특정 시점에 fork()를 통해 자식 프로세스를 생성하고, Copy-on-Write 메커니즘으로 메모리를 공유하면서 디스크에 바이너리 스냅샷을 저장합니다. COW 방식은 초기에는 메모리를 복사하지 않지만, 부모 프로세스가 데이터를 수정하면 해당 페이지만 복사되므로 쓰기가 많은 상황에서는 최대 2배의 메모리가 필요할 수 있습니다. AOF는 모든 쓰기 명령을 로그로 기록하며, AOF rewrite 시에도 fork()를 사용하여 백그라운드에서 압축된 AOF 파일을 생성합니다. Rewrite 중 새로운 명령은 메모리 버퍼(AOF rewrite buffer)에 누적되며, rewrite 완료 후 병합되므로 추가 메모리가 필요합니다. 메모리 오버헤드를 줄이기 위해서는 적절한 시간대에 rewrite를 스케줄링하고, 메모리 여유분을 충분히 확보하며, maxmemory-policy 설정을 통해 메모리 압박 상황을 관리해야 합니다.

Redis Cluster는 0부터 16383까지 16384개의 해시 슬롯을 사용하며, 각 키는 CRC16(key) mod 16384로 슬롯에 매핑됩니다. 16384개를 사용하는 이유는 클러스터 노드 간 gossip 프로토콜로 전송되는 heartbeat 패킷에 슬롯 정보를 비트맵으로 포함하는데, 16384비트는 2KB로 네트워크 오버헤드가 적절하기 때문입니다. 더 많은 슬롯을 사용하면 메타데이터 크기가 증가하고, 더 적으면 재분배 시 세밀한 제어가 어렵습니다. 슬롯 재분배 시 MOVED 에러는 슬롯이 완전히 다른 노드로 이동했음을 의미하며 클라이언트는 슬롯 테이블을 업데이트합니다. ASK 에러는 슬롯 마이그레이션 중 일시적 리다이렉션으로, 클라이언트는 ASKING 명령 후 대상 노드에 재요청하되 슬롯 테이블은 업데이트하지 않습니다. 클라이언트는 이러한 리다이렉션을 자동으로 처리하며, 슬롯 테이블 캐싱을 통해 대부분의 요청을 올바른 노드로 직접 전송합니다.

Redis Pub/Sub은 발행된 메시지를 현재 연결된 구독자에게만 즉시 전달하며, 메시지를 저장하지 않는 fire-and-forget 방식입니다. 구독자가 없거나, 네트워크 지연으로 클라이언트 버퍼가 가득 차거나, 구독자가 일시적으로 연결이 끊긴 경우 메시지가 유실됩니다. Pub/Sub은 실시간성이 중요하고 메시지 유실이 허용되는 라이브 채팅, 실시간 알림, 캐시 무효화 이벤트 전파 등에 적합합니다. 반면 메시지 지속성, 재처리, 컨슈머 그룹이 필요한 이벤트 소싱이나 작업 큐에는 부적합하며 이 경우 Stream이 적절합니다. 대규모 실시간 알림 시스템의 경우, 중요도가 낮은 실시간 피드는 Pub/Sub으로, 반드시 전달되어야 하는 중요 알림은 Stream으로 분리하여 설계하는 하이브리드 접근이 효과적입니다.

Redis의 maxmemory-policy는 메모리 한계 도달 시 키 제거 방식을 결정하며, noeviction은 쓰기를 거부하고, allkeys 계열은 모든 키를, volatile 계열은 TTL이 설정된 키만 대상으로 합니다. LRU는 가장 오래 사용되지 않은 키를, LFU는 가장 적게 사용된 키를, random은 무작위로, ttl은 만료 시간이 가까운 키를 제거합니다. Redis LRU는 정확한 연결 리스트 기반이 아닌 근사 LRU로, maxmemory-samples 설정값만큼(기본 5개) 무작위 샘플링하여 그 중 가장 오래된 키를 제거하므로 O(1) 성능을 유지합니다. LFU는 Morris counter를 사용한 logarithmic counter로 접근 빈도를 추적하며, lfu-decay-time으로 시간에 따른 감쇠를 구현합니다. allkeys-lru는 일반적인 캐시에, volatile-lru는 세션 데이터와 임시 데이터 혼합 시, allkeys-lfu는 인기도 기반 콘텐츠 캐싱에, volatile-ttl은 명시적 만료 시간 관리가 필요한 경우에 적합합니다.

전체 동기화는 replica가 처음 연결되거나 backlog에 필요한 데이터가 없을 때 master가 RDB 스냅샷을 생성하여 전송하고, 그 이후 명령을 버퍼링하여 전달하는 방식입니다. 부분 동기화는 replica가 일시적으로 연결이 끊겼다가 재연결될 때 replication offset을 기준으로 backlog에서 누락된 명령만 전송합니다. Replication backlog는 순환 버퍼로, 크기는 예상되는 네트워크 단절 시간과 쓰기 처리량을 곱한 값보다 커야 하며, 예를 들어 초당 10MB 쓰기에 60초 단절을 대비하려면 최소 600MB 이상이 필요합니다. PSYNC2는 replica가 master로 승격된 후에도 replication ID를 추적하여 부분 동기화가 가능하도록 개선했으며, 장애 조치 후 전체 동기화를 피할 수 있습니다. 복제 지연 발생 시 읽기 워크로드를 분산하여 master 부하를 줄이거나, replica를 추가하거나, 쓰기 집약적 작업을 배치로 처리하거나, 최종 일관성을 허용하는 읽기는 replica에서 처리하도록 애플리케이션 레벨에서 분리하는 전략을 사용합니다.

MULTI/EXEC 트랜잭션은 여러 명령을 큐에 저장했다가 EXEC 시점에 순차적으로 실행하여 원자성을 보장하지만, 명령 간 조건부 로직은 불가능하고 명령 실행 중 에러가 발생해도 롤백되지 않습니다. Lua Script는 Redis가 단일 스레드로 스크립트 전체를 원자적으로 실행하므로, 조건문과 반복문을 포함한 복잡한 로직을 원자적으로 처리할 수 있으며 중간에 다른 명령이 끼어들 수 없습니다. WATCH는 지정한 키를 모니터링하여 MULTI 실행 전에 키가 변경되면 EXEC가 실패(nil 반환)하는 낙관적 락을 구현하며, 여러 클라이언트가 동시에 같은 키를 수정하려 할 때 경쟁 조건이 발생합니다. 재시도 로직 설계 시 무한 루프를 방지하기 위한 최대 재시도 횟수 제한, 재시도 간 지수 백오프 적용, 경쟁이 심한 경우 Lua Script나 분산 락으로 전환하는 폴백 전략을 고려해야 합니다.

Redis Pipeline은 여러 명령을 클라이언트 측에서 버퍼링한 후 한 번의 네트워크 전송으로 서버에 보내고, 모든 응답을 받아오는 방식으로, N개 명령의 RTT를 N번에서 1번으로 줄여 네트워크 지연을 극적으로 감소시킵니다. 일반 실행은 명령마다 send-receive 사이클이 필요하지만, Pipeline은 명령들을 모아서 보내므로 네트워크 대역폭을 효율적으로 사용합니다. 주의할 점은 클라이언트와 서버 양쪽 모두 응답을 버퍼에 누적하므로, 배치 크기가 너무 크면 메모리 사용량이 급증하고 네트워크 타임아웃이 발생할 수 있습니다. 적절한 배치 크기는 네트워크 조건과 명령 크기에 따라 다르지만 일반적으로 100~1000개 정도가 적절하며, 메모리 사용량과 처리 시간을 모니터링하여 조정해야 합니다. Pipeline은 단순히 네트워크 최적화이며 원자성을 보장하지 않지만, MULTI/EXEC는 명령들의 원자적 실행을 보장하며, 두 기법을 함께 사용할 수도 있습니다.

Redis Sentinel은 master를 주기적으로 모니터링하며, 개별 Sentinel이 master 응답이 없다고 판단하면 SDOWN(주관적 다운) 상태로 표시합니다. 여러 Sentinel이 SDOWN을 감지하고 quorum 이상의 Sentinel이 동의하면 ODOWN(객관적 다운)으로 전환되어 페일오버가 시작됩니다. Quorum은 ODOWN 판단에 필요한 최소 Sentinel 수이며, 페일오버 승인에는 전체 Sentinel의 과반수(majority)가 필요하므로, quorum은 majority 이하로 설정해야 합니다. 일반적으로 Sentinel을 홀수 개(3개 또는 5개) 배치하고 quorum을 과반수로 설정합니다. 스플릿 브레인은 네트워크 파티션으로 구 master가 격리되어도 쓰기를 계속 받는 상황으로, min-replicas-to-write와 min-replicas-max-lag 설정으로 replica 연결 수가 부족하면 쓰기를 거부하도록 하여 방지할 수 있습니다. 또한 Sentinel을 여러 가용 영역에 분산 배치하고, 클라이언트가 Sentinel을 통해 master를 발견하도록 하여 페일오버 후 자동으로 새 master에 연결되도록 설계해야 합니다.

Redis Module API는 C 언어로 작성된 동적 라이브러리를 Redis 프로세스에 로드하여 새로운 명령과 자료구조를 추가할 수 있게 하며, MODULE LOAD 명령으로 런타임에 로드됩니다. Module 명령도 Redis의 단일 스레드 이벤트 루프에서 실행되므로 네이티브 명령과 동일하게 블로킹되며, 복잡한 연산은 성능 저하를 유발할 수 있습니다. RedisJSON은 JSON 문서를 JSONPath로 조작하며 내부적으로 트리 구조를 사용하고, RedisGraph는 그래프 쿼리를 위해 인접 행렬을 최적화한 구조를, RedisBloom은 Bloom Filter와 Cuckoo Filter를 제공합니다. 프로덕션 도입 시 Module 버그가 Redis 프로세스 전체를 크래시시킬 수 있고, Redis 버전 업그레이드 시 Module 호환성 문제가 발생할 수 있으며, 일부 Module은 AOF/RDB 직렬화를 완벽히 지원하지 않을 수 있습니다. 따라서 충분한 테스트, 버전 고정, 백업 전략 수립, 그리고 커뮤니티 활성도와 유지보수 상태를 확인해야 합니다.

RESP는 텍스트 기반 프로토콜로 Simple String(+), Error(-), Integer(:), Bulk String($), Array(*) 다섯 가지 데이터 타입을 첫 바이트로 구분하며, CRLF로 구분된 라인 단위로 파싱합니다. 예를 들어 Bulk String은 '$길이CRLF데이터CRLF' 형식이며, Array는 중첩 가능합니다. RESP3는 RESP2를 확장하여 Map, Set, Boolean, Double, Null 등 추가 타입을 지원하고, Push 타입으로 서버가 클라이언트에게 비동기 메시지를 보낼 수 있으며, 더 풍부한 메타데이터를 전달할 수 있습니다. 클라이언트 구현 시 스트림 기반 파싱으로 부분 응답을 처리하고, 버퍼 크기를 제한하여 메모리 소진을 방지하며, 파이프라인된 응답의 순서를 유지해야 합니다. 대용량 응답(예: 큰 Bulk String)은 스트리밍 방식으로 읽어 메모리에 한 번에 로드하지 않고, 청크 단위로 처리하거나 디스크에 임시 저장하는 전략을 사용합니다. 에러는 Error 타입으로 명확히 구분되며, 클라이언트는 이를 예외로 변환하여 애플리케이션에 전달합니다.