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


저작자 표시
신고

redis Introduction


Intro
Redis는 "REmote DIctionary System"의 약자로 메모리 기반의 Key/Value Store 이다.
Cassandra나 HBase와 같이 NoSQL DBMS로 분류되기도 하고, memcached와 같은 In memory 솔루션으로 분리되기도 한다.
성능은 memcached에 버금가면서 다양한 데이타 구조체를 지원함으로써 Message Queue, Shared memory, Remote Dictionary 용도로도 사용될 수 있으며, 이런 이유로 인스탄트그램, 네이버 재팬의 LINE 메신져 서비스, StackOverflow,Blizzard,digg 등 여러 소셜 서비스에 널리 사용되고 있다.
BSD 라이센스 기반의 오픈 소스이며 최근 VMWare에 인수되어 계속해서 업그레이드가 되고 있다.
16,000 라인정도의 C 코드로 작성되었으며, 클라이언트 SDK로는
Action Script,C,C#,C++,Clojure,Erlang,Java,Node.js,Objective-C,Perl,PHP,Python,Smalltalk,Tcl등 대부분의 언어를 지원한다. (참고 : http://www.redis.io/clients )

이번 글에서는 Redis란 무엇인지, 그리고 대략적인 내부 구조에 대해서 살펴보도록 한다.

1. Key/Value Store
Redis는 기본적으로 Key/Value Store이다. 특정 키 값에 값을 저장하는 구조로 되어 있고 기본적인 PUT/GET Operation을 지원한다.

단, 이 모든 데이타는 메모리에 저장되고, 이로 인하여 매우 빠른 write/read 속도를 보장한다. 그래서 전체 저장 가능한 데이타 용량은 물리적인 메모리 크기를 넘어설 수 있다. (물론 OS의 disk swapping 영역등을 사용하여 확장은 가능하겠지만 성능이 급격하게 떨어지기 때문에 의미가 없다.)
데이타 억세스는 메모리에서 일어나지만 server restart 와 같이 서버가 내려갔다가 올라오는 상황에 데이타를 저장을 보장하기 위해서 Disk를 persistence store로 사용한다.

2. 다양한 데이타 타입
단순한 메모리 기반의 Key/Value Store라면 이미 memcached가 있지 않은가? 그렇다면 어떤 차이가 있길래 redis가 유행하는 것일까?
redis가 Key/Value Store이기는 하지만 저장되는 Value가 단순한 Object가 아니라 자료구조를 갖기 때문에 큰 차이를 보인다.
redis가 지원하는 데이타 형은 크게 아래와 같이 5가지가 있다.

1) String
일반적인 문자열로 최대 512mbyte 길이 까지 지원한다.
Text 문자열 뿐만 아니라 Integer와 같은 숫자나 JPEG같은 Binary File까지 저장할 수 있다.

2) Set
set은 string의 집합이다. 여러개의 값을 하나의 Value 내에 넣을 수 있다고 생각하면 되며 블로그 포스트의 태깅(Tag)등에 사용될 수 있다.
재미있는 점은 set간의 연산을 지원하는데, 집합인 만큼 교집합, 합집합, 차이(Differences)를 매우 빠른 시간내에 추출할 수 있다.

3) Sorted Set
set 에 "score" 라는 필드가 추가된 데이타 형으로 score는 일종의 "가중치" 정도로 생각하면 된다.
sorted set에서 데이타는 오름 차순으로 내부 정렬되며, 정렬이 되어 있는 만큼 score 값 범위에 따른 쿼리(range query), top rank에 따른 query 등이 가능하다.


4) Hashes
hash는 value내에 field/string value 쌍으로 이루어진 테이블을 저장하는 데이타 구조체이다.
RDBMS에서 PK 1개와 string 필드 하나로 이루어진 테이블이라고 이해하면 된다.


5) List
list는 string들의 집합으로 저장되는 데이타 형태는 set과 유사하지만, 일종의 양방향 Linked List라고 생각하면 된다. List 앞과 뒤에서 PUSH/POP 연산을 이용해서 데이타를 넣거나 뺄 수 있고, 지정된 INDEX 값을 이용하여 지정된 위치에 데이타를 넣거나 뺄 수 있다. 


6) 데이타 구조체 정리
지금까지 간략하게 redis가 지원하는 데이타 구조체들에 대해서 살펴보았다.
redis의 데이타 구조체의 특징을 다시 요약하자면
  • Value가 일반적인 string 뿐만 아니라, set,list,hash와 같은 집합형 데이타 구조를 지원한다.
  • 저장된 데이타에 대한 연산이나 추가 작업 가능하다. (합집합,교집합,RANGE QUERY 등)
  • set은 일종의 집합, sorted set은 오름차순으로 정렬된 집합, hash는 키 기반의 테이블, list는 일종의 링크드 리스트 와 같은 특성을 지니고 있다.
이러한 집합형 데이타 구조 (set,list,hash)등은 redis에서 하나의 키당 총 2^32개의 데이타를 이론적으로 저장할 수 있으나, 최적의 성능을 낼 수 있는 것은 일반적으로 1,000~5,000개 사이로 알려져 있다.

데이타 구조에 따른 저장 구조를 정리해서 하나의 그림에 도식화해보면 다음과 같다.



3. Persistence
앞서도 언급하였듯이, redis는 데이타를 disk에 저장할 수 있다. memcached의 경우 메모리에만 데이타를 저장하기 때문에 서버가 shutdown 된후에 데이타가 유실 되지만, redis는 서버가 shutdown된 후 restart되더라도, disk에 저장해놓은 데이타를 다시 읽어서 메모리에 Loading하기 때문에 데이타 유실되지 않는다.
redis에서는 데이타를 저장하는 방법이 snapshotting 방식과 AOF (Append on file) 두가지가 있다.

1) snapshotting (RDB) 방식
순간적으로 메모리에 있는 내용을 DISK에 전체를 옮겨 담는 방식이다.
SAVE와 BGSAVE 두가지 방식이 있는데,
SAVE는 blocking 방식으로 순간적으로 redis의 모든 동작을 정지시키고, 그때의 snapshot을 disk에 저장한다.
BGSAVE는 non-blocking 방식으로 별도의 process를 띄운후, 명령어 수행 당시의 메모리 snaopshot을 disk에 저장하며, 저장 순간에 redis는 동작을 멈추지 않고 정상적으로 동작한다.
  • 장점 : 메모리의 snapshot을 그대로 뜬 것이기 때문에, 서버 restart시 snapshot만 load하면 되므로 restart 시간이 빠르다.
  • 단점 : snapshot을 추출하는데 시간이 오래 걸리며, snapshot 추출된후 서버가 down되면 snapshot 추출 이후 데이타는 유실된다.
    (백업 시점의 데이타만 유지된다는 이야기)
2) AOF 방식
AOF(Append On File) 방식은 redis의 모든 write/update 연산 자체를 모두 log 파일에 기록하는 형태이다. 서버가 재 시작될때 기록된  write/update operation을 순차적으로 재 실행하여 데이타를 복구한다. operation 이 발생할때 마다 매번 기록하기 때문에, RDB 방식과는 달리 특정 시점이 아니라 항상 현재 시점까지의 로그를 기록할 수 있으며, 기본적으로 non-blocking call이다.
  • 장점 : Log file에 대해서 append만 하기 때문에, log write 속도가 빠르며, 어느 시점에 server가 down되더라도 데이타 유실이 발생하지 않는다.
  • 단점 : 모든 write/update operation에 대해서 log를 남기기 때문에 로그 데이타 양이 RDB 방식에 비해서 과대하게 크며, 복구시 저장된 write/update operation을 다시 replay 하기 때문에 restart속도가 느리다.
3) 권장 사항
RDB와 AOF 방식의 장단점을 상쇠하기 위해서 두가지 방식을 혼용해서 사용하는 것이 바람직한데
주기적으로 snapshot으로 백업하고, 다음 snapshot까지의 저장을 AOF 방식으로 수행한다.
이렇게 하면 서버가 restart될 때 백업된 snapshot을 reload하고, 소량의 AOF 로그만 replay하면 되기 때문에, restart 시간을 절약하고 데이타의 유실을 방지할 수 있다.


4. Pub/Sub Model
redis는 JMS나 IBM MQ 같은 메세징에 활용할 수 있는데, 1:1 형태의 Queue 뿐만 아니라 1:N 형태의 Publish/Subscribe 메세징도 지원한다.(Publish/Subscribe 구조에서 사용되는 Queue를 일반적으로 Topic이라고 한다.)
하나의 Client가 메세지를 Publish하면, 이 Topic에 연결되어 있는 다수의 클라이언트가 메세지를 받을 수 있는 구조이다. (※ Publish/Subscribe 형태의 messaging 에 대해서는 http://en.wikipedia.org/wiki/Pub/sub  를 참고하기 바란다.)


재미있는 것중에 하나는 일반적인 Pub/Sub 시스템의 경우 Subscribe 하는 하나의 Topic에서만 Subscribe하는데 반해서, redis에서는 pattern matching을 통해서 다수의 Topic에서 message 를 subscribe할 수 있다.
예를 들어 topic 이름이 music.pop music,classic 이라는 두개의 Topic이 있을때, "PSUBSCRIBE music.*"라고 하면 두개의 Topic에서 동시에 message를 subscribe할 수 있다.

5. Replication Topology
redis는 NoSQL 계열의 Key/Store Storage인데 반해서 횡적 확장성을 지원하지 않는다.
쉽게 말해서 2.4.15 현재 버전 기준으로는 클러스터링 기능이 없다. (향후 지원 예정)
그래서 확장성(scalability)과 성능에 제약사항이 있는데, 다행이도 Master/Slave 구조의 Replication(복제)를 지원하기 때문에 성능 부분에 있어서는 어느정도 커버가 가능하다.

Master/Slave replication
Master/Slave Replication이란, redis의 master node에 write된 내용을 복제를 통해서 slave node에 복제 하는 것을 정의한다.
1개의 master node는 n개의 slave node를 가질 수 있으며, 각 slave node도 그에 대한 slave node를 또 가질 수 있다.


이 master/slave 간의 복제는 Non-blocking 상태로 이루어진다. 즉 master node에서 write나 query 연산을 하고 있을 때도 background로 slave node에 데이타를 복사하고 있다는 이야기고, 이는 master/slave node간의 데이타 불일치성을 유발할 수 있다는 이야기이기도 하다.
master node에 write한 데이타가 slave node에 복제중이라면 slave node에서 데이타를 조회할 경우 이전의 데이타가 조회될 수 있다.

Query Off Loading을 통한 성능 향상
그러면 이 master/slave replication을 통해서 무엇을 할 수 있냐? 성능을 높일 수 있다. 동시접속자수나 처리 속도를 늘릴 수 있다. (데이타 저장 용량은 늘릴 수 없다.) 이를 위해서 Query Off Loading이라는 기법을 사용하는데
Query Off Loading은 master node는 write only, slave node는 read only 로 사용하는 방법이다.
단지 redis에서만 사용하는 기법이 아니라, Oracle,MySQL과 같은 RDBMS에서도 많이 사용하는 아키텍쳐 패턴이다.
대부분의 DB 트렌젝션은 웹시스템의 경우 write가 10~20%, read가 70~90% 선이기 때문에, read 트렌젝션을 분산 시킨다면, 처리 시간과 속도를 비약적으로 증가 시킬 수 있다. 특히 redis의 경우 value에 대한 여러가지 연산(합집합,교집합,Range Query)등을 수행하기 때문에, 단순 PUT/GET만 하는 NoSQL이나 memcached에 비해서 read에 사용되는 resource의 양이 상대적으로 높기 때문에 redis의 성능을 높이기 위해서 효과적인 방법이다.

Sharding 을 통한 용량 확장
redis가 클러스터링을 통한 확장성을 제공하지 않는다면, 데이타의 용량이 늘어나면 어떤 방법으로 redis를 확장해야 할까?
일반적으로 Sharding이라는 아키텍쳐를 이용한다. Sharding은 Query Off loading과 마친가지로, redis 뿐만 아니라 일반적인 RDBMS나 다른 NoSQL에서도 많이 사용하는 아키텍쳐로 내용 자체는 간단하다.
여러개의 redis 서버를 구성한 후에, 데이타를 일정 구역별로 나눠서 저장하는 것이다. 예를 들어 숫자를 key로 하는 데이타가 있을때 아래와 그림과 같이 redis 서버별로 저장하는 key 대역폭을 정해놓은 후에, 나눠서 저장한다.
데이타 분산에 대한 통제권은 client가 가지며 client에서 애플리케이션 로직으로 처리한다.

현재 버전 2.4.15에서는 Clustering을 지원하지 않아서 Sharding을 사용할 수 밖에 없지만 2012년 내에 Clustering기능이 포함된다고 하니, 확장성에 대해서 기대해볼만하다. redis가 지원할 clustering 아키텍쳐는 ( http://redis.io/presentation/Redis_Cluster.pdf ) 를 참고하기 바란다.

6. Expriation
redis는 데이타에 대해서 생명주기를 정해서 일정 시간이 지나면 자동으로 삭제되게 할 수 있다.
redis가 expire된 데이타를 삭제 하는 정책은 내부적으로 Active와 Passive 두 가지 방법을 사용한다.
Active 방식은 Client가 expired된 데이타에 접근하려고 했을 때, 그때 체크해서 지우는 방법이 있고
Passive 방식은 주기적으로 key들을 random으로 100개만 (전부가 아니라) 스캔해서 지우는 방식이 이다.
expired time이 지난 후 클라이언트에 의해서 접근 되지 않은 데이타는 Active 방식으로 인해서 지워지지 않고 Passive 방식으로 지워져야 하는데, 이 경우 Passive 방식의 경우 전체 데이타를 scan하는 것이 아니기 때문에, redis에는 항상 expired 되었으나 지워지지 않는 garbage 데이타가 존재할 수 있는 원인이 된다.

7. Redis 설치(윈도우즈)
https://github.com/rgl/redis/downloads 에서 최신 버전 다운로드 받은후
redis-server.exe를 실행

클라이언트는 redis-cli.exe를 실행
아래는 테스트 스크립트
    % cd src
    % ./redis-cli
    redis> ping
    PONG
    redis> set foo bar
    OK
    redis> get foo
    "bar"
    redis> incr mycounter
    (integer) 1
    redis> incr mycounter
    (integer) 2
    redis> 


참고 자료


저작자 표시
신고

잘 정리해놓은 문서가 있어서 PPT 링크


저작자 표시
신고

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와 함께해서 아키텍쳐를 한번 조합해봤으면 좋겠는데..

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

저작자 표시
신고