기존 로직 분석#

기존의 뱃지 발급 로직은 다음과 같다.

• ReviewService : @Transactional 로 관리되며, 리뷰 저장 후 @Async로 BadgeService를 호출한다.

  1
  @Transactional
  2
  public ReviewIdResponse createReview(...) {
  3
      // ... (유효성 검사 및 다른 데이터 저장 로직 생략)
  4
  
  5
      // 1. 리뷰 데이터를 DB에 저장 (아직 커밋되지 않은 상태)
  6
      Review review = reviewRepository.save(Review.createReview(userId, request));
  7
  
  8
      // 2. 뱃지 발급 서비스 비동기 호출
  9
      badgeService.giveReviewBadge(userId);
  10
  
  11
      return ReviewIdResponse.builder()
  12
          .reviewId(review.getId())
  13
          .build();
  14
  }
  

• BadgeService : @Async와 @Transactional로 동작하며, 뱃지 획득 조건을 만족하는지 DB를 조회하고, 만족한다면 뱃지를 수여한다.

  1
  @Async
  2
  @Transactional
  3
  public CompletableFuture<List<Long>> giveReviewBadge(Long userId) {
  4
      // 내부적으로 giveBadge 메소드를 호출하여 로직 수행
  5
      return completedFuture(giveBadge(userId, BadgeType.REVIEW));
  6
  }
  7
  
  8
  // giveBadge 메소드는 일부만 발췌하여 핵심 로직을 보여줌
  9
  private List<Long> giveBadge(Long userId, BadgeType badgeType) {
  10
      // ... (사용자의 기존 뱃지 정보 조회 로직 등 생략)
  11
  
  12
      for (Long badgeId : badgeIds) {
  13
          // 3. 뱃지 획득 조건 확인 (내부적으로 DB 조회 발생)
  14
          if (isUserNotOwnedBadge(badgeId) && isBadgeCondition(userId, badgeId)) {
  15
              // ... (뱃지 지급 로직)
  16
          }
  17
      }
  18
      return givenBadgeIds;
  19
  }
  20
  
  21
  // isBadgeCondition 메소드에서 가장 관련 있는 부분만 예시로 보여줌
  22
  private boolean isBadgeCondition(long userId, long badgeId) {
  23
      if (badgeId == PASSIONATE_REVIEWER_BADGE_ID) {
  24
          // 이 부분에서 DB 조회가 발생!
  25
          return reviewRepository.countByUserId(userId) >= PASSIONATE_REVIEWER_THRESHOLD;
  26
      }
  27
      // ...
  28
      return false;
  29
  }
  

원인 분석#

해당 문제에 대한 유력한 원인은 생각할 수 있는 원인은 트랜잭션과 @Async의 동작 시점 문제 (동시성 문제)이다.

왜냐하면 에러 로그가 따로 찍히지 않았기 때문에 뱃지 발급 로직에서 동작하는 두 스레드에서는 둘 다 정상으로 처리되었거고, 그렇다면 에러가 날 수 있는 부분은 각 조건이 제대로 체크되지 않은 부분이기 때문이다.

즉 기존의 구현 방식 (async 방식) 에 따르면 ReviewService (트랜잭션 A)는 badgeService.giveReviewBadge()를 호출하고, 호출했다는 사실만 인지한 채 자신의 나머지 일을 계속하게 되고, BadgeService (트랜잭션 B)는 호출을 받자마자 별도의 스레드에서 즉시 실행을 시작하려고 한다.

async 로 동작하기 때문에 저 두 작업은 완전히 별개의 흐름으로 처리되며, 트랜잭션 B가 트랜잭션 A 이후에 시작한다는 보장이 없다.

따라서 트랜잭션 B가 DB에서 리뷰 개수를 조회할 때, 트랜잭션 격리 수준에 의해 아직 커밋되지 않은 트랜잭션의 데이터를 읽지 못하여 현재 기능에서 버그가 발생한 것이다.

가설 검증#

이를 증명하기 위해 MySQL에서 각 트랜잭션을 실행해 애플리케이션의 동작을 재현하였다. 사용한 MySQL(InnoDB)의 격리 수준은 기본 격리수준인 REPEATABLE-READ이다.

상황 재현을 위해 유저 123이 작성한 4개의 리뷰가 이미 존재하고, 5번째 리뷰를 작성하여 뱃지를 발급받을 상황을 생각해보자.

• 트랜잭션 A (ReviewService) - 리뷰를 새로 작성

  

  • 트랜잭션을 시작하고 5번째 리뷰를 INSERT 한다 .
  • 자신의 트랜잭션에서는 COUNT(*) 결과가 5로 정상적으로 조회된다.

• 트랜잭션 B (BadgeService) - 뱃지 수여 기준 확인

  

  • 트랜잭션 A가 종료되지 않은 시점에서 새로운 터미널을 열어 트랜잭션 B를 시작한다.
  • 유저 123에 대한 리뷰 갯수를 조회한다. REPEATABLE-READ 격리 수준에 따라 아직 커밋되지 않은 데이터를 읽지 못하므로 COUNT(*) 결과가 4로 조회된다.

따라서 BadgeService가 잘못된(과거의) 데이터를 기반으로 조건을 판단하여 뱃지 발급에 실패한 것이다.

MySQL에서 현재 트랜잭션 격리 수준 확인하기

1
SELECT @@transaction_isolation

명령어로 현재 트랜잭션 격리 수준을 확인할 수 있다. 본인의 경우, 기본 격리 수준을 그대로 사용하므로 REPEATABLE-READ 이다.

구현#

Step 1: 이벤트 기반 로직으로 리팩토링

먼저 ReviewService가 BadgeService에 대한 직접 의존성을 갖지 않도록 이벤트 기반으로 변경한다.

• 뱃지 발급에 필요한 최소한의 데이터(userId)를 담는 이벤트 객체를 정의한다.

1
public class ReviewCreatedEvent {
2
    private final Long userId
3

4
    public ReviewCreatedEvent(Long userId) {
5
        this.userId = userId;
6
    }
7

8
    public Long getUserId() {
9
        return userId;
10
    }
11
}

• 기존에 BadgeService 를 직접 호출하던 코드를 제거하고 ApplicationEventPublisher를 통해 이벤트를 발행하도록 변경한다.

1
import org.springframework.context.ApplicationEventPublisher; // import 추가
2

3
@Service
4
@RequiredArgsConstructor
5
public class ReviewService {
6

7
    private final ReviewRepository reviewRepository;
8
    // ... 다른 Repository들 ...
9
    private final ApplicationEventPublisher eventPublisher;
10

11
    @Transactional
12
    public ReviewResponse createReview(final Long userId, final ReviewCreateRequest request,
13
        final List<MultipartFile> images) {
14
        // ... (기존 유효성 검사 및 데이터 저장 로직)
15

16
        Review review = reviewRepository.save(Review.createReview(userId, request));
17

18
        // badgeService 직접 호출 대신 이벤트 발행
19
        // => 이 트랜잭션이 성공적으로 커밋되면 처리될 이벤트
20
        eventPublisher.publishEvent(new ReviewCreatedEvent(userId));
21

22
        // ...
23
    }
24
}

발행된 이벤트를 받아 처리할 리스너를 구현한다.@TransactionalEventListener를 사용하여 트랜잭션이 성공적으로 커밋된 후에만, @Async로 비동기 실행되도록 설정한다.

주의할 점은 기존에 뱃지를 발급하던 로직이 비동기로 처리되게 되어있다면, 해당 부분을 제거해야 한다.

1
@Component
2
public class BadgeEventHandler {
3
    private final BadgeService badgeService;
4

5
    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
6
    @Async
7
    public void handleReviewCreatedEvent(ReviewCreatedEvent event) {
8
        badgeService.giveReviewBadge(event.getUserId());
9
    }
10
}

2. 데이터 보정을 위한 배치 작업 구현

메인 애플리케이션 클래스에 스케줄링 기능을 활성화 한다. (@EnableScheduling)

1
@EnableScheduling // 스케줄링 기능 활성화
2
public class FiestaApplication {
3
    // ...
4
}

주기적으로 실행될 로직을 담을 배치 서비스 클래스를 생성한다.

1
@Service
2
public class BadgeCorrectionBatchService {
3
    // ... 의존성 주입 ...
4

5
    @Scheduled(cron = "0 0 4 * * *")
6
    public void runBadgeCorrection() {
7
        // ... 페이징 처리를 위한 do-while 루프 ...
8
        do {
9
            Page<User> userPage = userRepository.findAll(pageable);
10
            processUserChunk(userPage.getContent()); // 청크 단위로 트랜잭션 처리
11
            pageable = userPage.nextPageable();
12
        } while (userPage.hasNext());
13
    }
14

15
    @Transactional
16
    public void processUserChunk(List<User> users) {
17
        for (User user : users) {
18
            badgeService.giveReviewBadge(user.getId());
19
        }
20
    }
21
}

한 번에 모든 유저를 불러오면 오버헤드의 위험이 크므로 청크 단위로 트랜잭션을 끊어서 구현한다.