안녕하세요 이정운 입니다.
지난번 강좌에 JDBC 를 활용하여 DataGrid 를 동기적으로 사용하는 작업을 수행했었습니다.
이번에는 DataGrid 의 강점을 충분히 보여줄 수 있는 비동기적 방식인 Write-Behind 방식으로 변경하여 테스트 해보도록 하겠습니다.
많은 참조 부탁드리며 하단의 강좌를 시작하도록 하겠습니다.
WebSphere eXtreme Scale v8.6
DataGrid 를 활용한 In-Line 캐시 - Write-Behind 방식
0) DataGrid 를 활용한 In-Line 캐시 – Write-Behind 방식 ?
지
난 강좌에서는 JDBC 를 사용할 수 있는 Custom Loader 를 간단하게 만들어보고 이를 활용하여 In-Memory
DataGrid 의 In-Line 캐시를 활용하는 방안에 대해서 강좌를 진행하였습니다. 지난 강좌에서는 가장 기본적으로 Grid 에
반영된 것이 바로 DB 에 동기화 반영되도록 하는 Write-Through 방식의 구조로 작업을 해서 데모를 보여드렸습니다.
즉, Grid 에 insert, update, delete 를 하게되면 JDBCLoader 를 통해서 바로 DB 에서도 동일하게
insert, update, delete 를 수행하게 되는 방식이였습니다.
그런데 아키텍처 적으로 좀 더 생각을
해보면 굉장히 critical 한 데이터가 아니라면 또는 굉장히 critical 하더라도 Grid 영역이 제대로 된 고가용성을
제공한다면 매번 트랜잭션마다 Grid 에 저장하고 이를 다시 DB 에 동기화 하는 작업은 캐시를 사용하기는 하지만 insert,
update, delete 가 많은 업무에는 트랜잭션 부하가 오히려 두 배 증가하는 안 좋은 영향을 가지고 올 수도 있습니다.
이를 획기적으로 개선시킬 수 있는 방안이 지난 강좌에서 잠깐 언급한 Write-Behind 방식입니다. Write-Behind
방식은 CRUD 작업에서 DB 와의 동기화를 매번 바로 진행하는 것이 아니라 시간이나 건수를 가지고 비동기적으로 수행할 수
있습니다. 다시말하면 client 와 grid 간에 트랜잭션으로 insert 가 100 건이 발생해도 실제 DB 동기화 작업은
진행되지 않고 유지하다가 100 건이 넘었을 경우 해당 결과를 한번 DB 와의 동기화를 수행하는 것입니다. 당연히 이렇게 되면
매번 발생되는 DB 의 트랜잭션의 부하를 완벽히 경감시킬 수 있습니다.
이와 같은 구조적인 장점 때문에 Write-Behind 방식은 다양한 분야에서 성능 관점으로 활용이 가능하며 대표적으로 업무
logging 성 DB 트랜잭션이나 배치작업을 위한 임시 DB 트랜잭션, 대량 DB 트랜잭션 업무들을 대체해서 보다 높은 성능을
제공할 수 있습니다.
그럼 이전 JDBCLoader 강좌에서 사용한 구조를 활용하여 어떻게 Write-Behind 방식으로 변경하고 어떤 장점을 가질 수 있는지 살펴보도록 하겠습니다.
1) IBM WebSphere eXtreme Scale(WXS) 설치 및 기본 구성
설치 및 구성의 경우는 당연히 지난 강좌의 구성 형태와 동일하게 WXS 가 Client(WAS)와 Server 로 구분되어 설치 되어있다고 가정을 하고 진행하도록 하겠습니다.
2) 테스트를 위한 DB Table, JDBC 애플리케이션 작성
이전 강좌에서 사용한 Oracle DB 를 그대로 활용해서 진행하도록 하겠습니다.
(지난 강좌 “[WXS]WXS 를 활용한 In-Memory DataGrid 맛보기 04 - DataGrid 를 활용한 In-Line 캐시 (JDBC)” http://www.websphere.pe.kr/xe/new_lecture/38761 참고 )
3) DataGrid 를 활용한 In-Line 캐시를 위한 JDBC 애플리케이션 변경
이전 강좌에서 사용한 애플리케이션을 그대로 사용하도록 하겠습니다.
4) DataGrid 를 활용한 Write-Behind 방식을 위한 WXS Server 설정
이전까지는 지난 강좌에서 사용한 DB 라던지 애플리케이션을 변경없이 그대로 사용이 가능하며 결국 WXS Server 를
구동하기 위한 설정만 Write-behind 용으로 변경하면 동일한 애플리케이션/DB 를 활용하여 Write-behind 구성이
가능합니다 .
① IBM WXS 의 카탈로그 서버와 컨테이너 서버의 구성을 결정하는 설정 정보 파일 준비
중요 부분 JDBCBehindObjectGrid.xml
<objectGrids>
<objectGrid name="PersonGrid" txTimeout="60">
<bean id="TransactionCallback" className="com.ibm.juwlee.wxs.JDBCTxCallback">
</bean>
<backingMap name="Person" lockStrategy="PESSIMISTIC" pluginCollectionRef="Person" writeBehind="T300;C5"/>
</objectGrid>
</objectGrids>
<backingMapPluginCollections>
<backingMapPluginCollection id="Person" >
<bean id="Loader" className="com.ibm.juwlee.wxs.JDBCLoader">
</bean>
</backingMapPluginCollection>
</backingMapPluginCollections>
ObjectGrid
설정 파일을 보시면 JDBCLoader 를 사용했던 경우와 거의 동일하며 다만 writeBehind 설정을 위한 설정
정보(“T300;C5”) 만 추가를 해주면 됩니다. 지금 수행한 설정 정보를 간단하게 설명드리면 이전 강좌에서 사용한
Write-Through 방식과 다르게 매번 DB 와 동기화 작업을 수행하는 것이 아니라 시간기준으로 300 초,
개수(count) 기준으로 5개가 되면 몰아서 그때 한번에 동기화를 해주라는 설정입니다.
중요 부분 JDBCObjectGridDeployment.xml
<objectgridDeployment objectgridName="PersonGrid">
<mapSet name="PersonMapSet" numberOfPartitions="5"
minSyncReplicas="0" maxSyncReplicas="1" developmentMode="true">
<map ref="Person"/>
</mapSet>
</objectgridDeployment>
ObjectGridDeployment 설정 파일은 이전 강좌와 동일하므로 설명은 생략하겠습니다.
② IBM WXS 의 카탈로그 서버와 컨테이너 서버의 구동을 위한 script 준비
대부분의 설정은 지난번에 설명드린 내용과 비슷합니다. 간단한 테스트를 위해서 제가 테스트시에 간단하게 만들었던 시작 스크립트를 첨부드리오니 참고하시기 바라겠습니다.
카탈로그 서버
startXsServer cat1 -listenerPort 4809 -JMXServicePort 4899 -catalogServiceEndPoints cat1:kr050578:6600:6601
컨테이너 서버
startXsServer
c1 -listenerPort 5001 -haManagerPort 5002 -objectGridFile
D:\00.biz_work\01.SWG\11.WXS\WXS86_guide\JDBCBehindObjectGrid.xml
-deploymentPolicyFile
D:\00.biz_work\01.SWG\11.WXS\WXS86_guide\JDBCBehindObjectGridDeployment.xml
-catalogServiceEndPoints kr050578:4809 -jvmArgs
-javaagent:C:\IBM\WebSphere85\eXtremeScale\ObjectGrid\lib\wxssizeagent.jar
-cp
D:\00.biz_work\01.SWG\11.WXS\WXS86_guide\JDBCCustomLoader.jar;D:\00.biz_work\01.SWG\11.WXS\WXS86_guide\lib\ojdbc6.jar;D:\00.biz_work\01.SWG\11.WXS\WXS86_guide\lib\commons-dbcp2-2.0.1.jar;D:\00.biz_work\01.SWG\11.WXS\WXS86_guide\lib\commons-pool2-2.3.jar;D:\00.biz_work\01.SWG\11.WXS\WXS86_guide\lib\commons-logging-1.2.jar
컨테이너 서버 구동도 이전 강좌와 동일합니다. 이를 이용해서 WXS 의 카탈로그 서버와 컨테이너 서버를 구동하면 하단과 같은 결과를 확인할 수 잇습니다.
xscmd -c showMapSizes -cep kr050578:4809
이전 강좌와 다르게 자동으로 Queue 파티션과 Failed_Update 파티션이 추가된 것을 확인할 수 있습니다. 해당 파티션은 Select 를 제외하고 Insert, Update, Delete 와 같은 작업을 비동기적으로 수행하기 위해서 중간 Queue 역할을 수행하는 파티션입니다.
5) DataGrid 를 활용한 Write-Behind 방식 테스트
우선 현재 시점의 DB 테이블의 내용을 확인해봅니다. 하단과 같이 6개의 컬럼이 들어가 있는 환경을 가정해보고 진행하도록 하겠습니다.
애플리케이션을 WAS 에 모두 배포한 후에 해당 애플리케이션에서 WXS 의 Grid 를 조회하는 호출을 수행해보면 하단과 같이 정상으로 결과가 나오는 것을 확인할 수 있습니다.
( http://localhost:9080/search/ActionJDBCwithGrid )
조회를 한 후에 WXS 의 컨테이너 서버를 확인해 보면 이전 강좌와 동일하게 Person 파티션에 조회한 데이터가 캐시된 것을 확인할 수 있습니다.
그럼, 다음으로 애플리케이션에서 조회가 아닌 Insert 작업을 수행해봅니다. 해당 작업을 수행해보면 이전과 다른 것은 DB 에서 Select 를 해봤을 때 Insert 된 항목이 보이지 않는 것을 알수 있습니다.
그러나 WXS 의 그리드를 확인해보면 하단과 같이 Insert 한 항목이 Person 파티션과 Queue 파티션에 추가된 것을 확인할 수 있습니다. 
실제적으로 Grid 안의 데이터를 조회해도 추가한 10 번 항목을 확인할 수 있습니다.
xscmd -c findByKey -g PersonGrid -m Person -fs ".*" -rv -cep kr050578:4809
다음으로 새로 Insert 한 10 번 항목을 조회해보면 바로 Grid 에서 캐시된 객체를 가지고 오므로 빠르게 가지고 오는 것을 확인할 수 있습니다.
당연히 비동기 방식이라 DB 에서 다시한번 select 로 조회해 보면 여전히 10 번 항목은 DB 에 적용되지 않았다는 것을 확인하실 수 있습니다.
시간이 좀 흐른 후에(약 300초 경과 후에) DB 에서 조회해 보면 하단과 같이 이전에 Insert 를 수행한 10번 항목을 확인가능합니다.
뿐만 아니라 WXS 의 Grid 의 Queue 파티션의 항목이 비워진 것을 같이 확인 가능하십니다.
즉, Write-Behind 방식의 Loader 가 구동되어서 Insert 가 수행되어도 바로 Grid 에서 DB 로 동기화
하는 것이 아니라 미리 지정된 시간동안 기다린 후에 해당 항목이 Insert 되는 것을 확인할 수 있습니다.
이번에는 추가 테스트를 위해서 11번 항목을 Insert 수행한 후에 Update 수행을 같이 하도록 하겠습니다. 하단과 같이 애플리케이션에서 11번 항목을 Insert 수행합니다.
Insert 를 수행하고 WXS 의 Grid 를 조회해보면 이전과 동일하게 Queue 파티션에 맵 항목이 하나더 추가된 것을 확인할 수 있습니다.
Insert 가 Grid 에 수행된 것을 확인한 후에 11 번을 조회해서 하단과 같이 Update 를 수행합니다.
WXS 의 Grid 를 조회해보면 이전과 변화가 있는 부분이 확인되지 않습니다. (내부적으로 Queue 에 있는 내용이 업데이트 되는 것임)
마찬가지로 실제 데이터를 조회해도 변화가 눈으로 보여지지는 않습니다.
일정 시간이후에 DB 를 직접 확인해보면 하단과 같이 11번 항목이 Insert 되었을 뿐만 아니라 Update 까지 한꺼번에 수행된 결과를 확인할 수 있습니다. 즉, Write-Behind 방식을 사용하여 Grid 에서 계속적인 트랜잭션이 일어나더래도 결국 DB 에서는 그 결과만 한번 트랜잭션이 발생되는 것을 확인할 수 있습니다.
여기까지 잘 따라오셨다면 처음에 언급한 대로 Write-Behind 방식의 WXS Grid 사용을 잘 따라오신 것이며
Write-Through 방식과 어떠한 차이점이 있는지 데모를 통해서 실제 보실 수 있었을 것으로 판단됩니다. 그럼 이번 강좌를
여기서 이만…^^&
9) 참고 자료
IBM WebSphere eXtreme Scale Version 8.6 Information Center
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
Integrating WebSphere eXtreme Scale transactions with other transactions
http://www.ibm.com/developerworks/websphere/techjournal/1205_jolin/1205_jolin.html
GitHub - bnewport/Samples
https://github.com/bnewport/Samples
IBM Extreme Transaction Processing (XTP) Patterns: Leveraging WebSphere Extreme Scale as an in-line database buffer
http://www.ibm.com/developerworks/websphere/library/techarticles/0906_vuong/0906_vuong.html
댓글