Redis 미드레벨 CS 기초 기술면접
새 면접Q. Redis는 RESP(REdis Serialization Protocol) 프로토콜을 사용합니다. RESP 프로토콜의 특징과 장점을 설명하고, TCP 기반으로 동작하는 Redis가 높은 성능을 유지할 수 있는 네트워크 레벨의 이유를 설명해주세요.
RESP는 텍스트 기반의 간단한 프로토콜로, 사람이 읽을 수 있으며 파싱이 빠릅니다. Simple Strings, Errors, Integers, Bulk Strings, Arrays 등 5가지 데이터 타입으로 구성되어 있어 구현이 단순합니다. Redis는 단일 스레드 이벤트 루프와 I/O 멀티플렉싱(epoll, kqueue)을 사용하여 컨텍스트 스위칭 오버헤드 없이 수천 개의 동시 연결을 효율적으로 처리합니다. 또한 메모리 기반 데이터 저장으로 디스크 I/O 대기 시간이 없고, 파이프라이닝을 통해 RTT(Round Trip Time)를 최소화할 수 있습니다.
- • RESP는 텍스트 기반의 간단한 프로토콜로 파싱 성능이 우수함
- • 단일 스레드 이벤트 루프와 I/O 멀티플렉싱으로 컨텍스트 스위칭 오버헤드 제거
- • 메모리 기반 저장으로 디스크 I/O 없이 빠른 응답 제공
- • 파이프라이닝을 통한 네트워크 RTT 최소화
Redis 6.0부터 도입된 I/O 멀티 스레딩은 기존 단일 스레드 모델과 어떻게 다르며, 어떤 부분의 성능을 개선하나요?
Q. Redis의 Sorted Set은 내부적으로 skiplist와 hash table을 함께 사용합니다. skiplist의 시간 복잡도와 구조적 특징을 설명하고, 왜 Red-Black Tree나 AVL Tree 같은 균형 이진 탐색 트리 대신 skiplist를 선택했는지 그 이유를 설명해주세요.
skiplist는 확률적 균형 자료구조로, 검색/삽입/삭제의 평균 시간 복잡도가 O(log n)입니다. 여러 레벨의 연결 리스트로 구성되며, 상위 레벨은 하위 레벨의 '고속도로' 역할을 합니다. Redis가 skiplist를 선택한 이유는 첫째, 구현이 Red-Black Tree보다 단순하고 버그 가능성이 낮습니다. 둘째, 범위 쿼리(ZRANGE)에서 skiplist는 순차적 메모리 접근으로 캐시 친화적이며 연속된 노드 탐색이 효율적입니다. 셋째, lock-free 구현이 상대적으로 용이하며, 재균형 작업이 필요 없어 삽입/삭제 시 예측 가능한 성능을 보장합니다.
- • skiplist는 O(log n) 시간 복잡도를 가진 확률적 균형 자료구조
- • 구현이 단순하고 디버깅이 쉬우며 코드 유지보수성이 높음
- • 범위 쿼리에서 순차적 메모리 접근으로 캐시 효율성이 우수
- • 재균형 작업이 불필요하여 삽입/삭제 성능이 예측 가능함
Sorted Set에서 hash table을 skiplist와 함께 사용하는 이유는 무엇이며, 각각 어떤 연산을 최적화하나요?
Q. Redis는 fork() 시스템 콜을 사용하여 백그라운드에서 RDB 스냅샷을 생성합니다. fork()의 Copy-on-Write(COW) 메커니즘을 설명하고, 메모리 사용량이 높은 Redis 인스턴스에서 fork() 실행 시 발생할 수 있는 문제점과 해결 방안을 제시해주세요.
fork()는 부모 프로세스를 복제하여 자식 프로세스를 생성하며, COW 메커니즘으로 실제 메모리 복사 없이 페이지 테이블만 공유합니다. 부모나 자식이 메모리를 수정할 때만 해당 페이지가 실제로 복사됩니다. 문제점은 첫째, fork() 호출 시 페이지 테이블 복사로 수백 ms의 지연이 발생할 수 있고, 둘째, 쓰기 작업이 많으면 COW로 인해 메모리 사용량이 최대 2배까지 증가할 수 있습니다. 해결 방안으로는 충분한 메모리 여유 확보, vm.overcommit_memory=1 설정, Transparent Huge Pages 비활성화, 쓰기 트래픽이 적은 시간대에 백업 스케줄링, Replica에서 백업 수행 등이 있습니다.
- • COW는 메모리 수정 시에만 실제 복사가 발생하는 최적화 기법
- • fork() 시 페이지 테이블 복사로 인한 지연과 메모리 사용량 증가 가능
- • vm.overcommit_memory 설정과 THP 비활성화로 최적화
- • Replica에서 백업을 수행하여 Master의 부하 분산
Redis를 Docker 컨테이너에서 실행할 때 fork() 관련 메모리 문제를 어떻게 처리해야 하며, 메모리 제한 설정 시 주의사항은 무엇인가요?
Q. Redis는 기본적으로 eventual consistency 모델을 따릅니다. CAP 이론 관점에서 Redis의 특성을 분석하고, Redis Sentinel과 Redis Cluster 각각이 네트워크 파티션 상황에서 어떻게 동작하는지 설명해주세요.
CAP 이론에서 Redis는 기본적으로 AP(Availability + Partition tolerance)를 선택합니다. 비동기 복제로 인해 일시적 데이터 불일치를 허용하며, 네트워크 파티션 시에도 가용성을 우선합니다. Redis Sentinel은 파티션 발생 시 과반수 투표로 페일오버를 수행하지만, 소수 파티션의 구 Master는 여전히 쓰기를 받아 데이터 손실 가능성이 있습니다. Redis Cluster는 과반수 마스터가 있는 파티션만 동작하며, 소수 파티션은 쓰기를 거부합니다. WAIT 명령어나 min-replicas-to-write 설정으로 부분적인 강일관성을 구현할 수 있지만, 성능 트레이드오프가 발생합니다.
- • Redis는 CAP 이론에서 AP를 선택하며 eventual consistency 제공
- • 비동기 복제로 인한 일시적 데이터 불일치 허용
- • Sentinel은 과반수 투표 기반 페일오버, 소수 파티션에서 데이터 손실 가능
- • Cluster는 과반수 파티션만 동작, WAIT 명령으로 부분적 강일관성 구현 가능
금융 거래처럼 강일관성이 필수적인 시스템에서 Redis를 사용해야 한다면 어떤 아키텍처 패턴과 설정을 적용하시겠습니까?
Q. Redis의 단일 스레드 모델에서 명령어가 원자적으로 실행되는 원리를 설명하고, 이벤트 루프 기반 아키텍처에서 긴 실행 시간을 가진 명령어(예: KEYS, FLUSHALL)가 전체 시스템에 미치는 영향과 이를 모니터링하고 방지하는 방법을 제시해주세요.
Redis는 단일 스레드 이벤트 루프로 명령어를 순차적으로 처리하여 각 명령어가 완료될 때까지 다른 명령어가 실행되지 않으므로 원자성이 보장됩니다. 긴 실행 시간을 가진 명령어는 이벤트 루프를 블로킹하여 모든 클라이언트의 요청이 대기하게 되고, 타임아웃과 응답 지연이 발생합니다. 모니터링 방법으로는 SLOWLOG를 통해 느린 명령어를 추적하고, INFO commandstats로 명령어별 통계를 확인하며, latency monitoring 기능으로 지연 이벤트를 감지합니다. 방지 방법으로는 rename-command로 위험한 명령어를 비활성화하고, SCAN/SSCAN 등 커서 기반 명령어를 사용하며, 복잡한 연산은 Lua 스크립트로 최적화하고, Redis 6.0 이상에서는 ACL로 명령어 접근을 제한합니다.
- • 단일 스레드 이벤트 루프로 명령어 순차 처리하여 원자성 보장
- • 긴 실행 시간 명령어는 이벤트 루프 블로킹으로 전체 시스템 지연 발생
- • SLOWLOG, INFO commandstats, latency monitoring으로 모니터링
- • rename-command, SCAN 계열 사용, ACL 설정으로 방지
Redis 7.0의 Multi-threaded I/O와 Functions 기능이 이러한 블로킹 문제를 어떻게 개선하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!