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


Archive»


 
 

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

Enterprise Service Bus(ESB)를 이용한

차세대 JEE 아키텍쳐의 확장

 

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

 

서론

근래의 JEE애플리케이션 아키텍쳐를 보면 전통적인 JSP/Servlet과 같은 HTML방식의 UI에서 AJAX/FLASH같은 X-Internet 솔루션을 사용하는 경우가 많다. 그래서 애플리케이션 아키텍쳐 역시 비즈니스 모듈이 XML+HTTP 형태로 기능을 제공하고, XML 데이터를 X-Internet 솔루션에서 처리하는 경우가 통상적이다. (국내의 가우스 플랫폼등)


기존의 아키텍쳐에서는 UI에서 BIZ LOGIC으로의 호출이 Java Language에 의존적인 형태의 호출로 이루어져 왔다. 단순하게 Java Method Invoke하는 형태 였는데, X-Internet 솔루션의 도입후의 아키텍쳐는 아래 그림과 같이


클라이언트에서 BIZ LOGIC까지 HTTP등의 프로토콜을 이용한 Remote 호출형태로 변화되었다.

 

전통적인 X-Intenet 기반의 JEE 아키텍쳐의 문제점

비표준 전문 형태 사용

 X-Internet 플랫폼 특히, 국내에서 개발된 X-Internet 플랫폼의 문제는 그 프로토콜이 어떤 표준을 따르지 않는다는 것이다. SOAP을 기반으로한 웹서비스나 REST 스타일이 아닌 단순하게, HTTP XML을 실어 보내는 형태의 XML-RPC 형태로 그 X-Internet 플랫폼에 특화된 프로토콜을 정의하여 사용하는 경우가 많다.

 그래서 이 프로토콜에 맞춰서 개발된 시스템들의 경우 제공되는 서비스는 오로지 그 X-Internet 플랫폼에서만 호출하여 사용할 수 있고, 다른 애플리케이션에서 호출하고자 할때는 별도의 인터페이스를 개발해야 하는 일이 발생한다. 또한 프로토콜의 SPEC 자체가 조악하거나 기능이 매우 빈약하여 추후 유지 보수나 관리 관점에서 많은 문제를 유발한다.

     실예로, 모 통신회사의  X-Internet 클라이언트 형태가 이러하다.

중복된 Cross cutting concern의 개발

HTTP 형태로 컴포넌트 기능을 제공하는 아키텍쳐의 공통적인 문제점중 하나는 Cross Cutting Concern (공통 기능)이 각각의 컴포넌트에서 구현이 된다는 것이다.

 인증과 인가, 로깅과 같은 공통적인 처리 요건이 각각의 컴포넌트 모듈에서 중복되서 개발이 된다. 이로 인해서, 같은 코드를 반복해서 개발해서 생산성이 떨어지고, 또한 만약 이러한 공통 처리 요건이 변경되었을 때, 전체 시스템의 코드를 변경해야 하는 문제가 발생한다.


 Oracle Service Bus를 이용한 아키텍쳐 개선

이러한 문제는 HTTP 기반의 컴포넌트 모델을 지원할 수 있는 유연한 인프라를 가지지 못해서 발생하는 것인데, Oracle Service Bus(이하 OSB-Oracle에서 판매하는 Enterprise Service Bus)로 이러한 문제를 해결할 수 있다. 특히 OSB의 장점중의 하나는 SOAP 기반의 WebService만을 지원하는 것이 아니라 AnySOAP, AnyXML,Text 등과 같은 다양한 형태의 Message Format을 지원하기 때문에, 단순히 웹서비스 기반의 플랫폼뿐만이 아니라 자체 표준을 사용하는 다양한 형태의 비즈니스 애플리케이션에도 적용이 가능하다

1)    다양한 프로토콜을 지원

WEB 2.0이 도래하면서 HTTP 기반의 프로토콜이 웹서비스뿐만 아니라 용도에 따라 REST with XML이나 REST with JSON, XML RPC등 여러가지 형태의 프로토콜을 사용하고 있다. 이러한 프로토콜을 각각의 업무 비즈니스에서 지원하려면 중복된 개발이 필요하고, 컴포넌트 개발자가 비즈니스 로직뿐만 아니라 프로토콜 변환에도 상당한 노력을 들여야 한다.


OSB를 사용함으로써 얻을 수 있는 장점중의 하나가 Entry Point OSB로 단일화 함으로써, IN/OUT 프로토콜에 대한 변환 지원이 가능하며 이는 OSB에서 중앙 집중화된 형태로 처리가 가능하기 때문에, 업무 개발자의 노력을 경감시켜서 개발 생산성의 향상을 이끌어 올 수 있고, 추가적인 프로토콜 변화 요청에 대해서 유연하게 대응할 수 있다

또한 내부의 컴포넌트 프로토콜을 하나의 표준 프로토콜로 단일화 할 수 있어서, 아키텍쳐의 단순성과 함께 표준화를 통한 관리의 용이성을 얻을 수 있다.  

2)    Cross Cutting Concern(공통모듈) 처리의 단일화

위에서도 언급했듯이, 컴포넌트 개발에 있어서 문제점중의 하나가 공통 모듈에 대한 중복 개발 문제이다. 이는 중복적인 개발로 인하여 개발의 생산성을 떨어뜨리고 또한 공통 모듈의 변화는 전체 프로그램의 수정을 일으켜서 아키텍쳐의 유연성과 생산성을 급격하게 감소 시키는 문제점을 야기 하였다.

이러한 공통 모듈 (Cross cutting concern) OSB에 중앙 집중화 시킴으로써, 컴포넌트 개발자가 비즈니스 업무 로직 개발에 집중하도록 하고, 변경시에서도 OSB 단일 지점만 변경하도록 하여 유연하고 생산성이 높은 아키텍쳐를 구축할 수 있다.

 

3)    Mediation을 통한 비즈니스 변화에 대한 적응

아키텍쳐 설계에 있어서 중요한 점 중의 하나는 비즈니스 변화에 대한 대응 능력이다.

예를 들면

Ÿ  Function Adding

기존 기능에 대해서 새로운 기능이 더해진 경우. 예를 들어결재 서비스에 캐쉬백 기능이나 포인트 적립이 추가되는 경우

Ÿ  Data Transformation

입력이나 출력 받는 데이터의 형식이 바뀐 경우. 예를 들어 게시판에 글을 올리는데 기존에는 사용자 ID만 필요했는데, 실명제로 인해서 주민등록 번호를 조회해야 하는 경우 입력값이 사용자 ID만에서 사용자 ID와 주민등록 번호를 받는 입력형태로 변경되고, 기존의 글 올리기 서비스는 변경이 없고 입력 받은 주민등록 번호로 실명 인증하는 기능을 추가하는 경우

Ÿ  Routing

어떤 조건에 따라서 호출되는 서비스가 달라지는 경우. 예를 들어 신용카드 서비스 정책이 일반 회원만 있다가 플레티넘 회원에 대한 서비스와 포인트 적립 방식이 달라지는 경우 회원 등급에 따라서 호출해야 하는 서비스가 달라진다.

이러한 시나리오는 비즈니스 요구사항 변화에 따라서 발생을 하고, 이는 실제 비즈니스 컴포넌트에 변경 요건을 준다. 특히 해당 비즈니스 컴포넌트가 여러곳에서 사용되고 있을 경우(의존성을 갖는 경우) 이에 대한 변경 여파가 매우 크다.

 위와 같이 기존의 비즈니스 로직에 변화를 줘서 동작 방식을 바꾸거나 개선하는 것을 Mediation이라고 하는데, OSB에서 이 Mediation 계층을 추가하여 비즈니스 요건이 변경되었을 경우 비즈니스 컴포넌트에 대한 변경이 없이 이를 OSB내에서 반영하여 업무 요구 사항에 대한 변화에 쉽고 빠르게 대응할 수 있다

4)    모니터링과 서비스 통제 (SLA/Throttling )

마지막으로 서비스에 대한 통제와 모니터링 기능을 꼽을 수 있는데, 특정 서비스의 사용률이나 응답시간등의 모니터링을 통해서 비즈니스 컴포넌트의 건강성과 재사용률을 파악할 수 있다.

그리고 비즈니스 컴포넌트에 문제가 있을 때 빠르게 검출 및 대응을 할 수 있다. (응답시간이 5초내로 떨어지는등 현상),  무엇보다 통제 기능을 부여할 수 있는게 큰 장점중의 하나이다. 해당 비즈니스 컴포넌트의 TPS 100이상을 넘으면 더 이상 요청을 받지 않고 에러 처리를 해서 시스템을 보호한다거나 관리자에게 알려서 용량 증설등의 조치를 할 취할 수 있게 한다.

 이런한 모니터링 및 관제 기능을 별도로 비즈니스 컴포넌트단에서 구현하기 위해서는 별도의 아키텍쳐 설계와 함께, 공통 모듈의 개발과 테스트를 거쳐야 하는데, 이런 과정이 패키지화 되어 있기 때문에, 이 과정에 소요 되는 많은 리소스들을 절약할 수 있다

4가지 주요 기능을 정리해서 보면 다음과 같은 그림으로 나타낼 수 있다.

 

아키텍쳐 구현시 주의 사항

 

OSB ESB를 이용한 아키텍쳐 구현에서 있어서 가장 흔하게 발생하면서 가장 치명적인 실수중의 하나가 Mediation Orchestration에 대한 잘못된 이해이다.

 Mediation은 기존의 비즈니스 기능에 추가로 기능을 덧붙여서 비즈니스에 기능을 추가 (정확히 말하면 enrich)하는 것이다. Orchestration은 하나 이상의 비즈니스 컴포넌트를 묶어서 새로운 기능을 구현해 내는 것이다.

 언뜻 보면 비슷할 수 도 있지만, 결정적인 차이는 추가되는 양에 있다. 예를 들면 Mediation이 자동차를 튜닝하여 자동차의 기능을 개선하는 것이라면, Orchestration LCD 생산 라인과 전화기 생산라인을 연계해서 컬러 LCD 전화기를 만들어내는것과 같다고 할까? (예를 들기가 참 어렵군요)

그래서 전통적으로 Orchestration Volume이 비슷한 2개 이상의 비즈니스 컴포넌트가 묶여져서 하나의 새로운 비즈니스 기능을 만들어내고, 많게는 10여개 이상의 비즈니스 컴포넌트가 로직에 따라서 흐름을 이어가는 경우가 많다. 종종 이 과정에서는 stateful 하거나 long running한 프로세스가 구현되기도 하는데, 이런 Orchestration 요건은 BPM과 같은 솔루션을 이용해서 구현되는 것이 바람직하고, ESB는 비즈니스 컴포넌트를 하나의 BUS라는 Entry point (진입점)을 통해서 외부에 서비스 하면서, 비즈니스의 변화에 유연하게 대응할 수 있도록 Mediation을 하는 기능을 갖추어야 한다.

ESB 단에서 종종 Orchestration이 발생하는 경우를 봤는데. (기능상으로는 BPM이나 ESB Workflow를 구현할 수 있는 기능이 있기 때문에 언뜻보면 비슷하다.) 성능상으로 엄청난 부하를 유발해서 프로젝트 후반에는 잘못된 아키텍쳐로 엄청난 하드웨어 증설이 필요한 경우를 종종 봤다

결론

웹애플리케이션의 트렌드가 Servlet/JSP 처럼 비즈니스 로직과 같이 패키징 되는 형태에서 UI X-Internet 클라이언트 형식으로 구현되고, HTTP를 통해서 서버에 있는 비즈니스 로직을 호출하는 형태로 변화되고 있다.

 이런 시스템 환경 변화에서 비즈니스 로직 개발자에게는 좀더 비즈니스 로직 자체 개발에만 집중하고 기타 Cross Cutting Concern에 대해서는 공통된 BUS에서 처리하도록하고, 또한 비즈니스비 변화에 대한 유연한 대응성과, 통제(SLA) 및 모니터링을 ESB를 통해서 현실화 할 수 있다

 또한, 클라이언트 입장에서는 비즈니스 로직이 어떤 형태로 구현이 되었던간에, ESB 라는 단일 포인트를 통해서 통신하게 되고, 비즈니스 로직은 추가되는데로 ESB PLUG IN어 무제한적인 확장이 가능한 GRID 아키텍쳐를 구현할 수 있다

참고

본 문서에서는 ESB를 통한 JEE 아키텍쳐에 대한 확장 개념만을 간략하게 설명하였고, 구현 아키텍쳐에 대한 자세한 내용은 Generic Proxy Pattern 문서를 참고하기 바란다.

문제는 JMS Proxy에서는 Transaction start를 지원하지만
가장 많이 사용하는 WebService Proxy는 Global Transaction을 start하지 않기 때문에
Transactional EJB를 Composition하는 경우 분산 트렌젝션에 대한 구현 문제가 생긴다.

방법은 두가지 인데.
1) 단순하게 EJB를 하나 만들어서 ALSB(OSB)에 배포하여 Code로 Tx를 composition한후, 이 EJB를 Biz Service로 등록하고 WebService로 Expose하는 방법
2) 좀더 OSB 다운 방법은

WebService Proxy에서 JMS Q로 callout한후 JMS Proxy에서 읽어서 Tx 처리하고나서 Recv Q에 return하면 WebService Proxy에서 blocked wait하다가 response 받아서 처리하는 방식...
성능이 다소 떨어질테고, 클러스터에 고려해야할점도 있을테고, JMS Q를 관리해야 하는점, Tx Fail시 Hop이 늘어나는 점등이 풀어야할 문제이기는 한데, reference 아키텍쳐만 단단하게 만들어놓는 다면 가능할듯...

이럴때 그냥 WLI로 Service Enablement 시키고 Biz Service로 등록하면 얼마나 좋아.. ALINT가 그리워~~