Redis 주니어 성능 최적화 면접

먼저 INFO MEMORY 명령어로 전체 메모리 사용량과 메모리 할당 상태를 확인합니다. MEMORY STATS 명령으로 데이터 타입별 메모리 사용량을 분석하고, redis-cli --bigkeys 옵션으로 메모리를 많이 차지하는 큰 키들을 찾아냅니다. 개선 방안으로는 TTL이 설정되지 않은 키에 적절한 만료 시간을 설정하고, 큰 Hash나 List를 여러 개의 작은 키로 분할하며, ziplist 인코딩 임계값을 조정하여 메모리 효율적인 인코딩을 유지합니다. 또한 maxmemory-policy를 적절히 설정하여 메모리 한계 도달 시 자동으로 오래된 데이터를 삭제하도록 합니다.

개별 GET 명령어를 1000번 실행하면 각 요청마다 네트워크 왕복 시간(RTT)이 발생하여 최소 5000ms(5초)가 소요됩니다. 개선 방법으로는 첫째, MGET 명령어를 사용하여 한 번의 요청으로 여러 키를 조회하면 RTT를 1회로 줄일 수 있습니다. 둘째, Pipeline 기능을 사용하면 여러 명령어를 한 번에 전송하고 응답을 일괄 수신하여 네트워크 왕복 횟수를 대폭 줄입니다. 셋째, Connection Pool을 적절히 설정하여 연결 생성 오버헤드를 제거합니다. 특히 Pipeline을 사용하면 1000개 명령어를 100개씩 묶어 10번의 RTT로 줄일 수 있어 약 50ms로 단축됩니다.

KEYS 명령어는 O(N) 시간 복잡도를 가지며 모든 키를 한 번에 스캔하므로 싱글 스레드인 Redis가 작업을 완료할 때까지 다른 모든 클라이언트 요청이 블로킹됩니다. 수백만 개의 키가 있는 경우 수 초간 서버가 멈출 수 있습니다. 안전한 구현 방법은 SCAN 명령어를 사용하는 것으로, SCAN은 커서 기반으로 소량씩 반복 조회하여 다른 요청을 처리할 시간을 확보합니다. 구체적으로 SCAN 0 MATCH prefix:* COUNT 100 형태로 100개씩 조회하고, 반환된 커서가 0이 될 때까지 반복하며 매칭된 키를 DEL 또는 UNLINK로 삭제합니다. UNLINK는 비동기 삭제로 더 안전합니다.

List는 시간순 추가(LPUSH)는 O(1)로 빠르지만 중간 항목의 읽음 상태 업데이트가 어렵고 LINDEX로 접근 시 O(N)입니다. Sorted Set은 타임스탬프를 score로 사용하면 정렬이 자동 유지되고 ZRANGE로 범위 조회가 O(log N + M)으로 효율적이지만, 읽음 상태 같은 추가 속성을 저장할 수 없어 별도 Hash가 필요합니다. Hash는 알림 ID를 field로 사용하면 개별 알림 업데이트가 O(1)로 매우 빠르지만 정렬 기능이 없어 애플리케이션에서 정렬해야 합니다. 알림 개수가 10개 미만으로 적고 개별 업데이트가 빈번하다면 Hash에 JSON 형태로 저장하고 애플리케이션에서 정렬하는 것이 가장 실용적이며, 또는 Sorted Set으로 순서를 관리하고 Hash로 상세 정보를 저장하는 조합도 고려할 수 있습니다.

Cache Stampede는 인기 있는 캐시 키가 만료되는 순간 동시 다발적인 요청들이 모두 캐시 미스를 경험하고 데이터베이스를 동시에 조회하여 과부하를 일으키는 현상입니다. 방지 방법으로는 첫째, 캐시 조회 시 값이 없으면 SETNX로 임시 락 키를 생성하고 락을 획득한 요청만 DB를 조회하며 나머지는 짧은 대기 후 재시도합니다. 둘째, Probabilistic Early Expiration 방식으로 TTL이 얼마 남지 않았을 때 확률적으로 미리 갱신합니다. 셋째, 캐시에 빈 값이나 stale 데이터를 저장하고 백그라운드에서 비동기로 갱신하는 방식을 사용합니다. 넷째, TTL에 랜덤 시간을 추가하여 만료 시점을 분산시킵니다. 실무에서는 SETNX 락과 TTL 랜덤화를 조합하여 사용하는 것이 효과적입니다.