Redis 주니어 기술면접
새 면접Q. 전자상거래 사이트에서 사용자가 최근 본 상품 목록을 Redis로 관리하려고 합니다. 최근 본 상품 20개만 유지하면서 중복된 상품은 가장 최근 위치로 이동시켜야 할 때, 어떤 데이터 타입과 명령어 조합을 사용하는 것이 효율적인지 설명해주세요.
이 경우 List보다는 Sorted Set을 사용하는 것이 효율적입니다. 상품 ID를 member로, 조회 시각의 타임스탬프를 score로 저장하면 ZADD 명령어로 중복 시 자동으로 score가 업데이트됩니다. ZREVRANGE 명령어로 최근 순으로 조회하고, ZREMRANGEBYRANK 명령어로 20개를 초과하는 오래된 항목을 제거할 수 있습니다. 또는 List를 사용한다면 LREM으로 기존 항목을 제거한 후 LPUSH로 추가하고 LTRIM으로 20개로 제한하는 방식도 가능하지만, 중복 제거 과정에서 Sorted Set보다 비효율적입니다.
- • Sorted Set을 사용하여 타임스탬프를 score로 관리
- • ZADD로 중복 시 자동 업데이트, ZREVRANGE로 최근 순 조회
- • ZREMRANGEBYRANK로 상위 N개만 유지
- • List 사용 시 LREM + LPUSH + LTRIM 조합 필요하지만 비효율적
만약 사용자별 최근 본 상품을 관리한다면 키 설계는 어떻게 하시겠습니까? 그리고 수백만 사용자의 데이터를 관리할 때 메모리 최적화를 위해 어떤 전략을 사용할 수 있을까요?
Q. Redis에서 대량의 키를 조회해야 할 때 KEYS 명령어 대신 SCAN 명령어를 사용해야 하는 이유를 설명하고, SCAN의 동작 방식과 주요 특징을 말씀해주세요.
KEYS 명령어는 패턴과 일치하는 모든 키를 한 번에 반환하기 때문에 O(N) 시간 복잡도로 동작하며, Redis가 싱글 스레드이므로 실행 중 다른 모든 명령이 블로킹됩니다. 반면 SCAN은 커서 기반으로 일정 개수씩 나눠서 반환하므로 각 호출마다 짧은 시간만 소요되어 다른 명령어 처리를 방해하지 않습니다. SCAN은 COUNT 옵션으로 한 번에 반환할 개수의 힌트를 줄 수 있고, 순회 중 추가되거나 삭제된 키는 보장되지 않지만 순회 시작 시 존재했던 키는 중복 없이 최소 한 번 반환됩니다. 프로덕션 환경에서는 반드시 SCAN을 사용해야 서비스 장애를 방지할 수 있습니다.
- • KEYS는 O(N) 블로킹 명령어로 프로덕션에서 위험
- • SCAN은 커서 기반으로 나눠서 반환하여 블로킹 최소화
- • COUNT 옵션으로 반환 개수 힌트 제공 가능
- • 순회 중 변경사항은 보장 안 되지만 기존 키는 최소 한 번 반환
SCAN을 사용할 때 COUNT 값을 어떻게 설정하는 것이 좋을까요? 그리고 SCAN 외에 SSCAN, HSCAN, ZSCAN의 용도는 무엇인가요?
Q. Redis Replication(복제)의 동작 원리를 설명하고, Master-Slave 구조에서 Slave가 읽기 전용으로 사용되는 이유와 주의해야 할 점을 말씀해주세요.
Redis Replication은 Master 노드의 데이터를 하나 이상의 Slave(Replica) 노드로 비동기 복제하는 방식입니다. Slave가 Master에 연결되면 SYNC 또는 PSYNC 명령으로 전체 데이터셋을 받고, 이후 Master의 모든 쓰기 명령을 실시간으로 받아 복제합니다. Slave는 기본적으로 읽기 전용으로 설정되는데, 이는 데이터 일관성을 유지하기 위함입니다. Slave에 쓰기를 허용하면 Master와 데이터가 달라지고 복제 시 덮어써질 수 있습니다. 주의할 점은 복제가 비동기로 이루어지므로 Master와 Slave 간 약간의 데이터 지연(replication lag)이 발생할 수 있고, Slave에서 읽은 데이터가 최신이 아닐 수 있다는 점입니다.
- • Master의 데이터를 Slave로 비동기 복제
- • SYNC/PSYNC로 초기 동기화 후 실시간 명령 복제
- • Slave는 읽기 전용으로 사용하여 데이터 일관성 유지
- • 비동기 복제로 인한 replication lag 존재 가능
Master 노드가 장애로 다운되었을 때 Slave를 Master로 승격시키는 과정에서 발생할 수 있는 문제는 무엇이고, Redis Sentinel은 이를 어떻게 해결하나요?
Q. Redis의 INCR, INCRBY, DECR, DECRBY 명령어의 용도를 설명하고, 이 명령어들이 원자적(atomic) 연산인 이유와 왜 중요한지 말씀해주세요.
INCR은 키의 값을 1 증가, INCRBY는 지정한 값만큼 증가, DECR은 1 감소, DECRBY는 지정한 값만큼 감소시키는 명령어입니다. 이 명령어들은 카운터, 조회수, 재고 관리 등에 사용됩니다. Redis는 싱글 스레드로 동작하므로 이 명령어들은 원자적으로 실행되어 중간에 다른 명령이 끼어들 수 없습니다. 만약 GET-계산-SET으로 구현하면 여러 클라이언트가 동시에 실행할 때 race condition이 발생하여 정확한 값을 보장할 수 없지만, INCR/DECR 계열 명령어를 사용하면 동시성 문제 없이 안전하게 카운팅할 수 있습니다.
- • INCR/DECR은 값을 1씩, INCRBY/DECRBY는 지정 값만큼 증감
- • 카운터, 조회수, 재고 관리 등에 사용
- • 싱글 스레드 특성으로 원자적 연산 보장
- • GET-계산-SET 방식은 race condition 발생, INCR 사용이 안전
INCR 명령어를 사용하여 일일 방문자 수를 카운팅할 때, 날짜가 바뀌면 자동으로 0으로 리셋되도록 하려면 어떻게 구현해야 할까요?
Q. Redis 운영 중 성능 저하가 발생했을 때 문제를 진단하기 위해 확인해야 할 주요 메트릭과 Redis 명령어를 설명해주세요. 특히 INFO 명령어로 확인할 수 있는 중요한 정보들을 말씀해주세요.
Redis 성능 문제 진단 시 INFO 명령어로 다양한 메트릭을 확인할 수 있습니다. INFO memory로 used_memory, maxmemory, mem_fragmentation_ratio를 확인하여 메모리 사용률과 단편화를 파악하고, INFO stats로 total_commands_processed, instantaneous_ops_per_sec를 보고 처리량을 확인합니다. INFO replication으로 복제 지연을 체크하고, INFO cpu로 CPU 사용률을 확인합니다. 또한 SLOWLOG GET 명령어로 느린 쿼리를 분석하고, CLIENT LIST로 연결된 클라이언트 수와 상태를 확인할 수 있습니다. 메모리 단편화 비율이 1.5 이상이면 재시작을 고려하고, evicted_keys가 증가하면 메모리 부족 상태입니다.
- • INFO memory로 메모리 사용률과 단편화 비율 확인
- • INFO stats로 처리량과 evicted_keys 확인
- • SLOWLOG GET으로 느린 쿼리 분석
- • CLIENT LIST로 연결 상태, INFO replication으로 복제 지연 확인
mem_fragmentation_ratio 값이 의미하는 것이 무엇이고, 이 값이 너무 높거나 낮을 때 각각 어떤 문제가 있으며 어떻게 해결할 수 있나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!