블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-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 지원



Oracle Coherence나 Open source memcached와 같은 메모리 그리드 솔루션은 아키텍쳐를 그리는 데 상당한 효과를 발휘한다. 메모리 그리드랑, 간단하게 이야기 하면 Java의 HashTable이 무제한 용량으로 확대 가능하고, 어느 server instance에서도 접근이 가능하며, 장애시 Fail over를 통해서 고가용 서비스가 가능한 솔루션을 이야기 한다.
물론 Oracle Coherence가 .NET도 지원하기는 하는데, 이왕이면 MS도 이런게 있었으면 했는데, 새 윈도우즈 Server에 나왔다.
AppFabric이라는 일종의 윈도우즈 미들웨어인데, 일단  데이타 그리드의 성격을 가지고 무제한 클러스터링이 가능하다.. (물론 열어봐야 알겠지만..)

데이타 그리드로써도 의미가 있지만, ASP.NET은 기본적으로 Http Session Clustering을 지원하지 않았기 때문에, 이 Data Grid를 이용하면 WebLogic이나 WebSphere와 같은 Session Clustering을 지원할 수 있다. (그것들 보다 지능적이게 만들려면 개발은 좀 들어가겠지만...)

아울러 AppFabric은 ESB Feature를 제공하는데, WCF (Windows Communication Foundation - 일종의 통신 Framework)과 WF (Workflow Foundation - 워크 플로우)를 통해서 비지니스 프로세스를 그리고 배포할 수 있다.  WF와 WCF 기반의 코딩이 들어가야 하는 미들웨어성에 가까운데, 대신 코딩을 하는 만큼 오히려 성능이나 아키텍쳐 구성에는 유리한면이 있을듯 하다.
Oracle Service Bus가 높은 가격과 고수준의 XQuery/XSL 기술이 있어야 한다면, 상대적으로 좀더 Flexible하게 고성능 ESB를 디자인할 수 있을듯.
기본적으로 IIS는 Java의 WAS처럼 Thread Base 모델이 아니라 Process Base 모델이기 때문에, Hot Deploy나, 장애 전파 영향도는 낮을 듯 하다.

AppFabric이 나오면서 기존의 ESB 역할을 해주던, BizTalk의 Postion이 애매해지는데, David Chappel의 AppFabric WhitePaper를 보면

As the figure shows, an activity in the workflow service can issue a request to BizTalk Server. This might be done using a Web service or in some other way; BizTalk Server provides adapters for several different communication styles. However it’s accomplished, the request can then be handled by business logic running in BizTalk Server. This logic is implemented as an orchestration, and it knows how to carry out the next step in this process. Here, for instance, the orchestration uses another BizTalk adapter to communicate directly with the ERP application. Any response can be sent back through the same components.

출처 : http://download.microsoft.com/download/7/F/8/7F8BD8A0-EB05-4DB5-A5A4-DD1D3C909A0A/Introducing_Windows_Server_AppFabric.pdf


AppFabric이 전통적인 ESB 역할을 하면서 Service Orchestration등을, BizTalk는 EAI 또는 SOA에서 Service Enablement Layer처럼, Legacy 시스템들을 Itnegration해서 Expose하는 역할로 포지셔닝이 된다. (참고 : http://wm.microsoft.com/ms/msdn/windowsserver/WFDemoFinalHighRes.wmv )


일단 1 core에 몇천만원이나 하는 Service Bus보다, MS의 AppFabric은 단돈 몇백만원에 OS에 포함되어 있고, 개발 용이성도 높으니, REST와 함께해서 아키텍쳐를 한번 조합해봤으면 좋겠는데..

혹시.. 사이트에 좀 불러주실분...??? 손!! :)

http://wiki.tangosol.com/display/COH35UG/Coherence+3.5+Home


OO 차세대 시스템

WAS Architecture Blue Print (DRAFT)  

2009-06-28

Oracle Korea Consulting

Principal Consultant

Byungwook Cho (byungwook.cho@oracle.com)

 

 

Overview

본 아키텍쳐는 OO 차세대 시스템을 위한 웹로직 구성 아키텍쳐이다. OO 아키텍쳐 요구 사항에 따라서 구성한 아키텍쳐로 다음과 같은 전제 조건을 기반으로 한다. Ÿ          웹로직을 중심으로 설계할것           클라이언트는 웹이 아닌 윈도우 애플리케이션을 사용한다.

    100개의 웹로직 인스턴스가 동시 운영 될것으로 예측된다.         총 업무는 A업무 (4개), B관리 (4개), C관리 (4개) 로 구성된다.Ÿ          하드웨어는 IBM P6 시리즈를 사용하며, 총 예상 CPU수는 52장이며, 하드웨어 가상화 기능을 제공한다. 

Architecture Principals

본 아키텍쳐의 설계 기본 원칙은 다음과 같다.

1. 안정성

장애가 발생하였을 때도 장애 업무 이외의 업무는 정상적인 수행이 가능해야 하며 타 업무로 그 영향을 전파해서는 안된다.

2. 확장성

비즈니스 상황에 따라서, 전체 시스템의 용량 (동시 사용자수)나 기능 (서비스 수)를 아키텍쳐의 변화 없이 쉽게 확장할 수 있어야 한다.

3.유연성

비즈니스 변화에 대해서 유연하게 대처할 수 있어야 한다.

 

Conceptual Architecture

위의 세가지 Principal을 기반으로 설계된 Conceptual Architecture는 다음과 같다.


Application Grid

애플리케이션 그리드의 개념은 여러 개의 하드웨어를 모아서 비즈니스 로직을 제공하는 단일된 형태의 애플리케이션 집합체이다. 외부에서 보기에는 하나의 애플리케이션 집합체로 보이며 단일 접속점 (End Point)을 가지지만 실제로 내부에는 여러 개의 애플리케이션이 분리된 하드웨어에 분리된 형태로 배포되어 있다.

 하드웨어 가상화 개념을 응용하여 그리드 내부에서 업무의 비중과 중요도에 따라서 하드웨어 자원을 동적으로 재 배정하여 자원 사용의 효율성을 극대화 한다.

 새로운 기능이 추가될 때 마다 컴포넌트를 애플리케이션 그리드에 꼽는 (PLUG IN)하는 개념으로 비즈니스 컴포넌트를 추가할 수 있으며, 애플리케이션 그리드의 Infrastructure에는 그리드를 관리하기 위한 운영,관리,모니터링 기능(이하 OAM) 이 구현되어 있기 때문에, 개발자는 비즈니스 로직에만 집중하여 개발한후 그리드에 배포하면 OAM은 Infrastructure에 의해서 관리된다.

 

애플리케이션 그리드 아키텍쳐는 계층에 따라서 하드웨어/미들웨어(웹로직)/웹서버 3개의 계층으로 나뉘어서 분리된다.

 

(1)   하드웨어 아키텍쳐

하드웨어는 IBM AIX 중에 가상화를 지원하는 하드웨어를 사용한다. 가상화는 하나의 하드웨어내에 있는 여러개의 CPU와 메모리를 분할하여 사용할 수 있는 기능이다. 즉 하나의 하드웨어 자원을 조각으로 나누어서 업무별로 할당이 가능하다.

 

하드웨어 아키텍쳐 구성시에, 작은 하드웨어 여러 개를 사용하는 것보다, 가상화가 가능한 큰 하드웨어를 사용하는 것이 유리하다. 일반적인 국내 차세대 시스템의 경우 오픈후에, 안정화 기간을 거치면 통상적으로 CPU 평균 사용률이 40% 이하로 제대로 구성된 아키텍쳐에서는 20~30%대로 사용되는 경우가 많다. 반대로 부하가 몰리는 서버의 경우 CPU 사용률이 70~80%까지 육박하는 경우도 있다. 이러한 경우, CPU나 메모리 자원에 대한 효율적인 분할을 하기 위해서는 하드웨어를 물리적으로 옮겨서 새로 소프트웨어 시스템을 설치해야 하는데, 이 과정은 많은 시간과 검증 작업을 요구하며 또한 소프트웨어 라이센스 측면에서 문제를 유발할 수 있다. (하드웨어 추가는 소프트웨어 라이센스의 추가 구매를 의미한다.)

 이런 비효율성은 반대로 가상화를 지원하는 하드웨어를 사용했을 때 쉽게 해결된다.  업무의 부하량에 따라서 동적으로 CPU 자원을 재할당 하여 업무 부하에 적절하게 대응할 수 있고 CPU 재할당의 경우에도 별도의 하드웨어 작업(CPU를 빼서 다른 서버에 옮기는등의)이 없이 소프트웨어적인 설정만으로도 가능하기 때문에, 변경에 대한 영향도를 최소화 할 수 있다.

 

(2)   웹로직 구성 아키텍쳐

웹로직 구성상에 있어서는 다음과 같은 원칙을 따른다.

업무당 하나의 웹로직 도메인을 사용하며,하나의 도메인은 여러 개의 클러스터를 가질 수 있으며, 각 클러스터는 여러 개의 Managed Server로 구성된다. 각 Managed Server에는 1개 이상의 업무 애플리케이션이 배포될 수 있다.

 

1) 서버 분리를 통한 장애 전파성 제거

자바 기반의 장애 특성은 턱시도와 같은 TP Monitor와 다르게 모든 업무가 하나의 프로세스에서 돌아가는 특징을 가지고 있다. 이로 인해서 장애가 발생할 경우, 같은 프로세스에서 돌고 있는 다른 업무에도 영향을 줄 수 있다. (TP Monitor의 경우 업무별-SERVER로 프로세스가 나뉘어져서 기동되기 때문에 장애가 다른 업무에 전파되지 않고 국지화될 수 있는 장점을 가지고 있다.) 이와 같은 문제를 해결하기 위해서 WAS에서 여러가지 Work Manager나 Thread Pool 분리와 같은 여러가지 기능을 제공하는데, 이 역시도, 메모리 과사용이나 CPU 과 사용등에 대한 문제에서는 자유로울 수 없다.

 

가장 올바른 아키텍쳐 설계 방안은 TP Monitor와 같은 원리로, 업무별로 Manager Server를 분리하여 장애시 타 업무에 대한 장애 전파성을 제거하는 것이다.

 

2) 관리 포인트 증가에 대한 해결 방법

Managed Server를 업무별로 분할하여 운영할 경우, 그 만큼 많은 Managed Server가 운영되게 되고, 이는 관리 포인트의 증가로 귀결된다. 이런 관리상의 문제점을 해결하기 위해서, 웹로직을 클러스터링 기능을 사용할 수 있다. 클러스터링에서는 여러 개의 Managed Server가 있더라도 클러스터 단위로 configuration을 반영할 수 있는 기능이 있기 때문에, Managed Server의 수가 증가하더라도 실제로는 클러스터의 단위로 관리를 할 수 있기 때문에 관리에서 오는 복잡도를 감소 시킬 수 있다.

 

3) 클라이언트를 통한 상태 관리

업무별로 Managed Server를 나누는 경우 발생하는 문제점중의 하나가 Managed Server간에 Session이나 상태 정보가 공유가 안되는 문제점을 가지고 있다. 그러나 고객의 아키텍쳐 설계의 Assumption은 윈도우 클라이언트 기반의 Rich Client를 사용하기 때문에, 상태나 사용자 정보를 클라이언트에서 관리하도록 설계하여 서버간의 정보 공유를 서버에서 클라이언트로 이관함으로써 이를 극복할 수 있다.

 

(3)   웹서버 아키텍쳐

1) Endpoint에 대한 Location Transparency 의 제공

본 아키텍쳐에서 웹서버는 Application Grid로의 End point를 단일화 시켜주는 중요한 역할을 한다. Grid내의 여러 개의 Managed Server의 주소로 클라이언트가 직접 접근하는 것이 아니라 업무별로 배정된, 웹서버라는 단일 접속점을 통해서 Grid내의 Managed Server로 접근할 수 있게 해준다. (이는 Grid내의 Managed Server의 수가 증가하거나 감소하더라도, 접속점에 대한 변경을 없게 하여 Location Transparency를 보장할 수 있게 한다.)

 

2) 유연한 배포 구조의 제공

본 아키텍쳐에서의 웹서버 구성은 하나의 업무에 대해서 두 이상의 웹서버와 하나의 L4를 사용하도록 구성되어 있는데, 이는 애플리케이션의 배포의 용이성을 제공하기 위해서이다.

WAS의 기능에 상관없이 애플리케이션 개발과정상의 실수에 의해서 REDEPLOY 과정에 많은 문제를 일으킬 수 있는데, 이로 인해서 가장 좋은 REDEPLOY 방법은 DEPLOY후 RESTART하는 것이 가장 좋은 방법이다. 그러나 이 경우 해당 업무가 일시적으로 정지될 수 있는 위험도를 가지고 있기 때문에, 이 다운 타임을 최소화할 수 있는 아키텍쳐 설계가 필요하다.

2개의 웹서버중 하나의 웹서버를 다운 시키면 L4에 의해서 반대쪽 웹서버로만 부하가 가게 되고, 웹서버가 다운 되었기 때문에, 그에 연결된 Managed Server들은 사용자로부터 REQUEST를 받지 않는 상태가 된다. 이 상태에서 애플리케이션을 재배포한후 서버들을 재기동 시킨후, 반대족 웹서버도 번갈아서 같은 방식으로 재기동을 하게 되면 운영중에도 가장 안전한 방법으로 업무에 대한 정지 없이 재배포가 가능하게 된다.

 

Application Grid OAM (Operation, Administration, Monitoring)

OAM 기능은 애플리케이션 그리드에 대한 운영,관리, 모니터링 기능을 제공하는 인프라이다. 비록 고객의 요구 사항에서는 웹로직만으로 구성하는 것을 요청했으나, 아키텍쳐의 완성도를 위해서 OAM 모듈에 대한 기능을 추가하였다.

 

Configuration 관리

고객의 요구사항중의 하나는 100개이상의 웹로직 인스턴스를 운영 및 관리해야 한다. 비록 클러스터링을 통해서 관리 포인트를 줄일 수 있는 형태로 설계했지만, 많은 인스턴스에 대한 Configuration 관리는 매우 도전적인 과제중의 하나이다.

Oracle 제품중에 ACC (Application Configuration Console)은 단일 Console을 통해서 여러 Managed 서버와 도메인 그리고 클러스터에 대한 관리를 가능하게 해주며, Configuration에 대한 이력관리등을 통해서 애플리케이션 그리드에 대한 하나의 관리 기능을 제공한다.

 

시스템 상태 모니터링

전체 그리드에서 시스템의 상태를 일목요연하게 볼 수 있는 기능이 필요하다. CPU 사용률, 애플리케이션 관점에서의 병목 구간, Thread 상태, 응답 시간등에 대한 모니터링 기능이 필요한데, 이는 APM (Application Performance Monitoring)을 통해서 가능하다.

 

업무별 상태 모니터링

시스템 상태 모니터링이 애플리케이션 관점(기술 관점)이라면 업무별 상태 모니터링은 비즈니스 관점에서 애플리케이션 그리드를 모니터링 하는 것이다.

 업무별 응답시간, 사용률, 장애율등을 Oracle BAM (Business Activity Monitoring)을 이용하여 그래프로 가시화 하여, 업무의 운용 상황을 한눈에 파악할 수 있도록 한다.

 

Features

Application Grid 아키텍쳐의 특징을 다시한번 정리해보면 다음과 같다.

 

장애 전파 방지 

Ÿ          Managed Server 분리를 통한 장애 전파 방지

업무별로 Managed Server를 분리하여, Dead Lock이나 Lock 경합으로 인한 장애 전파 또는 메모리 과사용으로 인하여 다른 업무에 영향을 주는 요인을 제거하였다.

Ÿ          하드웨어 자원 분리를 통한 장애 전파 방지

기존 WAS 아키텍쳐에서는 JAVA 프로세스를 분리하더라도, 실제 CPU나 메모리등의 하드웨어 자원을 공유해왔기 때문에, 한 프로세스가 CPU를 과점유하기 시작하면 정상적인 다른 프로세스에게도 영향을 줬다.

그러나 이 아키텍쳐에서는 업무에 따라서 하드웨어 자원을 분리하여 할당하기 때문에,특정 업무가 CPU를 과점유한다하더라도, 다른 업무용으로 배정된 CPU 자원을 사용할 수 없기 때문에, 하드웨어 자원 점유에 의한 장애 전파를 방지한다.

유연하고 최적화된 하드웨어 리소스 운영

Ÿ          Managed Server의 수 조정을 통한 자원 배분

시스템의 사용량이 늘어날 때, 사용량이 늘어난 업무에만 Managed Server의 수를 늘려서 하드웨어 자원의 사용을 최적화 할 수 있다. 반대로 사용량이 적은 업무의 경우 Managed Server의 수를 줄여서 잉여된 자원을 다른 업무에 배정하여 전체 Application Grid의 하드웨어 사용 효율성을 극대화 한다.

Ÿ          가상화를 통한 CPU 및 메모리에 대한 유연한 배분

해당 업무에 메모리 사용량이 높거나 CPU 사용량이 높을때는 하드웨어 가상화 기능을 통해서

메모리 크기 한계 극복

Ÿ          업무별 분리를 통한 메모리 사용성의 극대화

자바 애플리케이션은 구조상의 한계상 통상적으로 1.5GB의 메모리만이 사용가능하다. (최대 3G). 그래서 사용자 수가 늘어나는 경우에는 전체 부하를 여러 개의 인스턴스로 분산 시켜서 메모리 사용량을 낮추어야 하는데, 이 아키텍쳐에서는 간단하게 Managed Server의 수만 늘려주는 것만으로 메모리에 대한 부하를 손쉽게 분산 시킨다.

       참고 : Managed Server 분리에도 불구하고, 더 많은 양의 메모리가 필요한 경우에는 Coherence Data Grid를 이용하여, 메모리 확장을 고려할 수 있다.

 

확장성 

Ÿ          웹서버를 이용한 Location Transparency의 제공

업무의 종류나 부하량 또는 사용자가 증가하는 것에 상관없이, 새로운 업무는 Application Grid에 추가로 배포될 수 있으며, 시스템의 용량도 하드웨어 증설만으로 큰 설정 변경 없이 손쉽게 증설이 가능하다. 시스템이 확장되더라도 Grid 밖에서 보기에는 동일한 End Point를 통해서 접근하는 것이기 때문에, 확장이 기존의 애플리케이션에 영향을 주지 않는다.

애플리케이션 배포의 유연성 

Ÿ          웹서버와 L4를 이용한 무정지 Clean redeploy 제공

앞서 설명한 바와 같이 L4와 2개 이상의 웹서버 구성을 통해서 가장 안전한 방법 (RESTART)으로 운영중 무정지 재배포를 지원한다.

 


The RESTful Soa Datagrid with Oracle
View more documents from Emiliano Pecis.


Coherence를 캐슁으로 실제 구축한것이 흥미롭다.
다음 아키텍쳐 구축할때 참고할것

JEE enterprise Application Grid Architecture

아키텍쳐 /SOA | 2009.06.12 14:56 | Posted by 조대협

JEE Application Grid Architecture

 

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

 

사상 (Architecture Principals)

애플리케이션 그리드 아키텍쳐 사상은 다음과 같다.

비즈니스 로직을 가진 업무 컴포넌트가 무제한적으로 그리드에 추가될 수 있으며, 호출하는 클라이언트 입장에서는 각각의 업무나 업무 컴포넌트를 분리된 형태가 아닌 하나의 진입점을 통해서 호출하도록 하고, 각 업무의 부하에 따라서 업무 시스템에 하드웨어 자원(CPU,MEMORY)를 탄력적으로 배분함으로써 최적화된 성능을 유지하고, 업무 또는 업무 컴포넌트에 장애가 발생하였을때에도 해당 장애가 다른 업무에 영향을 주지 않도록 하는 아키텍쳐이다.

 리소스 배분에 대한 구현

본 아키텍쳐의 특징중의 하나는 업무의 부하량에 따라서 하드웨어 자원을 자유롭게 배분하는 것이다. 이는 하드웨어에서 제공하는 가상화 기능을 이용하여 구축이 가능한데, 업무의 부하량에 따라서 WAS 인스턴스의 수를 탄력적으로 조정하고, 해당 업무를 담당하는 WAS INSTANCE그룹에 CPU와 메모리를 동적으로 배분함으로써 효율적인 자원 활용이 가능하다.

 바꿔 이야기 하면 오픈 당시에 예측했던 용량에 비해서 부하가 적은 업무에는 CPU를 빼고, 부하가 높은 업무에 CPU를 부여함으로써 자원 활용의 효율성과 확장성을 고려하는 것이다.

 장애 전파 방지

다른 특징은 장애 전파의 방지인데, 여러 업무 애플리케이션이 하나의 WAS INSTANCE에 배포되어 있는 경우, 한 업무가 장애가 나서 CPU과 사용등의 현상이 생기거나 THREAD를 과점유할 때, 같은 INSTANCE에 돌고 있는 다른 업무 역시 정상적인 수행이 불가능해진다. 이를 방지하기 위해서 업무별로 WAS INSTANCE를 나눠서 배포함으로써, 장애 전파 가능성을 제거할 수 있다.

 통상적으로 여러 업무를 하나의 WAS INSTANCE에 배포하는 주요한 이유중의 하나는 공유 데이터 (HTTP SESSION이나, 사용자 공유정보)를 하나의 INSTANCE내에서만 공유할 수 있기 때문인데 이 문제는 Oracle Coherence를 이용함으로써 INSTANCE간 메모리 공유를 통해서 해결할 수 있다.

 개발 생산성 증가

비즈니스 컴포넌트를 개발하는 입장에서 생산성에 문제를 일으키는 요인중의 하나가 공통 모듈 (Cross Cutting Concern)의 중복 개발이다. 인증,인가,로깅,Throwtling등의 공통 모듈 역시 JEE 아키텍쳐에서는 공통 라이브러리를 사용하건 말건간에, 비즈니스 컴포넌트에 붙여서 개발이 되어야 했다. 이는 개발자가 비즈니스 로직뿐만이 아니라 공통 모듈 개발에도 어느정도의 노력을 사용하도록 해왔고, 또한 공통 모듈의 변화는 개발 내용 전체에 영향을 줄 수 있어서 생산성에 영향을 줘왔던 것이 사실이다.

이러한 공통 모듈을 ESB 계층으로 모두 옮겨서, 비즈니스 컴포넌트에는 순수한 비즈니스 로직만이 들어가도록 하고, 공통 모듈은 ESB에 구현함으로써 비즈니스 로직 개발자가 순수 로직 개발에만 집중하도록 하여 개발의 생산성을 극대화 할 수 있다.

 시스템 유연성의 증가

IT 시스템은 비즈니스 요건에 따라서 변경 요건이 필수적으로 발생하는데, 본 아키텍쳐는 변경에 대한 요건을 ESB를 통해서 소화함으로써 시스템의 요건 변경에 대한 유연성을 극대화 한다.

 ESB는 자체적으로 Request/Response에 대해서 기능을 추가하거나 변경할 수 있는 Mediation의 개념을 가지고 있기 때문에, 업무 요건 변경으로 인한 기능 추가, 전문이나 데이터의 변경등을 비즈니스 컴포넌트의 변형 없이 ESB Mediation Logic을 추가함으로써 손쉽게 반영할 수 있다.

 무제한 확장 가능한 그리드  아키텍쳐

이 아키텍쳐의 가장 큰 특징중의 하나가 확장성이다. 새로운 비즈니스 로직이나 업무가 추가된다면, WAS INSTANCE를 추가하고 비즈니스 컴포넌트만 추가 배포하면 된다. (PLUG IN하듯이.) 비즈니스 로직을 호출하는 클라이언트 입장에서는 변화된 내용이 없으며 예전과 동일하게 하나의 접속점을 통해서 기존과 새로운 비즈니스 컴포넌트를 호출하면 되고, 하드웨어 용량 증설역시 횡적으로 확장해나가면서 비즈니스 로직을 추가할 수 있다.

 결론

기본 아키텍쳐 설계의 내용자체를 보면 복잡도는 크게 높지는 않다. “Simple is Best!”라는 원칙도 있듯이, 아키텍쳐는 단순성이 높을 수 록 성능과 그 신뢰성이 높아진다. 본 아키텍쳐는 엔터프라이즈 시스템에서 필수로 요구되는 확장성,유연성,신뢰성을 골고루 갖추고 있다.

참고

Coherence OSB를 이용한 아키텍쳐의 개념은 다음 문서를 참고하기 바란다.

 

 

'아키텍쳐  > SOA' 카테고리의 다른 글

EAI관점에서 본 SOA  (6) 2009.07.29
SOA를 공부하세요. 최고입니다.  (4) 2009.07.04
JEE enterprise Application Grid Architecture  (0) 2009.06.12
괜찮은 SOA 테스팅 툴 발견  (0) 2009.03.16
SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16

 

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

관심이 가는 오라클 제품들

아키텍쳐 /SOA | 2008.10.15 13:48 | Posted by 조대협
요즘 들어 오라클에 들어와서 제품들을 보면서 관심들이 가는 제품들이 있는데..

1. ODI -  ETL 같은 솔루션인데, 보다 Near realtime에다가 ETL과 접근 방법이 약간 틀려서 EL-T라고 하는데 성능이나 사용성이 좋은듯 하다. 그간 ETL 솔루션이 없어서 고생좀 했는데. 의외로 좋은 아이템이 될듯.
2. ORACLE BPEL PM - WLI 와 AL BPM의 중간 계보쯤을 이어주는 제품. Human Oritented BPM보다 System Oriented BPM에 가까운데. WLI의 족보를 이어서 선전(?)을 하지 않을까/
3. Coherence - 이미 아는 사람들은 다 아는 오라클이 인수한 메모리 캐슁 제품... 꼭 한번 써보리라!!
4. ALER - 시간이 없다는 핑계로 오랫동안 묻어두고 안보고 있었는데... 주인을 가리는 칼이라 해야하나? 쓰는 사람이 잘쓴다면 의외로 엄청난 무기가 될 수 있는 SOA Asset 관리 도구...

하나하나 새로운 기술이나 제품을 알아간다는것이 즐거운게.. 나는 어쩔 수 없는 엔지니어일까?

'아키텍쳐  > SOA' 카테고리의 다른 글

Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04