Backend/Redis (7) 썸네일형 리스트형 [Redis] 7. 실무에서 가장 많이 터지는 문제 총정리 Redis는 빠르고 강력하지만, 잘못 쓰면 장애가 터지는 속도 또한 빠른 도구입니다.이번 글에서는 실무에서 자주 경험하는 문제들을 중심으로원인 → 증상 → 해결책 순으로 정리했습니다.1. 메모리 폭증 문제 (Memory Leak 아님 → 잘못된 사용 패턴)💥 증상 Redis 메모리 사용량이 계속 증가 Evicted Keys 증가 → 중요한 캐시가 날아감 쓰기 성능 저하💣 원인 무한 증가하는 키 저장 (예: 로그, 통계 데이터) TTL이 없는 키 대량 누적 대형 Value(JSON 수백 KB)✔ 해결 TTL 기본 적용 (EXPIRE 자동 설정) SET 대신 SETEX, PSETEX 사용 대량 데이터는 Redis 대신 S3 / DB 저장 고려SETEX user:session:123 360.. [Redis] 6. Redis 클러스터 · Sentinel 구조 — 장애 대비와 확장성 완벽 이해하기 Redis는 속도가 빠르지만, 단일 서버에 올려두면 장애에 매우 취약합니다.그래서 실서비스에서는 반드시 Sentinel 또는 Redis Cluster 구성으로 운영하게 됩니다.이번 글에서는 “왜 필요한가?”부터 “어떤 차이가 있는가?”, “언제 무엇을 쓰면 좋은가?”까지 실무 기준으로 설명합니다.1. Redis 장애 대비가 중요한 이유단일 Redis 인스턴스를 쓰면 다음 문제가 발생합니다: 서버가 죽으면 → 모든 캐시 & 세션 & 메시징 기능이 중단됨 재부팅하면 메모리 기반 데이터가 사라질 수 있음 트래픽 증가 시 확장할 수 없음실제 운영에서는 Redis가 다운되면 로그인 세션이 날아가거나, 배치 작업이 실패하거나, 결제/인증 서버가 멈추는 등 치명적인 장애가 발생합니다.그래서 아래 두 가지 아키텍.. [Redis] 5. Redis Pub/Sub & Stream 완벽 이해 [Redis] 5. Redis Pub/Sub & Stream 완벽 이해Redis는 단순한 캐시나 데이터 저장소를 넘어서 실시간 메시징 시스템으로도 활용됩니다.특히 Pub/Sub과 Redis Streams는 실시간 알림, 이벤트 처리, 로그 수집, 비동기 메시지 전달에 많이 사용됩니다.이번 글에서는 실무 기준으로 Redis Pub/Sub과 Stream의 개념부터 차이점, 활용 사례까지 모두 정리했습니다.1. Redis Pub/Sub — 가장 단순한 실시간 메시징Redis Pub/Sub은 가장 기본적인 메시지 전달 방식입니다.Publisher가 특정 채널에 메시지를 발행(Publish)하면,Subscriber는 해당 채널을 구독(Subscribe)하고 메시지를 수신합니다.✔ Pub/Sub 기본 구조동작 방식.. [Redis] 4. 트랜잭션과 Lua 스크립팅 — Atomic 처리와 성능 극대 Redis의 진짜 가치는 Atomic(원자적) 연산과 고성능 처리를 위한 Lua 스크립트에서 폭발합니다.동시성 문제 없이 여러 명령을 안전하게 처리하거나, 복잡한 로직을 서버에서 직접 실행하여 네트워크 비용을 획기적으로 줄일 수 있습니다.이번 글에서는 Redis 트랜잭션과 Lua 스크립트 활용법을 실무 중심으로 정리합니다.1. Redis 트랜잭션 — MULTI / EXECRedis 트랜잭션은 SQL처럼 Rollback이 있는 구조는 아닙니다.대신 여러 명령을 큐에 넣고 한 번에 실행하여 Atomic 보장을 제공합니다.✔ 기본 구조MULTISET user:1:name "Autumn"INCR user:1:scoreEXEC모든 명령은 EXEC가 호출될 때 한 번에 실행됩니다.실패하면 전체 ROLLBACK이 되.. [Redis] 3. Redis 캐싱 전략 TTL, 만료 정책, Cache Aside / Write / Through Redis를 캐시로 쓴다면 반드시 알아야 하는 핵심이 있습니다.바로 TTL, 만료 정책, 캐싱 전략(Cache Patterns) 입니다.특히 실무에서는 “왜 캐시가 안 갱신되지?”, “왜 서버가 갑자기 느려졌지?” 같은 문제들이 대부분 캐시 전략 부재 때문입니다.✔ 1. TTL(Time To Live) — 캐시의 수명TTL은 Redis 키의 유효기간입니다.캐시는 영원히 살아있으면 안 되고, 적절한 시간이 지나면 지워져야 합니다.📌 TTL 설정SET user:1:data "..." EX 3600 # 1시간EXPIRE user:1:data 300 # 5분TTL user:1:data # TTL 조회📌 TTL 운영 팁API 응답 캐시 → 30초 ~ 5분상품/컨.. [Redis] 2. Redis 자료구조 - String, List, Set, Sorted Set, Hash Redis가 빠르고 유연한 이유는 단순히 인메모리 DB이기 때문만은 아닙니다.가장 큰 이유는 다양한 자료구조를 최적화된 형태로 제공하기 때문입니다.이번 글에서는 Redis의 핵심 자료구조 5개를 실무 기준으로 완전히 정리합니다.✔ Redis 자료구조가 중요한 이유Redis는 단순 key-value 저장소가 아니라 데이터 타입별 저장 방식이 완전히 다릅니다.따라서 어떤 자료구조를 선택하느냐에 따라:성능이 10배 이상 차이날 수 있고메모리 사용량이 크게 달라지며TTL 처리나 동시성 관리가 달라질 수 있습니다.그래서 Redis에서는 “자료구조 선택 = 성능 설계” 입니다.1. String — Redis의 기본이자 가장 많이 쓰는 타입String은 Redis의 가장 기본 타입이며, 내부적으로는 SDS(Simpl.. [Redis] 1. Redis란? 캐시, DB, 메시지 브로커 Redis는 백엔드 개발자라면 반드시 다루게 되는 핵심 인프라입니다.대부분은 “캐시 서버”로만 알고 있지만, 실제로는 캐시 + DB + 메시지 브로커 + 분산락 + 세션 저장소 역할까지 수행합니다.이번 글에서는 Redis가 무엇이고, 왜 이렇게 폭넓게 활용되는지 완전히 정리해드립니다.✔ Redis란 무엇인가?Redis는 인메모리 데이터 저장소(In-Memory Data Store)입니다.데이터가 메모리에 저장되기 때문에 디스크 기반 DB보다 훨씬 빠릅니다.특징 요약데이터를 메모리에 저장 → 속도가 미친 듯이 빠름다양한 자료구조 지원 (문자열, 리스트, 해시, 셋 등)싱글 스레드 기반의 안정적인 구조TTL(만료시간) 기반 캐싱 기능 내장Pub/Sub 메시징 기능 제공Persistence(AOF/RDB)로 .. 이전 1 다음
