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

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