분산 lock, Named lock

최근 redis를 이용하면서, 한 개의 elastic cache에 여러 process가 접근하게 되었다!.. 이것이 MSA...

이때, 현재 동작방식으로는 redis의 값을 메모리에 캐싱해두고, 레디스의 값이 변하게 됐을 때, 캐시를 날리고 새롭게 받아올 수 있게 구성했다.

하지만 이러한 redis의 값을 변경하는 서버를 하나에서 지금 scale-out을 통해서 여러개로 늘리고 되었다!....

동시에 수정, 읽기 요청 등 race-condition 문제가 발생할 여지가 존재하기 때문에, 이를 해결할 방법으로 분산락을 적용하게 되었다.

const redis = require('redis');
const Lock = require('node-redis-lock');

const redisClient = redis.createClient({
  host: 'localhost',
  port: 6379
});

const lock = new Lock(redisClient, {
  timeout: 5000 
});

lock.acquire('myLock')
  .then(function() {
    // 성공적으로 락을 얻었을 때의 로직
    console.log('Lock acquired');

    // 작업이 끝났으면 락을 해제
    return lock.release('myLock');
  })
  .then(function() {
    // 락이 성공적으로 해제됐을 때의 로직
    console.log('Lock released');
  })
  .catch(function(err) {
    // 락을 얻거나 해제하는 데 실패했을 때의 로직
    console.error('Failed to acquire or release lock', err);
  });

위와 같은 방식을 통해서, 값의 수정이 필요할 때 lock을 잡아주고, 알 수 없는 이유로 프로그램이 멈췄을 때, deadlock을 방지하기 위하여 타임아웃이 설정되어 있다!....

---

위의 분산락을 보면서 최근 보았던 Named lock에 대해서도 다시 생각하게 되었다.
Namedlock 또한 GET_LOCK을 통해서 특정 name에 대해 lock을 얻고 timeout을 다시 얻을 수 있으니 같은 방식으로 동작할 수 있을 것이라 생각했고 자료를 찾아본 결과 그것이 맞았다!..

Mysql에서 namedlock을 통해 여러서버에서 동시적으로 접근하는 요청에 대해 제어하고 조율할 수 있다!...

이때, 의문점이 들었는데 기존에 xLock을 통해서도 이러한 문제가 해결 가능한데!..왜 굳이 Named lock이 필요할까 라는 고민이었다.

이는 아래에서 의문이 해소되었다!..

https://techblog.woowahan.com/2631/

xLock을 통해서 해결을 하려면 결국 해당 record가 존해해야 한다. 하지만 동시에 여러개의 서버에서 생성요청이 들어왔을 때, User한명당 2개의 카드만 가질 수 있는 제약조건을 실행하려면 Named Lock을 통해서 lock을 잡아서 처리를 해줘야 2개의 제약조건을 지키며 실행할 수 있는 것이다!...

이번에 다시한번 lock에 대해 알아보는 시간을 가져 무척 재미있게 봤던 것 같다.