동시성 문제에 대한 고민과 해결 과정

1. 개요

현재 진행중인 창업 프로젝트의 기능 개발이 대부분 끝나고, 사업자가 나와야 할 수 있는 SMS, 알림톡 부분과 뱅킹 기능만이 남았다. 

 

지난 5개월간 정신없이 기능 개발에 집중하다보니 미흡한 부분이 꽤나 보였고 최근엔 하나하나 리펙터링 과정을 밟고있다. 

 

꼼꼼히 지난 코드를 살피던 중 동시성 문제가 발생할 만한 로직이 발견됐고 이를 해결하고자 Thread-Safe, 동시성 문제에 대해 공부하게 됐다.

 

아래 게시글에서 공부했던 내용들을 정리해뒀다. 

 

https://dgjinsu.tistory.com/53

멀티 쓰레드 사용 시 꼭 알아야 할 내용 - Thread-Safe

 

https://dgjinsu.tistory.com/54

Spring Boot 의 다중 유저 요청 처리 방법 (Tomcat)

 

하지만 내 코드의 동시성 문제는 일반적으로 동시성 문제로 다루는 상황들과는 조금은 달랐다. 

 

 

 

 

 

 

 

 

2. 문제 상황

위 사진은 내 코드에서 동시성 문제가 발생하는 상황을 조금이나마 이해하기 쉽도록 그린 사진이다. 

 

문제 상황을 글로도 표현하면 다음과 같다.

 

개발 요구 사항

같은 날짜에 노동자는 두 개의 일을 할 수 없다. 즉, 한 개 이상의 status 가 accepted인 Apply(지원) 이 있으면 안 됨.

 

노동자는 일자리 공고에 지원(Apply)할 수 있고 기업이 해당 노동자의 지원(Apply)를 수락해야 확정이 된다. 수락 전의 지원(Apply)의 status는 pending이다. 

수락을 하면 지원(Apply)의 status 필드는 accepted로 변경된다.

 

노동자는 기업으로부터 일자리를 제안(Offer) 받을 수 있다. 제안(Offer)은 노동자가 수락하면 바로 일자리가 확정된다. 노동자가 제안(Offer)를 수락하면 status 가 accepted인 Apply(지원) 을 생성한다.

 

 

그렇다면 기업이 노동자A의 지원을 수락하는 동시에, 노동자A가 제안받은 일자리를 수락한다면 status 가 accepted인 Apply(지원) 이 두 개 생기게 된다. 

 

바로 여기서 동시성 문제가 발생하는 것이다. 

 

 

그렇다면 위에서 일반적인 동시성 상황과는 다르다고 한 이유는 뭘까?

 

일반적인 동시성 문제에선 하나의 공유 자원을 수정할 때를 많이 다룬다. 이런 경우 락을 걸어 해결하지만, 나는 Apply(지원)을 새로 생성하기 때문에 락을 걸기에 애매했다. 

 

 

 

 

 

 

 

 

 

3. 해결 방안

처음 떠올린 방안은 메신저 큐 같은 큐 서비스를 사용해서 두 엔드포인트에 대한 처리를 병렬로 처리하지 않도록 하는 방안을 떠올렸다. 

 

카프카 같은 기술을 도입하기엔 아직 부담스러웠고, 다른 방법을 찾다 락을 걸 수 있는 상황으로 로직 설계를 바꿔보기로 했다. 

 

Apply(지원) 데이터를 새로 생성하기 때문에 락이 걸기 힘들었으니, Offer(제안)할 때 Apply(지원) 데이터까지 미리 넣어두면 락을 걸어 동시성을 예방할 수 있을거라 생각했다. 

 

 

 

동시성 문제를 해결해야하는 코드이다.

public void processOffer(Long workerId, OfferProcessRequest request) {
    // 생략

    // 요청에 따라 Apply 삭제 or status 업데이트
    Apply offeredApply = applyRepository.findOfferedApply(worker.getId(), workDate.getId())
            .orElseThrow(() -> new CustomException(ErrorCode.APPLY_OFFERED_NOT_FOUND));

    // 수락일 때
    if (request.getIsAccept()) {
        // 생략
        
        // 모집된 인원 증가
        workDate.plusRegisteredNum(1);

        // 제안 받으며 자동으로 생긴 지원 기록 승인 처리
        offeredApply.updateStatus(ApplyStatus.ACCEPTED, LocalDateTime.now());

        //생략
    }
    // 거절일 때
    else {
        // 제안 받으며 자동으로 생긴 지원 기록 제거
        applyRepository.delete(offeredApply);
    }

    // 생략
}

 

위 코드에서 조회한 offerdApply의 status를 업데이트 하는 중, 기업이 다른 Apply(제안)을 기업이 수락해버리면 동시성 문제가 발생한다.  

 

해결을 위해 비관적 Lock을 사용하여 member의 Apply 데이터 전부에 Lock을 걸어주었다. 

public void processOffer(Long workerId, OfferProcessRequest request) {
    // 생략

    // 동시성 문제를 해결하기 위한 Lock 쿼리
    applyRepository.findWorkerApplyForLock(worker.getId());

    // 요청에 따라 Apply 삭제 or status 업데이트
    Apply offeredApply = applyRepository.findOfferedApply(worker.getId(), workDate.getId())
            .orElseThrow(() -> new CustomException(ErrorCode.APPLY_OFFERED_NOT_FOUND));

    // 수락일 때
    if (request.getIsAccept()) {
        // 생략
        
        // 모집된 인원 증가
        workDate.plusRegisteredNum(1);

        // 제안 받으며 자동으로 생긴 지원 기록 승인 처리
        offeredApply.updateStatus(ApplyStatus.ACCEPTED, LocalDateTime.now());

        //생략
    }
    // 거절일 때
    else {
        // 제안 받으며 자동으로 생긴 지원 기록 제거
        applyRepository.delete(offeredApply);
    }

    // 생략
}

 

 

 

Repository 코드이다.

@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("select a from Apply a where a.member.id = :memberId")
List<Apply> findWorkerApplyForLock(@Param("memberId") Long memberId);

 

 

위와 같이 @Lock을 붙여줌으로써 다음과 같이 쿼리가 나간다.

 

비관적 Lock을 건 경우 select ~ for update 쿼리가 나간다. 즉, 여기서 조회된 레코드는 Lock이 걸린다. 

 

 

 

 

 

 

 

4. 결론

동시성 문제는 예상과 다르게 데이터가 처리될 수 있기 때문에 조심해서 개발해야 한다. 나같은 경우에도 지원 확정이 두 개 나버리면 기업 뿐만 아니라 노동자에게도 타격이 가는 상황이기 때문에 드물지만 그런 일이 일어나지 않도록 방지해야한다.

 

 

위에서 다룬 상황 말고도 현재 프로젝트에 동시성 문제를 해결해야 하는 몇 가지 로직들이 더 존재한다. 현업에선 이보다 수많은 예상치 못한 문제들이 많이 발생할텐데 빨리 경험해보고싶다..ㅎ