16.11 Infinispan

JBoss EAP 6에서는 웹 애플리케이션, EJB 애플리케이션의 클러스터링 기능을 제공하기 위하여 먼저 소개한 JGroups와 Infinispan라는 프로젝트를 내부에서 사용하고 있다.

Infinispan는 JBoss Cache 후속 프로젝트로 개발이 진행되고 있고 ‘JBoss Data Grid Platform’이라는 별도의 제품으로 판매되고 있다. JBoss EAP 6에도 클러스터링을 구현하기 위해서 Infinispan을 사용하고 있지만, 애플리케이션에서 Infinispan의 API를 직접 이용하는 경우에 대해서는 기술지원을 하지 않는다. 클러스터링 기능을 변경하려면 Infinispan의 캐시 컨테이너 설정을 변경한다.

JBoss EAP 6의 웹 애플리케이션 및 EJB 애플리케이션에서 캐시 데이터 복제 모드는 전체 노드에 모두 복사하는 replication방식과 일부 노드에만 복사하는dist 방식을 제공한다. 또, 통신모드는 동기(SYNC) 방식과 비동기(ASYNC) 두 가지 방식을 제공하고 있다. 기본값은 replication방식, 비동기 모드를 사용한다.

시스템 요건에 따라 다르겠지만, 대부분의 경우 위의 기본 설정으로도 충분한 성능과 신뢰성을 기대할 수 있다. 그러나 캐시 데이터 복제 모드에 대해서는 클러스터에 참여하는 노드 개수가 많을 경우 복제되는 객체의 개수 및 횟수가 많아져 메모리 이슈가 발생할 가능성이 있기 때문에 dist 모드로 변경하는 것이 좋다.

캐시 복제 모드

캐시 모드는 복제 대상을 클러스터 전체로 할 것인지, 임의의 노드로 할지를 설정하는 것이다. 전체를 대상으로 하려면 replication 모드를 선택하고, 임의의 노드로 복제하려면 distribution 모드를 선택한다. JBoss EAP 6는 기본값으로 replication 모드로 설정되어 있다.

replication 모드

클러스터 그룹내의 모든 서버 노드에 캐시를 복제한다. 모든 노드에 복제하기 때문에, 어느 서버 노드에 접속하더라도, 서버의 로컬에서 캐시 데이터를 사용할 수 있다.

그러나 모든 서버 노드에 캐시 데이터를 복제하기 때문에 네트워크 트래픽이 많고, 모든 노드의 복제본을 가지기 때문에 메모리 사용량도 많다. 또 SYNC 통신을 사용할 경우, 모든 서버 노드에 대해서 캐시 데이터 복제가 완료되어야 다음 작업을 처리할 수 있기 때문에, 서버 노드 수가 많아지면 캐시의 기록 속도가 느려져, 성능에 영향을 미치게 된다.

그림 . replication 모드의 복제 방법

distribution 모드

replication 모드는 전체서버 노드를 복제 대상으로 하고 있지만, distribution 모드는 캐시의 복제 대상을 클러스터내의 일부 노드들을 대상으로 한다. 또 복제 대상 서버 노드 개수를 임의로 설정할 수 있다. 이를 캐시 오너 수(Cache Owner)라고 한다.

JBoss EAP 5 까지는 Buddy Replication이라고 하는 캐시 replication 모드가 있었다. 이것은 특정 서버가 클러스터 내의 선택한 특정 서버 노드(buddy)에만 복제하는 기능이다. Infinispan의 Distribution 모드는 Buddy Replication과 비슷해 보이지만, Distribution 모드는 복제 대상을 지정하지 않아도 내부 알고리즘으로 판단하여 각각의 캐시마다 분산하여 복제하는 점이 다르다.

Distribution 모드에서 캐시는 Consistent Hash알고리즘을 사용하여 관리한다. 캐시 복제 대상 개수를 지정하여 사용하기 때문에, 동기(SYNC) 통신을 사용하더라도, 캐시의 저장 속도에 영향을 덜 받게 된다.

그림 16. dist 모드의 복제 방법

Consistent Hash

분산 캐시에 사용하는 해시 알고리즘이다. 단순한 해시에 키를 추가, 삭제했을 경우, 테이블의 사이즈 변경이 필요하여서, 키를 재 맵핑하는 시간이 오래 걸리게 된다. Consistent Hash을 이용하면 이 시간을 최소한으로 줄일 수 있다. Infinispan에서도 dist모드에서 어떤 노드에 데이터를 복제할지 결정하는데 이 알고리즘을 사용한다. 동적으로 노드의 개수가 증가하고 줄어드는 환경에서 자동으로 데이터를 분산하기 위해 사용하는 알고리즘이 Consistent Hash이다.

데이터를 저장하기 위한 대상 노드를 결정할 때 Consistent Hash 알고리즘을 이용하여 동적으로 노드 수가 증가하거나 감소할 때 자동으로 데이터를 분산한다. Memcached, Amazon’s Dynamo, Cassandra그리고 Riak 등의 제품에서 Consistent Hashing 을 활용하여 파티셔닝을 구현했다.

그림 . Consistent Hash

캐시 모드 변경 방법

캐시 모드를 Distribution 모드로 변경하려면 CLI 명령으로 아래와 같은 명령을 실행한다.

distribution 모드를 사용하는 경우 캐시 오너수도 설정할 수 있다.

따라하기

web 캐시 컨테이너로 이동

캐시 모드를 distribution 모드로 변경

캐시 오너 수 변경

web 캐시 컨테이너로 이동

   [standalone@localhost:9999 /] **cd /subsystem=infinispan/cache-container=web**

캐시 모드를 distribution 모드로 변경

[standalone@localhost:9999 cache-container=web] :write-attribute(name=default-cache, value=dist)
{
  "outcome" => "success",
  "response-headers" => {
    "operation-requires-reload" => true,
    "process-state" => "reload-required"
  }
}

캐시 오너수 변경

[standalone@localhost:9999 cache-container=web] cd distributed-cache=dist
[standalone@localhost:9999 distributed-cache=dist] :write-attribute(name=owners, value=3)
{
  "outcome" => "success",
  "response-headers" => {
    "operation-requires-reload" => true,
    "process-state" => "reload-required"
  }
}

EJB 애플리케이션의 경우에도 캐시모드를 변경하려면 위의 CLI에서 ‘cache-container=ejb’로 변경하여 설정하면 된다.

통신 방식

통신 방식은 비동기(ASYNC) 모드와 동기(SYNC) 모드의 두 가지 종류가 있다. 각각의 특징은 다음과 같다.

비동기(ASYNC) 모드
- 세션 복제시 비동기로 처리하여 응답 수신을 기다리지 않고 반환한다.
- 속도가 빠르다.
동기(SYNC) 모드
- 세션 복제시 모든 응답 수신이 완료되고 나서 응답을 준다.
- 백업까지 모두 성공적으로 된 것을 확인하기 때문에 신뢰성이 높다.
- 데이터 반영시 락을 걸고, 분산 2단계 커밋을 해서, 동일 데이터를 동시에 변경하면 에러가 발생한다.
- 속도가 상대적으로 느리다.

동기(SYNC) 모드로 변경하려면, CLI 명령으로 아래와 같이 설정을 변경한다.

[standalone@localhost:9999 /] cd /subsystem=infinispan/cache-container=web/replicated-cache=repl
[standalone@localhost:9999 replicated-cache=repl] :write-attribute(name=mode, value=SYNC)
{
  "outcome" => "success",
  "response-headers" => {
    "operation-requires-reload" => true,
    "process-state" => "reload-required"
}

캐시 복제 모드​

replication 모드​

distribution 모드​

Consistent Hash​

캐시 모드 변경 방법​

통신 방식​