프론트 시스템 아키텍처

프론트엔드는 Next.js App Router를 라우팅/렌더링의 중심으로 두고, UI 컴포넌트, Zustand 기반 클라이언트 상태, 서비스/API 계층, 인증 복구를 분리해 유지보수성과 운영 안정성을 확보한 구조입니다.

전체 구조

서비스별 역할

백엔드 시스템 아키텍처 (이너)

사용자 요청은 CDN → NLB → Istio를 통과한 뒤 API Gateway에 도달합니다. Gateway에서 JWT를 중앙 검증하고 X-User-Id 헤더를 주입하여 하위 서비스로 라우팅합니다. 하위 서비스는 JWT를 직접 파싱하지 않고 헤더만 신뢰합니다.

PlayBall 백엔드는 5개 마이크로서비스와 1개 공통 라이브러리로 구성되며, 서비스 간 직접 REST 호출 없이 Redis / Kafka를 통한 간접 데이터 공유만 존재합니다. 현재 DB는 단일 PostgreSQL 인스턴스에 테이블 소유권만 분리된 상태이며, 향후Payment 서비스 분리와 DB 스키마 분리를 대비해 EDA(Event-Driven Architecture)로 전환했습니다. 상세 내용은 MSA · EDA 전환 문서 참고.

전체 구조

flowchart TD
    U[사용자] --> CDN[Vercel CDN DDOS 방어]
    CDN --> NLB[NLB 접근 제한]
    NLB --> ISTIO[Istio Gateway WAF + mTLS]
    ISTIO --> G[API-Gateway :8085]
    G --> AG[Auth-Guard :8080]
    G --> Q[Queue :8081]
    G --> S[Seat :8082]
    G --> O[Order-Core :8083]

    AG -.-> RC[공용 Redis :6379]
    S -.-> RC
    O -.-> RC
    G -.-> RC
    Q -.-> RQ[Queue 전용 Redis :6380]
    S -.-> RQ

    AG --> DB[(PostgreSQL :5432)]
    S --> DB
    O --> DB

    AG -->|publish| KF[Kafka :9092]
    O -->|publish| KF
    S -->|consume| KF
    O -->|consume| KF

서비스별 역할

데이터 인프라

PostgreSQL

단일 PostgreSQL 16 인스턴스에서 테이블 소유권을 서비스별로 명확히 분리합니다. 각 서비스는 자신의 테이블만 쓰기하고, 다른 서비스 테이블은 읽기만 합니다. AES-256-GCM 필드 암호화가 email, nickname, phone에 적용됩니다.

Redis 2대 분리

Redis는 Queue 전용(:6380)과 공용(:6379)으로 두 인스턴스를 분리합니다. 티켓 오픈 시 대기열 트래픽이 폭발하더라도 인증이나 좌석 분산 락에 영향을 주지 않도록 설계했습니다.

Kafka 이벤트 메시징 (Apache Kafka 3.7.1)

파티션 3 / Acks all / 3회 재시도 후 실패 시 {토픽}.DLT(Dead Letter Topic)로 전송됩니다.

캐싱 전략

Caffeine 로컬 캐시 (JVM 인-메모리)

W-TinyLFU 교체 알고리즘을 사용하는 고성능 로컬 캐시. 네트워크 홉 없이 sub-microsecond 접근이 가능하며, 거의 불변 데이터(Match, Section, Block)에 적용되어 DB 커넥션 부하를 크게 낮췄습니다.

Redis 분산 캐시

인스턴스 간 공유가 필요한 변동 데이터(User, 응답 캐시)는 Redis 분산 캐시를 사용합니다.

스케줄러 (백그라운드 작업)