SOA (Service Oriented Architecture)
기업이 비즈니스 유연성을 확보함으로써 외부 변화에 반응, 빠르게 비즈니스를 바꿀 수 있도록 하는 온 디맨드 비즈니스를 구현하기 위해서는 IT 시스템의 유연성이 필수적입니다. SOA는 온 디맨드 운영 환경에서 비즈니스 유연성을 가능하게 하는 인프라스트럭처를 제공합니다. SOA를 적용하여 기업은 비즈니스 환경 변화에 유연하게 대응할 수 있는 시스템을 구축할 수 있고 이를 통해 경쟁력을 높일 수 있습니다.
하지만 기존 IT 시스템만으로 이러한 비즈니스 유연성을 만족시키기가 쉽지 않습니다. 과거와는 달리 요즘의 비즈니스 환경 변화는 기존 IT 시스템이 그 변화를 따라가기 어려울 정도로 빠르기 때문에, 기존 IT 시스템을 얼마나 유연하게 만들 수 있느냐가 관건이라 할 수 있습니다.
따라서 전통적인 IT 시스템과는 다른 패러다임이 필요하고 이러한 필요사항에서 나온 것이 서비스 지향 아키텍처(Service Oriented Architecture)입니다. 이를 위해 기업 내부 프로세스와 어플리케이션들을 각각 '서비스'라는 기본적인 기능 단위로 나누고 이들 서비스를 연결하여 원하는 기능을 제공하도록 구성하는 것이 중요합니다. 그래야 비즈니스 환경이 변화되었을 때 이 변화를 반영하여 서비스의 연결 구성을 쉽고 빠르게 변화시켜 새로운 기능을 제공하도록 할 수 있습니다.
SOA의 중요 개념
서비스 지향 아키텍처에서 언급되는 서비스는 반복 사용이 가능한 비즈니스 기능으로 정의할 수 있습니다. 서비스는 개별 기능을 수행하는 단위로서 다른 서비스와는 독립적으로 정의됩니다. 예를 들면, 고객 신용도 조사, 신규 계좌 개설 등을 서비스로 정의할 수 있습니다. 서비스 지향이란 서비스를 서로 통합하여 비즈니스 요구사항을 충족하는 방식을 말합니다. 다시 말하면 내부 비즈니스의 각각의 독립된 기능을 서비스로 정의하고 정의된 서비스를 서로 연결하여 특정 기능을 제공하는 방식입니다. 따라서 서비스 지향 아키텍처(SOA)는 서비스 지향 비즈니스를 지원하는 IT 아키텍처 방식을 말합니다. 그리고 이러한 아키텍처 상에서 운영되는 어플리케이션을 컴포지트(composite) 어플리케이션이라고 합니다. 컴포지트 어플리케이션은 기존 어플리케이션 개발 방식과는 달리 정의된 서비스를 비즈니스 요구 사항에 맞추어 조립(Composite)하여 원하는 기능을 구현합니다. 만약 기존 컴포지트 어플리케이션을 변경해야 한다면 컴포지트 어플리케이션을 구성하는 서비스 중 필요 없는 기능에 해당하는 서비스를 빼고 원하는 기능을 제공하는 서비스를 넣어서 새로운 기능을 하도록 변경할 수 있습니다. 따라서 어플리케이션을 만드는 시간을 단축시킬 수 있습니다.
그림에서 보면 차량 컴포넌트의 경우 예약 생성 및 예약 변경 서비스에 영향을 주게 됩니다. 그리고 예약 생성, 예약 변경, 예약 취소 예약 조회, 운임 조회 등의 서비스가 조립되어 차량 예약 프로세스를 만들어 냅니다. 서비스는 각각 업무 시스템이 특정 시스템을 통해 구현된 것을 의미할 수도 있고 신규로 만들어진 서비스를 의미할 수도 있지만 이 모든 것은 재활용 및 재성성 가능한 아키텍처를 기반으로 삼고 있다는 것을 확인할 수 있습니다. 즉 서비스나 프로세스의 부분적인 변화가 나타나더라도 유연한 대처를 가능하게 할 수 있는 시스템 아키텍처가 구성되어 있다는 것을 뜻합니다.
SOA 시장 현황
서비스 지향 아키텍처(SOA) 시장은 일반적으로 아래와 같이 3가지로 구분됩니다. 첫 번째는 미들웨어 영역입니다. 흔히 SOA 플랫폼이라고 언급되는 영역으로 비즈니스 프로세스나 메시지 기반의 커뮤니케이션이 이에 해당합니다. IBM의 WebSphere Process Server, SAP의 Net weaver, BEA의 Weblogic, Oracle의 Fusion Middleware, Microsoft의 Biztalk, TIBCO의 ESB, Sonic ESB 등이 이런 영역에 포함됩니다. 이런 플랫폼은 컴포지트 어플리케이션의 생성 및 서비스 공개를 가능하게 합니다. 두 번째는 Enterprise Service Bus(ESB) 영역입니다. 이는 ESB 제품군 뿐만 아니라 ESB 기능을 포함하고 있는 미들웨어 영역을 포함합니다. 일부 벤더의 경우 ESB 전용 소프트웨어를 제공하고 있지만, 나머지 벤더는 ESB를 개념적인 아키텍처 정도로 생각하여 기존의 솔루션의 일부 기능으로 표현하고 있기도 합니다. ESB는 일반적으로 메시지 전송, 라우팅, 중개 등의 역할을 담당합니다. 마지막이 SOA 서비스 영역입니다. SOA 구현을 위한 컨설팅 능력, 시스템 통합 능력, 어플리케이션 관리 영역, 기술 지원 영역 등이 이에 포함됩니다.
2006년 9월 Springboard Research에서 조사한 아시아 태평양 지역의 SOA 시장 규모 분석 자료는 아래와 같습니다. 자료에 의하면 Revenue 크기는 4배 가까이 성장할 것으로 예상되며 해마다 30% 이상의 시장 성장을 예측하고 있습니다.
2007년 IDC 자료에 따르면 SOA 컨설팅 서비스 능력에 대해 아래와 같이 분석하였습니다.
SOA 구현
서비스 지향 아키텍처(SOA)는 다음 4단계를 거쳐 구현됩니다.
● 1단계 - 비즈니스 디자인을 컴포넌트화
● 2단계 - 비즈니스 프로세스 요소를 서비스로 작성
● 3단계 - ESB(Enterprise Service Bus)를 사용하여 서비스를 연결
● 4단계 - 서비스 결합 프레임워크를 사용하여 서비스 통합
첫 번째 단계에서는 어플리케이션에서 수행되는 비즈니스 기능, 프로세스에서 사용되는 데이터, 시스템에서 제공되는 서비스 및 사람에 의해서 수행되는 과제 등의 기존 비즈니스 프로세스의 요소를 확인하고 이들 요소의 사용자를 파악합니다. 두 번째 단계에서는 이들 요소를 실행 가능한 서비스로 만듭니다. 서비스 사용자를 위한 클라이언트를 정의하고 웹서비스의 WSDL(Web Services Description Language)을 사용하여 각 서비스의 인터페이스를 생성합니다. 또한 각 서비스에 의해 사용되는 데이터 구조를 XML로 정의합니다. 세 번째 단계에서는 ESB(Enterprise Service Bus)를 사용하여 위치, 전송형태 및 조직 범위에 상관없이 서비스와 서비스 사용자를 연결합니다. 마지막으로 이러한 기반 위에 각각의 서비스로 구현된 업무들을 통합합니다.
SOA 라이프 사이클
어느 벤더의 어느 솔루션을 선택하든지 서비스 지향 아키텍처(SOA) 구현은 아래와 유사라이프 사이클을 가집니다. SOA 라이프 사이클은 모델(Model) -> 조립(Assemble) -> 전개(Deploy) -> 관리(Manage)의 절차를 거치게 되며, 이 모든 단계는 SOA 거버넌스를 통해 관리되고 통제됩니다.
모델(Model) 단계
모델(Model) 단계에서는 비즈니스를 잘 아는 현업 담당자가 비즈니스 요건을 분석하여 어떤 서비스를 어떻게 조립할 것인지를 정의합니다. 이를 비즈니스 모델 생성이라고 표현합니다. 기존 어플리케이션 개발은 운영을 해본 후에야 어플리케이션의 문제를 파악할 수 있는 반면에, SOA 라이프 사이클의 모델 단계에서는 IT 전문가가 어플리케이션을 개발하기 전에 현업 담당자가 정의한 비즈니스 모델을 미리 시뮬레이션할 수 있습니다. 미리 비즈니스 모델의 문제나 개선점을 파악할 수 있기 때문에 문제가 발생하는 부분에 대한 수정 사항을 비즈니스 모델에 반영하여 문제 가능성을 최소화합니다.
조립(Assemble) 단계
조립(Assemble) 단계에서는 모델 단계에서 만들어진 프로세스 모델을 가지고 이를 실제로 실행될 수 있는 컴포지트 어플리케이션을 조립합니다. 모델 단계에서 정의된 서비스와 프로세스를 기존의 시스템으로 연결하거나 컴포넌트를 신규로 작성하여 실행 가능하게 만듭니다.
전개(Deploy) 단계
전개(Deploy) 단계에서는 작성된 컴포지트 어플리케이션을 운영 환경에 전개할 수 있습니다. 비즈니스 프로세스가 확장성 있고 보안이 강화된 서비스 환경에서 운영할 수 있도록 어플리케이션 서버 및 프로세스 엔진이 구성되어 있어야 합니다. 비즈니스 환경 변화에 대응하기 위해서 동적으로 업데이트가 이루어지는 유연선을 제공하면서 중요한 핵심 비즈니스 프로세스를 실행하도록 최적화하는 것이 중요합니다. 이러한 서비스 지향 접근 방식은 다수의 Point-to-Point 통합을 유지 보수하는 비용과 복잡성을 줄여줍니다.
관리(Manage) 단계
관리(Manage) 단계에서는 운영되는 컴포지트 어플리케이션의 운영 상황을 실시간으로 모니터링하여 정의된 서비스와 프로세스가 문제나 개선점이 없는지 판단하도록 합니다. 만일 개선해야 할 것이 있다면 다시 모델(Model) 단계로 가서 작성된 모델을 수정한 후 다시 조립단계, 운영 단계를 거쳐 다시 모니터링 하는 단계로 순환됩니다.
거버넌스(Governance)
이러한 전체 라이프 사이클은 거버넌스를 통해 관리 및 통제 됩니다. 전체 프로세스를 제어하고 각각의 서비스에 대한 비용 관리뿐만 아니라 서비스의 복잡한 서비스 사이의 관계를 정의하고 이들이 원활하게 운영될 수 있도록 통제합니다.
SOA 어플라이언스를 통한 성능 및 보안 해결
SOA 구현을 위한 고객의 가장 큰 걸림돌은 성능과 보안 처리입니다. SOA를 구현할 수 있는 현존하는 유일한 대안이 웹서비스라고 보면 벤더 사이의 상호운용성도 중요한 문제가 될 수 있지만 고객이 기존 어플리케이션 대신에 사용할 수 있을 만큼의 성능이 보장되는지 여부와 보안 처리가 가능한지 여부가 더욱 중요한 사항으로 판단되고 있습니다. 따라서 일부 벤더의 경우 SOA 어플라이언스를 도입하여 물리적으로 많은 시간이 소요되는 비즈니스 로직을 디비이스로 내리는 방법을 사용하고 있습니다. 디바이스가 WS-Security를 포함한 웹서비스 및 XML 보안 처리가 가능하다면 고객들이 SOA 도입에 걸림돌로 생각하는 문제점들을 상당 부분 해소시킬 수 있을 것입니다.
그림의 경우 실제로 인터넷 경매로 유명한 e-Bay에서 구축한 사례입니다. e-Bay의 경우 대부분의 데이터 처리가 XML 기반의 웹서비스로 구축되어 있었으며 XML 사이의 데이터 변환 요건이 실제 업무에서 차지하는 비중은 40% 이상이었습니다. 따라서 이 부분의 처리를 위해 4000개 이상의 웹 어플리케이션을 사용하고 있었습니다. 성능의 향상과 비용의 감소를 위해 e-Bay의 경우 어플리케이션에서 부하가 많이 걸리는 부분을 디바이스를 도입하여 해결하였는데, XML 변환 로직을 디바이스로 내렸기 때문에 성능 향상이 보장되었으며, 이를 통해 전체 웹 어플리케이션 서버의 40%를 감소시킬 수 있었습니다. 실제로 추가적으로 도입해야 할 하드웨어 및 소프트웨어의 가격과 디바이스의 도입에 따른 비용 비교를 해보면 그 차이는 자명합니다. 물리적으로 그 수가 줄어들 뿐만 아니라 네트워크 유선 속도에 준하는 성능 향상이 보장되기 때문에 해당하는 자원의 물리적인 감소를 가능하게 합니다.
SOA 어플라이언스의 기능은 아래와 같아야 합니다. 기본적으로 XML 변환의 기능을 보장할 수 있어야 하고, 표준 기반의 보안 기능을 처리할 수 있어야 합니다. 또한 대부분의 웹 어플리케이션에서 가장 부하를 많이 차지하는 XML 변환 및 보안에 걸리는 시간을 단축시킬 수 있어야 합니다.
위의 그림의 경우 일반적인 XML 처리 시에 부하가 걸리는 단계에 대해 표현한 것입니다. XML의 변환 및 암복호와에 대부분의 시간이 소요되는 것을 확인할 수 있습니다. 웹서비스 및 SOA 보급이 보편화될수록 성능 향상을 위해 위의 사항이 어떻게 지원되느냐가 벤더의 차별성으로 자리매김될 수 있습니다. 현재 일부 벤더에서 디바이스를 통한 SOA 구현이 실제화되고 있으며, 어플리케이션마다 차이가 있겠지만 일부 고객 파일럿 사례의 경우 30배가 넘는 성능 향상이 이루어졌습니다.