Mini-Redis 프로젝트 (중점 : Redis에 관해서)

https://github.com/IMGyuGo/Mini-Redis

GitHub - IMGyuGo/Mini-Redis: 미니레디스 프로젝트[팀원 : 김규민, 김석제, 김현옥, 고민석]

현재 위 사이트를 접속해보면 Python으로 만든 Mini-Redis 프로젝트가 있다.

 

TCP 프로토콜로 소켓 통신을 하고, 실제 Redis와 비슷하게 구현하기 위해 RESP2 프로토콜로 encoding, decoding 작업을 해 실제로 redis-cli -p 6380 을 통해 커맨드라인에서 실행하면, 작동이 된다. (내 로컬에서만)

 

현재 Codex에게 실제 Redis와 비교해본 결과를 보여달라 했을 때,

• 학습용: 좋음
• 데모/실험용: 좋음
• 제한된 내부 도구용: 조건부 가능
• 범용 운영용 Redis 대체: 아직 어려움

이렇다고 한다.

나는 오늘 시간이 조금 날 때 레디스를 더욱 조사해보면서

1. 기존 MongoDB와의 비교

2. 실제 Redis와의 비교

3. 현재 구현되어 있는 Redis기능

4. 앞으로 어떻게 사용해봐야할지에 대한 조사

5. 실제로 운영에 테스트해보면서 얼마나 잘 동작하고 실제 구현이 가능한지에 대해 공부를 해보고자 한다.

 

1. MongoDB와 Redis 비교

- Redis는 보통 빠른 메모리 기반 저장소로 사용

- MongoDB는 보통 문서를 오래 저장하는 DB로 사용

Redis : 빠름, MongoDB : 오래 보관하고 구조화해서 저장하기 좋음

- Redis : 기본적으로 메모리 중심 저장소

  - 개념

    - 매우 빠른 읽기 / 쓰기 ( 빨리 넣고, 빨리 꺼내고, 빨리 지워야 하는 데이터에 강함 )

    - 캐시로 많이 사용됨

    - TTL이 매우 강력함

    - 단순 key-value 접근이 쉬움

    - 세션, 토큰, 카운터, 랭킹 같은 용도에 잘 맞음

    - 데이터 타입이 다양함

  - 사용

    - 로그인 세션 저장

    - 이메일 인증번호 저장

    - 비밀번호 재설정 토큰 저장

    - API rate limit카운터

    - 캐시

    - 짧은 시간 유지되는 작업 상태

    - 실시간 랭킹

- MongoDB : 문서 기반 데이터베이스

  - 개념

    - 디스크 기반 장기 저장에 적합 ( 구조적인 데이터를 오래 보관하는 저장소 )

    - JSON 비슷한 구조로 데이터 저장 가능

    - 구조가 비교적 유연

    - 복잡한 필드를 가진 데이터를 저장하기 좋음

    - 애플리케이션의 본 데이터 저장소로 자주 사용

  - 사용

    - 사용자 프로필 저장

    - 게시글/댓글 저장

    - 주문/문서/설정 데이터 저장

    - 로그성 문서 저장

    - 서비스의 메인 데이터 저장소

 

- 사용 패턴

  - MongoDB는 원본, Redis는 캐시 (Cache-aside 패턴)

    - 실제 원본 데이터는 MongoDB에 저장

    - 자주 읽는 값은 Redis에 캐시

    - Redis가 비어 있으면 MongoDB에서 읽어서 다시 Redis에 올림

    - 예시

      - 사용자 프로필 원본은 MongoDB에 존재

      - API 요청이 오면 먼저 Redis를 확인

      - Redis에 없으면 MongoDB에서 읽음

      - 읽은 값을 Redis에 몇 초 또는 몇 분 캐시

  - Redis는 임시 상태, MongoDB는 영구저장

    - Redis에는 지금 당장 필요한 임시 상태 저장

    - MongoDB에는 최종 결과 저장

    - 예시

      - Redis : 현재 로그인 상태, OTP, 임시 큐 상태

      - MongoDB : 사용자 계정 정보, 주문 정보, 기록 데이터

 

2. Redis와 mini-redis-project 비교 (보완해야할 점)

- 성능

실제 Redis는 매우 높은 처리량과 매우 낮은 latency를 목표

부족한 점

  - 초저지연 메모리 접근 최적화

  - 대량 요청 처리 성능

  - 대규모 동시 접속 처리

  - 메모리 할당/해제 비용 최소화

  - 네트워크 I/O 최적화

 

- 동시성 / 서버 실행 모델

실제 Redis는 이벤트 루프 기반으로 매우 정교하게 최적화 되어 있음

명령 실행을 CommandQueue로 직렬화해서 안정적으로 처리하려는 방향

  - 요청이 많아질수록 병목이 쉽게 생김

  - 긴 작업 하나가 뒤 요청을 오래 막을 수 있음

  - 고성능 네트워크 이벤트 처리 모델이 아직 단순

  - connection 수가 많아졌을 때 확장성이 제한될 수 있음

 

- 내구성(durability)과 장애 복구 신뢰성

현재 프로젝트에는 AOF, snapshot, recovery가 존재함

하지만 실제 운영에서는 아래 수준까지 검증되어야 함

  - 프로세스 강제 종료 직전 데이터 유실 범위

  - AOF 손상 시 복구 신뢰도

  - snapshot + AOF replay 순서의 완전성

  - 부분 쓰기, 파일 깨짐, 디스크 오류 상황 대응

  - fsync 정책별 데이터 보장 수준 검증

  - 장시간 운영 후 persistence 파일 비대화 대응

 

- 메모리 관리

실제 Redis는 메모리 기반 서버이기 때문에 메모리 관리가 핵심

추가해야할 것

  - 최대 메모리 제한

  - eviction 정책

    - "메모리가 부족할 때 어떤 데이터를 삭제할지 결정하는 규칙"

    - "LRU (Least Recently Used) 알고리즘 - 가장 오래 안 쓴 데이터 삭제"

    - "LFU (Least Frequently Used) 알고리즘 - 가장 적게 사용된 데이터 삭제"
    - "TTL 기반"

    - 실제 레디스 정책 이름

      - noeviction (삭제 안함 (에러 발생))

      - allkeys-lru (전체 키에서 LRU)

      - volatile-lru (TTL 있는 key만 LRU)

      - allkeys-lfu (전체 key에서 LFU)

      - volatile-ttl (TTL 짧은 것부터)

  - 데이터 크기 추적

  - key/value 메모리 사용량 추적

  - 메모리 압박 상황 대응

  - 대용량 key 방어 전략

예를 들어, 운영에선 "메모리가 꽉 차면 어떤 key를 버릴지"가 매우 중요

- 데이터 타입 확장 (현재 프로젝트는 str 중심 kv 저장)

실제 Redis는 단순 KV를 넘어 풍부한 자료구조를 제공

 

- 복제 / 고가용성

운영에서 가장 큰 차이 (현재 프로젝트는 단일 서버 기준 구조)

  - primary-replica 복제

  - 복제 지연 관리

  - 장애조치(failover)

  - 리더 선출

  - split-brain 방지

  - 백업 노드 승격

 

- 클러스터링 / 샤딩(sharding)

데이터가 커지고 요청이 많아지면 여러 노드에 나눠 저장해야 함

  - key slot 분산

  - 샤드 간 라우팅

  - 리밸런싱

  - 노드 추가/제거

  - 클러스터 메타데이터 관리

 

- 운영 기능

  - metrics

  - structured logging

  - health check

  - admin command

  - slow query 관측

  - connection 통계

  - memory 통계

  - persistence 상태 관측

  - alert 연동

 

- 보안

  - 인증

  - 권한분리

  - TLS

  - 접속 제어

  - 관리자 명령 보호

  - audit logging

 

- 프로토콜 및 클라이언트 호환성

  - RESP 호환 범위 확장

  - Redis 클라이언트 라이브러리와의 실제 호환성

  - 명령 응답 포맷 정합성

  - 에러 메시지와 동작 일관성

  - corner case 호환성

  

- C가 유리한 이유

  - 메모리 제어가 정밀

  - 오버헤드가 작음

  - 매우 빠른 실행 성능

  - 네트워크/이벤트 루프 최적화에 유리

  - 자료구조를 아주 세밀하게 튜닝가능

  - 초고속 응답

  - 많은 연결 수

  - 수십만/수백만 key 처리

  - 메모리 사용량 최소화

  - 운영 레벨 캐시 서버

 

- C는 강력하지만 개발 비용이 큼

  - 구현 난도 상승

  - 메모리 버그 위험 증가

  - 생산성 저하

  - 실험 속도 저하

  - 유지보수 난도 증가

 

3. 현재 구현되어 있는 Redis 기능과 추가할 목록

현재 mini-redis는 GET이 기본적으로 메모리 저장소를 확인

GET key
-> Redis engine
-> StorageManager.get(key)
-> 값 반환

Mongo 원본 + Redis 캐시 구조로 변경 필요(cache-aside 패턴)

GET key
-> 먼저 Redis 캐시 조회
-> 있으면 바로 반환
-> 없으면 MongoDB 조회
-> 조회한 값을 Redis에 TTL과 함께 캐시
-> 반환

 

따라서 변경할 예정

1. MongoDB에만 종속되지 않도록 DB 어댑터 인터페이스로 구성할 예정

  -> write-through 성격을 cache-aside 구조로 변경

4. 앞으로 어떻게 사용해봐야할지에 대한 조사

https://github.com/IMGyuGo/Mini-Redis/blob/main/%ED%94%84%EB%A0%88%EC%9E%84%EC%9B%8C%ED%81%AC%EC%82%AC%EC%9A%A9%EB%B2%95.md

Mini-Redis/프레임워크사용법.md at main · IMGyuGo/Mini-Redis

프레임워크 사용법으로 추가할 예정

 

5. 실제로 운영 적용

나중에 실제 개발이 완료되면 업데이트 예정

MongoDB는 HTTP 프로토콜 연결로 실제로 Cache 적용이 되는지 확인을 해보고

로컬로 배포할 웹사이트를 만들어서 테스트 진행 예정