OPEN API 제공을 위한 SOA(Service Oriented Architecture)

[출처 : KTH, 2011년11월25일]

개요 : Open API, Library 기반의 Mash-up서비스/사업을 위한 System Architecture

요즘 OPEN API의 중요성이 대두되고 있다. 아마존, 페이스 북, 구글 등 유명 IT업체에서도 OPEN API를 발표하고 있고, 이를 통해 3rd 개발자들이 만들어 낸 신규 서비스들을 재판매(제공)함으로써 서비스의 규모를 키워가고 있다. 물론, 수익금은 3rd 개발자에게 돌려주는 에코시스템을 표방한다.

사내의 자원을 이용하는 OPEN API 자체도 중요하지만 OPEN API의 결과인 Mash Up 서비스를 재판매(제공)하여 유기적으로 서비스 규모를 키워가기 위해서는 프로세스와 데이터들이 통합되어 있고 변화에 유연하게 대처할 수 있는 서비스 중심 아키텍처(SOA) 구성도 중요하다.

  1. Time To Market 가능한 SOA(Service Oriented Architecture)의 의미
    SOA는 소유하고 있는 소스, Application, Platform, System, Infra등의 자산/자원을 재사용 가능한(독립적인) 서비스 단위로 분리하고, 다른 서비스 단위와 조합(orchestration)할 수 있는 인터페이스를 제공하도록 구성된 아키텍처이다. 또한, 서비스 단위를 실시간으로 조합하여 손쉽게 새로운 서비스를 만들어 내는 Time To Market 실현이 가능한 구조로 구축되어야 한다.SOA에서의 ‘서비스’와 ‘서비스 단위’의 의미는 아래와 같다.
    서비스 재사용하기 편리하도록 서로 독립적이어야 하고(낮은 결합도), 그것 하나로 하나의 서비스에 집중되어 있어야 하고(높은 응집도), 외부에 내부의 구성방식이 노출되지 않아야 하며(정보은닉->캡슐화) 이렇게 하려니 서비스간 결합을 통하여 확장이 용이하도록 제각각 Interface를 가지고 있는 것
    서비스 단위 독립적으로 제공될 수 있는 가장 작은 단위의 서비스. (어느 정도로 분할할지는 서비스 특성에 맞추어 결정해야 함. 기능 단위들의 조합)

    서비스 단위는 기능 단위와 동일한 개념이 아니다. 예를 들어, 사용자는 A라는 서비스를 인터페이스(API)를 이용하여 호출한 후 사용(다른 서비스와 조합하던지 아니면 그냥 하나만 사용하던지)만 하는 것이지, A서비스를 사용하기 위해 이런저런 판단(로직)이 필요해서는 안 된다.

2. 서비스 단위의 재사용이 가능한 SOA의 일반적인 구성
<전통적인 구현 방식과 SOA 구현 방식>

전통적인 구현 방식 시스템 구조 기반으로 설계 및 구현. 서비스 환경 변화 및 정책 변화에 대한 대응이 시스템 구조부터 고려되어야 하기 때문에 시간이 소요
SOA 구현 방식 서비스 단위로 분리. 서비스 환경 변화 및 정책 변화 시 서비스 단위들을 조합하거나 또는 신규 서비스를 유연하게 추가하여 신속한 대응이 가능 서비스 단위가 Interface로만 소통이 가능한 Black Box. 수정 시 영향도 적음

물론, SOA의 서비스 단위가 이렇게 유연해 지기 위해서는 아래와 같은 내부 구조가 필요하며, 아래의 관리, 통합, BI야 말로 SOA가 지향하는 바이다.

<SOA 구성도> 비즈니스 프로세스 관리 – 서비스 조합의 결과로 생긴 비즈니스 프로세스 모니터링. 위험감지 및 대응 – 시장 내외부 변화에 대응하는 정책 추가 시 서비스 단위의 재조합을 통한 비즈니스 로직 자동반영
데이터 및 Legacy System 통합 – 서비스 별로 독립된 이기종 DB의 DATA통합 및 활용 위한 Big Data관리. – Legacy System간 호환을 위한 미들웨어 제공
통계/위험관리/미래예측 Business Intelligence – 통합 된 프로세스와 DATA를 이용하여 통계 추출(DATA Warehouse), 환경변화에 따른 위험감지, 미래 예측(Data Mining) 가능하도록 구축

기존 시스템과 데이터 구조를 변경해야 하는 SOA는 더 많은 시너지를 내기 위해 전사적으로 수행해야 하면 그렇기 때문에 단계적으로 진행되어야 한다. 서비스 단위의 구축은 Buttom-Up이어야 하지만 SOA 기반 플랫폼으로의 변화 의지는 Top-Down 으로 진행되어야 한다.

3. 전사적으로 수행해야 하는 SOA 적용 단계

단계 목표 내용 성숙도
No SOA SOA 이해 SOA 필요성 정리 및 사례 연구 단일 비즈니스 프로세스,데이터 통합
SOA 정의 핵심 기능 서비스 단위로 표준화 단일 프로젝트,시스템 통합. 레거시 시스템 주요기능 서비스로 표준화
SOA 전개 이 기종 Legacy System 통합 동일 업무영역 통합. Composite Service 전사 프로세스, 데이터 통합
SOA 성숙 비즈니스와 IT환경 통합 전사 업무영역 및 시스템 통합 Service Orchestration프로세스 자동화 비즈니스 프로세스 자동관리
SOA 완성 변화에 실시간 대응 기업외부 업무영역 및 외부 시스템 통합 서비스 모니터링 및 실시간 반영Package Services Business Intelligence

요즘 우리 회사에서도 OPEN API의 필요성에 대해 많은 사람들이 얘기하고 있으며, 자연스럽게 데이터 및 중복된 시스템들과 업무들에 대한 통합 및 유연한 관리 그리고 데이터에 대한 활용까지 논의되고 있다. 따라서 우리 회사의 단계는 2단계인 SOA 정의 단계라 하겠다.

4. SOA 정의: 단일 비즈니스의 데이터와 프로세스 통합 예시
현재 내가 맡고 있는 비즈니스는 PHP기반의 웹 서비스(ollehmap.paran.com)이며 RDB와 연동되어 있다. 또한 다수의 외부 시스템 및 Legacy System 들과도 연동이 일어나야 한다. 난 향후에 진행 될 타 비즈니스와의 프로세스 및 데이터 통합에 손쉽게 대응하기 위해, 그리고 지속적인 서비스 개편 요청에 유연하게 대응할 수 있는 구조로 현재의 비즈니스 프로세스와 데이터를 통합할 계획이며 일부는 진행되고 있는 상황이다.간단하게 정리하면 개발자라면 누구나 알고 있을 흔하디 흔한 MVC모델을 비즈니스에 적용하는 것으로 SOA의 2단계인 SOA의 정의를 실천하고 있는 것이다. 좀 다른 점이 있다면 controller를 API형식으로 구현한 것이지만 자체적으로 판단해 볼 때 서비스 지향적인 API는 아닌 듯 싶어 개선이 필요하다.올해까지 계획되어 있는 단일 비즈니스의 2단계를 마무리 하면 전사 프로세스와 데이터를 통합해야 하는 3단계 SOA의 전개를 실시해야 한다. 이를 진행하기 위해 해야 할 일은 아래와 같다- 전사 단위 비즈니스의 SOA 정의 단계 완료
– 단위 비즈니스가 관리하는 데이터와 SOA정의 단계의 결과인 API, 프로세스 공유
– 중복되는 데이터, 프로세스, API 식별 및 정리
– 동일 시스템(Legacy System등)에 접근하는 Interface 표준화
– 단일 비즈니스의 서비스를 조합하여 가능한 비즈니스에 대해 Composite Service 구성

5. 맺음말
SOA 진행은 비즈니스(서비스) 외부를 개편하는 것이 아니라 내부인 플랫폼을 개편하는 것이기 때문에 “지금도 잘 돌아가는 걸 왜?” 라는 의문들이 항상 생길 수 있다. 따라서 전사적으로 SOA 필요성에 대해 홍보하고 함께 이해해 나가는 단계가 필요하다. OPEN API가 필요하다고 많이 얘기되고 있지만 제대로 된 OPEN API를 만들기 위해서는 기반이 되는 플랫폼이 잘 통합되고 변화에 유연하게 대처할 수 있도록 관리되고 있어야 한다. 우선은 본인이 담당하는 단일 비즈니스의 플랫폼 부터라도 SOA를 적용하여 개선해 보겠다는 의지가 필요하다.

(주)리화이트 대표 / CEO & Founder

Next Article다음, 모바일게임 플랫폼 도전…DeNA와 제휴