Redis 주니어 CS 기초 면접
새 면접Q. Redis는 TCP 기반으로 통신합니다. TCP의 3-way handshake와 4-way handshake 과정을 설명하고, Redis 클라이언트가 연결을 맺을 때 발생하는 네트워크 오버헤드를 줄이기 위해 Connection Pool을 사용하는 이유를 설명해주세요.
TCP 3-way handshake는 연결 수립 시 SYN, SYN-ACK, ACK 세 단계로 이루어지며, 4-way handshake는 연결 종료 시 FIN, ACK, FIN, ACK 네 단계로 진행됩니다. Redis는 명령 하나를 실행하는데 매번 연결을 맺고 끊으면 handshake 오버헤드가 크기 때문에 Connection Pool을 사용하여 연결을 재사용합니다. Connection Pool은 미리 생성된 연결들을 관리하여 매 요청마다 연결 수립 비용을 제거하고, 동시 연결 수를 제한하여 서버 리소스를 보호합니다. 이를 통해 응답 시간을 단축하고 처리량을 높일 수 있습니다.
- • 3-way handshake(SYN, SYN-ACK, ACK)로 연결 수립, 4-way handshake로 연결 종료
- • 매 요청마다 handshake 수행 시 네트워크 오버헤드 발생
- • Connection Pool을 통한 연결 재사용으로 성능 향상 및 리소스 관리
Connection Pool의 최대 크기를 설정할 때 고려해야 할 요소는 무엇이며, Pool이 부족할 경우 어떤 문제가 발생할 수 있나요?
Q. Redis의 List 자료구조는 내부적으로 링크드 리스트(Linked List)로 구현되어 있습니다. 배열(Array) 기반 리스트와 링크드 리스트의 시간 복잡도 차이를 비교하고, Redis List에서 LPUSH, RPUSH, LPOP, RPOP 명령어가 빠른 이유를 설명해주세요.
배열은 인덱스 접근이 O(1)이지만 앞/뒤 삽입/삭제는 O(n)이며, 링크드 리스트는 인덱스 접근이 O(n)이지만 head/tail 삽입/삭제는 O(1)입니다. Redis List는 양방향 링크드 리스트로 구현되어 head와 tail에 대한 포인터를 유지하므로, LPUSH(head 삽입), RPUSH(tail 삽입), LPOP(head 삭제), RPOP(tail 삭제) 모두 O(1) 시간에 수행됩니다. 따라서 큐나 스택 같은 자료구조를 구현할 때 매우 효율적입니다.
- • 배열은 랜덤 접근 O(1), 링크드 리스트는 head/tail 삽입/삭제 O(1)
- • Redis List는 양방향 링크드 리스트로 구현
- • LPUSH, RPUSH, LPOP, RPOP 모두 O(1) 시간 복잡도
Redis List에서 중간 인덱스의 요소를 조회하는 LINDEX 명령어의 시간 복잡도는 어떻게 되며, 이것이 성능에 어떤 영향을 미칠 수 있나요?
Q. Redis는 메모리 기반 데이터베이스로 모든 데이터를 RAM에 저장합니다. 운영체제의 가상 메모리(Virtual Memory)와 스왑(Swap) 개념을 설명하고, Redis가 스왑 영역을 사용하게 되면 성능이 급격히 저하되는 이유를 설명해주세요.
가상 메모리는 물리 메모리보다 큰 주소 공간을 제공하는 기술이며, 스왑은 RAM이 부족할 때 디스크의 일부를 메모리처럼 사용하는 기법입니다. Redis 데이터가 스왑 영역으로 이동하면 디스크 I/O가 발생하는데, 디스크는 RAM보다 수천 배 느리기 때문에 Redis의 핵심 장점인 빠른 응답 속도가 사라집니다. 특히 Redis는 모든 데이터에 빠른 접근을 전제로 설계되었기 때문에, 일부 데이터만 스왑되어도 전체 성능이 크게 저하됩니다. 따라서 Redis 운영 시 충분한 물리 메모리 확보와 스왑 비활성화가 권장됩니다.
- • 가상 메모리와 스왑은 물리 메모리 부족 시 디스크를 활용
- • 디스크 I/O는 RAM보다 수천 배 느려 성능 급격히 저하
- • Redis는 모든 데이터에 빠른 접근을 전제로 설계되어 스왑 사용 시 치명적
Redis 서버에서 메모리 사용량을 모니터링할 때 어떤 지표들을 확인해야 하며, OOM(Out Of Memory) 상황을 예방하기 위한 방법은 무엇인가요?
Q. Redis의 HyperLogLog는 카디널리티(중복을 제거한 고유 원소의 개수)를 추정하는 확률적 자료구조입니다. 정확한 카운팅을 위해 Set을 사용하는 방법과 비교했을 때 HyperLogLog의 장단점을 설명하고, 어떤 상황에서 사용하는 것이 적합한지 말씀해주세요.
Set은 모든 원소를 저장하여 정확한 카디널리티를 제공하지만, 원소가 많아질수록 메모리 사용량이 선형적으로 증가합니다. HyperLogLog는 확률적 알고리즘을 사용하여 약 0.81%의 오차율로 카디널리티를 추정하며, 최대 12KB의 고정된 메모리만 사용합니다. 수백만~수억 개의 고유 방문자 수를 추적하거나 대규모 이벤트 로그 분석처럼 정확도보다 메모리 효율성이 중요한 경우에 적합합니다. 반면 정확한 카운팅이 필요하거나 원소 수가 적은 경우에는 Set이 더 적합합니다.
- • Set은 정확하지만 메모리 사용량이 원소 수에 비례
- • HyperLogLog는 고정 메모리(12KB)로 약 0.81% 오차율로 추정
- • 대규모 고유 카운팅에서 메모리 효율성이 중요할 때 사용
HyperLogLog가 사용하는 확률적 카운팅 알고리즘의 기본 원리는 무엇이며, 왜 고정된 메모리만으로 대용량 카디널리티를 추정할 수 있나요?
Q. 데이터베이스의 인덱스(Index)가 무엇인지 설명하고, Redis에서 특정 필드 값으로 빠르게 검색하기 위해 인덱스를 구현하려면 어떤 방식을 사용할 수 있는지 설명해주세요.
인덱스는 데이터베이스에서 특정 컬럼 값으로 빠르게 검색하기 위한 자료구조로, 보통 B-Tree나 Hash 구조로 구현됩니다. Redis는 기본적으로 Key 기반 접근만 O(1)이고 Value 내부 필드로는 직접 검색할 수 없습니다. 따라서 보조 인덱스를 직접 구현해야 하며, 검색하려는 필드 값을 Key로 하는 별도의 Set이나 Sorted Set을 생성하여 원본 Key들을 저장하는 방식을 사용합니다. 예를 들어 사용자 이메일로 검색하려면 'email:[email protected]' 키에 해당 사용자 ID를 저장하는 식입니다. 데이터 변경 시 인덱스도 함께 업데이트해야 하는 점이 중요합니다.
- • 인덱스는 특정 값으로 빠른 검색을 위한 보조 자료구조
- • Redis는 Key 기반 접근만 지원하므로 보조 인덱스를 직접 구현
- • 검색 필드를 Key로 하는 별도 자료구조를 생성하여 원본 Key 저장
Redis에서 범위 검색(예: 나이가 20~30세인 사용자)을 지원하는 인덱스를 구현하려면 어떤 데이터 타입을 사용하는 것이 좋을까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!