memcache클러스터구성 (python-memcache 패키지)

memcache클러스터구성을 (python-memcache 패키지) 사용할때 느낀점 위주로 적는다.

---

• consistent Hasing 

  • 서버의 수가 변경되는 상황에서, 리퀘스트를 어떻게 분산처리할까로 부터나온 것으로, 서버의 개수가 변하더라도 전체 데이터에 대한 재분배가 필요없고 K/N의 key만 재분배하면 되도록 되어있는 알고리즘이다.  ( https://en.wikipedia.org/wiki/Distributed_hash_table )

• python-memcache 패키지

  • memcache.set(KEY, value)  KEY의 해시값으로 커넥션이-유효한-리얼서버 를 정한다.

  • 운영중 문제가 된 서버가 있는 경우? 
  • init_server List 로 mod 를 통해 서버를 찾는다. 
  • init_server List 는 문제가 된 서버를 제외하는게 아니기 때문에, 전체 키에 대한 재분배는 아니다.
  • 원래 문제가된 서버가 처리할 key 는 다른 서버로 분배된다.
  • ( 다만 memcache 를 증설할때는? 
  • init_server 에 mod이라 전체키의 재부분가 일어나겠지.. )

  • 멤캐시에 set할때, KEY를 tuple형태로 쓰게 되면(해시값, 밸류)로 동작하고, KEY만 쓰게되면 해시값을 만들어 리얼서버를 선택하게 되고, 

  • socket.error 나 connection.error가 있는 경우에, 해당 서버를 marking 해두고, 커넥션 할당에서 제외한다.

  • 이때, socket.close()  하기 때문에 커넥션에 문제가 없는한 소켓은 재사용한다.

테스트코드 : 리얼서버군으로 맴캐시를 구성해서 사용하게 되는 경우

# -*- coding: utf-8 -*- from unittest import TestCase import memcache import random class TestConsistentHasing(TestCase): def setUp(self): ServerList=["192.168.127.50:11211", "192.168.127.50:11212", "192.168.127.50:11213", "192.168.127.50:11214", "192.168.127.50:11215", "192.168.127.50:11216"] self.mc = memcache.Client(servers=ServerList,debug=1) def test_loop(self): res = [] for n in range(1000): res.append(self.test_set(str(n), n) ) print(res) def test_set(self, key, val): return self.mc.set( str(key), val) )




• 리얼서버목록중 1대 아이피를 잘못설정해서 커넥션에러를 내면?
  

  1회 다운 로직... inet:192.168.127.5:11212 서버가 커넥션타임아웃.. 이 과정에 다른 서버를 할당받는데 약간의 지연이 있음 --start 1464932793.03 MemCached: MemCache: inet:192.168.127.5:11212: connect: timed out. Marking dead. (using server inet:192.168.127.50:11213) --end 1464932796.03 남은 로직 처리... 2회로 계속 다운발생하면 :11213 으로 처리되는 과정에 지연은 없음

  
  

• 유효한 서버를 할당 받을때,모듈러를 하는데, init으로 들고 있던 서버리스트에 timeout 난 서버가 빠지는게 아니다. 그래서 이런 경우에는 timeout  발생한 서버가 처리 했어야 하는 key는 다른 서버로 분배가 된다.

결론
• 대수가 적을때는, 적절한 리퀘스트를 분배한다고 볼수없지만 대수가 많아지면 어느정도 (그래도 해시값/모듈러로 서버를 할당..)
• 데이터가 어떤 서버로 들어가게 될지, 해시값으로 알수는 있고 + 리얼서버중 특정서버에 문제가 생겼을때 문제가 된 서버로 요청은 안가겠다.
특정서버가 다운 + 업 + 다운 이런 시나리오인경우,
• 1차 다운일때는 다른 서버가 대신 데이터를 갖고있음
• 2차 다운일때는 충분히 오래된 데이터를 리턴할수 있을거 같다. 
• 그래서, expired 가 짧고, 데이터정합성을 크게 요하지 않는 경우에만 별다른 구성없이 쓰는데는 큰 문제 없을거 같다.