다중화 어플리케이션 환경에서 동시성 처리하기

[Hongdonggeon]

일단 이 주제로 선정한 이유에 대해 말씀드리면, 공부할 포인트가 많다고 생각했어요
개인적으로 과제나 면접 경험이 많진 않지만, 그 적은 경험에서도 이 주제는 꼭 물어봤던 것 같습니다.
다중화 어플리케이션 환경에서 동시성 처리하는 방법만 생각해보는게 아닌 스레드 동기화, db lock, 저희가 보통 java 쓰니까 java에서 동기화 키워드 등등 여러가지 키워드들에 대해서 같이 공부해보면 좋을 것 같습니다!
최종적으로 정형화된 방법이 아닌 신선한 아이디어들을 기대하며 주제 던져봅니다!

[Hongdonggeon]

동시성 공부하다, 재밌는 예제를 발견해서요ㅎ
이 프로그램은 1초후에 종료될까요?

public class TestApplication {
    private static boolean stopRequested = false;

    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            int i = 0;
            while (stopRequested) {
                i++;
            }
        });
        backgroundThread.start();
        TimeUnit.SECONDS.sleep(1);
        stopRequested = true;
    }
}

[Hongdonggeon]

음..... 종료안될 것 같은디 사실 AtomicBoolean이 뭘해주는지 모르겠다

[Hongdonggeon]

• synchorized
• volatile
• atomic타입들 (AtomicBoolean)

이거 동작방식이랑 차이, 목적에 대해 같이 한번 알아보시죠!

[Hongdonggeon]

@kssumin 근데 읽고 쓰는 작업을 synchonized 사용하면 종료되는 것 같아요..?

public class TestApplication {
    private static boolean stopRequested = false;

    private static synchronized boolean stopRequested() {
        return stopRequested;
    }

    private static synchronized void requestStop() {
        stopRequested = true;
    }

    public static void main(String[] args) throws InterruptedException {
        Thread backgroundThread = new Thread(() -> {
            int i = 0;
            while (stopRequested()) {
                i++;
            }
        });
        backgroundThread.start();
        TimeUnit.SECONDS.sleep(1);
        requestStop();
    }
}

[belljun3395]

• synchorized
• volatile
• atomic타입들 (AtomicBoolean)

이거 동작방식이랑 차이, 목적에 대해 같이 한번 알아보시죠!

네!!

[Hongdonggeon]

스레드가 변수를 요청하면 RAM -> cache -> cpu register 경로로 가져옵니다. 변수 값이 업데이트 되면 읽어오는 역순의 경로 (cpu register -> cache -> RAM) 를 따릅니다.

CPU 입장에서 성능 개선을 위해 cache에 값을 저장해두고 읽고 쓰는 것이 유리하므로 데이터와 연산들을 캐시에 저장하는데, 이러한 캐싱으로 인해서 성능은 향상되지만 캐시 일관성 문제를 해결해야 됩니다.
위에 제가 올린 예제에서도 이러한 캐시 일관성 문제 때문에 메인 스레드에서 stopRequest의 값을 변경했지만 (여기서도 ram까지 변경되는 것이 아님?) backGroundThread가 값을 가져오는 캐시에서는 변경되지 않았기 때문에, while문에서 계속 돌게되는 현상이 일어나는 겁니다.

volatile

위의 문제를 해결하기 위해서 변수를 volatile로 선언하게 되면, 아래와 같이 값을 가져오므로 메모리 가시성 문제를 해결할 수 있게 됩니다.

• 모든 쓰기 작업은 바로 메인 메모리에 적용된다.
• 모든 읽기 작업은 메인 메모리로부터 직접 읽어온다.

volatile이 위와 같이 메모리 가시성 문제는 해결해주지만, 상호 배제 특징은 갖고 있지 않습니다.

private static volatile int a = 0;

public static int increase() {
  return a++;
}

volatile이 공유 자원에 락을 걸고 그런 행위는 해주지 않기 때문에, 멀티 스레드 환경에서 increase 메서드에 접근했을 때, 한 스레드가 a 의 값을 메모리에 변경하기 이전에 다른 스레드에서 a를 읽어와버렸다면, 예상치 못한 결과 값이 일어나게 될 것입니다.

참고)

• https://www.baeldung.com/java-volatile
• 이펙티브 자바 동시성 - 아이템 78

synchornized

자바에서 모든 객체들은 모니터를 가집니다. 모니터라는 개념을 이용해서 동기화를 보장하는데, A 스레드에서 모니터를 점유하게 되면 해당 객체에 lock을 걸 수 있고, 타 스레드에서 접근하지 못합니다.

이 때 모니터를 갖게 해주는 키워드가 synchronized !!
근데, synchonized가 객체의 접근을 막아주는 것은 아니고 synchronized 키워드를 붙인 메서드에 대한 접근을 막는 것이라고 합니다.

private static volatile int a = 0;

public static synchronized int increase() {
  return a++;
}

멀티 스레드 환경에서 a 스레드가 increase 메서드에 접근했다면, 타 스레드에서는 increase 메서드를 접근하지 못하게 되면서 상호배제가 보장됩니다.

또한, synchonized도 volatile 처럼 메모리 가시성을 확보해준다고 합니다.

• 스레드가 synchronized 블록에 진입할 때 모든 변수들은 메인메모리로부터 읽혀지게 된다.
• 스레드가 synchronized 블록을 빠져나갈 때 모든 변수들은 메인메모리에 쓰여지게 된다.

참고)

• https://velog.io/@destiny1616/Synchronized-%ED%82%A4%EC%9B%8C%EB%93%9C#%EB%A9%94%EB%AA%A8%EB%A6%AC-%EA%B0%80%EC%8B%9C%EC%84%B1%EA%B3%BC-happens-before

ATOMIC 객체

synchronized는 특정 스레드가 메서드 단위, 객체 단위까지도 락을 걸기 때문에 다른 스레드는 아무런 작업을 하지 못하고 기다리는 상황이 생기면서 성능이 저하되고 데드락이 발생할 수 있습니다.

이런 단점을 해결하기 위해서, non - blocking 하면서 동기화 문제를 해결해주는 방법이 ATOMIC 변수!!

ATOMIC 객체들도 메모리 가시성, 상호 배제를 둘다 보장합니다.

• 가시성 보장 (volatile - Atomic 객체 열어보면 안에 변수가 volatile로 선언되어 있음!! )


• 상호배제
  Compare and Swap 알고리즘을 이용해서 상호배제를 보장한다고 합니다.
  CAS 알고리즘에 대해서는 궁금하면 찾아보면 좋을 것 같아요..!

[imbf]

Pessimistic and Optimistic Locking Mechanism

Locking Mechanism 은 둘 이상의 서로 다른 프로세스/스레드(이하 스레드)가 동시에 공유 자원에 접근함을 통해 예측할 수 없고 프로그래머가 의도하지 않은 동시적인 이슈를 해결하기 위한 방법입니다. Locking Mechanism 은 크게 Pessimistic Locking 과 Optimistic Locking 으로 나뉩니다. Pessimistic Locking 은 다른 스레드가 특정 자원에 대한 접근을 끝낼 때까지 다른 스레드가 Lock 을 얻지 못하고 기다리는 것을 의미하구요. Optimistic Locking 은 여러 스레드가 특정 자원에 동시에 접근을 허용하고 변화를 영속화하는 시점에 자원에 대한 충돌을 검사하는 것입니다.

Pessimistic Locking 의 장점은 우선 매우 간단하다는 것이고요. 하나의 스레드가 공유 자원에 접근하는 과정에서 다른 스레드의 접근을 아예 허용조차 하지 않기 때문에 데이터의 무결성을 지킬 수 있다는 장점이 있습니다. 반면, 단점은 다른 스레드의 block 을 야기시킬 수 있기 때문에 성능 저하나 응답 속도 감소 등이 발생할 여지가 있구요. 특정 스레드가 Lock 이 풀리기 기다리는 Deadlock 이 발생할 수 있습니다.

Optimistic Locking 의 장점은 기본적으로 스레드를 Block 하지 않기 때문에 스레드 간의 경합이 적다면 성능이나 응답 속도가 Pessimistic Locking 에 비해 훨씬 빠르고요. 구현에 따라 다르지만 각 스레드가 Lock 을 최소한으로 얻거나 필요없는 경우도 있기 때문에 Deadlock 으로부터 비교적 자유롭습니다. 반면 단점은 충돌을 해소해야 하기 때문에 구현이 매우 복잡하고 사용이 불가능한 요구사항이 존재할 수 있다는 점인데요. 이 뿐만 아니라 구현에 따라서 일시적으로 일관되지 못한 데이터를 바라볼 수도 있다는 점을 감안해야 합니다.

각각의 동작방식을 간단히 살펴보면 다음과 같습니다. 이는 Pessimistic 과 Optimistic Locking Mechanism 의 여러 구현방식 중 가장 간단하면서 일반적인 구현 방식을 사용해서 이 두 방식을 설명한 예제입니다. 더 많고 디테일한 방법들이 많으니 요것이 이 두 방법의 전부라고 생각하지 않으셨으면 좋겠습니다.

Pessimistic Locking Mechanism in A Thread.

1. Acquire Lock: 공유 자원에 접근하기 전 A 스레드는 Lock 을 얻습니다. 만약 다른 스레드가 Lock 을 아직 Release 하지 않았다면 A 스레드는 기다립니다.
2. Access Resource: A 스레드가 Lock 을 얻었으면 공유 자원에 접근해 계획된 Task 를 수행합니다.
3. Release Lock: A 스레드가 연산을 모두 마쳤다면 Lock 을 Release 합니다. A 스레드의 Lock Release 를 기다리고 있던 다른 스레드가 있다면 해당 스레드가 Lock 을 얻고 지금의 프로세스를 반복합니다.

Optimistic Locking Mechanism in A Thread.

1. Read Resource: A 스레드는 버전 또는 최종 업데이트 시간과 함께 공유 자원을 읽어옵니다.
2. Modify Resource: A 스레드는 읽어온 자원을 바탕으로 연산을 수행합니다.
3. Check Version: 수행된 연산의 결과를 영속화 시키기 전 A 스레드는 공유 자원의 버전 또는 최종 업데이트 시간이 바뀌었는지 검증합니다. 만약 바뀌지 않았다면 결과를 영속화 시키고, 바뀌었다면 A 스레드의 연산을 롤백합니다.

Pessimistic 과 Optimistic Locking Mechanism 을 구현하기 위한 여러 방법들이 존재하는데 대표적인 방법은 다음과 같습니다.

pessismistic locking implementations

• mutex: Ensures that only one thread can access a resource at a time.
• Semaphore: Controls access to a resource pool with a fixed number of resources.
• spin lock: Provides a lock mechanism where the thread simply waits in a loop ("spins") while checking if the lock is available.

optimistic locking implementations

• compare and swap(CAS): Allows a variable to be updated only if it has not been changed since it was last read.
• read copy update(RCU): Provides a mechanism for multiple readers to access data concurrently with updates.

[imbf]

굉장히 정형화된 방법입니다만, 신선한 아이디어를 적용할만큼의 요구사항과 시간이 없어서 과거부터 조금은 궁금했던 부분을 조사해 보았습니다.

[Hongdonggeon]

사실 이번에 공부하고자 했던게 분산락이었는데, 오늘 synchronized랑 volatile 보다가 시간 다 가버렸네요..
조금 아쉬운감이 있어 분산락에 대해서도 공부하고 올리도록 하겠습니당

[belljun3395]

[Sprout-Symposium] 다중화 어플리케이션 환경에서 동시성 처리하기

들어가며

동시성 문제가 일어나는 여러 가지 상황이 있겠지만 저는 2가지 상황을 떠올릴 수 있었습니다.

• 요청에 의해 처리되는 데이터가 중요한 동시성
  • 카프카로 동시에 들어오는 중복된 발주를 수신하는 경우
  • 검수/검품 이슈 등록 시 더블 클릭, 네트워크 이슈로 인해 중복된 요청이 동시에 들어오는 경우
• 선착순과 같이 순서가 중요한 동시성
  • 선착순 쿠폰 차감

이번 글에서는 "순서가 중요한 동시성" 문제를 어플리케이션에서 어떻게 해결할 수 있을지 고민한 내용을 정리해보려 합니다.

Redisson 분산락

다중 어플리케이션 환경에서 동시성 문제 해결하기 위한 솔루션을 검색하며 Redisson을 활용한 분산락에 관한 내용을 접할 수 있었습니다.

// 특정 이름으로 락 정의 
RLock lock = redissonClient.getLock(key.toString());

try {
    // 락 획득을 시도한다(20초동안 시도를 할 예정이며 획득할 경우 1초안에 해제할 예정이다)
    boolean available = lock.tryLock(20, 1, TimeUnit.SECONDS);

    if (!available) {
        System.out.println("lock 획득 실패");
        return;
    }

    // 트랜잭션 로직(ex. orderService.createOrder(), stockService.increase())

} catch (InterruptedException e) {
    throw new RuntimeException(e);
} finally {
    if (lock.isLocked() && lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}

주로 위의 코드와 같이 redissonClient를 활용하여 일정 시간 동안 락을 획득하기 위해 시도하고 락을 획득하지 못하면 포기하는 예제를 확인할 수 있었습니다.

// version: redisson 3.16.0 RedissonLock 256 ~ 283
while (true) {
    long currentTime = System.currentTimeMillis();
    ttl = tryAcquire(waitTime, leaseTime, unit, threadId);
    // lock acquired
    if (ttl == null) {
        return true;
    }

    time -= System.currentTimeMillis() - currentTime;
    if (time <= 0) {
        acquireFailed(waitTime, unit, threadId);
        return false;
    }

    // waiting for message
    currentTime = System.currentTimeMillis();
    if (ttl >= 0 && ttl < time) {
        subscribeFuture.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
    } else {
        subscribeFuture.getNow().getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
    }

    time -= System.currentTimeMillis() - currentTime;
    if (time <= 0) {
        acquireFailed(waitTime, unit, threadId);
        return false;
    }
}

RedissonClient의 getLock 구현을 확인해 보아도 while 루프 속에서 일정 시간동안 락을 획득하기 위해 시도하는 코드를 확인할 수 있습니다.

예상되는 문제

하지만 위의 구현과 같이 일정 시간 동안 락을 획득하기 위해 시도하고 락을 획득하지 못하면 포기한다면 아래 이미지와 같은 문제가 일어날 수 있다고 생각합니다.

설명 : Request2보다 이후에 요청되었던 Request3이 먼저 처리되는 문제

스핀락

요청의 순서와 상관없이 처리되는 데이터가 문제가 없는 것이 중요한 상황이라면 이는 문제가 되지 않을 수 있지만 순서가 중요한 상황이라면 Redisson을 활용한 분산락은 적절한 선택이 되지 못할 것이라 생각하였습니다.

이에 스핀락에 조금의 구현을 추가하여 순서가 보장되는 락을 구현해보았습니다.

lock-local 구현 깃허브 바로가기

public interface LockService {

    boolean lock(Long id, Long userId);

    void unlock(Long id, Long userId);
}

lock(id)와 같이 id만 파라미터로 가지게 된다면 id에 대한 락을 획득할 수는 있지만 각 요청에 대한 식별을 할 수 없고 userId 파라미터와 같이 요청을 식별할 수 있는 파라미터를 추가하였습니다.

이에 해당 인터페이스를 우선 로컬 환경에서 구현한다면 아래의 LocalLockService 와 같이 구현할 수 있습니다.

locks를 통해 락에 관한 이력 관리를 수행하고 waitingQueue를 통해 순서를 보장하도록 구현하였습니다.

public class LocalLockService implements LockService {

    /**
     * key: lockId<br>
     * value: Pair&lt;userId, isLocked&gt;<br>
     */
    private final Map<Long, Pair<Long, Boolean>> locks = new ConcurrentHashMap<>();

    /** userId를 대기시키기 위한 Queue */
    private final Queue<Long> waitingQueue = new ConcurrentLinkedQueue<>();

    @Override
    public boolean lock(Long lockId, Long userId) {
        if (!waitingQueue.contains(userId)) {
            waitingQueue.add(userId);
        }

        Long peek = waitingQueue.peek();
        if (peek != null && peek.equals(userId)) {
            locks.put(lockId, Pair.of(userId, true));
            waitingQueue.poll();
            return true;
        } else {
            return false;
        }
    }

    @Override
    public void unlock(Long id, Long userId) {
        if (locks.containsKey(id) && locks.get(id).getLeft().equals(userId)) {
            locks.put(id, Pair.of(userId, false));
        }
    }
}

이를 다중화 어플리케이션 환경에 적용하기 위해서 Redis를 활용한 구현으로 변경한다면 아래와 같이 구현할 수 있습니다.

lock-redis 구현 깃허브 바로가기

public class RedisLockService implements LockService {

    private final RedisLockRepository redisLockRepository;

    private final RedisQueueRepository redisQueueRepository;

    public RedisLockService(
            RedisLockRepository redisLockRepository, RedisQueueRepository redisQueueRepository) {
        this.redisLockRepository = redisLockRepository;
        this.redisQueueRepository = redisQueueRepository;
    }

    @Override
    public boolean lock(Long lockId, Long userId) {
        if (!redisQueueRepository.isContain(userId.toString())) {
            redisQueueRepository.add(userId.toString());
        }

        String peek = redisQueueRepository.peek();
        if (peek != null && peek.equals(userId.toString())) {
            redisLockRepository.lock(lockId);
            redisQueueRepository.poll();
            return true;
        } else {
            return false;
        }
    }

    @Override
    public void unlock(Long id, Long userId) {
        redisLockRepository.unlock(id);
    }
}

LocalLockService에서는 ConcurrentHashMap과 ConcurrentLinkedQueue를 통해 락과 큐를 관리하였다면 RedisLockService에서는 이를 레디스를 활용해 관리한다는 것이 다를 뿐 다른 부분은 동일하게 구현할 수 있었습니다.

한계

이렇게 WaitingQueue 를 도입하여 순서를 보장하며 동시성 문제를 해결할 수 있지만 기존의 스핀 락 방식에 WaitingQueue를 위한 연산이 더해져 락 관리를 위한 레디스 서버에 부하는 여전할 것임을 예상할 수 있었습니다.

스핀락에서도 순서를 보장하지 않는다면?

스핀락에서도 순서를 보장하는 코드를 추가하지 않으면 아래 사진처럼 Request2와 Request3 중 어떤 요청이 먼저 처리될지 보장하지 못하는 문제가 발생할 수 있을 것이라 생각합니다.

락 대신 큐의 ACK를 활용한 방법

추가로 응답을 동기적으로 처리하는 것이 아닌 비동기적으로 처리하여도 괜찮은 경우 락을 대신해 큐의 ACK를 활용하여 보았습니다.

메시지 큐

메시지 큐는 FIFO 형식의 자료구조를 가지고 있고 이를 통해 요청의 순서를 보장할 수 있다 생각하였습니다.

명시적 ACK

AMQP 0-9-1 프로토콜에서 확인할 수 있는 **명시적 승인 모델(어플리케이션이 응답을 보낸다)**을 활용하였습니다.

락을 획득하는 대신 큐에서 메시지를 받은 어플리케이션에서 요청에 대한 처리가 완료된 이후 명시적으로 ACK를 큐에 보낸다면 동시성 문제를 겪지 않을 수 있을 것이라 생각하였습니다.

이를 코드로 메시지를 전송하는 서비스 클래스와 메시지를 처리하는 핸들러 클래스를 통해 간단히 구현해보았습니다.

queue-local 구현 깃허브 바로기기

@Service
public class SymposiumService {
  // ...
    public String execute() {
    // ...
        CountDownMessage message = new CountDownMessage(targetId, userId);
    // 메시지 전송
        messageTemplate.send(message);
    }
}

@Service
public class CountDownHandler implements MyMessageHandler<CountDownMessage> {
  // ...
    @Override
    public void onMessage(CountDownMessage message) {
        try {
      // ...
        } catch (Exception e) {
      // ...
        } finally {
      // 메시지 큐에 처리 완료 응답
            messageTemplate.ack();
        }
    }
}

이를 다중화 어플리케이션 환경에 적용하기 위해서 RabbitMQ를 메시지 큐로 활용한 구현으로 변경한다면 아래와 같이 구현할 수 있습니다.

queue-rabbitmq 구현 깃허브 바로가기

public class SymposiumService {

    private final RabbitTemplate messageTemplate;
    private final CountDownMessageRecords messageRepo;

    public SymposiumService(RabbitTemplate messageTemplate, CountDownMessageRecords messageRepo) {
       this.messageTemplate = messageTemplate;
       this.messageRepo = messageRepo;
    }

    public String execute() {
      // ...
       CountDownMessage message = new CountDownMessage(targetId, userId);
      // direct.waiting 익스체인지에 메시지 전송
       messageTemplate.convertAndSend("direct.waiting", "direct.waiting", message);
    }
}

한계점과 개선 방안

지금의 서비스 클래스 - 메시지 큐 - 핸들러 구조에서는 핸들러가 메시지를 하나씩 처리해야 동시성 문제에서 벗어날 수 있기에 병렬적으로 메시지를 처리하지 못한다는 한계가 존재합니다.

이에 메시지 큐 이전에 대기열 큐를 추가하여 이후 핸들러에 메시지를 하나씩 넘겨줌을 보장한다면 메시지를 처리하는 핸들러에서는 병렬적으로 메시지를 처리하여도 동시성 문제에서 벗어날 수 있을 것이라 생각하였습니다.

queue-rabbitmq-waiting 구현 깃허브 바로가기

public class RabbitWaitingHandler {
  // ...

    @RabbitListener(queues = "queue.waiting", concurrency = "1", ackMode = "MANUAL")
    public void onMessage(Message message, @Nullable Channel channel) throws IOException {
       try {
          byte[] body = message.getBody();
          CountDownMessage countDownMessage = objectMapper.readValue(body, CountDownMessage.class);
          int countDown = countDownService.getCountDown();
         // 컨슈머에서 동작을 수행할 수 있는 상황인지 확인한다.
          if (countDown > 0) {
            // 컨슈머 큐로 메시지 전송
            messageTemplate.convertAndSend("direct.waiting.consumer", "direct.waiting.consumer", message);
          } else {
             throw new RuntimeException(formattedMessage.getFormattedMessage());
          }
       } finally {
         // 메시지 처리 완료 ACK
          channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
       }
    }
}

public class RabbitCountDownHandler {
  // ...

  // concurrency를 통해 동시에 처리할 수 있는 RabbitListener의 갯수를 지정한다.
    @RabbitListener(queues = "queue.waiting.consumer", ackMode = "MANUAL", concurrency = "3")
    public void onMessage(Message message, @Nullable Channel channel) throws IOException {
       try {
         // 메시지를 처리한다.
       } catch (Exception e) {
         // ...
       } finally {
         // 메시지 처리 완료 ACK
          channel.basicAck(message.getMessageProperties().getDeliveryTag(), false);
       }
    }
}

테스트

상황 : 메시지 처리 과정에서 의도적으로 100ms의 지연을 추가하고 Jmeter를 통해 1011개의 요청을 처리하는 데 걸리는 시간

결과 :

• 단일 핸들러 구조 :105s
• 대기열 큐 + 멀티 핸들러 구조 (3개) : 35s

3개의 핸들러가 메시지를 처리하는 만큼 3배 정도 빠른 결과를 확인할 수 있었고 대기열 큐로 인해 동시성 문제도 겪지 않음을 확인할 수 있었습니다.

---

참고

https://helloworld.kurly.com/blog/distributed-redisson-lock/

https://incheol-jung.gitbook.io/docs/q-and-a/spring/redisson-trylock

[belljun3395]

(아직 미완이지만..)
아직 저는 고민의 범위가 구현을 벗어나기가 힘들어서 우선 구글링 통해 찾을 수 있는 라이브러리 활용 구현을 직접 자바로 구현해보는 방식으로 공부해보았습니다..!!
그래서 아직 로컬 환경 코드만 작성했는데 redis, rabbitmq를 활용한 다중화 어플리케이션 환경 코드는 작성하지 못해서 얼른 보충해서 추가하겠습니다.
완료했습니다~~!

[hyukjin-lee]

redisson 은 spin lock 방식이 아니라 pub sub lock 방식으로 알고 있습니다.
그리고 순서보장이 왜 필요하다고 생각하셨는지도 궁금해요 ~

[belljun3395]

요청 순서를 고려하지 않은 Redisson 분산락 경우

요청 순서를 고려하지 않은 스핀락 경우

아직 동시성 처리가 어떤 상황에서 필요한지 완전히 이해하지는 못했는데 제가 그래도 이해하고 필요한 상황이라 생각했던 상황이 선착순 쿠폰 차감과 같은 상황이었어요.
그래서 해당 상황에서는 요청의 순서도 고려해주어야 한다고 생각했습니다!

[belljun3395]

redisson 은 spin lock 방식이 아니라 pub sub lock 방식으로 알고 있습니다.

네!! 제가 위의 소제목을 너무 애매하게 달았나봐요..ㅎㅎ

그런데 찾아보다고 redisson getLock 구현을 봤는데 내부에서는 약간 spin lock 방식으로 구현된거 같아서 신기했어요

[Hongdonggeon]

자세히는 모르겠는데..
레디스 클라이언트에 lettuce랑 redisson이 있나봐요
lettuce는 setnx라는 명령어로 락을 획득할 수 있을때까지 명령어를 실행하는 spin lock 방법인 것 같고
redisson 은 pub sub 방식으로 레디스가 락을 획득할 수 있는 스레드에? publish 해주는 방식인의 차이가 있다고 이해했네요

[hyukjin-lee]

추가적인 인프라를 도입하는 것은 언제나 가능한 일도 아니며 관리 포인트와 장애 유발 포인트를 하나 더 늘리는 것이라고 생각해서 최후의 보루라는 생각이 듭니다.
웬만한 동시성 문제는 낙관락으로 해결이 가능하거나, 같은 자원에 동시에 접근하는 케이스가 적어서 비관락으로 풀어내도 괜찮은 경우가 대부분일 듯 하구요.

결국 서비스 관점에서 수많은 고객이 같은 자원에 접근하는 경우는 제한된 수량이 있는 경우일 것 같습니다.
그 외에는 같은 것에 대한 더블 클릭이나 admin 환경에서 서로 다른 담당자끼리 같은 자원에 접근하는 것이 있을 것 같습니다. (or wiki, figma 와 같은 편집기)

제한된 수량이 있고 트래픽이 높은 환경이라면 낙관락 방식을 먼저 고려하거나 DB 제약조건(constraint 로 count 에 조건 걸기) 을 쉽게 적용하는 것으로 끝낼 것 같습니다. 여러 고객이 실패 알림으로 인해 불편함을 겪겠지만 성능과 편의를 둘다 챙길 수 있는 방법은 딱히 본 적이 없는 것 같네요.

그리고 admin 환경에서는 보통 트래픽이 높지 않으니 단순히 비관락을 적용할 것 같습니다.
분산락이 논블로킹 방식이라 비관락에 비해 성능은 좋을 것 같지만 그만한 성능을 요하는 작업에서나 적용이 필요하지 않나라는 생각이 듭니다.
가장 먼저 고려되어야할 대상이거나 가장 좋은 방법은 아니라고 봅니다.

이 주제에 대해서는 다양한 동시성 이슈에 대한 사례를 모아보는 것이 좋지 않을까라는 생각도 드네요.
어떤 사례가 있는지 알아야 정형화된 기술적 해법들을 넘어서 좀 더 다양한 현업에 가까운 접근이 가능하지 않을까 싶습니다.

그리고 동시성/병렬성 관련해서는 실용주의 프로그래머 6장(동시성 241p) 과 가상 면접 사례로 배우는 대규모 시스템 설계 2 7장(호텔 예약 시스템 231p) 를 한번씩 보시는 것도 도움이 많이 될 것 같아서 추천드려봅니다.

이번 주제에 대해 따로 정리는 못해서 죄송한 마음에 스레드들 읽고 의견만 남겨보고 갑니다.
개인적으로 언젠가부터 분산락 또한 버즈워드가 된 것 같아서 한번 환기해보고 싶은 욕심도 있었습니다.

ps. 레디스 없던 시절엔 어떻게 했을까요?

[hyukjin-lee]

@imbf 네이버 예약 시스템에서는 만약 특정 시간대에 맛집 예약을 한다고 했을 때, 시간을 클릭하고 예약 주문서 들어가는 시점부터 락이 잡히는지 궁금합니다. (A 가 예약 진행중이면 B 는 해당 시간대를 선택할 수 없나요?)

[belljun3395]

그리고 동시성/병렬성 관련해서는 실용주의 프로그래머 6장(동시성 241p) 과 가상 면접 사례로 배우는 대규모 시스템 설계 2 7장(호텔 예약 시스템 231p) 를 한번씩 보시는 것도 도움이 많이 될 것 같아서 추천드려봅니다.

오 감사합니다~! 읽어볼께요!!

[imbf]

@hyukjin-lee

저희는 주문서 진입시점이 아니라, 실제 예약/주문을 신청하는 시점에 Redis 를 사용해서 요청을 직렬화합니다. Lock 은 따로 잡진 않아요.

[belljun3395]

동시성 문제

다수의 스레드가 동시에 공유 자원에 접근할 때 발생한다.

애플리케이션 개발에서의 동시성

다중 스레드

애플리케이션 개발에 주로 사용하는 스프링 부트의 경우 Tomcat을 내장하고 있다.

Tomcat은 다중 요청을 처리하기 위해, 부팅할 때 Thread Pool을 생성한다.

애플리케이션에서는 미리 생성한 Thread Pool의 Thread를 통해 유저의 요청을 처리한다.

이때 Thread는 동시에 공유 자원에 접근 할 수 있고 그 결과 동시성 문제가 발생할 수 있다.

공유 자원

애플리케이션 개발에서 공유자원은 DB에 저장된 정보가 대표적일 것 같다.

DB 공유 자원

DB에 저장된 정보에 접근하여 정보를 변경할 수 있는 고객이 여러 명이다.

• 글
  • 작성자
  • 재목
  • 내용
  • 조회 수
  • 좋아요

위와 같은 정보를 저장하고 있는 글 의 경우 제목, 내용에 대한 고객은 작성자 하나이자만 조회수, 좋아요에 대한 고객은 해당 기능의 요청을 하는 사용자로 여러 명이 될 수 있다.

• 상품
  • 상품 명
  • 가격
  • 재고

동시성 예시에서 가장 많이 등장하는 재고의 고객 역시 재고를 감소시키는 기능을 요청하는 사용자인 구매자가 여러 명이 될 수 있다.

DB 공유 자원 동시성 문제 상황

공유 정보의 값을 기반으로 공유 정보를 변경하는 요청을 수행하는 상황

DB 공유 자원을 변경하는 Request1 요청이 종료되기 이전에 Request2 요청이 시작되면 두 요청 모두 요청에 의한 값 변경 이전의 값을 기준으로 요청을 수행하게 된다. ( 위의 이미지에서는 두 요청 모두 0을 기준으로 요청을 수행 )

이에 공유 정보의 값을 기반으로 공유 정보를 변경하는 DB 조회 결과를 1 증가 요청이 동시에 2번 수행되어 정상적 요청에서 기대할 수 있는 결과인 2가 아닌 1이 결과로 저장되는 문제를 확인할 수 있다.

추가 예시 )

• 재고 차감 기능 예시 : 재고라는 공유자원을 차감하는 기능에서 발생할 수 있는 동시성 문제
• 좋아요 수 증가 예시: 좋아요라는 공유자원을 증가하는 기능에서 발생할 수 있는 동시성 문제

공유 정보의 값을 기준으로 이후 작업을 수행하는 상황

Reqest1~3은 요청 시 DB 공유 자원이 LAST ONE이기에 OK 응답을 받아 요청을 수행한다.

Request1 요청이 완료된 이후 DB 공유 자원을 조회한 Request4는 BAD 응답을 받아 요청을 수행하지 않는다.

이에 공유 정보의 값을 기준으로 이후 작업을 수행하는 작업이 동시에 3개 요청되어 기대하지 않았던 Request2~3 요청이 추가적으로 수행되는 문제를 확인할 수 있다.

추가 예시 )

• WVM 재고 할당과 취소 예시: 할당 상태를 기준으로 재고 할당과 취소 기능을 구현하여 발생한 동시성 문제

DB 공유 자원 동시성 문제 공통 사항

동시에 들어온 공용 자원의 변경이 포함된 여러 요청이 서로 다른 스레드에서 동시에 수행되며 요청에 따른 공용 자원의 변경 이전의 값을 사용하여 요청을 처리하고 있어 동시성 문제가 발생하는 것을 확인할 수 있다.

DB 공유 자원 동시성 문제 해결 방법

• DB
  • 낙관적 락
  • 비관적 락
• 애플리케이션
  • 스핀락
  • 분산락
  • 이벤트 소싱을 이용한 비동시성 문제로 전환

[belljun3395]

동시성 문제에 대해서 항상 애매해서 정리해 봤는데 요런 느낌이 맞을까요..?

[kssumin]

1. Single Thread

	@Test
	@DisplayName("딘일 스레드 환경에서 좋아요 요청 테스트")
	void single_thread_like() {
		// when
		for (Member member : members) {
			postLikeService.like(member.getId(), new CreatePostLikeRequest(post.getId()));
		}

		// then
		int likeCount = postRepository.getById(post.getId()).getLikeCount();
		Assertions.assertEquals(EXPECTED_LIKE_SIZE, likeCount);
	}

2. Multi Thread

	@Test
	@DisplayName("멀티 스레드 환경에서 좋아요 요청 테스트")
	void multi_thread_like() throws InterruptedException {
		// given
		ExecutorService executorService = Executors.newFixedThreadPool(30);
		CountDownLatch latch = new CountDownLatch(EXPECTED_LIKE_SIZE);

		AtomicInteger successCount = new AtomicInteger();
		AtomicInteger failCount = new AtomicInteger();

		// when
		for (Member member : members) {
			executorService.submit(
					() -> {
						try {
							postLikeService.like(member.getId(), request);
							successCount.incrementAndGet();
						} catch (Exception e) {
							failCount.incrementAndGet();
						} finally {
							latch.countDown();
						}
					});
		}

		latch.await();

		// then
		int likeCount = postRepository.getById(post.getId()).getLikeCount();
		Assertions.assertEquals(EXPECTED_LIKE_SIZE, likeCount);
	}

멀티스레드 환경에서 별도의 처리를 하지 않았을 때는 테스트 결과가 실패하였다.

심지어 갱신 손실 문제가 발생할 것이라는 것은 예상할 수 있는 문제였지만

deadlock이 발생하는 신기한 현상이 일어났다.

교착 상태가 왜 발생하더라?

둘 이상의 프로세스들이 **자원을 점유(Lock을 획득)**한 상태에서 서로 다른 프로세스가 점유하고 있는 **자원(Lock)**을 요구하며 무한정 기다리는 상황

그럼 LOCK이 사용되었다는 건데

내가 별도로 LOCK을 사용하지 않았으니깐 내가 사용한 쿼리에서 언제 LOCK을 사용하고 있는지 파악해보자

mysql 명령을 통해 deadlock history를 확인하였다.
s-lock, x-lock이라는 것을 획득하고 있는 것을 확인할 수 있다.

S-LOCK, X-LOCK은 무엇인가

S-Lock(Shared Lock)

• 데이터를 읽을 때 사용하는 Lock으로 데이터를 읽는 동안 수정이 발생하지 않음을 보장한다.
• 한 리소스에 두 개 이상의 S-Lock을 동시에 설정할 수 있다.
• X-Lock을 소유하고 있는 리소스는 읽지 못 한다.

X-Lock(Exclusive Lock)

• 데이터를 변경할 때 사용하는 Lock으로 쓰는 동안 수정이 발생하지 않음을 보장한다.
• 한 리소스에 하나의 X-Lock만 설정가능하다.
• 이때 MySQL의 Row-lovel Locking 특성으로 인해 행 전체

⭐ MySQL InnoDB는 SELECT시에 S-Lock을 걸지 않고 조회한다.

그렇다면 언제 S-LOCK, X-LOCK이 나간걸까?

S-Lock이 사용되는 상황

💡 fk가 있는 테이블에서, fk를 포함한 데이터를 insert, update, delete 하는 쿼리는 제약조건을 확인하기 위해 shared lock(s-lock)을 설정한다

• MySQL 5.6 Locks Set by Different SQL Statements in InnoDB

X-Lock이 사용되는 상황

💡 update 쿼리에 사용되는 모든 레코드에 exclusive lock(x-lock)이 설정된다.

• MySQL 5.6 Locks Set by Different SQL Statements in InnoDB

MySQL은 Row-Lovel Locking의 특성을 가지고 있다.

즉, 특정 행에 대해서 잠금을 걸지 않고 행 전체에 대해서 잠금을 건다.

코드에서 Lock이 걸리는 원인 확인

	public void like(Long memberId, CreatePostLikeRequest command) {
		Post post = postRepository.getById(command.postId());
		Member member = memberRepository.getById(memberId);
		PostLike postLike = toPostLike(post, member);
		
		postLike.like(postLikeValidator); // post에 대해 x-lock
		postLikeRepository.save(postLike); // post에 대해 s-lock
	}

post_like - post의 관계는 1:1 연관관계를 가지고 있다.

즉, post_like에서는 post의 id를 fk로 사용하고 있다.

따라서!!!

• post의 like_count를 update하는 시점에 post에 대해서 x-lock이 걸리게 된다.
• post_like가 insert되는 시점에 post에 대해서 s-lock이 걸리게 된다.

데드락 발생원인

• transaction1은 x-lock을 얻기 위해서 transaction2가 s-lock을 해제시키기를 기다린다.
• transaction2는 x-lock을 얻기 위해서 transaction1이 s-lock을 해제시키는 것을 기다린다.

즉 서로 S-Lock을 얻고 X-Lock을 얻기 위해 서로를 대기하는 상황이 발생한다.

해결책 1. 점유 대기를 하는 상황을 없애버리자(with 낙관적 락)

	@Lock(LockModeType.PESSIMISTIC_WRITE)
	@Query("SELECT p FROM Post p WHERE p.id = :postId")
	Post findByIdWithLock(@Param("postId") Long postId);

현 트랜젝션이 완료될 때까지 다른 트랜젝션에서 해당 행을 수정하지 못 하도록 행을 잠그는 sql이 나간 것을 확인할 수 있다.

생각 : 낙관적 락으로도 해결할 수 있을까?

우선 FK가 존재하기 때문에 s-lock은 발생할 수 밖에 없다.

따라서 낙관적 락을 사용한다고 해도 데드락을 피할 수는 없다.

실패 1. 낙관적 락만 적용

똑같이 s-lock을 획득한 상태에서 x-lock을 획득하기 위해서 다른 transaction이 s-lock를 해제시키는 것을 무한정으로 기다리게 된다.

실패 2. synchronized만 적용

각 스레드가 공유 자원을 동시에 접근해서 생긴 일이므로

공유 자원에 두 개 이상의 스레드가 접근할 수 없도록 synchronized를 적용하자

synchronized를 적용했지만 테스트가 실패했다.

	public synchronized void like(Long memberId, CreatePostLikeRequest command) {
		Post post = postRepository.getById(command.postId());
		Member member = memberRepository.getById(memberId);
		PostLike postLike = toPostLike(post, member);

		postLike.like(postLikeValidator);
		postLikeRepository.save(postLike);
	}

그 이유는 transactional은 Spring AOP 방식으로 동작한다.

따라서 like 메서드를 호출하게 되면 해당 메서드에 대한 proxy 객체를 생성하고

proxy 객체에서 transaction을 start 및 commit한다.

따라서 like 메서드에만 한 트랜젝션이 접근할 수 있다라는 제약사항이 있으므로

proxy객체에서 commit을 하기 전에 다른 트랜젝션에서 transaction을 시작할 수 있다.

해결책 2. 낙관적 락 + synchronized를 적용하자

	@Transactional
	@Retryable(
			retryFor = {ObjectOptimisticLockingFailureException.class},
			maxAttempts = 1000,
			backoff = @Backoff(100))
	public synchronized void like(Long memberId, CreatePostLikeRequest command) {
		Post post = postRepository.getById(command.postId());
		Member member = memberRepository.getById(memberId);
		PostLike postLike = toPostLike(post, member);

		postLike.like(postLikeValidator);
		postLikeRepository.save(postLike);
	}

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor(access = AccessLevel.PRIVATE)
@ToString
@SuperBuilder(toBuilder = true)
@Entity
public class Post {
	@Id
	@GeneratedValue(strategy = GenerationType.IDENTITY)
	private Long id;

	private String content;
	private String color;
	@OneToOne private Member member;

	@Embedded private Coordinate coordinate;

	private int likeCount = 0;
	@Version private Long version;

	public void clickLike() {
		this.likeCount++;
	}

	public void cancelLike() {
		if (likeCount == 0) {
			throw new PostLikeCountNegativeException();
		}
		this.likeCount--;
	}
}

그러나 단일 서버인 경우에만 synchronized가 유효하다라는 문제점이 있다.

문제점

단일 DB 환경 또는 단일 서버일 경우에만 해결이 된다.

또한 좋아요 같은 경우는 순차적으로 처리되지 않아도 되는데 비관적 락을 적용했을 때는 마치 선착순 처리처럼 순차적으로 처리가 된다.