image.png

image.png

image.png

image.png

구분 내용
개요 농업인과 농업 전문가를 연결하는 매칭 플랫폼
디지털 커뮤니티를 통해 소규모 영세농업의 공동농업을 활성화하고 전국의 농업 전문가를 연결하며,
**농업 데이터**를 기반으로 **체계적인 농업 서비스**를 제공 |

| 참여 인원 | 10명(PM 1명, 디자이너 1명, 백엔드 4명, 웹 프론트엔드 4명) | | 전체 기술 스택 | Backend: JAVA, SpringBoot, JPA, QueryDSL, SpringSecurity, JWT, CoolSMS DataBase: MySQL, Redis Messaging: RabbitMQ, WebSocket, STOMP DevOps: Docker, AWS(EC2, ALB, Rout53, ACM, RDS, S3), Nginx, GitHub Actions | | 핵심 기여 | 1. Redis 기반 검색 기능 구현: 작물 자동완성·추천·최근 검색·검색어 삭제 기능을 설계하여. 빠른 검색 경험 제공 2. RabbitMQ 기반 실시간 채팅 구현: 메시지 브로커를 도입해 채팅 메시지의 유실을 방지하고, 입장·퇴장·텍스트 전송을 메시지 타입별로 분리 3. Spring Security 역할 기반 접근 제어: 농업인·전문가 권한을 실시간 전환 가능하도록 설계하고 역할 별 접근 제어 적용 4. CI/CD 및 배포 환경 구축: Docker와 AWS 인프라를 활용해 컨테이너 기반 배포 환경을 구성하고, GitHub Actions를 통해 CI/CD 파이프라인 구축 5. 백엔드 팀장 역할 수행: API·ERD 설계, Swagger 문서화 및 백엔드 개발 방향과 일정 관리 주도 | | 문제 해결 | 1. 프로젝트 완료 후, 개인 학습 차원에서 동시 사용자 1,000명 규모의 부하 테스트 수행(k6·Prometheus·Grafana) • 홈 화면에서 카테고리별 인기 게시글 3건을 조회하는 API를 대상으로 용량 테스트를 수행함 ****→ QueryDSL 기반 단일 집계 쿼리로 리팩토링하여 N+1 제거 - Peak RPS: 155 → 312 req/s (약 101% 향상) - 평균 RPS: 142 → 268 req/s (약 88% 향상) - 평균 응답 시간: 2.13s → 1.03s (약 51.6% 단축) → HikariCP 커넥션 풀 및 Tomcat 스레드 튜닝 적용 - Peak RPS: 312 → 358 req/s (QueryDSL 대비 약 14.7% 추가 향상) - 평균 RPS: 268 → 300.49 req/s (QueryDSL 대비 약 12.1% 추가 향상) - 평균 응답 시간: 1.03s → 904.13ms (QueryDSL 대비 약 12.2% 추가 단축) → Redis 캐시(TTL 60초) + 트랜잭션 커밋 이후 이벤트 기반 캐시 무효화 적용 - Peak RPS: 155 → 498 req/s (초기 대비 약 221% 향상) - 평균 RPS: 142 → 401 req/s (초기 대비 약 182% 향상) - 평균 응답 시간: 2.13s → 630.89ms (초기 대비 약 70.4% 단축) → 최종적으로 총 77만 건 이상 요청을 에러율 0.009%로 처리하며 **시스템 처리 용량을 약 2.8배 확장

  1. 채팅 메시지 조회 시 N+1 문제 제거** • 메시지 조회 후 서비스 단에서 전송자 정보에 접근하면서, 메시지 수만큼 추가 쿼리가 발생 → Lazy 연관 접근을 제거하고 QueryDSL 기반 단일 조회 쿼리 구조로 리팩토링 → 메시지 수가 증가해도 쿼리 수가 1회로 고정 채팅 메시지 무한 스크롤 API의 성능 안정성 확보

3. Service 계층 책임 혼재 및 트랜잭션 비효율로 인한 계층 분리 • 조회와 수정 로직이 단일 Service에 혼재되어 불필요한 트랜잭션 범위 확장 및 성능 저하 발생 → Service 계층을 CommandService(쓰기) / QueryService(읽기) 로 명확히 분리 → QueryService는 조회 전용으로 구성하고 @Transactional(readOnly = true) 적용 → CommandService는 생성·수정·삭제 로직만 담당하며 필요한 범위에만 트랜잭션 적용 → 조회·변경 책임을 분리함으로써 Service 계층 가독성과 유지보수성을 개선하고, 불필요한 트랜잭션 오버헤드 감소 | | GitHub 링크 | 개발 레포지토리: https://github.com/Farm-On/BE 부하테스트 레포지토리: https://github.com/mmije0ng/FarmON_BE_Refactor | | 배포 링크 | https://farm-on.netlify.app (서버 비용으로 인해 현재 서비스 중단) |