SOA의 중심 ESB(Enterprise Service Bus)
ESB의 이해와 기술 동향

SOA를 구현하기 위해 비즈니스 관점에서 의미 있는 서비스를 구현해야하지만 웹 서비스 기술이 분산객체 기반의 인터페이스 기술의 성격이 크기 때문에 웹 서비스만으로는 부족한 부분이 많다. 또한 웹 서비스만으로 구축되는 애플리케이션의 아키텍처 및 특성은 기존의 애플리케이션과 크게 다르지 않다. ESB는 애플리케이션의 유연성과 민첩성을 보장해 주며, 복합 서비스의 구성과 유연한 서비스 관리 기술을 제공해 SOA가 실현 되도록 지원한다.

임철홍 imich@skcc.com｜SOA를 비롯한 신기술 분야 프로젝트 지원 업무 담당

ESB의 개념이 소개되고 부터 현재까지 많은 논란이 지속되고 있다. 가장 큰 논란은 “과연 어디에 쓰는 솔루션 인가” “EAI (Enterprise Application Integration)와 다른 점은 무엇인가” “BPM(Business Process Management)과 다른 점은 무엇인가”등 이다. 혹자는 ESB는 EAI와 같은 기능을 하며, SOA라는 패러다임에 맞춰진 마케팅 용어라고 비판도 한다. 이런 논란이 생긴 첫 번째 요인은 ESB의 시작이 개념적인 형태에서 출발했고, 솔루션도 기존 EAI 솔루션 기술을 기반으로 만들어 졌다는 점에 있다. 두 번째 요인은 SOA의 적용이 다른 개념과 완전히 독립적인 개별적인 형태가 아니라는 점이다.

즉 내부적인 통합을 기반으로 서비스를 제공하는 경우에는 EAI의 기능을 포함할 수밖에 없으며, 업무 프로세스의 설계와 실행 관점에서는 BPM의 기능을 어느 정도 포함 할 수밖에 없다. 초창기의 ESB개념은 시스템 측면의 통합과 일부 사용자 워크플로우의 통합을 포함하는 BPM과 유사한 넓은 개념이었으나, 최근의 ESB개념은 일부 EAI의 기능을 포함하며, 메시지의 변환과 라우팅을 주요 기능으로 하는 차별적인 형태를 지향하고 있으며, SOA를 실현하기 위한 중요한 기술로 자리매김 하고 있다. 제공하는 솔루션의 기능만으로 ESB를 판별하는 것은 의미가 없을 수 있다. ESB를 EAI와 같이 구현 할 수도 있으며, 이 경우 솔루션은 ESB를 활용했지만 구축형태는 EAI를 했다고 하는 게 적합한 표현일 것이다. 필자의 개인적인 생각일 수 있지만, ESB는 다른 솔루션과 달라서 어떻게 활용하느냐에 따라 달라지는 복합적인 형태를 가지고 있다.

SOA를 실현하는 ESB

SOA 환경에서 애플리케이션의 동작은 분산된 여러 개별 서비스를 호출하고 실행하는 환경이다. 공통적으로 활용 될 수 있는 기능을 서비스 형태로 구현하고 서비스의 위치와 활용 기술에 독립적으로 실행이 가능한 환경을 지향하는 것이 서비스 지향의 개념이다. 각 서비스들은 Loosely Coupling하게 연결되어, 유연성과 민첩성을 보장 할 수 있다. 이전의 애플리케이션은 개별적으로 큰 단위의 코드가 실행되는 개념이었다. 일부 공통 API (DLL, JAR형태)를 활용했지만, 기술적인 유틸리티 성격이 강했고, 애플리케이션에서 구현하려는 중요 로직은 코드로 모두 개발이 되는 형태였다. 반면 SOA에서는 주요 로직들이 서비스 단위로 존재 하고, 이를 호출하여 활용하게 되는 개념이다. 이러한 개념은 CBD에서도 오래 전부터 시도해 온 개념으로, 다른 점은 서비스의 크기가 CBD 보다는 크고, 다양한 조합에 의해 쉽게 새로운 서비스가 만들어진다. SOA는 기본적으로 CBD의 개념을 확장 발전시킨 형태이다. <그림 1>은 서비스들이 조합되어 애플리케이션을 구성하는 개념을 설명하고 있다.

<그림1>ESB를 활용한 SOA 애플리케이션

ESB(Enterprise Service Bus)는 웹 서비스, Content-Based Routing, 메시지 변환 기술을 기반으로 SOA를 지원하는 미들웨어 플랫폼이다. 개별 서비스들은 ESB를 통해 조립되고 활용 된다. 분산되어 존재하는 여러 서비스의 코드를 구현해 직접 호출하여 활용하는 경우를 생각해 보자. 서비스를 활용하는 클라이언트에서 모든 서비스 호출에 대한 부분이 코드로 작성되고, 이러한 경우 클라이언트에서 활용하는 로직에 변경이 발생 할 경우 빈번하게 코드를 수정해야 한다. ESB를 활용하는 경우에는 단위 서비스의 호출을 ESB가 담당하게 되고, 단위 서비스들을 조합하여 복합 서비스를 구축하는 것도 가능하다. 변경이 필요한 경우 클라이언트 모듈을 수정하는 게 아니라, 서비스의 조합에 대한 수정을 통해 변경이 가능하다. ESB에서는 메시지의 변환, Content-Based Routing, 실행 Flow 제어 기능을 지원하여 서비스, 클라이언트의 직접적인 변경 없이 유연하게 대응하는 것을 목표로 한다. <그림 2>에서 서비스를 직접 호출하는 경우와 ESB를 활용하는 경우에 대해 비교하고 있다. 직접 서비스를 호출하여 사용하는 경우에는 매우 복잡하게 연계되어, 서비스 사용이 어렵고, 변경되는 경우에 유연한 대응이 어렵다. ESB를 활용하는 경우 단일한 접점(ESB에서 노출하는 서비스)을 제공하여, 클라이언트가 쉽게 사용이 가능하며, 변경이 일어나는 경우 ESB에서 유연하게 대응이 가능한 구조를 제공 한다. 또한 여러 서비스를 조합하여 단일한 서비스(복합서비스)형태로 제공이 가능 하다.

<그림2>ESB를 활용한 서비스 연결

ESB는 Message기반의 Loosely Couple한 표준 인터페이스 기반의 통신을 지원하고 있으며, 표준적인 Message Standard인 SOAP을 지원 하며, 서비스의 조합과 실행을 위한 Flow 제어에 의한 통합을 지원한다(BPM에서 비즈니스 프로세스와 비슷하지만, 비즈니스 레벨보다는 작은 기능 측면의 레벨인 이유로 Micro level Process 또는 Service Orchestration으로 통용 된다).

● Loosely coupled: 표준 인터페이스(WSDL)를 준수하는 메시지 전송에 의해 Application 간의 연관성이 적은 형태에서 연동을 지원
● Highly distributed integration network: 중앙 집중적이면서도 분산 환경의 통합을 지원
● Event-driven:시스템에 독립적인 이벤트에 의해 자동적인 Process의 시작이나 정지, 재시작 등의 조정이 가능한 형태
● Documents-oriented(Message Driven): 메시지 기반의 통신을 기반으로 함
● 표준 인터페이스 지원: COM, CICS, .NET, JMS, JCA, JDBC, Web Services 지원

복합 서비스 제공을 위한 ESB 기능

분산된 서비스의 효율적인 통합을 위해 ESB는 각 서비스들이 사용하는 기술에 독립적으로 접근이 가능한 인터페이스 통합 기능을 제공한다. 개별 서비스들이 모두 웹 서비스 기반의 서비스 제공을 하지 않으므로, 대부분 ESB 솔루션에서 이러한 통합 기능을 어느 정도 제는 기능과 중복되는 부분이며, EAI와 ESB의 개념의 혼동을 일으키는 부분이기도 하다. 다른 ESB의 기능은 메시지 변환과 Content-Based Routing이 있다. 메시지 변환은 프로토콜 및 콘텐츠에 대한 변환을 수행하여 서비스의 통합을 지원한다. ESB의 중요한 기능으로 Flow control 기능이 있다. 플로우챠트와 같이 비교 판단과 Routing 등의 흐름을 제어하는 기능을 가진다. ESB 내부 및 ESB와 서비스간의 통신은 메시지 기반의 통신을 사용한다. MQ와 같은 MOM(Message Oriented Middleware) 기능을 활용해 안정적이고 신뢰성을 보장하는 메시지통신 환경을 지원한다. <그림 4>는 ESB의 기능을 설명하고 있다.

<그림4>EBS의 기능

인터페이스 통합

● Web Service(SOAP), JMS(MQ), File(FTP)에 대한 통합 기능 제공 - Legacy Application의 경우 JCA를 활용하거나 Custom Adapter 활용 가능
● 사용자 User Interface와의 연계 지원

메시지 변환

● 콘텐츠 변환: XML표준의 메시지가 XPath, XSLT를 활용해 메시지를 변환한다. <그림 5>는 ESB를 통해 컨텐츠의 내용이 변환되고 새로운 내용이 추가되는 기능을 설명하고 있다.

<그림5>콘텐츠 변환

● 프로토콜 변환: JMS, HTTP, RMI 등의 프로토콜을 상호간에 변환한다. 예를 들어JMS로 요청된 프로토콜이 HTTP형태로 바뀌어 질 수 있다.

Content-Based Routing(Intelligent Routing)

● 메시지의 내용에 따라 호출할 서비스를 결정하거나 특정한 로직을 처리할 경우 활용됨. <그림 6>은 Routing에 의해서 다른 처리로 분기 하는 모습을 설명하고 있다.

<그림6>Content-Based Routing의 활용

Message Communications

● XML기반의 동기/비동기 SOAP messaging: SOAP표준에 기반한 메시지를 교환함으로써 이기종/분산 환경에서의 데이터 및 Application 연동이 가능하게 지원함
● 신뢰성 있는 통신 환경: MQ와 같은 MOM(Message Oriented Middleware)을 활용하여 메시지 전송의 안정성과 보안성을 지원함

서비스 관리 및 운영을 위한 ESB 기능

최근의 ESB들은 서비스에 대한 조합을 통해 복합서비스를 구성하는 기능과 함께 서비스 관리 및 운영을 위한 보안, Proxy (Load Balancing, Fail over), QoS 측정 기능을 포함하고 있다. 원래 이러한 기능들은 웹 서비스 관리 솔루션 등을 통해서 제공 됐었지만, ESB의 기능으로 포함되고 있다. Proxy기능은 서비스에 대한 개별적인 위치 정보를 외부에 공개하지 않고, ESB에서 제공하는 대표 위치 정보를 제공하는 개념이다. Proxy는 요청받은 정보를 실제의 서비스에 다시 요청하고 결과를 전달받아 ‘요청자’에게 전달하는 Relay 기능을 수행한다. ESB의 Proxy 기능을 활용해 서비스에 대한 Load Balancing과 Fail over의 기능 수행이 가능하다. <그림 7>은 Proxy의 기능을 설명하고 있다. 만약 서비스가 다른 서비스로 교체 될 경우에도 클라이언트는 Proxy의 위치를 가지고 있기 때문에 Proxy에서 전달되는 서비스 위치만 수정하면 된다(클라이언트의 코드 수정이 필요 없게 된다).

<그림7>Proxy기능

다음 <그림 8>은 Proxy의 기능을 활용해 Load Balancing과 Fail Over를 구현하는 설명이다. 클라이언트로 부터의 요청을 Proxy가 개별 서비스에 순차적으로 요청을 하는 형태로 Load Balancing이 구현된다. 물론 개별 서비스들이 같은 네트워크 안에 있을 경우 L4스위치를 통해서 Load Balacing 처리가 가능 하나 L4가 없을 경우와 서비스들이 다른 네트워크에 속해 있을 경우 효과적으로 사용이 가능하다. Fail Over의 경우는 서비스에 장애가 생길 경우 등록되어 있는 다른 서비스로 기능을 이관하여 실행하는 형태이다. 두 가지 기능 모두 Proxy기능을 기반으로 제공 되는 기능이다.

<그림8>Load Balancing, Fail Over 기능

보안 기능은 WS-Security에서 정의 하고 있는 인증, XML기반 암호화/전자서명, SSL지원에 대한 기능을 지원한다. 보안 기능 활용을 위해서는 보안을 적용하고자 하는 수준과 알고리즘, 인증서 관리와 같은 보안 정책의 수립이 필요하다. ESB를 활용해 보안을 제공하는 방안은 클라이언트에서 요청을 암호화(전자서명)하는 부분과 암호화된 요청을 복호화 하여 제공하는 서비스의 암호화(전자서명)를 지원하는 두 가지 방식이 있다.

<그림 9>는 클라이언트에서 보안을 지원하는 방안이다. 서비스는 암호화/전자서명 요청을 처리하도록 구성되어 있으며, 클라이언트에 이러한 기능을 코드로 구현하지 않고, ESB를 활용하여 처리하는 방안이다. 서비스를 호출하고 사용하는 입장에서 구현되는 모습이다. 이 경우 클라이언트와 ESB가 같은 네트워크 안에서 방화벽에 의해 보호가 돼야 의미가 있다. 암호화 되지 않은 요청이 방화벽 밖으로 나가게 될 경우 보안의 안정성에 문제가 발생될 가능성이 있다.

<그림9>클라이언트에서의 보안 지원

<그림 10>은 Provider에서의 보안 지원 방안이다. 외부의 암호화(전자서명)된 요청에 대한 처리를 ESB를 통해 대신하는 방안이다. 이 경우 서비스는 원래 암호화(전자서명) 처리를 고려하지 않고 구성되어 있으나, ESB를 활용해 대신 처리한다. 여기에서 설명한 두 가지 방식을 클라이언트와 서비스 제공자에서 동시에 사용하는 방안도 가능하다.

<그림10>Provider에서의 보안 지원

QoS 보장 기능은 각 서비스에 대한 Response Time, Fail에 대한 통계 정보를 제공하며, SLA (Service Level Agreement)의 개념을 도입하여 설정된 목표를 달성하지 못할 경우 Alert의 형태로 관리자에게 공지하는 기능을 제공한다. 대체로 웹 서비스 관리 솔루션에서 지원하는 기능이었으나, 최근 ESB의 기능으로 포함되고 있다.

ESB 기반 애플리케이션

여러 서비스와 연동되어 있는 ESB는 자체적으로 복합 서비스의 형태로 구성되어, 여러 단위 서비스가 Flow에 의해 조합되고 연결 되어 복합 서비스로 활용 가능하다. <그림 11>에서 기능의 단위가 Class컴포넌트서비스복합서비스로 발전하는 모습을 볼 수 있다.

<그림11>애플리케이션의 단위

개별 서비스를 기반으로 복합 서비스기반으로 구축되는 ESB 애플리케이션의 모습은 다음과 같다. 여러 서비스들이 조합되어 구성된 복합 서비스도 외부에서는 개별 서비스 형태로 보인다. 즉 WSDL(Web Service Description Language)을 노출해 SOAP을 기반으로 통신이 가능하도록 지원하게 된다. 이러한 복합 서비스가 다른 복합 서비스에서 활용될 수도 있다. 따라서 복합 서비스라고 하는 관점은 구현 관점에서만 의미가 있게 되며, 사용자 관점에서는 일반 서비스와 다른 점을 알 수 없게 된다. 다음 <그림 12>는 이러한 서비스간의 관계에 대해 설명하고 있다.

<그림12>서비스와 복합 서비스의 관계

ESB 활용 사례

ESB를 활용하여 구축되는 애플리케이션은 기존의 애플리케이션과는 다른 형태로 구성됐고, 동작을 한다. SOA에 대한 가장 큰 오해 중에 한 가지는 현재의 애플리케이션을 ESB를 활용한 SOA의 형태로 전환이 가능하다는 생각이다. SOA는 특정한 시스템 단위의 애플리케이션이 아니라 내/외부 여러 시스템간의 실 시간적인 협업을 통해 이뤄지는 통합 시스템 형태이다. 기존의 애플리케이션과 비교를 위해 <그림 13>의 경우를 살펴보면, 신용조회-요청번호 채번-재고조회에 대한 부분이 하나의 코드로 구성된다.

객체지향 개념에 의해 API형태의 클래스를 만들어 사용하는 것은 아키텍처 측면에서 큰 차이가 없다. ESB의 경우에는 신용조회와 재고조회에 대한 별도의 서비스를 구성하여 다른 서비스에서도 사용이 가능하다. 또 다른 특성으로 Flow 처리가 있다. <그림 13>처럼 1~6까지 처리를 수행하며, Content-Based Rout ing에 의한 분기 처리도 가능 하다. 만약 순서가 바뀌거나 중간에 다른 메시지 변환이 필요한 경우 기존 다른 서비스에 영향을 미치지 않고 중간에 새로운 처리 단계를 생성 할 수도 있다.

신용조회와 재고조회의 경우 대내외 연동을 필요로 하는데, 웹 서비스나 Legacy 연계 Adapter를 활용한 Integration기능도 제공한다. 즉 기존에 하나의 코드로 제공되던 애플리케이션이 ESB 미들웨어에서 비즈니스 로직을 가지고 개별 서비스를 호출하고 조합하는 형태의 애플리케이션이 구성되어 동작한다. 기존 애플리케이션은 데이터베이스에 의존적인 형태로 구성이 되어 모든 트랜잭션이 데이터베이스를 통해 수행되거나 ESB를 활용하는 경우 메시지를 기반으로 처리를 수행한다. 물론 데이터베이스가 전혀 필요 없다는 것이 아니라, 필요한 경우에 내역을 저장하거나 참조를 위해 데이터베이스를 호출한다.

<그림13>ESB 애플리케이션과 기존 애플리케이션 비교

ESB 동향과 전망

현재 ESB는 EAI나 BPM솔루션에 포함되어 있던 기능을 선별하고 필요한 기능을 특화하여 정식적인 솔루션으로 출시되어 있고, 많은 오픈소스 프로젝트들도 진행되고 있다. 현재 ESB솔루션은 IBM ESB ,BEA ALSB, Oracle ESB, Sonic ESB와 같은 제품이 있다. 벤더에서 출시되는 ESB솔루션 외에 오픈소스로 진행되는 많은 프로젝트들이 있다. 개별 프로젝트들의 ESB도 프로젝트 목표에 따라 다른 점을 가지고 있다. 본 연재에서 소개할 Apache Service Mix를 비롯하여 Apache Synapse, Celtix. Mule과 같은 프로젝트가 있다. ESB를 활용한 SOA기반의 시스템 구축이 활성화되려면 다음과 같은 비즈니스적, 기술적 당면 과제를 가지고 있다.

① ESB 사례: 서비스를 구성하여 외부에 제공 되어 활용 되는 Best Practice가 부족
② 서비스의 부재: 다른 조직/시스템과의 업무 연계가 제한적이며, 외부에서 활용 가능한 서비스가 없음
③ 자동화 처리에 대한 제한성: 기업의 업무 처리 방식이 자동화가 되어 있지 않음
④ 표준화 문제: 표준 명세가 없음. Sun에서 JBI(Java Business Integration) 표준을 수립하였으나, 일부 오픈 소스 프로젝트(ServiceMix가 대표적임)에서 활용
⑤ Local Binding: 원격적인 호출을 기반으로 하기 때문에 POJO Com ponent와의 효과적인 Local Binding 지원이 어렵다. WSIF(Web Service Invocation Framework)등을 지원하는 방법도 있지만, 형태는 외부 연동과 같아서 구현이 어렵다. 이러한 대안으로 SCA(Service Component Architecture)가 등장하게 되었다.
⑥ ESB벤더의 Lock-In 전략: ESB를 사용하기 위해 ESB 벤더사의 DB, WAS, 개발 Tool이 함께 사용 되도록 만들어진 경우가 있다.

ESB는 분산된 서비스를 조합하여 애플리케이션을 구성하도록 지원하는 SOA의 개념을 실현하는 중요한 기술이다. 초기에는 EAI와 유사한 측면도 있었으나 현재는 차별화 되어 발전하고 있다. ESB의 복합 서비스라는 애플리케이션 적 측면을 보강하기 위해 SCA(Service Component Architecture)를 지원하려는 움직임이 있으며, SCA는 향후 ESB의 표준으로 수용 될 것으로 전망된다. 다음 호에서는 실제적인 구축 측면에서 ESB의 모습을 살펴보기 위해 Apache진영에서 진행되는 오픈 소스 ESB 프로젝트인 Service Mix와 Synapse를 살펴본다.