twemproxy는 태생이 memcache를 위한 lightweight server side proxy를 목표로 태어났습니다. 그래서 최소한의 오버헤드만 주면서 서비스를 하는게 목표였던 거죠. 그런데 얼마전부터 redis 프로토콜도 지원하기 시작했습니다. 그렇다면 twemproxy와 redis의 궁합은 어떨까요?
만구, 제 생각이긴 하지만, twemproxy와 redis의 궁합은 별로 좋지 않습니다. redis와 memcache 가 태생이 DataStore 와 Cache 로 나눠진 것 처럼, 이를 지원하는 proxy도 이 초기 설계가 이런 특성에 영향을 받기 때문입니다.
일단 제가 생각하는 twemproxy 와의 가장 중요한 이슈는 redis와 memcache의 본질적인 차이 때문입니다.
예를 들어, memcache의 경우 기본적으로 서버가 종료하면 모든 데이터가 사라집니다. 하지만, redis의 경우는 RDB 라는 것을 이용해서 데이터를 저장하게 됩니다. 이렇게 되면, 종료시나 장애시에도 기존 데이터가 남아있게 됩니다. 이렇게 되면, 장래로 인해서 특정 A 서버가 문제가 발생했다가 이 동안에 Consistent-Hashing으로 다른 B 서버에 저장되면, 해당 A 서버 복구시에, 이전 올드 데이터를 받게 되는 문제가 발생할 수 있습니다.
이 외에도 사소한 이슈들이 있습니다. “AUTH”, “FLUSHALL”, “INFO” 같은 명령을 사용할 수 없으므로, 특정 상황에서만 Redis를 사용할 수 있다는 것입니다. 특히 Redis 내부에서 “SELECT” 명령을 통해서 DB를 구분해서 사용하는 경우에는 twemproxy를 사용하시면 안됩니다. 왜냐하면 redis의 SELECT는 클라이언트당 현재 사용 DB를 설정하게 됩니다. 이럴 경우 SELECT 명령이 twemproxy에서 허용이 된다면(지금 안되고, 아마 앞으로도 안될것 같습니다.) 한 클라이언트가 SELECT 명령을 사용할 경우, 다른 클라이언트들도 전부 DB가 바뀌는 것과 동일한 현상이 발생하게 됩니다.
int selectDb(redisClient *c, int id) {
if (id < 0 || id >= server.dbnum)
return REDIS_ERR;
c->db = &server.db[id];
return REDIS_OK;
}
다만 Redis 자체의 Cluster Mode에서도”SELECT” 명령은 금지될 것으로 보이기 때문에, 차후를 위해서 Redis의 “SELECT” 명령을 통해서 여러 DB를 사용하는 것은 피하시는 것이 좋습니다. 사실 key 명령을 사용하는 경우를 제외하고는 관리상의 이점을 빼고 성능상으로는 하나의 DB를 이용하나, 여러개의 DB를 이용하나 한대의 Redis에서는 성능 차가 없습니다.
즉, 아직까지 twemproxy와 Redis의 궁합은 별로라고 할 수 있습니다.
Charsyam's Blog 