[🔥TroubleShooting - MoodBuddy🔥] 동시에 여러 기기로 일기에 접근한다면..?

📌 프로젝트 소개

팀원 : PM(1) / Design(1) / Frontend(2) / Backend(3)
기간 : 2024.03 ~ 2025.03
링크 : https://github.com/M-ung/MoodBuddy_Server
서비스 내용 : 사용자가 작성한 일기를 바탕으로 감정 분석하는 웹 서비스
소통 : GitHub, Slack, Notion, Discord

---

🔥TroubleShooting🔥

Problems

우리 서비스 "MoodBuddy" 는 사용자 혼자만의 공간이고 다른 사용자가 접근할 수 없는 공간이기 때문에 동시성을 크게 고려하지 않았다. 그 이유는 만약 일기 수정, 일기 삭제, 북마크, 등의 기능을 하나의 일기를 가지고 동시에 호출할 일이 없기 때문이다.

그래서 동시성을 고려하지 않고 기능 구현에 몰두했다.

하.지.만 만약에 '동시에 여러 기기로 일기에 접근한다면..?' 라는 생각을 했다. 예를 들어 사용자가 노트북, 핸드폰으로 동시에 일기 수정 또는 삭제를 한다면 동시성 문제가 발생하게 된다.

하지만 위 같은 경우는 정말 정말 정말 적은 일이라고 생각한다. 그래도 개발자라면 위 같은 경우도 생각해서 개발을 해야 한다고 생각하기 때문에 동시성 문제를 해결하기로 했다.

---

How

위에서 말했듯이 위 같은 경우는 자주 일어날 일이 아니라고 판단하였기에 최대한 간단하고 가볍게 동시성 문제를 해결하기로 했다. 그래서 선택한 방안은 "낙관적 락"이다.

그 이유는 아래와 같다.

낙관적 락은 동시 수정이 적은 경우 효율적이다.
트랜잭션 충돌이 발생할 때만 감지하여 성능 저하가 적다.
비관적 락보다 데이터베이스 락을 최소화하여 부하를 줄인다.

그렇기 때문에 자주 발생하지 않는 동시성 문제를 해결하기 적합하다고 판단했다.

---

Process

먼저 일기(Diary) 엔티티데 version 을 추가해 주었다.

📍 Diary.java

@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@Table(name = "diary")
public class Diary extends BaseTimeEntity {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Long id;

    @Column(name = "title", nullable = false)
    private String title;

    @Column(name = "date", nullable = false)
    private LocalDate date;

    @Column(name = "content", nullable = false, columnDefinition = "text")
    private String content;

    @Enumerated(EnumType.STRING)
    @Column(name = "weather", nullable = false)
    private DiaryWeather weather;

    @Enumerated(EnumType.STRING)
    @Column(name = "emotion")
    private DiaryEmotion emotion;

    @Enumerated(EnumType.STRING)
    @Column(name = "subject")
    private DiarySubject subject;

    @Column(name = "summary", columnDefinition = "varchar(255)")
    private String summary;

    @Column(name = "user_id", nullable = false, columnDefinition = "bigint")
    private Long userId;

    @Column(name = "book_mark")
    private Boolean bookMark;

    @Enumerated(EnumType.STRING)
    @Column(name = "font")
    private DiaryFont font;

    @Enumerated(EnumType.STRING)
    @Column(name = "font_size")
    private DiaryFontSize fontSize;

    @Column(name = "thumbnail", columnDefinition = "text")
    private String thumbnail;

    @Enumerated(EnumType.STRING)
    @Column(name = "mood_buddy_status")
    private MoodBuddyStatus moodBuddyStatus;

    @Version
    @Column(name = "version", nullable = false)
    private Long version;
 }

다음으로 일기 수정과 일기 삭제 기능을 아래와 같이 version 충돌이 일어나는지 감지할 수 있도록 구현해 주었다.

📍 DiaryServiceImpl.java

@Service
@Transactional(readOnly = true)
@RequiredArgsConstructor
public class DiaryServiceImpl implements DiaryService {
    private final DiaryRepository diaryRepository;

    @Override
    @Transactional
    public Long updateDiary(final Long userId,  DiaryReqUpdateDTO requestDTO) {
        try {
            var findDiary = findDiaryById(userId, requestDTO.diaryId());
            findDiary.updateDiary(requestDTO);
            return findDiary.getId();
        } catch (ObjectOptimisticLockingFailureException ex) {
            throw new DiaryConcurrentUpdateException(ErrorCode.DIARY_CONCURRENT_UPDATE);
        }
    }

    @Override
    @Transactional
    public LocalDate deleteDiary(final Long userId,  final Long diaryId) {
        try {
            final var findDiary = findDiaryById(userId, diaryId);
            findDiary.updateMoodBuddyStatus(MoodBuddyStatus.DIS_ACTIVE);
            return findDiary.getDate();
        } catch (OptimisticLockException ex) {
            throw new DiaryConcurrentUpdateException(ErrorCode.DIARY_CONCURRENT_DELETE);
        }
    }
}

📍 DiaryRepository.java

public interface DiaryRepository extends JpaRepository<Diary, Long>, DiaryRepositoryCustom {
    boolean existsByUserIdAndDate(Long userId, LocalDate date);

    @Lock(LockModeType.OPTIMISTIC)
    Optional<Diary> findByUserIdAndIdAndMoodBuddyStatus(final Long userId, final Long diaryId, MoodBuddyStatus moodBuddyStatus);
}

또 위 일기 수정과 일기 삭제 기능을 구현하면서 추가적으로 든 고민이 "일기 저장" 또한 동시성 문제를 해결할 필요가 있다고 생각했다. 그 이유는 우리 "MoodBuddy" 서비스는 하루에 한 번 일기를 작성할 수 있기 때문에 하나의 날짜에 일기가 2번 이상 작성되면 안 되기 때문이다. 그래서 이 문제는 테이블에 제약 조건을 걸어서 간단히 해결했다.

@Table(name = "diary", 
uniqueConstraints = @UniqueConstraint(columnNames = {"userId", "date"}))

---

Result

문제 해결로 아래와 같은 결과를 얻었다.
1. 희박한 동시성 충돌 상황을 고려해 낙관적 락으로 처리.
2. 10대 기기 기준, 동시에 요청 중 1대 성공, 9대 실패.

그리고 일기 관리 시나리오는 아래와 같다.

📍 일기 관리 시나리오

그럼 위 시나리오대로 테스트를 진행해 보겠다.

    @Test
    @DisplayName("일기 저장할 때 동시성 테스트")
    public void 일기_저장할_때_동시성_테스트() throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(THREAD_COUNT);
        ExecutorService executorService = Executors.newFixedThreadPool(THREAD_COUNT);
        AtomicInteger successCount = new AtomicInteger(0);
        AtomicInteger failureCount = new AtomicInteger(0);
        for (int i = 0; i < THREAD_COUNT; i++) {
            executorService.submit(() -> {
                try {
                    diaryService.saveDiary(1L, saveRequestDTO);
                    successCount.incrementAndGet();
                } catch (Exception e) {
                    failureCount.incrementAndGet();
                    e.printStackTrace();
                } finally{
                    latch.countDown();
                }
            });
        }
        executorService.shutdown();
        latch.await();
        assertThat(successCount.get()).isEqualTo(1);
        assertThat(failureCount.get()).isEqualTo(THREAD_COUNT - 1);
    }

    @Test
    @DisplayName("일기 수정할 때 동시성 테스트")
    public void 일기_수정할_때_동시성_테스트() throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(THREAD_COUNT);
        ExecutorService executorService = Executors.newFixedThreadPool(THREAD_COUNT);
        AtomicInteger successCount = new AtomicInteger(0);
        AtomicInteger failureCount = new AtomicInteger(0);
        for (int i = 0; i < THREAD_COUNT; i++) {
            executorService.submit(() -> {
                try {
                    diaryService.updateDiary(1L, updateRequestDTO);
                    successCount.incrementAndGet();
                } catch (Exception e) {
                    failureCount.incrementAndGet();
                    e.printStackTrace();
                } finally{
                    latch.countDown();
                }
            });
        }
        executorService.shutdown();
        latch.await();

        Optional<Diary> findDiary = diaryRepository.findById(diaryId);
        assertThat(findDiary.get().getTitle()).isEqualTo(updateRequestDTO.diaryTitle());
        assertThat(successCount.get()).isEqualTo(1);
        assertThat(failureCount.get()).isEqualTo(THREAD_COUNT - 1);
    }

    @Test
    @DisplayName("일기 삭제할 때 동시성 테스트")
    public void 일기_삭제할_때_동시성_테스트 () throws InterruptedException {
        CountDownLatch latch = new CountDownLatch(THREAD_COUNT);
        ExecutorService executorService = Executors.newFixedThreadPool(THREAD_COUNT);
        AtomicInteger successCount = new AtomicInteger(0);
        AtomicInteger failureCount = new AtomicInteger(0);
        for (int i = 0; i < THREAD_COUNT; i++) {
            executorService.submit(() -> {
                try {
                    diaryService.deleteDiary(1L, diaryId);
                    successCount.incrementAndGet();
                } catch (Exception e) {
                    failureCount.incrementAndGet();
                    e.printStackTrace();
                } finally{
                    latch.countDown();
                }
            });
        }
        executorService.shutdown();
        latch.await();
        Optional<Diary> findDiary = diaryRepository.findById(diaryId);
        assertThat(findDiary.get().getMoodBuddyStatus()).isEqualTo(MoodBuddyStatus.DIS_ACTIVE);
        assertThat(successCount.get()).isEqualTo(1);
        assertThat(failureCount.get()).isEqualTo(THREAD_COUNT - 1);
    }

테스트 모두 통과하는 걸 볼 수 있다.

---

Thoughts

이번 경험을 통해 동시성 문제는 예상하지 못한 곳에서도 발생할 수 있다는 점을 다시 한번 깨달았다. 처음에는 사용자가 같은 일기를 여러 기기를 가지고 동시에 수정하거나 삭제하는 일이 극히 드물다고 생각했지만, 개발자로서 극히 드문 경우라도 대비하는 것이 좋은 서비스의 기본이라는 점을 느끼고 배울 수 있었다.

특히 낙관적 락을 적용하면서 동시성 문제를 단순하고 가볍게 해결할 수 있었고, JPA의 @Version 기능과 @UniqueConstraint 를 활용해 불필요한 데이터베이스 락을 최소화하면서도 안정적인 데이터 무결성을 보장할 수 있었다.

위 문제를 해결하면서 여러 동시성 문제 해결 방법을 알게 되었지만, 동시성 문제를 해결하는 방법은 서비스의 특성에 맞춰 신중하게 선택해야 한다는 점도 깨달았다.
만약 일기의 동시 수정과 삭제가 잦거나 사용자가 다른 사용자와 일기를 공유하는 서비스였다면 낙관적 락보다는 비관적 락이나 분산 락을 고려했을 것이다.

이번 경험을 통해 서비스의 특징에 따라 적절한 동시성 제어 방법을 적용하는 것이 중요하며, 성능과 안정성을 모두 고려해야 한다는 점을 몸소 배울 수 있었다.

---