Redis 미드레벨 기술면접
새 면접Q. Redis의 Hash 자료구조에서 ziplist 인코딩을 사용할 때와 hashtable 인코딩을 사용할 때의 성능 차이를 설명하고, hash-max-ziplist-entries와 hash-max-ziplist-value 설정값이 실제 운영 환경에서 미치는 영향을 메모리와 CPU 관점에서 분석해주세요.
ziplist는 연속된 메모리 공간에 데이터를 저장하여 메모리 효율이 높지만 O(N) 탐색 시간을 가지며, hashtable은 O(1) 탐색이 가능하지만 포인터 오버헤드로 메모리 사용량이 큽니다. hash-max-ziplist-entries(기본 512)는 필드 개수 임계값이고, hash-max-ziplist-value(기본 64)는 값의 크기 임계값으로, 둘 중 하나라도 초과하면 hashtable로 전환됩니다. 작은 해시가 많은 경우 임계값을 높이면 메모리를 절약할 수 있지만, 필드 접근이 느려져 CPU 사용량이 증가할 수 있으므로 워크로드 특성에 따라 조정해야 합니다.
- • ziplist는 메모리 효율적이지만 O(N) 탐색, hashtable은 O(1) 탐색이지만 메모리 오버헤드 존재
- • hash-max-ziplist-entries는 필드 수, hash-max-ziplist-value는 값 크기의 임계값
- • 임계값 증가 시 메모리 절약 가능하지만 CPU 사용량 증가 트레이드오프 존재
실제 프로덕션에서 해시 필드가 1000개 이상인 경우가 많다면, 설계를 어떻게 변경하시겠습니까?
Q. Redis의 WAIT 명령어가 복제 지연 문제를 해결하는 방식을 설명하고, WAIT을 사용할 때의 성능 영향과 한계점을 분석해주세요. 또한 네트워크 파티션 상황에서 WAIT 명령어의 동작과 데이터 일관성 보장 수준을 설명해주세요.
WAIT 명령어는 지정된 수의 복제본이 쓰기 작업을 확인할 때까지 클라이언트를 블로킹하여 동기식 복제를 시뮬레이션합니다. 복제본 수와 타임아웃을 파라미터로 받으며, 성능상 응답 시간이 증가하고 처리량이 감소합니다. 하지만 WAIT은 강한 일관성을 보장하지 않으며, 네트워크 파티션 발생 시 복제본이 마스터와 분리되어도 이전에 WAIT으로 확인된 데이터가 손실될 수 있습니다. 따라서 WAIT은 데이터 유실 가능성을 줄이는 보조 수단일 뿐 완벽한 보장은 아닙니다.
- • WAIT은 N개 복제본의 쓰기 확인까지 블로킹하여 동기 복제 효과 제공
- • 응답 시간 증가와 처리량 감소라는 성능 트레이드오프 존재
- • 강한 일관성을 보장하지 않으며, 네트워크 파티션 시 데이터 손실 가능
금융 시스템처럼 강한 일관성이 필요한 경우, Redis 대신 어떤 저장소를 고려하시겠습니까?
Q. Redis의 INFO 명령어에서 확인할 수 있는 used_memory, used_memory_rss, used_memory_peak, mem_fragmentation_ratio 메트릭의 의미를 설명하고, mem_fragmentation_ratio가 1.5 이상일 때와 1.0 미만일 때 각각 어떤 문제를 의미하는지, 그리고 해결 방법을 제시해주세요.
used_memory는 Redis가 할당한 논리적 메모리, used_memory_rss는 OS가 실제 할당한 물리 메모리, used_memory_peak는 최대 메모리 사용량, mem_fragmentation_ratio는 rss/used_memory 비율입니다. 비율이 1.5 이상이면 메모리 단편화가 심각하여 실제 메모리 효율이 떨어지는 상태로, Redis 재시작이나 MEMORY PURGE, activedefrag 활성화로 해결합니다. 1.0 미만이면 스왑을 사용 중이라는 의미로 심각한 성능 저하가 발생하므로, maxmemory 설정 조정이나 메모리 증설, 데이터 삭제가 필요합니다.
- • used_memory는 논리 메모리, used_memory_rss는 물리 메모리, fragmentation_ratio는 그 비율
- • 1.5 이상은 메모리 단편화 문제로 activedefrag나 재시작으로 해결
- • 1.0 미만은 스왑 사용으로 심각한 성능 저하, 메모리 증설이나 데이터 정리 필요
activedefrag 기능을 프로덕션에서 활성화할 때 주의해야 할 점은 무엇인가요?
Q. API Rate Limiting을 Redis로 구현할 때 Fixed Window, Sliding Window Log, Sliding Window Counter 방식의 차이를 설명하고, 각 방식을 Redis로 구현할 때 사용할 자료구조와 명령어, 그리고 메모리 효율성과 정확도 측면에서의 트레이드오프를 분석해주세요.
Fixed Window는 String과 INCR, EXPIRE로 구현하며 메모리 효율적이지만 경계에서 burst 트래픽 허용 문제가 있습니다. Sliding Window Log는 Sorted Set과 ZADD, ZREMRANGEBYSCORE로 구현하여 정확하지만 요청마다 타임스탬프를 저장해 메모리 사용량이 큽니다. Sliding Window Counter는 여러 시간 구간의 String 카운터를 조합하여 근사치를 계산하는 방식으로, 메모리 효율과 정확도의 균형을 맞춥니다. 대규모 시스템에서는 메모리 효율을 위해 Sliding Window Counter나 Token Bucket 알고리즘을 선호합니다.
- • Fixed Window는 간단하지만 경계 burst 문제, Sliding Log는 정확하지만 메모리 과다
- • Sliding Window Counter는 메모리와 정확도의 절충안
- • 구현에 String(INCR), Sorted Set(ZADD), Lua Script 등 다양한 자료구조 활용
사용자별로 다른 Rate Limit을 적용해야 한다면 설계를 어떻게 확장하시겠습니까?
Q. Redis Cluster 환경에서 특정 노드의 CPU 사용률이 다른 노드보다 지속적으로 높게 나타나는 현상이 발생했습니다. 핫키(Hot Key) 문제를 진단하는 방법과 --hotkeys 옵션, MONITOR 명령어의 활용법을 설명하고, 핫키 문제를 해결하기 위한 아키텍처 레벨의 해결 방안을 제시해주세요.
핫키 진단은 redis-cli --hotkeys 옵션으로 LFU 정보 기반 분석하거나, MONITOR로 실시간 명령어 모니터링, 또는 애플리케이션 로그 분석으로 수행합니다. --hotkeys는 maxmemory-policy가 LFU 계열이어야 하며, MONITOR는 성능 영향이 크므로 단기간만 사용해야 합니다. 해결 방안으로는 핫키를 여러 복제본으로 복제하는 Read Replica 패턴, 키 이름에 랜덤 접미사를 붙여 분산하는 Sharding, 애플리케이션 레벨 로컬 캐싱, 또는 Redis 6.0+의 Client-Side Caching 활용이 있습니다.
- • --hotkeys는 LFU 기반 분석, MONITOR는 실시간 모니터링이지만 성능 영향 큼
- • 핫키는 특정 노드에 부하 집중으로 CPU와 네트워크 사용률 증가
- • 해결책으로 Read Replica, 키 샤딩, 로컬 캐싱, Client-Side Caching 활용
핫키가 쓰기 작업에서 발생하는 경우와 읽기 작업에서 발생하는 경우 해결 방법이 어떻게 달라지나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!