Redis 주니어 CS 기초 면접
새 면접Q. Redis는 클라이언트-서버 통신에 RESP(Redis Serialization Protocol)를 사용합니다. RESP의 특징과 왜 Redis가 HTTP 대신 RESP를 사용하는지 설명해주세요.
RESP는 Redis 전용 텍스트 기반 프로토콜로, 간단하고 파싱이 빠르며 사람이 읽을 수 있는 형태입니다. HTTP는 헤더와 메타데이터가 많아 오버헤드가 크지만, RESP는 최소한의 정보만 전송하여 네트워크 비용과 파싱 시간을 줄입니다. Redis는 초당 수만~수십만 건의 요청을 처리해야 하는 인메모리 DB이므로, 프로토콜 오버헤드를 최소화하는 것이 중요하여 RESP를 사용합니다. RESP는 배열, 문자열, 정수, 에러 등 5가지 기본 타입으로 구성되어 있습니다.
- • RESP는 텍스트 기반의 경량 프로토콜
- • HTTP 대비 오버헤드가 적어 성능이 우수
- • 고속 처리가 필요한 인메모리 DB 특성에 적합
- • 간단한 구조로 파싱 속도가 빠름
RESP 프로토콜에서 문자열과 배열은 어떤 형식으로 표현되는지 아시나요?
Q. Redis의 Hash 자료구조 내부는 두 가지 인코딩 방식(ziplist와 hashtable)으로 구현됩니다. 각 인코딩 방식의 특징과 언제 ziplist에서 hashtable로 전환되는지 설명해주세요.
ziplist는 연속된 메모리 공간에 데이터를 저장하는 압축된 형태로, 메모리 효율이 높지만 선형 탐색이 필요합니다. hashtable은 해시 테이블 구조로 O(1) 조회가 가능하지만 메모리 오버헤드가 있습니다. Redis는 Hash에 저장된 필드 개수가 512개 미만이고 각 값의 크기가 64바이트 미만일 때 ziplist를 사용하며, 이 임계값을 초과하면 자동으로 hashtable로 전환됩니다. 이는 작은 데이터셋에서는 메모리 효율을, 큰 데이터셋에서는 조회 성능을 최적화하기 위한 전략입니다.
- • ziplist는 메모리 효율적이지만 O(n) 탐색
- • hashtable은 O(1) 조회이지만 메모리 오버헤드 존재
- • 필드 512개 또는 값 64바이트 초과 시 전환
- • 데이터 크기에 따른 자동 최적화 전략
ziplist를 사용할 때의 시간 복잡도 O(n)이 실제 성능에 큰 영향을 미치지 않는 이유는 무엇일까요?
Q. Redis는 싱글 스레드로 동작하면서도 높은 성능을 보입니다. 싱글 스레드 구조에서 어떻게 높은 처리량을 달성할 수 있는지, 그리고 멀티 스레드 대비 어떤 장점이 있는지 설명해주세요.
Redis는 I/O 멀티플렉싱(epoll, kqueue 등)을 사용하여 하나의 스레드로 수천 개의 클라이언트 연결을 동시에 처리합니다. 모든 데이터가 메모리에 있어 디스크 I/O가 없고, 명령어 처리가 매우 빠르기 때문에 CPU 바운드 작업이 주를 이룹니다. 싱글 스레드 방식은 컨텍스트 스위칭 오버헤드가 없고, 락이나 동기화 메커니즘이 필요 없어 구현이 단순하며 race condition 문제가 발생하지 않습니다. 다만 Redis 6.0부터는 I/O 스레드를 별도로 두어 네트워크 처리를 병렬화했습니다.
- • I/O 멀티플렉싱으로 다수의 연결 처리
- • 인메모리 특성으로 빠른 명령어 실행
- • 컨텍스트 스위칭과 락 오버헤드 없음
- • race condition 걱정 없이 단순한 구조
싱글 스레드 구조의 Redis에서 시간이 오래 걸리는 명령어(예: KEYS *)를 실행하면 어떤 문제가 발생할까요?
Q. Redis는 NoSQL 데이터베이스 중 Key-Value 스토어로 분류됩니다. Key-Value 스토어의 특징과 Document DB, Column-Family DB 같은 다른 NoSQL 유형과의 차이점을 설명해주세요.
Key-Value 스토어는 고유한 키와 값의 쌍으로 데이터를 저장하는 가장 단순한 NoSQL 형태로, 키를 통한 빠른 조회가 가능하지만 값 내부의 특정 필드로는 검색할 수 없습니다. Document DB(MongoDB 등)는 JSON 같은 문서 형태로 저장하며 중첩된 구조를 쿼리할 수 있고, Column-Family DB(Cassandra 등)는 행과 열로 데이터를 구성하되 열 단위로 저장하여 분석 쿼리에 유리합니다. Redis는 Key-Value 기반이지만 String, List, Set, Hash 등 다양한 값 타입을 제공하여 단순 Key-Value 스토어보다 풍부한 기능을 제공합니다.
- • Key-Value는 단순한 키 기반 조회 구조
- • Document DB는 문서 내부 쿼리 가능
- • Column-Family는 열 지향 저장으로 분석에 유리
- • Redis는 다양한 데이터 타입으로 확장된 Key-Value 스토어
Redis에서 복잡한 검색 쿼리가 필요한 경우 어떤 방법으로 해결할 수 있을까요?
Q. Redis의 Sorted Set은 Skip List와 Hash Table의 조합으로 구현됩니다. Skip List가 무엇인지 설명하고, 왜 Balanced Tree(AVL, Red-Black Tree) 대신 Skip List를 사용하는지 말씀해주세요.
Skip List는 정렬된 연결 리스트에 여러 레벨의 인덱스를 추가하여 O(log n) 검색을 가능하게 하는 확률적 자료구조입니다. 각 노드는 무작위로 여러 레벨을 가질 수 있으며, 상위 레벨은 하위 레벨의 일부 노드만 포함하여 빠른 탐색을 지원합니다. Balanced Tree 대비 Skip List는 구현이 훨씬 단순하고, 삽입/삭제 시 복잡한 회전 연산이 필요 없으며, 범위 검색 시 순차 접근이 용이합니다. 또한 락프리 구현이 상대적으로 쉬워 동시성 처리에 유리하며, 캐시 지역성 측면에서도 이점이 있습니다.
- • Skip List는 다단계 인덱스를 가진 정렬 리스트
- • O(log n) 검색/삽입/삭제 성능
- • Balanced Tree 대비 구현이 단순하고 회전 연산 불필요
- • 범위 검색과 동시성 처리에 유리
Skip List에서 노드의 레벨을 결정할 때 사용하는 확률적 방법은 어떻게 동작하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!