- 프로젝트명: DaPanDa
- 팀명: 다판다
- 개발 기간: 2025.06.30 (월) ~ 2025.08.07 (목)
가족·지인 간 통신 데이터를 비공식적으로 나누는 현실은 번거롭고 불투명하며, 사용하지 못한 데이터는 소멸되기 쉽습니다.
DaPanDa는 이러한 문제를 해결하고 데이터를 자산처럼 자유롭게 사고팔 수 있는 공식 거래 플랫폼을 구축하고자 시작되었습니다.
단순한 거래를 넘어 데이터, 핫스팟, 와이파이 등 다양한 네트워크 자산을 등록·판매할 수 있도록 하여, 개인부터 소상공인까지 참여 가능한 디지털 공유 생태계를 지향합니다.
- SpringSecurity, OAuth2, JWT 기반 인증/인가 시스템
- 데이터 / 와이파이 상품 등록 및 실시간 거래
- 실시간 채팅 기능 및 거래 알림
- PG 연동 결제 + 캐시 충전 및 환불
- 리뷰 등록 / 신고 접수
- 시스템 모니터링
기획에 대한 자세한 내용은 팀 README.md를 확인해주세요 😊
| Category | Technologies |
|---|---|
| Backend |               |
| Infra / DevOps |    |
| Monitoring |    |
| Collaboration |     |
- ALB(애플리케이션 로드밸런서)와 연동하여 트래픽 증감에 따라 EC2 인스턴스 수를 자동으로 조절
- 사용량 급증 시 확장, 사용량 감소 시 축소를 통해 비용 효율 및 확장성 확보
- AWS CodeDeploy의 Blue/Green 전략 적용
- 신규(그린) 환경으로 트래픽을 전환해 배포 중에도 기존(블루) 환경 서비스가 중단되지 않도록 보장
한정된 재고를 판매하는 서비스에서는 고객이 거의 동시에 구매 버튼을 누를 때 재고 오버셀링, 이중 결제 등의 심각한 오류가 발생할 수 있음
구매나 결제 로직은 데이터 일관성 확보가 최우선이라 판단 → 비관적 락 적용
- 락을 적용하기 전에는 100건의 동시 요청에서 2건의 구매 발생
- 락을 적용한 후에는 100건의 동시 요청에서 1건의 구매 발생
락 대기 시간이 일부 늘어났지만, 평균 응답 시간은 200ms 이내로 유지되었고 서비스 안정성 확보라는 목표 달성
- 기존 구조에서는 모든 조회 요청마다 DB를 직접 호출하는 방식으로 동작
- 특히 상품 목록은 사용자 진입 시마다 반복적으로 호출되며 결과적으로 다음 문제가 발생
- DB 쿼리 부하 증가
- 응답 지연(Latency)
- 실사용자 테스트 당시 약 70명의 사용자, 50개의 상품 게시물이 존재하던 상황에서 모바일 데이터 상품과 와이파이 상품 각각 최대 780ms, 2.39s 의 응답 지연이 발생
- 또한 거리 기준 오름차순 정렬 결과는 사용자의 위도/경도에 따라 매번 달라지기 때문에 일반적인 의미에서의 캐싱(“모든 사용자에 대해 한 번만 계산 후 계속 재사용”)은 읽기 비용(네트워크+메모리 접근)조차 더 크거나 같을 수 있다고 판단
- 캐싱 전략 중 Cache-Aside 패턴 도입
- 와이파이 상품의 거리 기준 오름차순 정렬은 “동일 사용자” 정도의 짧은 시간(10~30초) 내 재요청을 대비해 캐시해두고 TTL(5분)이 지나면 자동 만료되도록 설정
- 기본 TTL은 30분, 와이파이 상품의 거리 정렬 캐시는 5분으로 설정
모바일 데이터 상품과 와이파이 상품 모두 평균 응답 시간, TPS 개선 확인
-
1차 개발에서 단일 서버 환경에서 인메모리 방식의 WebSocket STOMP 기반 채팅 시스템 구현
→ 오토스케일링에 의해 스케일 아웃 시, 서로 다른 서버로 트래픽이 나뉘어 사용자들 간의 채팅이 불가능한 문제 발생
Redis Pub/Sub 기능을 활용하여 통신 불가능 문제 해결
- 채팅 서버와 비즈니스 서버 분리
- 서버 간의 중계를 위한 Key-Value 방식 도입
- NoSQL 기반의 메시지 저장 방식, 인스턴수 증가에 따른 메시지 큐 도입 등 고려
- 사용자가 원하는
dataAmount만큼의 모바일 데이터를 최저 가격으로 구매하도록 하는 탐색 알고리즘 - 그리디 알고리즘을 변형하여 적용
- 기존 그리디 알고리즘은 한 번의 순회로 조합 결정
- 데이터 자투리 구매 알고리즘은 여러 그리디 경로를 비교해 더 나은 조합을 찾음
- 0.1 GB 단위로 최대 2.0 GB까지 존재하는 여러 개의 상품(Data Scrap) 중에서 조합을 찾아냄
- 최대 후보 조합 개수는 5개로 제한하여 성능 최적화
- 분산된 로그·메트릭 수집으로 장애 탐지 지연
- 수작업 로그 확인으로 운영 부담 증가
모니터링과 알림 시스템을 도입하여 시스템 장애를 사전에 감지하고 자동화된 알림으로 즉각 대응할 수 있는 신속·안정적 운영 체계를 확보
- 모니터링 포털에서 실시간 메트릭·로그 동시 조회 가능
- Slack 자동 알림으로 SSH 접속 없이도 이상 징후 즉시 인지
API 명세 도구로 Spring REST Docs를 채택함으로써 테스트 코드 작성 강제
→ 테스트 커버리지 80% 달성
더 자세한 내용은 Github Wiki를 확인해주세요
☺️
- 🔒 비관락 도입으로 상품 구매, 캐시 결제 동시성 처리
- 💨 Redis 캐싱을 통한 조회 성능 개선
- 💬 채팅 시스템 개발
- 🤖 데이터 자투리 구매 알고리즘
- 🚨 모니터링 시스템 도입 (feat. Slack 알림 연동)
- 🛠️ 기술 스택 선택 이유
- 🚀 인프라 설계
- 📑 Team Convention
 |
 |
 |
|
|
|