분산 캐시와 Redis 자료구조 선택

정렬된 집합(Sorted Set)을 씁니다. 점수로 정렬된 상태를 유지하면서 순위 조회가 로그 시간입니다.

다른 자료구조로는 이 조합이 안 됩니다. 리스트는 정렬을 유지하지 못하고, 해시는 순위를 모릅니다. DB 로 하면 매번 정렬이나 인덱스 스캔이 필요합니다.

주의할 점입니다.

흔한 실수: 랭킹 전체를 매번 가져오는 것. 상위 100명만 필요하면 그만큼만 요청해야 합니다.

전체를 한 번에 읽고 쓰면 String, 필드별로 접근하면 Hash 입니다.

기준은 접근 패턴입니다. 프로필 전체를 화면에 뿌린다면 String 이 단순하고, 조회수만 자주 올린다면 Hash 로 그 필드만 증가시키는 것이 훨씬 싸습니다.

흔한 실수: 필드별 만료가 필요한데 Hash 를 고르는 것. Hash 는 필드 단위 만료가 없어서, 필요하면 필드를 별도 키로 나눠야 합니다.

Redis 는 단일 스레드로 명령을 처리하는데, KEYS 는 전체 키를 훑는 O(n) 명령이라 그 시간 동안 다른 요청이 전부 멈춥니다.

키가 100만 개면 수백 밀리초에서 수 초
그 사이 모든 클라이언트가 대기한다

대안입니다.

같은 이유로 위험한 명령이 더 있습니다. FLUSHALL, 큰 컬렉션에 대한 SMEMBERS 나 LRANGE 전체 조회, 큰 키의 DEL 도 오래 걸립니다.

흔한 실수: 개발 환경에서 문제없어 운영에서도 쓰는 것. 키가 적으면 빠르므로 규모가 커진 뒤에야 드러납니다. 운영에서는 위험 명령을 아예 비활성화하는 설정을 걸어두는 편이 안전합니다.

단일 스레드라 한 요청이 오래 걸리면 전부 밀립니다. 그 원인부터 찾습니다.

스냅샷이 자주 간과됩니다. 저장 시점에 프로세스를 복제하는데, 그 뒤 쓰기가 많으면 복사가 대량으로 일어나 메모리와 지연이 함께 나빠집니다.

흔한 실수: 서버 CPU 사용률만 보는 것. 단일 스레드라 코어 하나가 100%면 그것이 상한입니다. 전체 CPU 가 12%로 보여도 이미 포화일 수 있습니다.