[3차 과제] 성능 테스트

[airoca]

✅ 성능 테스트 예정 항목 정리

QA 일정이 지연되며, 서버에 부하를 주는 성능 테스트를 실제로 수행하기는 어려웠지만, API 성능 개선 방향에 대해 정리하였습니다.

▶️ 피드 조회

• 문제 상황

  • 데이터 호출 빈도가 잦고, 다수의 JOIN 연산이 필요
  • 필터링 및 정렬 로직으로 인한 부하 증가

• 해결 방안

  • N+1 쿼리 문제를 해결하기 위해 페치 조인(Fetch Join) 또는 배치 처리 적용
  • 인기 피드나 정적 데이터를 캐싱하여 DB 부하를 줄임
  • 피드 조회 API를 전용 서버로 분리하여 트래픽 분산

▶️ 게시물 등록

• 문제 상황

  • 게시물을 등록할 때, 연관된 데이터(메뉴, 사진 등)를 삽입하는 트랜잭션 과정이 굉장히 긺
  • 또한, 게시물 등록 시 작성자를 팔로우하고 있는 사용자들의 피드에 해당 게시물을 추가하고, 작성자의 스푼 개수를 변동시키는 연쇄적인 작업이 존재함
  • 결과적으로, 게시물 등록 요청의 예상 처리 시간이 길기에 병목 지점이 될 것으로 우려됨

• 해결 방안

  • 게시물 등록 시, 정말 필수적으로 원자성이 보장되어야 하는 작업(게시물 연관 데이터 등록과 사용자 재화 개수 조정)만 트랜잭션으로 묶고, 사용자 피드 업데이트 등의 연쇄적인 작업은 트랜잭션 외부로 분리
  • 이 때, 부가 작업은 비동기 처리를 통해 스레드 병목 완화 (피드 추가 부분에서 이어 설명)

▶️ 게시물 등록 시 피드 추가

• 문제 상황

  • 팔로워가 많은 사용자가 게시물을 등록할 경우, 해당 게시물을 해당 사용자를 팔로우하고 있는 모든 유저들의 피드에 한 번에 업로드하려고 하면 병목이 발생한다.
  • 예를 들어, 팔로워가 1000만 명인 사용자가 존재할 경우, 피드 업데이트 과정이 과도하게 길어지고, 스레드 사용성을 낮춘다.

• 해결 방안

  • 피드 업데이트 과정에서 이벤트 큐를 부분적으로 사용(Spring MVC를 기본적으로 사용하되, 피드를 업데이트 하는 부분에서 이벤트 큐 사용)
  • 샐럽 사용자가 게시물을 등록 시 피드 업데이트를 즉시 전파시키지 말고, 이벤트 큐를 사용하여 점진적으로 작업 수행
  • 또다른 방법은 샐럽 사용자가 게시물을 등록하는 시점이 아닌, 해당 사용자를 팔로워하는 유저들이 실제로 피드를 "조회하는" 시점에 변경 사항을 업데이트 하는 것!