[기여도]
- 백엔드 개발자(본인), 프론트엔드 개발자, 프로덕트 디자이너
[문제]
- 글쓰기에 어려움을 겪는 사용자 VOC 지속적으로 인입, 임시저장 기능이 존재하지만, 도중 이탈 시 글 저장되지 않음
[어려웠던 점과 극복 방법]
- 웹소켓 사용 여부에 대한 고민
- 문제: 웹소켓을 사용하면 실시간 저장이 가능하지만, 커넥션 유지 비용 및 별도 상태 관리 구현의 복잡성이 발생
- 극복: 웹소켓 대신 REST API를 사용해 특정 주기(3초)로 저장 요청을 처리하도록 설계 → 부하 테스트 결과, REST API 기반의 호출이 성능과 유지보수 측면에서 적합하다고 판단
- 부하 분산 및 자동저장 내역 저장을 위한 MongoDB 활용
- 문제: RDB에 자동저장된 글 내역이 쌓이며, 정상적으로 발행된 글이 저장되는 테이블에 쓰레기 값이 많아지기 시작함
- 극복: 저장소 분리하여, MongoDB (NoSQL) 안에 저장
- 잦은 API 호출로 인한 서버 부하 우려
- 문제: 글 자동저장 기능을 추가할 경우, 사용자 입력 중 짧은 간격으로 저장 요청이 발생해 서버 부하가 증가할 가능성이 있었음
- 극복:
k6를 사용해 부하 테스트를 진행, 호출 간격 및 서버의 최대 처리 용량을 측정하여 성능 안정성을 확인. 최적의 호출 주기를 설정 (3초)
서버 리포트
동시접속자 1000명이 연속 자동저장 1000회 수행 시나리오 시, 서버 리소스 모니터링 결과
[해결방안]
- 글 자동저장 기능 제공
- 사용자 입력 중 일정 간격(3초)으로 자동 저장이 진행되도록 API 설계
- 프론트엔드에서 사용자 이탈 시에도 서버로 마지막 데이터 전송
- 저장 완료 및 실패 상태를 사용자에게 알림
- 기술 선택 근거
- REST API를 사용한 이유
- 서버와 클라이언트 간 커넥션 유지 비용 절감
- 웹소켓 대비 더 단순한 구현 및 유지보수 용이
- 서버 부하 테스트 결과, 일정 주기의 REST API 호출이 적합
- MongoDB를 사용한 이유
- 부하 분산 : 글쓰기 동시접속자가 많은 상황에서 RDB에 쓰기 요청이 과도하게 몰릴 위험이 있음
- 목적에 맞는 활용 : 데이터 무결성이 보장되지 않아도 되는 데이터를 RDB에 저장하는 것이 사용 목적에 맞지 않았음
[결과]
- 글쓰기 중 이탈한 사용자 VOC 80% 감소 (10개 → 2개)
- 자동저장 기능 도입 후 사용자 이탈 후에도 작성 글이 복구되었다는 긍정적 피드백 다수 확보
- API 호출 주기 최적화 및 부하 테스트를 통해 서버 안정성 확보
[활용기술]
- Java, Spring Boot, JPA, QueryDSL, MongoDB