1. 도입을 희망하는 기술

<aside>

Redis - 오픈 소스 기반의 인메모리(In-memory) 키-값 데이터 구조 저장소

</aside>

2. 기술 설명

<aside>

• Remote Dictionary Server의 약자로 키(Key) - 값(Value) 쌍의 해시 맵과 같은 구조를 가진 비관계형(NoSQL) 데이터베이스 관리 시스템(DBMS)이다. </aside>

1. 기술 장점

<aside>

• 성능 → Redis 데이터는 메모리에 저장되어 대기 시간이 낮아 DB보다 빠르게 처리 할 수 있다 평균적으로 읽기 및 쓰기 작업 속도가 1ms로 디스크 기반 데이터베이스보다 빠릅니다.
• 유연한 데이터 구조 : String, List, Hash, Sorted, Map, Set, Bitmap , JSON 등의 다양한 데이터 타입을 지원하므로 애플리케이션의 요구 사항에 알맞은 데이터 타입을 활용할 수 있습니다.
• 개발 용이성 : Redis는 쿼리문이 필요하지 않으며, 단순한 명령 구조로 데이터 저장, 조회 등이 가능합니다
• 데이터 영속성
  • 애플리케이션은 배포, 업데이트, 장애 등으로 인해 재시작이 빈번하게 일어나는데, 로컬 캐시는 재시작 시 모든 캐시 데이터가 사라진다.
• 독립된 프로세스로서의 이점
  • 로컬 캐시는 JVM 힙 메모리를 공유하므로, 캐시 데이터가 많아지면 GC 부담이 증가해 애플리케이션 전체의 성능(응답 속도)에 악영향을 줄 수 있다.
  • 반면 Redis는 애플리케이션과 완전히 분리된 프로세스로 실행되기 때문에 외부 메모리를 사용하여 GC에 영향을 주지 않는다.
• 확장성
  • 향후 서버가 여러 대로 늘어나더라도 자연스럽게 공유 캐시로 확장 가능.
• 데이터 가시성(모니터링) 및 관리 용이성
  • redis-cli와 같은 모니터링 도구를 통해 키/TTL/메모리/히트율 모니터링, 슬로우로그 분석, 키스페이스 알림 등이 가능하다.
  • 로컬 캐시는 내부 상태를 확인하려면 별도의 API를 구현해야 하는 등 번거로울 수 있다.

</aside>

4. 단점 / 한계점 / 주의사항

<aside>

• 메모리 기반 → 데이터 용량이 많으면 메모리 부담되며 메모리에만 저장되어 상당한 메모리 공간이 필요하고 데이터 유실 가능성이 있습니다.
• 복잡한 트랜잭션 부적합 →단순한 키-값 스토리지에 가까우므로 관계형 DB처럼 조인, 복잡한 쿼리 같은 대량의 데이터 처리에 부적합할 수 있습니다.
• 단일 스레드 아키텍처 → 기본적으로 단일 스레드 환경에서 동작하기 때문에 여러 개의 CPU 코어를 활용한 병렬 처리가 어렵고 CPU 집약적인 작업이나 매우 높은 동시성이 요구되는 작업에는 병목 현상이 발생 할 수 있습니다. </aside>

1. 도입 배경과 필요성

<aside>

• 로그아웃 , 회원 탈퇴 시 AccessToken과 RefreshToken을 즉시 무효화 해야하는 요구가 존재하면 DB 기반 검증은 속도가 느려 실시간 처리에 부적합하므로 In-Memory 기반인 Redis 사용합니다.
  • TTL 기능을 활용하여 토큰 만료 시 자동 삭제 가능 → 일관성 유지
• 설문 응답 제출 API는 설문이 진행 중인지 상태 확인, 질문/응답의 유효성 검증, 참여자 정보를 스냅샷으로 저장하기 위해 외부 API 호출이 필요하다.
  • 외부 API 호출 시, 스레드/커넥션 풀 고갈로 병목현상이 발생하기 때문에 이를 해결하기 위해서 캐싱을 사용
  • 비동기 처리나 CQRS 같은 구조 변경보다 훨씬 간단하게 구현할 수 있으며, 즉각적으로 가장 큰 성능 향상을 기대할 수 있다.
  • 외부 서비스의 데이터가 자주 바뀌지 않을 것이라는 합리적인 가정하에 가장 비용적으로 효율적인 해결책일 수 있다. → 특히 현재 설문은 진행 중인 상태에서는 수정이 불가능하기 때문에 더욱 캐시가 용이하다.
  • 외부 API의 변동 지연(P95/P99)이 설문 제출 응답 지연으로 전이되는 것을 차단할 수 있다. </aside>

1. 메모리 산정/용량 예측

<aside>

전체 필요 메모리 산정 방법

• 필요 메모리 ≈ 키 수 × (평균 값 크기 + 평균 키 크기 + Redis 오버헤드) × (복제 계수) ÷ (1 − 여유율)
• 운영 권장 여유율(헤드룸): +30~50%. (조밀한 캐시에서 파편화/버퍼/피크 대비)

평균을 문항 20개(객관식 10개) 라고 가정한 샘플의 실제 측정한 메모리 크기 2112 bytes(약 2.06KB)

예상 동시 키 수를 50rps x TTL(60s)로 추정한다고 가정하면 동시 보관 키 수는 약 3000개

여유율: 40%로 잡으면, 2112 x 3000 ÷ 0.6 = 10,560,000bytes ≈ 10.08MB

maxmemory = 16MB(최소), 32MB(여유)

</aside>