Redis in MSA 특강

개요

인메모리(in-memory) 스토리지로 데이터를 메모리에 저장해 빠른 읽기/쓰기가 가능
다양한 데이터 구조(String, Hash, List, Set, Sorted Set 등) 지원
캐싱, 세션 관리, Pub/Sub, 분산 락, 작업 대기열 등 MSA에서 다양한 용도로 활용

데이터 지속성

스냅샷(RDB, Snapshot)

주기적으로 전체 데이터를 덤프
스냅샷 주기 사이에 장애가 발생하면 일부 데이터 유실 위험 존재

AOF(Append-Only-File)

모든 쓰기 명령을 파일에 순차적으로 기록해 장애 발생 시 복구 가능성 증가
재시작 시 모든 쓰기 명령을 재실행해야 하므로 복구 시간이 오래 걸릴 수 있음

Redis와 MSA 활용

캐싱
세션 관리
작업 대기열(Queue)
Pub/Sub
- 구독자가 없으면 메시지가 소멸되므로 주의
분산 락(Distributed Lock)
- 동시성 제어, 데이터 정합성 확보를 위해 Redis 사용
- Redisson 라이브러리 등 활용 가능

운영 시 고려사항

데이터 유실 방지
- 스냅샷과 AOF의 장단점을 고려해 혼용 설계
Fail-over
- Sentinel 구성
  - 마스터 장애 시 센티널이 감지, 레플리카를 새로운 마스터로 승격
- Cluster 구성
  - 3대 이상의 마스터 노드가 필요한 클러스터 환경에서 고가용성 확보
모니터링
- 메모리 사용량, 연결 수 등의 지표를 모니터링하며 장애 대응 방안 마련

진행 상황

중간발표 이후 리팩토링(리팩톤)

중간발표 직후 3일 동안 리팩톤 진행한다고 한다. 팀별로 최소 한, 두 가지 개선사항을 선정해 리팩토링 및 개발을 진행하게 된다.

중간 발표 자료 준비

기술적 의사결정 소재

JSON 기반 템플릿 DB 고도화
Kafka 메시지 이벤트 리팩토링 (알림 정보 및 종류 변경 고려)
단순 Slack 알림에서 다양한 알림 시스템으로 확장 (Kafka 적용, 책임 분리)
연락처 데이터(소비자/레스토랑) 처리 시점 검토로 데이터 불일치 최소화
DI/IoC를 활용한 인터페이스 도입으로 레이어 간 역류 문제 방지

도전 계획 소재

Config 서버 적용
application.yml 분리 후 Config 서버에 적용해 무중단 배포 가능
Actuator 설정
Spring Boot Actuator를 통한 모니터링 지표 수집 및 헬스 체크
권한 적용
사용자 권한 및 인증/인가 메커니즘 구현
유저 및 가게 연동 통합 테스트
실제 시나리오 기반 통합 테스트 진행
템플릿 Redis 적용
템플릿 캐싱을 통한 성능 향상 및 Redis 최적화
알림 발송 후 히스토리 상태 반영
메시지 발송 결과를 히스토리 서비스에 기록 (발송 여부, 실패 시 에러 기록)
서비스 이름 변경
알림 서비스 → 히스토리 서비스 슬랙 서비스 → 메시징 서비스
Fallback 처리 기능 추가
슬랙 발송 실패 시 이메일로 재발송하는 등 재시도 로직 및 서킷 브레이커 사용 고려