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


Archive»


 
 

Microservice architecture note

아키텍쳐 /SOA | 2014.08.20 16:37 | Posted by 조대협

MSA (Microservice Architecture) 

자료 수집


참고 자료

Ebay 아키텍쳐 : http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf

Netflix 아키텍쳐 : http://techblog.netflix.com/2013/01/optimizing-netflix-api.html

infoQ Microservice Architecture : http://www.infoq.com/articles/microservices-intro

MicroService 개념 http://microservices.io/patterns/microservices.html

Martin folwer : http://martinfowler.com/articles/microservices.html

Dzone microservice architecture : http://java.dzone.com/articles/microservice-architecture

Thought works의 PPT : http://www.infoq.com/presentations/Micro-Services

node.js로 apigateway 만들기 : 정리 잘되어 있음. http://plainoldobjects.com/presentations/nodejs-the-good-parts-a-skeptics-view/


Conway's 법칙에 연관됨

You build, You run - Devops, Amazon

De-Centralized governance - 기술 표준화 보다는 다양한 기술을 허가. Microserice들을 스크립트 언어로 빠르게 만들어 버림. 

Cross platform, Self organized team 모델 지향 - Align 되기전에 Self organized로 이동되면. 망함. 

운영이 HELL이다. 높은 운영 능력, 장애 처리, Devops 필요.



==> 공감 x 100배 (나만 겪는 문제가 아니구만..)

ESB (Enterprise Night Bus.. ) 


저작자 표시
신고

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

Microservice architecture note  (0) 2014.08.20
Open API design  (0) 2013.07.06
통신 사업자의 SDP의 필수 컴포넌트  (0) 2010.08.03
SDP (Service Delivery Platform)  (1) 2009.09.15
모차세대 시스템의 WAS 아키텍쳐 Blue Print  (8) 2009.07.30
EAI관점에서 본 SOA  (6) 2009.07.29

Open API design

아키텍쳐 /SOA | 2013.07.06 13:14 | Posted by 조대협

OPEN API Design Consideration Point


1. API Type 

Internal APIs

Internal System in same network

User for internal user or authorized user

 

External APIs

for Public Developer

Developer Support is key point

 

for Partner

- Business value is key

 

2. API Design Best Practice

Easy to use

with out documentation, API should be easy enough to use.

Easy to Try and use

For private APIs, it is important to demonstrate real value in running a system or app off of the API

public APIs, one approach is to offer some level of free access. Many developers won’t even consider using your API if there are only paid options. At this point in the customer acquisition cycle, the developer may not know if your API meets their needs or if their app’s business model will support paid access.

 

Diffentiate API

Ÿ   The data is unique, more complete, or more accurate than that of your competitors

Ÿ   You offer better support or an easier signup process

Ÿ   Your API is more robust, reliable, cooler, or faster than alternatives

Ÿ   Your terms are more developer friendly; perhaps you offer more data traffic for free or at better rates

Provide mandatory functionality first time and enhance later

There are other aspects of simplicity that can help make your API easier to adopt. One success factor is to stick to conventions that the developer might already know

Target Specific Developer Segment 

3. Technology Selection

REST API

pragmatic REST API design

Figure 1 Wrong design for shopping cart

 

Figure 2 Good design for shopping cart

Binary protocol

Ÿ   Protocol Buffer

Ÿ   Thrift

 

Versioning

Having mediation layer like ESB

4. Security

Identification

- grant access by using API Key

Authenticate

- Determine who is accessing API.

Ÿ   User name & password

Ÿ   Session based

After log in with user name & password, session token key will be issued. with the session key authentication can be passed

Ÿ   Standard way

SAML

OAuth

 

Authentication vs Identification

Identification based API provides same functionalities and data to client.

Authentication based API provides user dependent data to client

Encryption

use SSL (can be attacked by Man in middle attack)

partial or all message encryption

 

Threat Detection and prevention

 

General recommendation of Security

API Keys for only nonsensitive & read-only data.

Use OAuth 2.0 for more sensitive authentication

use SSL for everthin sensitive data.

Sanitize incoming and outgoing data - prevent javascript attack and SQL attack. (especially in writable API)

 

5. Legal Consideration

 

Consideration point

- What content will be provided

- What right can u or do u want to grant the consumer of API

- Are they have different level of API access?

 

Perspective

Ÿ   Contract & Terms of Use

Ÿ   Privacy Policy

Ÿ   Data retention policy

 

6. API Operation

Monitoring

Throttling (Traffic management)

Depends on contract & consumer, API traffic can be managed. It is important to monetization

Reporting

SLA

Issue management

Internal operation issue tracking

Support

Ÿ   Issue management & ticketing

Ÿ   Documentation

Ÿ   Sand box

 

7. API Measurement

Effectiveness measurement - call per day

Effective measurement - call per day, call per client (by region ,model etc)

Performance measurement - response time

 

 

 참고

http://www.layer7tech.com/

http://www.apigee.com

 

 

저작자 표시
신고

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

Microservice architecture note  (0) 2014.08.20
Open API design  (0) 2013.07.06
통신 사업자의 SDP의 필수 컴포넌트  (0) 2010.08.03
SDP (Service Delivery Platform)  (1) 2009.09.15
모차세대 시스템의 WAS 아키텍쳐 Blue Print  (8) 2009.07.30
EAI관점에서 본 SOA  (6) 2009.07.29

통신 사업자의 SDP의 필수 컴포넌트

아키텍쳐 /SOA | 2010.08.03 00:24 | Posted by 조대협

오늘 본사에서 TMFORUM.ORG의 자료(http://www.tmforum.org/ResearchPublications/EvolvingSDPsEssential/7721/Home.html)와 SDP 시장 전망등에 대한 자료들을 찾아서 읽고 있는데, 대충 지금까지 알아왔던 내용과 방향은 비슷하지만 정리가 상당히 잘되어 있고, 약간 발전된 모습을 보인다.
잊어먹기전에 얼른 몇가지 정리해보면

기본적으로 SDP는 Telco 기반의 SOA 플랫폼으로 서비스의 생성과, 실행,배포등을 담당한다.
특히 3'rd party나 외부로 service를 expose할 수 있는 기능을 가져야 하며
필수 서비스 컴포넌트로는

  • 사용자 프로파일 관리
  • 디바이스 관리
  • 컨텐츠 관리 및 서비스 (CMS & Contents Service)
  • 과금
  • LBS (Location Based Service)

이 있으며, 특이한것은

  • 사용자 이용 내역을 통한 소비자 패턴 추적 (일종의 CRM + BI)
  • 타겟 광고 시스템
  • 애플리케이션 스토어

이다.

SDP는 뚜렷한 표준이나 아키텍쳐, 제품이 없고, 일반적인 사상이지만 위와 같은 공통점을 가지고 있으며, 벌써 세계적으로 300여개의 SDP가 존재한다고 하지만, 제대로 된건 몇개나 있을까 싶다. 사실..
그만큼 난이도가 높고, 기술적으로나 비지니스면에서 고려가 필요한 아키텍쳐이기 때문이다.

아!! 그리고 빼먹은거 한가지.. SDP는 아키텍쳐 설계에 앞서서, 비지니스 파이프라인을 먼저 설정하는게 우선 (비지니스 아키텍쳐와 Revenue Stream)

신고

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

Microservice architecture note  (0) 2014.08.20
Open API design  (0) 2013.07.06
통신 사업자의 SDP의 필수 컴포넌트  (0) 2010.08.03
SDP (Service Delivery Platform)  (1) 2009.09.15
모차세대 시스템의 WAS 아키텍쳐 Blue Print  (8) 2009.07.30
EAI관점에서 본 SOA  (6) 2009.07.29

SDP (Service Delivery Platform)

아키텍쳐 /SOA | 2009.09.15 17:24 | Posted by 조대협

Byungwook.Cho
Principal Consultant/Oracle Korea

Initiative

요즘 통신 업계의 트렌드 중의 하나가 SDP(Service Delivery Platform)이다.

현재 통신 업계는 크게 두가지 도전과제를 안고 있는데, 급격한 비즈니스 환경 변화와 기술적인 변화이다. 통신 업계는 현재 매우 빠른 속도로 변화하고 있다.

 구글의 안드로이드,애플의 IPHONE,심비안,림의 블랙베리,윈도우 WM등 수많은 플랫폼들이 쏟아져 나오고 있고 AppStore와 같은 오픈 마켓을 통해서 모바일 기반 애플리케이션들이 판매되고 있다. 또한 단순한 전화통화와 SMS 메세징에서부터 글로벌 로밍,영상통화,VoIP,모바일 인터넷까지 모바일 시장 초반에는 상상할 수 없을 정도로 빠른 속도로 비즈니스와 기술적인 변화를 겪고 있다. 이런 변화를 수용하기 위해서 통신 업체는 많은 silo (다른 시스템과 독립된) 시스템들을 개발해왔고, 또한 시스템간의 통합(Integration)을 해왔다. 그러나 시스템들이 많아지면서 통합해야 할 대상은 더욱더 많아지고 통합에 요구되는 시간도 짧아짐에 따라 더 이상 현재의 방식대로 Ad-Hoc방식의 통합이나 개발이 어려워 지게 되었다.

 이런 이유로 통합된 하나의 통신 플랫폼이 필요하게 되었는데 이것이 SDP (Service Delivery Platform)이다.

 기존의 나뉘어져 있던 모든 통신 애플리케이션을 하나의 통일된 형태의 프로토콜과 표준으로 통합하여 플랫폼으로 구축하여 시스템간의 통합을 신속하고 자유롭게 하고, 비즈니스의 변화에 유연하고 빠르게 대응하기 위함이다

SDP SOA Telco 버전

사실 SDP의 개념 자체는 매우 단순하다. 한마디로 이야기 하면 “Telco 버전의 SOA”로 정리된다. 기존의 전통적인 SOA아키텍쳐를 보면, 레거시 시스템을 통합하기 위해서 JCA아답터들을 사용하였다. 이 아답터들은 Legacy 프로토콜 (MQ, SAP, PeopleSoft etc)를 이용하여 Legacy 시스템과 통신하여 그 기능을 SOA 인프라쪽으로 enablement 해주는 역할을 하였다. 이런 아답터를 이용함으로써 여러 종류의 Legacy 시스템을 하나의 통일된 서비스 표준으로 운영할 수 있었던 것이다. SDP역시 그 원리는 똑같다. 기존 SOA가 아답터를 통해서 Legacy 시스템을 통합했다면, SDP는 아답터를 통해서 Legacy Network Application을 통합한다. Telco 시스템에는 SIP,VoIP,Paray,SMSC등의 다양한 프로토콜에 종속된 애플리케이션들이 존재한다. 이러한 애플리케이션들을 네트워크 아답터를 이용하여 통합된 메시지 형태를 사용하도록 하고 SOA 사상위에 통합함으로써, SDP의 목적을 달성할 수 있는 것이다

 전통적인 SOA 시스템과의 또 다른 차이점은 SDP는 기본적으로 B2C 서비스 시스템이라는 것이다. 전통적인 SOA가 기업의 내부 업무를 위해서 주로 디자인 되었다면, SDP는 사용자와 Interaction하는 업무를 중심으로 디자인된다. 이는 좀더 많은 사용자를 커버해야 하고, 빠른 사용자 응답 시간을 요구하고 아키텍쳐의 단순성을 요구한다는 의미이다

일반적인 SDP 아키텍쳐

SDP는 다음과 같이 크게 3가지 계층으로 나뉘어 진다.

 

Service Enablement

이 계층의 역할은 다양한 기술 플랫폼과 통신 프로토콜을 사용하는 기존의 시스템들을 SDP의 표준 컴포넌트 형태로 변환해주는 역할을 한다. 크게 두가지 관점으로 생각할 수 있는데, 첫번째는 Network Abstraction이다.

 다양한 Telco의 네트워크 프로토콜(SMSC, SIP etc)를 추상화 하여 SDP내부의 공용 프로토콜로 추상화 하여 제공한다.

 두번째는 기존의 비즈니스 애플리케이션 (과금, 파트너 관리)의 기능을 통합할 수 있게 공통된 서비스 형태로 Expose하여 SDP에 연결하는 기능을 제공한다. 예를 들어 과금 기능이 사내 ERP의 재무 모듈과 연동할 수 있게해주는 연결고리 역시 SDP의 기능이다

Service Component

 서비스 컴포넌트는 SDP의 고유한 기능을 제공하는 컴포넌트이다.특히 Telco쪽에 특화된 기능을 제공하는데, 대표적인 기능으로는 Billing,Charging,파트너 관리, 컨텐츠 관리, 사용자 프로필 관리,Location Based Service등이 된다.

 이러한 컴포넌트들은 Telco 솔루션 기반으로 제작되거나 Telco 내부에서 Inhouse로 개발되는데, 이 컴포넌트들은 Service Component라는 형태로 Abstract되어서 SDP 내부에 존재하게 된다.

 Service Exposure

 Service Component에 의해서 제공되는 기능들은 Service Exposure 계층을 통해서 외부로 서비스 된다. 이 계층에서는 컴포넌트에 Cross Cutting Concerns(공통 기능)을 가미하고, (빌링,Authentication/Authorization, SLA 관리, Logging/Audit) 하부 컴포넌트를 묶어서 (Orchestrate)해서 새로운 기능으로 Expose하는 기능을 수행한다.

 이 계층은 전통적인 SOA 사상으로 구성된다. ESB를 통한 단일 Access point를 제공하며, BPM을 통한 Long-running process에 대한 Orchestration등을 제공하게 된다.  기존의 SOA Reference Architecture와 큰 차이가 없기 때문에 이 부분에 대한 설명은 생략한다.

 

결론

SDP는 크게 보면 Telco 에 전문화된 SOA 플랫폼이다. Telco의 많은 통신 프로토콜을 Abstract하여 통일된 형태로 관리하여 통합을 자유롭게 하고 이로 인해서 비즈니스에 대한 빠른 적응을 가능하게 해준다. 또한 빌링이나 사용자 관리와 같은 공용 비즈니스 컴포넌트를 내재하여 중복 개발을 방지하고 시스템의 재사용성을 극대화 하며, 기존의 비즈니스 시스템 (ERP, CRM)과 연결할 수 있는 연계점을 제공하여 Telco의 전반적인 Infrastructure로 자리 잡을 수 있다.

 

저작자 표시
신고

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

Open API design  (0) 2013.07.06
통신 사업자의 SDP의 필수 컴포넌트  (0) 2010.08.03
SDP (Service Delivery Platform)  (1) 2009.09.15
모차세대 시스템의 WAS 아키텍쳐 Blue Print  (8) 2009.07.30
EAI관점에서 본 SOA  (6) 2009.07.29
SOA를 공부하세요. 최고입니다.  (4) 2009.07.04

OO 차세대 시스템

WAS Architecture Blue Print (DRAFT)  

2009-06-28

Oracle Korea Consulting

Principal Consultant

Byungwook Cho (byungwook.cho@oracle.com)

 

 

Overview

본 아키텍쳐는 OO 차세대 시스템을 위한 웹로직 구성 아키텍쳐이다. OO 아키텍쳐 요구 사항에 따라서 구성한 아키텍쳐로 다음과 같은 전제 조건을 기반으로 한다. Ÿ          웹로직을 중심으로 설계할것           클라이언트는 웹이 아닌 윈도우 애플리케이션을 사용한다.

    100개의 웹로직 인스턴스가 동시 운영 될것으로 예측된다.         총 업무는 A업무 (4개), B관리 (4개), C관리 (4개) 로 구성된다.Ÿ          하드웨어는 IBM P6 시리즈를 사용하며, 총 예상 CPU수는 52장이며, 하드웨어 가상화 기능을 제공한다. 

Architecture Principals

본 아키텍쳐의 설계 기본 원칙은 다음과 같다.

1. 안정성

장애가 발생하였을 때도 장애 업무 이외의 업무는 정상적인 수행이 가능해야 하며 타 업무로 그 영향을 전파해서는 안된다.

2. 확장성

비즈니스 상황에 따라서, 전체 시스템의 용량 (동시 사용자수)나 기능 (서비스 수)를 아키텍쳐의 변화 없이 쉽게 확장할 수 있어야 한다.

3.유연성

비즈니스 변화에 대해서 유연하게 대처할 수 있어야 한다.

 

Conceptual Architecture

위의 세가지 Principal을 기반으로 설계된 Conceptual Architecture는 다음과 같다.


Application Grid

애플리케이션 그리드의 개념은 여러 개의 하드웨어를 모아서 비즈니스 로직을 제공하는 단일된 형태의 애플리케이션 집합체이다. 외부에서 보기에는 하나의 애플리케이션 집합체로 보이며 단일 접속점 (End Point)을 가지지만 실제로 내부에는 여러 개의 애플리케이션이 분리된 하드웨어에 분리된 형태로 배포되어 있다.

 하드웨어 가상화 개념을 응용하여 그리드 내부에서 업무의 비중과 중요도에 따라서 하드웨어 자원을 동적으로 재 배정하여 자원 사용의 효율성을 극대화 한다.

 새로운 기능이 추가될 때 마다 컴포넌트를 애플리케이션 그리드에 꼽는 (PLUG IN)하는 개념으로 비즈니스 컴포넌트를 추가할 수 있으며, 애플리케이션 그리드의 Infrastructure에는 그리드를 관리하기 위한 운영,관리,모니터링 기능(이하 OAM) 이 구현되어 있기 때문에, 개발자는 비즈니스 로직에만 집중하여 개발한후 그리드에 배포하면 OAM은 Infrastructure에 의해서 관리된다.

 

애플리케이션 그리드 아키텍쳐는 계층에 따라서 하드웨어/미들웨어(웹로직)/웹서버 3개의 계층으로 나뉘어서 분리된다.

 

(1)   하드웨어 아키텍쳐

하드웨어는 IBM AIX 중에 가상화를 지원하는 하드웨어를 사용한다. 가상화는 하나의 하드웨어내에 있는 여러개의 CPU와 메모리를 분할하여 사용할 수 있는 기능이다. 즉 하나의 하드웨어 자원을 조각으로 나누어서 업무별로 할당이 가능하다.

 

하드웨어 아키텍쳐 구성시에, 작은 하드웨어 여러 개를 사용하는 것보다, 가상화가 가능한 큰 하드웨어를 사용하는 것이 유리하다. 일반적인 국내 차세대 시스템의 경우 오픈후에, 안정화 기간을 거치면 통상적으로 CPU 평균 사용률이 40% 이하로 제대로 구성된 아키텍쳐에서는 20~30%대로 사용되는 경우가 많다. 반대로 부하가 몰리는 서버의 경우 CPU 사용률이 70~80%까지 육박하는 경우도 있다. 이러한 경우, CPU나 메모리 자원에 대한 효율적인 분할을 하기 위해서는 하드웨어를 물리적으로 옮겨서 새로 소프트웨어 시스템을 설치해야 하는데, 이 과정은 많은 시간과 검증 작업을 요구하며 또한 소프트웨어 라이센스 측면에서 문제를 유발할 수 있다. (하드웨어 추가는 소프트웨어 라이센스의 추가 구매를 의미한다.)

 이런 비효율성은 반대로 가상화를 지원하는 하드웨어를 사용했을 때 쉽게 해결된다.  업무의 부하량에 따라서 동적으로 CPU 자원을 재할당 하여 업무 부하에 적절하게 대응할 수 있고 CPU 재할당의 경우에도 별도의 하드웨어 작업(CPU를 빼서 다른 서버에 옮기는등의)이 없이 소프트웨어적인 설정만으로도 가능하기 때문에, 변경에 대한 영향도를 최소화 할 수 있다.

 

(2)   웹로직 구성 아키텍쳐

웹로직 구성상에 있어서는 다음과 같은 원칙을 따른다.

업무당 하나의 웹로직 도메인을 사용하며,하나의 도메인은 여러 개의 클러스터를 가질 수 있으며, 각 클러스터는 여러 개의 Managed Server로 구성된다. 각 Managed Server에는 1개 이상의 업무 애플리케이션이 배포될 수 있다.

 

1) 서버 분리를 통한 장애 전파성 제거

자바 기반의 장애 특성은 턱시도와 같은 TP Monitor와 다르게 모든 업무가 하나의 프로세스에서 돌아가는 특징을 가지고 있다. 이로 인해서 장애가 발생할 경우, 같은 프로세스에서 돌고 있는 다른 업무에도 영향을 줄 수 있다. (TP Monitor의 경우 업무별-SERVER로 프로세스가 나뉘어져서 기동되기 때문에 장애가 다른 업무에 전파되지 않고 국지화될 수 있는 장점을 가지고 있다.) 이와 같은 문제를 해결하기 위해서 WAS에서 여러가지 Work Manager나 Thread Pool 분리와 같은 여러가지 기능을 제공하는데, 이 역시도, 메모리 과사용이나 CPU 과 사용등에 대한 문제에서는 자유로울 수 없다.

 

가장 올바른 아키텍쳐 설계 방안은 TP Monitor와 같은 원리로, 업무별로 Manager Server를 분리하여 장애시 타 업무에 대한 장애 전파성을 제거하는 것이다.

 

2) 관리 포인트 증가에 대한 해결 방법

Managed Server를 업무별로 분할하여 운영할 경우, 그 만큼 많은 Managed Server가 운영되게 되고, 이는 관리 포인트의 증가로 귀결된다. 이런 관리상의 문제점을 해결하기 위해서, 웹로직을 클러스터링 기능을 사용할 수 있다. 클러스터링에서는 여러 개의 Managed Server가 있더라도 클러스터 단위로 configuration을 반영할 수 있는 기능이 있기 때문에, Managed Server의 수가 증가하더라도 실제로는 클러스터의 단위로 관리를 할 수 있기 때문에 관리에서 오는 복잡도를 감소 시킬 수 있다.

 

3) 클라이언트를 통한 상태 관리

업무별로 Managed Server를 나누는 경우 발생하는 문제점중의 하나가 Managed Server간에 Session이나 상태 정보가 공유가 안되는 문제점을 가지고 있다. 그러나 고객의 아키텍쳐 설계의 Assumption은 윈도우 클라이언트 기반의 Rich Client를 사용하기 때문에, 상태나 사용자 정보를 클라이언트에서 관리하도록 설계하여 서버간의 정보 공유를 서버에서 클라이언트로 이관함으로써 이를 극복할 수 있다.

 

(3)   웹서버 아키텍쳐

1) Endpoint에 대한 Location Transparency 의 제공

본 아키텍쳐에서 웹서버는 Application Grid로의 End point를 단일화 시켜주는 중요한 역할을 한다. Grid내의 여러 개의 Managed Server의 주소로 클라이언트가 직접 접근하는 것이 아니라 업무별로 배정된, 웹서버라는 단일 접속점을 통해서 Grid내의 Managed Server로 접근할 수 있게 해준다. (이는 Grid내의 Managed Server의 수가 증가하거나 감소하더라도, 접속점에 대한 변경을 없게 하여 Location Transparency를 보장할 수 있게 한다.)

 

2) 유연한 배포 구조의 제공

본 아키텍쳐에서의 웹서버 구성은 하나의 업무에 대해서 두 이상의 웹서버와 하나의 L4를 사용하도록 구성되어 있는데, 이는 애플리케이션의 배포의 용이성을 제공하기 위해서이다.

WAS의 기능에 상관없이 애플리케이션 개발과정상의 실수에 의해서 REDEPLOY 과정에 많은 문제를 일으킬 수 있는데, 이로 인해서 가장 좋은 REDEPLOY 방법은 DEPLOY후 RESTART하는 것이 가장 좋은 방법이다. 그러나 이 경우 해당 업무가 일시적으로 정지될 수 있는 위험도를 가지고 있기 때문에, 이 다운 타임을 최소화할 수 있는 아키텍쳐 설계가 필요하다.

2개의 웹서버중 하나의 웹서버를 다운 시키면 L4에 의해서 반대쪽 웹서버로만 부하가 가게 되고, 웹서버가 다운 되었기 때문에, 그에 연결된 Managed Server들은 사용자로부터 REQUEST를 받지 않는 상태가 된다. 이 상태에서 애플리케이션을 재배포한후 서버들을 재기동 시킨후, 반대족 웹서버도 번갈아서 같은 방식으로 재기동을 하게 되면 운영중에도 가장 안전한 방법으로 업무에 대한 정지 없이 재배포가 가능하게 된다.

 

Application Grid OAM (Operation, Administration, Monitoring)

OAM 기능은 애플리케이션 그리드에 대한 운영,관리, 모니터링 기능을 제공하는 인프라이다. 비록 고객의 요구 사항에서는 웹로직만으로 구성하는 것을 요청했으나, 아키텍쳐의 완성도를 위해서 OAM 모듈에 대한 기능을 추가하였다.

 

Configuration 관리

고객의 요구사항중의 하나는 100개이상의 웹로직 인스턴스를 운영 및 관리해야 한다. 비록 클러스터링을 통해서 관리 포인트를 줄일 수 있는 형태로 설계했지만, 많은 인스턴스에 대한 Configuration 관리는 매우 도전적인 과제중의 하나이다.

Oracle 제품중에 ACC (Application Configuration Console)은 단일 Console을 통해서 여러 Managed 서버와 도메인 그리고 클러스터에 대한 관리를 가능하게 해주며, Configuration에 대한 이력관리등을 통해서 애플리케이션 그리드에 대한 하나의 관리 기능을 제공한다.

 

시스템 상태 모니터링

전체 그리드에서 시스템의 상태를 일목요연하게 볼 수 있는 기능이 필요하다. CPU 사용률, 애플리케이션 관점에서의 병목 구간, Thread 상태, 응답 시간등에 대한 모니터링 기능이 필요한데, 이는 APM (Application Performance Monitoring)을 통해서 가능하다.

 

업무별 상태 모니터링

시스템 상태 모니터링이 애플리케이션 관점(기술 관점)이라면 업무별 상태 모니터링은 비즈니스 관점에서 애플리케이션 그리드를 모니터링 하는 것이다.

 업무별 응답시간, 사용률, 장애율등을 Oracle BAM (Business Activity Monitoring)을 이용하여 그래프로 가시화 하여, 업무의 운용 상황을 한눈에 파악할 수 있도록 한다.

 

Features

Application Grid 아키텍쳐의 특징을 다시한번 정리해보면 다음과 같다.

 

장애 전파 방지 

Ÿ          Managed Server 분리를 통한 장애 전파 방지

업무별로 Managed Server를 분리하여, Dead Lock이나 Lock 경합으로 인한 장애 전파 또는 메모리 과사용으로 인하여 다른 업무에 영향을 주는 요인을 제거하였다.

Ÿ          하드웨어 자원 분리를 통한 장애 전파 방지

기존 WAS 아키텍쳐에서는 JAVA 프로세스를 분리하더라도, 실제 CPU나 메모리등의 하드웨어 자원을 공유해왔기 때문에, 한 프로세스가 CPU를 과점유하기 시작하면 정상적인 다른 프로세스에게도 영향을 줬다.

그러나 이 아키텍쳐에서는 업무에 따라서 하드웨어 자원을 분리하여 할당하기 때문에,특정 업무가 CPU를 과점유한다하더라도, 다른 업무용으로 배정된 CPU 자원을 사용할 수 없기 때문에, 하드웨어 자원 점유에 의한 장애 전파를 방지한다.

유연하고 최적화된 하드웨어 리소스 운영

Ÿ          Managed Server의 수 조정을 통한 자원 배분

시스템의 사용량이 늘어날 때, 사용량이 늘어난 업무에만 Managed Server의 수를 늘려서 하드웨어 자원의 사용을 최적화 할 수 있다. 반대로 사용량이 적은 업무의 경우 Managed Server의 수를 줄여서 잉여된 자원을 다른 업무에 배정하여 전체 Application Grid의 하드웨어 사용 효율성을 극대화 한다.

Ÿ          가상화를 통한 CPU 및 메모리에 대한 유연한 배분

해당 업무에 메모리 사용량이 높거나 CPU 사용량이 높을때는 하드웨어 가상화 기능을 통해서

메모리 크기 한계 극복

Ÿ          업무별 분리를 통한 메모리 사용성의 극대화

자바 애플리케이션은 구조상의 한계상 통상적으로 1.5GB의 메모리만이 사용가능하다. (최대 3G). 그래서 사용자 수가 늘어나는 경우에는 전체 부하를 여러 개의 인스턴스로 분산 시켜서 메모리 사용량을 낮추어야 하는데, 이 아키텍쳐에서는 간단하게 Managed Server의 수만 늘려주는 것만으로 메모리에 대한 부하를 손쉽게 분산 시킨다.

       참고 : Managed Server 분리에도 불구하고, 더 많은 양의 메모리가 필요한 경우에는 Coherence Data Grid를 이용하여, 메모리 확장을 고려할 수 있다.

 

확장성 

Ÿ          웹서버를 이용한 Location Transparency의 제공

업무의 종류나 부하량 또는 사용자가 증가하는 것에 상관없이, 새로운 업무는 Application Grid에 추가로 배포될 수 있으며, 시스템의 용량도 하드웨어 증설만으로 큰 설정 변경 없이 손쉽게 증설이 가능하다. 시스템이 확장되더라도 Grid 밖에서 보기에는 동일한 End Point를 통해서 접근하는 것이기 때문에, 확장이 기존의 애플리케이션에 영향을 주지 않는다.

애플리케이션 배포의 유연성 

Ÿ          웹서버와 L4를 이용한 무정지 Clean redeploy 제공

앞서 설명한 바와 같이 L4와 2개 이상의 웹서버 구성을 통해서 가장 안전한 방법 (RESTART)으로 운영중 무정지 재배포를 지원한다.

 

저작자 표시
신고

EAI관점에서 본 SOA

아키텍쳐 /SOA | 2009.07.29 23:16 | Posted by 조대협

EAI관점에서 본 SOA

 

2009-07-29

Oracle Korea/Principal Consultant

Byungwook.Cho (byungwook.cho 골뱅이 oracle.com)

 

SOA(Service Oriented Architecture) 에 대한 접근 방법은 BPM을 이용한 비즈니스의 민첩성 확보나 비즈니스의 서비스화를 통한 재 사용성등에 초점이 맞추어져왔다.

 BPM을 통한 민첩성 확보등은 실제 비즈니스에서 그만큼 변화가 다양한 업무 요건을 필요로하고 BPM으로 구현할 만큼 긴 프로세스가 정리되어 구현될 프로세스가 많지 않다. [ 사실 BPM으로 전체 프로세스를 시스템화 한다는 것은 상당히 힘든일이다. 그만큼 변화나 융통성이 많이 필요하기 때문인데, “일례로 XX과장님 무슨 업무 처리 부탁드립니다.” 와 같은 이메일이나 업무 협조 요청등을 통해서 일어나는 정형화되지 않은 프로세스도 있기 때문에 업무 절차에 대한 정리가 선행되야 BPM 도입시 효과를 볼 수 있다. ]

또한 재사용에 대한 문제 역시, 소프트웨어 공학론에서 수십년 전에서부터 언급되어 온 만큼 쉬운일이 아니다. 인터페이스를 통일하고 비즈니스 단위로 서비스를 만들어서 재사용을 하려면 상당히 고도화된 수준의 디자인 노하우가 필요하다.

그렇다면 SOA를 도입하는 데 있어서 다른 장점은 없을까? 그 중 하나가 통일된 인터페이스를 이용한 애플리케이션간의 통합을 SOA를 통해서 구축할 수 있다.

 

EAI (Enterprise Application Integration)

먼저 전통적인 애플리케이션간의 통합 방식인 EAI에 대해서 살펴보도록 하자.

1990년대에 인터넷의 활성화와 비즈니스의 IT 시스템의 도입이 가속화되면서 기업의 업무들은 급속하게 IT 시스템으로 구축되었다. ERP,CRP,PLM 등등 업무 부서별로 또는 비즈니스 영역별로 시스템들이 구축되었다.

 구축이 완료되고 시스템이 운영되기 시작하면서 문제가 발생되기 시작했다. 업무 시스템들이 서로 분리가 되어 있고, 업무에 대한 데이터가 서로 다른 시스템에 분리되서 관리되었던 것이다.

 물류 와 구매시스템에서 발생한 회사의 수입과 지출 내역이 회사의 회계 시스템과 분리되서 관리되었고 이로 인해서 각 시스템간의 데이터를 맞추는 작업이 수작업이나 또는 기타 원시적인 방법으로 진행되었다. 그러한 과정에서 실수도 발생을 하고 효율과 경영 여건에 대한 민첩성도 떨어지게 되었다.

업무간의 연계를 위해서 각각의 업무시스템을 P2P 형식으로 연결하기 시작했지만, 방대한 데이터에 대한 안정성,성능 그리고 모니터링등 여러가지 문제가 발생하였고, 이러한 애플리케이션간의 연동만을 전문으로 하는 아키텍쳐와 솔루션이 필요하게 되었는데 그것이 바로 EAI이다.

분리된 각각의 IT 시스템을 연결할 수 있는 인프라를 제공함으로써 전체 IT 시스템들의 유기적인 결합을 가능하게 하는 개념이다.

 

EAI의 통합상 문제점

그런데 이러한 전통적인 방식의 EAI는 통합 방식에 있어서 몇가지 문제를 가지고 있다.

그 중 하나가 통합 인터페이스의 문제이다. 통합하고자 하는 애플리케이션의 인터페이스를 이용하기 때문에, 통합이 발생할 때 마다 별도의 통합 프로그램을 구축해야 한다.


예를 들어 3개의 시스템을 서로 통합하고자 할 때, 각 업무 시스템별로 하나의 인터페이스만을 가지고 통합한다고 해도, 시스템의 인터페이스 방식이 틀리기 때문에 총 3개의 연결이 필요하다. 업무가 4개로 늘어나면 6개의 형태의 인터페이스 타입이 5개로 늘어나면 10개로 업무 시스템의 개수가 늘어나고 통합하고자 하는 기능의 수가 늘어날수록 통합 프로그램의 수는 급격하게 증가하게 된다.

 이는 통합 프로그램의 구현에 드는 자원과 이에 따른 관리 문제를 만들게 되고 특히 업무시스템 담당 부서간의 커뮤니케이션에 드는 노력을 급격하게 증가 시킨다.

 EAI 프로젝트의 경우 통합 하고자 하는 양쪽의 시스템의 현업 담당자들이 서로 인터페이스를 협의하고 메시지 타입을 협의하고, 연동할 인터페이스를 구현해야 하며 이에 대한 테스트를 수행해야 한다. 이 과정은 송신 시스템,EAI 시스템,수신 시스템 3개의 업무 부서가 관여하기 때문에, 커뮤니케이션에 소요되는 시간과 비용이 통상적으로 예상할 수 있는 범위를 넘어선다.

 

또한 기존 시스템들이 교체 되었을 때, 교체된 시스템의 인터페이스를 전면 교체해야 하는 작업이 발생한다. 그리고 EAI 시스템은 별도의 시스템들을 Native 인터페이스를 이용해서 연결하는 것이기 때문에, 각 시스템에 대한 전문 지식과, 타 업무 부서와 일하기 위한 프로세스, 그리고 연동 프로그래밍에 대한 능력등을 갖춘 개발자가 필요하다. 즉 인력이 교체될 때 높은 Learning Curve 와 Education Cost가 필요하게 된다는 것이다.

 

 

이러한 EAI의 문제는 각 시스템간의 인터페이스가 통일되어 있지 않고 호환되지 않기 때문에 발생하게 되는 것이다.

 

SOA를 이용한 통합

 

그러면 전통적인 EAI가 가지고 있는 문제를 해결하자면 어떻게 해야할까? 앞에서도 언급했듯이 이런 문제는 인터페이스의 비호환성에서부터 발생한다. 즉 해결 방식은 인터페이스 방식을 통합하는 것이다.

 

웹서비스나 CORBA등의 통합된 인터페이스 방식을 이용해서 모든 시스템들이 통신하게 되면 시스템이 바뀌었을때도 동일한 형태의 인터페이스를 노출해주면 되고, 중간에서 연동을 하는 입장에서도 여러 플랫폼에 대한 기술을 이해할 필요없이 하나의 표준 인터페이스 기술을 사용하면 되기 때문에 인력 운용면이나 Learning Curve 면에서도 여러가지 장점을 가질 수 있게 된다.

 

SOA와 EAI의 융합

그러면 EAI 는 더 이상 쓸모가 없는 것 일까? EAI는 통합에 있어서 SOA와 다른 관점을 가지는 만큼 다른 장점 또한 제공한다.

 

Tightly Coupled 통합

EAI는 통합 대상이 되는 애플리케이션에 대한 Native 인터페이스를 이용하기 때문에, Tightly Coupled 된 통합이 가능하다. 이 말은 애플리케이션간의 분산 트렌젝션과 같은 저수준의 통합을 가능하게 해준다는 것이다.

 특히 여러 개의 애플리케이션을 묶어서 하나의 서비스 기능으로 도출하고자 할 때, EAI내의 work flow 기능들을 이용하여 대상 애플리케이션들을 composite 하고 이를 서비스 형태로 expose (노출) 시키면 애플리케이션간의 분산 트렌젝션이 연계된 형태의 서비스를 노출 시킬 수 있다.

 즉 SOA에서 EAI는 저 수준의 시스템간의 통합을 담당하고 이를 서비스로 노출 시키는 역할을 한다.

 이렇게 기존의 Legacy 시스템들을 표준화된 인터페이스로 expose 해주는 계층을 SOA에서는 Service Enablement Layer라고 하고, EAI는 그 중에서 단일 시스템에 대한 expose 보다 하나 이상의 Legacy를 통합하여 expose 하는 composite 기반의 Service Enablement 를 수행한다.

 

기존 업무 조직에 대한 기술적 차이에 대한 중계

SOA 프로젝트에서 문제점중의 하나가 기존의 기술 조직의 서비스 구축에 대한 기술적인 차이이다.

예를 들어 ‘A사의 ERP 솔루션을 이용해서 ERP를 구축한 회사가 있다고 하자. 이 회사는 SOA로 아키텍쳐를 전환하기로 결정했고, ERP 팀에 회사 표준 인터페이스 기반으로 서비스를 Expose 하도록 지시했다고 가정하자.

그런데 이 ERP 팀의 개발자들은 오직 ERP 시스템에서 사용된 언어만을 안다. 설사 웹서비스와 같은 기술이 제공되더라도 XML도 모르고, 웹서비스를 공부할만한 시간도 의지도 없다. 결국에는 재사용이 가능한 높은 수준의 서비스가 아니라 간신히 구현한 서비스가 나오거나 또는 업무팀의 반발로 데이터 베이스간의 연동으로 통합을 하게 되고, SOA에서 추구하고자 하는 원래의 목적은 허물어져 간다.’

이런 시나리오는 실제 SOA 프로젝트에서 발생하는 시나리오이다. 처음부터 전체 시스템을 다시 구축하는 회사면 모르겠지만 새로 세운 회사가 아닌 이상, Legacy 시스템은 존재한다. 또한 하나의 솔루션에 전문화되어 있는 현업 인력에게 웹서비스라는 새로운 기술을 들이 민다는 것도 쉬운일이 아니다.

 여기서 EAI가 사용될 수 있는데, 업무팀은 현재 사용하고 있는 솔루션의 기술을 이용하여 비즈니스 서비스를 구축하면 EAI에서 해당 솔루션에 대한 아답터를 이용하여 연결하고 웹서비스로 외부에 Expose 해주는 기능을 수행한다.

 EAI의 인터페이스 변환은 단순하게 프로토콜이나 사용기술의 변화뿐만 아니라 조직간의 기술 차이에 대한 중재 역할까지 수행하게 된다.

 

결과적으로 EAI를 SOA에 적용하면 Service Enablement Layer로써 다음과 같은 계층 구조를 가지게 된다.

 

결론

지금까지 간단하게나마 기업의 애플리케이션의 통합의 필요성과 EAI를 통한 통합 그리고 SOA에서 애플리케이션의 통합 방법에 대해서 알아보았다. Application Integration은 현재의 Enterprise Architecture에서 반드시 필요한 요구사항이다. EAI가 되었건, SOA가 되었건 어떤 방식이던지 통합이 필수적인 요건이다. 어떤 방식으로 구현하느냐는 해당 기업의 시스템의 아키텍쳐와 요구사항에 따라 틀릴 것이고 SOA를 이용한 통합 방식이 전통적인 EAI방식보다 몇몇 장점이 있다는 것을 살펴보았다.

 

사실 본 문서에서 언급한 인터페이스 통일을 통한 시스템의 통합 방식은 SOA의 발전 모델중의 첫번째 모델인 통합 중심의 Fundamental SOA에 해당한다. (참고 : http://www.slideshare.net/Byungwook/soa-overview )

 

그러나 SOA가 반드시 모든 통합에 적합한 것은 아니다. EAI방식의 통합이 적절할때가 있고 SOA방식이 적절할때가 있기 때문에 SOA중심의 통합은 EAI 를 흡수하는 형태로 상호 보완적인 통합이 되어야 한다.

그리고 SOA의 목적 자체가 통합 하나만이 되서는 곤란하다. 여러 목적 중의 하나가 통합이고 그외에 서비스의 재사용, 시스템의 유연성과 민첩성등이 반영되어야 진정한 SOA 라고 이야기 할 수 있다.

 

 


저작자 표시
신고

SOA를 공부하세요. 최고입니다.

아키텍쳐 /SOA | 2009.07.04 22:41 | Posted by 조대협
오늘도 타이트한 하루가 끝나갑니다.
오전일 끝내고, 와이프와 딸을 데리고 집에서 한시간정도 거리에 있는 용인 한택 식물원에 다녀왔습니다. 오프로드를 유모차를 끌고 올라가는게 상당히 운동이 되더군요. 우리딸은 물만 보면 사죽을 못쓰는지라, 계곡에서 그리고 분수대에서 계속 있을려고 해서.. 데리고 나오느냐고 미안했습니다.

 SOA에 대해서 왜 이런 이야기를 하느냐 하면,
현존하는 아키텍쳐중에서 가장 범위가 넓고 가장 발전한 아키텍쳐중의 하나이기 때문입니다.
DDD의 글을 쓰다가 생각이 난 내용인데, SOA는 기본적으로 서비스를 비지니스적인 의미로 정의를 합니다. 비지니스와 IT조직간에 같은 Context를 사용한다는 겁니다. 그리고 전체 기업을 대상으로 하기 때문에 이 Context의 전파가 중요한 요건이 됩니다.

또한 애자일 사상에서 이야기 하는 Iteration의 개념역시 SOA에서 Vertical Slising과, Short Release의 개념으로 이미 녹아나 있습니다.

 팀조직과 협업 그리고 정치에 대한 부분역시 Governance에 대한 부분에 설명이되어 있고, 비지니스 아키텍쳐(사업의 비젼, 비용 관리등)에 대한 내용 역시 SOA의 비지니스 아키텍쳐에 설명이 되어있습니다.

SOA가 성공한 아키텍쳐네, 벤더들의 마케팅 수단이네 말은 많지만 SOA 자체는 훌륭한 아키텍쳐임에는 틀림이 없습니다. 적용하기가 힘들고, 현실화 시키기 위한 기술이 만만하지 않을뿐이지요.

 SOA를 공부하면 Enterprise System의 전체를 볼 수 있어서 아키텍쳐에 관심이 있으신분들은 꼭 공부해보시기를 추천합니다.

 항상 생각하는건데, 기술을 고민하는 사람들의 고민점과 해답은 시간이 지날수록 점점 비슷한 곳으로 모아지는 것 같습니다.

개인적으로 SOA에 관련해서 읽었던 책중 최고 명서는 http://www.amazon.com/Enterprise-SOA-Service-Oriented-Architecture-Practices/dp/0131465759/ref=sr_1_9?ie=UTF8&s=books&qid=1246714242&sr=8-9 이 아닌가 싶습니다. (Enterprise SOA)
2004년에 작성된 책이고, 웹서비스가 없었을때임에도 불구하고, SOA의 개념과 구현 방법,개념, 조직 구조등에 대해서 아주 잘 설명하고 있습니다. 군더더기가 없는 책이지요. 2004년에 이런 생각을 해낼 수 있다니 놀라울 따름입니다. 번역서도 있는 것으로 알고 있는데, 꼭 추천합니다.

다음으로는 Applied SOA입니다.
http://www.amazon.com/Applied-SOA-Service-Oriented-Architecture-Strategies/dp/0470223650/ref=sr_1_1?ie=UTF8&s=books&qid=1246714619&sr=1-1#
버릴것이 하나 없는 책입니다. 앞의 책보다 깊이가 좀더 있고, 특히 Governance와, Business Architecture 에 대한 부분이 보강이 되는 부분입니다. 작년에 출판사의 번역 여부 조언으로 받아서 읽었는데, 사실 읽을때 마다 새롭습니다. :(

마지막으로 SOA Design Pattern 입니다.
http://www.amazon.com/Design-Patterns-Prentice-Service-Oriented-Computing/dp/0136135161/ref=sr_1_1?ie=UTF8&s=books&qid=1246714775&sr=1-1
아마 SOA에 대한 책을 가장 많이 쓴 사람이 Thomas Erl 일겁니다. 그의 SOA에 대한 초기 두권의 저서가 시기를 잘 탔기 때문에 유명세를 탔다고 생각하는데요. 그 두권의 책의 내용은 사실 매우 별로 였습니다. 파란표지 책은 그나마 서비스 분석과 디자인 방법에 대해서 소프웨어 공학론적인 접근을 하고 있어서 참고할만 하지만, 그 내용을 수백페이지에 다뤄야 하나 하는 의문이 생깁니다.
 SOA Design Pattern은 Thomas Erl 의 이런 기존서적에 대한 비평을 조금이나마 덜어줄 수 있는 책이 아닌가 싶습니다.  역시나 이번책에도 다소 군더더기가 많아 보이기는 합니다만, 책의 질이 좋아서 들고 다니면 폼은납니다. :)
 이번 책에서는 SOA를 몇가지 관점으로 나눠서 정의하는데, 이 접근 방법이 매우 흥미롭습니다.
Service 자체에 대한 디자인 패턴, Composition 패턴, 그리고 기억이 가물가물한테 Service Infra에 대한 패턴 그리고 마지막으로 Service Inventory 패턴입니다.
 패턴 내용 자체보다는 제 경우 4가지 패턴으로 나누었다는 접근 방식 자체가 흥미롭습니다. 실제 설계해도 이렇게 해야 겠다는 생각이 들더군요.
 가장 주목할만한 점은 Service Inventory Pattern 입니다. 이 패턴은 흔히 이야기 하는 Service Repository 입니다. 기존에는  Service Repository를 단순히 UDDI 정도로 접근하는 개념이 많았지만 UDDI는 Runtime 에서 사용되는 서비스의 DNS? 정도입니다. (물론 부가기능은 더 있겠지만요.)
 그러나 SOA 가 성숙되어감에 따라 이 서비스를 어떻게 관리할것인가 (카달로그 또는 Repository 라고 합니다. )에 대한 의문이 생기는데, 이것이 Thomas Erl이 언급한 Inventory 입니다.
 Thomas Erl 아저씨의 특성상 책이 읽기가 어려워서 읽어도 잘 진도가 안나가서 고전을하고 있지만
 접근 방식에 대해서는 충분히 연구를 해볼만한 가치가 있습니다.

쭈욱 적어내려갔는데... 써놓고 보니 또 어렵습니다. :(
 그래도 SOA를 다른분들도 공부해서 많은 것을 얻어가실 수 있지 않을까 하는 생각에 정리해봤습니다.

의견이나 토론은 항상 환영합니다.



신고

JEE enterprise Application Grid Architecture

아키텍쳐 /SOA | 2009.06.12 14:56 | Posted by 조대협

JEE Application Grid Architecture

 

한국 오라클 컨설팅
Principal Consultant
조병욱(byungwook.cho골뱅이oracle.com)

 

사상 (Architecture Principals)

애플리케이션 그리드 아키텍쳐 사상은 다음과 같다.

비즈니스 로직을 가진 업무 컴포넌트가 무제한적으로 그리드에 추가될 수 있으며, 호출하는 클라이언트 입장에서는 각각의 업무나 업무 컴포넌트를 분리된 형태가 아닌 하나의 진입점을 통해서 호출하도록 하고, 각 업무의 부하에 따라서 업무 시스템에 하드웨어 자원(CPU,MEMORY)를 탄력적으로 배분함으로써 최적화된 성능을 유지하고, 업무 또는 업무 컴포넌트에 장애가 발생하였을때에도 해당 장애가 다른 업무에 영향을 주지 않도록 하는 아키텍쳐이다.

 리소스 배분에 대한 구현

본 아키텍쳐의 특징중의 하나는 업무의 부하량에 따라서 하드웨어 자원을 자유롭게 배분하는 것이다. 이는 하드웨어에서 제공하는 가상화 기능을 이용하여 구축이 가능한데, 업무의 부하량에 따라서 WAS 인스턴스의 수를 탄력적으로 조정하고, 해당 업무를 담당하는 WAS INSTANCE그룹에 CPU와 메모리를 동적으로 배분함으로써 효율적인 자원 활용이 가능하다.

 바꿔 이야기 하면 오픈 당시에 예측했던 용량에 비해서 부하가 적은 업무에는 CPU를 빼고, 부하가 높은 업무에 CPU를 부여함으로써 자원 활용의 효율성과 확장성을 고려하는 것이다.

 장애 전파 방지

다른 특징은 장애 전파의 방지인데, 여러 업무 애플리케이션이 하나의 WAS INSTANCE에 배포되어 있는 경우, 한 업무가 장애가 나서 CPU과 사용등의 현상이 생기거나 THREAD를 과점유할 때, 같은 INSTANCE에 돌고 있는 다른 업무 역시 정상적인 수행이 불가능해진다. 이를 방지하기 위해서 업무별로 WAS INSTANCE를 나눠서 배포함으로써, 장애 전파 가능성을 제거할 수 있다.

 통상적으로 여러 업무를 하나의 WAS INSTANCE에 배포하는 주요한 이유중의 하나는 공유 데이터 (HTTP SESSION이나, 사용자 공유정보)를 하나의 INSTANCE내에서만 공유할 수 있기 때문인데 이 문제는 Oracle Coherence를 이용함으로써 INSTANCE간 메모리 공유를 통해서 해결할 수 있다.

 개발 생산성 증가

비즈니스 컴포넌트를 개발하는 입장에서 생산성에 문제를 일으키는 요인중의 하나가 공통 모듈 (Cross Cutting Concern)의 중복 개발이다. 인증,인가,로깅,Throwtling등의 공통 모듈 역시 JEE 아키텍쳐에서는 공통 라이브러리를 사용하건 말건간에, 비즈니스 컴포넌트에 붙여서 개발이 되어야 했다. 이는 개발자가 비즈니스 로직뿐만이 아니라 공통 모듈 개발에도 어느정도의 노력을 사용하도록 해왔고, 또한 공통 모듈의 변화는 개발 내용 전체에 영향을 줄 수 있어서 생산성에 영향을 줘왔던 것이 사실이다.

이러한 공통 모듈을 ESB 계층으로 모두 옮겨서, 비즈니스 컴포넌트에는 순수한 비즈니스 로직만이 들어가도록 하고, 공통 모듈은 ESB에 구현함으로써 비즈니스 로직 개발자가 순수 로직 개발에만 집중하도록 하여 개발의 생산성을 극대화 할 수 있다.

 시스템 유연성의 증가

IT 시스템은 비즈니스 요건에 따라서 변경 요건이 필수적으로 발생하는데, 본 아키텍쳐는 변경에 대한 요건을 ESB를 통해서 소화함으로써 시스템의 요건 변경에 대한 유연성을 극대화 한다.

 ESB는 자체적으로 Request/Response에 대해서 기능을 추가하거나 변경할 수 있는 Mediation의 개념을 가지고 있기 때문에, 업무 요건 변경으로 인한 기능 추가, 전문이나 데이터의 변경등을 비즈니스 컴포넌트의 변형 없이 ESB Mediation Logic을 추가함으로써 손쉽게 반영할 수 있다.

 무제한 확장 가능한 그리드  아키텍쳐

이 아키텍쳐의 가장 큰 특징중의 하나가 확장성이다. 새로운 비즈니스 로직이나 업무가 추가된다면, WAS INSTANCE를 추가하고 비즈니스 컴포넌트만 추가 배포하면 된다. (PLUG IN하듯이.) 비즈니스 로직을 호출하는 클라이언트 입장에서는 변화된 내용이 없으며 예전과 동일하게 하나의 접속점을 통해서 기존과 새로운 비즈니스 컴포넌트를 호출하면 되고, 하드웨어 용량 증설역시 횡적으로 확장해나가면서 비즈니스 로직을 추가할 수 있다.

 결론

기본 아키텍쳐 설계의 내용자체를 보면 복잡도는 크게 높지는 않다. “Simple is Best!”라는 원칙도 있듯이, 아키텍쳐는 단순성이 높을 수 록 성능과 그 신뢰성이 높아진다. 본 아키텍쳐는 엔터프라이즈 시스템에서 필수로 요구되는 확장성,유연성,신뢰성을 골고루 갖추고 있다.

참고

Coherence OSB를 이용한 아키텍쳐의 개념은 다음 문서를 참고하기 바란다.

 

 

저작자 표시
신고

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

EAI관점에서 본 SOA  (6) 2009.07.29
SOA를 공부하세요. 최고입니다.  (4) 2009.07.04
JEE enterprise Application Grid Architecture  (0) 2009.06.12
괜찮은 SOA 테스팅 툴 발견  (0) 2009.03.16
SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16

괜찮은 SOA 테스팅 툴 발견

아키텍쳐 /SOA | 2009.03.16 11:23 | Posted by 조대협
http://www.crosschecknet.com/

SOA 구현시 테스팅이 문제인데, 기존에 SOAP UI만 사용하다가 좋은 툴을 발견
HP TC와 연동도 되고, JUnit형태로도 뽑아져서 Regression(회귀) 테스트에도 반영 가능하단다.
InforWorld에서 SOA 테스팅 툴 부분에서 가장 좋은 점수를 받은 툴

저작자 표시
신고

SOA 시스템 설계에서 가장 큰 실수

아키텍쳐 /SOA | 2009.03.16 10:31 | Posted by 조대협
SOA 시스템에 대한 컨설팅 (설계나 Code Inspection)을 다니다 보면,
Goverance나 프로젝트 관리상에서도 문제가 많이 나타나지만, 설계상에서 근본적인 문제로 나타나는 패턴들이 있다.

SOA의 근본적인 정의를 다시 내려보면, "비지니스적인 의미를 가지는 컴포넌트를 기업내의 통합된 프로토콜로 서비스하여 제공한다." 이다.
BPM을 이용한 Composition이나 ESB를 이용한 유연성의 증대도 SOA 에서 큰 의미를 차지하지만, 일단 시작은 SOA를 통해서 제공되는 컴포넌트의 형태이다.

즉 기본이 되는 SOA 서비스와 그 인터페이스에 대한 정의와 구현이 제대로 되어야 하는데
통상적으로 SOA 시스템을 설계하고 구현하는데 있어서 발견되는 실수는 다음과 같다.

1. 표준 전문의 미사용
서비스의 전문 형태는 해당 시스템에서 어느정도 통합된 형태를 가져야 한다. 웹서비스를 사용하더라도, 프로토콜 측면이 아니라 비지니스 측면에서도 통합된 전문 형태가 요구 된다. 메세지 헤더, Message PayLoad의 형태등 표준화된 메세지 포맷은 전문의 가독성을 높여주고 아키텍쳐의 일관성을 가지고 가도록 해준다.

Legacy 시스템에 대한 통합 요건이 있을 경우에는 Legacy 시스템으로부터의 메세지를 표준 전문으로 변환하는 작업이 필요하겠지만, 처음부터 시작하는 SOA 프로젝트는 설계 단계에서부터 표준 전문을 사용하기 때문에, 표준 전문으로의 변환 요건이 나올 수 가 없다. 오직 잘못된 설계에서만 처음 시작하는 SOA (Build from scratch)에서 표준 전문 변환 구현이 추가된다.

2. 헤더의 Message Payload를 분리하지 않음
헤더와 Message Payload는 당연히 다른 의미르 갖는다. 헤더는 공통적으로 사용되는 부분이며 비지니스적 로직 처리 보다는 인증,인가와 같은 보안에 관련된 부분, 거래 추적을 위한 메세지 ID, Call back등의 Message Exchange Pattern(MEP)를 위한 Correation ID와 같이 공통적인 부분과 아키텍쳐에 대한 부분을 처리하도록 설계된다.

그런데, 이 헤더가 Message Payload (메세지 본문)에 포함되어 설계되는 경우가 종종 있다.
웹서비스로 이야기 하면 SOAP Body에 Header 정보가 들어가는 경우인데, SOA 시스템의 전제중의 하나는 "서비스들이 조합되어 비지니스 로직을 구현한다" 이다. 즉 전문은 여러 과정을 거쳐서 긴 여행후에 비지니스 로직을 처리한후 그 값을 리턴한다는 이야기이고, 그 과정에서 로깅이나 라우팅, 인증등의 로직을 수행할 수 있다.
그런데, 문제는 라우팅을 위해서는 헤더내의 특정 필드만이 필요한데 이런 경우에는 Message Payload를 전체를 Parsing해야 그 값을 얻어낼 수 있고, 이는 심각한 성능 저하를 유발하게 된다.
웹서비스의 경우 SOAP Header라는 필드가 있고, 이 Header에 Header값들을 넣게 되면 Header가 필요한 경우에는 (예를 들어 인증의 경우 Header 내용만 파싱해서 체크하고 뒤의 비지니스 로직으로 메세지를 포워딩 하면 된다.) Header만 파싱해서 핸들링하고 Body는 파싱을 하지 않아도 되기 때문에 성능상의 장점을 가지고 갈 수 있다.

REST의 경우에도 SOA와 유사하게 Resource를 기반으로 아키텍쳐가 구성되고 여러 Backend단을 거쳐야 하기 때문에 같은 원리로  HTTP-Header를 사용하며 Header를 전송할 필요가 있다.

3. 벌크 데이타의 전송
SOA나 EAI와 같은 연계(통합)이 필요한 시스템의 경우에는 메세지의 전달 패턴 (Message Exchange Pattern)에 따라서 그 연계 방식이 다르게 정의되어야 한다. 일반적인 Sync나 ASync는 많이들 고려하여 설계가 되고 있지만 벌크 데이타에 대한 전송이나 대용량의 Binary Attach의 경우에는 제대로 아키텍쳐상에 반영되지 않는 경우가 많다
특히 File Attach의 경우 웹서비스 상에 주석 <!-- CDATA로 전송하거나 Base64 encoding등을 이용하여 XML 엘리먼트로 전송하는 경우가 많은데, 이런 경우에는 메세지 전송 자체에 부하를 초래할 수 있기 때문에,
Swa (SOAP with Attachment)등을 이용하는 것이 바람직하고, 대용량 레코드의 경우에는 Batch를 이용한 전송이나 비동기식으로 (near realtime)형태로 리스트를 전송하는 아키텍쳐를 고려하는 것이 바람직하다.

4. Fine grainned 메세지
SOA는 기본적으로 서비스의 재사용을 전제로 한다. 서비스가 재사용될만큼 비지니스적인 의미를 가지고 Coarse grainned되어야 하는데, 일선의 개발 현장을 보면 SQL하나 보내는 것과 같이 작은 단위의 서비스가 많이 존재하는 것을 종종 볼 수 있다. 이는 기존의 CBD와 같은 개발 사상에서 벗어나지 못한 상태에서 설계를 하면 Fine grainned된 서비스들이 난무하고 전체적으로 서비스개수가 올라가고 관리 포인트가 증가하는 형태의 시스템이 만들어지고, 또한 각각의 Fine grainned된 서비스들을 호출하여 네트워크 부하를 늘리는 요인이 될 수 가 있다.

5. 불필요한 필드의 사용
메세지를 리턴할때 Consumer 쪽에서 사용하는 내용만을 리턴하는 것이 바람직하다.
Consumer 쪽에서는 사용하지도 않는 필드가 주렁주렁 매달려 있거나, 추후를 위해서 예약해놓는 다는 필드들이 주렁주렁 매달려 있는 경우는 전체적인 XML 메세지의 크기를 증가 시켜 성능을 저하 시킨다.
최적화된 메세지를 사용하는 것이 성능과 가독성에 큰 영향을 준다.

6. 불필요한 메세지 변환 사용
많이 있는 문제중의 하나인데, ESB의 경우 강력한 메세지 변환 기능이 있기 때문에 이를 남용하는 사례이다.
메세지 변환이 필요한 경우도 있지만.
예를 들어
1) 데이타의 내용은 바뀌지 않는데, UI에서 보여주기 편하게 하기 위해서 변환을 수행한다.
2) 데이타에서 불필요한 내용을 제거하기 위해서 변환을 수행한다.
와 같은 경우는 정말 금지해야하는 사례이다.
보여주기 위한 데이타나, 재사용되기 위한 데이타의 정재는 Consumer side에서 이루어지는 것이 맞으며, 데이타의 비지니스적인 의미 자체만 제대로 전달된다면 변환을 수행할 필요가 없다.

ESB는 SOA 시스템에 대한 유연성을 부여해주기 위함이고, 유연성을 제공하기 위해서 XQuery,XPath와 같은 엔진을 제공한다. 유연성을 제공하는 만큼 이 XML관련 연산은 CPU등을 SAX나 DOMParser와 같은 Pure XML 처리 방식보다 많이 사용하게 되는 것이다.
 이것이 실제 Code로 작성하는 것보다 비용이 높은지 낮은지에 대한 ROI관점에서 ESB에 로직이 들어가야 되느냐 말아야 되느냐를 결정해야 한다.

 갑자기 SOA 시스템 설계에서 문제점이 생각이 나서 정리를 해봐서인지.. 깔끔하게 정리는 되지 않았는데 혹시 의견이나 토론할 거리가 있으면 환영합니다.

참고 문서 : http://www.infoq.com/news/2009/03/threecommon


저작자 표시
신고

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

JEE enterprise Application Grid Architecture  (0) 2009.06.12
괜찮은 SOA 테스팅 툴 발견  (0) 2009.03.16
SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12

OMG released SOAML draft

아키텍쳐 /SOA | 2009.01.16 15:52 | Posted by 조대협
OMG에서 SOA를 디자인할 수 있는 UML의 확장판인 SOAML을 발표했습니다.
http://www.omg.org/docs/ad/08-08-04.pdf

SOA 시스템 디자인하기에 편하겠네요.

저작자 표시
신고

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

괜찮은 SOA 테스팅 툴 발견  (0) 2009.03.16
SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
TAG OMG, soa, SOAML, UML

Composition 과 Mashup의 차이

아키텍쳐 /SOA | 2008.11.13 19:01 | Posted by 조대협
SOA 프로젝트를 하다보면 Mash up과 Composition를 혼용해서 쓰는 사람들이 종종있다.
먼저 유래부터 살펴보면 SOA 사상이 먼저 나온후에, 
WEB 2.0 이란 사상이 대두 되고, SOA의 무거운 부분과 복잡성을 제외하고, 단순성과 편의성을 위주로 OPEN API라는 개념이 나왔다.
SOA에서 통상적으로 웹서비스로 구현되는 서비스를 JSON이나 PLAIN OLD XML등과 같이 경량의 사용하기 쉬운 메세지 포맷을 이용해서 OPEN API라는 것이 개발되었고, 이 오픈 API를 조합하여 새로운 기능을 만들어 내는것을 MASH UP이라고 한다.
   SOA  WEB 2.0
 컴포넌트 개념  웹서비스 기반의 서비스  경량 기반의 서비스
 서비스 조합  Composition (Orchestration)  Mash up

그러면 차이가 무엇일까?
다시 족보부터 따져 보자면 SOA는 기업을 위한 아키텍쳐에서 부터 출발했고 WEB 2.0은 서비스 애플리케이션에서부터 시작되었다.
IBM,BEA,ORACLE등을 선두로 하는 벤더에서 주창되는 아키텍쳐가 SOA이고, 구글이나 아마존, 야후와 같은 서비스 기업에 의해서 주창되는것이 WEB 2.0 사상이다.

사상 처럼 SOA의 서비스는 대부분이 비지니스적인 의미를 갖는다. 대부분의 서비스가 UI를 가지기보다는 비지니스 컴포넌트로써의 의미를 가지고, WEB 2.0의 서비스는 맵이나, 뉴스, 가젯 등등과 같이 UI 성격을 갖는 서비스가 대다수이다.

SOA에서의 Composition은 서비스들을 조합하여 새로운 서비스를 만들어 내는 것으로, 이 새로운 서비스는 재 사용이 가능하고 다시 Composition이 가능하다. 반면 Mash up은 한번 조합이 되서 새롭게 구성된 서비스는 다시금 조합이 어렵다. (물론 아닌 경우도 있지만....) Mash up은 기존 서비스를 조합하여 새로운 화면을 만들어서 자신의 서비스 사이트에 나타내기 위한것이기 때문에, 근본적으로 재활용성에 큰 비중을 둔것이 아니다.
반면 SOA는 컴포넌트 조합을 통해서 다시금 재 사용을 하는 것을 전제로 하기 때문에 재 사용성의 여부에서 Mashup과 Composition의 차이를 볼 수 있다.


신고

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

SOA 시스템 설계에서 가장 큰 실수  (0) 2009.03.16
OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10

SOA 가 어려운 이유..

아키텍쳐 /SOA | 2008.11.12 15:00 | Posted by 조대협
SOA가 나온지도 오래되었고 개념이 좋다는 것은 다들 인정하고 있지만 쉽게 확산 되지 않는 이유가 무엇일까?
결과부터 따져보자면

성공적인 SOA<-- 성공적인 거버넌스 <-- 강력한 파워와 조직

SOA는 기업의 모든 업무를 서비스화하여 재 사용하고자 하는 아키텍쳐이다. 단순한 프로젝트처럼 단기간에 끝낼 수 있는 것도 아니고, 한팀이나 TF형식으로 만들고 끝날 수 있는 것이 아니라. 장기적인 관점에서 소프트웨어 컴포넌트를 서비스화하여 자산화 하고, 이 자산을 재 사용해야 한다.

그러기 위해서 가장 중요한 것이 장기적인 계획을 세우고 각 비니지스 업무 부서를 조율하여 서비스를 생성 및 관리하고 조합하여 업무에 반영 하는 역할을 할 수 있는 것!!이 필요하다.
이 "것" 이 거버넌스 인데. 거버넌스는 전체 SOA를 통제할 수 있는 조직과, 프로세스, 그리고 이것을 뒷받침해줄 플랫폼이 포함된다. 물론 여기에 돈이나 시간도 들어가겠지만 가장 중요한것은 이 3가지인데...
대부분의 실패한 SOA의 문제점을 이 거버넌스에서 생각해볼 수 있다.

  • 거버넌스 조직 구성 부터 생각해보면, 거버넌스 조직은 SOA를 수행할 만한 기술과 업무에 대한 전문적인 지식과 함께, 각 비지니스 부서를 통제할 수 있는 POWER가 있어야 한다. 거버넌스의 실무 인원들이 그런 POWER를 가지기는  불가능하고, 거버넌스 조직의 LEADER가 결국 그 힘을 주는 것인데.. SOA 거버넌스 모델에서는 그런 사람을 BACKER라고 한다. 한국말로 하면 빽..!! 거버넌스 조직이 실력과 이만한 파워를 갖춰야 각 업무 부서를 통제하고 서비스를 착착 만들어 나갈텐데.. 이것이 안되니 SOA가 제대로 될리가 있나?? 보통 이런 조직은 기업에서는 CIO 산하의 정보전략이 리딩을 하는게 하는것이 맞는데.. 정보전략이 그만한 힘이 없거나 또는 그만한 전문성이 없거나 단기적인 프로젝트에 집중할때 문제가 생긴다.
SOA 프로젝트가 다른 프로젝트와 틀린것은 기존 프로젝트는 하나의 비지니스 업무에 대해서 한 LOB에서 단기간에 시스템을 구축하면 끝났지만, SOA는 전사적으로 아키텍쳐가 설정되어야 하고 거버넌스 조직에 의한 전략에 따라서 LOB 간의 협업이 중요한데.. 사람이 하는일이니 쉽지 않은가 보다.
  • 프로세스 측면에서는, 프로세스가 현실과 동떨어져 있는 경우가 많다. RUP가 거버넌스 프로세스는 아니지만 예를 들어보면 좋은 방법론과 프로세스임에는 확실하지만 무겁고 이해하기가 어렵다. LOB별이나 직원별의 기술 수준이 다르기 때문에 프로세스에 대한 적응도가 떨어질 수 밖에 없고 있는 거버넌스의 실패 그리고 통제의 실패와 프로젝트의 실패로 연결이 된다. 그러면 어떻게 해야 하나? 프로세스는 가볍고 이해하기 편해야 한다. 커뮤니케이션 파이프라인은 되도록이면 짧아야 한다. 내 경우에는 감히 "하향 평준화"를 하라고 이야기 하고 싶다.
  • 시스템 관점에서 보면, 거버넌스 시스템의 예로 PPMS(프로젝트 관리도구), SCM(형상 관리 도구) 등이 있지만!! 실제 프로젝트를 보면 툴 따로 실제 업무 따로인경우가 많다. 툴은 업무를 돕는것이지 툴에 업무를 맞추는게 아니다. 물론 툴이 무지 좋다면 그것도 방법은 되겠지만...
사실 거버넌스의 실패가 SOA에만 해당되는 이야기는 아니다. 일반 프로젝트도 거버넌스의 실패가 대부분의 실패 요인이 되니까는 그럼에도 불구하고 SOA에서 거버넌스의 중요성을 언급한것은 위에서도 이야기 했지만, SOA는 장기적이고 여러 부서에 걸쳐 있는 프로젝트이기 때문에 무엇보다도 통제가 중요하기 때문이다..

이글을 썼다가 날라가서 다시썼는데.. 내용이 좀 꼬이는듯 하네..
신고

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

OMG released SOAML draft  (0) 2009.01.16
Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21

관심이 가는 오라클 제품들

아키텍쳐 /SOA | 2008.10.15 13:48 | Posted by 조대협
요즘 들어 오라클에 들어와서 제품들을 보면서 관심들이 가는 제품들이 있는데..

1. ODI -  ETL 같은 솔루션인데, 보다 Near realtime에다가 ETL과 접근 방법이 약간 틀려서 EL-T라고 하는데 성능이나 사용성이 좋은듯 하다. 그간 ETL 솔루션이 없어서 고생좀 했는데. 의외로 좋은 아이템이 될듯.
2. ORACLE BPEL PM - WLI 와 AL BPM의 중간 계보쯤을 이어주는 제품. Human Oritented BPM보다 System Oriented BPM에 가까운데. WLI의 족보를 이어서 선전(?)을 하지 않을까/
3. Coherence - 이미 아는 사람들은 다 아는 오라클이 인수한 메모리 캐슁 제품... 꼭 한번 써보리라!!
4. ALER - 시간이 없다는 핑계로 오랫동안 묻어두고 안보고 있었는데... 주인을 가리는 칼이라 해야하나? 쓰는 사람이 잘쓴다면 의외로 엄청난 무기가 될 수 있는 SOA Asset 관리 도구...

하나하나 새로운 기술이나 제품을 알아간다는것이 즐거운게.. 나는 어쩔 수 없는 엔지니어일까?
신고

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

Composition 과 Mashup의 차이  (0) 2008.11.13
SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04

2008년 SOA 전망

아키텍쳐 /SOA | 2008.01.10 17:49 | Posted by 조대협
경영과 컴퓨터 1월호에 기고했던글..

==

2008 SOA 기술 전망

 

저자  BEA 조병욱 과장 (Sr. consultant of BEA Systems Korea consulting dept.)

블로그 : http://bcho.tistory.com

온라인상의 필명으로 “조대협” 이라는 이름을 사용하고 있으며,온라인 자바사이트 www.javastudy.co.kr의 초대 운영과, 한국 자바 개발자 협의회 jco의 부회장을 맏았으며, SOA 관련 다수의 강의 경력과 컨설팅 경험을 가지고 있다.

 현재는 BEA Systems Korea에서 엔터프라이즈 시스템 관련 컨설턴트로 재직중이다.

 

1. 개요

 본 기고는 2007년의 SOA관련 기술의 흐름을 되 짚어보고, 2008년의 SOA의 기술의 변화 방향에 대해서 전망하여, SOA 를 적용할 기업들의 방향성에 대한 도움을 주고자 하는 기고이다.

 

2. SOA의 기술 계층

먼저 SOA가 어떤 기술 계층으로 이루어져 있는지를 이해하면, 각 계층들의 변화 방향을 통해서 전체 기술 방향의 변화를 인식할 수 있다.

 

(1) SOA 3단계 기술 계층

SOA는 크게 다음과 같이 3단계 기술 계층을 가지게 되어 있다.

 

1) 서비스 가능화 계층 (Service Enablement Layer)

서비스 가능화 계층의 기존의 레거시 시스템 (기존에 운영되고 있는 시스템)들을 비즈니스의미를 갖는 단위의 컴포넌트로 묶고 표준화된 인터페이스로 시스템 외부로 서비스를 제공할 수 있도록 해주는 계층이다.

현재에 유행하고 있는 웹서비스 중심의 SOA에서는 레거시 시스템들의 기능들을 웹서비스로 노출 시키고, 노출되는 컴포넌트 단위를 비즈니스 업무 단위로 크게 묶는 계층을 정의한다.

 

각각의 시스템들이 표준화된 인터페이스를 통해서 기능을 제공하기 때문에, 이 계층에서는 타 시스템간의 통합(Integration)이 용이하게 된다.

* 키워드 : 비즈니스 업무 단위, 표준화 인터페이스, 서비스화, 시스템 통합

 

2) 서비스 허브 계층 (Service Hub Layer)

서비스화된 각각의 업무 컴포넌트간의 통합과 호출은 각 시스템 대 시스템으로 이루어지기 때문에, P2P 구조를 가지게 되고 결국 이는 시스템간의 복잡도를 증가 시켜서, 시스템간 연계 Topology가 마치 거미줄 처럼 복잡화된 구조를 가지게 된다.

이런 복잡한 Topology를 중앙에 공용 Bus를 넣어서 Hub & Spoke 방식으로 중앙 집중형 통제 구조를 가지게 하여 복잡성을 제거하고, 관리의 용이성을 증가 시키며, Bus 안에 유연성을 가미할 수 있는 서비스 - Intermediary 서비스를 추가하여 시스템의 업무에 대한 유연성을 높인다.

 

 Intermediary 서비스란, 예를 들어 백화점의 구매 프로세스가 있었다고 가정하자 그런데 이 백화점에서 VIP 고객을 위한 특별한 포인트라는 신규 업무를 만들었을 경우에, 백화점 구매 프로세스에 변경을 가해서 포인트 적립하는 비즈니스 로직을 추가하거나 또는 백화점 구매 프로세스를 호출하는 쪽에서 포인트 적립을 하는 서비스를 호출해야 하는 것과 같이 ‘서비스 제공자’나 ‘서비스 사용자’ 에 대한 로직 변화가 필수적 이었다.

 이 문제를 해결하기 위해 ‘서비스 제공자’와 ‘서비스 사용자’ 사이에 중간자 적인 역할을 하는 Intermediary 서비스를 넣어서, ‘서비스 사용자’는 예전과 똑같은 방법으로 서비스 제공자를 호출하지만 이 Intermediary 서비스에서 고객의 정보에 따라서 VIP 고객일 경우, VIP 고객용 서비스로 라우팅(경로변환)함으로써 ‘서비스 사용자’와 ‘제공자’의 로직 변환 없이 그대로 변경된 업무를 유연하게 반영할 수 있도록 할 수 있다.

* 키워드 : 버스, 유연성의 추가

 

3) 서비스 조합 계층 (Service Orchestration Layer)

서비스 가능화 계층과, 서비스 허브 계층을 거치면 시스템의 업무들은 모두 비즈니스적인 의미를 가지고 표준화된 인터페이스를 통해서 서비스 허브에 집중화된 형태로 존재하게 된다.

이 서비스 업무하나하나를 조합하여, 현업에서 필요한 ‘비즈니스 업무 흐름’으로 구현해야 하는데, 이 계층이 서비스 조합 계층이다.

 이 계층에서는 비즈니스 업무 흐름을 조합하고, 이 조합된 업무 흐름을 사용자 인터페이스 (UI)로 보여주는 역할을 수행한다.

 

* 키워드 : 서비스 조합,업무 구현, 통합 사용자 인터페이스

 

(2) SOA 기술 계층별 사용 기술과 발전

지금까지 전통적인 SOA의 각 기술 계층이 어떤 역할을 수행하는지를 살펴보았다. 그렇다면 각각의 기술 계층들은 어떤 구체화된 기술을 이용하여 구현이 되어왔을까?

 

1) 서비스 가능화 계층 기술

서비스 가능화 계층에서 사용된 서비스 가능화 기술은, 기존 레거시 시스템의 기능을 서비스화 해주기 위한 “아답터”와, 여러 형태로 저장된 데이터들을 서비스 기능 형태로 변환해주는 “데이터 서비스” 기술이 그 주류를 이루어 왔다.

 또한 각각의 분리된 시스템 업무를 묶어서 하나의 서비스 업무로 변환하기 위해서 시스템간의 통합이 필요하게 되었는데, 이를 위해서는 EAI (Enterprise Application Integration)기술이 사용되었다.

 

 2008년의 서비스 가능화 계층 기술에서 눈 여겨 볼만한 기술적인 이슈는 SCA (Service Component Architecture)이다. SCA는 소프트웨어를 개발함에 있어서 각각의 Service Component로 다루어 이러한 서비스들을 조합하여 플랫폼에 중립적인 서비스로 재조합 한다는데 의미를 두는데, 특히 이 기술의 경우에는 기존의 SOA와는 다르게 명시적으로 WEB 2.0에 대한 프로토콜 (RSS,ATOM,JSON,Hessian etc)등을 폭 넓게 지원하여 좀더 개방적인 서비스 가능화 기능을 제공한다는 것이다.

 SCA를 통해서 서비스 자체에 대한 생성에 필요한 통합 기능이 증대될것이며, 서비스 가능화 계층에 필요한 “아답터”,”데이터 서비스”,EAI” 솔루션들은 아직까지 몇몇 선두 SOA업체만이 보유하고 있기 때문에, SOA를 지향하는 솔루션 업체라면 이 기술 계층을 마련하기 위한 노력들이 뒷 따를 것이며, 이미 이러한 솔루션을 가지고 있는 기업들의 경우에는 이 기술들의 성숙도를 높이는데, 포커싱이 될것이다.

 

2) 서비스 허브 계층 기술

다음으로 서비스 허브 계층은 SOA에서 흔히 이야기 하는 ESB(Enterprise Service Bus)으로 대변되었던 한해였다. 이 서비스 허브 계층을 통해서 각각 다른 형태로 존재하는 시스템들이 통일화된 인터페이스를 가지고, 각각의 분리된 시스템들이 비즈니스 업무 단위로 통합 되면서 하나의 서비스로 형태가 변화게 된다.

 즉 서비스 허브 계층에 대한 요구 사항이 기존의 유연성의 증대와 중앙 집중화된 버스 방식에 더해서, 분리된 시스템 업무간의 통합 기능이 추가 되었다.

 

 기존의 EAI 솔루션을 통해서 수행되던 시스템 통합 기능이 서비스 허브 계층으로 올라오면서 SOA에 적절한 형태 (웹서비스의 지원, ESB와의 통합성)로 변화되면서 서비스허브에 통합되도록 진행되고 있다. EAI 솔루션과 ESB 솔루션간의 통합성 문제와, ESB 솔루션을 사용할 때, 시스템 통합에 대한 요건이 필수 불가결하게 발생하기 때문에, 이에 대한 기능이 흡수 통합되는 모델이다.

 

 특히 SOA 모델에서 자주 언급되는 , Process에 대한 이야기에서 “Process의 주체와 목적이 누구인가?”이다. EAI BPM에 각각의 Process가 있었고 두개의 Process의 존재로 인해서 많은 혼동을 초래하였다. 이러한 Process들은 크게 비즈니스 사용자위주의 사용자 프로세스(Human centric process), 시스템 통합에 필요한 시스템 프로세스(System integration process)로 나뉘어 지고, 이를 각각 ‘BPM과’ ‘EAI Process’로 분리되었고, 이 시스템 프로세스가 서비스 허브 계층에 통폐합 되는 형태로 변화 될것이다..

 

3) 서비스 조합 계층 기술

서비스 허브 계층의해서 제공되는 서비스는 전통적인 SOA에서는 사용자 애플리케이션에서 직접적으로 조합하여 사용하거나 프로세스가 있는 업무의 경우에는 BPM을 사용하는 절차로 가이드되어 왔었다. 여기에 BPA,BAM을 통한 비즈니스 프로세스의 설계와 모니터링을 통한 프로세스 개선에 목적이 맞춰져 왔으나,  실제 업무에서 BPM이 필요한 경우는 복잡한 업무 프로세스가 존재하는 경우이고, BPM을 사용할 수 있는 수준의 SOA 성숙 수준까지 시스템이 발전하기 전까지는 각각의 서비스들을 애플리케이션에서 조합해서 사용하는 수준인데, 이 역시 별다른 기술적인 대안이 존재하지 않았다.

 이에 대한 대안으로 제시될 수 있는 것이 SCA이다. 앞에서도 설명했듯이 SCA는 컴포넌트에 대한 조합 기능을 제공하기 때문에, 상태나 장기적인 프로세스를 갖는 업무가 아닌 일반적인 업무 조합에서는 SCA를 통해서 충분하게 조합이 가능하게 된다.

 

 이렇게 조합된 업무들은 사용자 인터페이스 (UI)를 통해서 사용자들에게 제공이 될것인데, 업무별 또는 조직이나 사용자별의 업무 제공 UI Enterprise Portal (EP)로 제공되어 왔던것에 더해서 WEB 2.0의 개념을 도입한 POA의 개념으로 업무에 대한 서비스가 사용자에게 제공될것이다.

 

 POA (Participant Oriented Architecture)의 약자로, 사용자 참여 중심의 아키텍쳐를 이야기 한다. 요즘 “공유하지 않으면 망한다..” 라는 말이 있듯이 현재 e-비즈니스 환경은 위키나 블로그등으로 대변되는 참여 중심의 WEB 2.0 환경으로 변화하고 있다.

마찬가지로 기업의 비즈니스 환경 역시 공유와 참여가 필요로 하게 되는데, 서비스화된 업무들을 OPEN API 형태로 외부에 제공하거나 또는 부서별이나 개인별로 각각의 업무에 맞춰서 워크플레이스를 Mash-up (매쉬업)을 통해서 조합하여 기업의 다양한 업무 요건에 대한 대응을 더 이상 IT 부서에만 일임하는 것이 아니라, IT 부서는 업무를 위한 컴포넌트를 제공하고, 실제 현업에서 구성할 수 있는 형태의 개방성을 부여하는 기능이 제공될것이다.

 또한 태그 방식의 검색등을 통해서 기업내에 흩어져 있는 자산과 서비스들에 대한 사용성이 높아지게 될것이고, 이는 기업내의 지식과 자산의 공유를 가속화 시킬것이다.

 

 

3. SOA 2008

이렇게 변화된 각 계층간의 모델을 정리해보면 다음과 같다.

2007년까지는 SOA 의 개념이 도입되고 정리되는 기간이었고, 기업에서는 이런 개념들을 관측하고 평가해왔으며, 발빠른 업체는 SOA의 도입을 시작하였다.

2008년에는 SOA의 관련 기술이 성숙단계에 들어서고 기업들 역시 적극적으로 SOA의 도입을 준비할것이다.  2007년에 진행되었던 SOA의 경험들을 바탕삼아 벤더에서 제공하는 SOA기술들은 개념으로만 떠드는 SOA가 아니라 고객의 요구사항을 충분히 반영한 실용주의성의 사상과 솔루션으로 발전되어서 부족한 기술이나 쓸모없는 기술은 도태되고 필요한 사상이나 기술들은 점점 더 진화되는 한해가 될것이다.

 또한 오픈소스 진영을 중심으로 발전한 WEB 2.0 관련 기술과 참여 공유의 사상은 기업의 SOA 시스템의 사상에 급속하게 녹아들면서 POA라는 이름으로 영향을 줄것이다.

 

 특히 현대의 기업의 IT 부서는 예전과는 달리 ROI가 적거나 RISK 가 높은 기술에 대해서는 점점 도입을 꺼리고 적극적인 검증을 통한 실용적이고 합리적인 경향이 높아졌기 때문에, 아직 SOA 기술에 진입하지 않은 기업은 SOA를 적극적으로 검토하는 한해가 될것이고, 이미 SOA 기술에 진입한 발빠른 업체들은 다른 기업보다 앞서서 자사의 SOA 모델을 성숙시켜가고, 비즈니스 모델에 적용해 나가면서 빠르게 변하는 업무 환경에 빠르고 유연하게 대응할 수 있는 IT 시스템들을 갖추게 될것이다.

“제이슨 블룸버그”의 말처럼, SOA를 하지 않는 기업은 망한다.

 

신고

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

SOA 가 어려운 이유..  (0) 2008.11.12
관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04

Next Enterprise

아키텍쳐 /SOA | 2007.12.21 11:20 | Posted by 조대협

사용자 삽입 이미지
역시 BEA는 재미있는 기업이다.
EAI-->SOA로 이어진 기술의 파이프라인이 내년에는 Dynamic Biz App라는 개념을 들고 나왔다.

기존의 SOA 발전 모델에 대한 Stack을
1. Service Enablement를 통한 Share & Integration
2. ESB 구축을 통한 Flexibility 추가
3. BPM을 통한 Agility의 추가
이런 개념으로 생각했는데.
1.2. 개념을 합쳐서 SOA 사상으로 인식하고
그위에 BPM을 얹어서 Agility를 추가한후에
이것들을 하나의 서비스로 묶고 Saas(Software as a service) 개념을 넣어서, 플랫폼이나 기술에 종속성을 없애버린다. 여기서  SCA (Service Composition Architecture) 기술이 사용된다.
이렇게 서비스화된 기능들은 맨 윗단에 UI를 통해서 사용되는데
여기에 들어가는 개념이 WEB 2.0을 중심으로 함 "협업"과 "참여"의 개념이 들어간다.
Wiki나 Folksonomy와 같은 검색과 Mashup 지원이 들어가는데
이 중심을 이루는 것들이 EP(Enterprise Portal)과 Web 2.0 솔루션 BEA PEP (Pages,Ensemble,Pathway)가 차지하게된다.
이 WEB 2.0개념은 Enterprise Social Computing 또는 POA (Participant Oriented Architecture)라는 이름으로 맵핑이 되게 된다.

즉 기존 SOA개념에 + SCA + WEB 2.0 = Dynamic Biz Application이라는 것인데.
구체적인 개념정립은 좀더 시간이 필요한것 같고 (성숙의 시간이 필요하겠고)

Non-Enterprise World에서 WEB 2.0과 Open Source의 개념을 바탕으로 "공유"와 '참여"의 개념이 급속하게 퍼졌던 반면 Enterprise에서는 이에대한 반영이 늦었는데, 이것이 Enterprise에 적용될 수 있는 기회가 생겼다는 것이 주목할만 하며, 또한 OPEN Source들중 Ruby나 Spring,PHP와 같이 Non-Enterprise Level의 Light-weight하고 Agile한 기술들이 수용되었다는데 큰 의미가 있겠다.
 
신고

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

관심이 가는 오라클 제품들  (0) 2008.10.15
2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04
About SOA  (2) 2007.08.20

What is SOA? How to SOA?

아키텍쳐 /SOA | 2007.09.04 10:34 | Posted by 조대협

컴퓨터 시스템이 사용되면서부터, 각 시대의 기업 전략에 맞는 소프트웨어 아키텍쳐 존재하여 왔다. 초기 시대의 메인프레임에서는 기업의 업무를 전산화 하는데 목적이 맞춰졌고, 소프트웨어는 구조적 프로그래밍 (Structured Programming)으로 개발되었다.

그 후 개인 PC가 도입되면서 클라이언트 서버 시대 아키텍쳐가 도입되었고, 근래의 인터넷과 e비지니스 시대에서는EJB COM기반으로하는 컴포넌트 기반의 개발이 중심이 되었다.

그리고 지금의 IT 시스템들은 비즈니스의 급격한 변화를 수용할 수 있는 민첩성이 요구 되게 되었고, 이 요구를 충족시키기 위한 아키텍쳐가 서비스 지향 아키텍쳐 SOA 이다.

 이번 강좌에서는 SOA가 무엇이고 어떻게 SOA를 진행할지에 대해서 간략히 살펴보도록 한다.

 

1.    SOA 기본 개념

SOA, 기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍쳐이다.

 또한 기존의 시스템이 각각의 독립된 업무 시스템으로 개발되어왔던 반면 SOA는 기업의 전체 업무가 하나의 거대한 SOA시스템으로 구성이 된다.

 

이해를 돕기 위해 예를 들어보자, 자바 기술 기반으로 개발된 고객 정보 시스템, 룰 엔진으로 구현된 룰 엔진, 메인프레임을 구현된 계좌이체 업무 등이 있다고 가정하자.

이 각각의 업무들은 각각의 목적에 따라서 따로 개발된것이고, 서로 연계가 불가능했다.

이 각각의 시스템의 기능들을 업무를 기준으로 주요 기능들로 묶어서 플랫폼에 독립적인 인터페이스 (예를 들어 XML/HTTP, CORBA,SOAP)를 구현하여 외부로 서비스를 제공한다.

사용자 삽입 이미지
<그림 1 SOA의 개념 >

이렇게 제공된 서비스 인터페이스를 이용하여 신용 대출 이라는 새로운 업무를 구현할 때 새롭게 시스템을 신규 개발하는것등이 아니라 기존의 이미 제공되어 있는 서비스들을 조합하여, 하나의 업무를 구현할 수 있다. 이것이 SOA의 기본적인 개념이다.

 

SOA 자체는 새로운 개념은 아니다. 소프트웨어 개발에 있어서 계속해서 이야기 되어 왔던 소프트웨어의 재사용성레고웨어 [. 소프트웨어 모듈을 레고블럭처럼사용성이 높은 단위로 구성한후, 애플리케이션을 마치 레고 블록을 조립해서 하나의 조립물을 만들듯이 제작하는 개념] 의 연장성에 있는 것이다.

 

이런 SOA 개념과 구현된 프로젝트는 이미 1990년대부터 구현되어 왔고 존재되어 왔다. 그럼 지금에 와서야 SOA가 주목 받는 이유는 무었인가? 예전에 서비스 구축을 위한 표준 인터페이스에 대한 방안으로 제시되었던 CORBA등의 기술의 난이도가 높은 점이 문제가 되어 왔으나 현재에는 XML/HTTP SOAP 기반의 웹서비스 기술등의 등장으로 서비스의 구현의 기술 난이도 문제가 해결되었고,

e비즈니스 환경에서 기존 업무 환경을 전산화 하는데에만 목적이 맞춰져 있어서 각각의 업무별로 독립된 시스템의 형태로 개발이 되어, 이에 대한 통합이 필요하게 되었으며 [예를 들면 고객 정보를 매출 내용과 연계하여 판매 전략을 수립하는 경우 등] 급격한 비즈니스 환경의 변화에 따라 비즈니스의 요구를 민첩하게 IT시스템에 반영되어야할 필요성이 대두됨에 따라 이에 대한 대안으로 SOA가 대두 되었다.

 

앞에서도 설명하였지만 SOA는 크게 서비스와 이를 조합하여 애플리케이션을 구성하는 으로 구성된다. 지금부터 각 서비스서비스를 구성하는 방법 에 대해서 알아보도록 하자

 

2.    서비스란?

서비스란 플랫폼에 종속되지 않는 표준 인터페이스(CORBA웹서비스) 통해서 기업의 업무를 표현한 Loosely coupled하고 상호 조합 가능한 소프트웨어 이다.

현대의 SOA에서 서비스의 플랫폼 종속성은 SOAP기반의 웹서비스 또는 XML을 통해서 구현된다. 서비스를 표현하는데 있어서 가장 중요한 특징은 기업의 업무를 표현한다는 것이다. 임직원 정보 서비스,계좌 이체 서비스와 같이 기업의 업무는 서비스로 정의할 수 있지만  JNDI Lookup, SMTP 이메일 클라이언트와 같은 비업무성 서비스는 존재할 수 없다.

 

(1) 서비스의 구성

서비스는 크게 3가지 요소로 구성된다.

 - 서비스 인터페이스

 - 서비스 규약

 - 서비스의 구현체

사용자 삽입 이미지

< 그림 2서비스의 구조 >

서비스 인터페이스는 서비스내의 하나의 업무 기능을 이야기 한다.

즉 주문서비스라는 서비스가 있을 때, 이 서비스는 상품 주문 주문 내용 조회라는 인터페이스를 가진다. (EJB나 자바 오브젝트의 비즈니스 메서드를 생각하면 되지 않을까?)

그리고 이 서비스를 사용하기 위한 여러가지 규약들 데이터 포맷이나 수형 서비스를 호출하기 위한 인자나 인터페이스 이름등이 정의되는 곳이 서비스 Contract이다.

이에 대한 실제 구현체가 Implementation.

현대의 SOA에서는 대부분이 웹서비스를 표준 인터페이스로 사용하기 때문에 서비스 Contract WSDL로 정의된다.

 

(2)서비스의 특징

서비스는 몇가지 특성을 가지고 있는데, 그중 몇 가지 중요한 특성을 뽑아보면 다음과 같다.

Ÿ          수직적 분할 (Vertical Slicing)

수직적 분할이란 애플리케이션을 개발할 때 전체 애플리케이션을 여러 개의 서비스로 나누고 각각의 서비스를 독립적으로 개발하는 것을 이야기 한다.

이전의 소프트웨어 개발은 애플리케이션을 각 Data Layer, Business Logic,View Layer와 같이 수평적으로 분리하였다. 그러나 SOA에서는 각각의 서비스가 Data Layer,Business Logic,View에 대한 모듈을 모두 가지고 있고 그래서 각 서비스간의 의존성이 최소화 된다.

사용자 삽입 이미지
<그림 3 Vertical slicing의 개념 >

Ÿ          Has standard interface

서비스가 제공하는 인터페이스는 표준 기술로 구현이 되어야 한다. 서비스를 사용하고자 하는 사람이 서비스 규약만을 가지고도 해당 서비스를 호출할 수 있어야 하며, 이는 해당 SOA시스템 내에서 플랫폼이나 기술에 종속되지 않아야 한다.

Ÿ          Loosely Coupled

Vertical Slicing에서도 설명하였듯이 각 서비스 컴포넌트들은 다른 서비스에 대해서 의존성이 최소화 되어 있어서 서비스의 구현내용등을 변경하였을 때 다른 서비스가 이에 의해서 영향을 거의 받지 않는다.

Ÿ          Composable

서비스 컴포넌트들은 서로 연결되어 조합된 형태의 하나의 애플리케이션을 구성해야 하기 때문에, 서비스간에 연결 및 조합이 가능해야 한다.

Ÿ          Coarse grainned

서비스의 구성단위나 인테페이스의 단위는 업무 단위를 기본으로 한다. IT 개발 조직이 아니라 현업의 비즈니스 조직이라도 해당 서비스가 무엇이고 무슨 기능을 하는지 이해할 수 있어야 한다.

Ÿ          Dicoverable

서비스에 대한 정보가 검색 가능해야 한다. SOA시스템의 규모가 증가함에 따라 서비스의 중복이 발생할 수 있고, 이를 방지하기 위해서 이미 구현된 서비스가 있는지를 검색할 수 있어야 하며, 검색 내용에는 서비스의 내용과 서비스에 대한 사용방법,권한,보안에 대한 정보들이 포함되어야 한다.

 

(3) 서비스의 종류

서비스를 그 기능에 따라서 5가지 정도로 나눠볼 수 있다.

일반적으로 우리가 지금까지 이야기 했던 서비스는 비즈니스 서비스 이다.

이 비즈니스 서비스는 말 그대로 비즈니스 적인 의미를 가지는 서비스로 SOA의 최소 단위가 되며, 비즈니스 로직을 구현한 Task centric service와 비즈니스 데이터를 대표하는 Data centric service로 분리된다. [. EJB Session Bean Entity Bean 정도로 생각하면 된다.]

 

다음은 Intermediary 서비스 인데, 업무적인 기능을 가지는 것이 아니라 서비스들을 연결하는 데서 발생하는 차이점을 보안해주는 서비스 이다.

몇가지 예를 들어보자

기존의 백화점의 구매 프로세스가 존재하였다고 가정하자. 백화점의 업무 요건이 바뀌어서 일반고객과 VIP고객에 대한 구매 프로세스를 차별화 하였을 때, 고객의 요건에 따라 구매 프로세스를 서로 다르게 호출해야 한다. 이런 유형을 Routing 서비스라고 한다.

서비스에 들어오는 데이터 타입이 구매자의 이름,구매액과 물품 목록 이었는데, 서비스가 수정되면서 데이터 타입이 변화가 되었을 때 기존에 이 서비스를 호출하던 모든 서비스 소비자는 데이터 타입의 변경으로 모두 변경이 되어야 하며 이런 이유로 업무 변화에 유연하게 대처를 하지 못하는데, 이런 경우 구 데이터 타입을 새로운 데이터 타입으로 변화시켜주는 서비스가 있으면 유연하게 변화에 대처할 수 있다. 이런 형태의 서비스를 Transform 서비스라고 한다.

사용자 삽입 이미지

<그림 4 Routing 서비스 >

 

사용자 삽입 이미지

< 그림 5 Transform 서비스>

그 외에도 기존 서비스에 새로운 기능을 추가하는 Functional Adding서비스, Façade 기능을 구현한 서비스등을 그 예로 들 수 있다.

 Process centric 서비스 는 비즈니스 서비스들을 조합하여 하나의 업무 프로세스를 구현해내는 서비스로, 주로 상태가 있는 (Stateful)를 구현하는데 이용이 된다.

 Application 서비스 Technical한 서비스 트렌젝션 서비스, 로깅 서비스가 예가 된다. 지금까지 설명하면서 서비스는 비즈니스적인 의미를 가진 컴포넌트 이며 트렌젝션 등은 서비스가 될 수 없다.. 라고 이야기를 했지만, 현실세계에서 이런 서비스가 나오지 않을 수 있는 보장이 있을까? 언제나 예외는 존재한다고 SOA에서 지극히 예외적인 서비스이다. 잘 설계된 SOA에서는 Application 서비스가 존재하지 않는다.

 Public enterprise 서비스는 다른 회사나 다른 SOA시스템으로 제공되는 서비스이다. [은행의 대외계 업무 정도가 이에 해당한다.] 다른 서비스에 비해서 외부로 제공되는 서비스인 만큼 성능, 트렌젝션, 보안에 대한 깊은 고려가 필요하다. 

3.    SOA 아키텍쳐 모델

지금까지 서비스가 무엇인가? 에 대해서 알아보았다. 지금부터는 이 서비스들을 어떻게 조합하여 소프트웨어 시스템을 구성하는지, 구성 방법에 대해서 알아보도록 하자.

서비스의 구성 방법의 기업의 SOA 성숙도와 발전 정도에 따라 단계적으로 적용되어야 한다.

단계적인 발전 모델을 설명하기에 앞서서 application frontend 대해서 설명하면, 서비스들이 사용되어 최종 사용자에게 보이는 곳이 application front end이다. 일반적인 웹사이트나 기업 포탈, X 인터넷 클라이언트, 4GL 클라이언트등이 될 수 있다. 

(1)Fundamental SOA [통합]

가장 기본적인 형태의 SOA, 비즈니스 서비스와 애플리케이션 서비스만 존재하며 이 서비스들의 조합들은 application front end에서 이루어 진다.

Fundamental SOA의 가장 큰 목적은 기존의 시스템을 각각 서비스화하는 것과 독립되었던 시스템들을 통합하여 하나의 시스템으로 운영한다는데 목적이 있다. 

(2)Networked SOA [ 유연성과 통제 추가 ]

서비스화하여 통합된 SOA시스템은 시간이 갈 수 그 크기가 커지게 되고 서비스간의 호출은 관계는 날이 갈 수 복잡해진다. 그리고 서비스의 내용이 변경 또는 보강 되어 가면서 의존성에 의해서 서비스간에 수정이 필요한 경우가 발생한다. 이는 서비스의 변화를 어렵게 만들고 결과적으로 기업 업무에 대한 경직성 유발하는데, 이를 해결하기 위해서 모든 서비스들을 중앙에 하나의 버스를 통해서 관리하여 서비스간 연결의 복잡도를 해소하고 Intermediary 서비스를 추가 함으로써, 서비스의 내용이 변경되었을 때 그 차이를 보강해줄 수 있어야 한다.

 

사용자 삽입 이미지

<그림 6 Networked SOA 개념 >

이렇게 중앙에 버스 역할을 하는 것이 Enterprise Service Bus (ESB)이고, 여기에는 서비스에 대한 모니터링과, Intermediary 서비스 기능의 제공, 위치에 대한 투명성 제공을 통해서 기본적인 통제유연성 제공을 특징을 한다. 

(3) Process Oriented SOA [ 민첩성의 추가 ]

기업의 업무프로세스가 자주 변화가 되고, IT 시스템이 이에 민첩하게 반응해야 하거나, SOA로 구현해야 하는 기업 업무들에 복잡한 업무 플로우가 존재할 경우 이 업무 프로세스들을 BPM기반으로 구현하는 SOA를 고려해볼 수 있다.

 각 서비스를 조합하는 것을 BPM으로 구현함으로써, 업무의 조합이 별도의 코딩 없이 BPM툴로 이루어 지게 되고, 업무프로세스가 바뀌었을 때 BPM툴에서 업무프로세스를 조정하는 것만으로도 빠르게 비즈니스 조직의 요구에 대응하여 IT 시스템이 비즈니스 업무에 대한 민첩한 대응력을 확보할 수 있다.

 또한 업무 조직과 기술 조직간의 의사 소통에 있어서도, 기존에는 업무조직은 EJB JAVA와 같은 기술적인 내용을 이해하지 못하였고, 기술 조직의 경우 업무에 대한 이해도가 낮았기 때문에 의사소통에 있어서 많은 문제를 유발하였는데, BPM을 도입할 경우, BPM에서 사용되는 모든 서비스는 이미 업무적인 의미를 가지는 컴포넌트이기 때문에 IT조직과 업무 조직간에 의사 소통을 하는데 문제가 없으며, 특히 업무 프로세스의 경우 직접 업무 조직이 큰 흐름을 정의하고 IT조직이 구현화에 있어서 보강만 함으로써 빠르고 정확한 의사 소통을 이룰 수 있다.

 BPM과 함께 생각할 수 있는 것이 BPA(Business Process Analysis) BAM(Business Activity Monitoring) 이다. BPA는 실제 업무플로우를 BPM으로 구현하기 전에 업무팀에서 해당 업무 플로우에 대한 설계를 하고 이에 대한 시뮬레이션을 할 수 있는 Business Process 분석 설계 도구이다.

BPA를 통해서 현 업무팀에서 해당 업무프로세스를 정의하고, 작동 내용을 시뮬레이션 함으로써 보다 완성된 업무 프로세스를 얻을 수 있으며, 이렇게 설계된 업무는 IT 개발팀에 의해서 BPM으로 변환이 된다.

BPM으로 변환된 업무는 SOA 시스템에 반영되어 실제 운영이 되게 되고,

BAM이라는 비즈니스 프로세스 모니터링 도구를 이용하여 반영된 BPM에 대한 평가가 이루어진다. 이 평가를 기반으로 업무팀에서는 다시 BPA를 이용하여 해당 업무의 최적화를 수행하고 다시 이는 BPM으로 구현이되고.. 이러한 반복을 통해서 업무의 개선과 SOA시스템이 최적화를 이룰 수 있다.

사용자 삽입 이미지
<그림 7. BPA,BPM,BAM 통한 업무 프로세스의 구현과 업무의 최적화 >

4.    SOA 아키텍쳐 모델의 구현

앞에서 설명한 3단계 아키텍쳐를 실제로 구축하는데 있어서 고려할 사항이 있다. 

(1) 서비스화

먼저 Fundamental SOA에서 가장 중요한 것은 기존의 시스템을 서비스화 시키는 것이다. 현재의 서비스 인터페이스는 대부분 SOAP 기반의 웹서비스를 사용하는데, 솔루션 중에는 이미 Legacy System에 대해서 웹서비스를 제공하는 서비스 아답터 제공된다. (IWay社의 SAP, Siebel 아답터, BEA Tuxedo 웹서비스 아답터 SALT etc)

대부분의 서비스 아답터를 통해서 서비스화된 기존 메서드들은 비즈니스 적인 의미를 가지지 않는 Application 서비스가 될 가능성이 많다. 서비스화를 하기전에 기존 시스템에 기능등을 업무 단위의 Coarse grainned된 컴포넌트로 묶은후에 서비스화 하는 것이 좋다.

 

(2) 스펙과 범위

고려 사항중 하나가 트렌젝션이나 Reliable 메세징과 같은 웹서비스 스펙에 해당하는 문제이다. 현재 웹서비스의 확장 규약인 WS* (Webservice Extenstion)의 경우에는 트렌젝션이나 Reliable Messaging과 같은 기능들을 제공하고 있지만 문제는 서비스화를 시켜주는 솔루션에는 이에 대한 지원이 의무사항이 아니라는 것이다. 트렌젝션 기능들을 웹서비스에서 지원하는 기능을 사용하려고 했다가 막상 해당 시스템의 웹서비스에서 트렌젝션 기능들을 지원하지 않아서 문제가 될 수 있다. 서비스를 정의할 때 어떻게 이런 기능들을 구현할지에 대한 고려가 앞서야 한다.

 이런 서비스 구현에 있어서 유용하게 사용할 수 있는 것이 EAI이다. EAI는 시스템간의 통합을 목적으로 하는 솔루션으로, SOA는 다르게 Tightly Coupled 되고 비즈니스적인 통합이 아니라 IT 시스템간의 통합을 지원함으로써,  SOA 통합에서 다루기 힘든 트렌젝션이나 보안에 대한 내용을 해결해준다.

[ EAI 솔루션에도 IT 시스템간의 연계 흐름을 정의 하기 위해서 BPM이 사용되는데, 시스템간의 흐름과 업무 흐름을 분리하기 위해서 이를 각각 IC-BPM HC-BPM으로 구분하여 부른다.]

 

(3) 보안

보안에 대해서는 따로 길게 설명하지 않겠다. 암호화 선택할때는 전체 메시지를 암호화할지 메시지 내용중 일부만 암호화 할지가 결정해야 하며, 중앙에서 각 서비스에 대한 사용 권한과 계정에 대한 관리를 할 수 있는 솔루션을 구성할 필요가 있다.

 

(4) 모니터링

여러 시스템을 하나의 SOA 시스템에 구축한 만큼 각각의 서비스에 대한 모니터링과 성능 측정은 매우 중요한 요소로 작용한다. SOA 시스템을 구축할 때 미리 로깅과 모니터링 성능 측정에 대한 기능을 미리 구현할 필요가 있다.

 

(5) 서비스 검색

SOA 시스템에서 이미 개발된 서비스를 재사용하기 위해서 서비스를 검색할 수 있어야 하며, 서비스에 대한 메타 정보 (보안,과금체계 등에 대한 규약등)들도 검색할 수 있어야 한다. 웹서비스에서는 이를 UDDI로 구현한다.

 

(6) Application frontend

Application frontend는 최종 사용자에게 업무 기능을 제공하는 부분으로, 일반적인 웹 인터페이스를 이용할 수 도 있으며, Rich client의 개념을 웹에 도입한 AJAX 기반이나 Flex  같은 X-Internet 솔루션을 사용할 수 도 있다.

SOA 시스템은 여러 시스템을 통합한것으로 여러 메뉴와 UI가 통합 되기 때문에 권한과 메뉴등에 대한 관리 기능이 필요하게 되며, 이는 Enterprise Portal (EP)솔루션등을 이용해서 쉽게 구현할 수 있다. 지금까지 설명한 SOA 아키텍쳐 구성을 하나의 그림으로 표현해보면 다음과 같다.

 

사용자 삽입 이미지

<그림 8 SOA 레퍼런스 아키텍쳐 >

지금까지 SOA가 무엇인지, 그를 구성하는 서비스의 개념과 서비스를 조합하여 SOA시스템을 구축하는 방법에 대해서 알아보았다.

그렇다면 실제로 SOA 프로젝트를 수행하는데 있어서 어떻게 SOA 시스템을 구축하며 프로젝트를 진행해야 할까? 아래부터는 SOA의 수행 방법론에 대해서 알아보도록 하자.

 

5.    SOA 수행 방법론

SOA 시스템은 기존의 시스템과는 다르게 기업에 업무별로 개개별 시스템이 존재하는 것이 아니라, 이러한 개개별 시스템을 통합하여 하나의 거대한 IT 운영 플랫폼을 구축하는데 있다. 이에 따라 SOA 시스템을 수행 하는 방법도 역시 차이가 나는데, 기업의 전략, 비용의 집행방법, 팀의 통제, 프로젝트 관리 방법을 기준으로 하나씩 알아보도록 하자

 

(1) 기업의 전략

IT 시스템은 기본적으로 기업 업무에 대한 반영이다. 그래서 SOA시스템을 통해서 제공하고자 하는 기능은 기업의 전략에서부터 파생된다.예를 들어 기업 경영 전략이

2004년 매출 증대

2005년 고객 만족 실현

2006년 브랜드 이미지 관리

와 같다면, 이를 지원하기 위해서 IT시스템의 구현 전략을 다음과 같은 것들이 될 수 있다.

2004년 매출 내용 전산화

2005 CRM 도입을 통한 고객 정보 수집과 매출 내용을 기반으로 고객 패턴 추출

2006년 수집된 고객 정보를 토대로 마케팅 집중

SOA의 수행은 기업의 경영 전략에 따라서 수행되며, 성공적인 SOA를 위해서는 해당 단계에서 기업의 핵심 업무를 SOA화 하는 것이 필요하다.

또한 기업의 IT전략은 예전처럼 각각의 단위 시스템을 개발하는 것이 아니라 기업의 전략을 IT화하여 구현한 SOA시스템을 기업의 발전에 따라서 계속 반영 및 변화 시켜나가기 때문에 기존 IT전략에 비해서 좀더 장기적인 전략을 필요로 한다.

(2) 비용의 집행

SOA 시스템은 비용 집행에 대한 고려가 필요하다. 기존 IT시스템은 단위 시스템에 대한 개발 프로젝트에 소요되는 비용만 예상하여 집행하면 되었지만, SOA 계속해서 발전해 나가는 시스템이고 한 시스템에 기능이 추가 되기 때문에 비용 집행 방식이 다르다.

 SOA 시스템의 경우 초기에 SOA에 필요한 인프라의 구축 (ESB,BPM,모니터링,보안 인증,UDDI )에 비용이 많이 소요되기 때문에 초기 투자 비용이 기존의 IT 시스템 보다는 높아진다.

사용자 삽입 이미지
< 그림 9 SOA의 비용 집행 방법 >

그러나 위의 그림에서와 같이 계속해서 업무를 추가해나감에 따라 새로운 업무가 완전히 새롭게 구성이 되는 것이 아니라 앞단계에서 개발하였던 서비스들을 다시 재 사용되기 때문에 개발 비용은 지속적으로 감소하게 되고, 기능이 부족한 서비스들은 계속해서 대체 되면서 안정적으로 유지 되기 때문에 시간이 갈 수 소요 비용은 감소하게 된다.

 

(3) 제어와 통제

SOA 시스템이 거대화해짐에 따라 SOA 시스템에 대한 중앙 관리 및 통제 제어가 필요하게 된다. 어느 서비스부터 개발해야 할것인지, 이번 기간내에 진행해야할 SOA범위, 각 개발에 대한 표준화, 자금 조달 계획등을 수행해야 하며 이를 통제하는 조직이 필요하다. 이러한 통제를 Goverance라고 하는데,

이 통제를 실시하는 Governace 조직에서 하는 일은 다음과 같다.

-         SOA 시스템에 대한 정책 수립 및 표준화 - Standard

-         SOA 관련 기술 전파 및 가이드 - Evangelist

-         SOA 구축 계획 수립 및 실행 (로드맵)- Strategy

-         자금 조달 및 집행 계획

-         업무 분석 및 설계

-         문화 변화 IT조직과 비즈니스 협업 조직의 협업문화 개발

-         모범사례 수집과 배포

여기에는 여러가지 통제 모델을 도입할 수 있는데, 운영 환경상에 서비스의 개발 배포 모니터링을 위한 통제 모델이다.

 

사용자 삽입 이미지

<그림 10 SOA 제어 통제 모델 예시 >

중앙 통제 조직은 실 개발 조직인 IT 조직과 비즈니스 조직간의 중계 역할을 하게 되며, 비즈니스 조직으로부터 전략과 요구 사항을 받아 실제 구현 조직에 전달을 하며

각 개발 조직에서 개발된 내용들에 대한 검증 및 배포 작업과 SOA 플랫폼에 대한 운영 및 모니터링 통제를 실시 한다.

 이외에도 CVS등을 이용한 소스의 통제, apache maven과 같은 도구를 이용한 빌드의 관리, 일일 빌드 정책, 개발 방법론등도제어와 통제에 해당한다. 

(4) 프로젝트 관리

SOA의 프로젝트 진행에 있어서 특이한 점은 반복적인 개발(Iterative Development)점진적인 개발(Incremental Development)이다. 한번에 SOA 전체 시스템을 개발하는 것이 아니라 중요 업무를 먼저 개발한후에 반복적으로 업무에 대한 개선 작업을 병행하고, 점차적을 필요한 기능을 추가해나가는 모델이다.

 또한 SOA의 프로젝트 개발 관리는 앞에서 설명 했던 Thin Thread Model의 개발 방식을 준수 하면 좀 더 좋은 효과를 볼 수 있다. 

6.    결론

지금까지 SOA가 무엇인지, SOA를 구성하는 서비스의 형태와 특징은 어떠한지 그리고 SOA 프로젝트를 수행하는 몇가지 권고 방안에 대해서 살펴보았다.

 SOA ESB BPM같은 솔루션을 제외하고라도 이미 서비스의 개념과 서비스 인터페이스의 개념을 도입하여 개발되는 사례가 많다. 특히 AJAX X 인터넷의 등장으로 SOA 기반의 시스템 도입은 가속화 되어갈 전망이다.

 여기서 중요한점은 SOA의 개념이 무엇인지를 명확하게 이해하고, 현재 기업에서 필요한 SOA의 단계를 파악하여 적절한 수준의 SOA를 도입하고, SOA 시스템을 장기적으로 발전 시켜나갈 수 있는 장기적인 전략과 이를 수행할 수 있는 제어와 통제 모델 (Governance)를 구축하는 것이 중요하다.

신고

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

2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04
About SOA  (2) 2007.08.20
SOA에 대한 기술적 접근  (2) 2007.08.20

SOA & Agile

아키텍쳐 /SOA | 2007.09.04 10:26 | Posted by 조대협
예전 정리했던 글
==

요즘 읽는 책들이

XP,조엘온소프트웨어,대한민국에는 소프트웨어가 없다, 소프트웨어 프로젝트 생존 전략,TDD 주로 소프트웨어 프로젝트 방법론에 대한 책들이다. (지금은 생존전략을 읽는중이다. TDD는 사놓고 대충만 보고.. 다시 봐야 할텐데..)

접근 하는 방식은 틀리지만, 변경 관리, Short release,단계적 개발 모델, 개발자에 대한 배려 사용자 참여,등등. 결과적으로 이야기 하는 내용은 틀리지 않다.

근데 여기에 왜 Governace 이야기를 들고 나왔냐 하면, Governace도 결국 따지고 보면 소프트웨어 프로젝트 관리 방법론이고 뚜껑을 열어보면 위에서 설명하고 있는 내용들을 약간 더 서비스 개념에 맞게 포장해놓은것 뿐이고 같은 내용이라고 보인다.

결국에는 사람들이 생각하는 것은 똑같은게 아닌가 싶고,
Governance의 접근도 벤더의 Tool에 의해서 접근을 하는것이 아니라, 위의 개념들에 의해서 접근을 한후에 Tool을 그 개념에 맞게 배치하는것이 중요하겠다.

SOA Governace는 새로운것이 아니다. 기존의 소프트웨어 프로젝트 관리에 있어서 문제가 되어 왔던것들이 현재에 들어서 정재되고 재 정립되면서 SOA에서는 Governance라는 하나의 새로운 이름만을 가진것이다.
===
위의 개념들을 SOA에 맵핑 시켜보면

변경 관리 --> 변경 통제
Short Relase --> 전략과 업무 우선 순위별 개발
단계적 개발 모델 --> Vertical Slicing, 반복적 개발 모델, 단계적 비용 집행 모델
개발자에 대한 배려 --> Governance Team과, Stakeholder, Team control
사용자 참여 --> Communication,BPA, 비지니스 업무에 대한 사용자들의 구현

결국은 그이야기가 그이야기네...
신고

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

2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04
About SOA  (2) 2007.08.20
SOA에 대한 기술적 접근  (2) 2007.08.20

About SOA

아키텍쳐 /SOA | 2007.08.20 11:19 | Posted by 조대협

2007년 7월 6일 포스팅 글
==
이번에도 SOA기고를 하나 하긴 했는데. 맨날 했던 말이 그말인것같다.
한번 더 고민 한점이 있다면 한국에서만 유달리 SOA가 전파되지 않는다는 것이다.
근래의 N社에 입사해서 시스템들의 구성들을 이야기 들어보면, SOA의 필요성이 인식이된다. 비단 Enterprise만이 아니라 service업체에서도 개개의 서비스들을 XML형식으로 통신하는 구조가 많이 있는데, 중앙에서 통제되지 않고, XML-RPC, WebService, XML-HTTP 등등 프로토콜이 각각이고 Granuality도 각각이며, UDDI와 같은 Dictionary도 없는것 같다.
흔히들 말하는 공통 서비스들이 그것이 될테인데. 이미 SOA의 1차적 개념을 가지고 접근을 하고 있으나 SOA적인 접근을 이루는 경우는 많지 않다.

현재 IT 시스템들은 SOA와 같은 서비스 통합의 개념이 필요할 정도로 이미 성숙하였고 (Process Oriented SOA나 Event Driven SOA는 별게 겠지만..) 어떠한 형태로든지 제공이되고 있다.

그렇다면 왜? SOA가 도입이 되지 않을까?
첫번째는 SOA가 무엇인지 모르는 이해의 부족에서 온다.
현 업무 시스템의 구조가SOA가 필요함에도 불구하고, 이를 다른 방향으로 각각의 부서에서 독립적으로 개발하고 있다.
이를 해결하기 위해서는 각 개발 부서에서 SOA에 대한 이해를 충분히하고 도입 여부를 결정해야 하며, 공통 개발팀이나 Evengelist 그룹에서 SOA 기술에 대한 적극적인 홍보에 나서야 한다.

두번째는 경영진의 인식 부족이다.
SOA개념이 좋다는 것은 알고 있고 무엇인지도 이제는 대충 알고 있으리라 본다. 거버넌스도 이미 알고 있을듯 하지만, 문제는, 이 SOA가 장기적인 플랜이 필요하고 강제적인 중앙 통제가 필요하다는 것을 인식하지 못하는것 같다. SOA를 IT전략으로 체택하고 장기적으로 SOA를 적용해야 하는데 단기 위주의 프로젝트구조에서는 이것이 힘들다는것.

특히나 첫번째에 언급한것처럼 Evangelist의 부재로 인한 점이 하나의 문제점인데.
SOA는 하나의 IT 비젼이기 때문에 말단 개발자까지도 SOA에 대한 기본 개념을 파악하고 회사의 SOA 전략을 IT전략으로 인식해야 한다. 그래야 제대로 된 Service를 만들 수 있고, Loosely Coupled등의 개념을 적용하고 Governance에서 필요한 각각의 절차에 맞추어 일할 수 있는데, 개발자들에게 SOA는 하나의 귀찮은 개념으로 치부 되는것이 아닌가 싶다.

요즘들어서 Peopleware에 대한 생각을 많이 하는데, SOA 도입의 문제점은 기술보다는 사람이 문제가 아닌가 싶다.

얼마전에 K이사님이 조언해주신말중에 하나가
리더와 지도자의 차이중의 하나이다.
"사람을 통제하려고 하지 말고, 잘할 수 있도록 도와주는것이 리더와 지도자의 차이"라는 말을 요즘 생각하고 있는데. 언뜻 생각을 바꿔 보니 SOA 의 도입 방식도 거버넌스와 같이 지나치에 지도자적인 방향이 아닐까?
 각 이해당사자들이 SOA의 필요성을 인식하고 하나의 비젼으로 생각한다면 의외로 한국에서 SOA의 도입이 쉬워질 수 도...

 Do you want to introduce SOA into your company?
Make your customer to raving fan of SOA..!!

신고

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

2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04
About SOA  (2) 2007.08.20
SOA에 대한 기술적 접근  (2) 2007.08.20

SOA에 대한 기술적 접근

아키텍쳐 /SOA | 2007.08.20 10:55 | Posted by 조대협

월간 마이크로소프트웨어 2007년 7월호 기고 내용

==
“ SOA는 무엇이고, SOA를 준비하기 위해서 무엇을 해야 할까? 그리고 SOA 시스템을 구축하기 위해서는 어떤 기술을 준비해야 할까 ? ”

수년간 많은 벤더와 매체를 통해서 SOA라는 단어를 들어보고, 웹서비스, ESB, BPM, Governance와 같이 SOA와 관련된 주요 키워드들에 대해서 접해왔을 것이다. 그러나 정작 시스템을 어떻게 SOA화 해야하는지 심한 경우에 SOA 자체가 무엇인지 조차 이해하지 못하는 경우도 많다.

 이 글에서는 SOA의 올바른 이해와 함께, SOA 시스템 구축에 용이한 기술에 대해서 알아보도록 하겠다. 

  1. SOA란 무엇인가?

 SOA란, 기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한 후, 이 서비스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍쳐이다. 

SOA의 단계적 발전 모델

필자가 SOA를 이야기 할 때 빼놓지 않고 이야기 하는 것 중의 하나가 SOA의 발전 모델이다.  
초기의 SOA는 시스템을 서비스화하여 이를 묶어서 하나의 통합 시스템으로 구축하는 통합 중심의 SOA모델이었다. 이 모델은 P2P형식으로 서비스를 묶는 것에 중점을 두었으며 특히 이 기종간의 통합이 주요 목적이었다. 이런 초기적인 SOA 모델을 Fundamental SOA라고 이야기 한다.

이런 SOA모델이 발전함에 따라서 P2P형식일 경우 서비스간의 연결이 거미줄처럼 연결되어 통제가 불가능하게 되고, 서비스의 변경에 따라 그 서비스를 사용하는 다른 시스템에 영향도가 증가해서 시스템의 유연성이 떨어지게 되었다. 이를 보완하기 위해서 서비스의 연계 구조를 중앙에 Hub를 넣어서 중앙 집중형 구조로 변경하고 업무의 변화에 따라서 변화 내용을 반영하는 서비스 (Intermediary service)를 추가한 모델을 Networked SOA라고 한다.

기업의 업무 환경이 급속하게 변화함에 따라 서비스를 묶어서 구현한 업무 프로세스의 변경이 잦아지게 되는데, 이 잦은 업무 변화를 빠르게 반영하고 또한 현업과 IT조직간의 업무 정의에 대한 커뮤니케이션을 쉽게 하기 위해서 도입되는 것이 BPM이다. 이러한 BPM도입을 통해서 SOA시스템에 민첩성을 추가한 SOA구조가 Process Oriented SOA이다. 

간략하게 SOA의 개념과 발전 모델에 대해서 설명을 하였는데 이는 SOA를 개발하는데 유용한 기술의 발명 단계와도 관련이 있기 때문이다.  

좀더 자세한 설명은 http://blog.javastudy.co.kr/bcho/entry/What-is-SOA-How-to-SOA 문서를 참고하기 바란다 

  1. SOA 관련 기술

 웹서비스를 사용하면 SOA라고 말할 수 있을까? ESB를 사용하고 있으면 SOA 시스템이라고 말할 수 있을까?

 대답은 NO! 이다. SOA는 앞에서도 설명했듯이 시스템을 개발하기 위한 하나의 아키텍쳐이며 개념이다. 웹서비스나 ESB는 SOA개념을 구체화 하기 위한 요소 기술이나 솔루션에 불과하다. 이러한 기술들은 SOA 아키텍쳐를 구현하고 고민하면서 필요에 의해서 선택되거나 개발된 솔루션이다. 그래서 기술을 선택할 때 원래 이러한 기술이 나오게 된 이유 즉, 필요성에 대한 인식을 하지 못하면, 잘못된 기술을 선택하는 결과를 낳을 수 있다. 

“SOA에 대한 이해를 통해서 기술과 솔루션의 필요성을 인식한다.”

SOA를 구축하기 위한 몇가지 유용한 기술에 대해서 소개한다. 

  1. 업무 도메인에 대한 이해

“조엘 온 소프트웨어”를 보면 소프트웨어를 크게 4가지 종류로 나눈다. 기업용 소프트웨어, 서비스 소프트웨어, 패키지, 엔터테인먼트 소프트웨어 종류로 나뉘어 진다.

패키지는 MS-Office처럼 패키징이 되서 판매되는 소프트웨어를 말하고 엔터테인먼트는 게임이나 MP3 등과 같은 성격의 소프트웨어를 말하며 서비스 소프트웨어는 블로그, 카페, 인터넷 포탈과 같은 B2C 형식의 소프트웨어를 말한다.

 이 4가지 분류에서 현재 SOA가 적용되기 적절한 것은 기업용 소프트웨어와 서비스 소프트웨어 이다. 물론 소프트웨어 인프라가 발전이 되면 MS-Office에서 맞춤법 검사나 폰트등이 서비스 형태로 인터넷에서 제공될 수 있지만, 현재로써는 SOA가 적용되기에는 다소 이르다고 볼 수 있다.특히 현재 주류를 이루는 SOA는 기업용 소프트웨어는 업무 복잡도가 높고 시스템간의 복잡한 연계가 많아 SOA 사용시에 여러 장점이 많으며, 비용에 민감한 구조가 SOA의 장점에 부합하기 때문이다. 상대적으로 서비스 소프트웨어의 경우 은행 계좌 이체와 같은 Critical한 업무가 적으며 복잡도나 변화도가 낮기 때문에, SOA의 개념을 변형하여 WEB 2.0에서 OPEN API의 개념으로 구현하고 있다.

SOA를 적용하기 위해서는 적용하고자 하는 업무가 이 4개의 소프트웨어 종류중에 어느것에 해당하는지를 인식할 필요가 있다. 

  1. XML

 XML은 SOA의 서비스의 메시지를 정의하는데 매우 유용한 기술이다. 유연성과 가독성이 높고 플랫폼에 종속적이 아니다. 이런 이유로 현재의 SOA의 대부분이 XML을 이용하여 서비스의 메서드를 정의하고 있다. XML 문서 정의 기술 자체와, XML의 항목을 쉽게 얻어올 수 있는 XPath, XML의 문서 형식을 정의하기 위한 XML Scheme, DTD, XML 문서를 변환하기 위한 XSLT, XML 문서의 내용을 마치 데이타베이스의 SQL처럼 쿼리하기 위한 XQuery등이 현재의 SOA에서 주로 사용되는 XML 관련 기술이다.

이를 프로그램에서 처리하기 위한 자바 관련 기술로는 XML 파싱 기술인 JAXP 등이 있으며 요즘에는 XML 문서와 JAVA 객체를 복잡한 Parsing API를 사용하지 않고 상호 변환해주는 XML to Java 기술이 있으며, J2EE에서는 JAXB가 표준에 포함이 되어 있고 그 외에도 Castor와 같은 비표준 기술이 있다.

  1. 웹서비스

 SOA의 서비스를 구현하기 위해서는 표준화된 인터페이스를 통해서 서비스를 제공해야 한다. 이를 위해 인터페이스 표준화 기술이 필요한데, 주로 언급되는 것이 웹서비스이다. CORBA, RMI 또는 XML/HTTP등과 같은 프로토콜을 사용해도 되지만 웹서비스가 SOA에 있어서 주목을 받는 이유는 XML 기반이기 때문이다. 웹서비스는 다른 프로토콜에 비해서 비교적 쉽고 .NET, JAVA 와 같은 개발 플랫폼에 상관없이 모든 솔루션에서 호환성이 뛰어나기 때문에, SOA의 표준 인터페이스로 많이 사용된다.

 웹서비스 표준은 WS-I을 기본으로 하고 있고, 트렌젝션이나 로깅 관리, 메세징 (Sync ,Async ,Reliable)등의 부가적인 기능을 제공하기 위해서 WS* (Webservice extension)이라는 확장 표준을 정의하고 있다.

웹서비스 적용에 있어서 주의 할 점은 표준을 지원하는 방법이 벤더나 솔루션 마다 다르다는 것이다. 예를 들어 Reliable Meassaging의 경우, Vendor에서 웹서비스를 이용한 Reliable 메세징을 지원한다고 해서, WS-Reliable Messaging의 표준을 따르지는 않는다. Reliable Messaging의 표준이 나온지 얼마 되지 않지만, 각 Vendor는 각자의 고유 방법으로 Reliable Messaging을 지원하다가 표준이 나온 후 표준 기반의 Reliable Messaging을 지원하기 때문에, 이러한 기능들을 어떤 표준이나 구현방법으로 웹서비스에서 지원하는지에 대한 확인이 필요하다. 

  1. CBD (Component Based Development)

 SOA에서 가장 중요한 것 중 하나는 서비스의 정의 방법이다.

SOA의 서비스 정의를 다시 살펴보면, “기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서..” 와 같이 기능을 비즈니스적인 의미를 갖는 컴포넌트로 묶는데 있다.

이 서비스 컴포넌트의 단위를 Fine-grained (작은 단위)로 묶을 것이냐? Coarse-grained(큰 단위)로 묶을 것이냐? 는 SOA에서 중요한 하나의 설계 포인트가 된다.

Fine grained로 서비스를 나눴을 경우에는 각각 서비스의 의미는 정확해지지만 많은 서비스들이 존재하기 때문에 관리가 어려워지는 결과를 낳게 되며, Coarse grained한 서비스는 각개의 서비스기능을 사용하기 위해서 큰 서비스 컴포넌트를 사용해야 하기 때문에, 효율성의 문제가 생긴다.

비즈니스 업무를 효과적으로 서비스 컴포넌트로 추출하기 위해서는 방법론이 필요한데, 현재에는 SOA를 위한 명확한 방법론이 많지 않다. 벤더나 컨설팅 업체마다 SOA 방법론이라는 것을 제공하고는 있지만, 필자의 개인적인 생각으로는 충분하지 않고 추상적이거나 학문적이라는 생각이 든다.

서비스 역시 소프트웨어 관점에서 보면 하나의 소프트웨어 컴포넌트이고, 컴포넌트에 대한 분석 설계를 하기 위한 방법론으로는 대표적으로 CBD (Component Based Development)가 있다. 비단 CBD가 아니더라도 비즈니스 업무를 적절하게 서비스로 맵핑 시키고 그 서비스의 크기(Granuality)를 결정하는 것은 SOA에 있어서 매우 중요한 기술 요소가 된다. 

  1. Integration

 SOA 시스템은 서비스를 조합하여 업무를 구현해야 한다. 이 과정에서 이기종이나 타시스템간의 트렌젝션을 보장해야 하는 경우가 있다. 이런 경우에는 서비스를 묶어서 하나의 트렌젝션으로 구현하거나 또는 시스템들을 묶어서 트렌젝션을 보장하는 하나의 서비스를 구현하는 두가지 방법이 있다.

 전자의 경우 서비스에 트렌젝션을 보장하기 위한 기술이 필요한데, WS*-Transaction과 같은 기술이 있지만, 아직 일부 벤더에서만 제공하고 있다. 웹서비스를 통해서 트렌젝션을 묶을 경우 XML과 HTTP 통신등의 부하로 인해서 트렌젝션 처리에 대한 속도문제가 대두될 수 있다.

후자의 경우에는 시스템간을 통합하는 방법으로 여러가지 방안이 있겠지만 현재 자주 사용되는 아키텍쳐로는 EAI (Enterprise Application Integration)을 통해서 시스템을 통합하는 방법이 있으며, 트렌젝션 관리를 위한 요소 기술로는 JTA,JTS와 같은 트렌젝션 관리와, 이 기종 시스템들을 표준화된 인터페이스로 연계 하기 위한 Connector 아키텍쳐인 J2CA등이 있다. 

  1. ESB

 SOA 시스템의 규모가 커져가고, 오가는 메시지의 포맷이 다양화 되면서, P2P형식의 단순 통합형태의 SOA에서 버스를 중앙에 둔 SOA 시스템이 고안되었고, 이를 구현한 구현체가 ESB(Enterprise Serbvice Bus)이다. ESB의 초기 디자인시의 기능은 들어오는 표준메세지에 대한 변환,라우팅,모니터링등의 기본적인 기능만을 가지고 있었으나, 근 1~2년간 Legacy 시스템을 연동할 수 있는 기능, 메시지 통신 방법을 Async나 Reliable 메세징을 지원하는 기능들이 추가되는등 매우 빠르게 발전하고 있으며, 요즘에서는 SOA 2.0이나 EDA (Event Driven Architecture)라는 개념을 부가하여, 새로운 형태의 ESB 제품을 계속해서 출시되고 있다..

ESB는 SOA 시스템에서 척추와 같이 중요한 기능을 하고 있으며, SOA의 솔루션 중 가장 중요한 솔루션으로 인식되므로 ESB의 발전되는 기능에 대해서 지속적으로 알아둘 필요가 있다. 

  1. BPM

서비스를 조합한 업무의 구현이 복잡해지고, 기업의 환경이 빠르게 변화함에 따라 그 속도에 따른 업무 변화를 요구하므로 신속하게 서비스를 조합하고 변경할 필요성이 생겼다.

이런 요구를 반영하기 위해서 BPM이 SOA에 사용되기 시작했다. SOA에서는 BPM 솔루션을 사용하는데, BPM을 이용해서 업무를 조합하는 것은 솔루션을 사용하면 되지만 좀더 중요한 것은 업무를 어떻게 BPM으로 구현하는 가이다. 

  1. Enterprise Portal

여러 시스템을 SOA로 통합함에 따라 사용자 인터페이스에 대한 통합 역시 필요하게 되는데, 사용자 인터페이스에 대한 통합이 Enterprise Portal이다. 업무 화면에 대한 통합, 권한 통제, Single Sign On등의 문제를 해결할 수 있다.

이미 많은 시스템에서 SOA를 이용 여부와 상관없이 Enterprise Portal을 통해서 업무를 하나의 UI로 통합하고 있다. Enterprise Portal은 비교적 간단하게 프로젝트를 진행할 수 있지만 특히 여러 시스템을 동시에 호출해서 하나의 UI에 보여주는 만큼 성능에 대한 깊은 고려가 필요하다. 

  1. RIA & AJAX

WEB 2.0이 나오면서 화두가 되고 있는것중에 하나는 RIA (Rich Internet Application)이다. 기존의 단순한 HTML 기반의 화면 UI에서 벗어나서 마치 GUI 애플리케이션과 인터페이스를 웹브라우져에서 제공할 수 있다.

현재 RIA 기술로 많이 사용되는 것은 AJAX,Adobe Flex이다. Applet이나 Active X를 이용해도 RIA 를 구현할 수 는 있지만, Applet이나 Active X는 다운로드에 소요되는 시간이 길고, Platform Dependency를 가지고 있기 때문에 AJAX나 Flex가 널리 사용된다.

특히 AJAX나 Flex는 XML 기반으로 메시지를 처리하고 HTTP 프로토콜을 사용하기 때문에 웹서비스를 사용하는 SOA에는 매우 쉽게 적용할 수 있기 때문에, SOA의 RIA 기술로써 유용하게 사용될 수 있다.

이미 국내의 통신사와 보험회사의 프로젝트에서 AJAX 기반의 RIA 클라이언트가 사용되었으며, 업무 시스템 역시 XML/HTTP 인터페이스 기반의 SOA 1단계 레벨로 구현되었다.

기업의 업무가 복잡해지고 빠른UI처리와 여러UI 기능이 필요함에 따라 RIA의 요구가 증가하게 되었고, 특히 XML,HTTP에 친밀한 AJAX나 Flex 기반의 RIA기술을 SOA에 유용하게 적용할 수 있다. 

  1. Governance

Governance는 소프트웨어 프로젝트의 기획에서부터 개발 운영까지의 모든 과정의 통제를 이야기 한다. Governance 역시 SOA 이전부터 등장한 개념이지만, SOA의 등장과 함께 중요시되는 이유는 SOA의 특징중의 하나는 전체 시스템을 하나의 SOA 거대 시스템으로 묶기 때문에 전체 프로젝트를 관리할 수 있는 방법이 필요하기 때문이다.

Governance는 작게는 형상관리, 배포 관리, 프로젝트 관리에서부터 기업의 장기적인 IT전략의 수립 기술의 전도에 까지 전반적인 IT환경에 대한 관리를 필요로 하기 때문에 프로젝트 관리와 전략 수립에 대한 준비가 필요하다. 

지금까지 간단하게나마 SOA 구축에 유용한 몇가지 기술에 대해서 살펴보았다. 필자가 “필요한”이 아니라 “유용한”이라는 단어를 선택한 이유는 SOA를 구축하는데 정해진 기술이나 방법론은 없다. SOA는 아키텍쳐이며 개념일 뿐이고, 이를 효과적으로 구축하는 것은 개발자의 몫이며, 적절하게 필요한 기술을 선택하여 SOA를 구축하는 것이 중요하기 때문이다. 

    SOA가 활성화되지 않는 이유. 

    비단 필자많이 아니라 많은 사람들이 “왜? SOA가 활성화 되지 못할까?”에 대한 많은 의문들을 가지고 있을것이라고 본다.

    SOA의 개념을 도입한 시스템은 1996년대부터 개발되어서 운영되고 있고 그 사례 또한 다양하다. 이런 사례들이 있다면 불가능한 프로젝트가 아닐텐데 왜 SOA가 활성화 되지 못할까? 

    * 경영자들의 인식 부족 

     필자는 가장 큰 원인을 “SOA에 대한 이해 부족”과 “Governance”조직의 부재라고 생각한다.

    국내의 SOA도입을 시도하는 기업의 담당자들과 이야기를 해보면 SOA의 개념이 무엇인지 ESB가 무엇인지를 제대로 이해하고 있는 사람이 드물다. 설사 SOA의 개념을 제대로 이해하고 있는 사람을 만나더라도 실무 개발자일 경우가 많다.

    SOA는 EJB등과 같은 구체성을 가지고 있는 기술이 아니라 개념이며 하나의 전사적인 IT경영전략이다. 그래서 실무진에서부터의 제안이 아니라 경영진의 장기적인 전략과 의지를 가지고 위에서부터 수행해야 하는 문제임에도 불구하고, 국내 경영진들은 SOA에 대한 개념과 의지가 약하다.

    국내의 IT 관련된 책임자들은 빨리 현업의 서비스를 개발해주고 안정적으로 운영할 수 있고 적은 비용을 초점으로 두며 특히나 단기적인 성과에 많이 집착을 하게 된다.

    국내에서 전사포탈(Enterprise Portal)이 기업에서 확산되는 이유는 통합에 대한 이슈를 수용하면서도 가장 짧은 시간내에 가시적인 성과를 보여주기 때문에 SOA에 비해서 높은 확산을 보이고 있는것이라고 생각한다.

    그러나 SOA로 시스템을 구축하면 단기적인 성과를 보기 어렵다. 초반에 SOA에 관련된 인프라를 구축하고, 기존 시스템을 서비스화하기 위해서는 많은 비용이 소요되지만 이러한 초기투자는 초기보다는 장기적인 관점에서 효과를 낼 수 있는것이기 때문에 선뜻 인프라에 대한 투자가 어렵다.

    또한 SOA는 하나의 업무가 아니라 궁극적으로는 전사적인 업무를 하나의 SOA시스템으로 묶는것이기 때문에, 기존의 부서나 프로젝트 단위의 통제 모델이 아니라 전체 시스템과 프로젝트에 대한 전사적인 통제조직이 필요하다.(Governance)

    그러나 국내에서는 부서간의 커뮤니케이션 문제와 부서간의 파워게임(?) 때문에 전사적인 통제 조직이 하부 조직을 관리하기가 어렵다.

    SOA Governance 조직이 있는 경우도 드물거니와, 있다하더라도 그에 충분한 통제 권한과 비용이 지원되는 경우가 드물다. 경영자가 SOA를 도입해서 그만한 효과를 보고자 한다면 그에 상응하는 의지를 가져야 하지 않을까? 

    이런상황에서 어떻게 해야 기업에서SOA를 도입할 수 있을것인가?

    SOA에 도입에 의한 가시적인 성과에 대한 공감을 이끌어 내야 한다.

    필자의 글중에 SOA 도입 방법론에서 설명한 내용중에, SOA의 첫 프로젝트에 대한 중요성을 언급한 내용이 있다. SOA의 첫 프로젝트는 가장 관심을 받는 프로젝트이며 SOA의 필요성과 장점을 필역할 수 있는 프로젝트이여야 한다. 그래서 SOA로 구현한 첫 프로젝트는 그에 대한 성과는 높이 평가되어야 하며 실패하지 말아야 한다.

    성공적인 SOA를 위해서는 첫 프로젝트를 선택하는 것이 매우 중요하며 “기업의 핵심 업무중 가시성이 높고 상대적으로 위험도가 낮은 업무를 선택”해야한다. 

    * 벤더의 SOA

    하나 또 집고 넘어가고 싶은 것이 벤더 들에서 이야기 하는 SOA이다.

    Messaging 시스템을 개발하던 벤더는 SOA 시스템중 메세징에 중점을 둔 ESB를 이야기 하면서 ESB가 SOA의 전부인 것 처럼 이야기하고, BPM이 강점인 벤더는 BPM이 SOA의 전부인 것 처럼 이야기 한다. SOA의 원래 개념보다는 벤더들의 제품과 자사의 장점에 맞춰서 SOA를 제각각 해석이 되고 그것이 전체 SOA인 것 처럼 이야기 한다.

    어떤 벤더들은 SOA를 할려고 하면 Governance도 해야하고 ESB도 있어야 하고 EAI,EP등등 모든 솔루션들을 다 이야기 한다. 틀린말이라고는 하지 않겠지만, 한꺼번에 그런 솔루션들을 도입한다고 해서 SOA화가 될까? 물론 가능은 하겠지만, SOA는 그런 솔루션을 당장에 도입하지 않더라도 단계적으로 차근차근 발전 시키면서 기업 업무에 필요한 솔루션을 선택해서 성숙 시켜나갈 수 있다.

    SOA를 도입하고자하는 기업이 SOA에 대한 이해를 하는데 어려운 점중에 하나가 이러한 벤더들의 SOA를 자체적으로 해석하고 포장한 것 때문이 아닐까?

    SOA를 제대로 수행하기 위해서는 벤더들에게 이끌려가지 말고, SOA를 적절히 이해해서 필요한 솔루션을 벤더들에게서부터 선택할 수 있는 수준의 SOA 자체에 대한 이해가 필요하다.

신고

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

2008년 SOA 전망  (0) 2008.01.10
Next Enterprise  (0) 2007.12.21
What is SOA? How to SOA?  (1) 2007.09.04
SOA & Agile  (0) 2007.09.04
About SOA  (2) 2007.08.20
SOA에 대한 기술적 접근  (2) 2007.08.20