티켓 예매 서비스 PickGO

---

팀원 소개

PickGO - 공연 티켓 예매 웹사이트

https://pick-go.shop

연극, 뮤지컬, 콘서트, 무용 등 다양한 공연을 위한 기술 중심 예매 시스템

팀원 소개

김아성	김진명	전기범	이승민	조현우
asungkim 팀장 (PO)	jin214930 팀원	JunKiBeom 팀원	min429 팀원	chohyunwoo 팀원
- CI/CD 담당 - 예약 구현 및 결제 개선 - 로그 구현 - 모니터링 구현 - 대기열 리펙토링	- KOPIS API 연동 - 공연 데이터 처리 - 좌석 구조 구현	- 결제 구현 - 토스페이먼츠 API 연동 - 리뷰 기능 개선 - 성능 및 부하 테스트 - 로그 처리 개선	- 회원 구현(JWT, OAuth2) - Redis 기반 대기열 구현	- 좌석 실시간 상태 구현 - 관리자 CRUD 구현 - 리뷰 구현

---

프로젝트 개요

주제

PickGO는 공연 티켓을 실시간으로 예매할 수 있는 웹 기반 플랫폼입니다.
실 서비스 운영보다는 다음과 같은 기술적 도전에 초점을 맞춘 프로젝트입니다:

• 대기열 시스템 설계 및 구현
• 좌석 정합성 보장
• 예매 및 결제 흐름의 원자성 확보

---

주제 선정 배경

1. 사용자 경험 기반 문제 인식

• 좌석 선택 화면에서 확대 불가
• 실시간 좌석 상태 반영 지연

2. 기술적 도전 요소

• 대용량 트래픽 대응
  • 대기열 구조 설계
  • 서버 분리 및 확장 고려
• 도메인 정합성 유지
  • 좌석 선택 및 상태 일관성 보장
  • 예매 ~ 결제 흐름의 원자성 확보
• 성능 및 부하 테스트
  • 테스트 도구 활용 및 병목 지점 리팩토링
• 모니터링 체계 구축
  • 서버 및 JVM 모니터링
  • 비즈니스 지표 시각화

---

기술 스택

영역	기술 구성
Backend	Java, Spring Boot, OAuth2
Database	MySQL, Redis (Stream, Sorted Set)
Monitoring	Grafana, Prometheus, Node Exporter, Spring Actuator, InfluxDB
DevOps	Docker, GitHub Actions, AWS, Cloudflare Pages
Frontend	React, TypeScript, Vite, TailwindCSS, Thymeleaf
Web Server	Nginx (Reverse Proxy)
Testing	Gradle, JUnit5, K6
Communication	Notion, Slack, Discord, figma, Swagger

---

ERD

시스템 아키텍처

전체 흐름 요약

1. 사용자가 예매 페이지 접속
2. Nginx Reverse Proxy → Spring 서버 API 요청
3. 서버는 MySQL, Redis 기반으로 데이터 처리 및 응답
4. Redis Stream + SSE → 실시간 좌석 상태 전파
5. 대기열 입장은 스케줄러 기반 처리, 사용자별 상태 전송
6. Prometheus가 서버 및 JVM 상태 수집
7. Grafana 대시보드에서 실시간 확인 (iframe 제공)
8. GitHub Actions 자동 배포 → 각 EC2 인스턴스

---

서버 구성

구분	주요 구성 요소
EC2-1 (비즈니스 서버)	Spring App, MySQL, Redis, Nginx
EC2-2 (메트릭 서버)	Grafana, Prometheus, Node Exporter, InfluxDB, Nginx
	→ EC2-1의 상태 수집 및 메트릭 시각화

---

주요 기능 요약

• 실시간 좌석 상태 반영 (SSE + Redis Stream)
• 사용자 대기열 처리 로직
• 서버 상태/지표 실시간 모니터링
• GitHub Actions 기반 자동 배포 파이프라인
• RESTful API 설계 + OAuth2 인증

---

핵심 기능 및 주요 구현

1. 대기열 시스템 (Queue System)

📘 상세 위키 보기

• Redis Sorted Set: 사용자 대기 순서 저장
• Redis Stream: 대기 상태 메시지 발행
• SSE (Server-Sent Events): 클라이언트에게 실시간 대기 상태 전송
• 스케줄러 기반 입장 처리: TPS 기반 속도 제어 및 자동 입장 처리

---

2. 실시간 좌석 상태 반영

• 다중 사용자 동시 접속 시 좌석 현황 동기화
• SSE 구독을 통한 실시간 선택/해제 이벤트 전파

---

3. 좌석 선택 정합성 보장

• 좌석 테이블에 UNIQUE 제약조건 부여
  • 동시 선택 충돌 방지
• 낙관적 락 적용
  • 최종 선택자만 예매 확정 가능
  • 예매 경쟁 상황에서도 데이터 정합성 유지

---

4. 예매 및 결제 흐름

• TossPayments API 연동을 통한 실 결제 흐름 구현
• 예매/결제 만료 스케줄러
  • 예매 후 일정 시간 무응답 시 자동 만료 처리
• 예매 → 결제의 트랜잭션 흐름 보장
  • 원자성 있는 예매 처리 로직 구현

---

5. 운영자용 관리자 대시보드

• 운영 현황 시각화
  • 공연 목록, 예매 상태, 사용자 로그
• Grafana + MySQL 기반 대시보드
  • 주요 지표 실시간 시각화
  • iframe 방식으로 관리자 페이지에 통합

---

API 명세

Swagger 문서 바로가기

API 명세 Wiki 바로가기

협업 규칙

Git 브랜치 규칙

• GitHub Flow 방식

  1. Branch 생성

     • 기능 개발 또는 버그 수정 시 새 브랜치 생성
     • 브랜치 네이밍: feature/이슈번호, fix/이슈번호

  2. Commit 작성

     • 브랜치에서 변경 사항을 커밋으로 저장

     Commit 메시지 컨벤션

     1. feat: 새로운 기능 추가
     2. fix: 버그 수정
     3. docs: 문서 수정 (README, Wiki 등)
     4. style: 코드 포맷팅, 세미콜론 누락 등 (기능 변경 없음)
     5. refactor: 코드 리팩토링
     6. test: 테스트 코드 추가 또는 기존 테스트 수정
     7. chore: 기타 변경 사항
     8. comment: 주석 추가 및 변경
     9. !HOTFIX: 배포 관련 긴급 수정

  3. Pull Request(PR) 생성

     • 변경 사항을 develop 브랜치로 병합하기 위해 PR을 생성

     PR 규칙

     1. Merge 전 2명 이상 승인 필요
     2. PR 설명에 구현한 기능 간단히 작성
     3. PR 전 rebase 확인 필수

  4. 리뷰 및 피드백 반영

     • 리뷰어 요청 시 적극적으로 반영
     • 코드 리뷰 완료 후 squash merge

  5. develop 병합 (Merge)

     • PR이 승인되면 변경 사항을 develop 브랜치로 병합.
     • 배포 시점에 main 브랜치로 병합

자바 컨벤션

컨벤션 Wiki 바로가기

발표 자료

Canva

시연 영상

Youtube