Skip to content
김동환 edited this page Aug 20, 2024 · 18 revisions

리뷰

캠핑장 리뷰 조회 5분 간격

users 100

image image (1)

users 200

image (2) image (3)

users 300

image (4) image (5)

users 400

image (6) image (7)

users 500

image (8) image (9)

backend ec2

스크린샷 2024-08-16 오후 6 10 48

lb 대상 응답 시간

image (10)

db ec2

스크린샷 2024-08-16 오후 6 11 38

lb 요청

image (11)

리뷰 수정 5분 간격

users 100 / 1

image image (1)

users 100 / 10

image (2) image (3)

users 200 /10

image (4) image (10)

users 300 /10

image (5)
image (6)

backend ec2

image (7)

lb 대상 응답 시간

image (8)

db ec2

image (9)

FAILURE

image (12) image (13)

  • 이슈
    • RPS가 저조함
    • USER 200부터 실패율이 크게 증가 ( 501, 504 에러 )
    • DynamoDB 처리에 문제 발생
    • 응답 시간이 들쭉날쭉 함
  • 분석
    • 트랜잭션 어노테이션이 dynamoDB에서 온전하게 작동하지 않은 거 같음
    • 한 번의 요청에 리뷰, 마이리뷰, 별점평균 총 3개의 테이블 연산이 포함된 것도 부하의 원인인 거 같음
    • 조회 시 생성일로 정렬하는데, 생성일은 인덱스 설정이 되지 않아 조회 성능이 떨어지는 거 같음
  • 개선 방안
    • DynamoDB의 TransactWriteItems 또는 TransactGetItems 작업 등을 시도
    • existsByUserIdAndCampId 메서드 성능 개선을 위한 userId, campId 복합 인덱스 고려
    • 캐시 도입해서 캐시에서 값 변동 후 db 업데이트는 나중
    • 리뷰 수정 과정에서 실행되는 각 과정의 실행 시간을 측정하여 병목 지점 파악
    • 업데이트 요청 시 요청된 값들이 db나 캐시에 저장된 값과 일치하다면 리턴시키기
    • 리뷰 아이디와 생성일 복합 인덱스 설정
나의 리뷰 조회 5분 간격

users 100 / 10

image image (1)

users 200 / 10

image (2) image (3)

users 300 / 10

image (4) image (5)

users 400 / 10

image (6) image (7)

backend ec2

image (8)

lb 대상 응답 시간

image (9)

db ec2

image (10)

lb 요청

image (11)

  • 이슈
    • 응답속도가 높아 rps가 저조함
    • 유저가 많아질수록 응답속도도 높아
    • cpu 모니터링 확인 결과 backend ec2의 cpu 점유율이 테스트 초반부터 100% 도달된 상태였음
  • 분석
    • 사용자에게 3988개의 캠핑장 리뷰를 작성해놔서 3988개의 reviewId로 Review 테이블에서 모든 값을 조회하여 페이징 처리를 하는 게 오래걸리는 거 같음
    • cpu 점유율이 시작부터 100%에 도달해있었다는 것도 원인인 거 같음
  • 개선 방안
    • cpu 점유율이 낮아진 거 확인 후 다시 테스트 해봐야 할듯
나의 리뷰 조회 5분 간격 (cpu 점유율 확인 후 다시 진행)

users 100 / 10

image image (1)

backend ec2

image (2)

lb 대상 응답 시간

image (3)

db ec2

image (4)

lb 요청

image (5)

  • 분석
    • 테스트 실행 시 user 100명에서도 서버와 db cpu 점유율이 높은 편임이 확인 됨
    • 이게 작성된 리뷰를 조회하는 과정에서 발생하는 것인지 확인하기 위해 리뷰가 적은 유저를 대상으로 다시 한 번 테스트 진행
나의 리뷰 조회 5분 간격 (작성 리뷰 1개인 유저 대상)

users 100 / 10

image image (1)

users 200 / 10

image (2) image (3)

users 300 / 10

image (4) image (5)

users 400 / 10

image (6) image (7)

users 500 / 10

image (8) image (9)

backend ec2

image (10)

lb 대상 응답 시간

image (11)

db ec2

image (12)

lb 요청

image (13)

  • 이슈
    • rps 100이 넘어가면서 응답 속도가 불안정해지고 유저수가 늘어나도 200을 못넘음
    • rps가 200에 근접하면서 응답 속도가 크게 튀기 시작하고 유저수가 500명일 떄 응답속도가 현저히 느려짐
    • cpu 점유율은 작성된 리뷰가 많은 유저에 비해 안정적임
  • 분석
    • 작성된 리뷰 수가 많을 때에 비해 cpu 점유율이 안정적인 걸로 보아 모든 리뷰를 페이징해 가져오는 현재 로직이 서버에 부하를 많이 주는 거 같음
    • 한 페이지에 필요한 것보다 훨씬 많은 데이터를 db에서 받아옴
    • 등록 리뷰가 많아지면 리뷰 테이블에서 조회 시 IN절에 사용하는 reviewId 리스트의 크기가 커짐
    • 리뷰가 하나 뿐인 유저의 리뷰를 불러오는 요청도 요청 수가 늘어나면서 응답 속도가 불안정해지는 건 보아 서버의 처리 용량이 문제인지 페이징 로직이 문제인지는 테스트를 더 진행해봐야 알 것 같음
  • 개선 방안
    • 리뷰 등록할 때마다 리스트로 저장해서 리스트 자체로 조회하는 기존 로직 개선 고려
    • 캐시 적용 고려

Clone this wiki locally