Memcached를 이용한 Simple 분산 락에 대한 짧은 고찰

memcached는 분산 캐시 서버이다. redis 등의 또 다른 강력한 라이벌이 있지만, memcached는 Cache 라는 이름에 가장 부합하는

cache 서버이지 않을까 싶다. 왜냐하면, 특정 메모리 이상에서 LRU로 캐시가 날아가고, 디스크로의 Dump도 해주지 않는다.

(이게 사실 불편하긴 하다.) 하나의 Item도 1M가 넘는 것을 집어넣을 수 없고, 또한, Collection 도 지원해주지 않는다.

 

하지만, 정말 빠른 속도와, 가장 중요한, DHT 방식을 지원하면서, 캐시 서버를 무한대에 가까이 늘릴 수 있게 된다. 이 과정에서

데이터의 유실이 발생하지만, memcached는 태생이 Cache로 써라이기 때문에, 도리어 적합하다고 할 수 있지 않을까?

 

그런데 이 memcached 에 조금 특별한 부분이 있다. 그것은 operation 들이 모두 Atomic 하다는 것인데, protocol 파싱 레이어나

이런 부분 이외에 실제 데이터에 access 하는 연산은 모두 Lock 으로 인해서 Serialization 된다. 이 특성에 memcached 에 있는

add 라는 커맨드를 이용하면, 간단한 분산 락을 만들 수 있다.

 

add 라는 커맨드는 데이터가 존재하면 실패하게 된다. 즉, 이 명령을 이용해서 Lock을 획득하거나, 존재하는지에 대해서 알게 되는 것이다.

이미 시도를 한 사람이 있는데, http://bluxte.net/musings/2009/10/28/simple-distributed-lock-memcached 여기로 가보면

간단한 소스까지 볼 수 있다.

 

하지만 결론부터 말하자면, 개인적으로 이 것은 거의 ToyLock 이라고 봐야 할 것 같다. 아니면, Lock 자체가 그렇게까지 정밀하지

않아도 되는 상황에서 이용할 수 있을 것 같다.

 

먼저 어떤 disadvantage 가 있는지 보자면,

1. Lock 의 유실이다.

memcache 의 특성 상, DHT 를 이용하기 때문에, 서버리스트가 늘거나, 서버가 장애가 나면, 다른 서버가 해당 키의 범위를 커버하게 된다.

즉, 장비의 추가/삭제 시 마다 특정 락들이 유실되게 된다. 락이 중요한 서비스에서는 락 서버가 한대라도 장애가 나면, 문제가 생길 수 있다.

(이런 이유로, Zookeeper 같은 것들이 각광을 받는다는…) 즉, 락에 대한 리플리케이션이나 이에 대한 뭔가 보장이 필요하다.

 

2. Connection 유지가 되지 않는다.

zookeeper 는 클라이언트에 대한 컨넥션을 유지하다가 해제되면 이벤트를 발생시킨다. 하지만, memcache는 Store 로 설계되었으므로

이런 부분에 대한 처리는 없다. 다만… Expire Time 을 잘 조작해서 ^^ 클라이언트 장애시 자동으로 락이 풀리도록 할 수 있을 것 같다.

 

하지만, 락이 중요하지 않고, 간단하게 락서비스가 필요하다면, 스핀락 형태로 아주 간단하게 구현이 될 것 같다. 그리고 굉장히 성능도

좋은 락이 되지 않을까 싶다.