개인사업자 중심으로 파편화된 공동구매를 하나의 플랫폼에서 실시간으로 참여할 수 있는 서비스
6개 서비스 · 3종 DB · Kafka 이벤트 기반 · SAGA 보상 트랜잭션 · Redis 분산 락 · k6 부하 테스트 정량 검증

docker compose up -d
# → http://localhost:3002

GongGuHaSong/
├── member-service/         # 회원 관리 (MongoDB)
│   └── domain: Member, Note
├── product-service/        # 상품 관리 (MongoDB + Redis + Kafka)
│   └── domain: Sell, Survey, Like
├── order-service/          # 주문 처리 (MongoDB + Kafka)
│   └── domain: Registration
├── payment-service/        # 결제 — SAGA Orchestrator (MySQL)
│   └── domain: Payment, Card, CompensationOutbox
├── point-service/          # 포인트 — SELECT FOR UPDATE + Redis 분산 락 (MySQL + Redis)
│   └── domain: Point, PointHistory
├── search-service/         # 검색 + 실시간 랭킹 (ES + MongoDB)
│   └── domain: SearchDocument(ES), SearchLog, OrderRecord
├── load-test/              # k6 부하 테스트 스크립트
├── docker-compose.yml      # 6개 서비스 + 인프라 통합 배포
└── src/frontend/           # React

물리 인스턴스는 MySQL 1대, MongoDB 1대를 공유하되, 서비스별로 논리 스키마를 분리하고 전용 계정으로 접근 권한을 격리했다. (mysql-init.sql, mongo-init.js에서 서비스별 DB + 유저 생성, 자기 DB에만 읽기/쓰기 권한 부여)

서비스 간 FK 없이 userId, orderId로 논리적 참조. 통신은 Feign/Kafka만 사용.

──→ 같은 DB 내 참조 (JPA) · ···→ 서비스 간 논리적 참조 (FK 없음)

1건 주문이 3개 서비스에 동시 전달되는 이벤트 드리븐 구조

ES + Nori 한국어 형태소 분석 · 이벤트 드리븐 즉시 갱신 + 60초 폴링 폴백

• 깃허브 링크 : https://github.com/GongGuHaSong/GongGuHaSong
• 교내 공구 참여 사이트. 참여 요청, 쪽지, 찜, 회원가입 기능
• MongoDB 단일 DB, 모놀리식 구조, 결제/재고/검색 없음

결제/재고/포인트를 새로 만드는 건 당연하고, 진짜 문제는 여러 명이 동시에 주문할 때 금액과 재고가 꼬이지 않게 하는 것이었다.

모놀리식 → 6개 마이크로서비스로 분리. 결제(SAGA), 재고(원자적 차감), 검색(ES + 실시간 랭킹)을 새로 설계했다.

기능을 만든 것만으로는 부족했다. k6로 실제 부하를 걸어보니 단건에서는 보이지 않던 문제들이 드러났다.

2단계에서 적용한 DB 비관적 락(SELECT FOR UPDATE)은 단일 인스턴스에서는 잘 동작했다. 그러나 300 VU 부하에서 p95 469ms, max 2.26s로 지연이 쌓이기 시작했고, timeout이 DB 락 API에서 집중 발생했다.

타임아웃만으로 원인을 단정할 수는 없었지만, 인터넷에 서치하며 여러 문서를 보다 보니
DB 비관적 락을 사용하면 @Transactional 에 진입과 동시에 커넥션을 점유하는 구조 때문에 락을 못 잡아도 커넥션은 잡고 있게 된다는 사실을 알게 됐다.

반면에 Redis 분산 락은 @Transactional 바깥에서 락을 얻고 대기 후 락을 얻었을 때 트랜잭션을 진입하기 때문에 커넥션 점유가 없다.

영역	Before	After
Backend
Database
Infra	—
Frontend
Test	—

랭킹 점수 = 검색횟수 × 0.4  +  주문량 × 0.6   (최근 1시간 기준)

• 단순 검색 시 (가중치 0.4)
  

• 결제 전 금액 상태 (포인트 10만p, 카드 잔여 한도 1,010,000원)
  

• 결제 전 재고 상태 (진행률 38%, 재고 370개)
  

• 주문 과정 gif (잔액-재고-실검 흐름 확인, 잔액과 재고는 차감되고 실검은 구매(0.6)*검색(0.4) 비율에 따라 랭킹 실시간 재조정)
  

• 주문 -> 결제 후 금액 상태 (포인트 2000p, 카드 잔여 한도 210,000원)
  => 포인트 -10만p, 카드 -80만 (총 90만) + 포인트 적립 2000p (20개 * 개당 100p 적립)

• 주문 -> 결제 후 재고 상태 (진행률 63%, 재고 350개)
  

100개의 재고를 가진 물품을 최대 10,000명의 유저가 동시 구매하는 시나리오를 가정.

• before (동시성 보장 전)
  

• After (findAndModify로 조회+차감 원자성 보장 + 재고 정합성 보장)
  

k6 테스트 스크립트에서 매 요청마다 10P씩 차감하도록 설계했다.

  300 VU × 5분, 총 213,185건 (709 TPS)
  마이너스 잔액:  0건
  성공률:        50.43% (잔액 부족으로 정상 거절된 차감 요청 포함 — 적립/차감 반반 설계)
  p95 지연:      469ms
  max 지연:      2.26s
  총 HTTP 요청:  426,520건 (1,418 req/s)

=> 정합성은 완벽. 성공률 50%는 적립/차감 반반 설계에서 잔액 부족 거절 포함된 정상 수치.
=> 다만 p95 469ms, max 2.26s — 300 VU에서 request timeout 발생 시작.

point-service 3대 + nginx 로드밸런서, 300 VU, 2분간 총 4만 건 부하
DB 비관적 락 vs Redis 분산 락 정량 비교

=> 결과: Redis 분산 락이 처리량 34% 높고, p95 지연은 35% 낮음

50→300 VU 단계별 부하 + 장애 주입 10% (포인트 차감 후 결제 저장 전 강제 예외)
1인 1결제, 검증: 결제 실패 시 포인트가 복구되는가?

• before (보상 없음)
  

• after (SAGA 보상 트랜잭션 + Outbox)
  

PAYMENT_TROUBLESHOOTING.md

• MongoDB findAndModify로 포인트 차감 → 차감-이력 간 누락 발견 → MySQL @Transactional로 전환
• 낙관적 락/비관적 락 충돌 발견 → 금전 도메인은 비관적 락으로 통일
• SAGA 보상 적용 → 오히려 악화(90.4% → 97.1% 유실) → 원인: 보상 호출이 커넥션 풀에 추가 부하 → CompensationOutbox로 해결 (최종 유실 0건)
• DB 비관적 락의 구조적 한계 (@Transactional 안에서 락 대기 = 커넥션 점유) → Redis 분산 락으로 락 대기를 트랜잭션 바깥으로 분리. RedisLockPointFacade(락) + RedisLockPointInnerService(@Transactional) 별도 Bean 분리

LOAD_TEST.md

• 위 문제들은 전부 부하 테스트에서 발견했다. 단건에서는 보이지 않는 문제가 300명 동시 요청에서 드러남
• 재고 동시성: 300명 → 3,000명 → 10,000명 스파이크에서 초과 판매 0건
• SAGA 보상 3단계 비교: Before(90.4% 유실) → SAGA only(97.1%, 오히려 악화) → SAGA+Outbox(0% 유실)
• DB 락 vs Redis 락: 단일 인스턴스에서 p95 469ms 한계 확인 → 3대 비교 실험으로 커넥션 점유 병목 검증 → Redis 분산 락이 처리량 34%↑, p95 35%↓

REALTIME_SEARCH.md

• Elasticsearch + Nori 한국어 형태소 분석, 역인덱스 기반 검색
• 이벤트 드리븐(즉시) + 60초 폴링(폴백) 하이브리드
• 자동완성/실제검색 API 분리 (랭킹 오염 방지)
• 띄어쓰기 검색 에러, 랭킹 오염, 폴링→이벤트 드리븐 전환 트러블슈팅

MULTI_INSTANCE.md

• 대용량 트래픽 대응을 위해 K8s를 도입했으나, 단일 노드 환경에서는 K8s의 핵심 가치(self-healing, HPA, 롤링 업데이트)가 성립하지 않음을 인지
• 피상적 도입보다 확실한 필요에 의한 선택이라는 판단으로 제거. 과정에서 Eureka 제거, 인프라에 따른 코드 동작 차이 등을 학습

DATABASE_SEPARATION.md

• 단일 MongoDB → Database per Service → MongoDB + MySQL + ES
• NoSQL이 적합한 곳 vs RDBMS가 필수인 곳 판단 근거

PAYMENT_SECURITY.md

TROUBLESHOOTING.md / TROUBLESHOOTING2.md

• 6개 서비스 + 인프라 통합 배포 과정의 이슈 해결 (Nginx DNS, WebSocket 프록시, ES 기동 순서, Kafka 세션 충돌 등)