[싹틔움] 11/13 개발일지 쿠폰 발급 시 동시성 문제 해결 1 : 동시성 문제 발생 및 낙관적, 비관적, 분산 락

💡 목표

쿠폰 300 개를 유저 1000 명이 5초동안 발급을 받기 위해 테스트를 진행했는데, 중복된 쿠폰이 발급된다든지, 수량 300 개를 넘어서서 발급이 되는 문제가 발생했다.

이를 해결하기 위해서 락을 걸어 동시성 문제를 해결할 필요가 있었다.

 

 

📝 Test : 락을 적용하지 않은 상태의 동시성 문제 확인

• Number of Threads (users) : 1000
• Ramp-up period (seconds) : 5
• Loop Count : 1
• 발급한 유효 쿠폰 수 : 300
• 실제 쿠폰을 발급받은 유저 수 : 595

 

위 이미지와 같이 남은 쿠폰 수도 잘 줄지 않고 중복으로 발급되는 쿠폰이 많이 발생.

실제로 같은 코드의 쿠폰을 발급받은 유저도 많다.

응답 처리속도는 평균 약 171 ms 가 나왔다.

 

결론

많은 트래픽이 몰렸을 때 쿠폰 발급 요청에서 동시성 문제가 발생한다.

이에 맞는 해결책을 찾기 위해서 낙관적 락, 비관적 락, 분산 락에 대해서 알아보았다.

---

🌱 낙관적 락 ( Optimistic Lock )

@Entity
public class Product {
    @Id
    private Long id;

    @Version
    private int version;

    private String name;
    private int quantity;
    // getters and setters
}

 

📚 상황 예시

A 와 B 가 동시에 같은 Product 를 조회해서 수정한다고 가정

조회 시점의 version 은 1 이라고 했을 때,

A 가 Product 를 수정해서 version 을 2 로 올린다.

그 때 B 가 수정을 요청하면 여전히 B 에서 version 은 1 이기 때문에 충돌을 감지하고 예외를 발생.

-> B 는 수정을 롤백하고 다시 작업을 시도해야한다.

📚 장점

• 락이 걸리지 않음: 데이터에 락을 걸지 않고 수정하므로 동시성 성능이 좋다. 즉, 다른 트랜잭션이 락에 막히지 않고 데이터를 읽거나 수정할 수 있다.
• 낮은 리소스 사용: 비관적 락과 달리, 데이터를 수정하기 전까지는 락을 걸지 않으므로 리소스 사용이 줄어든다.

📚 단점

• 충돌 발생 시 재시도 필요: 만약 충돌이 발생하면 예외가 발생하고 트랜잭션을 다시 시도해야 한다. 충돌이 빈번하다면 비관적 락이 더 적합할 수 있다.
• 충돌 감지 및 관리 복잡성: 충돌을 감지하고 재시도하는 로직을 관리해야 하는 복잡성이 생긴다.

📚 요약

낙관적 락은 충돌 가능성이 낮은 경우에 유용하며, 충돌 시에는 예외를 발생시켜 재시도가 필요하다. 따라서 데이터 충돌이 자주 일어나지 않는 환경에서 성능 최적화에 좋다.

---

🌱 비관적 락 ( Pessimistic Lock )

import javax.persistence.LockModeType;

@Transactional
public Product updateProductQuantity(Long productId, int newQuantity) {
    Product product = entityManager.find(Product.class, productId, LockModeType.PESSIMISTIC_WRITE);
    product.setQuantity(newQuantity);
    return product;
}

 

위 코드에서 LockModeType.PESSIMISTIC_WRITE 옵션을 통해 데이터베이스에 비관적 락을 설정하고, 해당 데이터에 다른 트랜잭션이 접근하지 못하도록 한다.

📚 상황 예시

A 가 Product 의 quantity 를 수정한다고 가정.

A 는 먼저 데이터베이스에서 SELECT ... FOR UPDATE 쿼리를 실행하여 비관적 락을 설정

A 의 트랜잭션이 끝나기 전까지 다른 사용자는 해당 Product 쿼리에 접근할 수 없다.

 

이후 A 가 quantity 를 수정하고 커밋하면 락이 해제된다.

📚 장점

• 강력한 충돌 방지: 다른 트랜잭션이 데이터를 수정하지 못하도록 강력히 제어할 수 있어 데이터 정합성이 보장된다.
• 재시도가 필요 없음: 데이터 수정 전부터 락이 걸려 있어 충돌이 발생하지 않으므로, 충돌로 인한 예외 처리나 재시도 로직이 필요 없다.

📚 단점

• 성능 저하: 비관적 락은 트랜잭션이 종료될 때까지 락을 유지하므로, 대기 시간이 발생해 성능 저하를 일으킬 수 있다.
• 데드락 위험: 여러 트랜잭션이 서로 다른 데이터를 동시에 락을 걸려고 할 때, 데드락이 발생할 수 있다.

📚 요약

비관적 락은 데이터 충돌 가능성이 높거나, 강력한 데이터 정합성이 필요한 경우에 적합하다.

하지만 성능 저하와 데드락 위험이 있어, 충돌 가능성이 적은 경우라면 낙관적 락이 더 나은 선택일 수 있다.

---

🌱 분산 락 ( Distributed Lock ) - Redisson

import org.redisson.api.RLock;
import java.util.concurrent.TimeUnit;

// 락을 설정하고 사용할 키 이름 정의
String lockKey = "product:lock";

// 락을 가져오기
RLock lock = redissonClient.getLock(lockKey);

try {
        // 락을 획득하려고 시도, 10초 동안 기다리고 5초 동안 락 유지
        if (lock.tryLock(10, 5, TimeUnit.SECONDS)) {
        // 락을 획득했다면 실행할 코드
        System.out.println("Lock acquired, executing critical section.");
// 중요한 작업 수행 (예: 재고 수량 감소 등)
    } else {
            // 락을 얻지 못하면 실행할 코드
            System.out.println("Could not acquire lock, try again later.");
    }
            } catch (InterruptedException e) {
        e.printStackTrace();
} finally {
        // 락 해제
        if (lock.isHeldByCurrentThread()) {
        lock.unlock();
        System.out.println("Lock released.");
    }
            }

 

📚 상황 예시

A 가 Product 의 quantity 를 수정한다고 가정.

한 번에 하나의 프로세스만 Product 를 확인하고 변경할 수 있기 때문에 

먼저 요청이 들어온 A 가 락을 획득하고 Product 를 확인, 변경.

 

B 요청이 들어오면 고객 A 의 처리가 완료될 때 까지 기다리거나 "재시도" 와 같은 메세지를 보여주게 함.

고객 A의 처리가 완료되면 락이 해제되고, 고객 B가 락을 획득하여 동일한 프로세스를 수행

 

• lock.tryLock(10, 5, TimeUnit.SECONDS): 락을 획득할 때 10초 동안 기다리며, 락을 획득하면 5초 동안 유지, 이로써 데드락을 방지할 수 있다.
• isHeldByCurrentThread(): 락을 현재 스레드가 보유하고 있는지 확인하여, 현재 스레드만 락을 해제할 수 있게 한다.
• unlock(): 작업이 끝나면 락을 해제하여 다른 프로세스가 접근할 수 있도록 한다.

 

📚 장점

• 간편한 사용: Redisson을 사용하면 락 설정과 해제 로직을 쉽게 구현할 수 있다.
• TTL 관리 용이: 자동으로 만료 시간이 설정되므로, 데드락 방지가 쉽다.
• 높은 성능과 확장성: Redis를 활용해 높은 성능과 확장성을 제공하며, 다중 프로세스 간 락을 쉽게 관리할 수 있다.

📚 단점

• Redis 의존성: Redis 서버의 장애가 발생하면 락 관리가 불가능해질 수 있다.
• TTL 설정 주의 필요: 너무 짧게 설정할 경우, 작업이 끝나기 전에 락이 해제될 위험이 있다.

📚 요약

비관적 락은 데이터 충돌 가능성이 높거나, 강력한 데이터 정합성이 필요한 경우에 적합하다.

하지만 성능 저하와 데드락 위험이 있어, 충돌 가능성이 적은 경우라면 낙관적 락이 더 나은 선택일 수 있다.

Redisson을 이용한 Redis 기반의 분산 락은 다중 서버 환경에서 데이터 일관성을 유지하면서 자원 접근을 관리할 수 있는 효율적인 방법이다.

Redisson이 제공하는 다양한 락 기능을 활용하면 분산 시스템에서 데드락 방지와 성능 최적화가 가능하다.

---

💡 결론

쿠폰이 발급 될 때 쿠폰 데이터에 접근해서 쿠폰 발급 상태를 자주 수정해줘야 하기 때문에 낙관적 락은 충돌 처리나 상태 관리가 복잡해 질 수 있고,

 

비관적 락은 쿠폰 발급과 같은 고속 처리가 필요한 상황에서 성능 저하를 생각하면 바람직하지 않다.

 

이후 확장성을 고려해 분산 캐시 시스템인 Redisson 을 이용한 분산 락을 사용해보기로 결정했다.