Please enable JavaScript.

Coggle requires JavaScript to display documents.

Redis를 활용한 캐싱 - Coggle Diagram

- - - - Redis Sentinel
        복제 기반의 고가용성 관리도구. Redis 마스터-슬레이브 구조에서 장애 감지 및 자동 Failover를 수행하는 컴포넌트.
        
        하나의 데이터 셋을 다루며, 샤딩은 불가능하다
        
        수평 확장보다 고가용성에 초점
        
        비교적 설정과 운영이 단순
        
        모니터링: 마스터와 레플리카 상태 체크
        
        알림: 장애 발생 시 관리자에게 알림
        
        자동 장애 조치(Failover): 레플리카 중 하나를 마스터로 승격
        
        구성 관리: 클라이언트가 새로운 마스터를 자동 인식하도록 지원
      - Redis Cluster
        샤딩 기반의 수평 확장 구조
        
        운영은 Sentinel보다 복잡하지만, 대규모 트래픽/데이터 처리에 유리하다
        
        클라이언트가 Cluster를 지원해야 사용 가능 (Cluster-aware Client 필요)
        
        샤딩 지원: 데이터를 여러 슬롯(0~16383)에 분할 저장
        
        노드 간 통신 및 복제: 노드는 마스터/레플리카 구조 가능
        
        자동 장애 조치: 마스터 장애 시 레플리카가 자동 승격
        
        수평 확장 용이: 노드 추가로 데이터 용량 및 처리량 확장 가능
    - - 캐싱
        Redis는 주로 데이터베이스 쿼리나 계산 결과를 캐싱하는 사용되는데, 이때 많은 쿼리 작업을 메모리에 저장하여 테이터베이스에 대한 부하를 줄일 수 있다. 이를 통해 빠른 응답 시간을 제공하고 애플리케이션의 성능을 향상시킬 수 있다.
        
        캐싱 전략
        
        Write-Through
        
        애플리케이션이 DB 갱신 시점에 캐시에도 동시에 쓰기
        
        읽기 시 항상 캐시에서 응답
        
        장점: 읽기 일관성 확보
        
        단점: 쓰기 지연 증가, 캐시 쓰기 오버헤드
        
        Write-Back
        
        애플리케이션이 캐시에 먼저 쓰고, 백그라운드에서 DB에 비동기 반영
        
        장점: 쓰기 성능 극대화, 배치 처리 효율화
        
        단점: 장애 시 데이터 손실 위험, 복잡한 오류 처리 필요
        
        Read-Through
        
        캐시 미스 시, 자동으로 원본 DB에서 로드 후 반환 (캐시 미들웨어 기능)
        
        Cache-Aside (Lazy Loading)
        
        애플리케이션이 캐시에서 키 조회
        
        캐시 미스 시 원본 DB에서 조회 후 캐시에 저장
        
        이후 요청 시 캐시에서 직접 응답
        
        장점: 필요한 데이터만 캐시, 컨트롤 용이
        
        단점: 첫 요청 지연, 캐시 일관성 관리 필요
      - 높은 성능
        
        모든 데이터를 메모리에 저장하므로 디스크 I/O 오버헤드가 없고,
        이로 인해 매우 빠른 읽기/쓰기 작업 수행이 가능.
        
        단일 스레드 모델을 사용해 데이터베이스 작업을 순차적으로 처리하므로
        복잡한 동시성 문제를 피하고 데이터 일관성 유지 가능.
      - 다양한 데이터 구조 지원
        단순한 키-값 구조 외에도 문자열, 해시, 리스트, 셋, 정렬된 집합 등 다양한 데이터 유형을 지원함으로써, 많은 응용 프로그램에서 데이터 구조를 효과적으로 모델링할 수 있다
      - 분산환경 지원
        마스터-슬레이브 복제, 클러스터링 등의 기능을 제공해 데이터의 가용성과 확장성을 높일 수 있다.
        여러 서버에 데이터를 분산 저장하고 복제하여 고가용성을 보장하고, 수평적인 확장이 가능하다.
      - 간편한 사용 및 다양한 언어 지원
        간단하고 직관적인 명령어를 제공하며, 다양한 프로그래밍 언어에서 접근할 수 있는 클라이언트 라이브러리를 지원한다. 이를 통해 다양한 환경과 언어로 개발된 애플리케이션과 통합할 수 있다는 장점을 가진다.
      - 데이터 안정성 보장
        주로 메모리에 데이터를 저장하고, 필요에 따라 스냅샷이나 AOF 로그 파일을 사용하여 데이터의 영구 저장과 복구를 지원한다. 이를 통해 레디스는 빠른 응답 시간과 고성능을 유지하면서도 데이터의 안정성을 보장할 수 있다.
    - - 인메모리 구조 -> 높은 성능
        영구적인 디스크 저장소를 갖지 않고, 모든 데이터를 메모리에 유지.
        이로 인해 데이터에 대한 빠른 액세스 속도와 높은 처리량 제공 가능.
      - 선택적 영속화 기능 제공
        RDB 스냅샷 또는 AOF(Append-Only File) 형태로 선택적 영속화 제공.
        따라서, 캐시뿐 아니라 다양한 용도로 활용된다.
        
        활용 예시
        
        메시지 브로커
        레디스는 Pub/Sub 모델을 지원해 메시지 브로커로 사용할 수 있음. 다양한 컴포넌트나 서비스 간의 비동기 통신을 위해 사용되며, 실시간 채팅, 이벤트 기반 시스템, 실시간 분석 등에 적합하다.
        
        세션 저장소
        레디스는 세션 클러스터링과 부하 분산을 지원하여 대규모 웹 애플리케이션에서 확장성과 고가용성을 제공할 수 이싿.
        
        실시간 데이터 분석
        스트림(Stream) 데이터 구조를 활용해 이벤트 시퀀스를 저장하고, 소비자가 실시간으로 이벤트를 처리하고 분석할 수 있어, 이를 통해 실시간 대시보드, 실시간 알림, 로그 분석 등 다양한 실시간 데이터 처리 시나리오가 구현 가능하다.
        
        대기열 관리
        레디스는 메시지 큐 시스템으로도 사용 가능하다. 작업 처리를 비동기적으로 관리하기 위해 레디스의 리스트 데이터 구조를 활용하여 작업을 대기열에 추가하고, 워크 프로세스가 해당 작업을 처리하는 방식으로 사용 가능하다. 이를 통해 작업의 순서와 우선순위를 조절하고, 작업 처리량을 제어할 수 있다.
      - Single Threaded
        싱글 스레드 구조로 한 번에 하나의 명령만 처리할 수 있어, 중간에 처리 시간이 긴 명령어가 들어오면 그 뒤의 명령어 들은 앞에 있는 명령어가 처리될 때까지 대기 필요
    - - 운영상 유의점
        
        키 삭제
        한 번 생성한 키를 선택적으로 삭제하기 어렵고,
        특별한 조치를 취하지 않으면 서버 재시작 시에도 키가 계속해서 보관될 수 있다
        
        일정 시간 이후 삭제
        각각의 키를 저장할 때 set에 저장해 특정 시간이나 조건에 따라 삭제하는 방법으로,
        실제 삭제를 사용한다기 보다는 밀어내기를 한다고 이해할 수 있다.
        
        기간 만료 후 삭제
        
        가장 많이 사용되는 방식으로, 키를 추적할 필요 없이 쉽게 관리 가능
        
        키-값을 SET 커맨드로 저장해 EXPIRE 커맨드로 만료 시간을 정하는 방법을 사용하거나, Redis 버전 2.0.0 이상에서는 SETEX 커맨드(SET + EXPIRE)를 사용
        
        일괄 삭제: FLUSHDB 명령어를 통해 모든 키를 파괴. 복구가 불가능하며 보통 개발 수준에서 사용.
        
        조건 기반 삭제
        하나의 키에는 하나의 데이터만 남게 되는 set의 특징과, 교집합/차집합/합집합 같은 기능이
        제공되는 것을 활용해 교차되는 키만 남기거나 뺀 연산을 적용해 키를 삭제할 수 있다.
        
        메모리 관련 이슈
        
        메모리 과다 사용: 총 메모리 초과 시 디스크 스왑 발생, 성능 급락
        
        Eviction 정책 부적절 설정: noeviction 등 잘못된 정책 사용 시 캐시 미스 증가 또는 OOM 발생
        
        핫키(Hot Key) 집중
        특정 키에 트래픽이 몰리면 단일 샤드 병목 현상이 유발됨
        
        영속화(Persistence) 위험
        
        RDB 스냅샷: 주기적 스냅샷 사용시, 주기 사이에 발생한 데이터 손실 위험
        
        AOF 재작성: AOF rewrite 과정 중 서버 충돌 시, 로그 손상으로 전체 데이터 손실 가능
        
        네트워크 및 ACL 설정 부재
        기본 포트(6379) 개방, ACL 미사용 시 내부망/인터넷 스캔 툴에 노출 위험
      - 보안 취약점 및 대응책
        
        안증 미설정 문제
        기본적으로 인증 없이도 접속이 가능해 보안 위험 존재
        
        인증 기능 활성화
        
        requirepass 설정을 통해 비밀번호 인증 필수화
        
        Redis 6.x 이상에서는 ACL을 활용해 사용자별 권한 부여 가능
        
        외부 네트워크 노출
        기본적으로 외부에서 접근 가능한 포트이며, 방치 시 누구나 접속 가능
        
        접근 제어 강화
        
        bind 127.0.0.1 또는 내부 IP로 제한하여 외부접속 차단
        
        protected-mode yes 설정으로 안전모드 적용
        
        Redis 서버를 반드시 방화벽 또는 프라이빗 네트워크(VPC) 내에 배치
        
        평문 통신
        암호화되지 않은 평문으로 데이터를 주고 받으므로 도청 위험 존재
        
        TLS 암호화 적용
        
        운영 환경에서는 TLS 통신 외에는 접근을 허용하지 않도록 구성
        
        클라이언트와 서버 모두 TLS 인증서 필요
        
        관리자 명령어 노출
        FLUSHALL, CONFIG, SHUTDOWN 등 위험 명령어가 무제한 사용 가능할 경우 치명적인 문제가 발생할 수 있음
        
        명령어 사용 제한
        
        ACL 기능으로 명령어별 접근 권한 제어
        
        민감 명령어는 일반 사용자 계정에서 사용을 차단하고,
        관리자 명령어는 특정 사용자에게만 부여
        
        포트 노출
        기본 포트 6379를 사용하며, 이를 악용한 스캔 공격이나 무차별 인증 시도 가능
        
        접근 IP 제어
        
        서버 보안 그룹 또는 방화벽 설정으로 특정 IP만 허용
        
        운영 환경에서는 SSH 터널링 등을 통해 간접 접근만 허용
        
        악성 명령/명령어 남용 감지 미비
        명령어 사용 로그가 제한적이므로 악의적 사용을 탐지 하려면 추가 구성이 필요
        
        보안 감시 체계 구성
        
        보안 로깅 기능 연동 (예: MONITOR 활용 + 로깅 시스템)
        
        Fail2Ban 또는 보안 모니터링 시스템을 통해 비정상 명령 시도 감지
        
        경고 시스템을 통해 이상 동작 발생 시 관리자 알림
        
        무차별 대입 공격 가능성
        인증 기능을 활성화하지 않거나 약한 비밀번호를 사용할 경우,
        반복적인 시도를 통한 침입 가능성 존재
        
        접속 차단 시스템 설정
        
        강력한 비밀번호 정책 적용
        
        로그인 실패 횟구 제한 도구 연동으로 비정상 IP 차단
        
        접근 기록 주기적 확인 및 감사
        
        취약 버전 사용
        오픈소스 특성상 보안 취약점이 수시로 발견되며, 구버전 사용 시 보안 위협에 노출될 가능성이 높음
        
        최신 보안 패치 유지
        
        보인 패치를 포함해 최신 안정 버전으로 유지
        
        패키지 관리 시스템이나 자동 업데이트 도구로 정기 점검
- - - - Memcached
        단순한 캐싱 요구사항에 적합하며, 구현이 간단하다.
        단순한 키-값 저장소로, 빠른 읽기 성능과 낮은 지연 시간이 특징.
        값(value)은 기본 1MB까지 저장 가능하며, 클러스터는 클라이언트에서 직접 분산 처리한다.
        
        데이터 구조: 단순한 키-값 쌍 저장
        
        확장성: 수평 확장 용이, 클라이언트 측에서 분산 처리
        
        지속성: 데이터 영속성 미지원, 서버 재시작 시 데이터 손실 (비영속성)
        
        활용 사례: 정적 웹 페이지 캐싱, 세션 저장소 등 (일기만 많은 단순 앱)
        
        사용자 피드 캐싱
        🟩 최저 비용 캐시 솔루션: 복잡한 구조 필요 없이 간단하며, 메모리 사용량도 낮음
        🟩 제한적 기능: 확장성과 기능이 부족하다는 단점 -> 캐시 이외 용도로는 불리
        
        비용: 매우 낮음(가벼운 인프라), 매니지드 시 Redis 보다 저렴하다
      - Apache Ignite
        복잡한 트랜잭션과 실시간 분석이 필요한 시스템, 대규모 데이터 처리에 적합.
        In-Memory Data Grid(IMDG)로, 메모리 중심의 분산 해시 테이블을 기반으로 SQL 쿼리, ACID 트랜잭션, 배치 처리를 지원.
        자동 파티셔닝과 노드 간 데이터 재배치로 수평 확장이 용이하며, 디스크 영속성 옵션도 제공.
        
        데이터 구조: 키-값 저장소, SQL 테이블, ACID 트랜잭션 지원
        
        확장성: 자동 파티셔닝과 데이터 재배치를 통한 수평 확장
        
        지속성: 메모리 중심이지만 디스크 기반 영속성 옵션 제공
        
        활용 사례: 실시간 분석, 스트리밍 데이터 처리, 복잡한 트랜잭션 처리 등
        
        사용자 피드 캐싱
        🟨 기능 많고 유연하지만 운영 비용 큼
        
        SQL, ACID 트랜잭션, 인메모리 + 디스크 저장, 대규모 실시간 처리
        
        JVM 기반으로 메모리 / CPU 많이 사용, 클러스터 구성 복잡
        
        복잡한 기능만큼 비용 발생도 큼
        
        비용: 높음(JVM + 클러스터 관리 + HW 리소스)
      - Couchbase
        문서 기반 저장과 복잡한 쿼리 기능이 필요한 애플리케이션에 적합.
        문서 지향 NoSQL 데이터 베이스로, JSON 문서 저장과 N1QL 쿼리 언어를 지원.
        
        데이터 구조: JSON 문서 저장, N1QL 쿼리 지원
        
        확장성: 자동 샤딩 및 리밸런싱을 통한 수평 확장
        
        지속성: 디스크 기반 영속성과 메모리 중심의 에페메랄(volatile) 버킷 구분 운용 가능
        
        활용 사례: 모바일 백엔드, 실시간 분석, 콘텐츠 관리 시스템 등
        
        사용자 피드 캐싱
        🟥 성능은 뛰어나지만, 비용 부담이 큼
        
        운영 복잡도 + 클러스터 유지비 + SSD 인프라 필요
      - Aerospike
        높은 확장성과 빠른 성능이 요구되는 대규모 시스템에 적합.
        고성능 NoSQL 데이터베이스로, 하이브리드 메모리 아키텍처(HMA)를 채택해 DRAM에 인덱스를, SSD에 데이터를 저장함으로써 높은 처리량과 낮은 지연을 동시에 달성한다. 자동 파티셔닝과 리밸런싱으로 대규모 분산 환경에 적합
        
        데이터 구조: 키-값 저장소, 리스트, 맵 등 복합 데이터 타입 지원
        
        확장성: 자동 파티셔닝과 리밸런싱을 통한 수평 확장
        
        지속성: 하이브리드 메모리 아키텍처를 통한 메모리+디스크 저장
        
        활용 사례: 실시간 광고 타겟팅, 사기 탐지, IoT 데이터 처리 등
        
        사용자 피드 캐싱
        🟥 무료도 있지만, 확장성이 낮다: 인스턴스 규모가 커질 수록 비용 ⬆️
        🟥 캐시 없이 모든 요청을 처리하려면 더 강력한 서버 필요 -> 비용, 지연 모두 ⬆️
      - Redis
        다양한 데이터 구조와 빠른 성능을 요구하는 애플리케이션에 적합.
        인메모리 데이터 저장소로, 다양한 데이터 구조 지원 및 빠른 읽기/쓰기 성능 제공.
        
        데이터 구조: 문자열, 리스트, 해시, 셋, 정렬된 셋 등 다양한 구조 지원
        
        확장성: Redis Cluster를 통한 수평 확장 가능
        
        지속성: RDB 스냅샷, AOF 로그를 통한 데이터 영속성 제공
        
        활용 사례: 세션 저장소, 캐싱, Pub/Sub 시스템, 실시간 분석 등
        
        사용자 피드 캐싱
        ✅ 가성비 최상: 단순 캐싱 용도로는 메모리만 있으면 충분. 스케일 용이.
        ✅ 기술, 운영 부담 낮음: 메모리 기반이지만 Cluster / Replication으로 확장 가능
        ✅ 비용 안정성: 매니지드 서비스도 안정적이며 예측 가능한 비용. 가격대 성능비 좋음
        ✅ 기능 풍부
        
        비용: 중간 (RAM 가격 ⬆️), 매니지드 시 비용 ⬆️, 하지만 유지보수 ⬇️
        
        사용자 피드 캐싱 관점에서의 이점
        
        초저지연/고처리량
        DB 호출을 획기적으로 줄여 평균 응답 시간을 80% 이상 단축 가능
        
        정렬된 피드 관리 (Sorted Set)
        Redis의 Sroted Set은 O(log N) 복잡도로 삽입/삭제/범위 조회가 가능해 타임스탬프 기반 피드를 빠르게 정렬 및 조회하는 것이 가능
        
        원자성 및 복합 연산
        Lua 스크립트와 원자 명령으로 멀티스탭 피드 업데이트를 일관성 있게 처리할 수 있으며, ZINTERSTORE / ZUNIONSTORE로 팔로잉 교집합,합집합 처리도 지원
        
        실시간 알림 (Pub/Sub)
        레디스 Pub/Sub를 이용해 새로운 동영상 업로드 시 실시간으로 팔로워에게 푸시 알림을 전송할 수 있다
        
        클러스터 확장성
        Redis Cluster 모드로 노드를 수평 확장해, 사용자 수/피드 항목 증가에도 선형적인 처리량 증가가 가능
        
        Spring Boot 통합
        Spring Cache 추상화를 통해 Cacheable, CachePut 어노테이션만으로도 간단히 Redis 캐시 레이어 추가 가능
    - - RDBMS
        
        데이터 액세스 패턴: 디스크 I/O 기반, 조인 비용 높음
        
        스키마: 고정 스키마. 변경 시 마이그레이션 필요
        
        트랜잭션: 강력한 ACID, 복잡 트랜잭션 필요
        
        확장성: 수로 수직 확장, 샤딩 복잡
        
        지연 시간: 평균 5~10ms 이상
        
        유지 관리: 스키마 관리, 조인 최적화 필요
        
        한계
        
        매번 디스크 I/O와 조인으로 지연 발생
        
        스키마 변경 시 서비스 재배포의 부담이 큼
      - NoSQL
        
        데이터 액세스 패턴: 메모리 기반, key-value 조회 최적화
        
        스키마: 스키마리스, 유연한 확장 가능
        
        레디스의 스키마는 데이터를 정규화하고, 데이터 row에 대해 일관된 레퍼런스를 가질 수 있게 해주는 용도로 존재
        
        트랜잭션: 파티션 단위 ACID, 가벼운 원자성 연산
        
        확장성: 수평 확장 용이, 클러스터 자동 샤딩
        
        지연 시간: 서브밀리초 ~ 1ms 이하
        
        유지 관리: 단순 키-값 모델, 운영 복잡도 낮음
        
        ✅ 최적
        
        메모리 조화로 서브밀리초 응담
        
        Sorted Set으로 순위 기반 피드 조회 최적
        
        스키마리스로 자유로운 피드 항목 확장