동시성 제어 코드 작성
사용한 기술 : Redisson
후보 목록 : Redisson, lettuce, mySQL lock
장단점 비교 및 채택 이유
MySQL Lock- 해당 lock 은 DB에 직접 락을 거는 방식으로 DB내에서 트랜잭션에 대한 락을 거는 방식이다
비관적락, 낙관적락, 네임드락으로 소분할 수 있는데
- 비관적 락 같은 경우 구현이 간단하고 성능 저하가 우려되지 않는 동시에 DB 단의 락을 이용하기 때문에 데이터 무결성을 보증할 수 있지만 데드락 문제가 있고 트랙잭션 락이 끝나지 않으면 다음 트랙잭션의 대기가 우려된다
- 낙관적 락을 사용할 경우 해당 트랙잭션이 길어진다고 하더라도 다른 트랙잭션에 영향을 주지 않지만 로직이 비관적 락보다 복잡하고 재시도를 여러번 해서 성능 저하가 우려된다
- 네임드 락을 사용할 경우 분산락을 구현해서 다른 작업에 형향이 끼치지 않도록 할 수 있지만 락의 생명주기 로직을 모두 구현해주어야 한다
결국 MySQL락은 DB단에 걸리는 락 위주이기 때문에 report 같은 쓰기가 많을것으로 예상되는 현 상황에선 선택을 보류했다
Lettuce - Redis 에서 기본적으로 제공하는 lock 으로 이미 redis가 있는 현제 프로젝트에선 별도의 라이브러리 설치 없이 간단하게 사용할 수 있을것으로 예상된다. 하지만 서버에서 redis 캐시를 다른 용도로 사용하고 있다면 메모리 점유로 인한 문제가 생길 수 있다
- 기본적으로 redis 메모리 내에서 실행되므로 속도가 빠르고, db에 영향을 주지 않는다
- 별도 라이브러리 설치가 필요 없고, 빌드 시간도 필요 없다
- 기본적을 lettuce lock 은 spin lock 방식으로 락을 획득할 때 까지 지속적으로 재시도를 한다. 재시도가 여러번 반복되고 동시에 실행되는 경우 성능 이슈가 우려된다
- 분산 락을 구현하려고 하면 코드가 복잡해진다
Redisson - Redis 메모리를 이용한 락이라는 점은 lettuce 와 같으나 별도의 라이브러리 설치가 필요하고 최적화된 분산락을 기본 지원한다. 또한 동시성 제어를 위한 각종 기능들을 포함하고 있다.
- 기본적으로 redis 메모리 내에서 실행되므로 속도가 빠르고, db에 영향을 주지 않는다
- 기본으로 제공하는 분산락 (pub/sub) 방식으로 성능 이슈 없이 작동할 수 있다
- 따로 라이브러리를 설치해야 하며 빌드 시간이 추가된다
- redisson이 제공하는 기능들을 모두 쓰기 위해서는 많은 러닝커브가 예상된다
결정 Redisson - 지금 프로젝트에서는 엄청나게 많은 사용자가 동시에 몰리는 사태는 없을 것으로 판단하고 있기 때문에 성능이슈가 크게 문제가 되지 않을 것 같지만 프로젝트에 추가되는 구현사항이나 사용자 경험을 위해서 최대한 빠르고 확실한 락을 사용해야 겠다는 판단이 들었다 그리고 redis 캐시에 대한 재시도로 현제 다른곳에서 사용하고 있는 캐시에 대한 부담으로 공동작업하고 있는 다른 부분에 영향을 줄 수 있다는 생각이 들었다 redisson 같은 경우 러닝 커브가 크지만 간단한 락을 구현하는 정도라면 lettuce와 크게 차이가 없을 것이라고 생각됬고, 분산락 같은 경우는 기본으로 제공해 주기 떄문에 오히려 lettuce 보다 시간 비용이 적게 들것이라고 판단했다. 또한 프로젝트가 커질 수 있다면 redissond의 고급 기능을 사용하게 될 수도 있을 거라고 생각된다