📚 Book_wave

🔖 서비스 개요

• 서비스 기획 배경: 중고책 거래는 지속 가능한 소비를 촉진하고 환경 보호에 기여합니다. 이는 책을 재사용하여 자원 소모를 줄이고, 더 많은 사람들이 저렴하게 지식을 접할 수 있도록 돕습니다. 따라서 중고책을 위한 신뢰할 수 있는 플랫폼을 구축하여 사용자들에게 더 나은 경험을 제공하는 것이 필요합니다.
• 서비스 기대 효과: 중고책 거래는 친환경 소비 문화를 확산시키고, 독서와 학습의 기회를 확대합니다. 환경 보호와 지식 공유를 결합한 지속 가능한 모델로 사회에 긍정적인 영향을 미칩니다.

🔗 주요 기능

1️⃣ 간편 회원가입 및 로그인

• 카카오 소셜 로그인 연동으로 회원가입 및 로그인 절차 간소화
• OAuth 2.0 기반 인증 및 보안 강화

2️⃣ 정렬 및 무한 스크롤 리스트

• 다양한 정렬(���신순, 인기순, 가격순 등) 기능 제공
• 무한 스크롤 리스트로 사용자 경험 향상

3️⃣ 즐겨찾기 및 찜 기능

• 주요 검색어 즐겨찾기 등록으로 빠른 매물 탐색 지원
• 찜 기능을 통해 관심 매물의 상태 추적 가능

4️⃣ 알림 시스템

• 즐겨찾기 및 찜 목록에 대한 실시간 알림 제공
• 거래 상태, 가격 변동 등 주요 이벤트 알림

5️⃣ 데시벨 등급 사용자 분류

• 거래 활동을 기반으로 사용자를 데시벨 단위로 분류
• 책을 메인 콘텐츠로 하여, 똑똑한 동물(돌고래) 컨셉의 등급 시스템 적용

6️⃣ 사용자 간 채팅 및 거래 관리

• 판매자와 구매자 간 1:1 채팅 기능 제공
• 거래 상태(진행, 완료 등) 저장 및 관리

7️⃣ 정가 및 가격 비교

• 도서 API 연동을 통한 실시간 정가 및 시세 정보 제공
• 다양한 매물 간 가격 비교 기능 지원

---

서비스 아키텍처

🌈 개선 사항

1️⃣ 닉네임 조회 방식 개선 -

📌 문제 상황

• 1대1 채팅 진입 시, 사용자의 member id를 가지고 다시 닉네임을 조회해야하는 불필요한 DB 접근이 필요.
• 매번 인증 단계에서 추가적인 DB 접근으로 병목 현상이 발생.

✅ 개선 방향

• token claim에 사용자 닉네임 추가 : 사용자의 닉네임을 access token의 claim에 포함시켜, DB에 대한 불필요한 조회를 최소화.
• token 헤더의 크기 증가 에 대한 해결 : 토큰 헤더의 크기는 약 31바이트 증가(920바이트 → 951바이트)했지만, 이는 DB 접근을 줄이는 것에 비해 미미한 오버헤드.

---

2️⃣ 채팅 기능 고도화 ( 메세지 큐 적용 ) -

📌 문제 상황

• 단일 서버에서 약 100명의 유저가 동시에 1000개의 메세지를 같은 채팅방에 보낼 경우, 트래픽 누적으로 인한 HTTP 504 Gateway Timeout 발생

• 응답 시간 그래프가 주기적으로 0ms로 떨어지며 연결이 끊기는 것으로 보이는 현상 -> 서비스 불능 또는 응답 지연으로 해석 가능

  -> http/1.1의 라인 블로킹 및 stomp 세션 관리 및 리소스의 한계로 추정

✅ 개선 방향

• Netty-Websocket 및 RabbitMQ를 통해 성능 및 기능 비교 후 성능 고도화

1️⃣ Netty-Websocket

• HTTP/1.1의 한계를 극복하고, 더 낮은 레벨의 네트워크 제어를 통해 성능을 최적화하고자 Netty 프레임워크를 사용하여 WebSocket + STOMP 서버를 직접 구현 시도

📈

❗ 문제점

• STOMP 프로토콜 직접 구현 필요

  • 기존에 구현되어있는 모든 어노테이션으로 이루어진 STOMP 프로토콜 직접 구현 필요

• HTTP 핸드셰이크 -> WebSocket 업그레이드 -> WebSocketFrame -> ByteBuf (STOMP 코덱용) -> StompFrame (애플리케이션 로직용)으로 이어지는 인바운드 데이터 변환과 그 역의 아웃바운드 변환 과정에서의 복잡성

• ByteBuf의 참조 카운트 관리(retain(), release()) 미흡으로 인한 메모리 누수 가능성

-> Netty는 높은 유연성과 성능 잠재력을 제공하지만, STOMP와 같은 고수준 프로토콜을 직접 구현하는 것은 상당한 개발 시간과 Netty 내부 동작에 대한 깊은 이해를 요구함 학습 곡선이 매우 가파르고, 안정적인 구현까지 많은 디버깅 노력이 필요하여 현재 프로젝트의 자원과 일정을 고려했을 때 실질적인 성능 향상 측정 단계까지 나아가기 어려움

2️⃣ 메세지 큐

• WebSocket/STOMP 프로토콜 자체를 배제하고, 클라이언트와 ���버가 메세지 큐를 통해 직접 메시지를 주고받는 방식으로 변경하여 통신 안정성 및 성능 특성 평가
• 프로젝트 기간 및 학습 곡선을 고려하고, DeadLetterQueue 구현에 용이한 RabbitMQ 채택

**📈 **

-> 테스트 플로우상 테스트 툴이 publish -> consume 까지의 일렬의 과정을 다 받아야 응답 시간이 측정되기에 실제 시간과 상당한 차이 존재

❗ 문제점

• 각 채팅 채널에 대한 queue 선택 필요
  • 한 채팅방에 여러 사용자가 들어올 때, 사용자의 인원수 및 서버 스펙 고려 필요

** 성능 비교 **

기준	Netty-WebSocket	RabbitMQ
최대 TPS	70K/s (단일 서버)	50K/s (단일 노드), 클러스터링 시 확장
지연 시간	1ms~3ms	2ms~15ms
장애 복구	수동 구현 필요	DLQ/미러링큐 자동 복구
개발 복잡도	프로토콜 핸들러 직접 구현	스프링 통합으로 신속 적용
확장성	로드밸런서 추가 필요	클러스터 자동 확장
최적 사용 사례	초저지연 1:1 통신	복잡한 메시지 라우팅/재시도 필요 시

📉 개선 전

📈 개선 후

결론

• 메세지 상태 유지 및 이후 사용자와 서비스 확장에 따른 확장성 용이
• 또한 AMPQ (바이너리 프로토콜)을 사용하여 text 기반의 Stomp보다 작은 크기
• 메세지를 사용한 비동기 로직으로서 이후 서버 분리시 의존성 낮추고 결합성 높이기 용이

-> 메세지 큐를 통한 채팅 서비스로 변경