안녕하세요 freeman 입니다.
이번에는 지난 강좌에 이에 연속적으로 다루어보는 DataGrid 를 활용한 글로벌 캐시 구성 가이드입니다.
많은 참조 부탁드리며 하단의 강좌를 시작하도록 하겠습니다.
WebSphere eXtreme Scale v8.6
DataGrid 를 활용한 글로벌 캐시 구성 가이드
0) DataGrid 를 활용한 글로벌 캐시란?
이
전 강좌에서는 IBM WXS 의 기본 구조와 이를 활용한 HTTP 세션 관리에 대해서 살펴봤었습니다. WXS 의 컨테이너 서버로
구성된 Grid 를 활용하여 HTTP 세션 데이터를 캐시 해두고 여러 클라이언트(WAS)가 접근하여 HTTP 세션 데이터를
동일하게 유지하는 방안을 보았는데 이번 강좌에서는 이와 비슷하게 DataGrid 에 HTTP 세션 데이터 대신에 원하는 형태의 Java
객체를 캐시(저장) 해두고 여러 클라이언트가 접속해서 해당 정보를 활용할 수 있는 방안(글로벌 캐시)에 대해서 간단하게 샘플을
활용하여 설명 드리도록 하겠습니다. 구조와 설정부분은 이전 강좌와 거의 비슷하지만 HTTP 세션 유지를 위한 필터가 필요 없으며
HTTP 세션 데이터 대신에 원하는 형태의 Java 객체를 저장하고 활용하는 것만 다릅니다.
1) IBM WebSphere eXtreme Scale(WXS) 설치 및 기본 구성
설
치 및 구성의 경우는 지난 강좌에서 다루었던 HTTP 세션 복제를 구성한 형태와 동일하게 서비스를 수행하는 WAS 에
클라이언트(몇 개의 jar 파일) 가 설치되며 WXS 는 standalone 형태의 서버가 존재하는 아키텍처를 가정하고 진행하도록
하겠습니다.
2) IBM WebSphere eXtream Scale Server 구성
① IBM WXS 의 카탈로그 서버와 컨테이너 서버의 구성을 결정하는 설정 정보 파일 준비
일
반적으로 설치되어 있는 [WXS 설치디렉토리]/ObjectGrid/wesb 디렉토리에 설정 샘플파일이 들어있으며 해당
샘플파일을(wesb_objectGrid.xml, wesb_objectGridDeployment.xml) 약간 변형해서 사용하는
형태로 가이드를 진행하도록 하겠습니다.
중요 부분 in wesb_objectGrid.xml
<objectGrids>
<objectGrid name="Grid">
<backingMap name="Customer" lockStrategy="PESSIMISTIC" ttlEvictorType="CREATION_TIME" timeToLive="600"/>
</objectGrid>
</objectGrids>
샘
플로 제공되는 objectGrid 설정 파일을 살펴보면 단순하게 Customer 라는 backingMap 을 하나 만드는
설정입니다. backingMap 은 실제 캐시된 객체가 저장되며 이전에 설명했던 Grid 내부의 파티션 안에 존재합니다. 그 뒤의
설정들을 계속 살펴보면 락 전략은 pessimistic 방식으로 수행하고 ttl Evictor 를 지정하는데 ttl
Evictor 란 시간 기반으로 캐시를 버리는 형태의 모듈입니다. 설정을 읽어보면 바로 이해할 수 있는 것처럼 생성된 시간 이후로
600 초가 지나면 캐시가 무효하다고 보고 버리도록 설정된 것입니다.
변경 부분 in wesb_objectGrid2.xml
<objectGrids>
<objectGrid name="Grid">
<backingMap name="CacheData01" lockStrategy="PESSIMISTIC"
copyMode="COPY_TO_BYTES" ttlEvictorType="LAST_ACCESS_TIME"
timeToLive="600"/>
</objectGrid>
</objectGrids>
사
용의 편의를 위해 이를 상단과 같이 변경합니다. 변경된 부분을 간단하게 설명드리면 이름을 CacheData01 로 변경했고
copyMode="COPY_TO_BYTES" 를 추가하여 eXtreme data format (XDF) 을 사용할수 있도록
하였습니다. XDF 는 IBM 이 만든 WXS 고유의 포멧으로 Java 뿐만이 아니라 C# 이나 .NET 에서도 사용될 수 있는
직렬화 포멧으로 성능 및 메모리 사용율이 우수한 포멧입니다. ttl Evictor 는 “LAST_ACCESS_TIME” 으로
변경하여 생성 시간 대신에 마지막 접속 시간을 기준으로 캐시된 데이터를 만료시키도록 설정을 변경하였습니다.
다음으로 Grid Container 배치관련 설정파일을 살펴보도록 하겠습니다.
중요 부분 in wesb_objectGridDeployment.xml
<objectgridDeployment objectgridName="Grid">
<mapSet name="mapSet" numberOfPartitions="13" minSyncReplicas="0" maxSyncReplicas="1" >
<map ref="Customer"/>
</mapSet>
</objectgridDeployment>
샘
플로 제공되는 objectGridDeployment 설정 파일을 살펴보면 objectgrid 이름은 Grid 이며 mapSet
이라는 이름의 mapSet 을 하나 만들고 파티션의 개수는 13개, 동기화 형태로 복제를 수행해서 가지고 있는 복제복의 최대
개수는 1 로 설정하였습니다. 이렇게 만든 mapSet 안에는 Customer 라는 map 이 하나 들어 있는 형태입니다..
중요 부분 in wesb_objectGridDeployment2.xml
<objectgridDeployment objectgridName="Grid">
<mapSet name="mapSet" numberOfPartitions="5" minSyncReplicas="0" maxSyncReplicas="1" >
<map ref="CacheData01"/>
</mapSet>
</objectgridDeployment>
간단하게 테스하는게 목적이라 해당 설정의 파티션 개수를 줄이고 map 이름만 objectGrid 와 동일하게 변경하고 수정을 마칩니다.
나
머지 설정은 지난 강좌와 동일하게 사용하도록 하며 여기까지 하셨다면 WXS Server 에 대한 준비가 완료된 것 입니다. 참고로
말씀드린 것처럼 나머지 부분은 지난 강좌와 동일하게 사용해도 되지만 간단한 테스트를 위해서 제가 테스트시에 간단하게 만들었던
시작 스크립트를 첨부드리오니 참고하시기 바라겠습니다.
카탈로그 서버
startXsServer cat1 -listenerPort 4809 -JMXServicePort 4899 -catalogServiceEndPoints cat1:kr050578:6600:6601
카
탈로그 서버 스크립트는 이전과 동일하지만 시작을 위한 다양한 방안을 보여주기 위하여 이번에는 바로 script 로 실행하는 방안을
예시로 보여드린 것 입니다. 시작시에 조금 더 명확하게 필요한 포트를 명시하기 위해서 서비스를 위한 JMXServicePort
파라미터를 지정했습니다. (지정하지 않으면 비어있는 포트 자동 할당)
컨테이너 서버
startXsServer
c1 -listenerPort 5001 -haManagerPort 5002 -objectGridFile
C:\IBM\WebSphere85\eXtremeScale\ObjectGrid\wesb\wesb_objectGrid2.xml
-deploymentPolicyFile
C:\IBM\WebSphere85\eXtremeScale\ObjectGrid\wesb\wesb_objectGridDeployment2.xml
-catalogServiceEndPoints kr050578:4809
컨테이너 서버 스크립트도 이전과 동일하지만
마찬가지로 직접 실행하는 형태의 스크립트를 사용했으며 조금 더 명확하게 haManagerPort 를 명시적으로 지정했습니다.
haManagerPort 포트는 컨테이너간에 서로 살아있는지 확인하는 heartbeat 를 주고 받는 포트입니다. 마찬가지로
이러한 형태로 별도 지정하지 않으면 비어있는 포트가 자동으로 할당 됩니다.
위에서 언급한 스크립트를 WXS 의
카탈로그 서버와 컨테이너 서버를 구동하면 하단과 같은 결과를 확인할 수 잇습니다. (참고로 복제본은 그리드 설정이
minSyncReplicas="0" maxSyncReplicas="1" 이기 때문에 컨테이너 서버를 하나 더 두게 되는 경우에
확인하실 수 있습니다.)
xscmd -c showMapSizes -cep kr050578:4809
여기까지 하시면 WXS 를 활용한 글로벌 캐시를 위하여 WXS 의 Grid 준비는 다 완료하신 것 입니다.
3) WXS 클라이언트 용 애플리케이션 개발
당
연히 WXS 를 활용한 글로벌 캐시에 접속하고 데이터를 저장하거나 가져오기 위해서는 해당 애플리케이션에서 WXS 에서 제공되는
API 를 사용해서 호출을 해주어야 합니다. WXS 는 Grid 에 데이터를 저장하거나 가져오기 위해서 다양한 API 를 제공하며
이번 파트에서는 실제로 해당 부분을 직접 살펴보도록 하겠습니다.
이번 강좌에서는 이전 강좌처럼 WXS 클라이언트가
설치된 IBM WAS 제품이라면 별도의 라이브러리 추가나 설정이 필요하지 않습니다. 그러나 WXS 클라이언트가 설치되지 않은
경우라면 (예:standalone 형태의 Java 클라이언트 사용) ogclient.jar 파일이나 wsogclient.jar
파일만 클라이언트 애플리케이션에서 참조하시면 됩니다.
그럼 말씀 드린 환경에서 간단한 샘플 애플리케이션을 개발해
보도록 하겠습니다. 우선은 WXS 에서 제공되는 API 를 활용하여 카탈로그 서버에 접속하는 코드를 하단과 같이 작성합니다.
참고적으로 해당 부분은 계속 재사용되기 때문에 싱글톤 형태로 구성하는 것도 하나의 좋은 방법입니다.
보
시면 아시겠지만 ObjectGridManagerFactory 를 사용하여 ObjectGridManager 를 받아와서 연결을
수행하여 ObjectGrid 를 가지고 오는 형태로 간단하게 구성가능 합니다. (참고로 이번 강좌에서 endpoint 는 카탈로그
서버 주소:포트 형태로 “kr050578:4809” 을 gridName 은 접속하고자 하는 Gird 이름으로 “Grid” 를
입력합니다.)
다음으로 서블릿 페이지를 하나 만들어서 하단의 코드를 이용해서 WXS 캐시에 데이터를 input 하는 코드를 작성합니다.
여기서는 GridObject 를 이용하여 session 을 맺고 ObjectMap 에 원하는 데이터를 insert 하는 형태로 진행됩니다. 하단의 Grid 의 내부 구조를 보시면 좀 더 이해에 도움이 됩니다.
(참 고로 이번 강좌에서는 DB 와 동기화를 위한 Loader 를 사용하지 않으며 클라이언트에서 보관하는 Near Cache 는 락 전략을 NONE이나 OPTIMISTIC 을 사용했을 때 같이 사용 가능합니다. 유연한 락 전략을 사용하는 대신에 동시성에 민감하지 않은 업무를 대상으로 한다면 캐시를 로컬에서도 보유할 수 있기 때문에 당연히 보다 높은 성능을 기대할 수 있습니다. 현재 강좌에서는 해당 부분에 대한 자세한 설명은 생략하도록 하며 향후 기회가 있을 때 다시 다루겠습니다.)
즉, ObjectMap 은 Grid 에 저장된 BackingMap 과 연결되어 실제로 가지고 오는 Map 객체이며 내부적으로 Key, Value 쌍을 가지고 있게 됩니다.
Grid 에 데이터를 저장하는 애플리케이션 개발이 완료되었다면 이제 그와 비슷하게 서블릿 페이지를 하나 더 만들어서 이번에는 WXS 의 Grid 에 캐시된 정보를 반환하는 코드를 하단과 같이 작성합니다.
여기까지 하시면 단순하지만 WXS 로 구성된 글로벌 캐시에 데이터를 저장하고 가지고 오는 클라이언트용 테스트 애플리케이션 작성이 완료된 것입니다.
추
가적으로 ObjectMap 은 지금 보여드린 insert() 나 get() 이외에 remove(), update(),
upsert() – ‘데이터가 있으면 update(), 없으면 insert() 수행’ 와 같은 다양한 API 를 같이 제공하오니 좀
더 자세한 부분을 알고 싶다면 하단의 ObjectMap API 를 참고하시기 바라겠습니다.
http://www-01.ibm.com/support/knowledgecenter/SSTVLU_8.6.0/com.ibm.websphere.extremescale.javadoc.doc/topics/com/ibm/websphere/objectgrid/ObjectMap.html?lang=en
4) WXS 의 Grid 를 활용한 글로벌 캐시 테스트
작성된 애플리케이션을 클라이언트로 사용할 WAS 에 모두 배포한 후에 하단과 같이 WXS 캐시에 데이터를 저장하는 서블릿을 호출합니다. 
호출이 정상적으로 수행이 완료되면 하단과 같이 WXS Grid 컨테이너에 데이터가 저장 된 것을 확인할 수 있습니다. (당연히 이전 강좌에 소개해드린 것처럼 xscmd 명령을 통해서 저장된 데이터의 내용을 확인할 수도 있습니다.)
다음으로 WXS 캐시에서 데이터를 가지고 오는 서블릿 페이지를 연속해서 호출합니다.
첨
부한 결과를 보시면 아시겠지만 정상적으로 캐시에 저장된 데이터를 화면으로 확인할 수 있습니다. 이와 마찬가지로 다른 WAS 서버로
해당 애플리케이션을 배포하여 데이터를 가지고 오는 서블릿 페이지만을 호출해보면 해당 WAS 인스턴스 쪽에는 값이 저장되어 있지
않지만 글로벌 캐시 형태와 동일하게 이전에 1번 서버에서 저장한 데이터를 WXS 로 구현한 캐시 계층에서 정상적으로 반환하는 것을
확인할 수 있습니다.
이
를 좀더 정리하는 차원에서 다시 한번 설명 드리면 최초로 언급한 것과 같은 형태의 여러 클라이언트가 동시에 참조할 수 있는 글로벌
캐시 구성을 수행한 것이며 이를 통해서 클라이언트가 Grid 영역의 글로벌 캐시에 접속하여 데이터를 저장하거나 읽는 작업을
수행하는 것 입니다.
이렇게 하면 비교적 간단하게 WXS 를 활용한 글로벌 캐시 구성 완료 및 테스트를 수행해봤습니다.
마지막으로 아무 호출을 하지 않고 600 초를 기다린 후 조회 서블릿을 호출해보면 캐시된 데이터가 만료되어서 하단과 같이 null 을 반환하는 것을 확인할 수 있습니다.
(당연히 이전 objectGrid 설정에서 ttlEvictorType 를 NONE 으로 설정하시게 되면 시간이 지난다고 해도 만료되거나 제거 시키지 않을 수도 있습니다.)
여기까지 잘 따라오셨다면 간단하게 WXS 를 활용한 글로벌 캐시 구성 및 테스트를 문제 없이 완료하신 것입니다.
9) 참고 자료
[WXS]WXS 를 활용한 In-Memory DataGrid 맛보기 01 - 기본 설치 및 구성 가이드 ( HTTP 세션 관리 )
http://www.websphere.pe.kr/xe/new_lecture/36539
http://pic.dhe.ibm.com/infocenter/wxsinfo/v8r6/index.jsp?topic=%2Fcom.ibm.websphere.extremescale.doc%2Fwelcome%2Fwelcome_xs.html
WebSphere eXtreme Scale v8.6 Key Concepts and Usage Scenarios
http://www.redbooks.ibm.com/abstracts/sg247683.html?Open
WebSphere eXtreme Scale Best Practices for Operation and Management
http://www.redbooks.ibm.com/abstracts/sg247964.html?Open
댓글