동시성+데드락 제어를 위한 비관적 락 잠금 질문

Question

안녕하세요 글쓰기 커뮤니티 프로젝트를 개발하는 중입니다 회원이 소설을 찜하는 기능(좋아요)을 구현 중에 있는데요 찜 객체는 아래 첨부한 코드와 같이 memberId와 novelId를 외래키로 갖습니다 &#64;Entity public class Favorite { &#64;Id &#64;GeneratedValue(strategy &#61; GenerationType.IDENTITY) private Long favoriteId; &#64;ManyToOne(fetch &#61; FetchType.LAZY) &#64;JoinColumn(name &#61; &#34;member_id&#34;) &#64;NotNull private Member member; &#64;ManyToOne(fetch &#61; FetchType.LAZY) &#64;JoinColumn(name &#61; &#34;novel_id&#34;) &#64;NotNull private Novel novel; } // FavoriteService &#64;Transactional public FavoriteResponseDTO chooseFavorite(Long novelId, Long memberId) { favoriteJDBCRepository.save(memberId, novelId); novelRepository.updateFavoriteCount(novelId, &#43;1L); return FavoriteResponseDTO .builder() .... }편의상 코드는 질문과 관련된 부분만 올렸습니다문제는 동시성 이슈를 다뤄보고자 500명의 사용자가 동시에 novelId가 1인 소설을 찜하는 요청을 보낸다는 가정 하에 jmeter로 테스트를 돌려보니 동시성 이슈가 아니라 데드락이 발생해서요favoriteJDBCRepository.save(memberId, novelId); 코드 실행시 novelId가 외래키라 외래키 정합성 검사 때문에 db 내부적으로 novelId가 1인 레코드에 read lock이 걸리는 것 같습니다favorite 객체 save 시 트랜잭션 A가 novelId가 1인 레코드에 대해 read lock을 얻고, novelId가 3인 novel의 favoriteCount(찜 개수)를 &#43;1하고자 write lock 요청 -> favorite 객체 save 시 다른 트랜잭션 B도 novelId가 1인 레코드에 대해 readlock을 얻고, novelId가 1인 novel의 favoriteCount(찜 개수)를 &#43;1하고자 write lock 요청 -> write lock은 read lock이 전부 해제되어야 얻을 수 있음. 트랜잭션 A는 B가 read lock을 release하기를 대기하고 B도 A가 read lock을 release하기를 대기하면서 데드락 발생 // FavoriteService &#64;Transactional public FavoriteResponseDTO chooseFavoriteV2(Long novelId, Long memberId) { Novel foundNovel &#61; novelRepository.findByIdWithPessimisticLock(novelId).orElseThrow(...); Member foundMember &#61; memberRepository.findById(memberId).orElseThrow(...); Favorite favorite &#61; Favorite.builder() .member(foundMember) .novel(foundNovel) .build(); favoriteRepository.save(favorite); novelRepository.updateFavoriteCount(novelId, &#43;1L); return FavoriteResponseDTO .builder() .... } // NovelRepository &#64;Lock(LockModeType.PESSIMISTIC_WRITE) &#64;Query(&#34;SELECT n FROM Novel n WHERE n.novelId &#61; :novelId&#34;) Optional<Novel> findByIdWithPessimisticLock(&#64;Param(&#34;novelId&#34;) Long novelId);일단 novelId로 novel을 비관적 락을 사용해 조회해서 favorite 객체를 생성한 뒤에 저장하는 방식으로 데드락&#43;동시성 이슈 둘 다 해결이 되는데요 chooseFavoriteV2() 메서드가 이 방식으로 구현했습니다 이 방법 말고도 더 좋은 대안은 없을까요??

AskeTeddy · Answer

novelRepository.updateFavoriteCount(novelId, +1L);이 부분이 반정규화를 해놓은 부분이라고 이해되네요.아마 정규화로 해당 추천자를 다른 테이블에서 가져오는 방식이었다면, count 를 가져오는 통계 입장에서는 lock 이 될 가능성이 적었으리라 생각됩니다(트랜잭션 범위를 바꿔 추천 테이블만 lock 되면 됨)지금 하시는 작업이 aggregate pattern 과 join transaction 의 병합이라서 코드가 지저분 할 수 있습니다.전자 후자 방식중 하나를 고르면 좋을 것 같네요.예를 들어 aggregate pattern 은 하신 방식에다가 transaction 의 범주로 aggregate model 을 만듭니다. 여기서 aggregate root 를 통해서만 save, load 해줍니다.대신 aggregate pattern 에서는 join 으로 엮인 repository 를 하나로만 유지해야합니다... (설명하기 어렵네요)반대로 join transaction 방식은 정규화한 테이블을 통해서 작업하면 됩니다. 추천수는 정규화된 추천 테이블에서 count 만 새면 되고, 이를 read 합니다chatGPT 답변:좋은 조언입니다! 지금 말씀하신 두 가지 접근 방식, Aggregate Pattern과 Join Transaction 방식, 각각의 장단점에 따라 선택하면 더 나은 설계를 할 수 있습니다. 이를 정리하면 다음과 같습니다.1. Aggregate PatternAggregate Root를 정의하여, 관련 엔티티들 간의 복잡한 관계를 하나의 트랜잭션 내에서 관리하는 방식입니다. 예를 들어, 소설(Novel)이 Aggregate Root라면, 소설과 관련된 추천(Favorite 또는 NovelLike) 같은 서브 엔티티들은 소설을 통해서만 관리됩니다.장점: 소설에 대한 모든 상태 변경이 하나의 트랜잭션에서 관리되므로, 데이터 일관성을 보장할 수 있습니다. 이를 통해 복잡한 비즈니스 로직이 Aggregate Root에 의해 관리되고, 코드가 응집될 수 있습니다.단점: 트랜잭션 범위가 넓어져서 성능이 저하될 수 있고, 여러 엔티티 간의 의존성이 강해질 수 있습니다. 특히, 트랜잭션을 잘못 설계하면 락 경합이 발생할 위험도 있습니다.public class NovelAggregate { private Novel novel; private List likes; public NovelAggregate(Novel novel, List likes) { this.novel = novel; this.likes = likes; } public void addLike(Member member) { if (!likes.contains(member)) { likes.add(new NovelLike(novel, member)); // Aggregate Root를 통해 관리 } } }2. Join Transaction 방식 (정규화된 테이블 기반)추천 내역을 별도의 테이블로 관리하고, 추천자의 수는 해당 테이블에서 직접 COUNT를 통해 실시간으로 가져옵니다. 이 방식은 추천 수를 반정규화하지 않고, 데이터의 정규화를 유지하면서 단일 테이블에서 데이터를 읽고 쓰는 방식입니다.장점: 트랜잭션 범위가 좁아지므로, 락 경합 가능성이 줄어들고 성능이 향상됩니다. 각 엔티티가 독립적으로 관리되기 때문에 유연하고 유지보수하기 쉽습니다. 추천 수는 단순히 조회로 처리할 수 있어 멱등성 보장에도 유리합니다.단점: 추천 수를 실시간으로 계산해야 하므로, 대규모 데이터 환경에서는 성능 저하가 있을 수 있습니다. 하지만 인덱싱 등을 통해 이를 최적화할 수 있습니다.public long getLikeCount(Long novelId) { return novelLikeRepository.countByNovelId(novelId); // 추천 테이블에서 직접 조회 }결론Aggregate Pattern은 복잡한 상태 관리와 비즈니스 로직이 많은 경우 적합하지만, 데이터 일관성과 성능을 동시에 관리해야 하는 부담이 있습니다.Join Transaction 방식은 단순히 데이터 조회 및 트랜잭션을 가볍게 유지하고 싶을 때 더 적합하며, 추천 수를 실시간으로 계산하는 데 유리합니다.추천 수를 실시간으로 카운트하는 방식이 더 일관성과 멱등성을 보장할 수 있으므로, Join Transaction 방식이 더 직관적이고 유지보수하기 쉬운 선택일 수 있습니다.

동시성+데드락 제어를 위한 비관적 락 잠금 질문

1개의 답변

기술 목록