16.6.2.4 memcached의 해시 / 분포 유형
memcached 클라이언트 인터페이스는 특정 memcached 인스턴스의 데이터를 설정 또는 취득 할 때 어떤 호스트를 사용 해야할지 결정하기 위해 다중 서버 구성에서 사용되는 다른 분포 알고리즘을 지원합니다. 값을 가져 오거나 설정하면 지정된 키에서 해시가 만들어지고 구성된 서버 목록에서 호스트를 선택하는 데 사용됩니다. 해시 메커니즘은 지정된 키를 해시 기반으로 사용하기위한 설정 작업과 검색 작업에서 동일한 서버가 선택됩니다.
이 프로세스는 다음과 같이 생각할 수 있습니다. 일련의 서버 (a, b, c)가있어, 클라이언트는 저장하거나 검색하는 키를 기준 정수를 반환하는 해시 알고리즘을 사용합니다. 생성 된 값을 사용하여 클라이언트에 구성된 서버 목록에서 서버를 선택합니다. memcache 클라이언트의 가장 표준적인 클라이언트 해시에서는 구성된 memcached 서버의 숫자로 값을 나누는 간단한 계수 계산이 사용됩니다. 이 과정은 의사 코드에서 다음과 같이 요약 할 수 있습니다.
@memcservers = ['a.memc','b.memc','c.memc']; $value = hash($key); $chosen = $value % length(@memcservers);
위의 값으로 바꾸면 :
@memcservers = ['a.memc','b.memc','c.memc'];
$value = hash('myid');
$chosen = 7009 % 3;
위의 예에서는 클라이언트의 해시 알고리즘에 의해 인덱스 1 ( 7009 % 3 = 1 ) 서버가 선택되어 그 서버에서 키와 값을 저장하거나 검색됩니다.
이 선택과 해시 프로세스는 사용하는 memcached 클라이언트에 의해 자동으로 처리됩니다. 사용자가 사용하는 memcached 서버의 목록을 제공하기 만하면됩니다.
다음 그림 16.5 "memcached의 해시 선택" 이를 그래픽으로 표현한 것입니다.
그림 16.5 memcached의 해시 선택
같은 해시 선택 과정은 memcached 클라이언트의 지정된 키 조작으로 실행됩니다.
이 방법을 사용하면 몇 가지 이점을 얻을 수 있습니다.
연결할 서버의 해시와 선택이 클라이언트의 내부에서 완전히 처리됩니다. 그러면 연결하는 올바른 시스템을 결정하기 위해 네트워크 통신을 할 필요가 없습니다.
memcached 서버의 결정이 클라이언트의 내부에서 완전히 이루어지기 때문에 실행되는 조작 (설정, 검색, 증분 등)에 관계없이 서버를 자동으로 선택할 수 있습니다.
이 결정은 클라이언트에서 처리되기 때문에 해시 알고리즘은 특정 키에 대해 동일한 값을 반환합니다. 서버 환경의 차이에 의해 값이 영향을 받거나 재설정 할 수는 없습니다.
선택은 매우 빠릅니다. 키 값에 대한 해시 알고리즘은 고속이며, 그 결과 사용 가능한 기계의 간단한 배열에서 서버가 선택됩니다.
클라이언트 측의 해시를 사용하여 각 memcached 서버 간의 데이터의 분포가 간소화됩니다. 해시 알고리즘에 의해 반환되는 값의 자연 분포에서는 사용 가능한 서버간에 키가 자동으로 분산됩니다.
클라이언트에서 구성되는 서버 목록이 동일하게 유지한다면 저장되어있는 같은 키에 의해 같은 값이 반환 된 경우, 서버가 선택됩니다.
그러나 동일한 해시 메커니즘을 사용하지 않으면 동일한 데이터를 다른 인터페이스를 통해 다른 서버에 기록되고 memcached 공간이 낭비 될뿐만 아니라 정보의 차이로 이어질 수 있습니다.
멀티 인터페이스 호환 해시 메커니즘을 사용하는 한 가지 방법은 libmemcached 라이브러리와 관련 인터페이스를 사용하는 것입니다. 다른 언어 (C, Ruby, Perl, Python 포함) 인터페이스가 동일한 클라이언트 라이브러리 인터페이스를 사용하기 때문에 ID에서 항상 같은 해시 코드가 생성됩니다.
클라이언트 측에서 서버를 선택하는 경우의 문제는 memcached 서버를 사용하는 각 클라이언트에서 서버 목록 (그 순서를 포함)의 일관성을 유지하고 그 서버를 사용 가능하게 해 둘 필요가있는 것입니다 . 다음의 경우, 키에 대해 작업을 수행하려는 경우 :
사용 가능한 인스턴스 목록에 새 memcached 인스턴스를 추가 한
사용 가능한 인스턴스 목록에서 memcached 인스턴스를 삭제 한
memcached 인스턴스의 순서가 변경된
특정 키에 해시 알고리즘이 사용되는 경우 서버 목록이 다른 경우 해시 계산에 의해 목록에서 다른 서버가 선택 될 가능성이 있습니다.
다음 예제의 new.memc 처럼 서버 목록에 새 memcached 인스턴스가 추가 된 경우 동일한 키 ( myid )를 사용하는 GET 조작을 통해 캐시 미스가 발생합니다. 이것은이 키에서 동일한 값이 산출 된 서버의 배열에서 동일한 인덱스가 선택되는데, 인덱스 2는 데이터가 원래 저장되어있는 서버 c.memc 대신 새로운 서버를 가리 키도록 되었기 때문입니다. 따라서 다른 memcached 인스턴스 캐시에 그 키가 존재에도 불구하고, 캐시 미스가 발생합니다.
그림 16.6 새로운 memcached 인스턴스를 포함 memcached의 해시 선택
이것은 c.memc 과 new.memc 모두 키 myid 정보가 포함되는 것을 의미합니다,이 키에 대해 각 서버에 저장되는 정보는 각 인스턴스에서 다를 수 있습니다. 더 중요한 문제는 새로운 서버에서 키의 분포가 변화함에 따라 데이터 취득시의 캐시 미스의 수가 크게 증가하는 것입니다. 또한이 결과로 memcached 인스턴스에 캐시 된 데이터를 재 구축 할 필요가 있기 때문에 데이터베이스 읽기 횟수가 증가합니다.
클라이언트에 구성되어있는 서버 목록을 능동적으로 관리 구성된 memcached 인스턴스가 사용 가능한 것으로 확인 된 경우 각 인스턴스 추가 및 제거하는 경우에도 같은 결과가 될 가능성이 있습니다. 예를 들어, memcached 인스턴스를 연결할 수 없게 된 것을 클라이언트가 탐지 한 경우에 그 인스턴스를 제거하면 여기에 나타낸 바와 같이 서버의 선택이 실패 할 수 있습니다.
이는 심각한 문제가 발생하여 캐시가 해제되는 것을 방지하기 위해 서버 선택에 사용하는 해시 알고리즘을 선택할 수 있습니다. 해시 알고리즘은 일관성과 모듈의 2 개의 일반적인 유형이 있습니다.
일관성 해시 알고리즘은 구성된 서버의 목록이 변경된 경우에도 동일한 키를 서버 목록에 적용하면 동일한 서버를 사용하여 키를 저장하거나 검색됩니다. 이것은 구성 목록의 서버를 추가 및 제거하면서 특정 키에 대해 항상 동일한 서버를 사용할 수 있음을 의미합니다. 사용 가능한 일치 해시 알고리즘은 Ketama와 Wheel의 두 가지 유형이 있습니다. 두 유형 모두 libmemcached 의해 지원되고 PHP와 Java의 구현을 사용할 수 있습니다.
일관성 해시 알고리즘에는 몇 가지 제한이 있습니다. 기존에 구성된 서버 목록에 서버를 추가하면 정상 분포의 일부로 새 서버에 키가 분배됩니다. 목록에서 서버를 제거하면 그 키는 목록에있는 다른 서버에 재 할당되기 때문에 캐시에 정보를 다시 채울 필요가 있습니다. 또한 일관성 해시 알고리즘은 여러 클라이언트간에 서버를 일관되게 선택해야 있음에도 불구하고 각 클라이언트에 다른 서버 목록이 포함되어 있다는 문제가 해결되지 않습니다. 무결성이 적용되는 하나의 클라이언트의 내부뿐입니다.
모듈 해시 알고리즘은 클라이언트가 해시를 계산하여 구성된 서버 목록에서 서버를 선택하여 서버를 선택합니다. 서버 목록이 변경되면 모듈 해시 알고리즘을 사용하여 선택되는 서버도 바뀝니다. 따라서 위의 동작이 발생합니다. 서버 목록의 변경 데이터를 검색 할 때 다른 서버가 선택되는 것을 의미하고 캐시에 정보가 다시 채워 때문에 캐시 미스와 데이터베이스 부하의 증가로 이어집니다.
각 클라이언트에서 memcached 인스턴스를 하나만 사용하거나 클라이언트에 구성된 memcached 서버의 목록이 한번도 변경되지 않은 경우 해시 알고리즘의 선택에 의한 큰 효과도 없기 때문에 중요하지 않습니다.
서버를 정기적으로 변경하거나 다수의 클라이언트가 공유하는 공통 서버 설정을 사용하는 경우는 일관성 해시 알고리즘을 사용하여 확실하게 캐시 데이터의 중복을 방지하고 데이터를 균등하게 분배 쉬워집니다.