2021-02-17(Wed)

항목	내용
학습 날짜	2021-02-17(수)
학습 시간	11:00~24:00
학습 범위 및 주제	비관적 동시제어
학습 목표	Dual 모듈에서 생긴 문제를 해결하고 ChatRoom을 마무리한다.
동료 학습 방법	eunhkim, jujeong, sanam, yohlee님과 페어 프로그래밍으로 문제를 해결했다.

상세 학습 내용

Q) 3명 이상의 유저가 동시에 '레더 게임' 매칭 신청을 하면 의도한 것과 다른 형태의 플레이어 수가 들어간 게임이 생성된다.

루비로 작성한 코드 로직에는 문제가 없는 것처럼 보였으나 이상하게 여러명의 유저가 동시에 게임 매칭 신청을 하면 이상현상이 나타났다.

가령 3명의 플레이어가 게임 신청을 하면 정상적인 게임(2명의 플레이어만 존재하며 왼쪽 오른쪽으로 플레이어 위치가 나뉘어진 형태)이 1게임 매칭되고 나머지 1명은 다른 플레이어가 레더 매칭을 신청하기를 기다려야한다. 그러나 지금은 3명의 플레이어가 게임 신청을 하면 비정상적인 게임(3명의 플레이어가 존재하며 왼쪽에 한명 오른쪽에 두명의 플레이어가 배치된 형태)이 1개 생성되는 경우가 종종 발생한다.

A)

루비로 작성한 처리흐름 코드 자체의 논리적인 문제는 없었다. 원인은 바로 DB 동시접근을 방비 하지 않았던 것이었다.

단순 transaction 처리를 통해서는 DB 동시 접근을 막을 수 없었다. 이 때 레일즈에서의 낙관적 동시성 제어는 에러가 있음을 확인했던 바가 있으므로 바로 비관적 동시제어를 고려했다. 결과적으로 with_lock 메서드를 활용해서 행 단위로 레코드 접근을 막는 식으로 해결하였다.

비관적 동시성 제어의 특징은 아래와 같다.

1. 사용자들이 같은 데이터를 동시에 수정할 것이라고 가정한다.

2. 한 사용자가 데이터를 읽는 시점에 Lock을 걸고 조회 또는 갱신처리가 완료될 때까지 이를 유지한다. 마치 뮤텍스!

3. Locking은 첫 번째 사용자가 트랜잭션을 완료하기 전까지 다른 사용자들이 그 데이터를 수정할 수 없게 만들기 때문에 비관적 동시성 제어를 잘못 사용하면 동시성을 저해 받게 된다.

4. 이런 문제를 해결하기 위해 lock 되어있는 DB에 접근할 때 무한정 기다리는 것이 아니라 일정 시간 동안만 기다리고 Exception을 만나도록 구현하는 경우가 있고 이 경우 오히려 동시성을 증가시킬 수 있다고 한다.

이 때 with_lock에 의해 Exception이 던져지고, 다시 트랜잭션을 시작할 때까지의 시간차를 sleep rand/100 같은 메서드를 활용해서 각 요청마다 다르게 조절하면 동시성을 증가시킬 수 있다!

https://medium.com/@vipulbest1/handling-concurrency-through-database-in-rails-part-1-8619ffe75f2d

https://selleo.com/blog/pessimistic-locking-in-rails

https://stackoverflow.com/questions/6867233/multiple-models-creation-and-updation-under-one-transaction/6867341

https://stackoverflow.com/questions/20819403/how-do-i-ensure-a-model-always-uses-a-transaction-and-locks-in-rails

https://www.honeybadger.io/blog/how-to-try-again-when-exceptions-happen-in-ruby/

https://kbs4674.tistory.com/164?category=876767

학습 내용에 대한 개인적인 총평

후후 동시성 제어에 대해서 더더욱 알게 되어 알찼다. 확실히 여러명이 머리를 맞대니 빠르게 문제가 풀리는구나 싶다.

다음 학습 계획

• chat message 프로필을 관리하는 방식 개선