항해+ 백엔드 코드 5주차 회고 : 동시성 처리(Concurrency Control) 과제 정리 – 데이터 정합성과 성능 동시 확보하기 (항해 부트캠프 할인코드 있음)

이번 주차의 메인 주제는 동시성 처리 였습니다.

항해 20만원 할인 추천인코드: NYFKU8 

 

---

안녕하세요!

이번 포스팅에서는 제가 진행한 동시성 처리(Concurrency Control) 과제에 대해 정리해보려고 합니다.
실제 서비스 환경에서 자주 발생하는 경쟁 상황에서도 데이터 정합성을 지키면서 동시에 높은 성능을 내는 것이 목표였는데요,
제가 어떤 전략을 선택했고 어떻게 구현했는지, 그리고 검증 결과까지 자세히 공유합니다.

---

목차

1. 과제 개요 및 목표
2. 동시성 관련 기본 개념
3. 전략 선택과 도메인 매핑
4. 3계층 락 구현 방식
5. 주요 코드 및 테스트 결과
6. 성능 측정 및 결과
7. 전략 타당성 및 한계점
8. 마무리 요약

---

1. 과제 개요 및 목표

이번 과제의 주제는 바로 동시성 처리 입니다.
서비스가 커지고 여러 사용자가 동시에 요청할 때, 발생할 수 있는 데이터 충돌 문제를 방지하는 것이 핵심입니다.
목표는 경쟁 상황에서도 데이터 정합성(Consistency) 을 보장하고, 동시에 성능 저하를 최소화하는 것입니다.

---

2. 동시성 관련 기본 개념

• 트랜잭션과 ACID
  데이터 정합성을 보장하기 위해 트랜잭션은 반드시 ACID 원칙을 따라야 합니다.
  • Atomicity (원자성): 모두 성공하거나 모두 실패
  • Consistency (일관성): 데이터 일관성 유지
  • Isolation (고립성): 트랜잭션 간 간섭 방지
  • Durability (지속성): 완료된 트랜잭션 결과 영구 저장
• 격리 수준 (Isolation Level)
  성능과 안정성 사이 균형을 위해 보통 아래 중 선택합니다.
  • Read Committed
  • Repeatable Read
  • Serializable
• 동시성 문제 유형
  • Lost Update
  • Dirty Read
  • Non-Repeatable Read
  • Phantom Read

---

3. 전략 선택과 도메인 매핑

• 락 전략
  • 비관적 락: 충돌을 미리 방지하기 위해 선잠금, 안정적이지만 성능 부담 큼
  • 낙관적 락: 버전 비교 후 재시도 방식, 충돌 적으면 성능 우수
• 도메인별 전략 선택 기준
• 도메인충돌 빈도중요도락 전략

  쿠폰 발급 (선착순 보장)	높음	순서/수량 보장 필수	비관적 락
  포인트 충전/차감	중간	성능 중요	낙관적 락
  주문 생성, 회원가입, 결제	중간	성능 + 재시도 용이성	낙관적 락

   

---

4. 3계층 락 구현 방식

• 애플리케이션 레벨 락
  • @OptimisticLock, @PessimisticLock 데코레이터와 인터셉터로 적용
• Redis 분산 락
  • 다중 서버 환경에서의 동시성 이슈 방지용
  • RedisPessimisticLockInterceptor
• DB 물리적 락(보조적 사용)
  • FOR UPDATE 행 단위 락
  • 낙관적 락용 버전 컬럼 활용

---

5. 주요 코드 위치 및 테스트

• 데코레이터 & 인터셉터:
  src/common/decorators/*
  src/common/interceptors/*
• 레포지토리 적용:
  src/infrastructure/repositories/*.repository.ts
• 테스트:
  test/it/integration/concurrency.integration.spec.ts 외 다수

---

6. 검증 및 성능 결과

• 통합 테스트 59개 항목 모두 통과!
• 핵심 시나리오 검증 결과:
  • 동시 포인트 충전(10건) → 모두 성공 (낙관적 락 재시도 포함)
  • 동시 주문 생성(5건) → 재고 및 쿠폰 일관성 보장 성공
  • 중복 결제 방지 → 1건 성공, 2건 실패 (중복 차단 정상 작동)
  • 동시 쿠폰 발급(5건) → 선착순 순서 및 수량 보존
  • 트랜잭션 롤백 시 잔액 정상 복구
• 성능 측정 요약
• 작업요청수평균 처리 시간TPS(초당 처리량)

  포인트 충전 (10건)	10	57.4 ms	174 req/s
  주문 생성 (5건)	5	32.49 ms	154 req/s
  결제 (3건)	3	19.47 ms	154 req/s
  쿠폰 발급 (5건)	5	28.11 ms	178 req/s
  선착순 쿠폰 (3건 순차)	3	7.92 ms	379 req/s
  대량 처리 (포인트20/주문10/쿠폰15)	45	53~63 ms	159~318 req/s

   

---

7. 왜 이 전략이 타당한가?

• 쿠폰은 정확한 순서와 수량 보장이 비즈니스 핵심이므로,
  충돌을 즉시 제거하는 비관적 락이 적합합니다.
• 반면 포인트, 주문, 결제, 회원가입 등은 성능과 재시도 용이성이 중요하여,
  낙관적 락으로 처리량을 최적화하였습니다.
• Redis 분산락으로 다중 서버 환경에서도 확장성을 확보했고,
• DB 물리적 락은 보조적으로 사용해 병목 현상을 최소화했습니다.

---

8. 한계와 향후 계획

• 고경합 구간에 한해 물리적 락 강화 (NOWAIT/WAIT, 타임아웃 정책 적용)
• 분산 락 키 및 TTL 정책을 더 정교하게 설계
• 부하 테스트 자동화
• EXPLAIN 쿼리 및 인덱스 튜닝 주기적 실시
• 배치 작업 및 메시지 큐 도입 검토

---

마무리 한 줄 요약

“도메인 특성별 맞춤 락 전략과 애플리케이션/분산/DB 3계층 보호로 동시성과 성능을 모두 잡았다.”

---

궁금한 점이나 추가로 알고 싶은 부분이 있으면 댓글로 남겨주세요!
읽어주셔서 감사합니다. 🙌

 

 

📌 과제 링크

• Step09 PR
• Step10 PR

Step09 by seuthootDev · Pull Request #9 · seuthootDev/hanghae-plus-backend

 

Step10 by seuthootDev · Pull Request #10 · seuthootDev/hanghae-plus-backend