FlashDrop

쿠폰 50장에 동시 요청 300건이 몰려도 한 장도 초과 발급되면 안 됩니다. 단순한 '읽기 → 확인 → 쓰기'는 lost update 때문에 50장 대신 300장을 발급합니다. 같은 비즈니스 규칙을 4가지 방식으로 구현해, 실제 부하에서 정확성, 처리량, 지연 시간의 균형을 측정해야 했습니다.

Caddy가 정적 프론트엔드를 제공하고 /api/* 요청을 Spring Boot로 넘깁니다. 요청은 먼저 Bucket4j 레이트 리미터(상태는 Redis)를 통과합니다. 전략마다 엔드포인트, 엔티티, 테이블이 따로 있습니다. Redis 방식은 남은 수량과 '받은 사용자' 집합을 Lua 스크립트 하나에서 원자적으로 확인하고, PostgreSQL 기록은 @Async로 백그라운드에서 처리합니다.

크게 보기

무엇을 바꿨나

처음 표는 JIT와 커넥션 풀이 준비되지 않은 차가운 1회 실행이었습니다. scripts/bench.ps1에 warm-up, 3회 실행, 중앙값, 유효성 규칙(성공 + 품절 < 300이면 무효)을 넣고 다시 재자 두 결론이 뒤집혔습니다. 락 없음은 '가장 느림'이 아니라 '빠르지만 틀림'(80.4 → 307 rps)이었고, 낙관적 락은 '가장 느림'이 아니라 FOR UPDATE보다 1.76배 빨랐습니다(114.1 → 331 rps). 이유는 findByCodeForUpdate가 남은 수량을 확인하기 전에 락을 잡기 때문입니다. 개선책(락 전에 일반 SELECT로 품절 확인)은 아직 적용하지 않았습니다.

증상

2026-10-09 배포 후 flashdrop.javohir.dev UI가 깨지고 페이지에 <<<<<<< HEAD 문자열이 그대로 나왔습니다.

원인

로컬 저장소가 GitHub보다 뒤처져 push가 거부됐고, git pull 병합에서 4개 파일에 충돌이 났는데 표시를 지우지 않은 채 커밋됐습니다. 프론트엔드는 Caddy가 git 작업 디렉터리에서 바로 제공했기 때문에 git pull 즉시 프로덕션에 반영됐고, 백엔드 rollback은 프론트엔드를 되돌리지 못했습니다.

해결

마지막으로 정상 동작한 커밋에서 frontend/index.html을 복구하고 README를 다시 쓴 뒤, 실수로 커밋된 IDE 빌드 산출물(bin/)을 지우고 .gitignore에 추가해 다시 배포했습니다 (7ac0754).

재발 방지

deploy.sh가 git grep으로 upstream의 충돌 표시를 검사하고, 발견하면 배포를 멈춥니다. 병합은 --ff-only로만 합니다 (a2dd204). 숨은 후유증도 찾았습니다: 충돌을 고칠 때 README(ko/en/uz)가 예전 차가운 실행 표로 돌아가 있었고, 포트폴리오 문서를 repo와 대조하다 발견해 재측정 결과로 복구했습니다 (a29c567).

테스트 수

4

커버리지

—

CI

—

테스트 도구

JUnit 5, Testcontainers (PostgreSQL 17, Redis 7), virtual threads, k6, bench.ps1

배포 환경

iwinv VPS, Docker Compose: app(Spring Boot, non-root, 메모리 1GB 제한), web(Caddy: 정적 콘솔 + /api/* 프록시), PostgreSQL 17, Redis 7, seed(데모 캠페인). DB와 Redis 포트는 외부에 열지 않습니다. deploy.sh: 충돌 표시 검사 → git merge --ff-only → 이미지를 SHA 태그로도 빌드 → app과 web 갱신, SHA를 .deploy-history에 기록. HikariCP 50, Tomcat accept-count 500.

백업

매일 03:00(KST) cron으로 pg_dump, 7일 보관, 서버의 Postgres 9개 모두 대상. 2026-10-09 03:00 자동 실행 확인. 복원 시험: FlashDrop 0.22초(11/11 테이블), LedgerCore 0.66초(14/14 테이블)

롤백

rollback.sh는 이전 SHA 이미지를 latest로 지정해 빌드 없이 app을 다시 만듭니다. 프로덕션에서 명령은 real 0m1.201s, 외부에서 보면 03:32:00–03:32:07 동안 502 뒤 다시 200이었습니다.

모니터링

pg_stat_statements 활성화, 모니터링 네트워크로 PG Insight에 연결

• src/main/java/com/flashdrop/strategy/nolock/NoLockClaimService.java

  일부러 만든 lost update: 락 없이 읽기 → 확인 → 쓰기

• src/main/java/com/flashdrop/strategy/forupdate/ForUpdateCampaignRepository.java

  @Lock(PESSIMISTIC_WRITE) findByCodeForUpdate

• src/main/java/com/flashdrop/strategy/optimistic/OptimisticClaimAttempt.java

  self-invocation을 피하려고 별도 빈으로 뺀 트랜잭션

• src/main/resources/scripts/claim.lua

  중복, 남은 수량, 차감을 원자적 연산 하나로

• src/main/java/com/flashdrop/strategy/redis/RedisClaimService.java

  Lua 결과 코드를 비즈니스 상태로 바꾸고 DB 기록을 백그라운드로

• src/main/java/com/flashdrop/strategy/redis/RedisClaimWriteBackService.java

  Postgres에 @Async로 나중에 기록

• src/main/java/com/flashdrop/ratelimit/RateLimitInterceptor.java

  Bucket4j + Redis 토큰 버킷, 429와 Retry-After

• scripts/bench.ps1

  warm-up, 3회, 중앙값, 무효 실행 재실행

• scripts/deploy.sh, scripts/rollback.sh

  충돌 검사, SHA 태그 이미지, rollback

락 없음 방식은 50장 대신 300장을 발급했고(remaining_quantity는 0이 아니라 46), 나머지 세 방식은 300건 중 정확히 50건만 통과시켜 DB에도 정확히 50행이 남았습니다. Redis 방식은 FOR UPDATE보다 처리량 4.6배, p95 8.2배 좋았습니다. 수치는 warm-up 1회 뒤 유효한 3회의 중앙값이며, 성공 + 품절 합계가 300보다 적은 실행(TCP backlog로 일부 거부)은 자동으로 무효 처리하고 다시 실행했습니다. 레이트 리밋은 같은 userId로 12건 중 6건 통과, 6건 429(토큰 5개 + greedy refill)였습니다.