블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

전준식 이사님의 Infinispan 강의 내용 요약 정리


In Memory Data Grid - Infinispan(JBoss Data Grid) Webinar from Opennaru on Vimeo.


[Cosistent hashing]

- Hash Ring 형태로 저장

- 서버가 늘어나고 줄어드는 것에 대해서 대응이 가능한 구조

1번은 0번부터

2번은 27번부터

3번은 50번부터의 해쉬 값을 저장함.


장애 대응

예를 들어, 2번이 죽으면 1번이 0~49번까지 보관함

복제는, 다른 서버에다가도 값을 복제 해놓음.


이 알고리즘을 이용하면, memcached 등을 이용해서도 고가용 서버를 만들 수 있음


Segment(Replica,Virtual node)

- Hash ring에 가상의 노드를 만들어서, 특정 서버에 값이 몰리는 현상을 방지함

Inifinispan은 32bit int를 key로 사용하는데 통계적으로 100~200개정도의 Virtual Node를 사용하면 데이타의 몰림 현상이 일반적으로 해결됨

즉 예를 들어서, 서버가 4대면, segment를 50으로 잡으면 노드가 200개 정도로 ㅓㄹ정됨.


451 group reseach

-NewSQL : RDBMS의 기능을 가지면서, 분산 확장 개념을 가지는 DB - VoltDB


[Data Grid 기본 개념]

- in memory storage

- networked memory

- ★ pacemakers to database

- provide simple KV storage

- Linear scalability and eslasticity. (distributed)


사용 용도

- DB Cache, Session Clustering

※ EAS6 (JBoss)의 경우, Infinispan을 default로 탑재되서 session clustering에 사용됨


[Infinispan]

- Apache 2.0 license / Java와 Scala 언어로 이용하여 구현됨 (핵심 부분은 Scala 구현체)

- 두가지 제품이 있음

  1) Library 모드 - 임베딩 가능한 형태. 상세한 API 지원 가능하며, 고성능 지원 가능. Java만 지원 (Comment : HazelCast와 비슷한 개념). 

  2) Client/Server 모드 - 독립 서버. 다양한 언어 지원이 가능함. 

     : memcached,Hot Rod (Infinispan native protocol), REST 프로토콜을 사용함

     : 고급 기능은 사용 불가. MR,JTA Tx등. 

  대부분의 경우 Library 모드를 사용함.

- Python,Java,.NET 등에서 사용 가능.

- 주요 특징

  1) JTA TX 지원

  2) CacheStore (Disk,DB) Persistence 지원

  3) DisributedExecutors 지원 (일종의 MAP을 분산노드에서 실행하는 개념과 유사)

  4) M 지원

  5) FTS (Lucene API) 지원

  6) GridFileSystem - 메모리상의 파일 시스템 제공 (메모리를 기반으로 파일시시틈을 지원하는)

  

- 분산 tolpology

1) Local Storage - Local Cache 용도로 사용. 노드간 복제 않함

 Write through, Write behind

 Eviction

 Expiration (Time)

 Transaction

2) Replication Cache  - 모든 node가 같은 값을 가짐

 서버 개수만큼 복제해야 하기 때문에, 성능 문제가 있을 수 있다. 10대 서버 이하일 경우에만 사용 권장

3) Distributed Cache - 데이타를 분산 저장함. 장애 대응을 위해서 백업본은 다른 노드에도 저장함. 현재 노드에 데이타가 없으면 다른 노드에서 긁어옴. (매번) 

 GET시에는 최대 1회의 remote 호출 (현재 서버에 값이 없으면)이 발생할 수 있음

4) L1 + Disribution - 매번 다른 서버의 데이타를 가지고 오는 것을 줄이기 위해서 L1 캐쉬를 잡아놓고, 다른 서버에서 오는 값을 L1에 저장함

5) Invalidation Cache - 각 노드가 같은 데이타를 저장. 단 데이타 삭제가 발생하면, 다른 노드에도 데이타 삭제를 요청함. 2)번과 비슷

 데이타베이스와 같은 영속적인 스토어가 있는 경우에만 사용(??)

--> Topology에 따라서 성능이 다름.


- Evition and Expiration

Policy - None,FIFO,LRU,Unordered(무작위),LIRS (Low Inter reference recency Set)

예) <eviction maxEntries=1000 strategy=LRU wakeUpInterval=500>

500ms 마다 eviction을 LRU 정책으로 하고, 1000개의 레코드만 유지하도록 한다.


cf. Eviction : 엔트리의 수가 넘었을때 삭제, Expiration : 일정 시간이 지나면 삭제

Expriation의 예 - Session Time out 등

예) <expiration wakeupinternal=500 lifespan=60000 maxIdle=10000>

생성된지, 60,000 ms 가 되거나

사용된지 10,000ms 되면 삭제

500ms 마다 expiration check 수행


- DataGrid Store

1) 캐쉬에서 넘쳐나는 것을 저장하거나

2) 리스타트 되었을 때 캐쉬를 다시 복구 하는 용도(Redis와 비슷하네)

 DB나 파일,클라우드 스토리지(S3,Swift등) Remote Store(다른 데이타 그리드), Cassandra등에 저장가능


CacheStore에는 writethrough(Sync), write behind(Async) 로 설정 가능


- 코드 예제

아래는 Client/Server mode (Hot Rod 프로토콜을 사요아는 경우)

RemoteCacheManager manager = new RemoteCacheManager("ip:port,ip:port,ip:port,....")

Cache <String,String> cache = manager.getCache("cachename")

cache.put (key,value)

cache.get (key)

cache.remove (key)


대부분의 DataGrid는 사용 방식이 거의 비슷함. 거의 다 put,get,remove


- 부가 기능

1. Data Grid Disributed Executor : 분산 실행 기능. 데이타가 저장되어 있는 인스턴스에서 실행하여 결과를 반환. 거의 디스크 access나 네트워크 액세스를 줄이고 실행

Callable의 call(),setEnvironment()를 implement

Callable을 구현한후, executor에 submit을 하면 됨.

Callable은 각 값이 저장된 Cache 노드에 분산되서 실행된후에, List 형태로 그 값을 반환함. 


2. MR 기능 제공

 Hadoop 의 분산 병령 처리와 동일


3. DataGrid Query

 Apache Lucene (FTS)를 이용. Index를 만들어놓고, Hibernate Search API를 이용하여 검색함

 Index를 어디에 저장할것인가가. 디자인 이슈 (분산캐쉬에 넣어도 되고, 디스크에 넣어도 되고, 다향한 configuration이 있음)


4. 기타 확장 API

org.infinispan.cache 는 java / ConcurrentMap을 상속

 putAsync,getAsync과 같은 추가 API를 지원함

 @Annotation을 지원 - Cache에 listener등을 걸거나 하는 것등이 가능함

 JTA를 지원하며, 명시적으로  lock을 걸 수 있음

 Batch Put을 지원

 Custom Interceptor 지원 - lock 걸렸을때, put할때, get 할때 등등

 Listener 지원(이벤트가 발생했을때, listener를 실행해줌)

 Queue 형태의 자료구조는 시스템적으로는 지원하지 않음 (Redis는 지원). -> K/V 형태로 해서 Linked List형태로 구현이 가능

※ interceptor와 listener 차이가 모지? 비슷해 보이는데.

근데. 내부적으로 JGroup을 사용하네.


- 성능 측정 (Radar Gun 프로젝트 - Infinispan의 프로젝트로 DataGrid들에 대한 성능 비교 프레임웍)

Coherence와 비교했을때, inifinispan이 더 빠르네??


- Azul Zing (JVM) - Stop the world 현상이 적음. -Xmx40g 사용 가능

http://www.azulsystems.com/products/zing/whatisit



[추가내용 - Infinispan vs Hazelcast]

Infinispan 
전체적으로 캐쉬의 개념이 강함
- K/V 형식으로 get/set 만 제공
- TTL 기능 있음.
- Local / Server 방식으로 클러스터 구성 가능함
- size(), values(), keySet(), entrSet()등 Full Scan 관련 API는 Concurrency 문제와, Performance 문제를 유발함
- JTA 기반 Tx 지원
- Index 개념 있음
- Query 기능
  * Search/Filtering 지원 - Hibernate Search framework과 Apache Lucene으로 구현됨 (Full Scan 이 아니라 Index와 Lucene을 사용하니 단순 full scan 방식은 아니여서 쓸만할듯)
  * Sorting 지원
  * Pagenation 지원
- Map & reduce 지원
- Locking ?
- Eviction - LRU,TTL, Custom LRU 지원
- Executor 개념 지원
  
HazelCast
- 데이타 타입 : Distributed java.util.{Queue, Set, List, Map}
- Queue/Topic 개념 지원 ★
- Locking
  * global lock 지원
- Eviction - LRU,LFU,TTL 지원
- Query는 지원하긴 하지만, 전체 노드에 분산 수행되기 때문에 효율적이지 않음 (Riak과 비슷하네.)
- Index 지원함. 
- Trasaction 지원
- Executor 개념 지원 
- WAN Replication 지원


저작자 표시
신고



Basic Feature Set

* Distributed Map

- Usage is same as java map.

- But it is distributed and clusterd by Hazelcast. (HA supported)

example

HazelcastInstance instance = Hazelcast.newHazelcastInstance(cfg);

        Map<Integer, String> mapCustomers = instance.getMap("customers");

        mapCustomers.put(1, "Joe");


* Distributed Set


* 1:1 Queue

-TBD


* 1:N Topic

-TBD


* Distributed Lock

-TBD


* Distributed Event

- it can add event listener to Map. so some certain Key or data comes in, event listener will be fired. 


* Distributed Executor server

- It is like Queue Consumer (Worker)


* Serialization 

- TBD


* Support persistence

- It can store the K/V to persistence store like file or RDBMS.

- It supportes Write-Behind (asyc) and Write-through (sync). Read Through (if get key is null, load it).

- It needs to check that during the persistence, I think HazelCast cluster will be stopped.



Advanced Feature Set

* Index

* SQL like query

* Transaction

* Entry Listener

* Eviction

* Control partitioning (from 3.1 )

- by using partition key

- map.put("Key@PartitionKey","Value");

the data will be stored in Partition that correspond to the partition key

* Map & reduce

* External add on 

- hazlemr/castmapr - MR framework form Hazelcast 2.x,3.x

- hazelblast - remote invocation


Cluster

* Super Client

- -Dhazelcast.super.client=true

- As fast as any member in the cluster. but hold no-data


Some numbers in Hazelcast

- Default partition amount 271

- Biggest cluster 100+ member

- Handles 100,000 message/sec by using Topic


Reference : 

http://www.slideshare.net/jaxLondonConference/clustering-your-application-with-hazelcast-talip-ozturk-hazelcast?from_search=1

http://www.slideshare.net/uzquiano/hazelcast-and-mongodb-at-cloud-cms

http://www.slideshare.net/ChristophEngelbert/hazelcast-inmemory-datagrid

저작자 표시
신고

EmbeddedServer 애플리케이션

애플리케이션이 로딩될때, HazelCast를 같은 JVM에서 수행 시킴

1. HazelCast를 다운로드 받은 후, 압축을 푼다. (www.hazelcast.org)

2. 서버 애플리케이션 코드 작성

package terry.hazelcast;

 

import com.hazelcast.core.*;

import com.hazelcast.config.*;

import java.util.Map;

import java.util.Queue;

 

public class GettingStarted {

 

    public static void main(String[] args) {

        Config cfg = new Config();

        HazelcastInstance instance = Hazelcast.newHazelcastInstance(cfg);

        Map<Integer, String> mapCustomers = instance.getMap("customers");

        mapCustomers.put(1, "Joe");

        mapCustomers.put(2, "Ali");

        mapCustomers.put(3, "Avi");

 

        System.out.println("Customer with key 1: "+ mapCustomers.get(1));

        System.out.println("Map Size:" + mapCustomers.size());

 

        Queue<String> queueCustomers = instance.getQueue("customers");

        queueCustomers.offer("Tom");

        queueCustomers.offer("Mary");

        queueCustomers.offer("Jane");

        System.out.println("First customer: " + queueCustomers.poll());

        System.out.println("Second customer: "+ queueCustomers.peek());

        System.out.println("Queue size: " + queueCustomers.size());

    }

}

3. 서버 실행 

% java terry.hazelcast.GettingStarted


2월 11, 2014 12:33:22 오전 com.hazelcast.cluster.MulticastJoiner

INFO: [192.168.219.154]:5701 [dev] 



Members [1] {

Member [192.168.219.154]:5701 this

}


2월 11, 2014 12:33:22 오전 com.hazelcast.core.LifecycleService

INFO: [192.168.219.154]:5701 [dev] Address[192.168.219.154]:5701 is STARTED

2월 11, 2014 12:33:22 오전 com.hazelcast.partition.PartitionService

INFO: [192.168.219.154]:5701 [dev] Initializing cluster partition table first arrangement...

Customer with key 1: Joe

Map Size:3

First customer: Tom

Second customer: Mary

Queue size: 2

※ 만약에 같은 애플리케이션을 한번 더 수행 시키면, 새로운 HazelCast 인스턴스가 뜨면서 Cluster에 Join 되는 것을 확인할 수 있다.


Client/Server 형 애플리케이션

1. Client 코드 작성

package terry.hazelcast;

 

import com.hazelcast.client.config.ClientConfig;

import com.hazelcast.client.HazelcastClient;

import com.hazelcast.core.HazelcastInstance;

import com.hazelcast.core.IMap;

 

public class GettingStartedClient {

 

    public static void main(String[] args) {

        ClientConfig clientConfig = new ClientConfig();

        clientConfig.addAddress("127.0.0.1:5701");

        HazelcastInstance client = HazelcastClient.newHazelcastClient(clientConfig);

        IMap map = client.getMap("customers");

        System.out.println("Map Size:" + map.size());

    }

}

 2. 서버 실행

% {hazelcast_home}/bin/server.bat를 실행



3. 클라이언트 코드를 실행

% java terry.hazelcast.GettingStartedClient

2월 11, 2014 12:35:46 오전 com.hazelcast.core.LifecycleService

INFO: HazelcastClient[hz.client_0_dev] is STARTING

2월 11, 2014 12:35:47 오전 com.hazelcast.core.LifecycleService

INFO: HazelcastClient[hz.client_0_dev] is STARTED

2월 11, 2014 12:35:47 오전 com.hazelcast.client.spi.ClientClusterService

INFO: 


Members [1] {

Member [192.168.219.154]:5701

}


Map Size:0


참고. 위의 예제에 사용된 pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>

 

  <groupId>terry</groupId>

  <artifactId>hazelcast</artifactId>

  <version>0.0.1-SNAPSHOT</version>

  <packaging>jar</packaging>

 

  <name>hazelcast</name>

  <url>http://maven.apache.org</url>

 

  <properties>

    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

  </properties>

 

  <dependencies>

    <dependency>

            <groupId>com.hazelcast</groupId>

            <artifactId>hazelcast-all</artifactId>

            <version>3.1.3</version>

        </dependency>

    <dependency>

      <groupId>junit</groupId>

      <artifactId>junit</artifactId>

      <version>3.8.1</version>

      <scope>test</scope>

    </dependency>

  </dependencies>

</project>

 

노트

코드를 보면 알겠지만, 사용 방법이 다른 IMDG에 비해서 매우 쉽다. Learning Curve가 매우 낮다.

WSO2,Mule,Vert.x,Camel,Atlassian (이것도 레퍼런스 올라왔던데, 예전에는 Coherence를 사용했는데, 아마 Oracle 인수후, 이쪽으로 온듯) 등 여러 솔루션에 사용되고 있으며, 자체 Clustering 기능이 구현이 아주 쉽기 때문에, 다른 솔루션에 클러스터 구성용으로 많이 사용된다. 그외에서 message queue 기능, HTTP Session replication, Hibernate level2 캐쉬, Spring과 integration이 쉽기 때문에 사용성 면에서는 매우 높은 점수를 줄 수 있으나, 아직까지 Infinispan과의 성능 비교 글들을 보면, 열세인데, 이부분은 조금 더 리서치가 필요할듯


  • 내용 원본 : http://www.hazelcast.org/getting-started/
  • 테스트 소스 코드 https://github.com/bwcho75/hazelcast (향후 다른 코드 추가 예정)


저작자 표시
신고
http://wiki.tangosol.com/display/COH35UG/Coherence+3.5+Home


저작자 표시
신고

 

오라클 Coherence 가 그려내는

차세대 Java Enterprise Architecture

 

한국 오라클 컨설팅
Principal Consultant
조 병욱 (byungwook.cho골뱅이oracle.com)

 

서문 

2008년과 2009년의 SI 프로젝트 상황을 보면 의외로 사실상 실패하는 프로젝트의 비중이 늘어나고 프로젝트상에서 기술적인 문제가 발생하는 빈도가 늘어나고 있다. 특히 I사가 주 사업자로 참여한 프로젝트의 경우 오픈시에 항상 기술적인 문제점이 발생하고 있다. 이미 KOO 와 동XXX 와 프로젝트를 진행한 OO사 등이 그 사례라고 볼 수 있다. 진행사의 SI 능력에서 문제의 원인을 찾을 수 도 있지만, 근래에 진행되는 많은 프로젝트들이 유사한 문제점을 가지고 있는 것을 봤을때는 단순하게 수행사의 문제라고만 하기에는 어렵다

근래에 들어서 대부분의 SI 프로젝트의 경향을 보면 Spring,IBatis,Struts등과 같은 프레임웍을 사용하여 시스템을 개발하는 사례가 많다. 프레임웍은 생산성을 높여주고 시스템의 구조를 향상 시키는 역할을 하지만 반대로, 시스템의 구현 STACK이 깊어져서 시스템의 복잡도를 높이게 되고 이로 인해서 많은 기술적인 이슈를 야기 하게 된다

본 문서에서는 이 두가지 문제점을 자사의 Coherence Oracle Service Bus를 이용하여 해결할 수 있는 방법에 대해서 소개한다

기존 아키텍쳐의 문제점

J2EE가 소개된 이례 현재까지 가장 널리 사용되는 전통적인 아키텍쳐는 다음과 같다.


하나의 WAS 내에 UI와 비즈니스 로직을 같이 구현한다. 회사의 전체 업무가 크게 3개의 업무로 나뉘어진다고 해도, 3개의 업무가 모두 하나의 애플리케이션에 포함되어 배포되고 운영되어 왔다

메모리 사용량의 증가

이런 아키텍쳐가 가지고 있는 문제점은 무엇일까?
IT
비즈니스에 대한 요구 사항은 점점 더 증가 되어가고 있고 이는 더 많은 업무 로직과 기능을 요구하게 된다. 즉 업무 로직 자체가 커지게 되는데, 반대로 이를 지탱하고 있는 자바 언어 자체는 메모리의 한계를 벗어나지 못하고 있다. 통상적으로 32BIT JAVA에서 JAVA가 사용할 수 있는 메모리량은 최대 1.5G 내외가 된다. 물론 64Bit JVM을 사용해서 사용 가능한 메모리양을 확장할 수 는 있지만, JAVA가 가지고 있는 한계[i] 로 인하여 비대해지는 애플리케이션에 대한 문제가 많이 발생하고 있다.

실예로 모 화재 보험사 차세대 시스템의 경우에도 모든 업무가 하나의 애플리케이션에 함께 패키징되는 형태로 개발 및 배포 되어 많은 메모리 사용량을 요구하게 되었고 이로 인한 이슈가 있었다.

 또한 현재의 기술 흐름이 XML이나 OR Mapping과 같이 개발의 편의성과 우수한 구조를 제공하는 기술들이 소개되고 사용되지만 이것 역시 전통적인 애플리케이션에 의해서 메모리 사용량이 많이 늘어나게 된다

업무간의 장애 전파

기존 아키텍쳐의 다른 문제점중의 하나가 모든 업무가 똑같이 WAS인스턴스에 모두 같이 배포되기 때문에 장애가 발생하였을 때 그 장애가 다른 업무에도 영향을 준다는 것이다.[ii]

예를 들어 업무 C가 문제가 생겼을 때 같은 인스턴스에서 수행되고 있는 업무 A B에도 영향을 준다. 웹로직의 WorkManager등의 기능을 이용하여 장애를 최소화할 수 는 있지만 메모리 과사용이나 CPU 과점유등과 같은 Critical한 장애의 경우를 방지할 수 있는 방법이 없다

기존 아키텍쳐에 대한 개선 방안

그렇다면 기존 아키텍쳐에 대한 문제를 해결하기 위해서는 어떤 접근 방법이 필요할까?

해결 방안

해결 방안은 의외로 간단하다. 업무별로 WAS 인스턴스를 분리해서 배치하는 것이다.


 이런 아키텍쳐를 취할 경우 앞에서 제시된 두가지 문제점을 해결할 수 있다.

효율적인 메모리 사용

WAS 인스턴스별로 하나의 업무만 배포되기 때문에, 결과적으로 인스턴스당 요구되는 메모리 사용량이 적어진다.

장애 전파 방지

인스턴스가 물리적으로 완벽하게 분리되기 때문에, 특정 업무에서 장애가 발생하더라도 다른 업무에 전혀 영향을 주지 않는다.

 여기에 더해서 몇가지 장점을 더 얻을 수 가 있는데,

유연한 시스템 자원의 배분

업무 처리량에 따라서 유연하게 WAS 인스턴스 수를 조정할 수 있다. 업무 A의 처리량이 많을 경우에는 업무 A에 대한 WAS 인스턴스를 추가로 배정할 수 있고, 가상화를 지원하는 하드웨어의 경우에는 CPU를 업무 처리량이 많은 인스턴스에 배정하여 자원 사용의 효율성을 높일 수 있으며 업무에 대한 인스턴스가 명확하게 지정되어 있기 때문에 운영환경에서도 과부하시 자원(CPU)를 어느 프로세스에 적용해야 하는지가 명확해져서 시스템 운영의 효율성과 유연성을 확보할 수 있다

왜 개선 아키텍쳐를 사용하지 않는가?

그렇다면 이렇게 해결책이 명확한 아키텍쳐가 있음에도 불구하고 전통적인 엔터프라이즈 자바 애플리케이션에서 이런 아키텍쳐를 사용하지 않았을까? 문제는 이 아키텍쳐가 기술적인 한계성을 가지고 있다는 것이다.


애플리케이션은 업무 처리를 위해서 사용자에 대한 상태 정보등 (로그인 정보, 권한등)을 유지하게 되는데, 흔히 Http Session이라는 메모리 상에 이 정보를 저장한다. Session 정보는 클러스터간에는 서로 공유가 가능하지만 다른 클러스터 간에는 공유가 불가능 하다.

즉 업무 A를 위해 구성된 클러스터에서는 업무 B를 위해서 구성된 클러스터내의 사용자 상태 정보를 서로 공유할 수 없다는 것이다.

 완벽하게 분리되서 동작하기 때문에, 상태 정보역시 분리되어 버리는 결과를 낳게된다

Coherence를 이용한 아키텍쳐의 확장

이 아키텍쳐상의 한계를 Oracle Data Grid 솔루션인 Coherence로 해결할 수 있다.

Coherence Data Grid에 사용자 상태 정보를 정보와 업무간에 공유해야 하는 공유 데이터를 저장함으로써, 클러스터 구성 방식과 상관없이 업무 로직에서 사용자 상태 정보를 공유할 수 있게 됨으로써 구현하고자 하는 아키텍쳐를 실제로 구현할 수 있게 되었다.


 또한 Coherence를 이용한 Data Grid를 구축함으로써 기존에 사용자 상태 정보에 저장할 수 있는 데이터의 크기가 작았던 단점을 극복하고 좀더 큰양의 사용자 상태 정보를 유지할 수 있게 되었다[iii]

이 아키텍쳐에서는 업무로직을 가지고 있는 WAS Instance가 분리될 수 있어서 장애 전파성이 없어지고 확장이 무한적으로 가능할 수 있게 되며 업무에 따라서 WAS Instance 수나 CPU를 조정할 수 있기 때문에 유연한 자원 운용이 가능하다.


[i] Garbage Collection Time – 다 사용한 메모리를 반납하는 과정인데 이때 시스템이 일시적으로 정지하는 현상이 발생하는데,  이 정지 시간은 메모리의 크기에 비례한다

[ii] 클러스터링을 구성했다하더라도 업무 로직에 문제가 있는 경우에는 같은 업무 요청이 들어오게 되면 클러스터된 다른 인스턴스에서 같은 로직을 수행하기 때문에, 클러스터 여부에 관계없이 전체 시스템으로 장애가 전파 된다.

[iii] 실제 모 관공서 시스템의 경우 사용자 상태 정보에 많은 데이터를 유지했는데, 자바의 메모리 크기의 한계로 인하여 부하가 많을 경우에는 메모리 부족으로 인하여 장애를 유발하였다. 이런 문제를 해결하기 위해서는 기존의 아키텍쳐의 경우 하드웨어를 증설하여 더 많은 WAS 인스턴스를 운영하여 부하를 분산함으로써 WAS 인스턴스당 사용되는 사용자 정보 유지용 메모리 사용을 분산해야 하는데, Coherence를 도입할 경우에는 더 많은 메모리가 요구 될 경우 Coherence 용 서버만 확장하면 되기 때문에 시스템 증설시에 그 효율성이 매우 높아진다.

 

저작자 표시
신고
ALM 이후로 가지고 놀 수 있는 장남감을 찾던중에 발견한 장난감.
요즘 Vitualization과 cloud computing 이야기가 많은데.
Cloud computing중에서 data grid에 해당 하는 부분
자바 애플리케이션을 개발하면 문제중에 하나가 JVM Instance끼리 데이타 공유가 불가능하다는 것이다. 이런 경우는 DB나 FILE을 이용하는데 성능상의 문제도 많고 DB로 공유하기에는 어려운 데이타들이 있는 것이 사실인데.
이런것을 커버해주는 것이 NAM (Network Attached Memory)라는 개념이다.
애플리케이션 입장에서는 일반적인 메모리를 ACCESS하는 것처럼 사용하지만, NAM 서버들이 서로 클러스터링 되어서 대용량의 데이타를 애플리케이션 입장에서 하나처럼 보여주는 것이다.

예를 들어 애플리케이션에서 HashMap을 이용하여 데이타를 Put/get을 했을때 이 Hash map이 모든 Instance간에 공유가 되고 있고, 메모리 용량이 필요할때 마다 수평적으로 NAM 서버만 증가하면 된다. 또한 NAM 서버간에는 서로 데이타가 클러스터링에 의해서 복제되고 있기 때문에 서버 장애로 인한 유실 염려도 매우 낮다.

이 NAM 관련 제품으로는 여러가지가 있는데
* Coherence
상용제품으로는 오라클이 인수한 제품중에서 마음에드는 Coherence라는 제품이 있다. Tangosol이라는 회사를 작년에 인수 한것인데, Jive Soft나 Atlassian JIRA나 Confluence와 같은 패키지에도 이미 널리 쓰이고 있는 제품.

사용법도 정말 쉽다.. -_-
서버 띄우는 것은 java -jar coherence.jar 하면 뜬다. 인스턴스 더 띄우고 싶으면 또 그냥 띄우면 된다.
물론 구체적인 설정을 하자면 configuration이 필요하지만 기본 테스트정도는 충분한듯..

단순하게 캐쉬나 메모리 쉐어링만 되는 것이 아니고 별별짓들을 다 지원하는데.
예를 들어서 Coherence 내부의 메모리를 JMS 처럼 사용할 수 있는 Coherence의 설정을 JMS extension을 이용해서 한후 Weblogic 서버와 같은 WAS에 JMS로 등록해주면 개발자는 WebLogic의 JMS를 사용하는것과 같이 똑같이 사용할 수 있지만, 내부적으로는 Memory base의 대용량 JMS Q를 확보하게 되는것이다.
JMS 사용할때, 항상 메모리 Q의 경우 메모리 크기 한계가 있었고, Persistence 사용시에는 성능 문제가 있었는데 한번에 날려주는 깔끔함.. 

OR Mapper의(하이버네이트)등의 캐쉬로도 쉽게 맵핑이 되기 때문에 정말 편리하다.

대용량 데이타를 DB에 적재할 필요없이 메모리로 유지하면 되니까는 이 또한 성능에 얼마만큼이나 영향을 줄지 생각만해도 즐겁다.

그외에도 WAS의 세션 복제에도 사용이 될 수 있다. Message exchange pattern (Pub&Sub)등에도 사용할 수 있는 패턴들을 제공하고 있다. 단순히 Hashtable 프로그래밍 하듯이 하면 되기 때문에 매우매우 사용이 편하고...

* Terracotta
http://www.terracotta.org
오픈소스로는 테라코타라는 제품이 있는데. 이놈은 약간 골때린다.
예를 들어 static 으로 지정한 변수가 있다면 이 변수를 cluster를 통해 공유할 수 있다.
config 파일에서 어늘 클래스의 어느 변수를 공유하겠다고 정의만 하면 공유가 가능하다는 것이다. 프로그램에 영향을 주지 않고 공유가 가능하다는 점은 높이 살만하지만
기본적으로 instrumentation을 이용한 기법이기 때문에, 애플리케이션 실행시
% java main 
이 아니라
% dso-java main
식으로 jvm을 wrapping한 terracotta용 jvm을 사용해야 하기 때문에 장애에 대해서 얼마나 튼튼한지는 모르겠다.
다행히도 주요 WAS에 대해서는 certi를 하는 것 같고, enterprise 사용시 상용으로 support를 살 수 있기도 한것 같아서 마음이 약간 놓이기도 하지만 글쎄?? 써봐야 하지 않을까???

hadoop을 찝쩍 거리다가 어찌하다가 이쪽을 보게 되었는데 흥미 진진한 분야 인것 같다.
시간이 나면 테스트와 아키텍쳐 잡아보고 포스팅 하겠습니다.!!!

신고