// projects/the-last-supper

The Last Supper

식당 예약과 현장 웨이팅을 함께 관리하는 백엔드 서비스

completedWaiting & Reservation5명
Backend GitHubFrontend GitHub
role
웨이팅 파트 + JMeter 부하 검증
impact
Redis atomic/queue/async로 웨이팅 등록 max 응답 233ms → 7ms
proof
500명/1초 JMeter spike, max 233ms → 7ms, 평균 40.9%~47.8% 감소
웨이팅 등록 max response233ms → 7ms
평균 응답 감소40.9%~47.8%
근거 자료2개
근거 보기

Project.java

project_nameThe Last Supper
period_team2025.04.17 ~ 2025.05.09 / 5명
purpose식당 이용자의 예약·현장 웨이팅 신청, 운영자의 대기열·예약 슬롯 관리
goal예약 슬롯 · 웨이팅 큐 · 고객 호출 · 이력 처리 · 모니터링의 운영 흐름 연결
development_issue웨이팅 등록 요청 집중 시 대기번호 중복, DB 저장 병목, 실패 요청 복구, 운영 종료 후 이력 처리 문제가 동시 발생 가능.
results
  • JMeter 부하 테스트 기반 웨이팅 등록 병목 확인
  • Redis Atomic 연산 기반 중복 진입과 대기번호 발급 단순화
  • Spring 비동기 처리 기반 응답 경로와 DB 저장 경로 분리, max response 233ms → 7ms
  • Prometheus/Grafana와 Spring Batch 기반 운영 흐름 구성

Role.md

roleWaiting queue backend
contribution웨이팅 파트 담당. 부하 테스트와 단위 테스트로 병목·동시성 문제 확인, DB Lock/분산락 비교 후 Redis Atomic 연산 기반 해결책 적용.
implemented_features
  • 웨이팅 오픈/중단/종료
  • 고객 웨이팅 등록/취소/미루기
  • 내 대기 순번 조회와 다음 고객 호출
  • Redis 기반 웨이팅 큐와 pending key
  • 실패 요청 dead-letter 큐
  • 팀 구조에 포함된 Spring Batch 기반 웨이팅 이력 처리 흐름 분석/연동
  • JMeter 부하 테스트와 Prometheus/Grafana 모니터링
personal_achievements
  • 동시 요청의 대기번호 중복 가능성 테스트 노출
  • DB Lock/분산락 비교 후 Redis SETNX/INCR 기반 단순 해결책 선택
  • 응답 경로와 DB 저장 분리, 웨이팅 등록 체감 성능 개선

TechDecision.md

Backend

Java 17예약·웨이팅 백엔드의 Spring Boot 런타임
Spring Boot 3.4.4예약·웨이팅 API와 운영 모니터링 구성
Spring Security + JWT고객과 운영자 인증 처리
Spring Batch운영 종료 후 웨이팅 이력 처리 자동화
WebSocket웨이팅 상태 변화 실시간 전달 경로

AI

이 범주의 대표 기술은 없습니다.

Data

Spring Data JPA예약, 매장, 계정, 웨이팅 이력의 관계형 모델 관리
MySQL 8예약과 웨이팅 이력의 영속 저장소

Infra

Redis 7웨이팅 큐, pending key, 대기번호 발급의 빠른 처리
Actuator + Micrometer애플리케이션 상태와 메트릭 노출
Prometheus + Grafana부하 테스트와 운영 지표 시각화
Gradle빌드와 테스트 실행 표준화

Test

JMeter웨이팅 등록 부하와 병목 재현
JUnit 5 + Mockito웨이팅 서비스, Redis 서비스, 비동기 프로세서 검증

Docs

이 범주의 대표 기술은 없습니다.

웨이팅 큐를 Redis로 관리

decision웨이팅 등록 초입과 대기번호 발급은 Redis 큐와 atomic 연산 처리
reason동시 요청에서 DB 단독 대기번호 발급 시 lock 비용·병목 증가 가능성
alternativesDB pessimistic lock, 분산락, 단일 DB sequence
trade_offRedis 키 스키마·복구 흐름 관리 부담 vs 요청 초입 동시성 처리 단순화
verification웨이팅 등록 동시성 테스트와 JMeter 부하 테스트
ownership직접 구현/결정

JMeter + Prometheus + Grafana 부하 검증

decision웨이팅 등록 성능은 JMeter 시나리오와 Prometheus/Grafana 지표 동시 확인
reason단위 테스트만으로는 부족한 응답 시간·병목 위치 설명력
alternatives수동 API 반복 호출, k6, 테스트 없음
trade_off테스트 자산 관리 비용 증가 vs 성능 개선 전후 evidence 확보
verificationThread Group, accountIds.csv, JMeter log, 메트릭 대시보드 결과 확인
ownership직접 구현/결정

Spring Batch로 예약·웨이팅 생명주기 처리

decision운영 종료 후 이력 처리와 생명주기 작업은 Batch 분리
reason운영자 수동 상태 정리 시 누락과 반복 작업 발생 가능성
alternatives수동 관리자 API, 단순 scheduler only
trade_offBatch Job 관리 비용 증가 vs 반복 가능한 상태 전이
verificationBatchMonitoringController와 job 실행 결과 확인
ownership팀 결정/연동 · 프로젝트 구조의 운영 생명주기 결정. 포트폴리오에서는 웨이팅 운영 흐름과 연결.

Problems.md

부하 테스트 기반 병목 탐지

problem웨이팅 등록 요청 집중 시 동기 DB 저장으로 인한 응답 시간 증가 구간
approach2,000개 계정 데이터와 JMeter 시나리오 기반 요청 흐름 재현
causeAPI 응답 경로와 DB 저장의 강한 결합
solutionAPI 응답 경로는 Redis 큐 선적재, DB 저장은 비동기 프로세서 담당
resultJMeter spike 기준 max response time 233ms → 7ms, 평균 응답 95ms → 1ms 확인

웨이팅 번호 중복 동시성 문제

problem동일 고객 동시 웨이팅 등록과 대기번호 발급 시 중복 접수 가능성
approachDB Lock, 분산락, Redis atomic 연산 비교
cause동시 요청 초입의 동일 사용자·동일 매장 중복 진입 차단 부족
solutionRedis SETNX pending key 기반 중복 진입 차단, Redis INCR 기반 대기번호 발급
result단순한 Redis atomic 연산으로 동시성 해결, 테스트 기반 회귀 기준 확보

Evidence/

Architecture

Architecture

Spring Boot 3.4.4 백엔드, Redis 7 대기열·캐시, MySQL 8, Firebase FCM 푸시, React 19 SPA와 JMeter 부하 테스트·Prometheus/Grafana 모니터링까지 포함한 구성

ERD

ERD

계정·매장·예약(reservation_plan·slot·history)·웨이팅(queue·history·setting)·알림 도메인 관계

웨이팅 등록 max response

233ms -> 7ms

500명/1초 JMeter spike. Redis atomic + queue + async 적용 후 max 기준.

평균 응답 감소

40.9%~47.8%

동일 점주 반복 조회, 다수 점주 조회, 기간 확대, 대량 부하 시나리오 기준.

JMeter 계정 데이터

2,000개

웨이팅 등록 부하 테스트용 계정 CSV 기준.

테스트 검증

당시 Gradle test suite 통과

기존 포트폴리오 기록 기준이며 전체 품질 보증률을 뜻하지 않는다.

Retrospective.md

learned

  • 동시성 문제 해결의 출발점: 추상적 우려보다 부하 테스트와 단위 테스트 재현
  • 대기열 설계 범위: CRUD를 넘어 상태 전이, 실패 복구, 운영 종료 흐름

regrets

  • Redis 키 스키마와 TTL 정책의 명확한 문서 부족
  • 포트폴리오 즉시 인용 가능한 JMeter 표준 요약 부족

improvements

  • 웨이팅 큐 key, pending key, dead-letter 큐 생명주기 문서화
  • 부하 테스트 결과 before/after 표·그래프 정리, 재현 가능성 확보

collaboration

예약/웨이팅 도메인이 만나는 매장 운영 흐름 조율. 컨트롤러 책임 단위 축소.

STAR.md

Redis Atomic 연산으로 웨이팅 동시성 해결

Situation동시 웨이팅 등록 요청, 중복 접수와 대기번호 충돌 가능성
ActionDB Lock/분산락 비교 후 Redis SETNX pending key와 INCR 대기번호 발급으로 요청 초입 단순화
Result중복 진입 차단, 대기번호 원자적 발급, JMeter·단위 테스트 기반 병목과 회귀 확인
Learning동시성 해결의 출발점: 강한 락보다 작은 공유 상태와 atomic primitive 제한