Redis 미드레벨 기술면접
새 면접Q. Redis의 String 자료구조는 내부적으로 SDS(Simple Dynamic String)를 사용합니다. SDS가 C의 전통적인 문자열 대비 가지는 장점을 설명하고, embstr과 raw 인코딩이 분기되는 기준과 그 이유를 메모리 효율성 관점에서 설명해주세요.
SDS는 C 문자열과 달리 문자열 길이를 O(1)에 조회할 수 있고, 이진 안전성(binary-safe)을 보장하며, 버퍼 오버플로우를 방지합니다. embstr 인코딩은 44바이트 이하의 문자열에 사용되며 redisObject와 SDS를 연속된 메모리에 할당하여 메모리 단편화를 줄이고 캐시 지역성을 높입니다. 45바이트 이상은 raw 인코딩을 사용하여 redisObject와 SDS를 별도로 할당하는데, 이는 jemalloc의 64바이트 메모리 청크 크기를 고려한 최적화입니다. embstr은 읽기 전용으로 수정 시 raw로 변환되며, 이는 메모리 재할당 오버헤드를 줄이기 위함입니다.
- • SDS는 길이 정보 저장으로 O(1) 조회, 이진 안전성, 버퍼 오버플로우 방지 제공
- • 44바이트 이하는 embstr로 연속 메모리 할당, 45바이트 이상은 raw로 분리 할당
- • embstr은 jemalloc 64바이트 청크 최적화이며 읽기 전용, 수정 시 raw로 변환
Redis 7.0에서 도입된 listpack 자료구조가 ziplist를 대체한 이유와 개선점은 무엇인가요?
Q. Redis Sentinel의 SDOWN(Subjectively Down)과 ODOWN(Objectively Down) 상태의 차이를 설명하고, quorum 설정값이 failover 프로세스에 미치는 영향을 단계별로 설명해주세요. 또한 split-brain 문제가 발생할 수 있는 시나리오와 min-replicas-to-write 설정을 통한 예방 방법을 제시해주세요.
SDOWN은 개별 Sentinel이 Master를 다운으로 판단한 주관적 상태이고, ODOWN은 quorum 수 이상의 Sentinel이 합의한 객관적 다운 상태입니다. quorum은 ODOWN 판단과 failover 시작 권한 획득에 사용되며, 과반수 미만으로 설정 시 네트워크 파티션에서 양쪽 모두 failover를 시도할 수 있습니다. split-brain은 네트워크 파티션으로 구 Master가 격리되었지만 계속 쓰기를 받는 상황인데, min-replicas-to-write와 min-replicas-max-lag 설정으로 최소 N개의 Replica가 정상 복제 중일 때만 쓰기를 허용하여 예방할 수 있습니다. failover 완료 후 구 Master가 복귀하면 Replica로 전환되며 그동안의 쓰기는 손실됩니다.
- • SDOWN은 개별 판단, ODOWN은 quorum 이상의 Sentinel 합의로 failover 시작
- • quorum은 과반수 이상 권장, 미만 시 split-brain 발생 가능
- • min-replicas-to-write 설정으로 격리된 Master의 쓰기 차단하여 데이터 손실 최소화
Redis Cluster 환경에서는 Sentinel 없이 자체적으로 failover를 수행합니다. Cluster의 gossip 프로토콜 기반 장애 감지 메커니즘과 Sentinel 방식의 차이점은 무엇인가요?
Q. Redis의 SLOWLOG 기능을 활용하여 성능 병목을 진단하는 방법을 설명하고, slowlog-log-slower-than 설정의 적정값을 결정하는 기준을 제시해주세요. 또한 INFO commandstats를 통해 어떤 명령어가 시스템에 부하를 주는지 분석하는 방법을 설명해주세요.
SLOWLOG는 설정된 임계값보다 오래 걸린 명령어를 기록하며, SLOWLOG GET으로 조회할 수 있습니다. slowlog-log-slower-than은 마이크로초 단위로 설정하며, 일반적으로 10000(10ms)에서 시작해 평균 응답 시간의 2-3배로 조정합니다. P99 레이턴시를 기준으로 설정하면 이상치를 효과적으로 포착할 수 있습니다. INFO commandstats는 각 명령어별 호출 횟수와 총 소요 시간(usec)을 보여주며, usec_per_call 값이 높거나 calls 수가 과도한 명령어를 식별합니다. O(N) 복잡도 명령어(KEYS, SMEMBERS 등)의 빈번한 사용이나 대량 데이터 처리 명령어를 찾아 최적화합니다.
- • SLOWLOG로 느린 명령어 추적, 임계값은 10ms 시작해 P99 레이턴시 기준 조정
- • INFO commandstats로 명령어별 호출 횟수와 평균 실행 시간 분석
- • O(N) 명령어나 usec_per_call 높은 명령어 최적화 대상으로 식별
Redis의 latency monitoring framework(LATENCY 명령어)를 사용하여 포크 지연, AOF 쓰기 지연 등 다양한 이벤트의 레이턴시를 추적하는 방법을 설명해주세요.
Q. 대규모 세션 스토어를 Redis로 구축할 때, 단일 인스턴스 vs Redis Cluster vs Consistent Hashing with Multiple Instances 중 어떤 아키텍처를 선택하시겠습니까? 각 방식의 장단점을 확장성, 가용성, 운영 복잡도 관점에서 비교하고, 세션 데이터의 특성(크기, TTL, 읽기/쓰기 비율)에 따른 선택 기준을 제시해주세요.
단일 인스턴스는 구현이 단순하지만 수직 확장 한계와 단일 장애점(SPOF) 문제가 있습니다. Redis Cluster는 자동 샤딩과 고가용성을 제공하지만 운영 복잡도가 높고 MGET 등 다중 키 연산에 제약이 있습니다. Consistent Hashing 방식은 클라이언트 사이드 샤딩으로 유연하지만 리밸런싱과 장애 처리를 직접 구현해야 합니다. 세션 크기가 작고(수 KB) TTL이 짧으며(30분~2시간) 읽기 위주라면 Cluster가 적합하고, 대용량 세션(수십 KB)에 쓰기가 많다면 Consistent Hashing으로 핫키 분산을 제어하는 것이 유리합니다. 초기에는 Master-Replica with Sentinel로 시작해 트래픽 증가 시 Cluster로 전환하는 단계적 접근도 고려할 수 있습니다.
- • 단일 인스턴스는 단순하나 SPOF, Cluster는 자동 샤딩/HA 제공하나 운영 복잡
- • 세션 특성에 따라 선택: 소량/읽기 위주는 Cluster, 대량/쓰기 많으면 Consistent Hashing
- • 단계적 접근: Sentinel 시작 → 트래픽 증가 시 Cluster 전환
Redis Cluster에서 hash tag를 사용하여 관련 세션 데이터를 같은 슬롯에 배치하는 전략의 장단점과, 이로 인한 데이터 쏠림 문제를 해결하는 방법은 무엇인가요?
Q. 프로덕션 환경에서 Redis의 응답 시간이 간헐적으로 급증하는 현상이 발생했습니다. transparent huge pages(THP), swap 사용, 백그라운드 저장(BGSAVE/BGREWRITEAOF) 중 어떤 요인이 원인일 수 있는지 각각의 영향을 설명하고, 각 문제를 진단하고 해결하는 구체적인 방법을 제시해주세요.
THP는 메모리 단편화 시 대용량 페이지 압축으로 CPU 사용률이 급증하고 레이턴시 스파이크를 유발하므로, echo never > /sys/kernel/mm/transparent_hugepage/enabled로 비활성화합니다. Swap은 메모리 부족 시 디스크 I/O를 유발해 성능이 급격히 저하되므로, INFO stats의 total_swap을 모니터링하고 maxmemory 설정과 적절한 eviction policy로 예방합니다. BGSAVE/BGREWRITEAOF는 fork() 시 메모리 복사와 COW로 인한 지연을 유발하므로, INFO persistence의 rdb_last_bgsave_time_sec와 aof_last_rewrite_time_sec를 확인하고, 저장 주기를 트래픽이 적은 시간대로 조정하거나 Replica에서 수행합니다. latency doctor 명령어로 종합 진단이 가능합니다.
- • THP는 메모리 압축으로 CPU 스파이크 유발, 비활성화 필요
- • Swap 사용은 디스크 I/O로 성능 저하, maxmemory와 eviction policy로 예방
- • BGSAVE/BGREWRITEAOF는 fork COW 지연, 저장 주기 조정이나 Replica 활용
Redis 6.0부터 도입된 I/O threading이 응답 시간 개선에 어떻게 기여하는지, 그리고 threaded I/O를 활성화할 때 고려해야 할 CPU 코어 수와 io-threads 설정값의 관계를 설명해주세요.
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!