엔터프라이즈 솔루션/Oracle Service Bus (ALSB)

Enterprise Service Bus를 이용한 차세대 JEE 아키텍쳐 확장

Terry Cho 2009. 6. 12. 10:20

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 문서를 참고하기 바란다.

그리드형