동시성(synchronized)

틀린 부분이 있다면 피드백 주시면 감사합니다!

 

프로젝트를 진행하면서 조회수 불일치 문제를 겪은적이 있다. 당시 3주라는 짧은 기간에 기능 구현하기 급급해서 블로그 슥 보고 Redisson을 활용해서 분산락 방식으로 해결한 적이 있다. 프로젝트 끝나고 나서 동시성 문제가 왜 생기는지 알아보면서 멀티 스레드 환경에서 동시성 문제는 꼭 이해하고 넘어가야 한다는걸 느꼈다. 

 

동시성 문제란?

여러 작업(스레드, 프로세스, 트랜잭션)이 동시에 같은 데이터나 자원을 수정하려고 하면 문제가 발생할 수 있으며 이를 동시성 문제라고 한다.

여기서 다룰 내용은 데이터베이스의 저장된 데이터에 여러 작업이 동시에 수행될 때 의도하지 않은 작업 결과가 발생하는 경우라고 가정한다. 가장 쉬운 예시로 흔히 재고 시스템에서의 동시성 문제를 예시로 든다. 

• 요청 1이 트랜잭션을 열고 상품의 재고를 조회
• 요청 1이 조회한 이후 요청 2 조회
• 요청 1이 재고 1을 감소 시켜 재고값을 9로 업데이트
• 요청 2가 재고 2를 감소시키며 재고값을 8로 업데이트
• 최종적으로 반영되는 값은 7이 아닌 8

이처럼 원래라면 7이 저장되어야 하지만 8이 저장되면서 데이터의 정합성이 깨지게 된다. 이게 왜 중요한지는 재고 예시만 봐도 느낄 수 있다. 이커머스 플랫폼에서 물건을 주문했는데 동시성 문제가 발생한다면 없는 물건을 주문한 것과 마찬가지다. 

 

문제를 해결해보자

동시성 문제를 해결하는 방법은 여러가지 방법이 있다. 그리고 기술 스택에 따라서도 해결 방식이 달라지기도 한다. 그래서 최대한 다양한 방식으로 문제를 해결해보고 성능 비교도 해볼 생각이다! 개발 환경은 다음과 같다.

• Spring Boot 3.x
• JDK 21
• MySQL 8
• JPA(Hibernate), JdbcTemplate(spring jpa 안에 내장 되어 있음)

엔티티 및 기본 코드

테스트는 심플하다 조회성 증가 동시성 테스트이므로 Board 엔티티와 view 컬럼 정도만 있으면 된다.(제목 없으면 뭔가 허전해서 넣음) 그럼 동시성 문제를 해결할 수 있는 여러가지 방법을 알아보자. 참고로 아래는 사용한 개발 환경이다.

• spring boot 3.x
• JDK 21
• MySQL
• JPA(Hibernate)

@Getter
@Table(name = "board")
@Entity
public class Board {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String title;

    @Column(name = "view")
    private long view;

    public Board(String title, long view) {
        this.title = title;
        this.view = view;
    }

    public void increaseView() {
        this.view += 1;
    }

    public Board() {

    }
}

public interface BoardRepository extends JpaRepository<Board, Long> {
    default Board getBoardById(long boardId) {
        return findById(boardId).orElseThrow(IllegalArgumentException::new);
    }
}

1. synchronized

synchronized(JPA)

첫번째 방식은 스레드 진입 순서를 순차적으로 처리하도록 해주는 Java synchronized 방법을 사용해서 처리하는 방식이다. 

@Transactional
public synchronized void increaseViewCount(final long boardId) {
    Board board = boardRepository.getBoardById(boardId);
    board.increaseView();
}

위 방식대로 하면 과연 동시성 처리가 되는지 확인해보자 아래는 테스트 코드다

@Test
@DisplayName("JPA synchronized 테스트")
void increaseViewCount() throws InterruptedException {
    long boardId = 1L;
    int concurCnt = 50;
    ExecutorService executorService = Executors.newFixedThreadPool(32);
    CountDownLatch latch = new CountDownLatch(concurCnt);

    for (int i = 0; i < concurCnt; i++) {
        executorService.submit(() -> {
            try {
                boardService.increaseViewCount(1L);
            } finally {
                latch.countDown();
            }
        });
    }

    latch.await();
    BoardDto afterBoard = boardService.findBoard(boardId);
    assertThat(afterBoard.view()).isEqualTo(concurCnt);
}

----------------결과------------------
org.opentest4j.AssertionFailedError: 
expected: 50L
but was: 11L

결과는 실패로 뜨면서 조회수는 최종적으로 11로 저장되었다. 이유는 synchronized와 @Transactional를 생각해보면 쉽다. 

@Transactional은 Spring AOP를 활용하여 동작하는데 이때 아래와 같은 코드로 동작하게 된다. 

@Override
public void increaseViewCount(Long id, Long quantity) {
     try{
         tx.start();
         boardService.increaseViewCount();
     } catch (Exception e) {
         // ...
     } finally {
         tx.commit();
     }
}

• 각 스레드 트랜잭션 begin
• 스레드 접근 순서대로 메소드 내부 로직 실행
• a 스레드가 조회수 증가
• a 스레드 메소드 종료
• a 스레드의 commit() 실행 전 b 스레드가 board 조회 및 조회수 증가 수행

정리하자면 synchronized로 스레드 순서는 보장했지만 DB 반영 시점까지는 보장을 못해 다른 스레드가 아직 DB에 반영되지 않은 데이터를 읽어와 로직을 실행할 수 있다. 다시 말해 commit을 하기 이전 즉 반영이 되기 전에 다른 스레드가 increateViewCount() 메소드를 실행할 수 있다. 이러한 이유로 해당 로직은 동시성을 보장할 수 없게 된다. 이해가 안간다면 아래 로그를 참고하면 감이 잡힐 것이다.

INFO 11644 --- [concurrdemo] [pool-2-thread-9] o.t.concurrdemo.service.BoardService      : Thread : pool-2-thread-9
DEBUG 11644 --- [concurrdemo] [pool-2-thread-9] org.hibernate.SQL                        : select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
Hibernate: select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
DEBUG 11644 --- [concurrdemo] [pool-2-thread-9] o.h.e.t.internal.TransactionImpl         : committing
INFO 11644 --- [concurrdemo] [ool-2-thread-10] o.t.concurrdemo.service.BoardService      : Thread : pool-2-thread-10
DEBUG 11644 --- [concurrdemo] [ool-2-thread-10] org.hibernate.SQL                        : select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
Hibernate: select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
DEBUG 11644 --- [concurrdemo] [pool-2-thread-2] org.hibernate.SQL                        : update board set title=?,view=? where id=?
DEBUG 11644 --- [concurrdemo] [pool-2-thread-9] org.hibernate.SQL                        : update board set title=?,view=? where id=?
Hibernate: update board set title=?,view=? where id=?
DEBUG 11644 --- [concurrdemo] [ool-2-thread-10] o.h.e.t.internal.TransactionImpl         : committing
Hibernate: update board set title=?,view=? where id=?

 

그렇다면 단순하게 생각해서 해당 로직 내부에서 DB에 반영이 되어야 한다는 것을 해결법으로 생각할 수 있다. spring jpa에서 제공하는 saveAndFlush로 하면 될 것 같다. 

@Transactional
public synchronized void increaseViewCount(final long boardId) {
    log.info("Thread : {}", Thread.currentThread().getName());
    Board board = boardRepository.getBoardById(boardId);
    board.increaseView();
    boardRepository.saveAndFlush(board);
    log.info("==============================================");
}

 

테스트 코드는 동일하다 그럼 과연 결과는?

org.opentest4j.AssertionFailedError: 
expected: 50L
but was: 25L

실패다. 아래 로그상에서는 모든게 정상적으로 보인다. 스레드 별로 순서도 다 보장되었고 update도 해당 로직 안에서 들어가고 commit이 완료 된 후에 다음 스레드가 select 하는 것이 로그에는 잘 나온다. 

INFO 12832 --- [concurrdemo] [pool-2-thread-5] o.t.concurrdemo.service.BoardService     : Thread : pool-2-thread-5
DEBUG 12832 --- [concurrdemo] [pool-2-thread-5] org.hibernate.SQL                        : select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
Hibernate: select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
DEBUG 12832 --- [concurrdemo] [pool-2-thread-5] org.hibernate.SQL                        : update board set title=?,view=? where id=?
Hibernate: update board set title=?,view=? where id=?
INFO 12832 --- [concurrdemo] [pool-2-thread-5] o.t.concurrdemo.service.BoardService     : ==============================================
INFO 12832 --- [concurrdemo] [pool-2-thread-6] o.t.concurrdemo.service.BoardService     : Thread : pool-2-thread-6
DEBUG 12832 --- [concurrdemo] [pool-2-thread-5] o.h.e.t.internal.TransactionImpl         : committing
DEBUG 12832 --- [concurrdemo] [pool-2-thread-9] o.h.e.t.internal.TransactionImpl         : On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
DEBUG 12832 --- [concurrdemo] [pool-2-thread-9] o.h.e.t.internal.TransactionImpl         : begin
DEBUG 12832 --- [concurrdemo] [pool-2-thread-6] org.hibernate.SQL                        : select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
Hibernate: select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
DEBUG 12832 --- [concurrdemo] [pool-2-thread-5] o.h.e.t.internal.TransactionImpl         : On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
DEBUG 12832 --- [concurrdemo] [pool-2-thread-5] o.h.e.t.internal.TransactionImpl         : begin
DEBUG 12832 --- [concurrdemo] [pool-2-thread-6] org.hibernate.SQL                        : update board set title=?,view=? where id=?
Hibernate: update board set title=?,view=? where id=?
INFO 12832 --- [concurrdemo] [pool-2-thread-6] o.t.concurrdemo.service.BoardService     : ==============================================
DEBUG 12832 --- [concurrdemo] [pool-2-thread-6] o.h.e.t.internal.TransactionImpl         : committing

로그에서 쿼리 자체는 순서대로 발생하지만 중간에 보면 스레드 6이 이미 해당 메소드를 실행을 하는 사이에 스레드 5의 트랜잭션이 그 다음에 commiting을 하는 것을 볼 수 있다. 

1. saveAndFlush를 했는데 왜?
flush는 현재 트랜잭션이 열린 상태의 DB에 반영을 하는 것이지 commit을 하는것이 아니다 DB에 최종적으로 반영이 되기 위해서는 commit이 되어야 한다 다시 말해 현재 트랜잭션 내에서 변경은 DB에 반영이 되었지만 commit이 된게 아니다.

2. saveAndFlush 구현 메소드를 보니까 여기에도 @Transactional이 적용되어있지만 왜?
@Transactional의 전파 기본값은 REQUIRED 즉 기존에 트랜잭션이 있다면 기존 트랜잭션을 사용한다. 그 말은 새로 트랜잭션을 열지 않는다는 의미이다. 
여기서는 increaseViewCount()메소드에서 이미 트랜잭션을 열었기 때문에 saveAndFlush의 @Transactional 무의미해지기 때문에 commit이 동작하지 않는다.

그럼 이제 어떻게 해결을 해야할까? 위 테스트들을 봤을 때 결국은 서비스 메소드의 트랜잭션 커밋 시점이 엇갈리는 것이 근본적인 원인인것 같다. 그렇다면 커밋 완료까지 메소드 내부에서 해버리면 될거 같다.

 public synchronized void increaseViewCount(final long boardId) {
    log.info("Thread : {}", Thread.currentThread().getName());
    Board board = boardRepository.getBoardById(boardId);
    board.increaseView();
    boardRepository.saveAndFlush(board);
}

@Transactional을 제거하여 로직 내에서 commit()까지 순차적으로 해버리도록 하면 된다. 이렇게 할 경우 쿼리는 아래 로그처럼 발생하게 되면서 동시성 문제를 해결할 수 있다.

INFO 25536 --- [concurrdemo] [pool-2-thread-1] o.t.concurrdemo.service.BoardService     : Thread : pool-2-thread-1
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] o.h.e.t.internal.TransactionImpl         : On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] o.h.e.t.internal.TransactionImpl         : begin
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] org.hibernate.SQL                        : select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
Hibernate: select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] o.h.e.t.internal.TransactionImpl         : committing
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] o.h.e.t.internal.TransactionImpl         : On TransactionImpl creation, JpaCompliance#isJpaTransactionComplianceEnabled == false
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] o.h.e.t.internal.TransactionImpl         : begin
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] org.hibernate.SQL                        : select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
Hibernate: select b1_0.id,b1_0.title,b1_0.view from board b1_0 where b1_0.id=?
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] org.hibernate.SQL                        : update board set title=?,view=? where id=?
Hibernate: update board set title=?,view=? where id=?
DEBUG 25536 --- [concurrdemo] [pool-2-thread-1] o.h.e.t.internal.TransactionImpl         : committing

중간에 select가 한번 더 나가는 이유
영속성 컨텍스트 유지는 트랜잭션의 시작과 끝과 동일하다. 즉 트랜잭션이 끝나면 영속성 컨텍스트도 사라지게 된다. 이때 SimpleJpaRepository내의 메소드들은 기본적으로 @Transactional이 전부 설정되어 있다. 따라서 getBoardById에서 트랜잭션이 한번 열렸다가 닫힌 후 saveAndFlush 메소드 호출 시 영속성에 해당 엔티티가 있을 수 없으므로 조회 후 업데이트를 해야 하므로 select가 한번 더 발생하게 된다. 

 

synchronized(JdbcTemplate)

JPA를 사용하지 않는 환경에서의 동시성 제어는 비교적 쉽다. JdbcTemplate를 사용한 환경을 예시를 보면 아래 코드와 같다.

@Repository
@RequiredArgsConstructor
public class BoardDao {

    private final JdbcTemplate jdbcTemplate;
    
    @Transactional
    public void updateViewCount(long boardId) {
        jdbcTemplate.update("update board set view = view + 1 where id = ?", boardId);
    }
}

public synchronized void increaseViewCountJdbc(final long boardId) {
    boardDao.updateViewCount(boardId);
}

 

updateviewcount에서 바로 업데이트를 하므로 테스트 결과는 pass하게 된다. 하지만 얕은 지식을 바탕으로 조금 더 생각해보자면 MySQL을 사용하는 환경일 때 위 로직에서 굳이 synchronized가 필요한가 싶다. 왜냐면 기본적으로 REPETABLE_READ 수준에서 동일한 레코드에 update시 x lock을 획득하면서 다른 트랜잭션이 update를 하지 못하게 보장하기 때문에 정합성 보장을 해주는 것으로 알고 있다.

public void increaseViewCountJdbc(final long boardId) {
    boardDao.updateViewCount(boardId);
}

 

좋은 방식인가?

synchronized 관련된 내용을 보면 성능 저하를 일으킨다는 글들을 많이 볼 수 있다.(왜 인지는 찾아 봐야됨...) 실제로 테스트 코드를 수행할 때도 오래 걸리기도 했다. 그리고 결정적으로 synchronized는 해당 JVM에서만 유효하기 때문에 결과적으로 단일 서버에서만 가능한 방법이다. 즉 여러개의 서버에서 해당 방식으로 동시성을 해결하고자 한다면 각 서버에서의 동시성은 해결하지만 다른 서버간의 동기화는 이루어질 수 없게 된다.

 

---

참고

1. transactional과 synchornized

2. flush와 commit

3. 동시성 해결하기