SJH

문제 해결 포트폴리오 / 실시간 채팅 / 조회 성능

측정 완료Realtime Chat

채팅방 조회 N+1 제거

채팅방 조회 API의 N+1 쿼리를 제거해 RPS 937→1,598, p95 212.85ms→149.22ms로 개선했습니다.

RPS

937 → 1,598

p95

212.85ms → 149.22ms

Query

2N+1 → 1

해결 키워드JPQL ProjectionQuery Shapek6
프로젝트
Realtime Chat
참여
개인 / BE 1
기술
Java · Spring Boot · WebSocket · Kafka · Redis

문제 구간 아키텍처

채팅방 조회 API의 2N+1 쿼리 경로를 1회 조회 경로로 줄인 Before/After 아키텍처
채팅방 목록 조회에서 반복 쿼리로 증가하던 DB 접근 경로를 1회 조회/projection 경로로 줄인 Before/After 구조입니다.

문제

  1. 채팅방 목록 조회에서 방 수에 비례해 쿼리가 늘어나 API 응답 시간이 악화될 수 있었습니다.
  2. 실시간 채팅 프로젝트라도 사용자는 먼저 방 목록 조회와 재접속 동기화 API에서 지연을 경험합니다.
  3. WebSocket 연결 성공과 실제 메시지 전달 지연은 다른 지표이므로 성능 claim을 분리해야 했습니다.

해결

  1. 채팅방 조회 경로의 N+1 쿼리를 제거해 필요한 데이터를 1회 쿼리로 조회하도록 재구성했습니다.
  2. 조회 API 개선 수치, WebSocket 연결 스모크 테스트, 50/500/1,000-user receiver matrix local scenario, by-room denominator guard를 서로 다른 근거 상태로 분리했습니다.
  3. send-to-receive latency와 delivery completeness는 local scenario와 production/mixed benchmark를 분리해 과장을 피했습니다.

결과

  1. 채팅방 조회 API 처리량을 937 RPS에서 1,598 RPS로 개선했습니다.
  2. p95 응답 시간을 212.85ms에서 149.22ms로 낮췄습니다.
  3. N+1 쿼리를 2N+1회에서 1회로 제거했습니다.

검증 근거

채팅방 조회 API RPS

측정 완료

937 -> 1,598 RPS

p95 응답 시간

측정 완료

212.85ms -> 149.22ms

N+1 쿼리 제거

측정 완료

2N+1 queries -> 1 query

구현 포인트

  1. 조회 성능 사례는 WebSocket delivery 성능과 분리해 API 병목 개선으로 설명합니다.
  2. 채팅방 목록 조회는 N+1 제거와 fetch/projection 전략을 중심으로 답변할 수 있게 정리했습니다.
  3. WebSocket delivery와 mixed traffic 세부 artifact는 GitHub README/docs 근거로 분리했습니다.

세부 테스트, guard, raw artifact는 GitHub README와 docs에 정리했습니다.

GitHub 근거 보기