우리 서비스에 동시성 문제는 없을까요?

[f1v3-dev]

1. 모임을 생성할 때 미리 인원 수 만큼 일정을 만든다.
2. 회원/비회원이 일정을 할당할 때 미리 만들어진 일정을 업데이트 하는 방식을 사용한다.

ScheduleService.java

Schedule schedule = scheduleRepository.findNotAssignedScheduleByMeetingUuid(meetingUuid)
        .orElseThrow(ScheduleNotFoundException::new);

위와 같은 코드를 통해 미리 생성을 해뒀지만, 할당이 되지는 않은 일정 을 가져온 후 값을 넣고 있습니다.

현재 위와 같은 로직으로 진행이 되고 있는데 이러한 상황에서 발생할 수 있는 문제가 있다고 생각을 하는데 어떤 문제가 있을까요?

[RTUnu12]

일단.... 동시성 제어에 대해 이해가 부족해 지적이 정확하지 않을 수도 있습니다.

1. 중복 할당 문제

• 여러 사용자가 동시에 같은 미할당 Schedule을 할당할 수 있는 문제가 있습니다.
• 예를 들어 두 사용자가 동시에 findNotAssignedScheduleByMeetingUuid() 호출 시 같은 미할당 Schedule을 가져올 수 있고, 각자 자신의 정보로 업데이트하면서 하나의 Schedule이 중복 할당될 수 있어 보입니다.

2. Lost Update

• 위 문제와 이어지며, 여러 사용자가 같은 Schedule을 가져와 서로 다른 값으로 업데이트를 시도할 경우, 한 사용자의 값이 다른 사용자의 값으로 덮어씌워질 것 같습니다.
• 이로 인해 하나의 Schedule에 대한 정보가 최신 상태를 반영하지 못하게 되고, 특정 사용자의 업데이트가 사라질 수 있습니다.

[f1v3-dev]

저도 태웅님이랑 같은 생각으로 일정(Schedule) 이 공유 자원 이 되어서, 여러 스레드가 동시에 할당되지 않은 일정 조회 를 하게 되는게 가장 큰 문제라고 생각했어요.

이러한 문제를 해결하는 방법에 대해서 같이 고민해보고, 해결하면 좋을 것 같아요!

사실 이거 뿐 만 아니라, 다른 잠재적인 문제가 숨어있을 것 같다는 생각이 들긴 해요 ㅋㅋㅋㅋㅋㅋㅋ

[RTUnu12]

제가 생각한 방식인데 이건 어떻까요?

결국 Schedule에 여러 유저가 한번에 몰려서 동시성 문제가 발생하는 것이잖아요?

그래서 한 유저가 한 Schedule을 선점하면, 다른 유저들은 선택하지 못하게 하는 겁니다.

예를 들어서 isAssigned와 같은 예약 상태를 추가하고 이를 즉시 변경함으로써 다른 사용자 접근을 막는 방식입니다.

UPDATE schedule SET isAssigned = true WHERE meetingUuid = :meetingUuid AND isAssigned = false LIMIT 1쿼리를 통해 할 수 있어 보여요.

다른 좋은 생각 있나요?

[f1v3-dev]

태웅님이 말하신대로 즉각적으로 변경 할 수 있다면, 문제가 되지는 않을 것 같아요.
하지만, 하나의 트랜잭션으로 묶다보니 여전히 문제가 발생할 수 있다고도 생각이 드네용

지금 드는 생각은

1. Controller -> Service 와 같은 구조가 아닌 방식으로 중간 계층(ex. Facade)을 통해 트랜잭션을 분리하고 처리하는 방식
2. Lock 을 통해 접근을 시도하고, 접근이 되지 않았을 경우 (예외 발생과 같은 상황) 메서드 재호출?.. <- 이 방식도 추가적인 조치가 필요해 보이긴 해요

생각보다 쉽지 않은 것 같아요 ㅋㅋㅋㅋㅋ

지금, 재고시스템으로 알아보는 동시성이슈 해결방법 (1/3) - 동시성 이슈와 Application Level로 해결하기 여기 블로그에 있는 내용을 보면서 째깍에 어떻게 대입해볼지 생각중이에요 태웅님도 한 번 따라서 해보시고 같이 생각해보면 좋을 것 같습니다 😃

[f1v3-dev]

테스트

1. 모임 생성

동시성 테스트용 모임을 생성합니다.
해당 모임에는 5명의 인원만 입력할 수 있습니다.

2. 사용자의 일정 할당

동시에 100명의 사용자가 입력한다고 가정해보겠습니다.

테스트는 JMeter를 사용하여 테스트하였습니다.

위와 같은 Body를 담고 요청을 보내보겠습니다.

3. 문제 발생

원했던 상황은, 5명의 인원까지만 할당되고 다른 인원은 할당이 되지 않아야 합니다.
하지만, 10명의 인원이 일정을 할당해버린 오류가 발생하였어요.

우리가 예상했던 것 처럼 findNotAssignedScheduleByMeetingUuid 메서드에서 일정을 가져올 때 같은 일정을 가져오는 문제로 인해서 Lost Update 오류가 발생하는걸로 보여요.

[f1v3-dev]

문제를 해결해보자

1. Lock을 건다면?

제가 위에서 첨부했던 블로그를 참고해서, Redis를 통해 락을 거는 방식을 적용해보았어요.

• 기존: Controller -> Service
• 변경: Controller -> Facade (Redis Lock) -> Service

Facade 계층에서, 모임에 대해 잠시 락을 거는 방식을 생각해보았습니다.

ScheduleFacade.java

    public ScheduleAssignResponseDto assignScheduleToGuest(String meetingUuid, ScheduleAssignRequestDto requestDto) {
        String key = "meeting-" + meetingUuid;
        while (!redisRepository.lock(key)) {
            log.info("락 획득 실패");
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }

        try {
            return scheduleService.assignScheduleToGuest(meetingUuid, requestDto);
        } finally {
            redisRepository.delete(key);
        }
    }

while문을 통해, 락을 얻어올 때 까지 spin lock 방식을 통해 계속해서 획득을 요청하는 방식으로 구현해봤어요.

2. 테스트

Redis Lock 을 사용한 방식으로 테스트를 해봅시다.
테스트 환경은 위와 동일하게 진행하였습니다.

우리가 원했던 방법처럼, 들어온 순서대로 락을 얻은 후 일정을 할당하여 동시성 제어가 된 결과를 볼 수 있습니다.
하지만, 싱글 스레드인 레디스에 계속해서 락 획득을 요청하기 때문에 부하를 줄 수 있어요.
그렇기에 정말 많은 사용자가 동시에 요청한다면 피해야 할 것으로 보입니다.