[🔥TroubleShooting - MoodBuddy🔥] Redis 캐시 전략 너무 오버스팩...?

📌 프로젝트 소개

팀원 : PM(1) / Design(1) / Frontend(2) / Backend(3)
기간 : 2024.03 ~ 2025.03
링크 : https://github.com/M-ung/MoodBuddy_Server
서비스 내용 : 사용자가 작성한 일기를 바탕으로 감정 분석하는 웹 서비스
소통 : GitHub, Slack, Notion, Discord

---

🔥TroubleShooting🔥

Problems

일기 목록 조회 속도를 높이기 위해서 Redis 캐시를 적용했다. 하지만 단순히 응답 조회를 높이기 위해 Redis를 적용하여, 오히려 관리 측면에서 부담을 느꼈다.

또한, 사용자 id와 페이지 번호 조합으로 캐시 키를 생성하다 보니, 사용자 수와 페이지 수에 비례해 캐시 키가 급격히 증가하게 되었다. 이 역시... 메모리 자원을 지속적으로 소비하는 원인이 되었다.

결국 사용자가 대량으로 몰릴 가능성이 낮은 기능에 Redis를 연결하면서 오히려 개발 및 운영 비용을 높이는 요인이 되었다.

아래 k6 결과는 Redis 캐시를 적용했을 때의 결과이다.

📍 일기 목록 조회 테스트 결과 (Redis Cache 적용)

---

How

1. Redis 캐시 설정을 제거하고, Spring Cache를 적용.
2. 일기 목록 조회용 테이블을 따로 만들어서 조회를 할 때 해당 테이블에만 접근하도록 구현.
3. 일기 목록 조회용 테이블에 자주 조회되는 인덱스 적용.

---

Process

아래와 같이 일기 목록 조회에만 필요한 테이블을 따로 만들었다.

Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(
        name = "diary_query",
        uniqueConstraints = @UniqueConstraint(columnNames = {"userId", "date"}),
        indexes = {
                @Index(name = "idx_id_user_Id_mood_buddy_status", columnList = "diary_id, user_id, mood_buddy_status"),
                @Index(name = "idx_user_Id_mood_buddy_status_date", columnList = "user_id, mood_buddy_status, date")
        }
)
public class DiaryQuery {
    @Id
    @Column(name = "diary_id")
    private Long diaryId;

    @Column(name = "title", nullable = false)
    private String title;

    @Column(name = "date", nullable = false)
    private LocalDate date;

    @Column(name = "content", nullable = false, columnDefinition = "text")
    private String content;

    @Column(name = "user_id", nullable = false, columnDefinition = "bigint")
    private Long userId;
    
    @Column(name = "thumbnail", columnDefinition = "text")
    private String thumbnail;

    @Enumerated(EnumType.STRING)
    @Column(name = "emotion")
    private DiaryEmotion emotion;

    @Enumerated(EnumType.STRING)
    @Column(name = "subject")
    private DiarySubject subject;

    @Enumerated(EnumType.STRING)
    @Column(name = "mood_buddy_status")
    private MoodBuddyStatus moodBuddyStatus;
}

그리고 yml 설정을 아래와 같이 변경하여, Spring Cache로 변경했다.

spring:
  threads:
    virtual:
      enabled: true
  cache:
    type: simple

---

Test Scenario

📌 부하 증가 단계

• 2분 동안 500명의 사용자가 증가
• 2분 동안 1000명의 사용자가 증가
• 2분 동안 1000명 유지 (최대 부하)
• 2분 동안 500명으로 감소
• 2분 동안 0명으로 감소
• 총 10분 테스트 진행

📌 테스트 요청

• 1000명의 사용자 중 랜덤으로 로그인 시도
• 응답에서 accessToken을 추출
• accessToken을 가지고 getDiaries API 요청
• 총 50개의 일기를 가져오며, 페이지당 20개씩 요청
• 각 요청 후 1초 동안 sleep

📌 테스트 통과 기준

• 응답 속도: 95% 이상의 요청(p(95))이 100ms 이하로 처리되야 함.
• 에러율: 전체 요청 중 1% 미만만 실패

---

Result Analysis

📍 일기 목록 조회 테스트 결과 (Spring Cache 적용)

지표	Redis Cache 적용	Spring Cache 적용	개선율
총 요청 수 (http_reqs)	474,188	473,652	0.11% 감소
응답 시간 평균 (http_req_duration avg)	12.33ms	13.2ms	7.04% 증가
응답 시간 90퍼센트 (p(90))	23.89ms	27.01ms	13.04% 증가
응답 시간 95퍼센트 (p(95))	33.22ms	38.22ms	15.05% 증가
대기 시간 평균 (http_req_waiting avg)	12.26ms	13.13ms	7.1% 증가
최대 응답 시간 (http_req_duration max)	979.22ms	2.08s	112.4% 증가

---

Thoughts

이번 테스트는 현실보다 훨씬 높은 부하인 1000명의 동시 사용자(VUs)를 가정한 환경에서 진행되었다.
이러한 조건은 실서비스에서 자주 발생하진 않지만, 최악의 상황을 가정한 성능 안정성 평가로는 의미가 있다.

Spring Cache는 Redis Cache에 비해 평균 응답 시간과 최대 응답 시간에서 다소 느린 결과를 보였지만, 극단적인 부하 환경에서 나타난 차이이며, 실제 운영 상황에서는 그 차이가 체감될 수준은 아니라고 생각한다.

📍 Spring Cache 적용으로 얻은 이점

• Redis 인프라 운영 부담 제거
• 네트워크 I/O/직렬화 비용 감소
• 설정 간소화

결과적으로 속도는 약간 낮아졌지만, 운영 비용을 줄였다는 점에서 충분히 좋은 선택이라고 생각한다.

---