DB의 동시성(Concurrency) 제어와 트랜잭션 설계 고민
서비스를 운영하다 보면 "이 기능은 하나의 트랜잭션으로 묶여야 해!" 하는 순간이 온다.
트랜잭션 처리가 필요한 상황과 발생 할 수 있는 이슈에 대해 정리하고,
이런 이슈를 방지할 방안에 대해 고민해보려고 한다.
이슈1: 동시에 같은 요청이 들어오면? (A.K.A. 따닥)
다수 혹은 한명의 사용자가 동시에 같은 API를 여러번 호출해서 특정 리소스A를 수정이나 삭제하려고 한다면?
-> 예상치 못한 중복 처리, 데이터 불일치가 발생할 수 있음 (전형적인 동시성 문제)
728x90
해결방안1: 비관적 락 (Pessimistic Lock)
row-level lock 직접 걸기
@Lock(LockModeType.PESSIMISTIC_WRITE)
Optional<Data> findByIdForUpdate(Long id);
- 장점: 안전하게 처리 가능
- 단점: 성능 저하, 데드락
해결방안2: 낙관적 락 (Optimistic Lock)
version 필드를 두고 충돌이 날 것 같지 않다고 가정하고 먼저 처리한 뒤
최종 커밋 시점에 version 비교하여 충돌 여부 확인
@Entity
public class Product {
@Id
private Long id;
@Version
private Long version;
private int stock;
}- 장점: 락을 걸지 않아서 성능이 좋음
- 단점: 충돌 발생 시 예외 처리 및 재시도 로직 필요
동시 수정이 많을수록 실패율이 높아짐
해결방안3: 분산 락 (Distributed Lock)
로직 단에서 lock을 걸 때, 다중화 환경 지원을 위해 Redis 기반 락(Redisson) 등을 활용하여 직접 특정 key에 락 걸고 해제
RLock lock = redissonClient.getLock("lock:data1");
try {
if (lock.tryLock(5, 10, TimeUnit.SECONDS)) {
updateData();
}
} finally {
lock.unlock();
}- 장점: 여러 서버에서 동시에 접근할 때도 안전
트래픽 높은 분산 환경에서 유용 - 단점: Redis가 단일 실패 지점(SPOF)이 될 수 있음
락 유실, 타임아웃 등 관리 필요
해결방안4: 요청 자체의 중복 방지 (Idempotent 처리)
각 요청에 유일한 ID (X-Request-Id) 부여 및 체크하여 중복 방지
@PostMapping("/api/process")
public ResponseEntity<?> process(@RequestHeader("X-Request-Id") String requestId) {
if (requestService.isAlreadyProcessed(requestId)) {
return ResponseEntity.status(409).body("이미 처리된 요청입니다");
}
requestService.process();
}- 장점: 중복 호출에 DB Lock 없이 안전하게 동작
- 단점: 중복 체크용 저장소 필요 (DB, Redis 등)
DB와는 관계 없이 요청에 대한 중복만 체크 가능
이슈2: 트랜잭션 안에 오래 걸리는 작업이 있을때
예를 들어, 아래와 같은 기능의 메서드를 호출하는 API 를 만든다.
@Transactional
public void process() {
deleteData(); // 1. 데이터 삭제
someLongTask(); // 2. 오래 걸리는 작업 (ex. 외부 API, 복잡한 연산 등)
insertData(); // 3. 새로운 데이터 추가
}이런 트랜잭션이 걸린 메서드가 있을 때, 일반적으로 잘 동작하지만
트래픽이 많아지거나 동시에 여러 요청이 들어오면 아래와 같은 문제가 발생한다.
- DB 리소스를 오래 점유 → Lock이 유지됨
- 다른 요청들이 해당 리소스에 접근 시 지연(Lock 대기) 또는 타임아웃 발생
- 결국 전체 시스템의 응답 속도와 안정성에 영향을 줌
해결방안1: 트랜잭션 분리 전략
트랜잭션을 분리하여 오래 걸리는 작업은 비동기 처리(Kafka 등)
@Transactional
public void deleteData() { // 삭제는 즉시 처리
repository.deleteById(id);
}
public void enqueueProcessingJob() { // 오래걸리는 작업은 비동기 메시지 큐로 처리
kafkaProducer.send("data2-create", payload);
}- 장점: 트랜잭션 짧아져서 안정성이 높고 속도와 처리량 개선 가능
- 단점: 분산 시스템 복잡도 증가. 재시도, 보상 로직 추가 필요
728x90
반응형
'Java' 카테고리의 다른 글
| [Java] @FunctionalInterface 함수형 인터페이스 (0) | 2025.04.10 |
|---|