캐싱

캐싱은 시스템 응답 속도를 높이고 데이터베이스 부하를 줄이는 핵심 기법이다. Redis는 메모리 기반 키-값 저장소로서, 빈번한 조회가 발생하는 데이터를 보관하기 적합하다.

일반적인 패턴은 다음과 같다. 먼저 캐시를 조회하고, 존재하면 즉시 반환한다. 미스가 발생하면 DB에서 조회한 뒤 캐시에 기록한다. 데이터 변경 시에는 DB 업데이트 후 캐시를 무효화하며, 고부하 환경에서는 지연 기반 이중 삭제 전략을 고려해야 한다.

세션 클러스터링

분산 환경에서 세션 공유는 필수적이다. Redis 클러스터를 세션 저장소로 활용하면, 특정 서버 장애에도 사용자 로그인 상태가 유지된다.

인증 흐름은 이렇다. 사용자가 로그인하면 애플리케이션 서버가 세션 토큰을 발급하고, 이를 Redis에 저장한 뒤 클라이언트에 전달한다. 이후 요청마다 클라이언트는 해당 토큰을 전송하고, 서버는 Redis에서 세션 정보를 조회해 인증을 수행한다.

분산 락

다중 노드 환경에서 임계 자원 접근을 조율하려면 분산 락이 필요하다. Redis는 데이터베이스나 ZooKeeper 대비 뛰어난 성능을 제공한다.

핵심 명령어는 SETNX다. 키가 존재하지 않을 때만 값을 설정하는 원자 연산으로, 락 획득 여부를 판단한다.

SETNX lock:resource:123 "node-A-uuid"

실무에서는 락 만료, 재진입, 분산 환경에서의 안정성을 위해 Redisson 같은 라이브러리 사용을 권장한다.

경량 메시지 브로커

Redis의 Pub/Sub은 간단한 메시지 전달이 필요한 경우 유용하다. 발행자가 채널에 메시지를 푸시하면, 구독 중인 모든 수신자가 실시간으로 수신한다.

SUBSCRIBE alerts:system
PUBLISH alerts:system "disk usage > 90%"

단, 메시지 영속화가 되지 않아 장애 시 유실 가능성이 있고, 소비 지연이 발생하면 출력 버퍼가 무한 증가할 수 있어 주의가 필요하다. 따라서 복잡한 메시지 처리나 높은 신뢰성이 요구되는 곳에는 전용 메시지 큐(Kafka, RabbitMQ 등)를 고려해야 한다.

비트맵 기반 상태 관리

대규모 사용자의 이진 상태(예: 출석, 기능 활성화 여부)를 저장할 때, 비트맵은 극도의 공간 효율성을 제공한다. 1억 명의 로그인 여부를 저장해도 약 12MB면 충분하다.

SETBIT login:2024-01-15 9876543 1
GETBIT login:2024-01-15 9876543
BITCOUNT login:2024-01-15

각 비트가 개별 사용자를 의미하며, BITCOUNT로 하루 로그인 인원을 순식간에 집계할 수 있다.

원자적 카운터

방문자 수, 재고 수량, 순차 ID 생성 등에 INCRBY를 활용한다. 단일 스레드 처리와 원자성이 동시성 이슈 없이 정확한 수치를 보장한다.

INCRBY counter:page:home 1
INCRBY seq:order 10000

키가 없으면 자동으로 0으로 초기화 후 증가하므로, 별도의 존재 여부 확인이 불필요하다.

실시간 리더보드

Sorted Set은 점수 기반 순위 산출에 최적화된 자료구조다. 게임 랭킹, 인기 검색어 등 실시간 변동이 잦은 순위 데이터를 효율적으로 관리할 수 있다.

ZADD leaderboard:season5 2850 "player_42"
ZADD leaderboard:season5 3120 "player_17"
ZADD leaderboard:season5 1980 "player_89"

ZREVRANGE leaderboard:season5 0 2 WITHSCORES

ZREVRANGE는 높은 점수부터 상위 N명을 조회하며, ZRANK나 ZSCORE로 개인 순위나 점수를 개별 조회할 수도 있다.