Redis 시니어 CS 기초 기술면접
새 면접Q. Redis는 RESP(Redis Serialization Protocol)를 사용하여 클라이언트와 통신합니다. RESP 프로토콜의 구조와 특징을 설명하고, TCP 기반 텍스트 프로토콜을 선택한 이유를 바이너리 프로토콜과 비교하여 설명해주세요. 또한 파이프라이닝이 가능한 이유를 프로토콜 관점에서 설명해주세요.
RESP는 Simple String, Error, Integer, Bulk String, Array 5가지 타입을 줄바꿈 문자로 구분하는 텍스트 기반 프로토콜입니다. 각 메시지는 타입 식별자(+, -, :, $, *)로 시작하며, 사람이 읽을 수 있어 디버깅이 쉽고 구현이 단순합니다. 바이너리 프로토콜 대비 파싱 오버헤드가 약간 있지만, Redis의 병목은 주로 네트워크 I/O이므로 영향이 적습니다. 요청-응답이 순서대로 매칭되는 구조이기 때문에 클라이언트는 응답을 기다리지 않고 여러 명령을 연속으로 전송할 수 있어 파이프라이닝이 가능합니다.
- • 5가지 데이터 타입(Simple String, Error, Integer, Bulk String, Array)과 타입 식별자
- • 텍스트 기반으로 디버깅 용이성과 구현 단순성 확보
- • 요청-응답 순서 보장으로 파이프라이닝 지원
RESP2와 RESP3의 차이점은 무엇이며, RESP3에서 추가된 기능들이 어떤 문제를 해결하나요?
Q. Redis는 jemalloc을 기본 메모리 할당자로 사용합니다. jemalloc의 동작 원리와 glibc malloc 대비 장점을 설명하고, Redis처럼 빈번한 할당/해제가 발생하는 환경에서 메모리 단편화(fragmentation)를 줄이는 메커니즘을 설명해주세요. 또한 INFO memory에서 확인할 수 있는 mem_fragmentation_ratio의 의미와 문제 해결 방법을 제시해주세요.
jemalloc은 크기별로 메모리를 arena와 bin으로 분리하여 관리하며, thread-local 캐시를 활용해 lock contention을 줄입니다. 작은 객체는 slab 방식으로 같은 크기끼리 묶어 할당하고, 큰 객체는 별도로 관리하여 단편화를 최소화합니다. glibc malloc 대비 멀티스레드 환경에서 성능이 우수하고, size class를 통한 할당으로 외부 단편화가 적습니다. mem_fragmentation_ratio는 used_memory_rss / used_memory 값으로, 1.5 이상이면 단편화가 심각한 상태입니다. 해결 방법으로는 activedefrag 설정을 활성화하거나, 데이터 구조 최적화, 재시작을 통한 메모리 재구성이 있습니다.
- • arena와 bin 기반 크기별 메모리 관리, thread-local 캐시로 lock contention 감소
- • size class를 통한 slab 방식 할당으로 단편화 최소화
- • mem_fragmentation_ratio 모니터링과 activedefrag를 통한 능동적 단편화 해소
activedefrag가 활성화되었을 때 Redis의 응답 시간에 미치는 영향과, 프로덕션 환경에서 안전하게 적용하기 위한 설정 전략은 무엇인가요?
Q. Redis의 HyperLogLog는 O(1) 공간 복잡도로 카디널리티를 추정합니다. HyperLogLog 알고리즘의 동작 원리를 해시 함수와 확률론적 접근 관점에서 설명하고, 표준 오차율 0.81%를 달성하기 위해 12KB의 고정 메모리를 사용하는 이유를 수학적 배경과 함께 설명해주세요. 또한 실무에서 정확한 COUNT DISTINCT 대신 HyperLogLog를 선택해야 하는 시나리오를 제시해주세요.
HyperLogLog는 입력값을 해시한 후 이진수로 변환하여 앞에서부터 연속된 0의 개수를 관찰합니다. 확률적으로 n개의 고유값이 있으면 최대 연속 0의 개수는 log2(n)에 근접하므로, 이를 역산하여 카디널리티를 추정합니다. 정확도 향상을 위해 16384개의 버킷(2^14)으로 분할하여 조화평균을 계산하며, 각 버킷은 6비트(0~63 저장)를 사용해 총 12KB(16384 * 6bit)가 필요합니다. 표준 오차는 1.04/sqrt(m)이므로 m=16384일 때 약 0.81%입니다. 일일 순방문자 집계, 실시간 이벤트 중복 제거 등 수백만~수억 건의 고유값 카운팅이 필요하지만 99% 정확도로 충분한 경우 적합합니다.
- • 해시값의 연속 0 개수로 카디널리티 추정, 조화평균으로 정확도 향상
- • 16384개 버킷 * 6비트 = 12KB 고정 메모리, 표준 오차 0.81% 달성
- • 수억 건 규모에서 메모리 효율이 중요하고 근사값으로 충분한 경우 활용
Redis의 PFCOUNT 명령어로 여러 HyperLogLog를 병합할 때 정확도가 유지되는 원리와, Bloom Filter와의 사용 사례 차이를 설명해주세요.
Q. Redis 6.0부터 I/O 스레드가 도입되었지만 여전히 명령 실행은 단일 스레드로 처리됩니다. I/O 스레드의 역할과 동작 방식을 설명하고, 어떤 부분이 멀티스레드화 되었는지, 그리고 명령 실행을 멀티스레드화하지 않는 이유를 동시성 제어와 복잡도 관점에서 설명해주세요.
Redis 6.0의 I/O 스레드는 클라이언트로부터 데이터를 읽고 쓰는 네트워크 I/O 작업만 담당하며, 실제 명령 파싱과 실행은 메인 스레드에서 순차적으로 처리됩니다. 여러 I/O 스레드가 소켓에서 데이터를 읽어 버퍼에 저장하면, 메인 스레드가 이를 파싱하고 실행한 후, 다시 I/O 스레드들이 응답을 클라이언트에게 전송합니다. 명령 실행을 단일 스레드로 유지하는 이유는 락이나 동기화 없이 데이터 구조에 접근할 수 있어 복잡도가 낮고, race condition이 발생하지 않으며, 코드 유지보수가 쉽기 때문입니다. Redis의 병목은 주로 네트워크 I/O이므로 이 부분만 멀티스레드화해도 충분한 성능 향상을 얻을 수 있습니다.
- • I/O 스레드는 네트워크 읽기/쓰기만 처리, 명령 실행은 메인 스레드 담당
- • 단일 스레드 실행으로 락 없는 데이터 접근, race condition 방지
- • 병목이 네트워크 I/O이므로 해당 부분만 멀티스레드화로 성능 개선
io-threads 설정값을 CPU 코어 수만큼 늘리는 것이 항상 좋은 전략인가요? 최적값을 결정하는 기준은 무엇인가요?
Q. Redis의 Sorted Set에서 ZRANGEBYLEX 명령어를 사용하면 사전순 범위 검색이 가능합니다. 이것이 가능한 내부 구조적 이유를 Skip List의 특성과 연결하여 설명하고, ZRANGEBYSCORE와 ZRANGEBYLEX의 시간 복잡도 차이와 각각의 적합한 사용 사례를 제시해주세요. 또한 자동완성 기능 구현 시 고려해야 할 메모리 최적화 전략을 설명해주세요.
Sorted Set은 score가 같을 때 member를 사전순으로 정렬하는 특성이 있으며, Skip List는 순서를 유지하면서 범위 검색을 지원합니다. ZRANGEBYLEX는 모든 member의 score를 동일하게 설정(보통 0)하여 순수하게 사전순 정렬만 활용하며, 시간 복잡도는 O(log(N)+M)입니다. ZRANGEBYSCORE는 score 기반 검색으로 동일한 복잡도이지만 수치 범위 검색에 적합하고, ZRANGEBYLEX는 문자열 prefix 검색에 유리합니다. 자동완성 구현 시 전체 문자열 대신 prefix만 저장하거나, 빈도수 기반으로 상위 N개만 유지하고, 긴 문자열은 해시로 압축하여 별도 저장하는 전략이 필요합니다. 또한 LIMIT 옵션으로 결과 개수를 제한하여 네트워크 오버헤드를 줄여야 합니다.
- • score 동일 시 member 사전순 정렬, Skip List의 순서 보장 특성 활용
- • ZRANGEBYSCORE는 수치 범위, ZRANGEBYLEX는 문자열 prefix 검색에 최적화
- • 자동완성 시 prefix 저장, 빈도수 기반 제한, LIMIT으로 결과 제한
수백만 개의 검색어를 저장해야 할 때 Sorted Set 대신 Trie 자료구조를 Redis에 구현한다면 어떤 자료구조 조합을 사용할 수 있으며, 트레이드오프는 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!