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


Archive»


 

'아키텍쳐 /EAI'에 해당되는 글 5

  1. 2013.02.20 Apache Camel Error Handling
  2. 2013.02.17 Apache Camel Overview
  3. 2009.07.16 EAI (Enterprise Application Integration) 추진 전략 (1)
  4. 2009.06.16 ETL vs EAI
  5. 2007.08.21 EAI 도입 전략
 

Apache Camel Error Handling

아키텍쳐 /EAI | 2013.02.20 00:54 | Posted by 조대협


Camel의 에러처리

먼저 Camel의 에러 타입에 대해서 살펴보자. 이 에러 타입은 Camel 이 아니더라도, 일반적인 integration 시나리오에서는 공통적으로 존재하는 에러 타입으로, 복구 가능한 에러와 복구 불가능한 에러가 있다.

에러의 종류

복구 가능한 에러 (Recoverable error)

복구 가능한 에러는 다시 시도 했을 경우 정상 처리 할 수 있는 에러이다. 예를 들어 순간적으로 네트워크 Connection이 끊어졌을때는 대부분, 다시 시도 하면 재처리가 가능하다.

복구 불가능한 에러 (Irrecoverable error)

복구 불가능한 에러는 내부 로직 문제나 잘못된 데이타 입력으로 인하여 다시 시도했을때에도 에러가 예상되는 에러를 복구 불가능 에러로 분리한다.

Camel에서 수신 컴포넌트에서부터 전달되는 메세지는 org.apache.camel.Exchange라는 클래스를 이용해서 전달이 되는데, 에러가 발생하면, 이 클래스에 에러를 Binding 시킬 수 있다. 에러 처리는 Camel Route 흐름에 따라서 Channel이라는 단계에서 처리된다. (Channel의 개념은 뒤에서 설명)

Recoverable 에러의 경우에는 Throwable이나 Exception 으로 정의하고, Exchange.setException() 메서드를 통해서 바인딩 한다.

Irrecoverable 에러의 경우에는

Message msg = Exchange.getOut();

msg.setFault(true)

로 설정해주면, 이 에러는 irrecoverable 에러로 정의된다이렇게 발생된 에러는 어떻게 처리 될까? 에러 처리 정책을 결정하는 ErrorHandler에 정의된 정책에 따라서 처리 된다.

ErrorHandler

어떻게 Error 가 처리 되는지를 설명하기 위해서 앞서 설명했던 Camel Route 흐름을 조금 더 자세하게 살펴보자




Camel은 앞서도 설명하였지만, 메세지를 수신 받는 Component, 이를 처리하는 Processor 그리고, 수신 시스템으로 송신하는 Component로 구성이 된다. 이 세 요소 사이에 메세지가 흘러가는데, 이 각각의 구간을 Channel이라고 정의한다. Channel은 단순히 논리적인 구간만이 아니라, 메세지가 흘러가는 길목으로 이 부분을 통해서 에러 처리나 모니터링 등의 (injection과 같은) 작업을 수행할 수 있다. 즉 에러 처리가 여기서 발생한다

에러가 발생하면, 에러는 전단계의 Channel로 넘어가게 되고, 정의된 ErrorHandler의 정책에 따라서 에러가 처리 된다. 즉 위의 그림에서 Processor에서 에러가 발생하면, Exception[1] Channel 부분으로 넘어가게 되고, 정의된 ErrorHandler에 의해서 처리된다. 마찬가지로 (Outbound) Component에서 에러가 발생하면 [2] Channel로 넘어가서 여기서 에러가 처리된다.

그러면 실제로 에러를 처리 하는 ErrorHandler를 살펴보자. Camel은 크게 5개의 Error Handler를 가지고 있다.


(1) DefaultErrorHandler

가장 일반적으로 사용되는 ErrorHandler이다. DefaultErrorHandler의 경우 에러가 발생하면, 앞단계로 Error Propagation한다.

, Processor에서 에러가 발생하면 앞단계의 Inbound Component Error propagte하고 Route process를 끝낸다. Inbound Component의 경우 내부적으로 자체 Error 처리 로직을 가지고 있는 경우가 있다. (File,FTP,DB Component의 경우) 이 컴포넌트들은 에러를 받으면 에러 처리를 한 후에 Route를 종료 시킨다.

만약 특정 에러가 발생하였을 때, Route를 정지 시키지 않고 진행을 하고 싶다면, Error 처리를 한 후에 뒤로 진행하도록 할 수 있다.

다음 코드를 보자

from(“src:start)
 .process(new MyProcessor())
 .to(“des:end”);

 

onException(StepBackException.class).log(“error sent back to caller”);

onException(HandledErrorException.class).handled(true).setBody(constant(“error handled”)).to(“des:errorhandle)

onException(IgnoreErrorException.class).continue(true);

 

이 코드는 별도의 ErrorHandler를 지정하지 않았기 때문에, Default Handler로 작동하고,

StepBackException 이 발생하면 앞단계로 Error propagate하고 Route를 종료한다.

HandledErrorException이 발생하면 handled(true)를 세팅하였기 때문에, setBody~ 부터의 흐름을 진행하여, des:errorhandle로 메세지를 전달한다.

IgnoreErrorException 이 발생하면, continue(true)에 의해서 에러를 무시하고 to(des:end)를 그대로 진행한다.

 

(2) DeadLetterChannel

Error가 발생되었을때, DeadLetterChannel로 메세지를 전송한다. 일반적으로 Message Queue 메카니즘을 사용할때 쓰는 일종의 ErrorQueue로 생각하면 된다.

RouterBuilder Class에서

public void configure(){

 errorHandler(deadLetterChannel("jms:queue:error_queue"));

 from(…)…

 to(…)..

}

와 같이 정의 해놓으면, 에러가 발생하였을때, 메세지를 JMS error_queue로 전송한다.

 

(3) LogErrorHandler

에러가 발생하였을 때, 설정된 Log4J등의 Logger를 통해서 에러를 출력한다.

그 외에 TransactionErrorHandler NoErrorHandler 등이 있다.

ErrorHandler들은 CamelContext에 적용하여 Context binding된 전체 Route들에 적용할 수도 있고, 또는 개개별 Route에만 적용할 수 도 있다.

에러의 재처리

DefaultErrorHandler의 경우, 에러가 발생하였을때, 재처리를 하도록 설정할 수 있다.

errorHandler(defaultErrorHandler().maximumRedeliveries(5))

로 지정하면 5 Retry를 하게 된다. 물론, retry 간격등이나, retry logging 등 다양한 옵션을 지정할 수 있다.

http://camel.apache.org/redeliverypolicy.html


참고 : Apache Camel 소개 -http://bcho.tistory.com/715


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (1) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21

Apache Camel Overview

아키텍쳐 /EAI | 2013.02.17 00:43 | Posted by 조대협

조대협 (http://bcho.tistory.com)

서문

예전 BEA나 오라클 시절에, EAI, ESB 등을 가지고 시스템간의 연계 업무를 많이 해왔던 나로써는 오픈 소스 기반의 EAI 프레임웍인 Apache Camel의 경우 상당히 흥미로운 주제였다. 과연 상용 제품 대비 얼마나 현실성있는 integration 기능을 제공할 것인가? 가 가장 큰 궁금증이었다.

BEA WebLogic EAI, Oracle Service Bus, AIA 등 여러 제품을 이용해서 직접 시스템간의 연계 시나리오도 구현해보고, BMT에서 타의 솔루션을 테스트도 해봤지만, 먼저 상용 솔루션의 약점은, 솔루션에서 제공하는 시스템간의 연계에 있어서 성능적인 제약이 매우 많이 따른 다는 것이다. 대부분 Message Queue 구조의 비동기 구조를 통해서, 양단간에 데이타 연계를 하는 시나리오가 많은데, 이 경우 비주얼하게 각 단계에 대해서 모니터링은 가능 하지만, 대규모 처리에 있어서 비동기의 약점 때문에 성능적인 제약이 따르고 특히 대규모 메세지 처리에 있어서 그리 매끄럽지 못했던 경험이 있다. BPEL과 같은 제품의 경우 양단간의 연동 시나리오중, 개개별 메세지를 콘솔을 통해서 트레이스할 수 있는데, 하루에 수백,수천건을 연계하는 거래의 경우에는 GUI 콘솔을 통해서 메세지를 전달 내용이나 에러 내용을 추적한다는 것은 애초 부터 불가능한 일이다.

 그래서 실제 프로젝트 때에는 송수신 시스템을 연동하는 양쪽의 아답터 (JMS, 메인프레임, TP 모니터, ERP, CRM 등 다양한 시스템과 연동이 필요하기 때문에, 상용 제품에서 지원되는 아답터는 매우 중요하다)와 기본적인 메세지 플로우 이외의 부분은 대부분 직접 구현하였다. 그래서, EAI와 같은 제품에서 필요한 구조와 이런 것을 요구 사항에 맞게 빠르게 만들었으면 하는 프레임웍이 있었으면 했는데, Apache Camel을 보니, EAI와 같은 연계 업무성 프레임웍으로 적합해 보인다.

Apache Camel의 특징을 보면

Message Integration Framework

Camel은 기본적으로 Message Integration Framework이다. Framework임을 강조하는 것은, ESB EAI 제품과 같은 솔루션이라기 보다는 이를 개발하기 위한 Framework으로 보는 것이 적절하다고 판단된다.

이유는 ESB EAI는 메세지 연동 기능을 수행하기 위한 컨테이너가 있다. (즉 서버가 있다) 아무런 연동 인터페이스가 없더라도, 연동 인터페이스를 수용할 수 있는 컨테이너가 있고, 이 컨테이너들은 모니터링, 로깅등의 관리 기능을 제공한다. 그러나 CamelLibrary이다. 자체적으로 Container를 가지고 있지 않다. 다만, OSGI 컨테이너나 WAS, Spring등에 탑재 되서 돌아갈 수 있다. 쉽게 이야기 하면, EAI ESB와 같은 솔루션 제품은 서버를 설치해야 하고, 서버 관리를 위한 관리 콘솔 UI를 제공한다. Camel Jar로 된 라이브러리 이다.

상용 제품 연계에는 적절하지 않다.

Camel을 보면, 타 솔루션을 연동하기 위한 아답터, (Camel에서는 Component라고 부른다)가 있다. 50여개의 아답터가 있기는 하지만, 기업에서 많이 사용되는 솔루션의 아답터는 턱없이 부족하다. 예를 들어 SAP ERP, Sieble CRM, Tuxedo, AS/400 과 같은 애플리케이션에 대한 아답터 지원이 없다. 상용 제품의 경우 이런 아답터 지원이 강력하다.

반면, DB,FTP,HTTP,JMS와 같이 일반적인 애플리케이션 개발에 사용되는 기술에 대한 아답터는 많이 제공된다.

Apache Camel의 컨셉

Apache Camel의 컨셉을 대략적으로 도식화 해보면 다음과 같다.


Route

먼저 Route 라는 개념을 이해해야 하는데, Route하나의 시스템간의 연동 인터페이스를 정의한다. 예를 들어 시스템 A에서 B로 웹서비스를 이용해서 연동을 했다면 이것이 하나의 Route가 된다. Route 1:1 관계뿐만 아니라 1:N의 관계도 지원 하는데, A 시스템에서 B 시스템으로 JMS로 메세지를 보내고, 그후에 C 시스템으로 FTP 파일 전송하는 인터페이스가 있다면, 이 역시 하나의 Route로 정의할 수 있다.

Component

Route는 크게 Component Processor로 정의 된다. 연계 하고자 하는 송신 시스템과 수신 시스템이 있을때, 각 송신,수신 시스템의 주소(IP) end point라고 정의하며, Component는 일종의 아답터의 개념으로, 송수신 시스템의 프로토콜에 맞는 컴포넌트를 선택해야 한다. 예를 들어 송신 시스템을 FTP로 연동하고 싶다면, FTP 컴포넌트를 , JDBC로 연동하고 싶다면, JDBC 컴포넌트를 사용해야 한다. 컴포넌트는 송신 시스템으로 부터 메세지를 읽어드리고, 수신 시스템으로 메세지를 전송하는 역할을 한다.

Processor

메세지를 읽고 그냥 보내기만 한다면 별 문제가 없겠지만, 시스템간의 연동에는 메세지를 받은 후에 수신 시스템으로 보내기전에 하다못해 로깅을 남기더라도 무엇인가 항상 처리를 한다. 이렇게 송신 시스템으로 부터 받은 메세지를 수신 시스템에 보내기전에 무엇인가 처리를 하는 부분을 Processor라고 하는데, Processor는 그 특징에 따라서 몇가지로 나뉘어 질 수 있다.

1. Message Transformation

Message Format Transformation

메세지의 포맷을 변경하는 작업을 수행한다. 예를 들어 JSON으로 들어온 데이타를 XML로 변경하는 것들이 이에 해당한다.

Message Type Transformation

메세지의 데이타 타입을 변경한다. String으로 들어온 메세지를 jms:TextMessageType으로 변경하는 등의 작업을 수행한다.

이러한 메세지 변환은 Java Class를 정의해서할 수 있으며, 이외에도 Camel에서 미리 제공되는 Converter, XSLT를 이용한 변환 Apache Velocity의 같은 Template 엔진등 다양한 방법을 이용해서 변환이 가능하다.

2. Routing

메세지 라우팅은 들어온 메세지를 다수의 수신 시스템에 조건에 따라서 라우팅할 수 있는 기능이다.


Processor 단계는 쉽게 생각하면, 메세지를 받은 후, 보내기전에 무엇인가.. 를 하는 곳이다. 앞서 설명한것처럼, 메세지를 변환하거나, 라우팅할 수 도 있고, 로깅을 할 수도 있다. 들어온 메세지에 대해서 유효성 검증을 할 수 도 있다. 이러한 Processor는 자주 사용되는 메세지 변환등의 패턴은 Camel에 의해서 제공되지만, Java 클래스를 구현하면, 무엇이든지 가능하기 때문에 메세지에 대한 거의 모든 처리를 구현할 수 있는 단계이다.

 

이렇게, “송신 Component à Processor à 수신 Component”로 하나의 Route가 정의되는데, 이렇게 Route를 정의하여 객체화 시키는 것이 RouteBuilder이다. 이렇게 RouteBuilder에 의해서 생성된 Route CamelContext에 바인딩이 된다. CamelContext SpringContext와 유사한 개념으로 생각하면 된다. Route에 대한 집합이며, Route에 대한 라이플 사이클 (Start up,Stop)등을 관리한다.

간단한 개발 예제

이쯤에서 간단한 예제를 하나 보자. 다음은 FTP로 원격지 디렉토리의 파일을 읽어서 Local Directory에 쓰는 Camel Application이다.

먼저 Maven을 이용해서 다음과 같이 Camel Project를 만든 후에,

mvn archetype:create -DarchetypeGroupId=org.apache.camel.archetypes -DarchetypeArtifactId=camel-archetype-java -DarchetypeVersion=2.5.0 -DgroupId=camelinaction -DartifactId=order-router

다음과 같은 코드를 구현한다.

public class MyRouteBuilder extends RouteBuilder {

    public static void main(String... args) throws Exception {

        Main.main(args);

    }



    public void configure() {

        from("ftp://userid@168.1.2.3/camel/src/?password=password&stepwise=false")

         .to("file:c:/temp/");

 

    }

}

위의 코드는 RouteBuilder를 구현한 코드로 configure 메서드에서 FTP로 파일을 읽어와서 Local에 저장하는 route를 정의한 예이다.

DSL

눈치가 빠른 사람이라면, 위의 코드가 몬가 이상하다는 것을 느꼈을지도 모르겠다. configure 메서드안에 from(“….”).to(“….”).??

함수().함수() 호출? Java에서 이런 문법이 있었던가?

정확히 이야기 하면 이건 일반적인 Java Coding이 아니라 DSL (Domain Specific Language)이다. DSL은 특수목적으로 정의된 언어를 이야기 하는데, 여기서 사용된 Java DSL Route를 효율적으로 정의하기 위해서 Camel에 정의된 내장 스크립트 언어이다.

JavaDSL을 이용하면 상당히 쉽게 Route를 구성할 수 있는데, Camel은 이 Java DSL 뿐만 아니라, 다음과 같이 상당히 다양한 DSL을 제공한다.

Ÿ   Spring XML : XML 기반으로 정의된 DSL , Spring xml configuration 파일에 정의

Ÿ   Groovy,Scala DSL : Groovy 언어, Scala 언어 기반의 DSL

Ÿ   Annotation DSL : Java Annotation 기반의 DSL

Ÿ   기타 (Kotlin DSL, Bluprint XML etc)

(참고: http://camel.apache.org/dsl.html)

DSL Route Processor 부분을 정의하는데 주로 사용되는데, 송수신, Component만 정의되면, 사실상 시스템 연계에서 구현해야 되는 부분은 거의 Processor이며, Processor의 로직 대부분은 메세지 처리, 변환,라우팅에 해당하는 내용이기 때문에 특수목적의 DSL을 사용할 수 있으며, 또한 DSL 사용을 통해서 개발 생산성이나 코드양을 획기적으로 줄일 수 있다.

예를 메세지를 스트링으로 받아서 reverse하여, 화면에 출력하는 경우 Java DSL을 이용하면

from("direct:test")

      .transform(new Expression() {

         @Override

         public Object evaluate(Exchange e) {

            return new StringBuffer(e.getIn().getBody().toString()).reverse().toString();

         }

      })

      .process(new Processor() {

         @Override

         public void process(Exchange e) {

           System.out.println(e.getIn().getBody());

         }

      });

인데 반해서, Groovy DSL을 사용하면

from('direct:test')

      .transform { it.in.body.reverse() }

      .process { println it.in.body }

같이 단지 3줄이면 간단하게 끝난다.

Camel EIP

시스템 연동에는 사실 많은 패턴들이 있다. 메세지 변환, 라우팅, 로그 추적을 위한 글로벌 트렌젝션 ID, 장애시 재처리등등 여러가지 방법이 있는데, 이를 패턴화 시켜놓은 것이 Enterprise Integration Pattern (EIP)이다. EIP


책에 잘 정의 되어 있으니 참고하기 바란다.

사실 Camel에서 반영 및 설계되어 있는 EIP도 이 책에 있는 내용을 대부분 바탕으로 하여 구현되어 있다. (Camel을 쓸려면 이책은 꼭 한번 읽어봐야 하지 않을까 싶다.)

 

참고 : http://camel.apache.org/enterprise-integration-patterns.html 에 간단하게 대표적인 EIP 들이 정리되어 있다.

상용 지원

오픈소스가 무료이라서 저 비용의 장점을 가지고 있지만, 반대로, 오픈소스는 기술지원이나 교육 부분에서 매우 취약하다. 그래서 RedHat과 같이 오픈소스 제품에 대해서 subscription base로 기술 지원이나 교육 및 컨설팅을 제공하는 회사들이 존재하는데, Apache Camel 역시 http://fusesource.com/ 는 곳에서 상용 기술 지원을 받을 수 있다. (얼마전에 Redhat에 인수되었다.) Fuse Source의 경우, Camel을 이용하여 제품을 만들어서 판매하고 있으며, Camel 프로젝트에 참여하고 있는 Commiter 들을 많이 보유하고 있다고 한다.

http://fusesource.com/products/enterprise-camel/ 들어가면 Fuse Source에서 개발 및 판매하는 상용 Camel을 다운로드 받을 수 있으며, 개발 관련 및 트레이닝 자료들을 살펴볼 수 있다.

결론

짧은 시간내에 살펴본 제품이라서 아직 완벽한 특성은 파악하지는 못했다. 그러나 EAI, ESB와 같이 메세지 기반의 연동 처리를 하기 위한 시스템을 개발한다면, 개발 프레임웍으로 충분히 활용할만 하다. 특히 엔터프라이즈의 특정 애플리케이션 (ERP,CRM)등이 아니라 일반적인 프로토콜 (HTTP,JMS,TCP)등을 사용하여 그리 복잡하지 않으면서 고속의 연동 처리를 필요로 한다면 아주 유용하게 사용할 수 있을 것이라 판단된다.

시간 관계상 에러처리, 모니터링, 배포 및 확장성등 운영 관점에 대한 부분은 깊게 살펴보지 못했지만, 그냥 개발 프레임웍으로 본다면, 어짜피 운영 관련 부분은 직접 구현해야 하니까는 괜찮지 않을까 싶다.

다만 단순히 프레임웍이기 때문에, 클러스터링 기반의 HA나 부하 분산등의 기능을 제공하지 않는 것이 아쉬운 점이다.

시스템간의 연동의 중요성과 편이성을 경험한 나한테는, Apache Camel물건은 물건이다.” 라는 결론이 적절하다고나 할까?

 

ErrorHandling - http://bcho.tistory.com/716


참고:ErrorHandling에 대한 관련글 -

http://www.consulting-notes.com/2010/08/camel-exception-handling-overview.html 

정리가 잘되어 있네...

 

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (1) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21

EAI 프로젝트 추진 전략

2009-07-16
Oracle Korea / Principal Consultant
Byungwook Cho. (byungwook.cho@oracle.com)

 

EAI는 수년전에 소개된 이후로도 아직까지 국내 기업 시스템에서 신규 프로젝트가 발생되고 있고 업무에서 중요하게 사용되고 있는 시스템중의 하나이다. 본 문서에서는 EAI 프로젝트를 진행함에 있어서 필요한 중요 사항에 대해서 간단하게 정리하여 EAI 프로젝트의 성공적인 수행 전략에 대해서 설명하고자 한다

EAI 프로젝트의 접근 방법

EAI 프로젝트를 성공적으로 수행하기 위해서는 크게 EAI 4가지 관점에서 접근할 필요가 있다.


Business Requirement

제일 먼저 기업에서 EAI 시스템이 가져야할 요구사항이다. 어떤 시스템과 인터페이스를 할것인지, 거래에 대한 추적과 장애 처리를 어떻게 할것인지, 목표 성능은 어느정도 인지 그리고 어떤 시나리오에 따라 시스템들이 통신을 할것인지와 같이  EAI 시스템이 실제적으로 가져야하는 기능적/비기능적 요구 사항이다

Architecture

EAI라고 해서 모두 똑 같은 설계와 아키텍쳐를 가지는 것이 아니다. 앞에서 정의한 요구 사항에 따라서 그 아키텍쳐가 변경이 된다.  아키텍쳐는 EAI 시스템의 요구사항을 구현에 반영하는 중요한 블루프린트가 된다

Process

EAI 프로젝트의 가장 큰 특징중 하나는, EAI의 기본 목적이라는 게 다른 시스템과의 연동이기 때문에, 타 팀과의 Communication이 매우 많다는 것이다. 인터페이스(이하 IF)연계에 대한 서로 요건을 맞추고 테스트를 하고 변경 사항을 반영해야 하는 일이 많고 IF의 수도 보통 300~400개는 기본적으로 넘어버리기 때문에, IF에 대한 연계 방식을 협의하고 개발 및 배포하는 프로세스를 관리하는 것이 매우 중요하다

Development / Production Environment

마지막으로 개발 및 운영 환경에 대한 고려가 필요한데, 앞서 Process에서도 설명했듯이, 타팀과의 IF가 중요하기 때문에, 개발에서 완료된 IF EAI와 연동하는 시스템을 개발하는 팀이 자유롭게 사용할 수 있어야 한다. EAI 자체의 개발환경과 타팀을 위한 개발 환경이 존재해야 하고, 특히나 대외거래(B2B)의 경우 물리적으로 폐쇄망 (X.25와 같이 기업과 기업을 연결하는 독립적인 회선)이 존재하기 때문에, 개발 및 운영 환경을 어떻게 설계하고 환경간의 이행을 어떻게 해야 하는 가에 대한 고려가 필요하게 된다

간략하게 EAI 프로젝트를 수행하는 관점에 대해서 살펴보았다.  지금부터 각각의 관점에 대해서 자세하게 설명하도록 한다

첫번째 관점 Business Requirement

EAI가 기업 업무에서 무엇을 할것인가? 에 대한 정의이다EAI의 거래 업무 타입은 아래 그림과 같이 크게 3가지 패턴으로 정의 될 수 있다.


대내 거래는 기업 내부 시스템간의 업무를 통합하는 패턴이다. 대부분 온라인성 업무가 주류를 이루게 된다. 인터넷 뱅킹에서 계좌 정보를 조회해온다던지, 당행 계좌간 이체를 한다던지와 같은 실시간성 거래가 주류를 이룬다

대외 거래는 기업간의 거래를 정의한다. 계열사로 재무 내역을 전송하거나 전송 받거나, 협력 업체에 물품을 주문한다거나와 같은 업무가 주류를 이루며, 온라인성 업무와 디퍼드거래 그리고 배치성 거래들이 섞여서 구성된다. 대외 거래의 특징은 기업간 거래이기 때문에 분산 트렌젝션(XA)등을 이용한 트렌젝션 보장이 불가능하기 때문에 오류시 양쪽의 트렌젝션정보를 비교할 수 있는 거래로그를 저장하는 것이 중요하다.

또 다른 관점에서는 B2B 거래에 있어서는 별도의 한정된 개수의 폐쇄망(X.25, TCP)을 사용하는 경우가 있기 때문에, 회선이 1~2개 인데, 서버가 >2 일 경우 회선이 연결된 서버로 거래 요청을 라우팅 하는 기능과 회선의 상태를 확인하는 기능등이 중요하다

BATCH거래는 대용량의 데이터를 송신 시스템에서 수신 시스템으로 전송하는 요건인데, 다른 업무 시스템간의 거래 정보를 맞추기 위한 BATCH거래와 정보계(데이터를 분석하여 경영에 필요한 리포트를 뽑아 내는 Warehouse BI성의 업무) 두 가지 형태로 분리된다. 전자의 경우 운영 데이타로 사용되는 데이터에 대한 연계이기 때문에, 전달 보장 요건이 매우 중요하고(경우에 따라 XA를 사용할 수도 있음) 후자의 경우는 분석 데이터이기 때문에 전달 보장 요건은 그리 중요하지 않다.

 BATCH거래의 경우 보통 ETL 솔루션을 사용하기도 하는데, ETL 솔루션의 경우 XA기반의 전달 보장 요건이 없기 때문에, 위의 사례중의 후자 (정보계)에는 적절하지만 운영 데이터를 전송하는 과정에는 EAI 솔루션이 더 적절하다고 볼 수 있다

간략하게나마 기업 내부에서 EAI의 업무 요건에 대해서 살펴보았다.

사실 이외에도 MEP (Message Exchange Pattern) – 온라인성의 경우 SYNC,ASYN, 1:N,N:1 거래에 대한 정의와 BATCH성의 경우 Master-Detail, Merge & Insert등 여러가지 거래 패턴이 존재하며 필요한 거래 패턴에 대한 정의도 이 단계에서 이루어져야 한다.

그외에, EAI의 인프라성 기능 거래 추적, 모니터링 배포 등의 요구 사항도 함께 정의 되어야 한다.

 두번째 관점 EAI 개발 프로세스

두번째 관점은 실제 EAI 프로젝트를 수행하는데 있어서의 프로세스이다.

전통적인 Water-Fall 모델 관점에서 봤을 때, 각 단계 별로 EAI 프로젝트에서 필수적으로 수행해야 하는 작업들은 다음과 같다.


Analysis 단계

분석단계에서는 기업내에서 EAI가 무엇을 할것인가? 를 정의한다.

(1)    인터페이스 타입 정의

인터페이스 타입 정의란, 어떤 업무 시스템들과 연동을 할것인지, 그리고 해당 시스템의 기술적인 인터페이스 타입은 무엇인지(Tuxedo,EJB,Socket,WebService,MQ etc)를 조사하고 서로 협의한다. 이때 XA 지원 인터페이스도 정의한다.

(2)    메시지 패턴 정의

인터페이스를 할 시스템들이 정의되었으면 어떤 방식으로 인터페이스를 할지를 정의한다. 이를 MEP라고 한다. SYNC 방식인지, 1:N으로 분할 거래를 할것인지, ASYNC 방식인지, 디퍼드인지 각 업무별로 연계하는 방식에 대해 정의한다.

(3)    인터페이스 전문 정의

어떤 업무 시스템과 어떤 방법으로 연계할지가 정해지면 실제로 왔다 갔다 하는 메시지(전문)에 대한 포맷을 정의한다. XML로 할것인지, TEXT로 할것인지 헤더에는 어떤 데이터데 들어갈것인지, 메시지 ID는 어떻게 정의할것인지등에 대한 정의를 한다.

분석단계가 끝나면 EAI 시스템이 갖추어야 할 모양과 어떤 업무 시스템간을 어떻게 연동할것인지가 정의된다.

Design 단계

EAI 시스템의 요구 사항이 나오면 디자인 단계에서는 실제 인터페이스별로 아키텍쳐 디자인을 수행한다.

(1)   프로토타입 제작

EAI는 시스템의 특성상 기능적인 면(시스템간 연계) 보다 중요한 것이 비기능적인 요건이다. 시스템간의 연계를 주요 목적으로 하다보니, 거래 데이터의 전달 보장과 장애시에 거래 유실을 방지하는 아키텍쳐가 필요하다. 이를 위해서 디자인 초기에 요건이 나온 인터페이스 연계 타입에 대해서 프로토 타입을 구현을 해서 정상적으로 작동하는지 다른 RISK 요인은 없는지 검증을 하고 현업과 연동을 해봄으로써 현업과 연계 시나리오에 대한 동일한 VIEW를 가지도록 한다.

(2)   프로토타입 검증

프로토 타입이 완성되면 해당 프로토 타입에 대한 검증을 한다. 대부분 Micro Benchmark 테스트 형식으로, 시스템 장애에 대한 장애 발견,원인분석,복구 기능을 검증하고, 장기간 거래에 대한 안정성 성능을 측정하여 시스템에 대한 기초 데이터를 마련한다.

(3)   IF 리스트 수집

프로토 타입에 의해서 검증된 아키텍쳐를 기반으로 현업에서부터 실제 연계 IF 목록을 수집하고 개발 일정을 수립한다. 현업의 시스템 개발과 연계 일정에 대해 의존성을 가지기 때문에, 이 과정에서 자세한 인터페이스 방식과 스케쥴을 정의한다.

디자인 단계에서 가장 중요한 것은 주요 인터페이스 패턴 별로 프로토타입을 개발하고 검증을 하는 것이다. 검증된 프로토 타입을 가지고 실제 구현단계에서는 붕어빵(?) 찍어내듯이 같은 패턴으로 정해진 스케쥴에 따라서 인터페이스를 구현해주게 된다

프로토 타입의 중요성은 비기능적 요건의 경우 시스템의 코어 아키텍쳐와 깊게 연관이 되는 경우가 많고, 인터페이스 연계가 끝난 후에 비기능적인 요건에 문제가 있을 경우, 기존에 구현된 인터페이스를 수정하는데 많은 노력을 필요로 한다. 특히 EAI 프로젝트 특성상 타 업무팀과의 협의를 요하고 인터페이스 변경은 그 타업무팀에 새로운 작업을 요구하기 때문에 커뮤니케이션상의 많은 부담과 책임을 가지고 갈 수 있기 때문에, 요건이 정리된 후 되도록이면 빠르게 아키텍쳐를 프로토타입핑을 통해서 검증하는 것이 중요하다

Implementation 단계

구현 단계에서는 실제 스케쥴에 맞춰서 인터페이스를 연계 하고, 이를 개발이나 STAGING환경으로 이행하면서 연계에 있어서 오류가 있는 부분을 수정한다

(1)   인터페이스 연계

구현단계에서는 일정에 맞춰서 인터페이스를 연계한다. 이때 필히 테스트환경을 구축하여 인터페이스 구축시 마다 인터페이스에 대한 테스트를 수행해야 한다.

(2)   단계적 이행

EAI 개발시스템에서 개발된 인터페이스는 EAI STAGING 시스템으로 개발된다. EAI STAGING 시스템에는 업무 시스템에 대한 개발 시스템이 연동이 되어 있는데. EAI 개발 시스템에 연동을 하지 않는 이유는 개발 시스템에서는 잦은 RESTART와 디버깅등이 개발팀에서 이루어지기 때문에 이에 대한 영향을 타 업무 개발팀에 끼치지 않도록 하기 위함이다. STAGING으로 이행을 할때는 정해진 인터페이스 개발 스케쥴에 맞춰서 이행하여 업무 개발팀이 원할하게 업무 개발을 할 수 있도록 한다.

EAI 프로젝트 과정중에는 많은 이행단계가 있다. 개발,통합테스트,운영 시스템으로의 이행등 많은 과정을 거치는데, EAI 이행의 경우 EAI 시스템만 옮기면 되는 것이 아니라 업무와의 연결 포인트가 변경될 수 있고, 특히 B2B 거래의 경우 실제 회선을 물리적으로 이행을 해야할 경우가 있기 때문에, 이행에 대해서 일반 애플리케이션보다 정교한 계획이 필요하다.

(3)   모니터링 및 수정

EAI 프로젝트에서 인터페이스를 연계해놓고 나면 문제가 예상하지 못했던 인터페이스 에러나, 요건 수정이 발생한다. STAGING 시스템에서 이를 모니터링해서 에러를 수정하고 이에 대한 보강 아키텍쳐를 수립하여 반영하는 반복적인 절차가 필요하고, 인터페이스 요건 변경에 대한 반영역시 필요하다. 소프트웨어 개발 프로젝트의 특성상 요건에 대한 변경을 발생할 수 있으나, 거래 인터페이스 타입의 변경 (대상 시스템 타입이 바뀌거나, MEP 자체가 변경되는)은 발생해서는 안되며, 피치못하게 발생했을 경우 변경된 요건에 대한 아키텍쳐 영향도를 분석(프로토 타입핑을 통해서)후에 결정을 해야 완성된 EAI시스템의 안정성에도 문제가 없게 된다

EAI 프로젝트에서 구현 단계에서는 특히 현업의 요건 변경과, 현업의 인터페이스 미 준비등이 가장 큰 이슈가 된다. 스케쥴에 맞게 준비를 하지 않거나 인터페이스 표준을 따르지 않다가 통합 테스트등 프로젝트 마지막 단계에서 갑자기 몰아서 하면서 많은 문제를 만들어내거나, EAI팀이 인터페이스 연계가 늦어져서 업무 개발이 늦어진다는 변명 아닌 변명이 많은 것이  EAI 프로젝트의 특성이다

이를 방지하기 위해서는 구현단계에서 스케쥴에 맞춰서 인터페이스를 연동해주고, 장애나 문제가 있는 상황을 바로바로 로깅하여 백데이타를 확보하고 인터페이스 연계 지연이나 장애 목록에 대해서는 PMO (프로젝트 관리조직)을 통해서 리포팅하여 나중에 있을 수 있는 논쟁의 여지를 방지할 필요가 있다

세번째 관점. EAI 레퍼런스 아키텍쳐

많은 EAI 상용 EAI 솔루션들이 있지만 이러한 솔루션들은 프레임웍만 제공할뿐 실제 연계 아키텍쳐는 그 프레임웍을 기반으로 따로 설계해야 하는 경우가 보편적이다. 여기서는 EAI시스템이 갖추어야 할 요건에 대해서 통상적인 아키텍쳐를 소개하고자 한다


인터페이스

인터페이스 모듈은 EAI의 가장 기본적인 아키텍쳐 모듈로 송수신 시스템을 통합 시키는 부분에 대한 아키텍쳐이다.

(1)  Inbound

Inbound는 송신 시스템과 연동되어 요청을 받고 응답을 송신 시스템에 보내는 역할을 한다. Inbound는 크게 두가지 모듈로 구성된다.

Ÿ   Adapter

아답터는 다양한 플랫폼으로부터 메시지를 읽어드리는 Entry Point의 역할을 한다. 연동 시스템마다 각각의 아답터가 정의 되어야 한다.

Ÿ   메시지 변환

Adapter에 의해서 요청된 전문(메시지)는 각 연동 시스템의 플랫폼에 따라서 각각 다르다. FML이나 XML, 또는 TEXT형태의 전문, Binary등 여러가지 형태가 될 수 있으나, EAI내부에서 처리하기 위해서 이런 전문형태를 공통적인 데이터 구조로 변환한다. 흔히 상용 솔루션에서는 메시지 처리의 유연성을 가지고 가기 위해서 XML을 사용하고, In-House 개발의 경우 성능의 최적화를 위해서 HashTable형태의 Java POJO Object를 사용하기도 한다.

(2)  Mediation

Mediation은 입력된 메시지를 가공하고 중계하는 EAI의 핵심적인 기능 부분이다.

Ÿ   Routing

Routing은 입력된 메시지를 메시지의 내용(헤더나 인터페이스 정보)에 따라서 적절한 수신 시스템으로 Routing하는 역할을 수행한다. 이 과정은 1:1 Routing이 될 수 도 있지만 N:1, 1:N등 다양한 관계로 Routing을 수행할 수 있어야 한다.

Ÿ   Mapping

입력된 전문을 수신 시스템에서 요구하는 형태로 맵핑하는 작업을 수행한다. 필드간의 맵핑이나 간단한 메시지에 대한 변환을 수행한다.

Ÿ   MEP (Message Exchange pattern)

이부분에서 MEP에 대한 처리도 수행한다.SYNC ASYNC, 디퍼드성 거래에 대해서 JMS 와 같은 큐잉을 이용해서 MEP를 구현한다.

(3)  Outbound

Inbound와 마찬가지로 처리가 끝난 메시지를 수신 시스템의 플랫폼의 Native 메시지 형태로 변환하여 Adapter를 통해서 수신 시스템에 전달한다

모니터링 및 장애 관리

인터페이스 아키텍쳐가 가장 기본적인 연계에 관련된 아키텍쳐라면 EAI 아키텍쳐상의 매우 중요한 요소중의 하나가 거래 추적과 에러 처리 방식이다.

(1)  거래 로그

거래 로그는 EAI 시스템의 장애시 송수신 시스템과 거래 내용을 맞춰서 이를 복구하는데 사용한다. 거래 로그에 사용되는 거래 ID는 전사 표준 전문의 헤더에 정의하는 것이 일반적이고 이 거래 ID는 송신에서 수신 시스템까지 하나의 공통된 ID를 사용해야 한다.

거래 로그에 대한 접근 방식은 크게 저장 장소와 저장 방식에 대해서 고민해야 하는데,  데이터 저장 장소는 FILE DB 두가지를 선택할 수 있다. FILE의 경우 비교적 IO성능이 빠르고, DB 장애에 대해 의존성이 적다는 장점을 가지고 있지만 반대로 거래 추적을 할할 때 일일이 FILE을 뒤져야 하는 단점이 있고, DB의 경우 특정 거래를 찾거나 조건으로 검색을 하기는 용이하지만 별도의 DB하드웨어를 필요로 하고, DB 장애에 독립적이지 못한 문제를 가지고 있다

이를 보완하기 위해서 LOG WRITING하는 방식에 대해서 고려할 수 있는데, JMS 서버를 이용하여 비동기적으로 LOG WRITING하는 방법을 고려할 수 있다. 이 때 JMS의 메세지를 FILE에 저장할지 메모리에 저장할지도 고려해야 하는데, 업무상 감사(AUDIT)요건이 있는 중요한 로그는 JMS File store를 이용하여 저장하고 중요하지 않은 로그는 JMS Memory Store를 이용해서 저장하는 방법이 있다. (Memory Store의 경우 성능적 우위에 있지만, JMS 서버가 RESTART될 때 메모리상의 데이터가 유실되는 문제가 있다.) 

거래로그는 EAI의 필수적인 요건중에 하나이지만 IO를 유발하기 때문에 성능에 가장 큰 영향을 주는 부분으로 세밀한 설계와 검증 과정을 필요로 한다.

(2)  에러 처리 로직 (Error Hospital)

에러 처리 로직은 모니터링 요건과 더블어 EAI의 또다른 필수요건이다.에러 처리 로직의 요건은 장애 감지, 장애 원인 리포팅, 장애 해결 3단계로 이루어 진다.

모든 종류의 장애를 신속하게 감지해야 한다. 특히 B2B거래의 경우 회선 장애에 대한 감지 능력이 보강되어야 하고, 장애가 발생하였을 때 장애 원인을 추적할 수 있도록 그 내용이 리포팅 되어야 하고, 장애 내용에 대해서 해결할 수 있는 절차를 갖추어야 한다

장래 해결 방식은 여러가지로 분리할 수 있는데 장애에 대한 처리 정책을 Fault-Policy라 하고 인터페이스마다 정의하여 인터페이스별로 장애를 처리할 수 있도록 한다

이렇게 장애가 발견되고 리포팅이 되면 모든 장애 내용을 한곳에 모아서 위에서 언급한 Fault-Policy에 따라 처리하는데 모든 장애가 모이는 곳을 Error-Hospital이라고 정의한다

(3)  장애 처리 정책

앞에서 정의한 에러 처리 로직 (Error-Hospital)에 모인 장애 들은 장애 처리 정책에 따라서 처리가 되는데, 일반적으로 크게 아래와 같이 4가지 정책으로 정의할 수 있다.

Policy

Description

Note

Ignore

Simply ignore the fault and purge message.

 

Report

Report the fault. Optionally send notification message (Email,IM,SMS etc)

 

Retry

Automatically retry the transaction with specified time after specified sleep time

After failing all of retry, next error handling policy definition is required.

Manual

handling

Report the fault and let user select policy described above

 

무시하거나(Ignore), 장애 내용을 관리자에게 알리거나 (Report), 자동으로 재시도 하거나 (Retry), 또는 Work list등에 추가하여 관리자가 에러 처리를 수동으로 하도록 하는 방식이다.

인프라 기능

거래이외에 공통적으로, 처리해야 하는 기본적인 기능들이 있다.

(1)   트렌젝션 처리

EAI 프로젝트에서 통상적으로 10~30% XA 기반의 분산 트렌젝션 처리를 사용하는 경우가 있다. 양쪽에 거래에 대한 장애시 거래 데이터가 틀려지는 것을 방지하기 위해서 XA를 사용한다. XA 사용은 시스템의 복잡도를 높이고 높은 수준의 테스트가 필요하기 때문에, XA 거래는 되도록이면 사용하지 않는 것이 좋다.

(2)   동적 배포

EAI 시스템은 24 x 7 으로 무정지로 운영이 되기 때문에 새로운 인터페이스가 추가 되었을때 EAI 시스템을 정지하지 않고 인터페이스 배포가 가능해야 하며, 장애가 난 인터페이스가 다른 연계 인터페이스에 영향을 미치지 않도록 내릴 수 도 있어야 한다.  인터페이스에 대한 동적 배포 기능은 EAI 시스템의 운영 관점에서의 필수요소이다

네번째 관점 EAI 프로젝트 개발 환경과 이행

앞에서도 몇번 언급했던 내용인데, EAI 시스템은 개발중에도 독립적으로 개발이 불가능하고, 다른 업무 시스템과의 연관성을 가지고 개발을 하기 때문에 개발 과정중에도 업무 시스템간에 인터페이스를 해줄 수 있는 시스템이 필요하다.


이를 지원하기 위해서 크게 3가지 환경으로 나눌 수 있는데, 다음과 같다.

분류

역할

참고사항

EAI 개발 환경

EAI 개발팀만 사용, EAI 시스템 자체에 대한 개발, 인터페이스 개발

 

EAI Staging

개발된 인터페이스가 배포되는 환경. 업무 개발 시스템과 연결되어 업무 개발 환경을 지원함

 

EAI Production

실제 운영환경

 

특히 개발환경에서 Staging 환경으로는 주기적인 업데이트가 일어나야 하고, Production 환경으로 옮길때는 별도의 이행 계획을 세워서 이행을 진행한다. (회선과 서버 연결점에 대한 고려가 필요함)

개발환경과 Staging 환경은 별도로 하드웨어를 분리할 필요없이 같은 하드웨어를 공유해서 사용해도 되지만, 필수적으로 두개의 환경을 나눠서 운영하도록 한다.

 

마지막으로 국내 EAI 프로젝트의 특이성

국내에 진출을 한 몇몇 EAI 솔루션 벤더들이 있지만 이 솔루션들이 국내에서는 그리 평탄하게 프로젝트를 진행하고 있지는 않은 것으로 알고 있다. 비즈니스가 없다는 말이 아니라, 제품의 고유 기능만 가지고 국내 EAI 고객의 요구 사항을 맞추기가 어렵고 이로 인해서 Custom 개발이 많이 발생한다는 이야기다.

국내 EAI 요건은 EAI 패키지들이 제공하는 기능에 비해 훨씬 높은 편인데, 몇가지 주요 특이 사항을 나열해 보면 다음과 같다.

 

Ÿ   Config 방식의 연계 선호

전통적인 EAI 솔루션은 GUI 기반의 개발툴에서 송수신 시스템을 연결하는 인터페이스를 구현하고 이를 EAI 시스템으로 배포하는 구조이다.

국내 EAI 시스템을 운영하는 사람은 대부분 개발자적인 소양보다는 운영과 업무 관점의 인력이기 때문에, 개발 기반의 EAI 연계를 선호하지 않는다. 단순히 웹 관리 화면으로 송수신 시스템에 대한 CONFIG 정보 만으로 연동이 이루어지기를  선호하기 때문에 별도의 연계 Config 화면을 구현할 필요가 있다.

Ÿ   변환 라우팅 보다는 연계에 초점

EAI 솔루션의 특징중의 하나가 송수신 중간의 Mediation에 상당히 자유로운 비즈니스 로직을 넣을 수 있다는 것인데, 변환과 라우팅들이 그에 해당한다. 그러나 국내 EAI요건은 필드간의 맵핑이나 간단한 변환만을 사용할 뿐 EAI 개발 도구가 제공하는 복잡하고 강력한 맵핑이나 라우팅은 사용하지 않는다.

Ÿ   높은 성능 요구치

국내 기업의 경우 고객과 기업의 IT 인프라가 상당한 수준으로 발전해 있기 때문에, 시스템에 대한 응답시간에 대한 기대치도 높고 많은 업무가 이미 온라인으로 처리되기 때문에, 초당 트렌젝션양(TPS)에 대한 요구 수준도 매우 높다. 그래서 변환이나 라우팅 같은 고급 기능보다는 단순한 맵핑 기능들만을 사용하면서 성능을 높이고자 하는 요구 사항이 많다.

Ÿ   비표준 전문 구조 사용

특히 대외 B2B 연계의 경우 ebXML등의 국제 표준 전문 형태를 사용하기 보다는 업체간의 협약을 맺어서 단순히 TCP 기반에 TEXT 타입으로 전문 표준을 맺어서 사용하는 경우가 많기 때문에 이 경우 전문 포멧을 핸들링하기 위한 아답터가 별도로 필요할 수 있다.

Ÿ   SOCKET 아답터

Legacy와의 연동이 WebService IIOP,RMI,EJB등의 표준 기술이 아닌 TCP Socket 기반의 연계 패턴이 종종 있다. Socket을 이용한 연동 부분은 EAI 솔루션에서 대부분 제공하지 않기 때문에, In/Out bound Socket 아답터에 대한 구현이 필요한 경우가 많다.

Ÿ   X.25 기반의 대외 연계

대외계(B2B) 거래의 경우 X.25 회선을 이용하는 경우가 아직도 많기 때문에, X.25를 지원하는 아답터가 필요하나 EAI 솔루션에서 제공하지 않는 경우가 많기 때문에 구현이 필요하다

결론

지금까지 간략하게나마 한국에서 EAI 프로젝트를 진행함에 있어서 고려해야할 몇가지 사항에 대해서 정리했다.

 국내의 EAI 환경은 시스템간의 연계 시나리오 자체는 간단하지만, 연계에 대한 비기능적인 요건 (성능이나 장애 처리)에 대한 기대치가 높고, 기술적인 난이도가 높은 시스템이 대부분이다.

 범용적으로 개발된 EAI 솔루션을 가지고 일반적인 소프트웨어 개발 프로젝트식으로 EAI 프로젝트를 수행한다면 십중팔구는 실패를 하거나 시스템의 안정성에 치명적인 결과를 가지고 오게 마련이다.

한국 EAI 시스템에 대한 고객 요구 사항을 적절하게 분석하여 EAI 솔루션 위에 한국 고객의 요건을 반영한 EAI 프레임웍의 개발과 EAI 프로젝트를 위한 개발 프로세스가 잘 정의되어야 복잡하고 난이도가 높은 한국형 EAI 프로젝트를 성공적으로 마무리 할 수 있다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (1) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21

ETL vs EAI

아키텍쳐 /EAI | 2009.06.16 18:28 | Posted by 조대협

ETL과 EAI 차이점 정리

ETL은 Dataware house나 BI와 같이 좀 덜 Mission Critical한 데이타에 사용되고, Batch등의 대량 전송에 사용함. 주로 DB 위주의 접근, 송수신 인터페이스에 대한 방향성이 있음

EAI는 애플리케이션간의 Integration이고, 단건이나 수건의 데이타에 대한 실시간 조회용 분산 트렌젝션(XA)가 중요한 요건으로 작용함. 양방향성을 띰

ETL and EAI Characteristics

ETL EAI
Focus Data Integration (Data Warehousing) Application Integration (Operational Apps)
Primary Technology Database Application
Timing Batch Real-time
Data Historical Transactional
Volume Size 
>Days or weeks of data 
>Records per min (GB)
Throughput 
>Single transactions 
>Messages/second (KB)
Integration Initiation Pull, query-driven Push, pull, event-driven
Flow Control Meta-data driven, complex data flow Business-rule driven, workflow oriented
Validation Strong data profiling and cleansing capabilities Limited data validations
Transactional Limited transaction and messaging capabilities Strong transaction control and recovery. Guaranteed message delivery with two phase commit
저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (1) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21
TAG EAI, eTL, 비교, 차이

EAI 도입 전략

아키텍쳐 /EAI | 2007.08.21 16:29 | Posted by 조대협
한국 소프트웨어 진흥원 부탁으로 써줬던 기고인데,
EAI의 도입 전략에 대해서 설명했던 글이다.

==

Introduction strategy of EAI

 

2006 7 5

자바스터디 네트워크 (http://www.javastudy.co.kr)

 조대협 (bcho@bea.com)

 

1. EAI 가 필요한가?

 

전통적으로 기업의 애플리케이션들의 개발은 각 부서의 업무나 특정 업무의 요구 사항에 맞춰서 필요한 시기에 전사적인 기업 업무나 기존의 IT 시스템에 대한 고려 없이 독립적으로 개발되었다.

  , 고객 관리를 위해서 CRM이 개발이 되었고, 경영자의 데이터 분석을 위해서 DW 시스템이 개발이 되었고, 기업 내부의 전산화를 위해 그룹 웨어가 개발이 되었다.

 이런 각각의 애플리케이션의 개발은 개발 당시의 적합한 기술(?) 또는 주류가 되는 기술에 의해서 개발이 되었고 결과적으로 기업의 애플리케이션들은 각기 다른 기술로 구축이 되고, 데이터 또는 기능상의 불필요한 중복을 야기하게 되었다.

특히 1980년대를 거쳐 1990년에 이르기 까지, 메인프레임에서부터 C/S환경 인터넷 환경까지의 급격한 기술 변화를 거치면서, IT 시스템들의 플랫폼은 점점 더 다양화 되게 되었다.

 이로 인해서 점점 거대해지고 다양화된 IT 시스템에 대한 유지보수 및 중복 개발로 인한 비용이 증대하게 되었고, 이는 기업 시스템 운영의 하나의 문제점으로 대두 되게 된다.

 

이 시기에 경영자들은 각 부서간 협업과 업무 프로세스 개선을 통해서 기업의 전략을 신속하게 비즈니스에 반영하려는 시도를 하지만, 기존의 IT 시스템은 이미 독립적으로 개발이 되어서 연계성이 떨어지고, 비즈니스 요구 사항을 IT 시스템에 반영하려면 기존 시스템들에 대한 수정을 일일이 거쳐야 하기 때문에 민첩성이 떨어지게 되었다.

 

이런 이유로 기업의 애플리케이션들의 통합에 대한 필요성이 대두되게 된다.

 

2. EAI 의 개념

먼저 EAI의 개념에 대해서 간략하게 설명하기 위해서 간단한 예를 들어보자. 고객이 어떤 기업에 물건을 하나 주문하고, 구입하는 순서를 살펴보면 고객이 물건을 주문을 하면, 기업에서는 주문 내용을 시스템에 입력하고, 입금이 된 것을 확인한 다음에, 재고 관리 시스템을 조회해서 재고가 있는지를 체크한다. 재고가 없으면 다시 발주시스템을 통해서 협력사에 물품을 발주하고, 재고가 있으면 물류 시스템을 통해서 해당 물품을 출고 시키도록 하고 출고된 물품은 운송 추적 시스템을 통해서 고객에게 수령되기 까지 추적된다.

주문

입금확인

재고체크

출고

운송

발주

납품

수령

고객

기업

협력사

발주 시스템

주문 시스템

재고관리

물류 시스템

운송 시스템

 

 

 

 

 

 

 

 

 


< 그림 1. 주문 프로세스 예제 >

이 업무 프로세스에서 기업에서는 각기 독립된 다른 시스템에 접근해서 데이터를 입력해야 하고(주문,영업정보 etc), 때로는 중복된 데이터를 입력해야 하는 경우도 있을 것이고, 재고가 없어서 발주라도 했을 경우에는 발주자가 해당 물품이 납품이 되었는지 아닌지를 일일이 확인한 후에 출고를 시킬 수 있다.이렇게 다수의 인터페이스를 통해서 각각의 애플리케이션을 접근해야 하는 복잡성 때문에 업무의 효율이 급속하게 감소된다.

 만약에 이 각각의 시스템들이 유기적으로 결합되어 하나의 통합된 주문 처리 시스템으로 존재한다면 좀더 빠르고 신속하게 주문 이라는 업무에 대해서 대응을 할 수 있게 될것이다.

 이렇게 각기 다른 시스템을 통합해주고 유기적으로 연결 시켜주는 시스템을 EAI (Enterprise Application Integration)이라고 한다.

 

폭넓은 의미에서의 EAI는 전체 시스템 통합을 의미한다. Presentation Layer간의 통합, Application 간의 통합, Data 간의 통합을 모두 포함한 개념이지만, 현재 일반적으로 사용하는 EAI Application 간의 통합을 지칭한다. (참고: Presentation Layer간의 통합은 Enterprise Portal, Data간의 통합은 Data Integration Solution 등을 통해서 이루어 진다.)

 

3. EAI 모델과 단계별 도입 전략

 

EAI의 단계별 발전 모델로 분리했을 때 크게 3가지 모델로 분류할 수 있다.

1) P2P

가장 기본적인 형태의 EAI로 단위 애플리케이션을 1:1 로 연결한다.

기존의 전통적인 통합방법에서 가장 많이 사용한 형태로 간단한 애플리케이션간의 통합에서는 저비용으로 쉽게 구현을 할 수 있으나, 시스템의 통합 규모가 커짐에 따라서 관리상의 어려움과 함께 표준화되지 않은 인터페이스나 기술에 의한 통합이기 때문에 비용상의 문제가 함께 발생한다.

 

2) Hub & Spoke

현재 일반적으로 이야기 하는 EAI 시스템의 구조이다. EAI 솔루션이 Hub 형태로 단위 애플리케이션들을 EAI Hub에 연결하고, Hub를 통해서 애플리케이션간의 호출 및 통신을 하는 구조이다.

 중앙 집중된 Hub를 통해서 통합을 진행하기 때문에 중앙에서의 통제와 관리등이 가능하며, 중앙 Hub의 통합된 연결 인터페이스를 통해서 단위 애플리케이션의 업무간의 재사용성이 극대화 된다.

 기존에는 CORBA등의 ORB 형태의 Hub를 사용했으나, CORBA의 기술적인 난이도와, CORBA를 지원하지 않는 애플리케이션까지 통합하기 위해서 2000년대에 들어서는 전용 EAI Hub Adapter 로 조합된 형태의 EAI 제품군들을 주로 사용한다.

 

3) BPM based EAI

Hub&Spoke 방식이 애플리케이션간의 연결만을 뜻한다면, BPM Based EAI는 애플리케이션의 업무를 재배치 및 조합하여 새로운 업무를 빠르게 구현하여 비즈니스 요구사항에 빠르게 대응할 수 있는 민첩성을 제공한다.

 비즈니스의 요구가 바뀌었을 때 해당 요구에 대한 애플리케이션을 구현하기 위해서 다시 코딩을 하는 것이 아니라 비즈니스 프로세스상에서 기존 조합을 변경함으로써 요구 사항을 반영하여 빠르게 현업의 요구 사항을 IT에 반영할 수 있게 된다.

 

일반적으로 현재 EAI 솔루션은 Hub&Spoke 모델을 지칭하는 경우가 많지만 요즘에는 BPM을 포함한 EAI 모델을 지향하는 경향이 있다.

1990년대 초반에 비즈니스 프로세스의 구축을 위한 BPR (Business Process Reengineering)이 대두 되었고, 포춘선정 500개 기업이 이 BPR을 도입하였지만 대부분의 결과는 실패로 돌아갔다. 이유는 staring from scratch 즉 기존의 애플리케이션의 기능들을 재 사용하는 것이 아니라 재구축 하는 곳에서부터 시작했기 때문인데, 그에 대한 대안으로 나온 것이 BPM (Business Process Modeling)이다. BPM은 기존의 애플리케이션의 기능들을 재사용하여 단위 애플리케이션들을 업무 흐름에 맞추어서 재배치 하는 것으로 기존 업무의 재 사용을 전제로 하는 만큼, EAI의 사상과 잘 매치가 된다.

 

BPM은 업무 프로세스를 재정의하고 구성하는 만큼 IT 부서에서 뿐만이 아니라 실제적인 업무와 그 흐름을 정의하는 경영부서와 함께 진행되어야 하며 Six sigma, ISO9000같은 비니지스 프로세스의 재 정립과 함께 진행한다면 좀더 큰 효과를 기대할 수 있다..

 

기업에서 통합을 고려하고 있다면 빅뱅식의 접근 모델 보다, 3가지 발전 모델을 단계적으로 도입하는 것이 통합에서 올 수 있는 혼란이나 부작용을 최소화 할 수 있다.

 

4. 성공적인 EAI 구현을 위한 전략

 

그러면 지금부터 성공적으로 EAI 시스템을 구축하기 위한 몇가지 전략에 대해서 알아보도록 하자.

 

1) 목표와 범위

먼저 애플리케이션을 통합하고자 하는 목적을 명확하게 정의해야한다. 통합하면 좋으니까 라는 막연한 목표보다는 고객 신상 정보와 고객 매출 정보 시스템을 통합하여 고객 관리 만족도를 높이겠다. 등의 구체적인 목표를 정해야만 프로젝트의 방향이 어긋나지 않는다.

다음으로는 정해진 목표를 이루기 위한 통합의 범위를 정한다.

종종 EAI 프로젝트를 보다보면 실패하는 원인중의 하나가 초반에 정의되지 않은 범위와 목표를 벗어나는 업무를 이번에 통합하는 김에 같이 하자 라는 등의 막연한 이유로 막판에 통합에 포함 시키려는 시도를 보게 된다. 그러나 이는 처음에 설계되었던 통합의 방향을 바꿀 수 있고, 새로운 통합 대상 시스템이 들어오게 됨으로써 프로젝트의 범위를 넓혀버릴 수 있다.

 먼저 설정된 목표와 범위만큼만 통합을하고, 확장은 다음 단계의 개발에 반영하는 것이 현명하다.

 단 해당 목표를 위한 통합의 범위를 지정했음에도 불구하고, 개발중에 목표 달성을 위해서 통합의 범위가 더 추가가 필요로 되는 경우가 있는데, 이는 프로젝트의 수행을 순차적 수행 모델이 아닌 반복적 (Iterative) 수행 모델을 통해서, 각 프로젝트 Milestone 별로 feed back을 받고 적절한 통합 범위를 조정하는 것이 필수적으로 필요하다.

 

2) 기존 시스템 인식

통합을 진행하면서 통합할 시스템의 기능적과 비기능적인 요소에 대한 검토가 필요하다.

 먼저 통합에 필요한 기능이 있는지 없는지 그리고 새로 추가해야하는 기능이 있는지 없는지를 검토하고 통합에 필요한 기능적 요건을 모두 만족할 수 있는지를 검토한 후 에,

 비기능적인 요소, 즉 해당 애플리케이션의 동시 사용자수, 평균 응답시간, 장애에 대한 대응 능력 SLA,Qos 등을 체크해야 한다.(대부분 기능적인 요소에 대해서는 꼼꼼하게 검토가 이루어지지만 이 비기능적인 요소에 대한 검토는 프로젝트시에 점검이 소홀한 경우가 많다.)

 예를 들어 5개의 애플리케이션을 통합하여 새로운 비즈니스 애플리케이션을 만든다고 했을 때, 4개의 애플리케이션의 평균 응답시간이 0.3 sec라도, 1개의 애플리케이션의 평균 응답시간이 5sec, 이 새로운 애플리케이션의 전체 응답 시간은 0.3*4 + 5 = 6.2초가 된다. 5sec가 걸리는 애플리케이션에 대한 증설이나 재개발 또는 EAI의 메세징 모델의 변경등을 통해서 비 기능적인 요소를 만족시킬 수 있도록 해야한다.

 

3) 부서간 협력과 EAI 팀의 지배력

EAI 프로젝트를 진행하면 가장 중요한점중의 하나가 협업이다.

EAI의 대상 시스템은 주로 다른 부서간의 업무가 되는 경우가 많고, 통합을 위해서 일부 애플리케이션에 대한 수정이나 가감 작업이 수행되는 경우가 많은데, 이 경우에 부서간의 대화 문제나 책임회피 등으로 이상적이지 않은 방향으로 시스템이 통합되는 경우가 있다.

 이를 해결하기 위해서 원할한 협력관계가 우선시되어야 하는 것은 물론이고, EAI 프로젝트를 진행하는 주관팀이 효과적인 EAI 아키텍쳐를 위해서 적절하게 해당 부서에 통합 업무를 분할하고 진행 요청할 수 있는 적절한 권한을 가져야 한다.

 

4) Simple is best

애플리케이션을 상호연동하다보면 나오는 문제점중의 하나가 트렌젝션 에 대한 범위 지정일 것이다. 트렌젝션의 연동은 애플리케이션에서 매우 중요하고 필수적인 요소라고 할 수 있지만 그만큼 복잡성이 높고, 쉽게 연동할 수 없는 부분이기도 하다.

 실제로 기업 통합의 시나리오를 살펴보면 전체 업무의 80~85% 정도가 트렌젝션 연계가 필요없는 경우가 많다. 불필요한 부분에 트렌젝션을 연계하여 시스템의 복잡성을 증가시키지 말고 필요한 부분에만 사용하도록 하자.

또한 2Phase Commit이나 XA 사용보다는 Logging을 이용하거나 보상 트렌젝션등을 이용하는 방법으로 시스템을 단순화 시키는 것이 시스템의 안정성과 성능 향상에 더 큰 도움이 된다.

 

5) 경영 지원

기업의 애플리케이션 통합은 IT 부서의 요구보다는 비니지스 조직의 요구사항에 의한 경우가 많다. 그 만큼 경영 부서에서 애플리케이션 통합에 대한 인식과 적절한 요구 사항을 도출 시키는 것이 중요하고, IT 부서와의 협업을 통해서 적절한 통합 범위와 프로젝트 단계를 설정하는 것이 중요하다.

 또한 BPM 기반의 통합의 경우 BPM 자체가 비니지스 조직에 의해서 도출 되는 만큼 비즈니스 프로세스의 개선 작업이 경영선에서부터 시작이 되어야 한다.

 

5. SOA EAI

 

현재의 애플리케이션 통합을 이야기 하자면 SOA를 빼놓을 수 없다. EAI SOA의 접근 방식은 어떤면에서는 매우 비슷하게 보이지만 각각이 고유한 특징을 가지고 있다.

 SOA의 접근은 서비스 지향적인 접근 방식이다. 서비스란, 애플리케이션의 API나 구현 단위를 뜻하는 것이 아니라, 비즈니스적인 의미를 가지고 있는 단위 컴포넌트 이며, 서비스의 호출은 플랫폼이나 특정 기술에 대한 종속성을 가지고 있지 않는다. (해당 시스템이 Tuxedo ATMI, CORBA로 개발되었던간에 사용자 입장에서는 공통된 표준 기술을 이용해서 호출이 가능하다)

 상품ID로 정보를 상품 정보를 데이터베이스에서부터 읽어온다. 는 기능이 애플리케이션적인 의미를 가진다면 상품 ID로 발주를 한다는 의미는 상품의 재고 상태 파악과 입금 정산, 운송을 함께 하는 기능으로 비즈니스적인 의미를 가지게 된다. 반대로 EAI는 애플리케이션의 각 API들을 연동하여 하나의 통합된 의미의 기능을 만드는데 그 목적을 가지고 있다.

 EAI는 이 비즈니스적인 의미를 가지는 서비스 자체를 구현하기 위해서 하단의 애플리케이션들을 통합하여 상위 개념으로 추상화하여 하나의 서비스를 구축하는데 사용되며 특히 트렌젝션 연결과 같은 Tightly Coupled 된 애플리케이션 통합에서는 SOA 함께 사용되어야 한다.

 SOA Reference Architecture를 보더라도, SOA의 인프라가 되는 ESB (Enterprise Service Bus)의 하단에 애플리케이션들을 통합하여 비즈니스 서비스화하여, ESB에 연결하는데, EAI 가 이 ESB의 하단에 위치하게 된다.

 

6. 결론

 

기존의 애플리케이션들은 각기 다른 요구사항에 따라서 독립적이고 상호적인 운영성이 고려되지 않은 상태에서 독립운영 되도록 설계가 되었다.

그러나 기업이 커지고 업무의 복잡성과 요구되는 민첩성이 증가함에 따라 애플리케이션 간에 서로 공유되어야 하는 정보와 애플리케이션의 필요성을 인식하면서 통합에 대한 필요성이 대두 되었고, 기업들은 이러한 자원들을 연결하여 능률적인 비즈니스 프로세스를 구현하기 위해서 EAI를 도입하고 있다.

 

EAI를 도입하기 위해서는 적절한 목표와 이를 위한 적절한 범위가 선정되어야 하며, 통합을 진행하는 과정은 업무의 성격과 시스템의 규모에 따라서 단계적으로 진행되어야 한다. 효과적인 통합을 위해서는 EAI를 추진하는 조직이 성공적인 EAI 시스템의 구축을 위해서 부서간의 통합을 통제할 수 있는 적절한 권한을 가져야 한다.

 

또한 기업의 업무 프로세스 자체를 혁신하고 이를 IT에 민첩하게 반영하기 위해서 BPM이 등장하였으며, BPM의 적용은 IT 조직뿐만이 아니라 경영조직의 지원이 함께 이루어져야 한다.

 

EAI 프로젝트는 다음단계로 이루어질 SOA를 지원하는 구조가 고려되어야 한다.

신고
크리에이티브 커먼즈 라이선스
Creative Commons License

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

Apache Camel Error Handling  (0) 2013.02.20
Apache Camel Overview  (0) 2013.02.17
EAI (Enterprise Application Integration) 추진 전략  (1) 2009.07.16
ETL vs EAI  (0) 2009.06.16
EAI 도입 전략  (0) 2007.08.21
 

티스토리 툴바