동시성 제어 Chap 2 | 분산락

이번주 멘토링 시 멘토님께서 내가 만든 Redis Cache + Scheduler + Spring Batch를 이용한 Update처리 로직 관련해서

동시에 여러 서버가 접근하면 어떻게 될 것 같나요? 라는 질문을 던져주셨고 멘토링 직전까지 해당 로직을 만들어내는데에 급급했던 나는

 

🙋🏻 Redis서버를 각 로컬에 생성한다면 아무 문제가 없지 않을까용 ? 이라고 대답을 하였다.

 

애기들 세명이 오락기 하나 가지고 싸우고있는데 이걸 어떻게 사이좋게 나눠서 놀도록 할 수 있을까? 대한 질문을 

오락기를 세개를 두면 되지 않나요?의 답변을 한 셈임

대답이 틀렸다고 할수는 없지만 동시성 제어 부분을 아예 생각도 안한걸 바로 들킬수 있는 구문이였다 

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

 

그래서 한발 늦었지만 성능 개선을 위해서 공부해보는 분산락 기법 💪🏻

 

---

🖍 분산락

: 서버가 여러대인 상황에서 동일한 데이터에 대한 동기화를 보장하기 위해서 사용

: 서버가 한대가 아니라 여러대인 경우 여러 서버로 API가 분산 호출되게 된다

: 서버들간의 동기화된 처리가 필요하고, 여러 서버에 공통된 락을 적용해야 하기 때문에 분산락을 사용한다.

 

🙋🏻 어떤 경우에 분산락 사용이 필요할까? 동시에 2개의 트랜잭션이 하나의 레코드에 접근하는 경우 같은 레코드 버전을 갖게 되는데, 이때 2개의 트랜잭션이 동시에 데이터를 변경한다면 한 트랜잭션에서 변경한 데이터 변경값 결과는 잃어버리고 우선적으로 처리 한 트랜잭션의 결과만 남게되거나, 마지막으로 처리한 결과만 남게 된다 .. !  상황에 따라 마지막 결과만 반영되면 되는 경우에는 분산락 처리를 별도로 해주지 않아도 되지만, 처리된 트랜잭션의 결과가 이후의 트랜잭션의 결과에도 영향이 있다면 트랜잭션이 순차적으로 처리 되어야한다.

 

여러가지 기술 중 동시에 요청이 와도 작업이 누락되지 않고, 정상적으로 처리 되어야한다는 부분에 초점을 맞춘다면 

사용할 수 있는 기술들은 아래와 같다.

 

• JPA Version 방식을 활용한 낙관적 락(Optimistic Locking)
• MySQL의 User Lock 활용하기
• Redis Java Client 중의 하나인 Redisson의 RLock을 활용하기

---

1) 낙관적 락(Optimistic Locking)

 

낙관적락은 이전 포스팅의 내용처럼 충돌을 감지하여 충돌이 발생할 경우 재시도하거나, 충돌이 발생한 데이터에 대해서 롤백하는 작업을 별도로 구현해야한다.

 

2) Mysql의 User Lock

 

사용자가 특정 문자열에 Lock을 걸 수 있는 Lock으로 어떠한 작업이 오래걸린다면 작업 시간만큼 Lock을 소유하는 기법

Connetion Pool과 Lock을 획득하는 DB Connetion Pool을 분리하는 작업이 필요하다.

 

3) Redis 기반 분산락

• Lettuce Client의 분산락 기법 :
  
  • Lock의 타임아웃이 지정되어있지 않음
  • 스핀락을 사용한 구현 기법으로 락을 획득하지 못한 경우 Redis에게 락을 획득하기 위해 계속 요청을 보내서 서버 부하 발생
  • Lock-Unlock하는 과정이 아주 짧아서 락 하는 경우가 드문 경우에는 유용함
• Redisson Client의 분산락 기법 : 
  
  • Lock에 타임아웃을 지정할 수 있어서 무한정 대기 상태로 빠질 수 있는 위험이 없음
  • pub/sub방식을 사용하므로 스핀락을 사용하지 않음 
    -> 락이 해제되면 락을 subscribe하는 클라이언트에게 락이 해제되었다는 신호를 보내줌
    -> 클라이언트들은 더이상 락 획득 확인 요청을 redis로 보내지 않음

---

🌀 0. 별첨 | 스핀락

: 스핀락은 락을 걸지 못하면 무한 루프를 돌면서 계속 락을 얻으려고 시도하는 동기화 기법

 

왼쪽  : Lock / 오른쪽 : Spin Lock

 

: '조금만 기다리면 바로 쓸 수 있는데 굳이 Context Switching으로 부하를 줄 필요가 있나?'라는 컨셉으로 개발된 기법

: 락을 얻지 못할경우 쉬지않고 계속 락을 얻으려는 시도를 하기 때문에 락하는 경우가 잦은 경우 서버에 많은 부하를 줌

: Lock-Unlock하는 과정이 아주 짧아서 락 하는 경우가 드문 경우에는 유용함

 

결론 

 

- CPU나 하나의 코어만 있는 경우에는 유용하지 않음

- 스핀락은 기본적으로 무한 for루프를 돌면서 Lock을 기다리므로 하나의 스레드가 lock을 오랫동안 가지고 있다면,
   다른 Blocking된 스레드는 busy Waiting을 하므로 CPU를 쓸대없이 낭비하게 됨

   ( Busy Waiting = 무한 루프를 돌면서 최대한 다른 스레드에게 CPU를 양보하지 않는 것 )

 

  

---

Redis 서버를 이미 구축해두었기 때문에 Redis의 두 기법 중에 고민해보면 될 것 같은데 

어떤 Lock 기법을 사용하는게 맞을지 조금 더 고민이 필요할 것 같다 🤔