20230807_deadlock

교착 상태란? 나무위키에서 알려주길, "두 개 이상의 작업이 서로 상대방의 작업이 끝나기 만을 기다리고 있기 때문에 어떻게든 결론이 나지 않는 상태"를 의미한다 해당 상황이 발생할 수 있는 상황은 아래와 같다

• 비선점 > 지원을 선점하지 않음

• 환형대기 > 원형으로 자원을 대기 중

• 상호배제 > 자원은 하나의 프로세스만 점유 가능

• 점유대기 > 자원에 고유번호 할당 후 순서대로 자원

이렇게 디비에서 트랜잭션(작업 단위)가 교착상태로 되어있는 상황에서 오라클은 교착상태인 상황을 확인하고, 오라클이 위의 ORA-00060 을 뱉으면서 교착상태를 풀어주게 된다 백엔드 서버에서 발생하는 교착상태면 역시 디비에 걸려있는 락과 관련있을 것이라고 예상을 했고 디비에서 락은 거는 케이스는 크게 2가지가 있는 것으로 알고 있다 @Lock 을 통해서 조회 시, for update 문을 날리는 케이스 / 특정 로우에 대한 update 문이 날라가는 케이스

우선 이번에 해당 이슈가 발생한 프로젝트에서는 @Lock 을 통해서 락을 걸고 처리하는 방식은 별로 많지 않았기에 그렇게 엄청 의심가는게 있지는 않았다 그렇게 확인해보니 @Lock 을 통해서 나가는 사항 자체는 따로 없었다 다음으로는 그럼 해당 에러가 발생한 시점에 돌아가고 있는 트랜잭션들을 쭉 확인했다 정확하게는 에러가 발생한 로직에서 디비에 insert/update 치는 것들이 있는지 확인, 트랜잭션 안에서 언제 해당 쿼리가 디비에 날아가는지 확인했다 그리고 디비에 update, insert 문이 날아가는 케이스에서 어떻게 교착상태가 생성되었는지 고민해봤다 <br

예상이 가는 두 가지 케이스는 이와 같다 두 트랜잭션이 서로 하나의 로우를 업데이트하기 위해서 각각이 락을 잡은 상항에서 추가적으로 해당 로우에 락을 잡으려는 쿼리가 들어오는 케이스 두 트랜잭션이 로우 A, B 를 순환적으로 락을 잡고 있는 상황 - T1에서 A를 먼저 걸고, T2에서 B를 먼저 걸고, T1에서 B를 걸려고하고, T2에서 A를 걸려는 케이스 >교착상태를 서버 로그단에서 확인하기 위해서는 deadlock 이 발생하게된 특정 로우를 찾고 > 해당 로우를 업데이트하는 쿼리들과 그 트랜잭션의 범위를 구체화 찾고 > 실제 로그를 봤을 때 어느 시점에 쿼리가 서버로부터 디비로 날아갔는지 확인 서버의 로그를 기반으로 해당 트랜잭션의 순서를 그려가보면서 어떤 교착상태인지에 대해서 파악이 필요했다

상황은 이러했다 사용자별로 특정 리워드의 지급 갯수를 통계로써 저장하는 경우인데, 특정 이벤트에 연결되어 있는 리워드를 가져오는 과정에서 같은 리워드들을 가져오는데, 이벤트가 동시에 들어온 상황에서 두 이벤트가 리워들르 가져올 떄 동일한 순서를 보장해서 들어오는 케이스가 아니라 둘 다 순서를 자기 멋대로 설정해서 리워드별로 로직이 돌아가기 떄문에 교착상태의 두 번째 상황이 발생한 것이다

이것의 해결방안으로는 우선 순서를 보장하는게 가장 좋을 것이라고 생각이 들었다, 그런데 순서를 보장하는 방법에 대해서 고민해보자니, MQ를 사용해서 순서를 보장시키는 방법이 있다고 생각했다 그런데 그렇게 하기에는 너무 많은 코드를 들어 엎어야 하는 이슈가 있기에 그냥 방법 중 하나라고만 인지하고 넘어가려고 한다

이번에 적용한 방법은 그래서 락의 범위를 늘려주는 방식으로 처리했다 교착상태가 발생한 원인은 2개의 트랜잭션에서 순환적으로 2개의 로우를 업데이트하려고 하기에 발생한 상황이라고 했는데 해당 상황은 두 트랜잭션이 거의 동시에(0.094초인가..)에 같이 커밋되었고 업데이트 치는 순간에 락이 잡혀서 문제였으니, select for update 문을 통해서 락의 시간을 길게 늘려주고, 트랜잭션을 분리함으로써 처리하려고 했다

이렇게 까지해주면 우려하고 있었던 교착상태에 대한 처리는 해소되는 것을 테스트 코드를 통해서 확인했는데 추가적인 문제가 있었다 >> 이슈는 트랜잭션을 분리하면서 발생한 이슈인데, 기존에 테스트 코드 중에서 통계 로직이 수행되고 나서 해당 통계 데이터를 사용하는 부분을 검증하는 코드가 있었다 수정된 사항으로는 트랜잭션을 REQUIRES_NEW 을 통해서 처리해둔 상황이고, 루프를 도는 상황에서 전에 조회해두었던(새로운 트랜잭션에서 업데이트친 로우)를 디비로부터 조회해와서 사용하는 것이 아니라 jpa 에서 제공해주는 캐싱을 통해서 처리한다는 점이다 실제로 jpa 에서 우리가 흔히 알고 있는 영속성 컨텍스트는 각 트랜잭션 별로 생성되고 관리된다 > 특정 로우를 트랜잭션 A에서 먼저 조회해둔 다음, 해당 로우를 B에서 수정한다고 해서 트랜잭션 A는 트랜잭션 B에서의 수정사항을 바로 업데이트되어 가지고 있지 않는다는 것이였다 만약에 해당 케이스 같은 경우에는 뭐 방법은 몇 가지가 존재할 것이다 트랜잭션이 분리되어서 로직이 돌아가는 케이스에는 해당 로우를 조회할 때 네이티브 쿼리를 통해서 처리한다던가, 새로운 트랜잭션에서 처리한 값을 리턴하여 부모 트랜잭션에서도 변경된 값을 부모에서도 저장해서 영속성에 넣어주는 방법 이제 어떤 방식을 가지고 진행할까 고민하는 도중에 확인해보니 사실 로직에서는 그렇게 통계치를 쌓은 부분의 데이터를 부모 트랜잭션에서 사용하는 케이스가 있던 것은 아니였다..! 실제 로직을 계속 들여다봐도 뭔가 이상해서 테스트 코드를 봐보니.. 옛날에 테스트코드 위에다가 @Transactional 을 붙혀놔서 테스트 코드 자체가 묶여서 동작하고 있었던 것이다 그래서 자꾸 업데이트되지 않은 값을 가지고 검증을 진행하니 에러가 날수밖에.. 결론으로는 그래서 하나 배웠다 생각하고 @Transactional 으로 묶여있는 테스트코드를 분리하는 작업을 진행했었다

느낀점.. 백엔드 개발자로써 이제 문제사항들을 하나하나 파악하고 처리해가는 과정을 겪는데 여전히 공부가 많이 필요하고, 내가 알고 있었다고 생각한 것들이 100%가 아닌 케이스도 있더라.. 많은 선인들과 다른 개발자들과도 이슈에 대해서 공유하고 서로의 지식을 공유하며 더 나은 방향을 위해서 고민하는 것도 굉장이 중요하다고 생각이 든다