Kon-ticket
기술 리포트

차세대 공연·티켓 통합 플랫폼 기술 보고서

작성일: 2025-10-08 문서 유형: Technical Due Diligence Report
엔드투엔드 공연/티켓팅 플랫폼
실시간 대기열·좌석 점유 제어
멀티 채널 운영 역량
메시지 지향 아키텍처
성숙한 데이터 모델

Kon-ticket 개요

차세대 공연·티켓 통합 플랫폼의 핵심 강점

Kon-ticket은 기획·예매·현장 운영·사후 분석까지 하나의 생태계에서 처리하는 엔드투엔드 공연/티켓팅 플랫폼입니다.

아키텍처 특징
9~12개 서비스로 구성된 모듈러 아키텍처로, 각 서비스는 동기식 API와 비동기 이벤트 스트림을 혼합해 결합도를 낮춥니다.

실시간 대기열·좌석 점유 제어

고도의 경합 상황에서도 안정적인 티켓팅 경험 제공

SSE/웹소켓 좌석 예약 타임아웃 선착순 처리

멀티 채널 운영 역량

다양한 채널에서 일관된 사용자 경험 제공

소비자 웹 Admin/Staff 콘솔 Electron 키오스크

메시지 지향 아키텍처

비동기 처리로 스파이크 트래픽 효과적으로 흡수

AWS SQS Redis 버스트 흡수

데이터 모델 성숙도

복잡한 도메인을 체계적으로 모델링

수십 개 핵심 엔티티 다수 마이그레이션 풍부한 관리 기능

시스템 아키텍처

서비스 맵과 상호작용 패턴

서비스 맵
채널 계층
소비자 웹
서비스 계층
관리 콘솔
메시지 계층
데이터 계층
키오스크
채널 계층
소비자 웹/앱 Admin 콘솔 Staff 콘솔 키오스크
서비스 계층
좌석/인벤토리 주문 서비스 결제 서비스 대기열/세션
메시지 계층
SQS 메시지 컨슈머 알림/메시징
데이터 계층
MySQL MongoDB Redis 객체 스토리지
상호작용 패턴
요청-응답 (동기)
사용자 체감 지연에 민감한 경로에서 사용
좌석 조회 가격 계산 REST/gRPC
사가/아웃박스 (비동기)
분산 트랜잭션 처리, 실패 시 보상 트랜잭션으로 원복
주문 생성 결제 승인 좌석 확정
백프레셔
큐 적재율·소비율 임계 시 트래픽 제어
429 응답 대기열 페이지 지수 백오프
캐시 전략
읽기 경로 최적화, 좌석 잠금 효율화
Read-Through Write-Behind Cache-as-Authority

데이터 아키텍처

핵심 데이터 도메인과 정합성 전략

핵심 데이터 도메인
카탈로그·스케줄링
공연 메타데이터, 회차/일정, 가격 정책
주요 테이블
concerts, venues, schedules, pricing
저장소
MySQL (Primary)
정합성
ACID 트랜잭션, 변경 이력 관리
보존
장기 보존 (규정 기준)
좌석·공간 모델
좌석 그리드, 구역/레이아웃, 가시성
주요 테이블
seats, sections, layouts, holds
저장소
Redis (Lock) + MySQL
정합성
단기 락(TTL) + 확정 시 커밋
보존
락 TTL 단기, 확정 데이터 장기
거래·결제
주문 레코드, 결제 상태, 환불/클레임
주요 테이블
orders, payments, refunds, transactions
저장소
MySQL + SQS (Event)
정합성
강한 정합성, 멱등성, 재처리
보존
법정 보존/회계 규정 (7년)
신원·권한
사용자 프로필, 인증 토큰, 역할/권한
주요 테이블
users, roles, permissions, sessions
저장소
MySQL + Redis (Session)
정합성
강한 정합성, 키 관리(KMS)
보존
GDPR 준수, 탈퇴 시 삭제
정합성 전략
좌석 점유
Redis 분산 락 + TTL 기반 임시 점유
좌석 잠금
결제 완료
영구 확정
결제 멱등성
결제 요청 키와 트랜잭션 아웃박스 패턴
멱등성 키
중복 검증
아웃박스 기록
대기열 토큰화
사용자별 토큰/슬롯 발급, 레이트 리미터
토큰 발급
진입 제어
순번 통지

성능 및 확장성

EC2 → Fargate 마이그레이션과 무제한 확장 가능성

4.1 인프라 진화: EC2 → Fargate 마이그레이션
Before
AWS Elastic Beanstalk + EC2
인스턴스 기반 운영
스케일링 시간 지연 (부팅 + 시작)
유휴 리소스 비용 발생
2025년 전환
After
ECS Fargate (서버리스 컨테이너)
이론적 무제한 확장성
즉각 스케일링 (~10초)
컨테이너 단위 확장
4.2 현재 아키텍처 역량
컨테이너 기반 마이크로서비스
9개 서비스가 독립적으로 확장 가능
Auto Scaling
CPU 70% 기준 자동 확장
즉각 응답
컨테이너 시작 ~10초 이내
이론적 무제한 확장
Fargate 자체는 사실상 제약 없음
실질적 제약 요소
1
데이터베이스
RDS MySQL Read Replica로 읽기 분산, 쓰기는 단일 마스터 제약
2
외부 API 레이트 리밋
결제 게이트웨이, SMS 등 외부 서비스 처리량 한계
3
비용 관리
무제한 확장 시 예산 초과 리스크
4.3 확장 시나리오
규모
동시 접속
특징
Small-scale
수천~1만 명
최소 컨테이너, 대기열 없이 처리
Medium-scale
수만 명
Auto Scaling, 대기열 가동, Redis 분산 락
Large-scale
10만 명 이상
전체 스케일 아웃, Read Replica 활용, API 병목 모니터링
Peak-scale
이론적 무제한
실질 제약: DB 처리량, 외부 API 한계, 비용 한도
대응: Read Replica 확장, DB 샤딩, 복수 API 계정
4.4 성능 목표 및 특성
지표
목표치
비고
P95 API 응답 시간
150~180ms
캐시 활용 시 개선
결제 처리 처리량
1,500~3,000 txn/min
외부 API 의존적
좌석 락 충돌률
<1%
Redis 분산 락 성능
대기열 이탈률
<10%
SSE 연결 안정성
DB 복제 지연
<1초
Read Replica 동기화
핵심 강점
EC2 → Fargate 전환으로 즉각 스케일 아웃 가능 (컨테이너 단위)
이론적으로 무제한 확장 가능한 컴퓨팅 계층
실질적 병목은 데이터베이스 및 외부 API로 집중 관리 가능

DevOps 및 운영 전략

CI/CD, 관측성, 복구 전략

CI/CD 파이프라인
빌드
코드 컴파일
이미지
ECR 푸시
배포
ECS 적용
자동 테스트: 단위/통합/E2E 테스트 자동화
보안 스캔: 정적·동적 분석, 컨테이너 이미지 검사
환경 분리: dev/stage/uat/demo/prod 환경 템플릿화
복구 전략
30분
RTO 목표
5분
RPO 목표
DB 스냅샷
Point-in-time
오브젝트 버저닝
멀티 AZ/리전
재해복구 플레이북
배포 성과
Kon-ticket main api 기준
147
총 배포 횟수 (6개월)
98.6%
평균 성공률
12분
평균 배포 시간
관측성 (Observability)
메트릭
4 Golden Signals (레이트/에러/지연/포화), 큐 적재/소비율
로그
구조화 로그(JSON), 감사 로그, 샘플링, 개인정보 마스킹
트레이싱
AWS X-Ray 중심, OpenTelemetry 도입 진행 중
알림
다중 채널(Slack/Webhook), 임계값 기반 + 애노말리
SLO: API 가용성 99.95%, P95 180ms
에스컬레이션: 온콜/2차 알림 체계
운영 기능
DLQ 처리: 실패 메시지 격리·재처리, 운영 대시보드 연동
실시간 대시보드: 판매/예매 현황 실시간 집계, API 기반 시각화
파일 관리: 오브젝트 스토리지 연동, 감사 로그
런타임 관리: Docker + ECS, 블루-그린/카나리 배포 도입 진행 중

핵심 워크플로우

대기열, 좌석, 결제 프로세스

대기열
1
입장 토큰 발급
사용자별 고유 토큰 생성 및 할당
토큰 버킷 SSE
2
레이트 리미터 기반 속도 제어
초당 요청량 제어, 트래픽 정체 흡수
백프레셔 429 응답
3
순번 통지
SSE/웹소켓을 통한 실시간 순번 업데이트
Server-Sent Events WebSocket
4
타임아웃/재연결 처리
세션 만료 및 재연결 로직
TTL Idempotent Resume
장애 대응
SSE 재연결
토큰 재발급
입장 요청
토큰 발급
대기열 등록
순번 대기
입장 허가
좌석
1
좌석 선택
사용자가 원하는 좌석 선택
좌석 그리드 가시성 정보
2
Redis 락 + TTL 점유
분산 락으로 좌석 임시 점유
Redis 분산 락 TTL (10-15분)
3
결제 완료 시 확정
결제 성공 시 DB에 영구 확정
트랜잭션 커밋 ACID
4
실패 시 자동 해제
스케줄러 기반 잠금 해제
스케줄러 자동 롤백
장애 대응
TTL 만료 해제
재시도 로직
좌석 조회
좌석 선택
Lock 획득
점유 유지
결제 이동
결제
1
결제 게이트웨이
Omise/2C2P 등 외부 결제 서비스 연동
REST API Webhook
2
콜백 검증
결제 결과 콜백 수신 및 검증
서명 검증 보안 검증
3
멱등성 키 검증
중복 결제 방지를 위한 키 검증
Idempotency Key 아웃박스 패턴
4
주문 상태 전이
결제 결과에 따른 주문 상태 변경
State Machine 사가 패턴
장애 대응
보상 트랜잭션
이벤트 재전송
DLQ 자가 치유
결제 시작
PG 호출
결제 완료
검증
티켓 발행

위험 관리

위험 레지스터와 대응 전략

보안 위험
자격 증명/비밀키 노출
영향
치명적
가능성
높음
우선순위
히스토리 퍼지
Secrets Manager
로테이션
정합성 위험
좌석 확정 이중 과금
영향
높음
가능성
중간
우선순위
멱등 키
사가/아웃박스
회계 대사
가용성 위험
결제 게이트웨이 지역 장애
영향
높음
가능성
중간
우선순위
액티브-액티브
대체 게이트웨이
위험 분포 및 우선순위
성능 위험
대기열 토큰 손실·SSE 단절
영향
중간
가능성
중간
우선순위
재연결
오프라인 큐
세션 동기화
운영 위험
다중 레포 분기/코드 드리프트
영향
중간
가능성
높음
우선순위
모노레포
모듈화
공용 패키지화
규정 위험
PCI-DSS/PDPA 미충족
영향
높음
가능성
중간
우선순위
네트워크 분리
토큰화
DLP

결론

기술적 강점과 향후 강화 포인트

기술적 강점
실시간 처리 역량
대기열·웹소켓 알림, 인메모리 락, 멱등성 기반 중복 방지
SSE
Redis 락
멱등성
옴니채널 운영성
소비자 웹·Admin/Staff 콘솔·키오스크로 일관된 경험 제공
멀티 채널
통합 플랫폼
비동기 내성
메시지 큐와 DLQ 기반의 스파이크·일시 장애 흡수
SQS
DLQ
버스트 흡수
모듈러 서비스 경계
도메인 단위 분리로 변경 영향 최소화
마이크로서비스
결합도 낮춤
향후 강화 포인트
이벤트 정합성
아웃박스/사가 패턴으로 분산 트랜잭션 정합성 보장
도입 진행 중
적응형 대기열 승급
Adaptive Admission Control로 트래픽 패턴에 따른 동적 입장 제어
도입 진행 중
토큰 버킷
버스트 버퍼를 통한 트래픽 평탄화 및 안정적인 서비스 제공
도입 진행 중
멀티 AZ·오토스케일링
가용성 영역 분산 및 자동 확장으로 장애 내성 강화
도입 진행 중
끝맺음
Kon-ticket은 실시간 좌석·대기열·결제의 핵심 경합 구간을 기술적으로 잘 포착한 플랫폼입니다. 현재 구조만으로도 대중적 이벤트의 부하를 수용할 토대를 갖추었으며, 운영 표준화와 관측성/정합성 고도화를 순차적으로 이행하면 성능·안정성·운영 효율에서 한 단계 도약이 가능합니다.