캐싱, 세션, 큐, 퍼브/섭, 레이트리밋 등 애플리케이션에서 Redis를 실용적으로 사용하는 방법 — 확장, 지속성, 모니터링과 주의할 점까지.
Redis는 애플리케이션에서 공유되는 "빠른 레이어"로 자주 사용되는 인메모리 데이터 저장소입니다. 팀들이 선호하는 이유는 도입이 간단하고, 일반 작업에서 매우 빠르며, 캐시, 세션, 카운터, 큐, 퍼브/섭 등 여러 작업을 별도의 시스템 없이 유연하게 처리할 수 있기 때문입니다.
실무에서는 Redis를 속도 + 조정 용도로 다루고, 기본 데이터베이스는 **진실의 원천(source of truth)**으로 유지하는 것이 가장 좋습니다.
보통 다음과 같은 구성입니다:
이 분리는 데이터베이스를 정합성과 내구성에 집중하게 하고, Redis는 지연(latency)이나 부하를 높이는 고빈도 읽기/쓰기 작업을 흡수합니다.
잘 사용하면 Redis는 다음과 같은 결과를 가져옵니다:
Redis는 기본 데이터베이스를 대체하지 않습니다. 복잡한 쿼리, 장기 저장 보장, 분석형 리포팅이 필요하면 데이터베이스가 맞습니다.
또한 Redis가 “기본적으로 내구성 있다”라고 가정하지 마세요. 몇 초치 데이터 손실도 용납할 수 없다면 비즈니스 요구에 맞춘 신중한 지속성 설정이나 다른 시스템이 필요합니다.
Redis는 흔히 "키-값 저장소"로 묘사되지만, 이름으로 작은 데이터를 보관하고 조작할 수 있는 매우 빠른 서버로 생각하는 편이 더 유용합니다. 이 모델은 예측 가능한 접근 패턴을 장려합니다: 대개 정확히 무엇을 원하는지(세션, 캐시된 페이지, 카운터)를 알고 있으며 Redis는 단일 왕복으로 이를 가져오거나 업데이트할 수 있습니다.
Redis는 데이터를 RAM에 보관하기 때문에 마이크로초에서 밀리초 단위 응답이 가능합니다. 대신 RAM은 디스크보다 제한적이고 비용이 높습니다.
초기에 결정하세요. Redis가:
Redis는 디스크로 데이터를 지속화(RDB 스냅샷 및/또는 AOF 추가 전용 로그)할 수 있지만, 지속성은 쓰기 오버헤드를 추가하고 내구성 선택을 요구합니다(예: “빠르지만 1초를 잃을 수 있음” 대 “느리지만 안전함”). 지속성은 비즈니스 영향에 따라 설정하는 다이얼로 생각하세요.
Redis는 명령을 주로 단일 스레드로 실행합니다. 제한적으로 들릴 수 있지만 두 가지를 기억하면 이해가 쉬워집니다: 작업은 보통 작고, 여러 작업 스레드 간의 락 오버헤드가 없습니다. 비용이 큰 명령과 과도한 페이로드만 피하면 이 모델은 높은 동시성에서도 매우 효율적일 수 있습니다.
애플리케이션은 TCP로 클라이언트 라이브러리를 통해 Redis와 통신합니다. 연결 풀을 사용하고 요청을 작게 유지하며, 여러 작업이 필요할 때는 배칭/파이프라이닝을 선호하세요.
타임아웃과 재시도를 계획하세요: Redis는 빠르지만 네트워크는 그렇지 않을 수 있으며, 애플리케이션은 Redis가 바쁘거나 일시적으로 사용할 수 없을 때 점차적으로 열화되도록 설계해야 합니다.
새 서비스를 만들고 이러한 기본을 빠르게 표준화하려면 Koder.ai와 같은 플랫폼이 React + Go + PostgreSQL 애플리케이션을 스캐폴딩하고 채팅 기반 워크플로를 통해 Redis 기반 기능(캐싱, 세션, 레이트 리밋)을 추가하도록 도와줄 수 있습니다—동시에 소스 코드를 내보내어 원하는 곳에 실행할 수 있습니다.
캐시는 누가 채우고 누가 무효화하며 ‘충분히 최신’의 기준이 무엇인지에 대한 명확한 소유권이 있을 때만 도움이 됩니다.
캐시-어사이드는 애플리케이션—Redis가 아니라—읽기/쓰기 제어를 책임지는 방식입니다.
일반적인 흐름:
Redis는 빠른 키-값 저장소입니다; 직렬화, 버전 관리, 만료 정책은 애플리케이션이 결정합니다.
TTL은 기술적 결정이면서 제품 결정입니다. 짧은 TTL은 오래됨을 줄이지만 데이터베이스 부하를 늘리고, 긴 TTL은 작업을 절약하지만 오래된 결과를 제공할 위험이 있습니다.
실용적인 팁:
user:v3:123)—구형 캐시 형식이 새 코드에 문제를 일으키지 않도록핫 키가 만료될 때 많은 요청이 동시에 미스할 수 있습니다.
일반적인 방어책:
좋은 후보: API 응답, 비싼 쿼리 결과, 계산된 객체(추천, 집계). 전체 HTML 페이지 캐싱도 가능하지만 개인화와 권한 관련 로직이 있을 경우 단편 캐시를 신중히 사용하세요.
Redis는 단기 로그인 상태(세션 ID, 리프레시 토큰 메타데이터, 디바이스 기억 플래그 등)를 보관하기에 실용적입니다. 목표는 인증을 빠르게 제공하면서 세션 수명과 폐기가 엄격히 제어되도록 하는 것입니다.
일반적 패턴: 애플리케이션이 랜덤 세션 ID를 발급하고 Redis에 컴팩트한 레코드를 저장한 뒤 브라우저에는 HTTP-Only 쿠키로 세션 ID를 반환합니다. 각 요청에서 세션 키를 조회해 사용자 신원과 권한을 요청 컨텍스트에 붙입니다.
세션 읽기가 빈번하고 만료가 내장되어 있어 Redis가 여기서 잘 작동합니다.
키를 스캔하거나 폐기하기 쉽도록 설계하세요:
sess:{sessionId} → 세션 페이로드(userId, issuedAt, deviceId)user:sessions:{userId} → 활성 세션 ID의 Set(선택사항, ‘모든 기기 로그아웃’용)sess:{sessionId}에 세션 수명과 맞는 TTL을 사용하세요. 세션을 회전시키는 것이 권장되며, 새 세션 ID를 만들고 이전 것을 즉시 삭제하세요.
모든 요청에서 TTL을 연장하는 ‘슬라이딩 만료’는 무거운 사용자에게 세션을 무기한 연장시킬 수 있습니다. 만료가 임박했을 때만 TTL을 연장하는 절충안이 안전합니다.
단일 기기 로그아웃: sess:{sessionId} 삭제.
모든 기기 로그아웃:
user:sessions:{userId}에서 모든 세션 ID를 찾아 삭제하거나, 또는user:revoked_after:{userId} 타임스탬프를 유지하고 그 이전에 발행된 세션을 무효로 처리타임스탬프 방식은 대량의 팬아웃 삭제를 피해줍니다.
Redis에는 필요한 최소한의 정보만 저장하고 개인 데이터 대신 ID를 저장하세요. 원시 비밀번호나 장기 비밀값을 절대 저장하지 마세요. 토큰 관련 데이터를 저장해야 한다면 해시를 저장하고 TTL을 짧게 유지하세요.
Redis에 연결할 수 있는 주체를 제한하고 인증을 요구하며 세션 ID는 추측 불가능하도록 높은 엔트로피로 생성하세요.
레이트 리밋은 Redis가 탁월한 분야입니다: 빠르고 앱 인스턴스 간 공유되며 원자적 연산으로 트래픽이 많을 때도 카운터를 일관되게 유지합니다. 로그인 엔드포인트, 비용이 큰 검색, 비밀번호 재설정 흐름 등 스크랩·브루트포스 공격으로부터 보호하는 데 유용합니다.
고정 윈도우( Fixed window): “분당 100회”처럼 가장 간단합니다. 현재 분 버킷에서 요청을 셉니다. 다만 경계에서 버스트가 발생할 수 있습니다(예: 12:00:59에 100회, 12:01:00에 다시 100회).
슬라이딩 윈도우: 최근 N초/분을 보며 경계를 평탄화합니다. 더 공정하지만 보통 더 비용이 듭니다(정렬 집합이나 더 많은 책 keeping 필요).
토큰 버킷(Token bucket): 버스트 처리에 좋습니다. 사용자는 시간이 지남에 따라 토큰을 얻고 최대 한도까지 누적됩니다; 각 요청은 토큰을 소비합니다. 짧은 버스트를 허용하면서 평균 속도를 유지할 수 있습니다.
고정 윈도우의 일반적 패턴:
INCR key로 카운터 증가EXPIRE key window_seconds로 TTL 설정/리셋문제는 이것을 안전하게 하는 것입니다. INCR와 EXPIRE를 별도 호출로 실행하면 그 사이에 크래시가 발생해 만료되지 않는 키가 생성될 수 있습니다.
더 안전한 접근법:
INCR와 생성을 감지해 EXPIRE를 설정하는 동작을 Lua 스크립트로 묶기SET key 1 EX <ttl> NX를 사용하고 이후 INCR를 사용하는 방법(경합을 피하려면 여전히 스크립트로 래핑하는 것이 좋음)원자적 연산은 트래픽 급증 시 가장 중요합니다: 그렇지 않으면 두 요청이 동일한 남은 할당량을 보고 둘 다 통과할 수 있습니다.
대부분의 앱은 다중 레이어가 필요합니다:
rl:user:{userId}:{route}버스트가 많은 엔드포인트에는 토큰 버킷이나 관대하게 설정된 고정 윈도우와 짧은 ‘버스트’ 윈도우를 결합해 정당한 급증을 벌주지 않도록 하세요.
미리 “안전”의 의미를 결정하세요:
일반적인 절충안: 저위험 경로는 fail-open, 민감한 경로(로그인, 비밀번호 재설정, OTP 등)는 fail-closed로 두고 레이트 리밋이 작동하지 않을 때 즉시 감지할 수 있도록 모니터링하세요.
이메일 발송, 이미지 리사이즈, 데이터 동기화, 주기 작업 등 가벼운 큐가 필요할 때 Redis로 백그라운드 잡을 처리할 수 있습니다. 핵심은 올바른 데이터 구조를 선택하고 재시도 및 실패 처리 규칙을 명확히 하는 것입니다.
리스트: 가장 단순한 큐. 생산자는 LPUSH, 워커는 BRPOP. 단순하지만 인플라이트 잡, 재시도, 가시성 타임아웃을 위한 추가 로직이 필요합니다.
정렬 집합(ZSET): 스케줄링이 중요할 때 빛을 발합니다. 점수를 타임스탬프(또는 우선순위)로 사용하고 워커는 다음 만료된 잡을 가져옵니다. 지연 잡과 우선순위 큐에 적합합니다.
스트림(Streams): 내구성 있는 작업 분배의 기본 선택인 경우가 많습니다. 소비자 그룹을 지원하고 히스토리를 유지하며 여러 워커가 자체적으로 조정할 수 있습니다.
Streams 소비자 그룹에서는 워커가 메시지를 읽고 나중에 ACK합니다. 워커가 죽으면 메시지는 보류 상태로 남아 다른 워커가 가져갈 수 있습니다.
재시도는 시도 횟수를 메시지 페이로드나 사이드 키에 기록하고 지수 백오프(정렬 집합의 ‘재시도 스케줄’ 사용 등)를 적용하세요. 최대 시도 횟수에 도달하면 잡을 수동 검토용 데드레터 큐(다른 스트림이나 리스트)로 옮깁니다.
잡은 두 번 실행될 수 있다고 가정하세요. 핸들러를 멱등하게 만들려면:
job:{id}:done)를 SET ... NX로 설정해 부작용 전에 확인페이로드는 작게 유지(큰 데이터는 다른 저장소에 두고 참조 전달). 큐 길이를 제한해 역압을 주고, 지연이 커질 때 프로듀서를 느리게 하며, 보류 깊이 및 처리 시간 기반으로 워커를 스케일하세요.
Redis Pub/Sub은 이벤트를 브로드캐스트하는 가장 단순한 방법입니다: 퍼블리셔가 채널에 메시지를 보내면 연결된 구독자 모두가 즉시 받습니다. 폴링이 없고 실시간 업데이트에 잘 맞는 가벼운 푸시 방식입니다.
Pub/Sub은 전달 보장보다 속도와 팬아웃을 중시할 때 유용합니다:
비유하자면 Pub/Sub은 라디오 방송과 같습니다. 청취 중인 사람은 방송을 듣지만 자동으로 녹음이 남지는 않습니다.
Pub/Sub의 트레이드오프:
따라서 모든 이벤트를 반드시 처리해야 하는 워크플로에는 적합하지 않습니다.
내구성, 재시도, 소비자 그룹, 역압 처리 등이 필요하면 Redis Streams가 보통 더 나은 선택입니다. 스트림은 이벤트를 저장하고 ACK로 처리하며 재시작 후 복구할 수 있어 경량 메시지 큐와 더 가깝습니다.
실환경에서는 여러 앱 인스턴스가 구독합니다. 몇 가지 실용 팁:
app:{env}:{domain}:{event} (예: shop:prod:orders:created)notifications:global에 브로드캐스트, 사용자 대상은 notifications:user:{id}이렇게 사용하면 Pub/Sub은 빠른 이벤트 “신호”로, 스트림(또는 다른 큐)은 손실 불가 이벤트 처리를 담당합니다.
데이터 구조 선택은 단순히 “작동한다”가 아니라 메모리 사용, 쿼리 속도, 코드의 단순성에 영향을 줍니다. 좋은 규칙은 현재 저장 방식뿐 아니라 향후 묻고자 할 질문(읽기 패턴)에 맞는 구조를 선택하는 것입니다.
INCR/DECR로 원자적 카운터에 좋음.SISMEMBER 빠름.Redis 명령은 명령 단위로 원자적이므로 카운터를 경합 없이 안전하게 증가시킬 수 있습니다. 페이지뷰와 레이트 리밋 카운터는 TTL과 함께 문자열과 INCR를 쓰는 것이 일반적입니다.
리더보드는 정렬 집합이 유리합니다: 점수 갱신(ZINCRBY)과 상위 플레이어 추출(ZREVRANGE)을 효율적으로 처리할 수 있습니다.
user:123:name, user:123:email, user:123:plan으로 키를 많이 만들면 키당 오버헤드가 누적되어 메모리를 더 쓰게 되고 키 관리가 어려워집니다.
user:123 해시에 필드(name, email, plan)를 넣으면 관련 데이터를 함께 보관해 키 수를 줄이고 개별 필드 업데이트도 간단합니다.
의심스러우면 작은 샘플로 모델링하고 메모리 사용량을 측정하세요.
Redis는 종종 “인메모리”로 불리지만 재시작, 디스크 포화, 서버 소실 시 무엇이 일어나는지 선택할 수 있는 옵션이 있습니다. 적절한 설정은 얼마나 많은 데이터를 잃을 수 있는지와 얼마나 빨리 복구해야 하는지에 달려 있습니다.
RDB 스냅샷은 데이터셋의 시점 덤프를 저장합니다. 컴팩트하고 시작 시 로드가 빠르며 재시작을 빠르게 합니다. 대가로 마지막 스냅샷 이후의 최신 쓰기를 잃을 수 있습니다.
**AOF(append-only file)**는 쓰기 작업을 발생 시점에 로그로 기록합니다. 보통 잠재적 데이터 손실을 줄여주지만 AOF 파일이 커질 수 있고 시작 시 재생 시간이 길어질 수 있습니다(다만 Redis는 AOF를 리라이트/압축해 관리 가능).
많은 팀이 둘 다 운영합니다: 빠른 재시작용 스냅샷과 더 나은 쓰기 내구성을 위한 AOF.
지속성은 비용이 듭니다. 디스크 쓰기, AOF fsync 정책, 백그라운드 리라이트 작업은 스토리지가 느리거나 포화되면 지연 스파이크를 초래할 수 있습니다. 반면 지속성은 재시작을 덜 두렵게 만듭니다: 지속성이 없으면 계획되지 않은 재시작 시 Redis는 빈 상태로 시작합니다.
복제는 복제본에 데이터를 보관해 기본 노드가 다운될 때 장애 조치를 가능하게 합니다. 목표는 보통 가용성 우선이며 완전한 일관성은 아닙니다. 장애 상황에서는 복제본이 약간 뒤처질 수 있고 장애 조치 시 최근에 확정된 쓰기가 손실될 수 있습니다.
무엇을 조정하기 전에 두 숫자를 적으세요:
이 목표를 바탕으로 RDB 빈도, AOF 설정, 복제 및 자동 장애 조치 여부를 결정하세요—역할이 캐시인지, 세션 스토어인지, 큐인지, 혹은 1차 데이터 저장소인지에 따라 다릅니다.
단일 Redis 노드는 놀랄 만큼 많은 것을 처리할 수 있습니다: 운영이 단순하고 추론하기 쉬우며 많은 캐시, 세션, 큐 워크로드에 충분히 빠릅니다.
확장이 필요해지는 경우는 보통 메모리 한계, CPU 포화, 또는 단일 노드가 허용할 수 없는 단일 실패 지점이 될 때입니다.
다음 중 하나라도 해당하면 노드를 추가 고려:
실용적 첫 단계는 클러스터로 가기 전에 워크로드 분리(예: 두 개의 독립 Redis 인스턴스)를 검토하는 것입니다.
샤딩은 키를 여러 Redis 노드에 나누는 것으로 각 노드는 데이터의 일부만 저장합니다. Redis Cluster는 키스페이스를 슬롯으로 나누고 각 노드가 일부 슬롯을 소유하는 내장 방식입니다.
장점은 더 많은 총 메모리와 집계 처리량입니다. 단점은 복잡성 증가: 멀티키 연산은 같은 샤드에 있어야 하고(또는 해시 태그 사용), 문제 해결 시 더 많은 요소가 움직인다는 점입니다.
균등한 샤딩에도 실제 트래픽은 한쪽으로 치우칠 수 있습니다. 한 인기 키(핫 키)가 하나의 노드를 과부하시키고 다른 노드는 유휴 상태일 수 있습니다.
완화책: 짧은 TTL과 지터 추가, 값을 여러 키로 분할(키 해싱), 또는 읽기를 분산시키도록 접근 패턴을 재설계.
Redis Cluster는 토폴로지를 발견하고 적절한 노드로 요청을 라우팅하며 슬롯 이동 시 리다이렉션을 따를 수 있는 클러스터 인식 클라이언트를 필요로 합니다.
이전 전에는 확인하세요:
확장은 계획된 진화로 접근할 때 가장 잘 작동합니다: 부하 테스트로 검증하고 키 레이턴시를 계측하며 트래픽을 점진적으로 마이그레이션하세요.
Redis는 종종 “내부 배관”으로 취급되는데, 바로 그 점 때문에 표적이 됩니다: 노출된 포트 하나가 전체 데이터 유출이나 공격자 제어 캐시로 이어질 수 있습니다. 임시 데이터만 저장한다고 해도 Redis를 민감한 인프라로 가정하세요.
우선 인증을 활성화하고 ACL(Redis 6+)을 사용하세요. ACL을 통해:
모든 구성요소가 하나의 비밀번호를 공유하지 않게 하고, 서비스별 자격증명을 발급해 권한을 최소화하세요.
가장 효과적인 제어는 접근 불가로 만드는 것입니다. Redis를 프라이빗 인터페이스에 바인딩하고 프라이빗 서브넷에 배치하며 보안 그룹/방화벽으로 접근을 제한하세요.
호스트 경계를 넘나드는 경우(멀티 AZ, 공유 네트워크, 쿠버네티스 노드, 하이브리드 환경)는 TLS를 사용하세요. TLS는 스니핑과 자격증명 탈취를 막아주며 세션·토큰·사용자 관련 데이터를 다룰 때 작은 오버헤드만으로도 가치를 제공합니다.
남용 시 큰 피해를 줄 수 있는 명령을 잠그세요. ACL로 제한하거나 비활성화할 명령 예: FLUSHALL, FLUSHDB, CONFIG, SAVE, DEBUG, EVAL(또는 스크립팅을 엄격히 통제). rename-command로 보호하는 방법도 있지만 ACL이 보통 더 명확하고 감사하기 쉽습니다.
Redis 자격증명을 코드나 컨테이너 이미지에 두지 말고 시크릿 매니저에 보관하고 교체 계획을 가지세요. 교체는 클라이언트가 재배포 없이 자격증명을 다시 로드할 수 있거나 전환 창 동안 두 개의 유효 자격증명을 허용할 때 가장 쉽습니다.
실용적 체크리스트가 필요하면 운영 매뉴얼에 /blog/monitoring-troubleshooting-redis 노트를 함께 두세요.
Redis는 종종 “괜찮아 보인다”…가 트래픽 변화, 메모리 누적, 느린 명령이 모든 것을 멈추게 할 때까지 문제를 드러내지 않습니다. 가벼운 모니터링 루틴과 명확한 사고 대응 체크리스트는 대부분의 놀라움을 예방합니다.
팀 누구나 설명할 수 있는 소수의 지표로 시작하세요:
무언가 느려지면 Redis 자체 도구로 확인하세요:
KEYS, SMEMBERS, 큰 LRANGE 호출의 급증은 흔한 적신호입니다.지연이 증가하고 CPU가 정상이면 네트워크 포화, 과도한 페이로드, 또는 블로킹 클라이언트를 의심하세요.
성장을 계획할 때는 **여유(headroom)**를 유지하세요(일반적으로 20–30% 여유 메모리). 출시나 기능 플래그 후 가정도 재검토하세요. “지속적 축출”은 경고가 아니라 서비스 중단으로 취급하세요.
사고 시 다음 순으로 확인하세요: 메모리/축출, 지연, 클라이언트 연결, slowlog, 복제 지연, 최근 배포. 반복적으로 발생하는 주요 원인을 기록하고 영구적으로 수정하세요—알람만으로는 부족합니다.
팀이 빠르게 반복한다면 이러한 운영 기대치를 개발 워크플로에 포함시키는 것이 도움이 됩니다. 예를 들어 Koder.ai의 계획 모드와 스냅샷/롤백을 사용하면 Redis 기반 기능(캐싱, 레이트 리밋)을 프로토타이핑하고 부하 테스트를 진행하며 안전하게 변경을 되돌릴 수 있고, 구현을 소스 코드로 내보내 유지할 수 있습니다.
Redis는 다음과 같은 공유 인메모리 ‘빠른 레이어’로 가장 적합합니다:
영구적이고 권위 있는 데이터와 복잡한 쿼리는 기본 데이터베이스에 두세요. Redis는 가속기이자 조정자이지 시스템 오브 레코드가 아닙니다.
아니요. Redis는 지속성을 제공할 수는 있지만 “기본적으로 내구성 있는” 저장소가 아닙니다. 복잡한 쿼리, 강력한 내구성 보장, 또는 분석/리포팅용 데이터가 필요하면 기본 데이터베이스에 보관하세요.
몇 초치 데이터의 손실도 용납할 수 없다면, Redis의 지속성 설정만으로 요구를 충족한다고 가정하지 말고 신중히 구성하거나 다른 시스템을 고려하세요.
허용 가능한 데이터 손실량과 재기동 동작을 기준으로 결정하세요:
우선 RPO/RTO 목표를 적고, 그에 맞춰 지속성 설정을 튜닝하세요.
캐시-어사이드 패턴에서는 애플리케이션이 로직을 소유합니다:
일부 미스를 허용할 수 있고 만료/무효화 전략이 명확할 때 이 패턴이 잘 작동합니다.
사용자 영향과 백엔드 부하를 기준으로 TTL을 선택하세요:
user:v3:123)를 사용하세요.불확실하면 짧게 시작해 데이터베이스 부하를 측정한 뒤 조정하세요.
다음 중 하나 이상을 사용하세요:
이 패턴들은 동기화된 캐시 미스로 데이터베이스가 과부하되는 것을 막습니다.
일반적인 방법은 다음과 같습니다:
sess:{sessionId} 아래에 TTL을 가진 세션 데이터를 저장하고 세션 수명과 일치시키세요.user:sessions:{userId}를 활성 세션 ID의 Set으로 유지해 ‘모든 기기에서 로그아웃’ 기능을 구현할 수 있습니다.모든 요청마다 TTL을 연장하는 ‘슬라이딩 만료’는 무거운 사용자에게 세션을 무한히 유지시키므로, 만료 임박 시에만 연장하는 식으로 제어하는 것이 안전합니다.
카운터가 고착되거나 경합하지 않도록 원자적 업데이트를 사용하세요:
INCR와 EXPIRE를 분리된 비보호 호출로 하지 마세요.키의 범위를 신중히 정하세요(예: 사용자별, IP별, 경로별). Redis가 불가할 때는 허용(fail-open)할지 차단(fail-closed)할지 미리 결정하세요—특히 로그인 같은 민감한 엔드포인트는 중요합니다.
운영·내구성 요구에 따라 선택하세요:
LPUSH/BRPOP): 간단하지만 인플라이트(in-flight) 처리, 재시도, 가시성 타임아웃을 직접 구현해야 합니다.작업 페이로드는 작게 유지하고 큰 데이터는 다른 곳에 보관한 뒤 참조만 전달하세요.
Pub/Sub는 메시지를 놓쳐도 괜찮은 실시간 브로드캐스트에 사용하세요(예: 프레즌스, 실시간 대시보드). 특징:
모든 이벤트를 처리해야 한다면 Redis Streams가 내구성, 소비자 그룹, 재시도, 역압(backpressure) 처리 면에서 더 적합합니다. 운영 관점에서 Redis는 ACL/네트워크 격리로 잠그고 지연/추방(evictions)을 모니터링하며, /blog/monitoring-troubleshooting-redis 같은 런북을 유지하세요.