SOA & MCI & EAI & ESB

Tech Note 정보
카테고리: [ Miscellaneous ]
조회수: 17546

1. SOA

SOA는 어떤 실체가 있다기 보다는 개념이다. 어떤 개념이냐면 비즈니스적인 의미를 가지는 컴포넌트를 기업내의 통합된 프로토콜로 서비스하여 제공하는 개념이다. 그래서 이 SOA는 BPM을 이용한 Composition이나 ESB를 이용한 유연성의 증대 등으로 구체화될 수 있다.

본격적으로 이야기를 풀어보려고 한다. 금융권의 채널이란 무엇인가?

우선 대내 채널과 대외 채널로 나눌 수 있다.

  • 대내 채널 : 각 영업점의 단말(창구), ATM, 인터넷, 콜센터 등의 고객 접점 (증권사의 경우라면 각 영업점의 단말, HTS, WTS, MTS 등이 되겠다)
  • 대외 채널 : 금융결제원, 제휴기관, 은행공동망, VAN사

그런데 채널이 늘어나면서 관리, 통제가 어려워진다. 또한 서비스 중복에 따른 비용이 증가하고 있다. 일반적인 채널 구조의 문제점을 정리해보자.

  • 업무의 채널 종속성 : 시스템을 개발할 때 모든 채널을 고려하여 구현해야 한다. 채널을 변경하거나 추가한다면 역시 응용의 변경이 필요하다.
  • 중복 업무 개발 : 개발 기능이 중복된다. 만약 업무가 변경되면 다른 채널을 모두 변경해야 한다.
  • 중복 인터페이스 개발 : 각각의 채널은 모든 타 업무에 대한 인터페이스를 중복하여 개발한다. 게다가 업무가 추가되면 채널 인터페이스를 또 개발해야 한다.
  • 일관성 부재 : 전 채널을 대상으로 하는 인프라 부재로 인해 일관성 있는 정보 제공이 어렵다.

2. MCI

대내 채널통합을 대내MCI가, 대외기관(금융결제원, 은행, VAN사 등) 채널통합은 대외MCI가 담당한다.

2.1. 장점

  • 비용 감소 : 채널 증가와 기존 채널의 관리에 따른 비용이 즐어든다.
  • 전략적 프로젝트 가능 : 맞춤형 서비스와 복합 상품 판매와 같은 상품 및 서비스 체계 구현이 가능해진다.

2.2. 기능

  • 전문 변환 : 외부 시스템의 전문을 내부 시스템의 전문과 매핑
  • 다양한 통신 방식 지원 : P2P, Request/Reply, Store/Forward, Publish/Subscribe 등
  • 다양한 프로토콜 지원 : 일반적으로 Socket 통신, TCP/IP, X.25, FTP, HTTP, SOAP 등
  • Load Balancing, Failover, Flow Control
  • 배치잡 처리 및 스케쥴러
  • 보안 : 암호화/복호화를 통한 데이터 보안

2.3. 구성 요소

  • 채널 어댑터 : 통신 프로토콜, 비즈니스 프로토콜의 인터페이스 담당
  • 매핑 엔진 : 외부 전문을 내부 전문(해당 업무)으로 변환
  • 매핑 DB : 전문 매핑 테이블
  • Developer Studio : 전문, 매핑 룰 정의
  • Admin Tool : 시스템 관리 도구 (모니터링, Failover)

2.4. 단점

  • 통합이 발생할 때마다 별도의 통합 프로그램을 구축해야 한다. 즉, 통합하고자하는 기능이 늘어날 수록 통합 프로그램 수가 계속 늘어난다는 것이다.
  • 또 시스템이 교체된다면 교체된 시스템의 인터페이스를 바꿔야 한다. EAI는 서로 다른 시스템들을 Native 인터페이스를 통해 연결하는 것이기 때문에 각 시스템에 대한 전문지식, 타 부서와의 연계 프로세스, 인터페이스 프로그래밍에 대한 지식을 갖추고 있어야 한다.

2.5. 구축 시 고려사항

  • 성능 : 모든 채널이 집중된다. 따라서 성능 이슈가 발생할 수 있다. 성능 확보 방안이 필요하다.
  • 가용성 : MCI의 장애는 시스템 전체 장애로 이어진다. 따라서 장애 대응 방안이 필요하다.

2.6. 응답 보장

2.6.1. 대내  

  1. 요청한 단말의 채널ID 및 세션 저장
  2. 요청 단말은 응답전문 대기
  3. 단말의 타임아웃 전문 수신시 해당 요청전문 오류 처리
  4. Back-end 지연 응답 전문 오류 처리 

2.6.2. 대외

  1. 전문별 타임아웃값 설정
  2. 타임아웃 처리방법 설정
    - 재전송 횟수
    - 오류 전송 

2.7. 제품

MCI 제품에는 티맥스의 AnyLink 등이 있다.

3. EAI

3.1. 설명

채널 내부로 들어온 데이터 중 필요한 정보를 전문 변환이나 라우팅으로 가공하여 새로운 데이터를 만들어내는 역할을 한다.

EAI를 MCI로 전환 시 장점은 다음과 같다.

  • 대내전문 표준화에 따른 서비스 확장시 유연성 제공
  • 다양한 OS, 프로토콜에 대응하기 위한 어댑터 제공
  • 프로세스 통합에 따른 데이터 정합성 유지
  • 거래추적 및 오류 발생에 대한 채널 간 통합 모니터링 환경 제공
  • 비즈니스 로직와 기술 표준을 분리함에 따른 관리 효울화
  • 장애 및 구현에 필요한 Effort 절감으로 운영 효울화

종류는 Tibco, OSB, WebSphere Message Broker 등이 있다.

4. ESB(Enterprise Service Bus)

4.1. ESB란?

서두에 SOA에 대해 잠깐 언급한 바 있다.  ESB는 SOA를 지원하는 서비스와 응용 컴포넌트간의 연동을 지원한다. 즉, ESB는 SOA를 구현할 수 있게 해주는 실체로, Loosely coupled의 asynchronous 메세지 방식의 SOA를 위한 라우팅 알고리즘을 제공한다.

사실 EAI의 Hub & Spoke 방식의 한계로부터 발전했다. (하지만 EAI와 ESB는 서로 같은 형태로 수렴하고 있어 ESB는 벤더들의 마케팅 전술이라는 비판이 있다)

본격적으로 특징을 보자.

먼저 다양한 시스템과 연동을 위한 다양한 프로토콜을 제공한다. 웹 서비스나 XML이 그 예이다. 또한 변환이 가능하다. 예를 들어 XML와 JSON이 존재한다면 ESB 계층에서 JSON TO XML 변환을 수행할 수 있다. JMS TO HTTP도 가능하다.

그리고 위에서 말했지만 loosely coupled, 느슨한 결합이다. (클라우드의 추세이기도 하다)

BPM을 지원한다. 다음은 큰 SOA의 구조이다.

  • 서비스 구현 레이어 : 프레임웍이나 응용으로 구현
  • 서비스 오케스트레이션 레이어 : ESB로 구현
  • 비즈니스 프로세스 레이어 : BPM으로 구현

라우팅, 매우 중요한 부분이다. 일반적인 리버스 프록시보다 향상된 라우팅을 제공한다. 보통의 리버스 프록시는 HTTP 헤더 또는 URI 기반으로 라우팅을 하는데 반해 ESB는 메세지(헤더 혹은 본문)를 이용하여 라우팅할 수 있다. (Content-Based Rouing) 메세지의 내용에 따라 호출할 서비스를 결정하거나 특정한 로직을 처리하는 경우다. 정적 라우팅, 동적 라우팅 지원, 동적 라우팅은 메세지 내용 기반, 룰 기반, 정책 기반 등 다양한 라우팅을 제공한다.

SLA, QoS를 지원한다. 이는 전송 보장 기능, 트랜잭션 관리를 수행한다. SLA(Service Level Agreement) 관련해서는 만약 설정된 목표를 달성하지 못하면 알람을 보내기도 한다.

보안은 어떨까? WS-Security에서 정의하고 있는 인증, XML 기반 암호화, SSL 등을 지원한다. 보안 기능을 사용하고자 한다면 보안 수준과 여러 보안 정책(예: 인증서 관리 등)이 필요하다.

그리고 이벤트 지향적아고, 표준 지향적이며 플랫폼 독립적이다.

MCI와의 차이점은 무엇일까? MCI가 이기종간의 통신을 위해 전문 해석/변환을 통한 채널 관리/통합을 한다고 하면, ESB는 응용(애플리케이션) 간의 통합을 보장하는 개념이다.

한편 성능이 중요하다. bypass만 하느냐, 무언가 작업을 하느냐에 따라 다르긴 하지만 어쨌든 타임 오버헤드를 최소화해야 한다. 또 메세지 body까지 파싱하지 않도록 하는게 중요하다. (body까지 파싱다면 성능은 더욱 떨어진다)

이처럼 ESB는 차후 시스템에 변화가 있을 때 매우 도움이 된다. (초기에는 별 메리트가 없다. 초기에는 이미 요구사항대로 구현이 되어 있기 때문이다)

ESB 솔루션은 다음과 같이 구분할 수 있다.

1. 소규모 ESB 솔루션 제공 벤더

  • 업무 복잡도가 낮은 회사에 적합
  • 저가

2. 통합 솔루션 제공 벤더

  • EAI에서 ESB로 확장하고 있는 벤더
  • ESB 단독 제품은 아니지만 EAI 기반으로 ESB로 나아가고 있음

3. 플랫폼 벤더

  • 애플리케이션 플랫폼 혹은 엔터프라이즈 애플리케이션 영역에서 출발한 벤더
  • 자사 솔루션 내에 ESB를 포함하고 있거나, 독립적인 ESB 제품을 제공

ESB 제품의 종류에는 티맥스의 ProBus, Apache ServiceMix(http://servicemix.apache.org/) 등의 제품이 있다.

다음은 위키 백과에서 발췌한 ESB의 특성(기능) 정리이다.

  • Invocation
  • Routing
  • Messaging
  • Service Orchestration
  • Complex Event Processing
  • Message Exchange Pattern
  • Governance

4.2. Apache ServiceMix

그러면 오픈 소스 ESB 제품인 Apache ServiceMix에 대해 조금 더 자세히 알아보자.

Apache License 2.0에 의해 배포되는 ServiceMix는 JBI(Java Business Integration, JSR 208) 스펙을 만족하며 다음과 같은 구성 요소를 갖추고 있다.

  • Apache ActiveMQ : 메시징 서비스
  • Apache Camel : 메시징, 라우팅, 통합 패턴
  • Apache CXF : 웹 서비스
  • Apache Karaf : OSGi 기반 서버 런타임

JBoss에도 관련 제품군이 있다.

  • JBoss Data Virtualization (JDV) : Connect, Compose, Consume 단계를 통해 정형화되지 않은 데이터를 통합, 관리
  • JBoss Fuse Service Works : 서비스 관리, 디플로이, 오케스트레이션, 룰 관리
  • BPM Suite

5. 결론

다시 간단히 MCI와 ESB를 비교해보자.

  • MCI : Hub를 이용하여 비즈니스 로직을 중심으로 기업의 애플리케이션 통합, tightly coupled, 속도 빠르다.
  • ESB : Bus를 이용하여 서비스 중심으로 시스템 간 유기적 연계, loosely coupled, 속도 느리다. (표준 준수)

마지막으로..

계속해서 전문의 변환에 대한 이야기를 했다. 만약 레거시 시스템에 대한 통합을 수행한다면 레거시 메세지를 표준 전문으로 변환하는 작업이 필요하겠지만 애초에 SOA 프로젝트라면 설계 단계부터 표준 전문을 사용하기 때문에 전문 변환 작업은 발생할 일이 없다.