WELCOME TO THE PROJECT STORE
The Last Supper
식당 예약과 현장 웨이팅을 함께 관리하는 백엔드 서비스
- ROLE
- 웨이팅 파트 + JMeter 부하 검증
- IMPACT
- Redis atomic/queue/async로 웨이팅 등록 max 응답 233ms → 7ms
- PROOF
- 500명/1초 JMeter spike, max 233ms → 7ms, 평균 40.9%~47.8% 감소
IN THE STORE
프로젝트 안내
WHY THIS STORE EXISTS목적
식당 이용자의 예약·현장 웨이팅 신청, 운영자의 대기열·예약 슬롯 관리
목표
예약 슬롯 · 웨이팅 큐 · 고객 호출 · 이력 처리 · 모니터링의
운영 흐름 연결개발 과제
웨이팅 등록 요청 집중 시 대기번호 중복, DB 저장 병목, 실패 요청 복구, 운영 종료 후 이력 처리 문제가 동시 발생 가능.
결과
- JMeter 부하 테스트 기반 웨이팅 등록 병목 확인
Redis Atomic연산 기반 중복 진입과 대기번호 발급 단순화- Spring 비동기 처리 기반 응답 경로와 DB 저장 경로 분리, max response 233ms → 7ms
- Prometheus/Grafana와 Spring Batch 기반 운영 흐름 구성
IN THE STORE
내가 맡은 일
OWNERSHIP역할
Waiting queue backend
기여도
웨이팅 파트 담당. 부하 테스트와 단위 테스트로 병목·동시성 문제 확인, DB Lock/분산락 비교 후 Redis Atomic 연산 기반 해결책 적용.
구현한 기능
- 웨이팅 오픈/중단/종료
- 고객 웨이팅 등록/취소/미루기
- 내 대기 순번 조회와 다음 고객 호출
- Redis 기반 웨이팅 큐와 pending key
- 실패 요청 dead-letter 큐
- 팀 구조에 포함된 Spring Batch 기반 웨이팅 이력 처리 흐름 분석/연동
- JMeter 부하 테스트와 Prometheus/Grafana 모니터링
개인 성과
- 동시 요청의 대기번호 중복 가능성 테스트 노출
- DB Lock/분산락 비교 후
Redis SETNX/INCR기반 단순 해결책 선택 - 응답 경로와 DB 저장 분리, 웨이팅 등록 체감 성능 개선
IN THE STORE
기술과 선택
TECH & DECISIONS백엔드
Java 17
예약·웨이팅 백엔드의 Spring Boot 런타임
Spring Boot 3.4.4
예약·웨이팅 API와 운영 모니터링 구성
Spring Security + JWT
고객과 운영자 인증 처리
Spring Batch
운영 종료 후 웨이팅 이력 처리 자동화
WebSocket
웨이팅 상태 변화 실시간 전달 경로
데이터
Spring Data JPA
예약, 매장, 계정, 웨이팅 이력의 관계형 모델 관리
MySQL 8
예약과 웨이팅 이력의 영속 저장소
인프라
Redis 7
웨이팅 큐, pending key, 대기번호 발급의 빠른 처리
Actuator + Micrometer
애플리케이션 상태와 메트릭 노출
Prometheus + Grafana
부하 테스트와 운영 지표 시각화
Gradle
빌드와 테스트 실행 표준화
테스트
JMeter
웨이팅 등록 부하와 병목 재현
JUnit 5 + Mockito
웨이팅 서비스, Redis 서비스, 비동기 프로세서 검증
웨이팅 큐를 Redis로 관리
선택
웨이팅 등록 초입과 대기번호 발급은 Redis 큐와 atomic 연산 처리
이유
동시 요청에서 DB 단독 대기번호 발급 시 lock 비용·병목 증가 가능성
대안
DB pessimistic lock, 분산락, 단일 DB sequence
트레이드오프
Redis 키 스키마·복구 흐름 관리 부담 vs 요청 초입 동시성 처리 단순화
검증
웨이팅 등록 동시성 테스트와 JMeter 부하 테스트
주도성
직접 구현/결정
JMeter + Prometheus + Grafana 부하 검증
선택
웨이팅 등록 성능은 JMeter 시나리오와 Prometheus/Grafana 지표 동시 확인
이유
단위 테스트만으로는 부족한 응답 시간·병목 위치 설명력
대안
수동 API 반복 호출, k6, 테스트 없음
트레이드오프
테스트 자산 관리 비용 증가 vs 성능 개선 전후 evidence 확보
검증
Thread Group, accountIds.csv, JMeter log, 메트릭 대시보드 결과 확인
주도성
직접 구현/결정
Spring Batch로 예약·웨이팅 생명주기 처리
선택
운영 종료 후 이력 처리와 생명주기 작업은 Batch 분리
이유
운영자 수동 상태 정리 시 누락과 반복 작업 발생 가능성
대안
수동 관리자 API, 단순 scheduler only
트레이드오프
Batch Job 관리 비용 증가 vs 반복 가능한 상태 전이
검증
BatchMonitoringController와 job 실행 결과 확인
주도성
팀 결정/연동 · 프로젝트 구조의 운영 생명주기 결정. 포트폴리오에서는 웨이팅 운영 흐름과 연결.
IN THE STORE
문제를 푼 방식
PROBLEM SOLVING부하 테스트 기반 병목 탐지
문제
웨이팅 등록 요청 집중 시 동기 DB 저장으로 인한 응답 시간 증가 구간
접근
2,000개 계정 데이터와 JMeter 시나리오 기반 요청 흐름 재현
원인
API 응답 경로와 DB 저장의 강한 결합
해결
API 응답 경로는 Redis 큐 선적재, DB 저장은 비동기 프로세서 담당
결과
JMeter spike 기준 max response time 233ms → 7ms, 평균 응답 95ms → 1ms 확인
웨이팅 번호 중복 동시성 문제
문제
동일 고객 동시 웨이팅 등록과 대기번호 발급 시 중복 접수 가능성
접근
DB Lock, 분산락, Redis atomic 연산 비교
원인
동시 요청 초입의 동일 사용자·동일 매장 중복 진입 차단 부족
해결
Redis SETNX pending key 기반 중복 진입 차단, Redis INCR 기반 대기번호 발급결과
단순한 Redis atomic 연산으로 동시성 해결, 테스트 기반 회귀 기준 확보
IN THE STORE
검증 자료
EVIDENCE, NOT DECORATION
Architecture
Spring Boot 3.4.4 백엔드, Redis 7 대기열·캐시, MySQL 8, Firebase FCM 푸시, React 19 SPA와 JMeter 부하 테스트·Prometheus/Grafana 모니터링까지 포함한 구성
ERD
계정·매장·예약(reservation_plan·slot·history)·웨이팅(queue·history·setting)·알림 도메인 관계
웨이팅 등록 max response
233ms → 7ms500명/1초 JMeter spike. Redis atomic + queue + async 적용 후 max 기준.평균 응답 감소
40.9%~47.8%동일 점주 반복 조회, 다수 점주 조회, 기간 확대, 대량 부하 시나리오 기준.JMeter 계정 데이터
2,000개웨이팅 등록부하 테스트용 계정 CSV 기준.테스트 검증
당시 Gradle test suite 통과기존 포트폴리오 기록 기준이며 전체 품질 보증률을 뜻하지 않는다.IN THE STORE
회고
WHAT I LEARNED배운 점
- 동시성 문제 해결의 출발점: 추상적 우려보다 부하 테스트와 단위 테스트 재현
- 대기열 설계 범위: CRUD를 넘어 상태 전이, 실패 복구, 운영 종료 흐름
아쉬운 점
- Redis 키 스키마와 TTL 정책의 명확한 문서 부족
- 포트폴리오 즉시 인용 가능한 JMeter 표준 요약 부족
다음 개선
- 웨이팅 큐 key, pending key, dead-letter 큐 생명주기 문서화
- 부하 테스트 결과 before/after 표·그래프 정리, 재현 가능성 확보
협업
예약/웨이팅 도메인이 만나는 매장 운영 흐름 조율. 컨트롤러 책임 단위 축소.
IN THE STORE
면접에서 설명할 사례
STAR STORIESRedis Atomic 연산으로 웨이팅 동시성 해결
상황
동시 웨이팅 등록 요청, 중복 접수와 대기번호 충돌 가능성
행동
DB Lock/분산락 비교 후 Redis SETNX pending key와 INCR 대기번호 발급으로 요청 초입 단순화
결과
중복 진입 차단, 대기번호 원자적 발급, JMeter·단위 테스트 기반 병목과 회귀 확인
배움
동시성 해결의 출발점: 강한 락보다 작은 공유 상태와 atomic primitive 제한