<aside> 👋
안정적인 서비스를 위해 부하테스트와 모니터링을 통해 서버 리소스(메모리) 사용량을 30% 감축하였고, 빈번히 호출되는 API의 평균 소요 시간을 95% 감축시켰습니다.
또한 테스트를 중요시 여겨 테스트 커버리지를 90% 이상 달성한 경험이 있으며 사용자 요청 중 동시성 문제가 있는 로직을 찾아 해결하였습니다.
</aside>
<aside> 💡 저당, 글루텐 프리 등 건강한 베이커리를 찾는 사람들을 위해 판매처를 모아주고 추천해 주는 플랫폼
</aside>
참여 인원(명): Back-end(5), Front-end(4), PM(2), Design(2), Marketing(3) 총 17명
담당 파트: Back-end 파트
사용 기술: Java, Spring, Querydsl, Spring Security, OAuth2, MariaDB, Redis, Github Actions, Docker Compose, NCP
사용자 이벤트 기반 게시글 랭킹 시스템 개발 및 성능 개선(기여도 100%)
사용자 위시리스트 기능 개발 및 성능 개선(기여도 100%)
게시글 랭킹 조작 방지 시스템 개발(기여도 100%)
개발 서버 자동 배포 파이프라인 개발(기여도 100%)
<aside> 💡
DEV 환경에서 테스트를 하던 도중 서버의 메모리 자원을 초과 사용하여 서버가 다운되는 현상이 발생
</aside>
메모리 초과 문제 원인을 서버에서 사용하는 데이터가 제대로 정리되지 않거나 특정 요청이 너무 많은 데이터를 생성한다고 판단
Jmeter 기반의 API 부하테스트를 가하는 동시에 모니터링 도구(VisualVM) 를 사용해 서버의 메모리 상태를 확인하는 작업 실시
→ 특정 API를 호출하는 과정에서 사용된 객체가 삭제되지 않고 메모리 자원을 계속 차지하는 것을 확인
해당 객체가 LinkedHashMap 타입의 객체인 것을 확인, LinkedHashMap은 강한 참조 관계로 삭제가 잘 안되는 데이터 타입인 것을 확인하고 사용이 완료된 LinkedHashMap을 삭제해주는 기능을 추가하여 메모리에 누적되지 않도록 조치
heap 메모리 초과로 인해 서버가 다운되는 문제 발생
LinkedHashMap을 삭제 도입한 후 서버의 메모리 사용량 확인
→ 전체 메모리 리소스 중 약 30% 사용량 감축 확인
<aside> 💡
한 사람당 한 게의 게시글만 위시리스트(게시글 찜 기능)에 담을 수 있게 정책이 수립되어 있지만 한 사람 당 두 개 이상의 게시글을 위시리스트 DB에 담겨 조회 시 오류가 발생
</aside>
프론트엔드 팀에 확인 후 찜 누르기 버튼을 광클할 경우 위시리스트 추가 API가 연속으로 호출되는 경우가 발생, 연속 호출 시 동시성 문제가 발생했을 거라 추측하고 테스트 코드를 작성
→ 실제로 동시에 호출될 경우 검증로직을 통과하여 한 명이 같은 게시글을 여러 개 찜할 수 있는 경우가 발생
이미 게시글에 찜한 이력 확인 후 게시글 찜 정보를 저장하는데 저장 과정에서 먼저 발생한 찜 요청이 끝나고 데이터가 저장이 되기 전에 동시에 진행한 요청이 이미 찜이 되었는지 검증하는 로직을 실행하면 찜 데이터가 없다고 판단하고 검증 로직을 통과하는 문제 확인
DB에 한 사람 당 한 게시글만 찜할 수 있는 제약 조건(유니크 제약 조건)을 걸고 이를 위배하고 요청할 시 서버에서 커스텀하게 만든 예외가 발생하도록 처리
검증과 데이터 저장을 하는 동안 다른 동일한 요청을 처리할 수 없도록 잠금을 걸 수도 있으나(이 경우에는 Named Lock, Distributed Lock 등)
제약 조건과 예외처리만 진행하면 검증 로직 자체가 사라져도 돼서 DB에 데이터가 있는지 확인하는 쿼리를 보내지 않아도 된다.
즉 DB 네트워크 통신을 1회 줄이면서도 동시성 문제를 간단히 해결할 수 있어 제약 조건을 거는 방식을 선택
두 개의 동일한 찜 요청을 동시에 진행할 때 테스트 실패 확인
같은 로직을 동시에 실행 시 문제점 확인