🎯 Redis 기초개념

한 줄 정의

“엄청 빠른 메모리 메모장” DB는 디스크에 저장 → 느림. Redis는 RAM에 저장 → 빠름.

DB 조회:    요청 → 디스크 → 응답   (~10ms)
Redis 조회: 요청 → 메모리 → 응답   (~0.1ms)

📑 목차


1. 캐싱

문제상황: 유저 1000명이 동시에 상품 정보 요청 → DB에 1000번 쿼리 → DB 죽음

해결: 첫 번째만 DB에서 가져오고 Redis에 저장. 나머지 999명은 Redis에서 응답.

# 저장 (EX 60 = 60초 후 자동 삭제)
SET timedeal:1 '{"name":"강아지사료","price":25000}' EX 60
 
# 조회
GET timedeal:1
# → {"name":"강아지사료","price":25000}

EX (Expire)

타임딜이 끝나면 캐시도 같이 만료되도록 TTL 설정. 딜 종료 시간에 맞춰 EX 값을 설정하면 됨.


2. 재고 카운터

문제상황: 유저 100명이 동시에 구매 클릭 → DB 동시 업데이트 → 재고 100개인데 200개 팔릴 수 있음

해결: Redis DECR은 원자적(Atomic) 처리. 한 번에 하나씩 순서 보장.

SET stock:1 100
 
DECR stock:1   # → 99
DECR stock:1   # → 98
GET stock:1    # → 98

원자적(Atomic)이란?

“중간에 끼어들 수 없음” DECR 하는 도중에 다른 요청이 끼어들지 못함. 순서 보장.


3. 분산락

문제상황: 서버 여러 대가 동시에 같은 재고를 줄이려고 함

해결: 먼저 락을 잡은 서버만 작업. 나머지는 대기.

# 서버A가 락 획득
SET lock:stock:1 "서버A" NX EX 10
# → OK (성공)
 
# 서버B가 락 시도
SET lock:stock:1 "서버B" NX EX 10
# → (nil) (실패! 서버A가 갖고 있음)
 
# 작업 완료 후 락 해제
DEL lock:stock:1

NX / EX 옵션

  • NX = Not eXists. 키가 없을 때만 저장 (이미 있으면 실패)
  • EX 10 = 10초 후 자동 해제. 서버가 죽어도 락이 영원히 안 남음

4. 멱등성 키

문제상황: 유저가 결제 버튼을 두 번 클릭 → 주문이 두 번 생성됨

해결: 요청마다 고유 ID 발급 → Redis에 기록 → 같은 ID 두 번 오면 무시

# 첫 번째 요청
SETNX idempotency:uuid-001 "처리완료"
# → 1 (성공, 처음 요청)
 
# 두 번째 요청 (같은 UUID)
SETNX idempotency:uuid-001 "처리완료"
# → 0 (실패, 이미 있음 → 중복 무시)
 
GET idempotency:uuid-001
# → "처리완료" (원래 값 그대로)

멱등성(Idempotency)이란?

같은 요청을 여러 번 해도 결과가 동일함. 결제 두 번 눌러도 한 번만 결제되는 것.


5. EKS에서 어디에 사는가

EKS 클러스터 (내 서비스들)
└── 주문서비스 Pod
└── 재고서비스 Pod

AWS 관리형 (EKS 밖)
└── ElastiCache (Redis) ← 여기!
    └── redis.xxx.cache.amazonaws.com:6379

왜 밖에 두냐?

  • Pod는 언제든 죽었다 살아남 → 데이터 날아감
  • ElastiCache는 AWS가 백업/복구/패치 다 관리
  • 비용: t3.micro 기준 월 ~$12 (MSK보다 훨씬 쌈)

연결 방법: 그냥 엔드포인트 주소를 환경변수로 넣으면 끝

env:
  - name: REDIS_HOST
    value: "redis.xxx.cache.amazonaws.com"
  - name: REDIS_PORT
    value: "6379"

📊 패턴 요약

패턴명령사용 시나리오
캐싱SET key value EX ttl상품 정보, 세션
재고 카운터DECR key동시 재고 차감
분산락SET key val NX EX ttl중복 작업 방지
멱등성SETNX key value중복 요청 방지