서론

은행 시스템을 구현해보는 프로젝트를 진행했다.
은행 시스템에서 제일 중요한 것은 데이터의 정합성이다.
데이터의 정합성을 만족시키기 위해서는 작업중인 데이터에 대해서 쓰기, 읽기에 대한 락을 걸어야한다.
Lock을 거는 방식은 크게 데이터베이스 해당 Column에 직접 Lock을 거는 방식과 레디스 등을 통한 별도의 저장소로 락 권한을 부여하는 것이다.
현재 테스트는 단일 시스템 환경이지만 두 방식이 어떤 퍼포먼스를 보이는지 테스트 해봤다.

Lettuce vs Redisson

Lettuce의 경우 Lock 획득을 실패할 경우 Lock을 획득할 때 까지 계속 락 획득 요청을 보내는 스핀 Lock의 형태이다.
Redisson의 경우 pub&sub 시스템으로 Lock 획득에 실패할 시 대기하고, 기존에 Lock 권한을 가지고 있던 스레드가 락의 권한을 다 사용했을 때 중앙 시스템으로 완료 메세지를 보내고 중앙 시스템은 해당 대기중인 스레드에 락 권한을 제공해준다.
은행 시스템의 경우 한 계좌에 대한 여러 요청이 들어올 경우 모든 스레드들이 대기하고 있는 상태이기에 모든 스레드들의 스핀락 방식의 요청은 시스템에 무리를 줄 것이라 판단해 Redisson 방식을 사용했다.

테스트 시나리오

테스트의 환경의 경우 h2 db Lock사용, h2 db + Redisson, mysql + Redisson, mysql 비관적 Lock 사용으로 나누었다.
트랜잭션 로직에 데이터베이스 접속은 불가피하기에 나눈것이다.
테스트의 경우 계좌1->계좌2로 송금하는 시나리오로 각 환경마다 같은 요청의 10, 100, 1000, 10000개의 스레드를 발생시키고 처리 시간을 살펴보았다.

결과

h2 db를 사용한 테스트는 h2 db가 테스트에 최적화 된 실전과는 먼 db이기에 테스트 결과 판단에서 제외한다.
결과는 MySQL 비관적 Lock 방식이 Redisson 방식보다 빨랐다.
하지만 단일 시스템 환경의 경우 후자의 방식의 경우 MySQL과 Redisson 접속의 2번의 네트워크 연결로 인해 단일 네트워크 접속인 MySQL 비관적 Lock 방식보다 느린것으로 보인다.

결론

h2 db를 사용했을때와 mysql을 사용했을때 Redisson의 속도 차이를 보면 Redisson 자체의 자동 Lock 해제 기능, 단일 DB 접속에 대한 분산 서버들의 커넥션 관련 이슈를 생각한다면 분산 시스템에선 Redisson을 사용하는 것이 유리하다고 판단한다.
테스트 코드를 작성하며 Excutor을 사용한 스레드 병렬 테스트를 진행했는데, 테스트 클래스에 트랜잭션 어노테이션을 붙이니 데드락 발생, 영속성 문제 등 여러 문제가 생겨 어려움을 겪었다.
해당 문제가 생기는 이유에 대해선 더 공부해봐야 할 것 같다.
또한, 처음 시스템을 설계할 때 트랜잭션 어노테이션을 붙인 한 메소드 안에서 모든 로직을 구현했었는데,
트랜잭션 속에서 락 획득, 반납이 이루어지다보니 예상하지 못한 스레드의 접근이 이루어저 데이터 정합성 이슈가 생겼었고, 락과 트랜잭션을 분리함으로 해결했다.