동시성 문제를 해결하는 여러가지 방법

소프트웨어 개발에서 동시성 문제는 데이터 일관성과 시스템 안정성을 위해 반드시 고려해야 하는 요소다. 특히, 데이터베이스를 다루는 애플리케이션에서는 여러 사용자의 요청을 동시에 처리하면서도 데이터의 정확성을 유지하는 것이 핵심이다.

 

 

선착순 이벤트나 재고 처리는 동시성(Concurrency) 문제가 발생하기 쉬운 영역으로, 다수의 요청이 동시에 처리될 때 정확성과 일관성을 유지해야 한다. 이를 해결하기 위해 다양한 동시성 제어 방법을 사용할 수 있으며, 시스템의 요구 사항과 트래픽에 따라 적합한 방법을 선택해야 한다.

 

 

1. 데이터베이스 레벨에서 동시성 제어

트랜잭션 & 락

데이터베이스 트랜잭션을 사용하여 SELECT ... FOR UPDATE로 재고를 조회하고 업데이트 시 락을 걸어 동시성을 제어. 비관적 락의 일종이다.

START TRANSACTION;
SELECT stock FROM inventory WHERE product_id = 1 FOR UPDATE;
UPDATE inventory SET stock = stock - 1 WHERE product_id = 1 AND stock > 0;
COMMIT;

 

데이터베이스 수준에서 정확한 동시성을 보장해 준다. 하지만 락이 걸린 상태에선 해당 트랜잭션이 완료될 때까지 다른 트랜잭션이 데이터에 접근하지 못한다. 그래서 높은 트래픽에서 성능저하 문제를 일으킬 수 있다.

또한 분산 데이터베이스에선 락이 한 곳의 데이터만 잠금을 걸기에 다른 데이터베이스의 데이터는 접근 가능하기에 한계가 있다.

 

비관적 락(Pessimistic Lock)

충돌이 발생할 가능성이 높은 경우 사용되는 동시성 제어 기법이다. 위에 트랜잭션 & 락과 같이 데이터베이스에 락을 거는 방식이다.  애플리케이션 코드에서 설정이 가능하다.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("SELECT p FROM Product p WHERE p.id = :id")
Product findProductForUpdate(@Param("id") Long id);

 

데이터를 읽거나 수정하기 전에 LOCK 을 획득하여 다른 트랜잭션의 액세스를 차단한다. 

 

동시성 문제가 빈번하게 일어난다면 rollback의 횟수를 줄일 수 있기 때문에 성능적으로 좋다. 모든 트랜젝션에 lock을 사용하기 때문에, lock이 필요하지 않은 상황이더라도 무조건 lock을 걸어서 성능상 문제가 될 수 있다. 특히 read 작업이 많이 일어나는 경우 단점이 될 수 있다. 또한, 선착순 이벤트같이 많은 트래픽이 몰리는 상황이나 여러 테이블에 lock을 걸면서 서로 자원이 필요한 경우, 데드락이 발생할 수 있고 이는 비관적 락으로 해결할 수 없는 부분이다.

또한 똑같이 분산 데이터베이스 환경에서도 제한적이다.

 

낙관적 락(Optimistic Lock)

낙관적 락은 데이터 변경 시점에만 충돌을 검사하는 방식이다. 왜냐하면 낙관적 락은 데이터 충돌이 자주 발생하지 않는 상황에서 성능을 최적화하기 위해 사용되기 때문이다.

레코드에 version 필드를 추가하고, 업데이트 시 체크한다. 만약 version이 변경되었으면 재시도(충돌 감지) 을 통해 충돌을 해결한다. 자원에 Lock을 직접 걸어서 선점하지 않고, 동시성 문제가 실제로 발생하면 그때가서 처리하는 방식이다. 자원을 읽었을 때 버전이 7이었는데 수정하려고 하니 버전이 8 이면 그 사이에 다른 트랜잭션이 와서 상태를 업데이트 했다는 뜻이된다. 그럼 트랜잭선을 롤백해서 다시 처리한다. 

@Entity
public class {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private int stock;
    
    @Version
    private Long version;
}

 

실제로 lock을 사용하지 않고 version을 이용함으로서 정합성을 맞추기에 성능면에서 유리하다. 하지만 동시성 문제가 빈번하게 일어나면 계속 rollback 처리를 해주어야 한다.

분산 데이터베이스 환경에서도 제한적이다.

 

 

 

 

2. 애플리케이션 레벨에서 동시성 제어

Synchronized 키워드 사용

Java의 synchronized 키워드를 사용하여 특정 코드 블록의 동시 실행을 차단한다. 

public synchronized void updateStock(int productId, int quantity) {
    // 재고 처리 로직
}

 

간단히 구현이 가능하지만, 단일 애플리케이션에서만 작동하기에 서버가 여러 개인 분산 시스템 환경에서는 사용할 수 없다. 

 

분산락 사용

분산락은 여러 애플리케이션 또는 프로세스 간에 공유된 자원에 대한 동시 액세스를 제어하기 위해 사용된다.

웹 애플리케이션에선 대부분 Redis, Zookeeper 등을 활용하여 분산 환경에서 락을 구현한다. 분산 시스템에서 애플리케이션은 공유 자원에 접근하기 전에 락을 요청다. 락이 성공적으로 획득되면 작업을 수행하고, 완료 후 락을 해제다. 락이 이미 점유 중이라면, 요청은 실패하거나 대기 상태로 처리된다.

private final RedissonClient redissonClient;

    public DistributedLockExample(RedissonClient redissonClient) {
        this.redissonClient = redissonClient;
    }

    public void executeCriticalTask() {
        RLock lock = redissonClient.getLock("criticalTaskLock");
        try {
            if (lock.tryLock(10, 30, TimeUnit.SECONDS)) { // 락 시도 (최대 10초 대기, 30초 유지)
                // 공유 자원 작업
                System.out.println("Lock acquired, executing critical task...");
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        } finally {
            lock.unlock(); // 락 해제
            System.out.println("Lock released.");
        }
    }

 

분산환경에서도 락 구현이 가능하기 때문에 널리 사용되는 방식이다. 분산 락은 외부 시스템이 관리하여 락의 상태를 중앙에서 관리한다. 따라서 애플리케이션이나 DB에 락을 거는 것이 아니기 때문에 높은 성능과 안정성을 제공한다. 

Redis를 활용하기에 Redis 구축 이해를 필요로 하고, 락 획득 및 해제 실패 시 복구 로직 필요하다. 또한 네트워크 지연이나 장애로 인한 문제에 대비할 수 있어야 한다.

 

3. 미들웨어를 활용한 동시성 제어

메시지 큐 같은 미들웨어를 활용한 방법이다. 모든 재고 처리 요청을 메시지 큐(Kafka, RabbitMQ 등)에 넣고 순차적으로 처리한다. 생산자(Producer)가 요청을 큐에 보내고, 소비자(Consumer)가 이를 하나씩 처리한다. 비동기 처리로 요청을 즉시 처리하지 않고 큐나 이벤트 로그에 저장한 뒤 순차적으로 처리한다.

트래픽 급증에도 안정적인 처리 가능하다. 큐에 있는 요청을 소비하며 동작하기에 동시성 문제가 발생하지 않는다. 로그 기반의 Kafka를 사용한다면 모든 이벤트들을 로그 형식으로 남기기 때문에 변경 사항을 추적할 수 있다.

요청에 대해 동기적으로 처리 하지 않고 네트워크 통신을 하기에 약간의 지연이 발생할 수 있다.

중복 처리, 순서 문제, 병목 현상 등이 발생할 가능성은 존재하기에, 멱등성 설계, 순서 보장 메커니즘, Consumer 확장 등의 전략을 사용해 한다. 또한 추가적인 미들웨어를 활용하기에 이에대한 이해와 구축 및 관리가 필요하다.