🕓

데드락 원인과 해결방안 고민(비관적 락, 낙관적 락)

생성일

2023/02/03

태그

Spring

Transaction

MySQL

JPA

목차

데드락이 발생한 이유

저희 서비스에서는 투표/약속잡기 목록 조회시 투표 또는 약속잡기를 마친 인원의 수를 표시하는 기능이 있습니다. 기존에는 연관 관계로 매핑된 결과 테이블에서 해당 투표 또는 약속잡기의 id 로 조회하고, 그 결과의 수를 세는 로직이었습니다. 하지만 데이터가 쌓이면 쌓일수록 조회 성능이 저하가 되는 단점을 발견했고, 이를 해결하기 위해 투표/약속잡기를 마친 인원의 수를 update 하는 selected_count 칼럼을 추가하는 반정규화를 진행하였습니다. 반정규화를 한 투표/약속잡기 진행 시의 로직은 다음과 같습니다.

투표/약속잡기 조회

투표/약속잡기 선택 결과 레코드 삽입

투표/약속잡기 selected_count + 1 수정

처음 이런 프로세스를 구성할 당시에는 이 과정에서 동시성과 관련된 문제가 발생할 수 있다는 사실을 인지하지 못하고 넘어갔습니다. 어떤 동시성 문제가 발생할까요?

반정규화 하면서 생겨날 수 있는 데드락 문제

저희 로직은 투표/약속잡기 진행 시 해당 멤버가 아직 진행하지 않은 멤버라면 selected_count 를 +1 합니다. 그러면 JPA 는 트랜잭션 커밋 종료 시점 또는 영속성 컨텍스트의 flush가 일어나는 시점에 엔티티의 스냅샷을 비교하는 더티 체킹을 하고 변경된 컬럼이 있으면 변경된 엔티티에 대해 update 쿼리를 실행합니다. 직접 쿼리를 작성하지 않고 JPA 기능을 활용하여 최대한 도메인 객체 내부에 비즈니스 로직을 만들어 응집도를 높일 수 있도록 하였습니다.

문제가 발생한 지점

위의 1, 2, 3 로직은 하나의 트랜잭션 내에서 순차적으로 진행됩니다. 그리고 2번 로직에서 선택 결과를 삽입할 때에는, 주 테이블의 외래키를 함께 저장합니다. 이 부분으로 기인하여 동시성 문제가 발생하였습니다. 저희가 사용하고 있는 MySQL 의 Inno DB 의 특성상, 연관관계에 있는 테이블에 레코드 삽입 시 연관관계에 있는 레코드에 공유락을 잡습니다.

•

약속잡기

•

약속잡기 선택 결과

id	title	selected_count
1	회식 날짜	0
2	스터디 시간	0

id	appointment_id
1	1
2	1

약속잡기 선택 결과에 레코드를 삽입할 때 외래키(appointment_id 1)도 저장하는데, 이 외래키에 있는 레코드인 약속잡기의 id가 1인 레코드에 공유락을 획득합니다.

start transaction;
insert into appointment_available_time values (null, 1);
select * from performance_schema.data_locks;
SQL
복사

lock_mode 컬럼을 보면 S 라는 공유락(Shared lock)과, REC_NOT_GAP 이라는 갭락이 아닌 레코드락 을 획득한 것을 확인할 수 있습니다.

이후 3번 로직에서 약속잡기의 해당 레코드에 selected_count 를 +1 하는 업데이트 쿼리를 날리는데 update 할 때에는 해당 레코드에 배타락을 획득해야 합니다.

update appointment set selected_count=1 where id = 1;
select * from performance_schema.data_locks;
SQL
복사

왼쪽의 공유락과 더불어, X 라는 배타락(eXclusive lock) 을 획득하였습니다.

그런데, 공유락은 조회가 가능하지만 수정은 불가능하고, 다른 트랜잭션에서는 배타락 획득이 불가능하여 획득이 가능할 때까지 대기합니다. 그래서 만약 두 개의 트랜잭션에서 각각 공유락을 획득 후 배타락을 획득하려고 시도하면 어떻게 될까요?

그림과 같이 서로 얽힌 상태에서 배타락을 획득하려고 시도하면 서로 대기만 하는 상태에 빠져 데드락이 발생하게 됩니다.

이 데드락 문제를 해결하기 위해 여러가지 해결 방법을 생각해보았습니다.

비관락

가장 먼저, 구상하기 가장 쉬운 비관적 락을 사용하는 방법을 생각해 보았습니다.

1번 로직인 약속잡기 조회 시 비관적 락을 걸어주게 되면 해당 레코드에 대해 배타락을 얻게 됩니다. 때문에 A 트랜잭션에서 비관적 락으로 약속잡기를 조회하면, A 트랜잭션이 끝날 때 까지 다른 트랜잭션들은 배타락 획득도, 공유락 획득도 불가능합니다(단 락 획득없는 단순 조회는 가능합니다). 한번에 한 트랜잭션만 락을 얻을 수 있으므로 정합성 문제도, 데드락 문제도 해결됩니다.

스프링에서는 @Lock 어노테이션을 통해 비관적 락과 낙관적 락을 지원합니다.

@Query("select a from Appointment a where a.menu.code.code = :appointmentCode")
@Lock(LockModeType.PESSIMISTIC_WRITE)
Optional<Appointment> findByCodeForUpdate(@Param("appointmentCode") String appointmentCode);
Java
복사

그리고 CountDownLatch 를 이용하여 쓰레드 100개를 병렬적으로 수행하는 테스트를 만들어 테스트를 해보았습니다.

비관적 락을 사용하는 경우, 조회 시에 for update 키워드를 통해 배타락을 획득합니다. 그리고 완료된 갯수를 세어보면!

select selected_count, (select count(*) from appointment_available_time) as 'appointment_available_time_count' from appointment;
SQL
복사

100 개의 데이터가 성공적으로 삽입된 것을 확인할 수 있습니다. 단, 이렇게 할 경우 대기 시간이 크게 발생합니다. 위의 그림과 같이 로직을 시작하자마자 트랜잭션에서 배타락을 얻기때문에 이후의 쓰레드에서는 각각의 트랜잭션들이 먼저 시작된 트랜잭션에서 커밋 또는 롤백될 때까지 로직을 실행하지 못하고 대기 상태에 빠지게 됩니다. 정합성을 확실하게 맞출 수는 있지만, 동시에 접근하는 트랜잭션이 많아지면 많아질수록 API 콜의 대기 시간은 늘어나게 됩니다. 또한 현업에서도 효율상, 비관락을 거의 사용하지 않는다는 친구의 말을 들어 비관적 락은 사용하지 않는 것으로 결정하였습니다.

낙관적 락은 현재 상태에서는 데드락에 빠지는 것을 피할 수 없기때문에 이후에 다루도록 하겠습니다.

foreign key 떼기

공유락을 획득하는 이유는 외래키 제약 조건 때문이었습니다. 이에 따라 데드락을 유발시켰던 공유락 획득하는 로직을 없애기 위해 외래키 제약조건을 제거하였습니다.

alter table appointment_available_time drop foreign key appointment_available_time_ibfk_1;

select * from information_schema.table_constraints where table_name = 'appointment_available_time';
SQL
복사

외래키 제약 조건을 제거한 뒤 그대로 로직을 수행하면 어떻게 될까요?

삽입된 데이터(appointment_available_time_count) 는 100개인데, 실제로 업데이트된 선택 인원(selected_count) 는 12개입니다. 두 데이터가 맞지 않는 정합성 문제가 발생하였습니다.

조회 시에 서로 다른 트랜잭션에서 같은 count 를 조회한 뒤, 각각 트랜잭션에서 update 를 수행하면 뒤에 수행된 트랜잭션의 update 가 앞의 트랜잭션에서 update 했던 결과를 덮어 씌우게 됩니다. 이로 인해 앞서 수행되었던 트랜잭션의 결과가 누락이 되고 정합성 문제가 발생한 것입니다.

낙관락

비관적 락은 앞서 언급한 상황과 같아 비관적 락 대신 낙관적 락을 사용해 보기로 하였습니다. 낙관적 락은 version 컬럼이 존재하고, update 시 기존에 조회했던 version 과 일치하는지 확인 후 update 합니다. 레코드에 배타락을 걸지 않기에 성능상 크게 저하되지 않고 동시성 문제를 해결할 수 있을 것이라고 판단하였습니다.

@Query("select a from Appointment a where a.menu.code.code = :code")
@Lock(LockModeType.OPTIMISTIC)
Optional<Appointment> findByCode(@Param("code") String code);
Java
복사

JPA 에서는 비관적 락과 마찬가지로 @Lock 어노테이션을 통해 낙관적 락을 지원합니다.

alter table appointment add column version int default 1;
SQL
복사

그리고 도메인 객체에 version 필드를 추가해준 뒤 해당 필드에 @Version 어노테이션을 붙이면 낙관적 락을 적용할 수 있습니다. 그리고 테스트를 돌려보면!

update 할 때 수정할 레코드 이외에도 version 이 일치하는지 확인하기 위해 version 도 함께 조건절에 추가하여 조회합니다. 하지만 테스트한 100개 모두 적용되지 않아 테스트에 실패하였습니다.

그림과 같이 수정에 실패하면 롤백을 진행하여 앞서 삽입한 데이터도 모두 취소되고 롤백됩니다. 낙관적 락을 적용한 로직의 결과를 확인해 보겠습니다.

수정한 값과 삽입된 값이 일치하여 정합성 문제를 해결할 수는 있었습니다.

하지만 결과적으로 유실된 데이터가 87건이 있습니다. 데이터 유실을 해결하기 위해서는 비즈니스 로직에서 rollback 이 발생했는지 확인하고 다시 동일한 과정을 수행하는 while 반복문을 돌려야 합니다. 이 뿐만 아니라 이미 도메인 객체에는 낙관적 락만을 위한 version 필드가 있습니다. 정합성과 데이터 유실없는 낙관적 락을 구현하기 위해 비즈니스 로직을 희생해야 하는 상황이 발생하게 됩니다. 이로 인해 낙관적 락은 보류하기로 결정하였습니다.

로직으로 풀기

마지막 방법은 count 값을 수정하는 더티 체킹을 포기하고 쿼리를 직접 날리는 방식입니다.

비즈니스 로직에서는 count 값을 변경하지 않고 새로운 데이터를 추가만 합니다. 그리고 수정하는 쿼리를 날리면 JPA 에서는 flush 를 하고 더티 체킹을 통해 데이터가 추가되는 쿼리만 생성한 뒤, 수정하는 쿼리가 발생합니다. 수정하는 쿼리는 수정하는 시점의 값에서 +1 하는 로직이기때문에 정합성을 맞출 수 있습니다. 이는 앞서 언급드린대로 update 쿼리를 실행할 때 데이터베이스 자체적으로 배타락을 획득하기 때문입니다. 이 경우 다른 로직으로 인한 공유락을 획득하지 않기에 데드락 문제도 피할 수 있습니다.

@Modifying(clearAutomatically =true, flushAutomatically =true)
@Query("update Appointment a "
        + "set a.availableTimes.selectedCount = a.availableTimes.selectedCount + 1 "
        + "where a.menu.code.code = :appointmentCode")
void updateSelectedCount(@Param("appointmentCode") String appointmentCode);
Java
복사

현재 저장된 회원의 팔로워 카운트 값에 +1을 해주는 JPQL입니다. 그리고 테스트를 돌려 보면!

정합성 문제와 데이터 유실 문제 모두 해결할 수 있었습니다.

위의 여러 방법들과 비교해보면, JPA의 더티 체킹 기능을 포기하여 덜 객체 지향적인 코드가 되고, 도메인의 로직이 서비스 계층으로 이동해 비대한 서비스 코드를 만드는 단점이 있습니다. 또한 JPQL 을 적용하여 자동으로 영속성 컨텍스트의 객체를 flush 하여 이후 영속성 컨텍스트를 이용하려면 다시 조회를 해야 하는 등 영속성 컨텍스트를 비효율적으로 이용할 수 밖에 없습니다. 하지만 락을 최소화하면서 정합성을 확실하게 보장할 수 있고 데이터 유실 문제도 해결할 수 있는 방법이기도 하고, 해당 로직 이후에는 영속성 컨텍스트를 이용하는 로직이 없기에 저희는 로직으로 해결하는 방법을 선택하였습니다.