5장 아키텍쳐 아키텍쳐 - 조대협의 블로그...

5장 아키텍쳐

http://bcho.tistory.com 조대협

아키텍쳐

아키텍쳐란 무엇일까? 소프트웨어 시스템에 대해서 이야기 하다보면, “아키텍쳐가 어떻다”. “최신

아키텍쳐를 적용했다.” 등 아키텍쳐에 대한 언급이 많다. 그렇다면, 소프트웨어 아키텍쳐에 대한

정의는 무엇일까?

http://www.sei.cmu.edu/architecture/start/glossary/community.cfm 를 보면, 수많은 아키텍쳐에 대

한 정의가 있다. 지금부터 설명하고자 하는 아키텍쳐에 대한 정의는 다음과 같다.

“아키텍쳐는 비지니스 요구 사항을 만족하는 시스템을 구축하기 위해서 전체 시스템에 대한 구조

를 정의한 문서로, 시스템을 구성하는 컴포넌트와, 그 컴포넌트간의 관계, 그리고, 컴포넌트가 다

루는 정보(데이타)를 정의한다.”

또한 소프트웨어 아키텍쳐는 현재의 요구사항뿐 아니라 변화되는 비지니스 전략에 대응이 가능하

도록 장기적인 로드맵을 수용하여 확장가능한 형태로 디자인 되어야 하며 가능하면, 구현 및 사

용하고자 하는 조직의 기술 수준, 조직의 규모와 형태 그리고 비지니스의 형태에 맞춰서 설계 되

어야 한다.

아키텍쳐 설계 프로세스

앞에서 아키텍쳐에 대한 정의는 끝냈다. 그렇다면 실제 아키텍쳐는 어떤 형태로 설계해야 할까?

아키텍쳐 설계 방법론은 여러가지가 있으나, 주로 사용되는 프레임웍으로는 Zachman Framework,

TOGAF, Federal Enterprise Architecture등이 있다. 여기서 소개하는 아키텍쳐 설계 프로세스는

Open Group 1에서 만든 TOGAF(The Open Group Architecture Framework) 방법론을 기반으로 하

여 프로세스를 정의하였다. TOGAF에 대한 자세한 설명과 템플릿은 http://www.opengroup.org 나

http://www.togaf.org/ 를 참고하기 바란다.

아키텍쳐 설계의 큰 흐름을 정의하면 다음 그림과 같다.

1 http://www.opengroup.org/

비지니스 아키텍쳐 이해

아키텍쳐는 앞서 정의하였듯이, 비지니스를 성공적으로 이끌기 위해서, 만들어지는 시스템에 대한

설계다. 목적이 “비지니스의 성공”에 있기 때문에, 그 비지니스 자체가 어떤 목표,전략을 가지고

있는지를 이해해야, 목표에 부합하는 아키텍쳐를 설계할 수 있다.

아키텍쳐 설계 원칙 정의 (Architecture Principals)

비지니스 아키텍쳐가 정의되었으면, 시스템을 설계 하기 위한 기술적인 시스템 아키텍쳐를 설계

하기 위한 원칙을 정한다. 품질 속성이나, 기간, 조직 운용론, 기반 기술등 설계의 기본 사상이 되

는 원칙을 정의한다.

시스템 아키텍쳐의 (System Architecture) 설계

설계 원칙이 정해졌으면, 비지니스의 요구 사항을 이 설계 원칙에 따라서 설계한다. 시스템 아키

텍쳐는 크게 아래와 같이 3가지로 나뉘어 정의된다.

① 애플리케이션 아키텍쳐 (Application Architecture) : 개발해야하는 애플리케이션 소프트웨

어에 대한 아키텍쳐를 설계한다. 여기에는 컴포넌트의 정의, 컴포넌트 간의 관계, 특정

기능에 대한 컴포넌트간의 호출 흐름, 그리고 컴포넌트간의 통신을 위한 메세지에 대한

규격 정의를 포함한다.

② 테크니컬 아키텍쳐 (Technical Architecture) : 애플리케이션의 배포 구조를 정의한다. 애플

리케이션을 배포할 하드웨어의 구조와, 애플리케이션 개발에 사용하는 미들웨어 (DBMS,

웹서버등)등의 배포 구조를 함께 정의한다.

③ 데이타 아키텍쳐 (Data Architecture) : 마지막으로, 애플리케이션에서 다루는 정보(데이타)

의 구조와 관계를 정의한다.

이 아키텍쳐의 설계는 기반 지식이 없는 상태에서는 설계가 어렵다. 물론 경험을 가지고 할 수

있겠지만, 참고할 수 있는 레퍼런스가 있다면 실수나 실패를 줄이고, 시간 또한 단축 시킬 수 있

다. 참고자료는 CBD,SOA,EAI와 같은 일반적인 애플리케이션을 개발하기 위해서 패턴화된 아키텍

쳐 스타일을 응용하거나, 유사한 도메인의 CASE STUDY (선행 사례) 기반의 아키텍쳐, 그리고 솔

루션을 사용할 경우, 솔루션 제공사의 컨설팅 서비스를 이용하면, 매우 효율적으로 아키텍쳐 설계

를 할 수 있다.

이 설계 프로세스를 도표화해보면, 다음과 같다.

그러면 이제 부터 각 단계에 대해서 상세하게 설명한다.

1. 비지니스 아키텍쳐의 정의

비지니스 아키텍쳐는 비지니스 목적을 달성하기 위한 시스템 개발을 위해, 비지니스의 목적과 모

델을 이해한다. 이를 위해서 비지니스 모델을 도식화 하고, 기술 조직이 이를 이용하여 비지니스

모델과 목적을 이해한다.

비지니스 아키텍쳐에는 주로 다음과 같은 내용을 포함한다.

① 시스템의 핵심 기능

② 시장 현황과 차별화 요소

③ 비지니스 로드맵과 일정

④ 투자 및 수익 정보

⑤ 시스템을 사용하는 사용자 (End User를 포함, 내부 인원 등)에 대한 도메인 모델

⑥ 프로세스 (주요 기능에 대한 프로세스)

⑦ Business Information (시스템에서 주로 다루는 정보)

추상적인 내용이기 때문에, 비지니스 아키텍쳐에 어떤 내용이 들어가야 할까? 이해가 어려울 수

있겠지만, 쉽게 예를 들면 “사업계획서”, “시스템 개발 제안서” 와 같은 형태의 문서를 생각하면

된다. 해당 비지니스에 대한 목적이 정의되고, 시스템의 목적과 주요 특성, 구축일정, 비용등이 함

께 정의 된다. 이 문서를 읽었을때, 이 비지니스를 수행하는 조직(회사)의 모든 인원들이 그 내용

에 대해서 이해할 수 있어야 한다. 기술쪽 인원이건, 비지니스(영업,마케팅,경영)의 원리와 로직을

이해할 수 있어야 한다.

(1) 서비스 모델의 정의

서비스의 형태를 정의한다. 블로그 서비스를 계획하고 있다면, 블로그 서비스의 비지니스 모델 정

의 예시는 다음과 같다.

“블로그란, 일반적인 사용자가, 자신의 글과 생각을 손쉽게 인터넷에 올릴 수 있는 시스템으로, 1

人 미디어의 성격을 갖는다. 개인이 생산한 블로그내의 컨텐츠는 다른 사람들에게 흥미나 지식을

전달하는 가치를 제공함으로써, 블로그 시스템으로 많은 인터넷 사용자의 유입을 유도할 수 있다.

당 서비스에서는 일반 사용자들에게 블로그 서비스 시스템을 제공하고, 일반 사용자들은 컨텐츠

를 제작함으로써, 이 컨텐츠를 통해서 인터넷 사용자의 유입을 유도하고, 블로그 시스템에 광고를

유치함으로써 수익을 창출한다.”

아주 간략하게 설명하였지만, 사업 제안서를 쓴다고 생각하면 된다.

어떤 시스템인지를 설명하고, 어떤 사용자와 관계를 갖으며, 어떠한 가치를 창출해 내며, 어떻게

수익을 창출하는지를 서술해야 한다.

(2) 시장 현황 분석

비지니스에 대한 정의와 모델 정의가 끝났으면, 해당 비지니스에 대한 시장 현황과 경쟁사등을

분석해야 한다. 상당히 비지니스적인 내용임에도 불구하고 아키텍쳐 문서에 포함 시키는 이유는,

경쟁 제품이 있을 경우 기능이나 성능들의 비교 대상이 될 수 있기 때문이다. 장단점 분석을 통

해서 조금 더 나은 시스템을 설계할 수 있기 때문이다.

시장 규모, 경쟁사 자료들은 가트너 컨설팅 자료를 참고하면 전체 시장 규모나 선도 업체들을 볼

수 있다. 특히 가트너의 magic quadrant report는 해당 비지니스의 선도 업체를 잘 리포팅해준다.

Figure 1 예) 소셜 소프트웨어 벤더의 Gartner Magic quadrent graph

출처 : http://theparallaxview.com/2009/10/gartner-magic-quadrant-dark-horse-closing-fence/

경쟁사의 제품 기능 분석은 경쟁사의 홈페이지를 통해서 찾아볼 수 있고, 매출 규모등은 홈페이

지에 공시된 IR (Investor Report – 상장 회사의 경우 투자자에게 매 분기별로 비지니스 사항을 리

포팅해야 함) 자료를 참고하면 얻을 수 있다.

이렇게 자료를 수집하여, 자社의 시스템에 대한 기능과 타社 시스템에 대한 기능 비교표를 만들

수 있고 이를 통해서, 차이점과 장단점을 비교해서 집중해야할 기능 항목을 정의하는데 참고할

수 있다.

Figure 2 예) 블로그 서비스들 에 대한 비교

출처 : http://blog-services-review.toptenreviews.com/

위의 그림은 선진 경쟁사의 블로그 서비스를 비교표인데, 실제 비지니스 아키텍쳐에서는 자社 에

서 개발하고자하는 블로그 서비스에 대해서 위와 같이 비교를 해야 한다. “타사 들은 기능이나 특

징이 이러이러한데, 우리는 어느 부분은 지원이 되고, 어느 부분은 차별화 요소다.” 라는 메세지가

들어가야 한다.

(3) 비지니스 전략

비지니스 모델과, 시장 현황 그리고 경쟁 제품이 정의 되었으면, 이 상황에서 성공적으로 비지니

스를 수행하기 위한 전략을 정의한다.

주로 차별화 전략으로, 기능적인 차별화, 판매 금액, 서비스, 시장 진입 시간,원가 절감등이 전략

항목의 예가 될 수 는 있다. 포괄적인 방향성을 정의해야 하는데, 비지니스 전략은 소프트웨어 시

스템의 특징과도 연관이 된다.

예를 들어 원가를 절감하려면 오픈소스를 사용해서 원가를 사용하는 방법도 있고, 시장 진입 시

간을 줄이는 서비스를 개발하기 위해서는 클라우드를 이용해서 하드웨어 배포 시간을 줄이는 방

법도 있다. 기능적인 차별화를 위해서는 특정 기술에 집중하는 방법도 있다.

이렇게 아키텍쳐적인 특성은 비지니스 전략에 영향을 받아서 정의되는 경우가 많다.

(4) 주요 기능 정의

다음으로, 시스템에 대한 주요 기능을 정의한다. 비지니스 관점에서의 기능이 되기 때문에, 세세

한 기능 보다는 10~20 개정도의 큰 기능으로 정의하는 것이 좋다. 상세한 기능 정의는 시스템 아

키텍쳐에서 정의 한다. Actor 와 기능 중심의 Use Case Diagram과 같은 도표를 사용하는 것도 유

용하다.

주요 기능을 정의할때, 꼭 들어가야 하는 것중의 하나는 이 시스템을 사용하는 “사용자” 와 “시스

템”간의 상호작용(Interaction)을 정의해야 한다.

(5) 비지니스 로드맵

비지니스 로드맵은 해당 비지니스의 장기적인 일정을 서술한다.

출시 일정, 시장 공략 계획등을 포함한다.

비지니스 로드맵은 시스템의 개발 및 출시 일정과도 연관이 된다. 블로그나 SNS와 같은 순수 소

프트웨어 서비스일 경우에는 비교적 개발 일정 조정이 가능한 편이지만, 스마트폰이나 TV와 연동

되는 소프트웨어나 공장 자동화 같은 소프트웨어의 경우에는 제조부분과 연동이 되어 있기 때문

에 마케팅, 광고, 물류등의 다른 비지니스 유닛과 연결이 된다. 그래서 개발 일정이 지연될 경우

큰 손해를 입을 수 있다. 이런 이유로 비지니스 로드맵을 정확하게 알아야 개발 일정을 조정할

수 있고, 필요에 따라 기능을 조정하거나 단계적인 출시 일정등을 고려할 수 있다.

다음은 블로그 시스템에 대한 로드맵 예제이다.

Figure 3 블로그 시스템 비지니스 로드맵 예시

아주 간단하게 표현하였지만, 실제 로드맵 작성시에는 반드시 제품의 출시 일정과 버전별 릴리즈

계획등이 정교하게 포함되어야 한다.

지금까지 상당히 복잡한 내용을 설명하였다. 비지니스 아키텍쳐는 , 기술 아키텍쳐를 비지니스 목

적에 부합시키기 위해서, 비지니스를 이해하는 것을 목적으로 작성하는 문서이다. 직접 기술 아키

텍트가 이런 내용을 작성하기는 어렵다. 아키텍쳐 설계가 들어간다는 것은, 이미 위에서 서술한

대부분의 모델이 어느정도 분석이 끝났다는 것이다. 적어도 어떤 비지니스를 할것이며, 시장 상황

등은 정의가 되었을 것이며, 비지니스 전략 역시 마케팅이나 경영쪽에서 작성해야 하는 내용이니

크게 걱정을 할 필요는 없다.

이미 작성된 내용을 다시 기술팀 입장에서 재 정의하고 문서를 작성함으로써 비지니스를 이해하

한다.

2. 아키텍쳐 설계 원칙 (Architecture Principal) 정의

비지니스를 분석했으면, 설계 해야 하는 시스템의 설계 원칙 (Architecture Principal)을 정한다. 이

는 비지니스의 요구 사항에 의해서 원칙이 세워진다.

예를 들어 “경영 악화에 의해서 IT에 투자를 많이 하지 않는다”면, Outsourcing 등을 고려할 수

있고, 아키텍쳐 역시 외주 개발팀에 의해서 분산 개발이 용이한 아키텍쳐 스타일이 되어야 한다.

또는 “SNS에서의 사용자의 반응을 실시간으로 분석해서 제품 마케팅에 활용한다” 와 같은 비지니

스 요구 사항이 있을 경우에는 “SNS의 데이타를 실시간으로 분석할 수 있는 빅데이타 기능을 아

키텍쳐에 반영해야 한다.”

이러한 설계 원칙을 Architecture Principal이라고 하고, 아키텍쳐 디자인의 기본 원칙이 된다.

Architecture Principal은 보통 7~15개 정도를 정의하는 것이 적절하다. 요구사항 변경이나, 기술적

인 난이도, 조직의 숙련도등 많은 요인에 의해서 아키텍쳐를 변경해야할 상황이 발생하는데, 이때,

판단의 기준이 되는 것이 Architecture Principal이다.

다음은 블로그 시스템 구축을 위한 Architecture Principal의 예이다.

3. 시스템 아키텍쳐의 설계

비지니스 모델의 파악이 끝나고, 아키텍쳐의 기본 설계 원칙이 정해졌으면 시스템 아키텍쳐 설계

에 들어간다. 시스템 아키텍쳐는 비지니스 아키텍쳐와, 아키텍쳐 설계 원칙을 기본으로 해서 설계

를 하고, 아키텍쳐 스타일이나 CASE STUDY 등의 레퍼런스 자료를 이용해서 설계를 한다.

(1) 애플리케이션 아키텍쳐

애플리케이션 아키텍쳐는 직접 개발하는 소프트웨어 애플리케이션에 대한 아키텍쳐 구조이다.

애플리케이션은 크게 4가지 요소로 표한할 수 있다.

애플리케이션을 구성하는 컴포넌트, 컴포넌트의 상호 관계, 특정 기능을 수행하기 위한 컴포넌트

간의 호출 순서 그리고 각 컴포넌트간의 호출을 위한 통신 방식 즉 인터페이스에 대한 패턴과 프

로토콜로 이루어진다.

이 4가지 구성 요소를 아키텍쳐 문서로 분류해보면, 애플리케이션 아키텍쳐의 구조는 컴포넌트들

의 구성과, 각 컴포넌트들의 상호 연관 관계를 표현하는 정적인 아키텍쳐 (Static Architecture)와,

특정 기능에 대해서, 컴포넌트 간의 호출 흐름을 표현하는 동적인 아키텍쳐 (Dynamic

Architecture)와 컴포넌트간의 통신 규격을 정의하는 인터페이스 정의서 (Interface Defintion)로 정

의 된다.

< 그림. Application Architecture 구성 요소 >

이제 부터 각 구성 요소를 표현하는 아키텍쳐 다이어그램들에 대해서 설명한다.

Static Architecture

컴포넌트 구성의 표현

시스템을 구성하는 컴포넌트들을 표현한다. 계층별로(Layered) 표현하며, 각 컴포넌트에 대한 설명

을 간략하게 서술한다. 컴포넌트를 break down하여 보통 Level0~Leve3까지 설계하고, 더 상세한

부분은 각 컴포넌트의 상세 설계 문서에서 기술한다.

Level 0의 경우에는 일반적인 계층 (Layer or Tier)를 정의한다. 주로, SOA(Service Oriendted

Architecture),CBD, 3-Tier Client Server와 같은 Architecture Style에 영향을 많이 받는다. 이러한

Architecture Style은 이미 정해진 계층 구조를 가지고 있기 때문에, 설계 하고자 하는 아키텍쳐가

이러한 Reference Architecture에 영향을 받았다면 상당히 유사한 구조의 계층 구조가 나오게 된

다.

아래는 요즘 일반적으로 사용되는 OPEN API나 SOA 기반의 아키텍쳐에 대한 계층 구조와 각 컴

포넌트의 기능을 Level 0 기준으로 표현하면 다음과 같다.

Figure 4. Level 0 Component Diagram

Figure 5. Level 0 Component Description

Level 0가 정해졌으면, 각 블록을 Break down해서 Level1,2,3 단계로 아래 그림과 같이 정의해나간

다. 마찬가지로, 각 Level별로 정의된 컴포넌트에 대해서도 Component Description을 서술한다.

이 단계까지 디자인을 하면, 전체 시스템이 어떤 구조(Structure)를 가지는지 정의가 된다

특히 블록들은 Level1이나 2정도에서 각 개발 UNIT으로 분리될 수 가 있다. 예를 들어 Business

Compoent Layer내에, Compoent A,B,C는 A팀이 개발, D,E,F는 B팀이 개발하고 UI Layer에서

Mobile은 C팀이 개발, WEB UI는 D팀이 개발하는 식으로 나뉘어 질 수 있다.

이는 향후에 팀 모델링과 TASK 기반의 개발 프로세스 관리등과도 연계성을 가지게 된다. 개발

TASK를 상위 레벨 (Level 1정도) 블록으로 Categorize(분류)하여 관리하면 시스템에 대한 개발 진

척도를 가시화하여 관리할 수 있다.

또 다른 예를 보자, 아래 그림은 통신사의 서비스 Delivery 플랫폼의 상위 아키텍쳐이다. 앞서 설

명한 계층화된 컴포넌트 다이어그램의 구조로 서술이 되어 있다. 각 컴포넌트들은 기능적인면으

로 서술이 되어 있다. 약간 특이한 점은 맨 아래, Consumer,Provider, Network & Gateway Layer와

같은 내부 소프트웨어 컴포넌트가 아닌 부분이 서술되어 있는데, 이렇게 시스템 아키텍쳐 설명에

필요하다면 외부 시스템에 대한 연계 구조를 함께 포함하는 것도 구조 설명에 도움이 된다.

Figure 6 통신사의 통합 서비스 Delivery 플랫폼 상위 아키텍쳐

컴포넌트간의 관계 표현

컴포넌트 구성을 정의했으면, 이 컴포넌트들이 상호 유기적으로 어떤 관계를 갖는지를 정의해야

한다. 이 관계는 컴포넌트간의 호출 구조를 정의하면 된다. 함수의 호출 관계를 연상하면 이해가

쉽게 될 것이다. 아래는 일반적인 웹 시스템에 대한 컴포넌트간의 관계를 표현한 다이어그램이다.

Figure 7 컴포넌트간 관계 표시도

이렇게 Static Architecture를 디자인할때, 흔히 혼동 되는 사항이 컴포넌트의 명명과 분리를 어떻

게 할것인가인데, 컴포넌트 명을 “컨텐츠 관리”,”사용자 관리”,”학습 시스템”,”매출 관리 시스템” 과

같은 비지니스 단위로 분리할 수 도 있고, “Transaction Processing”, “Load Balancing”;과 같이 기술

적인 단위로 분리할 수 도 있다. 디자인시 여기서 많은 혼동을 유발하는데, 가이드는 상위 계층의

분류법은 비지니스 위주를 사용하고, 하위 디테일로 갈 수 록, 기술적인 단위로 분리하는 것이 좋

다.

Dynamic Architecture

컴포넌트의 종류와 구조가 파악되었으면, 이제 부터 주요 시나리오에 대해서, 각 시나리오를 처리

하기 위한 흐름을 표시한다. 컴포넌트 관계도를 이용하여, 각 시나리오에 대한 호출 흐름에만 번

호를 적어서 순차적으로 설명할 수 도 있고, 시나리오의 특성상 낮은 레벨의 컴포넌트가 필요하

거나, 기타 기술적인 사항이 있으면 추가로 표시하도록 한다. 다음은 블로깅 시스템에서 “첨부 파

일을 업로드 하는 시나리오” 대한 Dynamic Architecture 예제이다.

애플리케이션 아키텍쳐는 소프트웨어 컴퍼넌트간의 구조를 표현하지만, 경우에 따라서

설명을 돕기 위해서는 하드웨어나 네트워크에 대한 구성이나, 소프트웨어 솔루션을 참고

사항으로 표현할 수 있다.

위의 그림에도, L4 스위치등이 표현되어 있고, 각 컴포넌트의 구성 미들웨어들이 표현되

어 있다. 이는 시스템을 구성하는 하드웨어 및 솔루션 컴포넌트를 표현하여 이들 특성에

따른 아키텍쳐 흐름을 표현하기 위함이다.

Detail Architecture

Static Architecture와 Dynamic Architecture를 정의하였으면, 전체 시스템의 구조와 흐름을 표현한

다. 큰 그림 설명을 통해서 전체 시스템에 대략적인 설명은 하였고 기능별 상세 디자인등은 별도

의 디자인 문서에서 진행한다.

여기서 고려해야할 사항은, 아키텍쳐는 전체 시스템의 큰 그림의 설계이고, 각 컴포넌트 개발팀은

컴포넌트에 대한 상세 설계와 구현 및 테스트를 담당한다. 그래서 아키텍쳐에 정의된 설계 사상

이 개발팀에까지 연속적으로 잘 전달되는 것이 필요한데, 아키텍쳐 설계상의 특징이나 사상을 담

은 설계의 경우에는 별도로 상세 디자인을 포함한 “Detail Architecture”라는 것을 작성하여, 문서

에 포함하도록 한다.

다음은 블로그에 업로드된 동영상을 병렬로 인코딩 하는 시스템에 대한 상세 아키텍쳐이다. 예제

로 사용하는 용도라서 한장 정도만 첨부하였지만, 상세 디자인 수준으로 자세하게 서술해야 한다.

Interface Definition (인터페이스 정의서)

인터페이스 정의서에서는 각 컴포넌트들이 통신하는 방법을 정의하며, Protocol, Message format

그리고, Message Exchange Pattern (MEP) 3가지 항목으로 구성된다.

Protocol

Protocol은 통신 프로토콜이다, JSON/HTTP 기반의 REST, SOAP 기반의 웹서비스, 구글의

Protocol Buffer와 같은 통신 프로토콜이 해당한다.

Message Format

다음은 Message Format으로, Protocol에 실려서 전송되는 메세지에 대한 포맷(스키마)를 정의한

다. SOAP 기반의 웹서비스에서는 WSDL등이 해당하며, 이해하기 쉬운 것으로는 OPEN API의 명

세서등이 있다. 여기서 정의 하는 Message Format은 큰틀의 아키텍쳐 부분에 대한 설계이지

개별 인터페이스에 대해 각각 Message Format을 정의하는 것이 아니다.

메세지의 전체적인 구조를 기술하는 것으로, 메세지의 헤더, 전체 구조, 에러 코드등을 정의한

다.

메세지 구조 설계시, 구글이나 Amazon과 같이 OPEN API를 제공하는 해외 유수의 서비스나, 솔

루션들의 API 명세 문서를 참고하면 많은 도움이 된다.

예) Amazon Web Service 클라우드 서비스의 Simple Storage Service (S3)의 OPEN API 명세서

http://docs.amazonwebservices.com/AmazonS3/2006-03-01/API/RESTBucketGET.html

Message format에는 request와 response 양쪽을 모두 정의해야 하며, 특히 response에는 정상

적인 응답뿐만 아니라 예외 사항(에러)에 대한 Message format을 포함하여 정의해야 하며, 특

히 장애에 대해서는 에러코드를 정의 해야 한다.

Message Exchange Pattern

마지막으로는 Message Exchange Pattern (MEP)인데, 메세지를 호출하는 방법을 정의한다. 우리

가 일반적 예로, 프로그래밍에서 사용하는 호출 형태는 Synchronous 형태로 request가 가면

return이 올때 까지 기다리는 호출 패턴이다. 윈도우즈나, 모바일 앱에서 버튼을 누를 때 특정

함수를 호출하게 하는 것은 Event Handling 패턴이다.

일반적으로 프로그래밍에서 사용하는 API에 대한 함수 호출 패턴이 MEP이다.

대부분의 인터페이스는 동기식 (Synchronous) 방식을 사용하는데, 이 방식은 필수적으로 사용되

고 난이도가 있는 부분은, 비동기식 (Asynchronous) 호출 패턴으로, Message Queue를 이용한

메세징 패턴이다. 동기식의 경우 호출 후, 성공 실패 여부를 바로 리턴받기 때문에 그리 구현이

어렵지 않지만, 비동기식의 경우 호출 한 후, 비동기적으로 서버에서 처리한 후에 리턴을 해야

하는데, 호출한 클라이언트가 응답을 대기하지 않기 때문에 에러 처리가 쉽지 않다. 특히 에러

가 났을때에 대한 처리 방식 – “재시도, 무시, 관리자에게 알림” 등의 에러 처리 정책을 정의해

야 하는데, 이러한 에러 처리를 하는 패턴을 “Error Hospital”이라고 한다. (에러가 나면 병원에가

서 치료를 하고 온다는 의미로). 이 “Error Hospital”의 구현은 난이도가 높고, 시간이 많이 걸리

기 때문에 특별히 신경을 써야 하는 부분이기도 하며, 비동기식의 경우 클라이언트와 서버의

관계가 M:N의 multiplicity를 가지기 때문에 복잡도가 비교적 매우 높다.

인터페이스 관점에서는 RPC 형태의 함수 호출만 생각하면 안된다. 컴포넌트간을 연계하는 방법

은 RPC 뿐만 아니라, FTP를 사용한 FILE 인터페이스 방법, DBMS의 테이블을 복사하는 테이블

인터페이스 방식등 여러 가지 방식이 있기 때문에, 인터페이스 아키텍쳐 정의에 의해서 유연적

으로 설계를 해야한다.

Message Queue를 이용하여, 비동기 호출 방식의 MEP 구현 방식이다. 이런 구현 방식은

Message Queue 솔루션들의 문서를 보면, 아키텍쳐 스타일을 참고할 수 있는데, 아래 그림은

Message Queue 미들웨어인, RabbitMQ에서 소개한 MEP 패턴이다.

출처 : http://www.rabbitmq.com/getstarted.html

MEP 만 가지고도 책한권이 나올만큼 많은 분량이기 때문에, 여기서는 상세한 설명을 하지 않는

다. MEP에 대한 상세한 설계는 미들웨어나, EAI 아키텍쳐, OPEN API 아키텍쳐 스타일등을 참고하

고, 서적으로는 “Enterprise Integration Patterns”2를 참고하면 조금 더 다양한 패턴을 참고할 수 있

다.

(2) 테크니컬 아키텍쳐

테크니컬 아키텍쳐에는 개발한 애플리케이션을 배포할 솔루션(RDBMS, WAS등의 미들웨어)과 하

드웨어에 대한 구조를 정의한다.

시스템이 동작하기 위해서는 애플리케이션 소프트웨어 뿐만 아니라 소프트웨어 애플리케이션이

동작하기 위한 기본적인 미들웨어 (DBMS,웹서버 등)와 이 미들웨어와 애플리케이션을 호스팅할

하드웨어로 이루어진다.

테크니컬 아키텍쳐에서는 애플리케이션에서 하드웨어까지 연관 구조를 정의한다.

2 Addison Wesley : Gregor Hohpe , Bobby Woolf, ISBN-10: 0321200683

Hardware deployment Architecture

하드웨어의 배포 구조와 하드웨어를 아키텍쳐를 구성하는 각각의 컴포넌트, 서버 RACK, 서버, 네

트워크 장비, 스토리지에 대한 디자인을 정의한다. 각 서버에 대한 특성등은 다른 하드웨어와 인

프라를 다루는 챕터에서 구체적으로 설명하도록 한다.

서버 디자인 아키텍쳐

개별 하드웨어 서버의 디자인을 정의한다. 서버 하드웨어에서 정의해야 하는 내용은

CPU의 클럭 속도, Hyper Threading 등의 CPU 관련 기술들을 선택하여 설계한다.

네트워크 구성 부분에서는 NIC (network interface card)에 대한 디자인을 고려하는데, 네

트워크는 단순하게 하나의 NIC를 구성하는 것이 아니라 용도에 따라 관리용 인터페이스,

외부 서비스용, 내부 통신용, 스토리지 네트워크 연결등을 애플리케이션의 특성에 맞도록

분리해서 배포한다. 또한 성능이나 안정성등을 고려하여 bonding (두개의 NIC를 논리적

으로 하나로 묶는 방법)등을 고려해야 한다.

메모리 부분에 있어서도, 서버의 처리능력에 맞게 알맞은 용량을 선정해야 한다. 예를

들어 하나의 WAS가 2 core에서 가장 최적의 성능이 나온다고 가정하였을때, 서버가

12core로 구성되어 있다면, 32 bit JVM에서 작동하는 WAS의 경우 최적의 메모리 사이즈

는 1.5G~2G정도가 된다. 12core이기 때문에, 2 core를 OS의 기본 동작에 사용한다고 가

정하면, 나머지 10 core가 WAS에 사용되기 때문에 총 5개의 WAS 인스턴스를 기동할 수

있고, 필요 메모리양은 5개의 WAS 인스턴스가 각 2GB의 메모리를 소요한다면, 10 GB의

메모리가 필요하며, OS가 기본적으로 사용하는 메모리를 2GB로 가정하면 총 12GB가 필

요하다.

애플리케이션의 형태를 고려하여 로컬 디스크를 설계해야 하는데, TP성의 처리만 할 경

우 많은 디스크 용량을 필요로 하지 않기 때문에 작은 수의 디스크만을 사용하면 되지만,

만약 많은 데이타를 저장하는 RDBMS같은 솔루션의 경우 많은 디스크를 사용해야 하기

때문에 서버가 충분한 물리적인 공간을 가지고 있어야 하며, 성능과 안정성 (이중화)를

고려하여 RAID 구성을 결정해야 한다.

이러한 내용들을 고려하여, 내부에 충분한 공간 확보를 해야 하는데, NIC를 꼽을 PCI 슬

롯, 디스크를 꼽을 수 있는 공간등을 고려해야 하며,서버 케이스의 크기를 결정해야 한다.

(1U,2U,4U) 이러한 모든 장비에 전력을 제공할 수 있는 power supply 에 대한 용량도 함

께 설계해야 한다.

아울러 서버의 집적도등을 고려하여 서버의 타입 (서버형,랙마운트,블레이드)등을 결정해

야 한다.

네트워크 디자인 아키텍쳐

서버간의 네트워크 디자인을 정의한다.

외부 네트워크와 연결하기 위한 라우터

네트워크의 백본이 되는 L2 스위치

그리고 로드밸런싱과, 기타 애플리케이션의 특성에 따른 네트워크 서비스를 제공하는

L4,L7 스위치

보안을 위한 침입 탐지 시스템 IPS와 방화벽

내부 IP를 사용하기 위한 NAT (Network Address Translation) 장비

그리고 LAN (Local Area Network)에 대한 구성등을 정의한다.

스토리지 디자인 아키텍쳐

외부 스토리지 (디스크)에 대한 아키텍쳐를 정의한다.

NFS (Network File System)과 같은 공유 파일 시스템, SAN (Storage Area Network)과 같은

스토리지 타입을 정의하고

스토리지를 관리하는 Controller, 어떤 물리적인 디스크를 사용할것인지 (SAS,SATA, DISK

회전속도)에 대한 디자인과 RAID 구성등을 정의한다.

그리고 스토리지를 연결하는 네트워크 구성등에 대해서 정의한다.

랙 디자인 아키텍쳐

시스템의 규모가 RACK (서버를 집적해서 데이타 센터에 배치 시키는 일종의 서버용 케이스)에 서

버를 배치하는 구성을 디자인 한다. 랙의 위치에 따른 케이블링의 위치, 랙의 전력 용량, 랙을 컨

트롤 하기 위한 KVM (키보드와 화면이 달려있는 콘솔로, 여러대의 서버를 스위칭하며, 서버를 컨

트롤 할 수 있다.), 필요에 따라 UPS(무정전 전원 공급 장치)등의 설계를 포함해서 고려한다.

특히 대규모 숫자의 랙을 설계할 경우에는 서버들의 배치는 랙의 전력 용량과 함께, 발열량을 고

려하여 장비를 배치해야 한다.

[ HP RACK 디자인 ]

출처 : http://www.hp.com/sbso/productivity/howto/rack-server/plan-it.html

Solution deployment Architecture

솔루션은 애플리케이션이 동작하기 위한 미들웨어를 정의하며, Solution deployment Architecture

는 이에 대한 배포 구조를 정의한다.

솔루션 아키텍쳐는 각 솔루션의 특성을 많이 반영된다. 특히 클러스터링 기능이나 HA와 같은 이

중화 기능을 제공하는 경우에는 조금 더 많은 특성을 요구로 한다. 클러스터링을 위한 전용 네트

워크 인터페이스나, HA의 경우 상태 정보를 공유하기 위한 공유 디스크를 사용하는 것

RDBMS의 경우 트렌젝션 로그를 빠른 디스크에 분리해서 배치 하는 등의 케이스가 있다. 이렇게

솔루션들은 각 솔루션 자체의 배포 구조에 대한 것들에 대한 설계 뿐만 아니라 하드웨어에 대한

요구 사항이나 구성들에 대한 권고 사항을 가지고 있기 때문에 solution deployment architecture

는 solution의 배포 구조뿐만 아니라, 하드웨어 설계 아키텍쳐에까지 영향을 준다.

(3) 데이타 아키텍쳐

데이타 아키텍쳐는 시스템에서 저장하고 다루는 정보에 대한 정의와 관리 구조에 대한 아키텍쳐

이다. 데이타 아키텍쳐에서 표현해야 하는 주요 내용들은 다음과 같다.

데이타 모델링

데이타 모델링은 시스템에서 다루는 정보를 구성하는 개체와 그 개체들의 관계를 정의한다. 쉽게

정의하면 DB 설계에 사용하는 ERD (Entity Relationship Diagram)을 생각하면 가장 명확하다. 이

단계에서는 각 Entity를 판별하고, 각 Entity에 대한 관계를 정의한다.

데이타 모델링은 두가지 단계로 이루어져야 한다.

Conceptual Modeling

시스템을 이루는 정보를 표현하는 개체와, 개체간의 관계와 multiplicity 정의한다. 여기에는 개

체들이 가지고 있는 구체적인 속성 (Attribue)이나 Key 등은 정의하지 않는다.

Logical Modeling

Conceptual Modeling에서 추가하여, 각 Entity에 Attribute를 표현하고, 아울러 Primary Key와

ForeignKey를 정의한다.

Implementation Model

Logical Model을 물리적인 테이블로 설계한다. 각 Attribute에 대해서 Table Column으로 맵핑하

고, Index 정의와, 각 Column에 대한 데이타 타입을 정의한다. Data Architecture 설계에서는

Implementation Model까지 설계하지 않고, Logical Model까지만 설계 한다. Implementation

Model은 상세 설계 단계에서 수행한다. Implementation Model은 구현에 사용될 솔루션의 특성

에 맞게 데이타를 디자인하며, 솔루션에 추가 기능 (Stored Procedure), XML Document 지원 등

의 기능을 반영하여 설계한다.

데이타 저장소

Data Architecture에서 정의하는 데이타는 RDBMS에 들어가는 데이타 뿐만 아니라, 파일,메타 정

보등의 모든 형태의 데이타 아키텍쳐를 정의한다. 그래서 RDBMS에 대한 설계뿐만 아니라, 데이

타의 특성에 맞는 데이타 저장소를 선택해야 한다.

대표적인 데이타 저장소 타입으로는 LDAP,RDBMS,FILE SYSTEM,NO SQL,ISAM 있으며, 데이타 모델

의 Logical Model에서 정의한 개체들을 각 저장소 타입에 맞게 재 배치해야 한다. 어디에 데이타

를 저장할지를 결정한 후에, 각 데이타 저장소 특성에 맞게 상세 설계 단계에서 Implementation

Model을 설계 한다.

애플리케이션 컴포넌트와 맵핑

데이타의 종류와 각 속성이 파악되고, 저장소가 결정 되었으면, 각 데이타를 사용하는 애플리케이

션 컴포넌트와의 관계를 정의한다. 되도록이면, 각 데이타 개체가 단일 애플리케이션에 의해서 다

뤄지도록 설계를 하는 것이 좋다.

동일한 데이타 개체를 여러개의 애플리케이션에서 동시 업데이트를 할때는 일관성의 문제가 발생

할 수 있다. 트렌젝션 보장 능력이 있는 RDBMS의 경우에는 큰 문제가 없을 수 있겠으나, 파일

시스템이나 NOSQL과 같이 트렌젝션에 대한 개념이 없는 저장소의 경우 데이타 불 일치를 유발

할 수 있다.

그리고 가능하다면, 하나의 기능을 구현하는데, 데이타가 같은 저장소에 있는 것이 유리하다. 예

를 들어 사용자 정보를 LDAP과 RDBMS에 나눠서 저장한다면, “사용자 생성”과 같은 기능은 하나

의 트렌젝션에서 LDAP과 RDBMS 양쪽을 동시에 업데이트 해야 하며, 두 개의 데이타 저장소를

하나의 트렌젝션으로 묶는 분산 트렌젝션 (Distributed Transaction)의 개념으로 구현을 해야 한다.

이러한 저장소들이 분산 트렌젝션 표준 (XA)등을 지원한다면 일관성 보장이 다소 쉽겠지만,

NoSQL과 같이 분산 트렌젝션을 지원하지 않는 시스템이 트렌젝션에 참여하게 되면, 애플리케이

션 계층에서 트렌젝션에 대한 보장 로직을 별도로 구현해야 하기 때문이다.

데이타 관리 프로세스

어떤 데이타를 어디에 저장하고, 누가 사용할지가 정해졌으면, 이 데이타에 대한 관리 정책을 정

해야 한다.

Security 데이타에 대한 암호화, 데이타 베이스 시스템으로의 접근 통제를 위한 인증과 인가에

대한 정책을 정의한다.

Life cycle 데이타의 생성에서 부터 폐기까지의 데이타 생명 주기를 정의한다. 특히 이 영역에서

는 데이타에 대한 백업 정책등이 정의되어야 한다.

Sharing & Integration 애플리케이션 시스템 간의 데이타를 공유하거나, 서로 통합을 위해서

데이타를 전송하기 위한 아키텍쳐를 정의한다. EAI나 Date Integration 관점에 대한 부분이나

MDM (Master Data Management) 부분이 이 영역에 해당한다.

Analysis & reporting 시스템에 축적된 데이타를 기반으로 분석과 리포팅 서비스를 제공할 수

있는 아키텍쳐를 정의한다. OLAP이나 BI같은 데이타 분석 리포팅이 이 영역에 해당한다.

4. Architecture Decision Process

Architecture Decision Process (이하 AD)는 아키텍쳐 설계 과정에서, 문제를 해결하기 위해서 다양

한 아키텍쳐 옵션이 존재 하는 경우 아키텍쳐에 따라서 비지니스에 영향을 주는 일정, 기간, 비용

에 영향을 주거나, 구현에서 기술적인 이유나 일정, 조직의 기술 보유 능력 또는 회사의 전략에

따라서 아키텍쳐의 선택이 필요할 경우, 아키텍쳐 옵션에 대한 의사결정을 하는 프로세스 이다.

일반적으로 아키텍쳐는 해당 분야의 담당 아키텍트가 결정하는 구조를 가지지만, 그에 대한 파급

효과가 클 경우 AD Process를 사용하는데, AD Process는 아키텍트의 단독적인 결정이 아니라 아

키텍쳐 의사 결정을 위한 Architecture Committee 라는 조직을 운영하여, 이 Committee에서 의사

결정을 한다. Committee는 아키텍트등의 기술자로만 이루어진 것이 아니라 필요에 따라 경영진,

프로젝트 관리자(PM)나 관리 조직(PMO), 실무 개발 PM 들로 구성된다.

AD Process를 사용하는 이유는 전체 조직적인 관점 (기술,비지니스,프로젝트 관리)에서 특정 아키

텍쳐의 장단점을 기반으로 아키텍쳐를 결정하여 향후 발생 가능한 위험을 최소화 하고 위험 관리

대책을 마련하기 위함이다.

AD Process 정의

AD Process는 일반적으로 다음과 같은 절차를 따른다

① [NEW] 실무팀 (개발,영업,QA,운영)이 요건 만족을 위해서 다른팀과 회의를 통해서 요건

변경의 필요성이 있음을 파악하고, 변경 방법 옵션을 정의하고 각각의 장단점을 AD 템플

릿 포맷에 맞게 작성 한다.

② [ASSIGNED] 아키텍쳐팀이 해당 AD을 검토후 판단하여, 결정이 가능한 수준이면 결정을

한후, 실무팀에 결정 사항을 통보한다.

③ [ESCALATED] 아키텍쳐팀의 결정에 실무팀이 수락이 안되거나 또는 해당 결정 사항이 시

스템 개발이나 비지니스에 지대한 영향이 있다고 판단되었을 때는 Architecture

Committee* 로 해당 AD를 escalation한다.

④ [Resolved] AD에 대해서 하나의 옵션으로 결정이 난후에, 아키텍쳐적인 파급효과등을 파

악하여 검토한 후, 실무팀에 결정 사항을 통보한다.

AD Template

AD Process를 진행하기 위해서는 AD이 필요한 아키텍쳐 Option에 대한 설명과 장단점, 그리고

AD가 필요한 이유를 서술해야 한다. 이는 문서로 작성되어 Commiitee등에서 의사 결정의 기본

자료로 활용되며, Commiitee는 기술 인력 뿐만 아니라 비지니스와 관리인력이 참여하는 만큼 기

술 인력 이외의 사람들도 이해할 수 있는 수준으로 작성되어야 하며, 이 모든 내용을 간략하게 1

장에 작성해야 한다. 상세한 설명이 필요한 경우에는 별첨 문서를 따로 작성하여 첨부하도록 한

다.

아래는 이러한 내용을 담은 AD Template 예제이다.

AD Template에 들어가는 각 항목에 대한 내용은 다음과 같다.

• Description & Motivation 해당 문제에 대한 간략한 정의와 의사 결정이 필요한 이유

• Assumption 본 아키텍쳐에 대한 가정 사항

• Consideration 본 아키텍쳐에 대한 주요 고려 사항

• Option별 장단점 옵션별 장단점을 기술 및 비지니스 관점에서 정의

• Decision 아키텍쳐 옵션에 대한 선택이 종료된 경우, 어느 옵션으로 선택했는지를 명시

• Implication 본 의사 결정으로 미치는 영향 (기술 및 비지니스-기간 연장,솔루션 구매,매

출 감소 등)

아키텍트의 종류와 역할

이러한 아키텍쳐를 설계 하는 사람은 아키텍트(Architect)라고 한다. 이 아키텍트는 아키텍쳐 설계

프로세스에서 정의한 각 아키텍쳐에 대해서 아키텍쳐를 설계하는 역할들이 정의된다. 계층 구조

를 제외하면 아키텍쳐는 5가지로 분리된다. Business Architecture, Application Architecture,

Solution Architecture, Data Architecture로 분리되며, 아키텍트 역시 이 5개 분야에 걸쳐서 총 5개

의 역할로 정의된다.

Enterprise Architect (EA) Business Architecture를 포함한 전체 아키텍쳐 설계에 대한 책임을 진

다. 비지니스 이해를 바탕으로 전체 아키텍쳐에 대한 큰 설계를 담당하며, 비지니스에 대한 이해

를 바탕으로 장기적인 IT 전략 수립을 담당한다. EA의 특징중의 하나는, EA의 경우 단일 프로젝트

뿐만 아니라, 해당 회사의 앞으로의 비지니스 전략에 맞춰서 향후 모든 프로젝트에 대한 아키텍

쳐에 대한 책임을 진다. 또한 SA,AA,TA,DA에 대한 통제 권한을 가지고 아키텍트 팀을 운용한다.

가끔 CIO와 혼동하는 경우가 있는데, CIO는 회사 내부의 IT 전략을 수립하고, IT 포트폴리오를 정

의하고 수행한다는 관점에서 EA와 유사한 면이 있으나, 기술적인 면에서는 CIO와 EA의 부분이

겹칠 수 있으나 경영적인 측면에서는 다르다. CIO는 결정적으로 예산 집행권과 인사권을 가지고

있으며 설계 보다는 경영과 관리에 목적을 두는 반면, EA는 아키텍쳐 설계를 그 목적으로 한다.

Solution Architect (SA) 특정 솔루션에 대한 아키텍쳐를 설계한다. SA의 경우 프로젝트 내에 개

발팀이 있을때, 해당 솔루션을 사용하는 모든 팀에 대한 아키텍쳐 설계를 담당한다.

Technical Architect (TA) 프로젝트 전체팀에 대한 하드웨어 및 네트워크 아키텍쳐를 설계한다.

Application Architect (AA) 애플리케이션에 대한 표준 가이드 및 아키텍쳐 구조를 담당한다. 팀

규모에 따라 대규모 팀인 경우 각 개발팀마다 AA를 배치하고, 소규모팀인 경우에는 프로젝트 전

체팀에 대해서 애플리케이션 아키텍쳐 설계를 담당한다.

Data Architect (DA) 프로젝트 전체팀테 대해서 데이타 아키텍쳐 설계를 담당한다.

Global Architect (GA) [Optional] 일반적인 프로젝트 팀 구조에서는 잘 존재하지 않는 역할이다.

EA의 경우 사내에서 진행중인 모든 프로젝트에 대해서 관여해야 하고, 비지니스 전략 측면에서

접근을 하다보니 경영진과의 커뮤니케이션이나 의사 결정 과정에 참여가 많아지기 때문에 실제

아키텍쳐 설계 과정에 디테일하게 참여하기가 어렵고, 때로는 기술의 이해수준이 아주 디테일 하

지 않은 경우가 있기 때문에, GA라는 역할을 둬서 SA,TA,DA,AA에 대한 통제 권한 부여하고 기술

중심의 System Architecture의 설계 하도록 한다. 프로젝트 팀의 PM/PL의 관계를 EA/GA 관계로

보면 된다. EA는 비지니스를 포함한 외부 대응이나 큰 그림에 신경 쓰고, GA는 기술 위주의 아키

텍쳐 설계에 집중한다.

Reference Architecture Style

레퍼런스 아키텍쳐 스타일은 아키텍쳐 설계를 할때 참고할 수 있는 아키텍쳐이다.

레퍼런스 아키텍쳐는 그 범위에 따라서 다음과 같이 3가지로 분리 될 수 있다.

Common Architecture는 기술 중심으로, 일반적인 소프트웨어 개발에 사용될 수 있는 아키텍쳐

스타일이다. 특정 업무 도메인에 대한 종속성이 없이 널리 적용이 가능하다. CBD (Component

Based Development), SOA (Service Oriented Architecture), ROA (Resource Oriented

Architecture),EAI (Enterprise Application Integration) 등이 이에 해당한다.

Industry Architecture는 업무 도메인에 대한 종속성을 갖는다. Finance,Government,

Gas/Oil,HighTech,Telco 등 특정 산업 분야에 대한 레퍼런스 아키텍쳐이다. 같은 산업 분야에서는

각 기업별로 기업의 비지니스 목적이나 특징에 따라서 다소 차이는 나지만, 대부분 같은 산업분

야의 큰 아키텍쳐는 유사하다.

Enterprise Architecture는 업무 도메인내에서 회사 내부의 표준 아키텍쳐를 정의한다.

여기서는 몇개의 대표적인 Common Architecture Style에 대해서 소개한다.

SOA (Service Oriented Architecture)

SOA는 2008년대에 유행했던 아키텍쳐 스타일이지만, 2010년대에 들어서는 오히려 OPEN API의

등장과 함께, SOA라고 명시적인 이름은 사용하지 않지만, 조금더 경량화 되면서 OPEN API 기반

의 플랫폼에 많은 영향을 주고 있다. 여기서는 SOA 아키텍쳐에 대한 기본적인 구조와 개념에 대

해서 소개한다.

SOA의 기본 개념

SOA란, 기존의 애플리케이션들의 기능들을 비즈니스적인 의미를 가지는 기능 단위로 묶어서 표

준화된 호출 인터페이스를 통해서 서비스라는 소프트웨어 컴포넌트 단위로 재 조합한후, 이 서비

스들을 서로 조합(Orchestration)하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어

아키텍쳐이다.

또한 기존의 시스템이 각각의 독립된 업무 시스템으로 개발되어왔던 반면 SOA는 기업의 전체

업무가 하나의 거대한 SOA시스템으로 구성이 된다.

이해를 돕기 위해 예를 들어보자, 자바 기술 기반으로 개발된 “고객 정보 시스템”과, 룰 엔진으로

구현된 “룰 엔진”, 메인프레임을 구현된 “계좌이체” 업무 등이 있다고 가정하자.

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

이 각각의 시스템의 기능들을 업무를 기준으로 주요 기능들로 묶어서 플랫폼에 독립적인 인터페

이스 (예를 들어 XML/HTTP, CORBA,SOAP)를 구현하여 외부로 서비스를 제공한다.

<그림 1 SOA의 개념 >

이렇게 제공된 서비스 인터페이스를 이용하여 “신용 대출” 이라는 새로운 업무를 구현할 때 새롭

게 시스템을 신규 개발하는것등이 아니라 기존의 이미 제공되어 있는 서비스들을 조합하여, 하나

의 업무를 구현할 수 있다. 이것이 SOA의 기본적인 개념이다.

SOA 자체는 새로운 개념은 아니다. 소프트웨어 개발에 있어서 계속해서 이야기 되어 왔던 “소프

트웨어의 재사용성”과 “레고웨어 [주. 소프트웨어 모듈을 레고블럭처럼 재 사용성이 높은 단위로

구성한후, 애플리케이션을 마치 레고 블록을 조립해서 하나의 조립물을 만들듯이 제작하는 개념]”

의 연장성에 있는 것이다.

이런 SOA 개념과 구현된 프로젝트는 이미 1990년대부터 구현되어 왔고 존재되어 왔다. 그럼 지

금에 와서야 SOA가 주목 받는 이유는 무었인가? 예전에 서비스 구축을 위한 표준 인터페이스에

대한 방안으로 제시되었던 CORBA등의 기술의 난이도가 높은 점이 문제가 되어 왔으나 현재에는

XML/HTTP나 SOAP 기반의 웹서비스 기술등의 등장으로 서비스의 구현의 기술 난이도 문제가 해

결되었고, e비즈니스 환경에서 기존 업무 환경을 전산화 하는데에만 목적이 맞춰져 있어서 각각의

업무별로 독립된 시스템의 형태로 개발이 되어, 이에 대한 통합이 필요하게 되었으며 [예를 들면

고객 정보를 매출 내용과 연계하여 판매 전략을 수립하는 경우 등] 급격한 비즈니스 환경의 변화

에 따라 비즈니스의 요구를 민첩하게 IT시스템에 반영되어야할 필요성이 대두됨에 따라 이에 대

한 대안으로 SOA가 대두 되었다.

앞에서도 설명하였지만 SOA는 크게 “서비스와 이를 조합하여 애플리케이션을 구성하는 것” 으로

구성된다. 지금부터 각 “서비스”와 “서비스를 구성하는 방법” 에 대해서 알아보도록 한다

SOA에서 서비스의 정의

서비스란 “플랫폼에 종속되지 않는 표준 인터페이스(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. Message Transform 서비스 >

그 외에도 기존 서비스에 새로운 기능을 추가하는 Functional Adding서비스, Façade 기능을 구현

한 서비스등을 그 예로 들 수 있다.

“Process centric 서비스” 는 비즈니스 서비스들을 조합하여 하나의 업무 프로세스를 구현해내는

서비스로, 주로 상태가 있는 (Stateful)를 구현하는데 이용이 된다.

“Application 서비스”는 Technical한 서비스 “트렌젝션 서비스”, “로깅 서비스”가 예가 된다. 지금까

지 설명하면서 “서비스는 비즈니스적인 의미를 가진 컴포넌트 이며 트렌젝션 등은 서비스가 될

수 없다..” 라고 이야기를 했지만, 현실세계에서 이런 서비스가 나오지 않을 수 있는 보장이 있을

까? 언제나 예외는 존재한다고 SOA에서 지극히 예외적인 서비스이다. 잘 설계된 SOA에서는

“Application 서비스”가 존재하지 않는다.

“Public enterprise 서비스”는 다른 회사나 다른 SOA시스템으로 제공되는 서비스이다. [은행의 대

외계 업무 정도가 이에 해당한다.] 다른 서비스에 비해서 외부로 제공되는 서비스인 만큼 성능,

트렌젝션, 보안에 대한 깊은 고려가 필요하다.

SOA 아키텍쳐 모델

지금까지 “서비스가 무엇인가?” 에 대해서 알아보았다. 지금부터는 이 서비스들을 어떻게 조합하

여 소프트웨어 시스템을 구성하는지, 구성 방법에 대해서 알아보도록 하자.

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

단계적인 발전 모델을 설명하기에 앞서서 “application frontend”에 대해서 설명하면, 서비스들이

사용되어 최종 사용자에게 보이는 곳이 application front end이다. 일반적인 웹사이트나 기업 포

탈, X 인터넷 클라이언트, 4GL 클라이언트등이 될 수 있다.

(1) Fundamental SOA [통합]

가장 기본적인 형태의 SOA로, 비즈니스 서비스와 애플리케이션 서비스만 존재하며 이 서비스들

의 조합들은 application front end에서 이루어 진다.

Fundamental SOA의 가장 큰 목적은 기존의 시스템을 각각 서비스화하는 것과 독립되었던 시스

템들을 통합하여 하나의 시스템으로 운영한다는데 목적이 있다.

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

서비스화하여 통합된 SOA시스템은 시간이 갈 수 록 그 크기가 커지게 되고 서비스간의 호출은

관계는 날이 갈 수 록 복잡해진다. 그리고 서비스의 내용이 변경 또는 보강 되어 가면서 의존성

에 의해서 서비스간에 수정이 필요한 경우가 발생한다. 이는 서비스의 변화를 어렵게 만들고 결

과적으로 기업 업무에 대한 ‘경직성’ 을 유발하는데, 이를 해결하기 위해서 모든 서비스들을 중앙

에 하나의 버스를 통해서 관리하여 서비스간 연결의 복잡도를 해소하고 Intermediary 서비스를

추가 함으로써, 서비스의 내용이 변경되었을 때 그 차이를 보강해줄 수 있어야 한다.

<그림 4 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시스템이 최적화를 이룰 수

있다.

<그림 5. BPA,BPM,BAM을 통한 업무 프로세스의 구현과 업무의 최적화 >

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 아키텍쳐 구성을 하나의 그림으로 표현해보면 다음과 같다.

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

지금까지 SOA가 무엇인지, 그를 구성하는 서비스의 개념과 서비스를 조합하여 SOA시스템을 구

축하는 방법에 대해서 알아보았다.

그렇다면 실제로 SOA 프로젝트를 수행하는데 있어서 어떻게 SOA 시스템을 구축하며 프로젝트를

진행해야 할까? 아래부터는 SOA의 수행 방법론에 대해서 알아보도록 하자.

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 시스템 보다는 높아진다.

< 그림 7 SOA의 비용 집행 방법 >

그러나 위의 그림에서와 같이 계속해서 업무를 추가해나감에 따라 새로운 업무가 완전히 새롭게

구성이 되는 것이 아니라 앞단계에서 개발하였던 서비스들을 다시 재 사용되기 때문에 개발 비용

은 지속적으로 감소하게 되고, 기능이 부족한 서비스들은 계속해서 대체 되면서 안정적으로 유지

되기 때문에 시간이 갈 수 록 소요 비용은 감소하게 된다.

(3) 제어와 통제

SOA 시스템이 거대화해짐에 따라 SOA 시스템에 대한 중앙 관리 및 통제 제어가 필요하게 된다.

어느 서비스부터 개발해야 할것인지, 이번 기간내에 진행해야할 SOA범위, 각 개발에 대한 표준화,

자금 조달 계획등을 수행해야 하며 이를 통제하는 조직이 필요하다. 이러한 통제를 Goverance라

고 하는데,

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

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

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

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

- 자금 조달 및 집행 계획

- 업무 분석 및 설계

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

- 모범사례 수집과 배포

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

을 위한 통제 모델이다.

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

중앙 통제 조직은 실 개발 조직인 IT 조직과 비즈니스 조직간의 중계 역할을 하게 되며, 비즈니스

조직으로부터 전략과 요구 사항을 받아 실제 구현 조직에 전달을 하며

각 개발 조직에서 개발된 내용들에 대한 검증 및 배포 작업과 SOA 플랫폼에 대한 운영 및 모니

터링 통제를 실시 한다.

이외에도 SVN 등을 이용한 소스의 통제, apache maven과 같은 도구를 이용한 빌드의 관리, 일일

빌드 정책, 개발 방법론등도 이 “제어와 통제”에 해당한다.

(4) 프로젝트 관리

SOA의 프로젝트 진행에 있어서 특이한 점은 “반복적인 개발(Iterative Development)”과 “점진적인

개발(Incremental Development)”이다. 한번에 SOA 전체 시스템을 개발하는 것이 아니라 중요 업

무를 먼저 개발한후에 반복적으로 업무에 대한 개선 작업을 병행하고, 점차적을 필요한 기능을

추가해나가는 모델이다.

또한 SOA의 프로젝트 개발 관리는 앞에서 설명 했던 Thin Thread Model의 개발 방식을 준수 하

면 좀 더 좋은 효과를 볼 수 있다.

REST Architecture

근래에 인터넷 서비스의 유행으로 업체들은 매쉬업과 OPEN API를 이용하여 새로운 서비스를 제

공하기 시작했는데, 기존의 SOAP 기반의 웹서비스들은 서비스 업체들이 제공하는 단순한 OPEN

API에 사용하기에는 지나치게 복잡하였고, 무거웠다. 그래서 서비스 업체들은 새로운 기술을 찾기

시작했는데, 그것이 바로 REST이다. 근래 들어 유행하는 인터넷 아키텍쳐들은 대부분 이 REST를

기반으로한 OPEN API를 사용한다.

REST는 웹의 창시자(HTTP) 중의 한 사람인 Roy Fielding의 2000년 논문에 의해서 소개되었다. 현

재의 아키텍쳐가 웹의 본래 설계의 우수성을 많이 사용하지 못하고 있다고 판단했기 때문에, 웹

의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍쳐를 소개했는데 그것이 바로

Representational safe transfer (REST)이다.

대표적인 OPEN API를 제공하는 인터넷 서비스 업체인 아마존 역시 SOAP 기반으로 제공하던

OPEN API를 모두 이 REST 방식으로 전환하고 있다.

Basic of REST

자아 그러면 REST에 대해서 살펴보도록 하자. 한마디로 REST를 정리하면 HTTP URI + HTTP

Method 이다. URI로 대상 자원을 명시하고 Method로 해당 자원에 대한 행위를 정의한다.

<그림. REST의 구성>

Resource

REST의 가장 큰 특징중의 하나가 모든 대상을 Resource 즉 자원으로 표현한다는 것이다. 이

Resource는 HTTP URL에 의해서 표현된다. 예를 들어 javastudy 사이트의 bcho 라는 사용자를 표

현하면 http://www.javastudy.co.kr/users/bcho 로 표현이 가능하고, 서울 강남구 사무실의 9층의

HP프린터를 표현할때는 http://printers/localtion/seoul/kangnamgu/9f/hp 식으로 표현을 한다. 이

로써 HTTP URI를 통해서 모든 Resource를 표현이 가능하다.

Action

그렇다면 해당 자원에 대한 행동은 어떻게 표현할것인가? 이는 HTTP Method를 사용한다.

자바스터디 사이트의 bcho 에 대한 회원 정보를 가지고 오고 싶을때는

URI : http://www.javastudy.co.kr/users/bcho

Method : GET

또는 해당 회원을 생성하고 싶을 때


Method : POST

PayLoad

<payload>

<name>조대협</name>

:

</payload>

해당 회원을 삭제하고 싶을 때


Method : DELETE

해당 회원에 대한 정보를 변경하고 싶을 때


Method : PUT

PayLoad

<payload>

<name>조대협</name>

:

</payload>

즉 HTTP 프로토콜에 정의된 4개의 메서드들이 자원(Resource)에 대한 CRUD행위를 정의한다.

HTTP Method 의미

POST Create

GET Select

PUT Create or Update

DELETE Delete

상당히 직관적이고 쉽지 않은가? 이것이 REST의 기본이다.

그러면 조금 더 발전된 형태의 REST 디자인을 살펴보자. 예를 들기위해서 은행의 계좌이체를 하

는 시나리오를 가정해서 생각해보자.

인터넷 뱅킹 계좌 이체 시나리오의 구현

STEP 1. 인터넷 뱅킹 시스템에 로그인을 한다.

STEP 2. 사용자 ID로, 해당 사용자가 가지고 있는 계좌 목록을 조회한다.

http://bank.org/accounts?findby=7t676323a

200 OK

Content-Type: application/xml;charset=UTF-8

<accounts xmlns="urn:org:bank:accounts">

<account>

<id>AZA12093</id>

<customer-id>7t676323a</customer-id>

<balance currency="USD">993.95</balance>

</account>

<account>

<id>ADK31242</id>

<customer-id>7t676323a</customer-id>


</account>

</accounts>

사용자 ID 7t76323a에 대해서 두개의 계좌 AZA12093과 ADK31242 가 리턴되고 각 계좌의 잔액

이 함께 리턴된다. 각 계좌 번호를 조회했기 때문에 각 계좌의 상세 정보는

http://bank.org/account/AZA12093

http://bank.org/account/ADK31242

STEP 3. 계좌 이체를 하는 시나리오를 보면

POST /transfers

Host: bank.org


<transfer xmlns="urn:org:bank:accounts">

<from>account:AZA12093</from>

<to>account:ADK31242</to>

<amount currency="USD">100</amount>

<note>RESTing</note>

</transfer>

AZA12093에서 ADK31242로 100 USD를 이체하는 것을 HTTP POST를 통해서 보낸다.계

좌 이체가 성공하면 다음과 같은 결과값이 리턴된다.

201 Created





<id>transfer:XTA8763</id>



</transfer>

이때 주의해서 볼 것은 리턴값이 HTTP 200이 아니라 HTTP 201이다. 이 시스템의 경우

계좌이체가 바로 발생하는 것이 아니라 비동기적으로 나중에 발생하는 형태로 가정하기

때문에, 계좌 이체 요청이 접수되었다라는 의미로 HTTP 201 Created를 리턴하고 이체 신

청 번호 XTA8763을 리턴한다.

STEP 4. 하루가 지난후에, 계좌 이체가 된 내용을 다시 확인해보면

http://bank.org/check/XTA8763

GET /check/XTA8763

Host: bank.org

200 OK


<status xmlns="urn:org:bank:accounts">

<code>01</code>

<message xml:lang="en">Pending</message>

</status>

해당 계좌 이체 요청이 Pending이 되어 있는 것으로 나타난다.

발전된 형태의 REST를 이용한 인터넷 뱅킹 계좌이체 시나리오의 구현

앞의 예제는 언뜻 보면 상당히 잘 구현된 형태의 REST처럼 보이지만, 이는 실제 REST의 장점을

제대로 살린 구현이라고는 볼 수 없다.

REST는

첫번째로 URI 를 이용한 자원의 식별이 가능해야 하고,

두번째로 HTTP 프로토콜의 여러 기능들 특히 HTTP Header 들을 이용해서 리소스에 대한

다양한 접근 방법을 표현할 수 있어야 한다. 예를 들어서 Sync/Async 식의 Message

Exchange Pattern, Correlation ID 등을 이용한 CALL BACK, 웹캐쉬를 이용하기 위한 Last

Update Time 등의 메타 정보를 HTTP HEADER 에 정의해야 하며 Contents Type 등을 통한

Input 과 Output Data Format 에 대한 정의가 가능할 수 있다.

세번째로는 링크를 이용한 리소스간의 관계나 현재 리소스에 대한 상태 정보를 표현할 수

있어야 한다.

그러면 이 특징을 기반으로 해서 앞에서 작성했던 계좌 이체 시나리오를 재 구현해보자

STEP 1. 인터넷 뱅킹 시스템에 로그인을 한다.

STEP 2. 사용자 ID로, 해당 사용자가 가지고 있는 계좌 목록을 조회한다.

200 OK

Content-Type: application/vnd.bank.org.account+xml;charset=UTF-8

<accounts xmlns="urn:org:bank:accounts">

<account>

<id>AZA12093</id>

<link href="http://bank.org/account/AZA12093" rel="self"/>

<link rel="http://bank.org/rel/transfer edit"

type="application/vnd.bank.org.transfer+xml"

href="http://bank.org/transfers"/>

이 부분을 살펴보면 세가지 변화 상태를 볼 수 있다. Self와 http://bank.org/rel/transfer 그리고

http://bank.org/rel/customer 이다.

첫번째로 http://bank.org/rel/transfer 로 이 계좌에 대해서 “계좌 이체”를 할 수 있는 관계(또는

기능)을 정의하며, 계좌 이체를 하기 위해서는 http://bank.org/transfers URL에 보내면 되고 리턴

값은 application/vnd.bank.org.transfer+xml 형태가 된다.

두번째 self는 이 Account 자체에 대한 좀더 제사한 정보를 나타내며

http://bank.org/account/ADK31242 를 통해서 조회할 수 있으며 리턴 되는 데이터 형태는

application/vnd.bank.org.account+xml 로 리턴 됨을 정의한다.

세번째 http://bank.org/rel/customer 는 고객 정보를 나타내며

http://bank.org/customer/7t676323a 를 통해서 조회가 가능하고 리턴되는 데이터 형태는

application/vnd.bank.org.customer+xml 이 된다.

STEP 3. 실제로 계좌 이체를 수행한다.

STEP 2에서 리턴 받은 transfer 관계의 URL로 아래와 같은 데이터를 전송한다.

POST /transfers

Host: bank.org

Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8






</transfer>

리턴값은 아래와 같다.

201 Created

Content-Type: application/vnd.bank.org.transfer+xml;charset=UTF-8


<link rel="self"

href="http://bank.org/transfer/XTA8763"/>

<link rel="http://bank.org/rel/transfer/from"

type="application/vnd.bank.org.account+xml"

href="http://bank.org/account/AZA12093"/>

<link rel="http://bank.org/rel/transfer/to"

type="application/vnd.bank.org.account+xml"

href="http://bank.org/account/ADK31242"/>

<link rel="http://bank.org/rel/transfer/status"

type="application/vnd.bank.org.status+xml"

href="http://bank.org/check/XTA8763"/>

<id>transfer:XTA8763</id>



</transfer>

STEP 4. 계좌 이체 진행 상태를 확인한다.

계좌 이체 진행 상태를 확인하기 위해서는 STEP 3에서 리턴된

http://bank.org/check/XTA8763 을 이용하여 확인할 수 있다.

지금까지 REST 아키텍쳐의 개념에 대해서 간략하게 알아보았다.

REST 아키텍쳐적인 문제점

그러면 REST가 아키텍쳐적으로 우수해 보인다 . 그러면 결점이 없느냐? 치명적인 결점이 있다.

REST를 이용해서 설계를 하다보면 우리가 사용할 수 있는 메서드가 4가지 밖에 없다는 것이다.

예를 들어 send email이라던가, Log write와 같은 메서드들은 HTTP Method로 표현하기가 모호해

진다.

기존의 프로그래밍 스타일이 Function이나 Method를 중심으로 한 행위 중심적인 접근이었기 때

문에, REST가 지향하고 있는 자원 기반의 접근에 맞지 않는 것이다. 오히려 DBMS와 같이 CRUD

를 가지고 있는 자원에 대해서는 적절하게 적용된다. 이런 이유가 REST를 단순하게 프로토콜이라

고 부르지 않고 아키텍쳐라고 정의한 이유이다.

그렇다면 이 문제를 어떻게 해결해야 할 것인가?

사실 CRUD만으로 모든 행위를 표현할 수 는 없다. Control성이나 함수성의 의미를 갖는 것들을

표현해야 하는데, 이런 경우는 HTTP/PUT이나 POST 메서드를 사용하거나 또는 함수에 대한 의미

를 재해석하는 접근이 필요한데. Send Mail을 예를 들어보면 “메일을 보낸다” 라는 행위를 “누구

한테 보내는 메일을 생성한다” 라는 의미로 바꾸면 다음과 같은 표현이 가능하다. HTTP/POST

http://www.xxx./sendmail/to/{emailaddress}

그래도 문맥상으로 의미 변환이 불가능한 경우가 생긴다.

이런 경우는 HTTP/PUT과 URI를 사용하여 control의 의미를 부여한다. 사용자 ID bcho에 대한 등

급 변경을 하는 경우는 다음과 같이 표현할 수 있다.

예를 들어 http://www.xxx/users/bcho/upgrade

사실상 REST 기반의 아키텍쳐를 설계하려면 가장 어려운 것이 이 URI를 어떻게 정의하는 것이다.

REST의 장점중 하나는 이 URI와 HTTP Method만으로도 쉽게 의미를 파악할 수 있다는 것이기 때

문에, URI 정의에 많은 노력을 기울이는 것이 좋다

REST 아키텍쳐의 장단점

REST의 장점

기존의 웹 인프라를 그대로 이용할 수 있다.

가장 큰 장점중의 하나일거다. 기존 HTTP를 그대로 사용하기 때문에, Remote Call을 할때도 방화

벽을 새로 뚫어야 하느니등의 요건이 없고, L4등의 로드 밸런서 장비들도 그대로 사용이 가능하다.

무.엇.보.다. 웹캐쉬 서버를 그대로 사용할 수 있다. 모든 Resource가 URI로 Unique하게 표현되기

때문에, 웹 캐쉬상에 보관될 수 있고, 특히나 SELECT성의 Operation은 이 캐쉬에 의해서 실제 Biz

Transaction을 타지 않고 바로 리턴될 수 있기 때문에, 성능과 리소스 활용 측면에서 어마어마한

장점을 가지고 있다.

정말 쉽다. 웹서비스와 비교해보면 웹서비스는 스펙이 정말 많다. WS*-I, WS Reliable Messaging,

WS Transaction 등등등 스펙 덩어리다. 그러나 REST는 별도의 SPEC이 없다. 보통 Defactor 표준

이라고 하는데, HTTP URI와 Method만 잘 지켜서 사용하면 그게 REST다.

REST의 단점

표준이 없다. 즉 관리가 어렵다. 웹서비스와 같은 메시지 구조를 정의하는 WSDL도 없고, UDDI와

같은 서비스 관리체계도 없다. WS-I이나 WS-* 와 같은 메시지 규약도 없다.

REST가 요즘 들어 부각되는 이유 자체가 WebService의 복잡성과 그 표준의 난이도 때문에 Non

Enterprise 진영 (Google,Yahoo,Amazone) 을 중심으로 집중적으로 소개되었다. 데이터에 대한 의

미 자체가 어떤 비즈니스 요건 처럼 Mission Critical 한 요건이 아니었기 때문에 서로 데이터를

전송할 수 있는 정도의 상호 이해 수준의 표준만이 필요했지 Enterprise 수준의 표준도 필요하지

않았고, 벤더들 처럼 이를 주도하는 회사도 없었다.

단순히 많이 사용하고 암묵적으로 암암리에 생겨난 표준 비스무리 한 것이 있을 뿐이다. (이런

것을 Defactor 표준이라고 부른다.)

그런데 문제는 정확한 표준이 없다보니, 개발에 있어서 이를 관리하기가 어려워진다는 것이다. 표

준을 따르면 몇 가지 스펙에 맞춰서 개발 프로세스나 패턴을 만들 수 가 있는데, 이는 표준이

없으니, REST 기반으로 시스템을 설계하자면 사용할 REST에 대한 자체 표준을 정해야 하고, 어떤

경우에는 REST에 대한 잘못된 이해로 인하여 잘못된 REST 아키텍쳐에 이건 REST다 라는 딱지를

붙이는 경우가 많다. 실제로 WEB 2.0의 대표 주자격인 Flickr.com 도 REST의 특성을 살리지 못하

면서 RPC 스타일로 디자인한 API를 HTTP + XML을 사용했다는 이유로 Hybrid REST라는 이름을

붙여서 REST 아키텍쳐에 대한 혼란을 초래했다.

주. Hybrid REST

Flickr의 Hybrid Rest는 어떤 Operation을 처리할 때,

http://URL/operation?name=operationname 과 같은 형태로 메서드를 Query String으로 넘기는

형태를 사용했다. 언뜻 봐서는 RESTful한 디자인 같지만, 모든 Resource의 URI는 같고 operation

을 Query String으로 나눈것에 불과 하기 때문에, 모든 Resource에 Unique 한 URI를 부여하는

REST의 원래 설계 원칙과 벗어난다. 그럼에도 불구하고 이런 설계 방식이 모 서적에 Hybrid REST

라는 형태로 소개되어 많은 잘못된 디자인을 양산했다.

REST 아키텍쳐 설계 방법

위에서도 잠깐 설명했지만, REST는 WebService와 같은 프로토콜이 아니다. REST는 아키텍쳐이다

Resource를 기반으로 하는 아키텍쳐이기 때문에 시스템 설계도 Rest 에 맞는 설계가 필요하다.

Alternative Key의 사용

예를 들어 Resource를 표현할 때, 이러한 Resource는 DB의 하나의 Row가 되는 경우가 많은데,

DB의 경우는 Primary Key가 복합 Key 형태로 존재하는 경우가 많다. (여러 개의 컬럼이 묶여서

하나의 PK가 되는 경우) DB에서는 유효한 설계일지 몰라도, HTTP URI는 / 에 따라서 계층 구조를

가지기 때문에, 이에 대한 표현이 매우 부자연 스러워진다.

예를 들어 DB의 PK가 “세대주의 주민번호”+”사는 지역”+”본인 이름일 때” DB에서는 이렇게 표현

하는 것이 하나 이상할 것이 없으나, REST에서 이를 userinfo/{세대주 주민번호}/{사는 지역}/{본인

이름} 식으로 표현하게 되면 다소 이상한 의미가 부여될 수 있다.

이외에도 resource에 대한 Unique한 Key를 부여하는 것에 여러가지 애로점이 있는데, 이를 해결

하는 대안으로는 Alternative Key (AK)를 사용하는 방법이 있다. 의미를 가지지 않은 Unique Value

를 Key로 잡아서 DB Table에 AK라는 필드로 잡아서 사용 하는 방법인데. 이미 Google 의 REST도

이러한 AK를 사용하는 아키텍쳐를 채택하고 있다.

그러나 DB에 AK 필드를 추가하는 것은 전체적인 DB설계에 대한 변경을 의미하고 이는 즉 REST

를 위해서 전체 시스템의 아키텍쳐에 변화를 준다는 점에서 REST 사용시 아키텍쳐적인 접근의

필요성을 의미한다.

사실 그외에도 REST적인 설계를 하기 위해서는 Resource간의 관계를 href로 (링크)로 표현하는

기법,Versioning 방법,Naming Rule, ESB를 이용한 Cross cutting concern의 처리와 Routing 등 여

러가지 고려 사항이 있으나, 아키텍쳐 설계 방법과 고급 REST에 대해서는 다음 기고 (고도화된

REST 아키텍쳐)에 대해서 논의 하기로 하겠다.

REST에 대한 잘못된 인식

REST = HTTP + XML 프로토콜?

프로젝트 성격상 고도화된 REST 시스템에 대한 설계가 필요했기 때문에 필자가 작년 중반즘에

국내의 한 커뮤니티 사이트에 REST에 대한 토론을 제안한적이 있었는데. 대부분의 사람들의 REST

에 대한 이해는 REST는 HTTP를 써서 XML을 보내면 REST라고 생각하고 있었다.

절대 아니다.

REST는 웹의 특성을 잘 활용하여 자원을 리소스로 표현하는 아키텍쳐이다.(프로토콜이 아니다) 물

론 HTTP는 사용해야 한다. 그러나 XML은 필수가 아니다. JSON이나 YAML과 같은 다른 표현 언

어를 사용해도 무방하다. 리소스에 대한 표현과 웹의 특성을 얼마나 잘 활용했는가가 REST 아키

텍쳐를 제대로 이해하는가에 대한 판단 기준이 될것이다.

이번 글을 쓰는 이유중의 하나도 국내에 제대로된 REST에 대한 기고나 원칙을 설명한 문서가 없

는 것 같아서 다소 부족한 글이지만 정리하고자 함이다.

REST는 WebService보다 쉽다.?

사실 그렇지도 않다. 맨 바닥에서 개발한다면야 REST가 더 쉽다. 자체 표준을 만들어서 Simple

XML로 메시지를 정의해서 단순히 HTTP로만 보내면 되니까.. 그런데 이건 서비스 제공자 입장이

다. 서비스를 사용하는 입장에서는 HTTP Client로 요청을 보내서 리턴받은 XML이나 JSON 데이터

를 일일이 파싱해서 처리해야 한다.

그러나 WebService는? 이미 잘 짜여진 표준 때문에, POJO나 JAX-WS등으로 코딩만 하면 자동으

로 웹서비스가 생성된다. 무엇보다 WSDL에 의해서 정해진 서비스 Contract에 의해서 Client Stub

을 자동으로 생성할 수 있기 때문에, 프로토콜 Spec을 전혀 모르더라도 마치 Java Library를 호출

해서 사용하는 것처럼 쉽게 사용할 수 있다.

본인의 경우에는 REST보다 WebService개발이 더 쉬워 보인다. 가장 쓰기 좋은 것은 복잡도가 낮

고 잘 정리된 WS-I 기반의 WebService를 사용하는 것이 가장 간단하고 생산성면에서도 좋다.

Advanced REST Architecture

지금까지 REST 아키텍쳐에 대한 개념 소개, 설계 방법에 대해서 알아보았다. 이번는 REST 고유의

특성을 살려서 향상된 아키텍쳐를 설계할 수 있는 방안에 대해서 소개한다.

ESB를 이용한 향상된 REST 아키텍쳐

1) 공통 기능에 대한 처리

REST와 같은 RPC 스타일의 호출 구조를 가지게 되는 아키텍쳐의 경우 각 컴포넌트마다 공통적인

문제점중 하나는 Cross Cutting Concern (공통 기능)이 각각의 컴포넌트에서 구현이 된다는 것

이다.

인증과 인가, 로깅과 같은 공통적인 처리 요건이 각각의 컴포넌트 모듈에서 중복되서 개발이 된

다. 이로 인해서, 같은 코드를 반복해서 개발해서 생산성이 떨어지고, 또한 만약 이러한 공통 처

리 요건이 변경되었을 때, 전체 시스템의 코드를 변경해야 하는 문제가 발생한다

그림 1일반적인 컴포넌트 아키텍쳐

이러한 공통 기능의 중복적인 개발은 생산성을 떨어뜨리고 또한 공통 모듈의 변화는 전체 프로그

램의 수정을 일으켜서 아키텍쳐의 유연성과 생산성을 급격하게 감소 시키는 문제점을 야기 하였

다.

이러한 공통 모듈 (Cross cutting concern)을 ESB 에 중앙 집중화 시킴으로써, 컴포넌트 개발자가

비즈니스 업무 로직 개발에 집중하도록 하고, 변경 시에서도 ESB 단일 지점만 변경하도록 하여

유연하고 생산성이 높은 아키텍쳐를 구축할 수 있다.

그림 2공통 기능을 ESB에서 공통 처리하는 아키텍쳐

2) Mediation을 통한 유연성 증대

아키텍쳐 설계에 있어서 중요한 점 중의 하나는 비즈니스 변화에 대한 대응 능력이다.

예를 들면

Function Adding

기존 기능에 대해서 새로운 기능이 더해진 경우. 예를 들어결재 서비스에 캐쉬백 기능이

나 포인트 적립이 추가되는 경우

Data Transformation

입력이나 출력 받는 데이터의 형식이 바뀐 경우. 예를 들어 게시판에 글을 올리는데 기

존에는 사용자 ID만 필요했는데, 실명제로 인해서 주민등록 번호를 조회해야 하는 경우

입력값이 사용자 ID만에서 사용자 ID와 주민등록 번호를 받는 입력형태로 변경되고, 기

존의 글 올리기 서비스는 변경이 없고 입력 받은 주민등록 번호로 실명 인증하는 기능을

추가하는 경우

Routing

어떤 조건에 따라서 호출되는 서비스가 달라지는 경우. 예를 들어 신용카드 서비스 정책

이 일반 회원만 있다가 플레티넘 회원에 대한 서비스와 포인트 적립 방식이 달라지는 경

우 회원 등급에 따라서 호출해야 하는 서비스가 달라진다.

이러한 시나리오는 비즈니스 요구사항 변화에 따라서 발생을 하고, 이는 실제 비즈니스 컴포넌트

에 변경 요건을 준다. 특히 해당 비즈니스 컴포넌트가 여러곳에서 사용되고 있을 경우(의존성을

갖는 경우) 이에 대한 변경 여파가 매우 크다.

위와 같이 기존의 비즈니스 로직에 변화를 줘서 동작 방식을 바꾸거나 개선하는 것을 Mediation

이라고 하는데, ESB 에서 이 Mediation 계층을 추가하여 비즈니스 요건이 변경되었을 경우 비즈

니스 컴포넌트에 대한 변경이 없이 이를 ESB 내에서 반영하여 업무 요구 사항에 대한 변화에 쉽

고 빠르게 대응할 수 있다.

3) 모니터링과 서비스 통제

마지막으로 서비스에 대한 통제와 모니터링 기능을 꼽을 수 있는데, 특정 서비스의 사용률이나

응답시간등의 모니터링을 통해서 비즈니스 컴포넌트의 건강성과 재사용률을 파악할 수 있다.

그리고 비즈니스 컴포넌트에 문제가 있을 때 빠르게 검출 및 대응을 할 수 있다. (응답시간이 5초

내로 떨어지는등 현상), 무엇보다 통제 기능을 부여할 수 있는게 큰 장점중의 하나이다. 해당 비

즈니스 컴포넌트의 TPS가 100이상을 넘으면 더 이상 요청을 받지 않고 에러 처리를 해서 시스템

을 보호한다거나 관리자에게 알려서 용량 증설등의 조치를 할 취할 수 있게 한다.

이런한 모니터링 및 관제 기능을 별도로 비즈니스 컴포넌트단에서 구현하기 위해서는 별도의 아

키텍쳐 설계와 함께, 공통 모듈의 개발과 테스트를 거쳐야 하는데, 이런 과정이 패키지화 되어 있

기 때문에, 이 과정에 소요 되는 많은 리소스들을 절약할 수 있다.

4) NoSQL DB를 이용한 데이터 베이스의 확장

REST는 모든 Operation이 Resource라는 데이터 단위로 움직이는데, 이 Resource를 기존의 아키텍

쳐 방식에 따라서 RDBMS에 저장하면 여러가지 문제가 생긴다. (첫회에서도 설명하였듯이)

REST에서는 1 resource가 하나의 저장소에 저장되는 형태가 좋은데, (하나의 ROW라던지). RDBMS

는 여러개의 Table에 걸쳐서 데이타가 나누어 저장되고, Key 구조도 FK를 이용하거나해서 복합 키

가 생겨 버려서 Key 정의에도 모호성이 보인다.

반면에 NoSQL DB, 특히 Column형 DB는 Key & Value형태를 가지고 Value는 Schmeless로 아무

데이타형이나 들어갈 수 있기 때문에, (마치 HashTable에 VO를 Object 형으로 넣으면 모든 데이

타 타입을 다 넣을 수 있는것 처럼) ROA 에 딱 맞아 떨어진다.

5) DataGrid를 이용한 캐쉬 기능 추가

첫회에서도 언급한 내용인데, REST의 경우 HTTP 스펙을 준수하고, URI를 Key로 하여 값을 리턴하

는 방식이기 때문에, 웹에서 사용하는 캐슁 기능을 그대로 사용할 수 있다. “Last-Modified” 태그

나 E-Tag를 이용하면 캐슁을 구현할 수 있는데,

아래와 같이 Client가 HTTP GET을 “Last-Modified” 값과 함께 보냈을 때, 컨텐츠가 변화가 없으면

REST Component는 “304 Not Modified”를 리턴하면 Client는 자체 캐쉬에 저장된 값을 사용하게

된다.

그림 3 Last Modified 필드를 이용한 캐슁 처리 방식

이렇게 캐쉬를 사용하게 되면 네트웍 응답시간 뿐만 아니라, REST 컴포넌트가 위치한 서버에 트

렌젝션을 발생시키지 않기 때문에, 전체 응답시간과 성능 그리고 서버의 자원 사용률을 비약적으

로 향상 시킬 수 있다.

그러면 다음 문제가 캐쉬를 어떻게 컨트롤 할 것인가가 문제인데, 물론 Client마다 개별 로직을

이용해서 캐쉬를 저장소를 운영하고 캐쉬로직을 컨트롤할 수 있다.

그러나 이런 경우 앞에서 설명했던, 공통 기능에 대한 중복 개발 문제가 또다시 발생하게 되어서

생산성 문제를 야기하고 코드 변경을 어렵게 한다. 앞서 공통 기능에 대한 문제를 ESB로 풀었던

것처럼, 이 문제 역시 ESB로 해결할 수 있는데, 여기에 더해서 캐쉬의 데이터 저장소에 대한 이슈

가 발생한다. 캐쉬 저장소를 파일이나 DBMS를 사용하게 되면 물리적인 DISK IO로 인하여 캐쉬의

성능이 저하되고, 메모리를 사용하게 되면 프로세스상의 물리적 메모리 한계와 클러스터 환경에

서 캐쉬가 분산되는 문제가 발생한다. 자바의 경우, 하나의 프로세스의 사용 가능한 메모리는 실

제적으로는 3G가 한계이다. 64 bit에서는 더 큰 사이즈를 지원하기는 하지만 Full GC등의 문제로

현실적으로 적용이 불가능 하다. 또한 여러 개의 웹서버에 걸쳐서 캐쉬가 존재하게 되면, 프로세

스간의 메모리 내용 공유가 어렵기 때문에 분리된 캐쉬를 가지게 되고, 캐쉬간에 각각 중복된 데

이타가 저장되거나 데이터가 동기화가 어려운 문제로 인해서 데이터 불일치성이 발생할 수 있다.

이러한 문제를 해결하기 위해서 필요한 솔루션은 메모리에 캐쉬를 저장하되, 이 메모리가 서로

클러스터링이 되서 무제한 확장 가능한 형태를 가져야 하는데, 이러한 솔루션을 DataGrid라고 한

다. 데이터 구조는 앞서 설명한 NoSQL과 거의 같은 형태를 가지고 있는데, DataGrid는 프로세스

간의 클러스터링을 통해서 이론적으로 무제한 확장이 가능하다.

이러한 솔루션은 memcached 와 같은 오픈 소스 솔루션이 있으며, 이미 Facebook이나 Twitter에

서 이와 같은 캐쉬 솔루션으로 사용되고 있다. 상용 솔루션으로는 Oracle의 Coherence와

Windows Server의 Appfabric Cache 가 있다.

그림 4 DataGrid를 이용한 REST 캐슁 처리

아키텍쳐를 설계하면 위와 같은 그림이 된다. 모든 Request는 ESB를 통하게 되고, ESB의 Cache

Logic에서 DataGrid에 REST의 Resource Key로 Last-Modified 시간을 조회한다. 만약에 Last-

Modified 시간이 Client에서 보낸 것과 같거나 새것인 경우에는 Cached된 값을 리턴하고, Client

에서 보낸 값이 더 새로운 시간인 경우, REST Component로 요청을 전달하여 비즈니스 로직 처리

후 리턴을 하고, 리턴 과정에서 Cache에 데이터를 업데이트 한다.

Advanced REST Architecture 요약

지금까지 REST 아키텍쳐의 향상된 형태에 대해서 소개하였다.

아키텍쳐 향상 방법을 종합해 보면 다음과 같은 그림의 아키텍쳐가 나온다.

그림 5 향상된 REST 아키텍쳐 요약

REST 컴포넌트 맨 앞에서 ESB가 공통로직, 모니터링 및 SLA 통제 그리고 Mediation을 통한 유연

성을 증대 시키고, ESB와 연동되어 DataGrid에서는 REST에 대한 캐쉬 데이터를 저장한다.

데이터 계층에서는 No-SQL의 Column DB를 통해서 REST 아키텍쳐에 알맞은 데이터 저장 구조를

제공한다.

OPEN API는 이미 유행이나 신기술이 아닌 대세이자 표준이다. Amazon이 WebService API를

SOAP에서 탈피하여 REST로 전환 중에 있고,Google,Twitter,Facebook과 같은 대표적인 Social

Service들도 REST를 기반으로 OPEN API를 제공하고 있다.

대용량 서비스 시스템에 대한 레퍼런스 아키텍쳐

일반적인 시스템의 구조

일반적인 서버형태의 시스템들은 대부분의 구조가 비슷한데 크게 다음과 같이 3개의 구조로 이루

어진다.

사용자의 요청을 처리하는 Internal Business Logic으로 일반적인 시스템의 기능은 여기서 모두 처

리된다. 다음으로, 외부 시스템과의 연계를 담당하는 “External Interface” 부분이다. 은행의 계좌

이체나 증권 감독원, 타 은행 들에 대한 연계등이 해당된다. 마지막으로 각 로그 데이타를 수집해

서 분석이나 리포팅 처리를 하는 Reporting 부분으로 나뉘어진다. 금융권에서는 일반적으로 “대내

계,대외계,정보계” 형식으로 이야기 한다. 금융권뿐만 아니라 대부분의 시스템은 이와 같은 3가지

구조를 가지고 있다. 이 분류를 기본으로 하여, 대용량 서비스 시스템에 대한 레퍼런스 아키텍쳐

를 소개한다.

SOA + REST 기반의 플랫폼 아키텍쳐

앞서 설명한 SOA는 판매되는 솔루션은 다소 유행처럼 지나갔지만, 업무를 서비스화하여 컴포넌

트로 제공하는 개념은 현대의 아키텍쳐에 많은 영향을 줬다. 현재 개발되는 시스템들은 대부분

기본적인 사상은 SOA에 기반하는 시스템이 많다 SOA의 무거운 아키텍쳐와 불필요한 컴포넌트들

을 제거하여 경량화 하고, SOAP 기반의 웹서비스를 REST 형식으로 변환한 형태가 주류를 이루는

데, 여기서 소개하는 레퍼런스 아키텍쳐는 이 SOA와 REST 아키텍쳐를 기반으로 한다.

아키텍쳐 구조

이 레퍼런스 아키텍쳐 구조는 대용량 처리뿐만 아니라 대부분의 온라인 서비스 처리에서 사용되

는 구조이다. 이 구조를 기반으로 하여 요구 사항이나 시스템의 성격에 따라 변형은 있을 수 있

으나 기본적인 흐름이나 사상은 유사하다.

기본적으로 플랫폼 형태를 갖추고 있는데, User Interface에 해당하는 웹사이트나 모바일 애플리케

이션들이 클라이언트로써 API를 사용하여 서버 플랫폼과 통신하여 비지니스 로직을 처리하는 형

태이다.

서버쪽에는 트렌젝션을 처리하기 위해서는 크게 3가지 계층을 거치게 되는데, Access Layer,

Business Layer, Persistent Layer이다. 이 3가지 계층은 사용자 요청에 따른 비지니스 로직을 처리

하고 저장하는 역할을 한다.

Access Layer : Access Layer는 크게 두 가지 역할을 하는데, 외부로 부터 들어오는 사용

자 요청에 대해서 관문 역할을 하며, 외부 시스템과의 연동 역할을 한다.

Business Layer : Business Layer는 들어온 사용자 요청에 대해서 비지니스 로직을 처리하

여 응답을 내보낸다.

Persistent Layer : 마지막으로 Persistent Layer는 Business Logic에 의해 처리되는 또는

처리된 데이타를 저장하는 역할을 한다.

다음으로 시스템에 대한 관리와 운용을 맏는 OAM (Operation Administration Monitoring) 과 로

그등의 분석을 하는 Analysis Layer 계층으로 분리된다. OAM은 다른 이름으로는 OSS (Operation

Support System)이라고 불리며, Analysys Layer는 다른 이름으로는 BSS (Business Support System)

으로 불리기도 한다.

(1) Access Layer

Access Layer는 클라이언트로부터 User Request를 맨 처음으로 받는 계층이다. 들어온 User

Request에 대해서 사용자 인증(ID,PASSWORD 체크)와 권한 인증을 수행하여, 뒷단의 비지니스 로

직으로 전달하는 역할을 수행한다.

Reverse Proxy

Access Layer에는 보통 맨 앞단에 Reverse Proxy를 위치 시키는데, Apache httpd, nginx,

HAProxy등을 주로 사용한다. 웹서버의 역할을 하면서 static contents에 대한 서비스를 제

공하고, 필요에 따라서 HTTP Request에 대한 인증 역할을 수행한다. HTTP Header 내용을

보고 인증 처리를 하는데, 구현은 Reverse Proxy 서버에 module 형태로 plug-in 해서

HTTP request에 대한 인증 여부를 판단하여 request를 뒤로 넘길지를 검증한다. 이 인증

모듈은 사용자 인증 정보를 저장하고 있는 시스템에 접근하여 인증 가능 여부를 체크한

다.

인증은 이 Reverse Proxy 계층에서 수행할 수 도 있고, 경우에 따라서는 뒤의 ESB나

Business Component에서 직접처리할 수 도 있다. Reverse Proxy나 ESB에서 처리하는 경

우에는 HTTP request를 기반으로 인증 처리를 하는데, 중앙 집중적인 처리가 가능하다.

개별 Business Component에서 인증 처리를 하는 경우에는 분산형 인증 처리가 되기 때

문에, 하나의 Business Component에서 인증한 정보를 다른 Business Component에서도

인증이 되었음을 인지할 수 있어야 하기 때문에 이 경우에는 SSO (Single Sign On)이라는

기술을 이용한다. 예를 들어 A 웹시스템에 한번 로그인 되었다면 B 웹시스템에 로그인할

때 별도의 로그인이 필요 없이 서비스가 가능한 것이 이러한 SSO를 사용한 케이스이다.

네이버의 서비스의 경우를 보면 http://www.naver.com 에 로그인 한후에,

http://cafe.naver.com 이나 http://blog.naver.com 에 별도의 로그인 없이 인증이 가능한것

이 이 SSO 적용의 좋은 예라고 볼수 있다.

그리고, 뒷단 비지니스 로직을 처리하는 컴포넌트로 라우팅 하는 역할을 한다. 예를 들어

뒷단의 비지니스 로직이 Apache Tomcat 기반의 Servlet으로 구현되어 있다고 하면,

Reverse Proxy는 여러개의 Tomcat instance에 request를 balancing하는 역할을 수행한다.

대표적인 제품으로는 Apache나 NginX와 같은 웹서버 엔진을 사용하는 방법이 있고,

HAProxy와 같은 소프트웨어 proxy도 있다. Apache의 경우 워낙 오래된 엔진이기 때문에

안정성이 뛰어나고 SSL,Proxy,Cache,인증등 다양한 기능을 추가할 수 있다. Nginx는 러시

아에서 개발된 오픈소스로 Apache에 비해서 성능이 월등하게 뛰어나다 그러나 아직 약

간의 버그가 있는 부분이 있어서 사전에 충분히 체크를 해야 한다. HAProxy의 경우에는

성능이 가장 뛰어나지만 단순하게 load balancing 개념만을 가지고 있고 SSL이나 기타 부

가 기능을 지원하지 않기 때문에, 단순한 소프트웨어 load balancer 정도로 활용하는 것

이 좋다.

Enterprise Service Bus (Optional)

Enterprise Service Bus (이하 ESB)는 SOA 개념에서 만들어져서 내려온 개념이다. 근래에 서비스의

형태들이 대부분 REST 기반의 OPEN API로 기능을 제공하는 구조이고, 각 비지니스 컴포넌트가

하나의 시스템이 아닌 여러개의 시스템에 걸쳐서 이 OPEN API로 기능을 제공하기 때문에 이러한

OPEN API를 하나의 backbone을 통해서 공통된 기능 처리를 할 필요가 있다.

ESB는 시스템상에서 없어도 상관 없는 컴포넌트이지만, 디자인에 추가될 경우 아키텍쳐에 유연성

을 제공한다. ESB는 OPEN API 컴포넌트들의 맨 앞에 위치해서 single entry point의 역할을 하면

서 들어오는 open api request에 대해서 분석하고 여기에 “무엇인가”의 작업을 추가로 한다. 그러

면 이 “무엇인가”의 작업에 대해서 알아보도록 하자.

주요 기능

① Routing : Routing 기능을 들어오는 message의 내용에 따라서, 여러 서비스로 routing을

하는 것이다. 예를 들어서 [물품 주문] 이라는 OPEN API 서비스가 있을때, request에 들어

오는 주문서의 사용자 ID에 따라서, [일반 물품 주문] 이라는 OPEN API로 라우팅 하거나

VIP의 경우 [VIP 물품 주문]으로 라우팅을 할 수 있다.

또한 자주 사용되는 시나리오중의 하나는, 글로벌로 배포되는 시스템이고, 특정 기능을

가지고 있는 컴포넌트는 본사에만 위치한다고 하자. 이런 경우에는 각 지역에 ESB를 배

치하고 이 ESB가 해당 region에 그 기능이 없다하더라도 본사로 OPEN API request를 라

우팅하는 기능을 구현할 수 있다.

② MSG Transformation : ESB의 주요 기능중의 하나로, 들어오는 OPEN API의 request

message나 response message에 대한 변환 기능을 수행한다. JSON으로 OPEN API

request를 받았을때, 이를 XML로 바꿔서 뒷단의 OPEN API 서버로 포워딩 하거나 메세지

자체를 수정할 수 도 있다.

또한 통신사의 경우에 HTTP 프로토콜(헤더)에 특정 값을 hooking해서 넣는 경우가 있다.

HTTP Header 앞단에 4byte 정도의 값을 넣는다거나 하는 일이 있는데, 이런 경우 각 통

신사를 위해서 매번 서비스를 새로 만들 수 없다. ESB가 앞단에 있을 경우, 들어오는 ESB

메세지의 헤더나 IP를 보고 어느 통신사에서 들어오는지 판단한 후, hooking된 메세지들

을 정재해서 원래의 HTTP 형태로 메세지를 변환시킬 수 있다.

③ MEP Transformation : MEP는 Message Exchange Pattern의 약자로 Sync 방식의 호출,

Async 방식의 호출, Async 중에서도 Fire & forget,Publish & Subscribe와 같은 메세지 전

달에 대한 호출 방식을 정의한다. 몇가지 구체적인 MEP에 대해서는 본장 “Message

Queue & Async Transaction Processing”에서 설명한다.

ESB는 MEP에 대한 변환 작업을 수행할 수 있다. 예를 들어 HTTP 방식의 Sync(동기) 호

출을 지원하는 Open API 서버가 있다고 하자

이 서버가 사용량이 폭주하여 더이상 sync 형식으로 처리할 수 없고, async(비동기) 형식

으로 MEP를 바꾸고 싶다고 하자. 이런 상황에서 OPEN API 서버 자체를 다시 만드는 것

이 아니라 ESB가 중간에 있다면, 간단하게 MEP를 변환할 수 있다.

ESB 내에 Message Queue를 넣어서 클라이언트로 부터 request가 들어오면 바로 return

을 하는 fire & forget 방식으로 클라이언트에 서비스를 하고, ESB가 큐에 메세지를 가지

고 있다가 OPEN API Server가 허용하는 용량 내에서 호출을 하는 방식으로 변환이 가능

하다.

④ Logging : ESB단에서 Logging을 사용하면 좋은점은 ESB는 모든 OPEN API에 대한

request가 통과하는 관문의 역할을 하고 있기 때문에, 모든 OPEN API에 대한 추적이 가

능하다. ESB가 없다면 단일 Logging 포인트가 없기 때문에 문제가 생긴 request를 찾으려

면 각 OPEN API 서버들의 로그를 모두 뒤져야 한다. ESB에서 Logging을 하게 되면 모든

OPEN API에 대한 호출은 ESB를 거치기 때문에, client request가 어느 컴포넌트들을 거쳐

갔는지에 대한 end-to-end 추적이 가능하다. 그리고 차후 로그 분석등을 위해서 여러 분

산되어 있는 OPEN API 서버들로 부터 로그를 수집할 필요 없이 ESB에서만 수집하면 되

기 때문에 설계의 단순성이 증가 한다.

⑤ Authentication : Logging과 마찬가지로 인증과 권한 인가도 공통 기능이기 때문에 ESB에

서 처리하면 아키텍쳐가 단순해 진다.

여기에 더불어 내부 시스템간의 호출과 외부로부터의 호출을 구분해서 내부 시스템간의

호출은 인증을 제외할 수 있다. 아래 그림처럼 ESB로 부터 외부 인터페이스를 두개 오픈

할 수 있다. http://external.esb.com 과 http://internal.esb.com 으로 오픈했을때,

internal.esb.com의 경우 firewall (방화벽)으로 감싸서 내부에서만 호출할 수 있도록 하고

인증을 생략하며, external.esb.com으로 들어오는 요청의 경우 인증 인가를 거치도록 하면

내외부 호출에 대한 인증,인가를 해결할 수 있다.

※ Cross Cutting Concern : 앞의 REST 아키텍쳐에서도 설명하였듯이, Logging이나 Authenticaion과 같은 공통

적인 기능들은 ESB에서 처리하게 되면 비지니스 컴포넌트 개발시 순수 로직에만 전념할 수 있고, 이러한

공통 기능들을 넣었다 뺐다 선별 적용이 가능하기 때문에 아키텍쳐적인 유연성이 증대 된다.

⑥ Throttling : 또 다른 특징중의 하나가 Throttling이다. 들어오는 request에 대해서 일정 용

량 이상이 되면, alert을 보내거나 또는 최후의 경우에는 system 보호를 위해서 허용 용량

을 넘는 request를 blocking할 수 있다. 조금 더 고급 기능으로는 들어오는 request의 메

세지 내용 (사용자 id, priority 필드)에 따라서, request에 대한 처리 순서를 조정하여 중요

한 request를 우선적으로 처리할 수 있는 방법이 있다.

⑦ Orchestration : 마지막으로 orchestration인데, mash up과 같은 개념으로 생각하면 된다.

여러가지의 서비스들을 워크 플로우 형태로 모아서 새로운 로직을 만들어내는 개념이다.

예를 들어서 [주문] 이라는 서비스가 있는데, [주문]시 [포인트 부여],[택배 등록] 과 같은

부가 기능을 더해서 [택배 주문] 이라는 새로운 서비스를 만들어 낼 수 있다.

간략하게나마 ESB의 기능을 살펴 보았다. 앞에서 ESB의 장점이 유연성이라고 했는데, 이 유연성

이랑 시스템에 대한 변화가 필요할때, 시스템을 최소한의 수정을 통해서 그 변화 요구 사항을 수

용할 수 있는 특성이다. 사실상 없어도 되는 컴포넌트이기는 하지만 앞서 살펴보았듯이 있으면

많은 value를 제공해줄 수 있지만 반대로 모든 메세지가 ESB를 통과하기 때문에, 성능에 매우 민

감하며, 장애시 전체 시스템 장애로 발전할 수 있기 때문에 디자인과 구현 그리고 운용이 매우

까다로운 시스템이다. ESB 계층이 들어갈 경우 ESB에서의 소요 시간이 보통 100ms이하가 되야

크게 전체 성능에 문제를 주지 않는다. 메세지를 핸들링 하는 경우가 많기 때문에 주로 xquery나

xpath와 같은 XML 핸들링 프레임웍을 많이 사용하는데, 이러한 프레임웍은 구현 방법에 따라서

성능 차이가 매우 많이 나기 때문에 충분한 이해와 설계가 필요하다.

그러면 이러한 ESB를 활용할 수 있는 곳은 어디에 있을까?

OPEN API를 기반으로 하는 시스템에는 위와 같은 기능을 기반으로 사용 용도가 무궁무진하다.

근래에는 시스템간의 연동을 하는 EAI와 같은 시나리오에도 많이 사용된다. EAI란 시스템간을 연

결하고 MEP 변환이나 MSG 변환을 주요 목적으로 하기 때문에 ESB 적용이 가능하기도 하다. 단

이경우에는 legacy 시스템 연동을 위한 아답터 (SAP,Siebel,Tuxedo)가 필수적으로 필요하다.

또한 전세계에 걸쳐서 배포 (deployment)되는 시스템 (global roll out) 시스템의 경우 활용도가 매

우 많은데, 통신망이나 각 국가별 연계 시스템의 차이에 대한 대응성이나 앞서 routing 시나리오

에서 설명했던, 국가간의 message routing등에 활용이 가능하다.

Identity Management System

Identity Management System (이하 IDM 또는 IAM이라고도 부른다.)은 사용자 정보와 계정 관리,

시스템에 대한 인증(Authentication)과 권한 인가(Authorization)을 담당한다. 보통 웹사이트를 구

축할때, RDBMS에 사용자 정보를 넣어놓고, 웹페이지에서 인증을 한후 HTTP Session으로 인증을

하는게 일반적인 구축 구조인다.

시스템들이 많아지고 복잡도가 높아짐에 따라서, 이렇게 시스템 마다 단독적으로 계정 시스템을

구축하였을 경우 향후 통합에 문제가 생기는 경우가 많고, 권한과 사용자 정보가 여러 시스템에

걸쳐서 분산되서 저장되어 관리의 문제를 야기 하는 경우가 많다. 사실 이렇게 간단하게 구축을

하기는 하지만, 이 IDM 시스템은 전체 시스템에서 복잡도도 높고 규모도 큰 시스템이다. 일례로

오라클의 경우에만 3봐도 IDM 시스템 자체가 하나의 독립되어 있는 큰 suite 규모의 제품으로 나

와 있다.

IDM 시스템의 아키텍쳐는 다음과 같다.

User Profile

User Profile 컴포넌트의 사용자의 모든 정보를 기록한다. 또한 사용자의 가입이나 Validation,

Activation등이 모두 여기서 이루어 진다. 경우에 따라서는 복잡한 가입 프로세스가 있을 경우에

는 가입 프로세스를 처리하는 Workflow Engine을 내장하는 경우도 많다. 다양한 사용자의 정보를

저장하기 위해서 RDBMS를 기반으로 구현하는 경우가 많다.

User Credential

User Profile의 경우에는 인증,인가를 위한 정보 이외에 사용자에 대한 모든 정보를 가지고 있기

때문에, 빠른 응답을 필요로 하는 인증,인가에는 적절하지 않다. User Profile이 모든 정보를 체계

적으로 저장하기 위한 컴포넌트라고 한다면, User Credential 시스템은 단순히 인증과 인가를 위한

정보만을 저장하기 위한 저장소이다. LDAP이나 Active Directory(이하 AD) 등을 기반으로 구현하

는 경우가 많다. 특히 이 LDAP이나 AD는 계정 정보에 대해서 거의 표준 처럼 사용되기 때문에,

시스템이 LDAP이나 AD를 사용할 경우 다른 시스템과의 계정 통합이 쉽다.

Authentication & Authorization

사용자에 대한 인증과 인가 부분을 담당한다. 인증과 인가가 필요한 시스템과 통신을 하여, 중앙

집중화된 인증과 권한 관리를 수행한다. 해당 시스템에 AGENT가 설치되어 이 AGENT와

Authentication & Authorizaion 서버와 통신하게 된다. Java의 경우에는 JAAS(Java Authentication

Authorization Service)라는 표준을 통해서 이런 AGENT 아키텍쳐를 구현한다.

3 http://www.oracle.com/us/products/middleware/identity-management/overview/index.html

Provisioning

위의 Agent기반의 Authentication & Authorization이 신규로 개발되는 서비스에 처음부터 적용을

하는 방법이라면, Provisioning 컴포넌트는 기존에 독립적인 계정체계를 가지고 있는 시스템에 대

해서 계정 연동을 지원한다.

이미 구축되어 있거나 독립적인 계정 체계를 가지고 있는 경우에는 IDM의 Master User Profile에

서 계정이 생성되면, 각 서비스로 복제를 해주거나, 반대로 기존 시스템의 계정 정보를 Master

User Profile로 끌어와서 다른 Service로 복제하는 기능을 수행한다.

또한 외부 시스템간의 계정 연동도 지원한다.

SSO (Single Sign On)

Single Sign On은 또다른 계정 관련 통합 방법중의 하나인데, SSO 자체는 서로 독립된 시스템(여

러 웹사이트)들을 하나의 ID,PASSWORD로 통합 로그인하도록 해주는 시스템이다.

Integration Layer

대외 시스템 연계 또는 대내 시스템간의 연동을 맏는 시스템을 Integration System이라고 한다.

엔터프라이즈쪽에서는 EAI (Enterprise Application Integration)라는 아키텍쳐로 구현된다.

대내 거래는 내부 시스템간의 업무를 통합하는 패턴이다. 대부분 온라인성 업무가 주류를 이루게

된다. 인터넷 뱅킹에서 계좌 정보를 조회해온다던지, 당행 계좌간 이체를 한다던지와 같은 실시간

성 거래가 주류를 이룬다.

대외 거래는 기업간의 거래를 정의한다. 계열사로 재무 내역을 전송하거나 전송 받거나, 협력 업

체에 물품을 주문한다거나와 같은 업무가 주류를 이루며, 온라인성 업무와 디퍼드거래 그리고 배

치성 거래들이 섞여서 구성된다. 대외 거래의 특징은 기업간 거래이기 때문에 분산 트렌젝션(XA)

등을 이용한 트렌젝션 보장이 불가능하기 때문에 오류시 양쪽의 트렌젝션정보를 비교할 수 있는

거래로그를 저장하는 것이 중요하다.

또 다른 관점에서는 B2B 거래에 있어서는 별도의 한정된 개수의 폐쇄망(X.25, TCP)을 사용하는 경

우가 있기 때문에, 회선이 1~2개 인데, 서버가 >2 일 경우 회선이 연결된 서버로 거래 요청을 라

우팅 하는 기능과 회선의 상태를 확인하는 기능등이 중요하다.

BATCH거래는 대용량의 데이터를 송신 시스템에서 수신 시스템으로 전송하는 요건인데, 다른 업

무 시스템간의 거래 정보를 맞추기 위한 BATCH거래와 정보계(데이터를 분석하여 경영에 필요한

리포트를 뽑아 내는 Warehouse나 BI성의 업무) 두 가지 형태로 분리된다. 전자의 경우 운영 데이

타로 사용되는 데이터에 대한 연계이기 때문에, 전달 보장 요건이 매우 중요하고(경우에 따라 XA

를 사용할 수도 있음) 후자의 경우는 분석 데이터이기 때문에 전달 보장 요건은 그리 중요하지

않다.

BATCH거래의 경우 보통 ETL 솔루션을 사용하기도 하는데, ETL 솔루션의 경우 XA기반의 전달 보

장 요건이 없기 때문에, 위의 사례중의 후자 (정보계)에는 적절하지만 운영 데이터를 전송하는 과

정에는 EAI 솔루션이 더 적절하다고 볼 수 있다.

이런 3가지 기능적인 통합을 지원하기 위한 EAI 시스템에 대한 아키텍쳐는 다음과 같다.

인터페이스

인터페이스 모듈은 EAI의 가장 기본적인 아키텍쳐 모듈로 송수신 시스템을 통합 시키는 부분에

대한 아키텍쳐이다.

1) Inbound

Inbound는 송신 시스템과 연동되어 요청을 받고 응답을 송신 시스템에 보내는 역할을 한다.

Inbound는 크게 두가지 모듈로 구성된다.

Adapter

아답터는 다양한 플랫폼으로부터 메시지를 읽어드리는 Entry Point의 역할을 한다. 연동 시스템마

다 각각의 아답터가 정의 되어야 한다.

메시지 변환

Adapter에 의해서 요청된 전문(메시지)는 각 연동 시스템의 플랫폼에 따라서 각각 다르다. FML이

나 XML, 또는 TEXT형태의 전문, Binary등 여러가지 형태가 될 수 있으나, EAI내부에서 처리하기

위해서 이런 전문형태를 공통적인 데이터 구조로 변환한다. 흔히 상용 솔루션에서는 메시지 처리

의 유연성을 가지고 가기 위해서 XML을 사용하고, In-House 개발의 경우 성능의 최적화를 위해

서 HashTable형태의 Java POJO Object를 사용하기도 한다.

2) Mediation

Mediation은 입력된 메시지를 가공하고 중계하는 EAI의 핵심적인 기능 부분이다.

Routing

Routing은 입력된 메시지를 메시지의 내용(헤더나 인터페이스 정보)에 따라서 적절한 수신 시스

템으로 Routing하는 역할을 수행한다. 이 과정은 1:1 Routing이 될 수 도 있지만 N:1, 1:N등 다양

한 관계로 Routing을 수행할 수 있어야 한다.

Mapping

입력된 전문을 수신 시스템에서 요구하는 형태로 맵핑하는 작업을 수행한다. 필드간의 맵핑이나

간단한 메시지에 대한 변환을 수행한다.

MEP (Message Exchange pattern)

이부분에서 MEP에 대한 처리도 수행한다.SYNC나 ASYNC, 디퍼드성 거래에 대해서 JMS 와 같은

큐잉을 이용해서 MEP를 구현한다.

3) Outbound

Inbound와 마찬가지로 처리가 끝난 메시지를 수신 시스템의 플랫폼의 Native 메시지 형태로 변

환하여 Adapter를 통해서 수신 시스템에 전달한다.

모니터링 및 장애 관리

인터페이스 아키텍쳐가 가장 기본적인 연계에 관련된 아키텍쳐라면 EAI 아키텍쳐상의 매우 중요

한 요소중의 하나가 거래 추적과 에러 처리 방식이다.

1) 거래 로그

거래 로그는 EAI 시스템의 장애시 송수신 시스템과 거래 내용을 맞춰서 이를 복구하는데 사용한

다. 거래 로그에 사용되는 거래 ID는 전사 표준 전문의 헤더에 정의하는 것이 일반적이고 이 거

래 ID는 송신에서 수신 시스템까지 하나의 공통된 ID를 사용해야 한다.

거래 로그에 대한 접근 방식은 크게 저장 장소와 저장 방식에 대해서 고민해야 하는데, 데이터

저장 장소는 FILE과 DB 두가지를 선택할 수 있다. FILE의 경우 비교적 IO성능이 빠르고, DB 장애

에 대해 의존성이 적다는 장점을 가지고 있지만 반대로 거래 추적을 할할 때 일일이 FILE을 뒤져

야 하는 단점이 있고, DB의 경우 특정 거래를 찾거나 조건으로 검색을 하기는 용이하지만 별도의

DB하드웨어를 필요로 하고, DB 장애에 독립적이지 못한 문제를 가지고 있다.

이를 보완하기 위해서 LOG를 WRITING하는 방식에 대해서 고려할 수 있는데, JMS 서버를 이용하

여 비동기적으로 LOG를 WRITING하는 방법을 고려할 수 있다. 이 때 JMS의 메세지를 FILE에 저

장할지 메모리에 저장할지도 고려해야 하는데, 업무상 감사(AUDIT)요건이 있는 중요한 로그는

JMS File store를 이용하여 저장하고 중요하지 않은 로그는 JMS Memory Store를 이용해서 저장하

는 방법이 있다. (Memory Store의 경우 성능적 우위에 있지만, JMS 서버가 RESTART될 때 메모리

상의 데이터가 유실되는 문제가 있다.)

거래로그는 EAI의 필수적인 요건중에 하나이지만 IO를 유발하기 때문에 성능에 가장 큰 영향을

주는 부분으로 세밀한 설계와 검증 과정을 필요로 한다.

2) 에러 처리 로직 (Error Hospital)

에러 처리 로직은 모니터링 요건과 더블어 EAI의 또다른 필수요건이다.에러 처리 로직의 요건은

장애 감지, 장애 원인 리포팅, 장애 해결 3단계로 이루어 진다.

모든 종류의 장애를 신속하게 감지해야 한다. 특히 B2B거래의 경우 회선 장애에 대한 감지 능력

이 보강되어야 하고, 장애가 발생하였을 때 장애 원인을 추적할 수 있도록 그 내용이 리포팅 되

어야 하고, 장애 내용에 대해서 해결할 수 있는 절차를 갖추어야 한다.

장래 해결 방식은 여러가지로 분리할 수 있는데 장애에 대한 처리 정책을 Fault-Policy라 하고 인

터페이스마다 정의하여 인터페이스별로 장애를 처리할 수 있도록 한다.

이렇게 장애가 발견되고 리포팅이 되면 모든 장애 내용을 한곳에 모아서 위에서 언급한 Fault-

Policy에 따라 처리하는데 모든 장애가 모이는 곳을 Error-Hospital이라고 정의한다.

3) 장애 처리 정책

앞에서 정의한 에러 처리 로직 (Error-Hospital)에 모인 장애 들은 장애 처리 정책에 따라서 처리

가 되는데, 일반적으로 크게 아래와 같이 4가지 정책으로 정의할 수 있다.

Policy Description Note

Ignore Simply ignore the fault and purge message.

Report Report the fault. Optionally send notification message (Email,IM,SMS etc)

Retry Automatically retry the transaction with specified time after specified sleep time

After failing all of retry, next error handling policy definition is required.

Manual handling

Report the fault and let user select policy described above

무시하거나(Ignore), 장애 내용을 관리자에게 알리거나 (Report), 자동으로 재시도 하거나 (Retry),

또는 Work list등에 추가하여 관리자가 에러 처리를 수동으로 하도록 하는 방식이다. 뒤에서 설명

되는 비동기 처리 패턴에서의 에러 핸들링에서 조금더 자세하게 설명한다.

인프라 기능

거래이외에 공통적으로, 처리해야 하는 기본적인 기능들이 있다.

1) 트렌젝션 처리

EAI 프로젝트에서 통상적으로 10~30%가 XA 기반의 분산 트렌젝션 처리를 사용하는 경우가 있다.

양쪽에 거래에 대한 장애시 거래 데이터가 틀려지는 것을 방지하기 위해서 XA를 사용한다. 단

XA 사용은 시스템의 복잡도를 높이고 높은 수준의 테스트가 필요하기 때문에, XA 거래는 되도록

이면 사용하지 않는 것이 좋다.

2) 동적 배포

EAI 시스템은 24 x 7 으로 무정지로 운영이 되기 때문에 새로운 인터페이스가 추가 되었을때 EAI

시스템을 정지하지 않고 인터페이스 배포가 가능해야 하며, 장애가 난 인터페이스가 다른 연계

인터페이스에 영향을 미치지 않도록 내릴 수 도 있어야 한다. 인터페이스에 대한 동적 배포 기

능은 EAI 시스템의 운영 관점에서의 필수요소이다.

(2) Business Layer

1) Transaction Processing (Synchronous)

Transaction Processing은 비지니스 로직을 처리하는 계층이다. Access Layer를 통해서 들어온 요청

에 대해서 로직을 처리해서 응답을 하는 역할을 수행한다.

클라이언트가 request를 보내고 (1), 서버쪽의 비지니스 컴포넌트가 요청에 대한 처리를 한다(2).

request에 대한 처리가 끝나면 클라이언트에 response를 보낸다(3). response를 받을 때 까지 클

라이언트가 기다리고 있는 호출 형태를 Synchronous (동기식) 호출이라고 하는데, 일반적인 시스

템의 호출 방식은 이런 Synchronous 방식을 사용한다.

우리가 일반적으로 사용하는 RedHat JBoss Server나 Apache Tomcat, Oracle WebLogic과 같은

Application Server가 Transaction Processing에 해당한다.

SN(Shared Nothing) 아키텍쳐

이런 application server 기반의 동기처리 아키텍쳐에서 확장성과 안정성을 보장하기 위한 아키텍

쳐가 SN 아키텍쳐 (Shared Nothing)이다.

SN 아키텍쳐란, 분산 처리 시스템을 구성하는 여러개의 노드가 서로간의 종속성을 가지지 않고

독립적으로 작동하는 아키텍쳐로, 종속성이 없기 때문에, 이론적으로 노드를 무제한적으로 늘릴

수 있으며, 노드의 수에 비례하여 전체 시스템의 용량이 비례해서 늘어나며, 특정 노드의 장애가

전체 시스템에 영향을 주지 않는 아키텍쳐를 이야기 한다.

여기서 노드간의 종속성을 발생 시키는 것이 노드간의 공유 정보, 즉 상태 정보(State)이다. 웹 시

스템에서는 EJB의 Stateful EJB의 상태 정보나, HTTP Session 정보가 대표적인 사례가 된다. 이러한

상태 정보는 application server의 클러스터링 기능을 이용하여, 각 노드간에 복제가 되는데, 이 복

제가 종속성을 유발한다. 이러한 공유 상태 정보를 application server 단에서 제거하면 Shared

Nothing Architecture를 구현할 수 있다.

그런데, 비지니스 로직상에 서버들이 공유하는 정보가 있을 수 밖에 없다. 상태 정보를

application server 에 저장하지 않는 방법은 무엇이 있을까? 다른 계층에 상태 정보를 저장하면된

다. 가장 쉽게 생각할 수 있는 부분이 클라이언트에 상태 정보를 저장하는 방법으로, 웹에서는 전

통적으로 cookie 를 사용하는 방법등이 있다. 그러나 cookie는 저장할 수 있는 정보의 양이 한계

가 있기 때문에 별도의 상태 정보를 저장할 수 있는 구조가 필요한데, application server 이외의

계층인 data base나 memcached와 같은 캐쉬 또는 뒤에 설명할 data grid 계층을 사용하거나

NFS와 같은 공유 파일 시스템 또는 RDBMS와 같은 저장소를 이용할 수 있다. 사용자를 식별하기

위해서 Cookie등을 이용하여 클라이언트쪽에 사용자 식별자 를 저장하도록 하고, request를 보낼

때 마다 이 사용자 식별자를 같이 보내서, 그것을 키로 하여, 서버쪽에 상태 정보를 저장한 곳에

서 상태 정보를 조회해오면 된다.

보상 트렌젝션 (Compensation Transaction) 관리

TBD

2) Message Queue & Async Transaction Processing

Request를 처리하는 방법에는 앞서 설명한 동기식 방식도 있지만, 비동기식 방식도 있는데, 동기

방식이 request를 보낸후, 처리가 된후 response가 오는 방식이라면, 비동기 방식은 request를 보

낸후, client는 응답을 받지 못한 상태에서, 응답을 기다리지 않고 로직을 진행한다. 서버로 전달된

request는 나중에 처리가 되며, 경우에 따라서 client로 응답이 전달된다. (응답을 전달하지 않는

경우도 있다.) 동기식 방식과 비동기식 방식의 가장 큰 차이점은 동기식 방식은 응답이 올때 까지

client가 대기하는 것이고, 비동기식 방식은 request만 보내놓고, 응답이 오는 것과 상관 없이

client는 대기 없이 다음 로직을 수행한다.

이러한 비동기식 패턴 구현은 일반적으로 message queue라는 것을 사용한다. 이 message queue

는 들어온 request를 쌓아놓는 임시 공간으로, 쌓여 있는 request message는 뒤의 business logic

에 의해서 처리 된다

IBM의 MQ, 자바 진영에서 사용했던 JMS (Java Messaging Service), Rabbit MQ등이 이러한 큐서비

스에 해당한다. 비지니스 컴포넌트는 이 큐에 쌓여 있는 메세지를 순차적으로 읽어서 처리를 하

는 패턴을 띄게 된다.

에러처리

이러한 비동기식 구현에서 가장 중요하게 고려해야 할 사항이 전달된 request 메세지가 잘 처리

되었냐이다. Client는 단순하게 request를 보내고 response를 받지 않기 때문에 해당 request가 제

대로 처리되었는지 보장할 수 있는 방법이 없다. 그래서 이러한 비동기 구현에서는 에러처리 부

분에 가장 신경을 써서 디자인을 해야 한다.

비지니스 컴포넌트에서 메세지 처리중 에러가 났을때, 해당 메세지를 Error Queue라는 재처리용

Queue로 전달한다. 메세지의 에러 처리 정책을 정해서 에러를 어떻게 처리할지를 지정할 수 있

는데, 일반적으로 비동기 메세징 처리에서는 다음과 같이 크게 4가지 정책을 사용한다.

① Retry

메세지 처리중 에러가 발생하였을때, 다시 재처리를 시도하도록 하는 방법이다. 메세지를

처리하는 비지니스 컴포넌트가 일시적인 장애 (네트워크 문제,리소스 부족등)일 경우에는

효율 적으로 사용할 수 있다. 재처리를 할때는 반드시 최대 재처리 횟수를 지정해야 한

다. (통상적으로 3~5번 정도) 그리고 재처리를 할때, 에러 발생후 바로 재처리를 시도하

면 같은 원인으로 같은 에러가 날 수 있기 때문에 일정 시간을 기다렸다가 다시 재처리

를 하는 것이 좋다. 이 기다리는 대기 시간은 재처리 횟수에 비례해서 늘려주는게 좋은

데, 예를 들어 첫번째 에러가 났을 경우 1초 후 재처리 시도, 두번째는 5초후, 세번째는

30초후 식으로 늘려주면, 비지니스 컴포넌트가 장애에서 복구될 때 까지의 충분한 시간

을 벌 수 있다.

② Ignore

에러가 난 메세지의 경우 무시를 하고, 메세지를 없애 버리는 방식이다. 중요하지 않은

로그 정보를 저장할때와 같이 메세지 유실이 허용되는 경우에만 사용한다.

③ Notify

메세지 처리중 에러가 발생하였을 경우, 관리자에게 Email, SMS등을 이용하여 통보하여,

관리자가 에러에 대한 후처리를 할 수 있도록 해주는 방식

④ Human Interaction

에러가 발생하였을때, 자동으로 처리 하지 않고, 관리자가 직접 처리할 수 있는 User

Interfce를 제공한다. 관리자가 에러가 난 메세지를 확인하고, retry를 할지, Ignore를 할지

등을 결정하도록 한다.

에러 재처리 부분이 복잡하거나 규모가 큰경우, 이런 메세지에 대한 에러 처리를 별도의 컴포넌

트로 구현하기도 하는데, 이러한 컴포넌트를 “Error Hospital”이라고 부른다. “Error Hospital”을 처

리중 에러가 난 메세지를 모아서, 다양한 에러 처리 정책에 따라서 재처리를 할 수 있는 기능을

갖는다.

비동기 처리 패턴

비동기 메세지 패턴은 앞서 중간에 큐를 둬서 구현하기 때문에, 여러가지 메세지 전달 패턴을 구

현할 수 있다. 몇가지 대표적인 패턴에 대해서 알아보자

Fire & Forget

메세지 큐를 사용하는 패턴중에 가장 일반적인 비동기 호출 패턴으로, 클라이언트가 호출한후, 큐

에 메세지가 제대로 들어갔으면, 메세지의 처리 결과에 관계 없이 응답을 기다리지 않고 바로 리

턴한다. 큐에 저장된 메세지는 비지니스 컴포넌트에 의해서 나중에 처리된다

Publish/Subscribe

메세지 큐에 구독자 (Subscriber)를 등록하면, 클라이언트에서 보낸 하나의 메세지가 등록되어 있

는 모든 구독자에게 전달 되어 처리된다. 1:N 관계의 비동기 처리를 구현하고자 할때 사용된다.

JMS의 Topic이 이에 해당한다.

Routing

Routing 패턴은, 큐에 저장된 메세지를, 조건에 따라 특정 Business Component 로 라우팅하는 기

능이다. Pub/Sub 처럼 큐에 여러개의 Business Component 가 붙기는 하지만, 특정 메세지는 조

건에 따라서 특정 Business Component 한개에만 전달이 된다.

Call Back

메세지 큐를 이용한 비동기 패턴은 클라이언트가 메세지 처리에 대한 결과 응답을 받을 수 없다

고 설명했었는데, 예외적으로 Call-Back 패턴이라는 것을 사용하면, 메세지 처리에 대한 응답을 받

을 수 있다.

클라이언트가 request를 보내서 메세지큐에 저장한후에, Call-Back 패턴도 다른 비동기 패턴과 마

찬가지로, 응답을 기다리지 않고 다음 로직을 진행한다. (그래야 비동기 패턴이니까는)

비지니스 컴포넌트에서 처리가 끝나면, 서버는 다시 클라이언트에 처리가 끝났다는 응답과 함께

처리 결과 (response) message를 보낸다. 이 때 클라이언트가 응답 메세지가 올때 까지 기다리는

것이 아니고 비지니스 로직을 수행하고 있기 때문에, 서버가 응답 메세지를 보내면 Event 방식에

4 의해서 응답 메세지를 처리하는 Event Handler를 호출하여 응답 메세지를 처리하도록 한다.

Call Back 방식의 호출은 응답 메세지를 받기 위해서 몇가지 부가적인 정보가 필요한데, Call Back

주소와 Correation ID라는 것이다. Call Back 주소는 서버가 메세지를 다 처리한 후에, 클라이언트

에게로 응답을 보낼때, 클라이언트의 IP주소와 포트이다. 그리고 Correation ID라는 것이 특이한데,

클라이언트에서 10개의 request를 서버에 보냈다고 가정하자, 서버가 메세지를 처리한후에 Call

Back을 이용하여 응답을 보낸경우, 해당 응답 메세지가 10개의 request 중 어느 request에 대한

4 Event Handler 방식은 윈도우즈에서 마우스 클릭 등의 이벤트가 발생하였을때와 같이 이벤트

발생시 처리하는 방법으로, 일반적인 프로그래밍 모델이 코드를 순차적으로 수행하는데 반하여,

이벤트 방식은, 특정 이벤트가 발생하면, 해당 이벤트를 처리하기 위해서 미리 등록된 Event

Handler를 호출하여 이벤트에 대한 처리를 진행한다.

응답인지 식별할 수 없다. 이를 식별하기 위해서 request 에 Correation ID라는 것을 실어 보낸후

응답에 이 ID를 다시 실어서 리턴하는데, 이 Correation ID를 통해서 Call Back 응답 메세지가 어

느 request에 대한 응답 메세지인지를 식별할 수 있게 한다.

3) Data Grid

Data Grid는 자바의 HashTable과 같이 Key/Value로 되어 있는 메모리 기반의 저장공간이다. 단

application server와 별도의 process로 동작하고, 자체적인 클러스터링 기능을 가지고 있기 때문

에 수평적인 용량 확장이 가능하다. Oracle Coherence, 오픈소스로는 memcached, Redis 등이

DataGrid의 대표적인 제품군이다.

Datga Grid는 application server간의 상태 정보를 공유하기 위해서 사용된다. 앞서 application

server의 SN(Shared Nothing) 구조에서도 설명하였듯이, 본 아키텍쳐에서 application server는 상

태 정보를 공유하지 않고 별도의 계층에서 공유하도록 설계하였다. 그 별도의 계층 중의 하나가

이 Data Grid 계층이 된다.

Data Grid 계층을 통하여 상태 정보를 공유할 수 있다. (application server를 위한 공유메모리로

생각하면 된다.)

Data Grid에 대한 확장성은 Data Grid 자체가 클러스터링 기능을 이용하여, 수평적인 확장성

(Horizontal Scalability)을 제공한다.

Data Grid의 또 다른 장점중의 하나는 메모리 용량에서 조금 더 자유로와 진다는 것이다.

Application server내의 HTTP session 등에 상태 정보를 저장하게 되면, application server의 메모

리를 사용하게 되기 때문에 일정 수준의 한계를 가지게 된다. 일반적으로 Java 기반의 application

server의 적정 메모리 크기가 1.5G인것을 감안하면, 이를 넘어서는 상태 정보를 저장하기는 힘들

다. 그러나 Data Grid를 사용하게 되면, application server 밖에 상태 정보를 저장하기 때문에

application server의 메모리 제약에서 자유롭고, Data Grid내에 메모리를 확장하거나 Node를 추가

하면 전체 메모리 용량을 늘릴 수 있기 때문에 더 큰 상태 정보 저장 공간을 사용할 수 있다.

※ Data Grid에 해당하는 제품들은 기본적으로 Key/Value 기반의 데이타 저장 기능을 가지고 있지

만 제품에 따라서 매우 다양한 추가 기능들을 가지고 있다. Oracle Coherence의 경우 SQL 과 유

사한 쿼리 기능을 제공하기도 하고, JMS와 같은 여러가지 프로토콜로 접근이 가능하다. Redis의

경우에는 Key/Value 뿐만 아니라 JSON과 같은 Document 형태 데이타 저장은 물론이고, Sorting

등의 다양한 기능을 제공한다. 본 대용량 아키텍쳐의 다른 컴포넌트들 보다 제품간의 기능 편차

가 매우 크기 때문에, 사용전에는 반드시 제품에 대한 기능 및 아키텍쳐 비교를 통해서 솔루션을

결정하기 바란다.

4) Working Space

Working Space는 request에 의해서 생성되거나, 업로드된 파일을 최종 저장소에 저장하기 전에

작업을 목적으로 임시로 저장하는 장소이다. (Temporary Directory)

예를 들어 동영상을 업로드 했을때, 최종 저장소에 저장하기 전에 Thumnail과 메타 정보를 추출

하거나, 이미지를 업로드 하였을때, Thumbnail 추출 및 포맷 변환등을 수행할 수 있다.

이러한 임시 저장소는 저장의 안정성 보다는, 처리속도에 우선을 둔 파일 시스템을 사용한다.

Gluster FS와 같은 NFS 형태의 공유 파일 시스템을 사용하거나 필요에 따라서는 SAN 기반의

attach가 가능한 스토리지를 사용한다.

(3) Persistent Layer

Persistent Layer는 처리가 끝난 데이타를 저장하는 공간이다. 전통적으로 관계형 데이타 베이스

(RDBMS), 파일 시스템등을 주로 사용하며, 인증을 위한 사용자 정보와 같이 개수는 많고, 레코드

별 용량은 적으며, 데이타 구조가 디렉토리 구조일 경우에는 LDAP을 사용한다.

그리고 마지막으로 근래에 들어서 BIG DATA와 함께 더불어 서비스 업체를 중심으로 등장한

NoSQL 등이 있다. NoSQL은 대용량의 데이타를 Key/Value 형태의 단순한 구조로 저장하기 위한

저장소로, 성능과 대용량 확장성에 촛점이 맞추어져 있다. 이 NoSQL에 대해서는 6장에서 조금

더 자세하게 설명하도록 한다.

Persistent Layer에 해당하는 솔루션들에 대해서는 전통적으로 사용해왔던 것이기 때문에, 대부분

익숙하다. 그래서 각자의 솔루션등에 대한 소개 보다는 , 아키텍쳐 설계시에 고려할 수 있는 부분

에 대해서 설명한다.

RDBMS

RDBMS는 크게 request를 바로 처리하는 트렌젝션 처리용의 OLTP(On-Line Transaction Processing)

성과, 데이타를 모아서 분석하고 리포팅하는 OLAP(On-Line Analytical Processing) 두가지로 분리

된다. 여기서 설명하는 RDBMS는 OLTP성의 데이타 베이스 이다.

RDBMS는 2차원 테이블 구조의 데이타를 KEY 값을 중심으로 여러개의 컬럼으로 저장되며, 저장

된 각각의 로우(행)은 다른 테이블의 로우와 관계를 가질 수 있다.

RDBMS를 이용한 설계를 하는데, 고려할만한 아키텍쳐는 성능 향상을 위한 Query Off Loading과,

Sharding이라는 기법이 있다.

Query Off Loading

Query Off Loading은 DB의 성능 향상을 위한 기법이다. (정확하게 이야기 하면, 처리량을 증가

시키기 위한 설계 기법이다.) DB 트렌젝션의 70~90%는 대부분 READ 성이 많다. 나머지 10~30%

가 Create/Delete/Update와 같은 트렌젝션인데, 이 Update 성 트렌젝션과 Read 트렌젝션을 분리

하는 기법이다.

먼저 Master DB에는 쓰기(Update)만을 허용하고, Master DB의 내용을 중간의 Staging DB라는 곳

으로 복사한다. 이 Staging DB는 복제된 내용은 N개의 Slave DB로 복제한다.

애플리케이션은 Master DB에만 쓰기를 하고, 읽기는 Slave DB에서만 수행한다. 이를 위해서

Application을 DB에 대한 쓰기 로직과 읽기 로직을 분리해서 구현해야 하며, 이 분리된 로직은

쓰기 DB로 접근하기 위한 DB Connection과 읽기 DB로 접근하기 위한 DB Connection을 이용해

서 접근한다. 일반적으로 application server에서는 이러한 Connection을 Connection Pool 을 이용

해서 관리 하는데, 읽기 DB의 경우에는 N개의 Slave DB로 부터 읽기 때문에, Application이 이 N

개의 Slave DB에 대한 요청을 Load Balacing을 해야 한다. 또한 특정 Slave DB 장애시 다른 Slave

DB 인스턴스에 접근을 할 수 있도록 HA (High Availability) 기능을 제공해야 하는데 Connection

Pool 자체에 Load Balancing과 HA 기능을 가지고 있는 Connection Pool을 이용하거나 또는 JDBC

Driver와 같이 DBMS용 Driver 자체에 Load Balancing과 HA 기능을 사용한다.

Master DB와 Slave DB는 각각 쓰기와 읽기를 위해서 접근된다고 하지만 그렇다면 중간에 Staging

DB의 역할은 무엇일까? Staging DB는 Slave DB로 복제하기 위한 중간 경유지 역할을 한다. 다수

의 Slave DB로 복제를 해야 하기 때문에, 이에 대한 부하가 크다. 만약 Master DB에서 Slave DB

로 바로 복제를 하게 되면, Master DB가 쓰기 트렌젝션 이외에 복제에 대한 부분을 처리해야 하

기 때문에 성능 저하를 유발할 수 있다. 이를 방지 하기 위해서 중간에 Staging DB를 넣는 것이

다.

그렇다면 Master Staging Slave DB로의 복제는 어떤 기술을 이용할까?

CDC (Change Data Capture)라는 기술을 이용한다. DBMS들은 공통적으로 Create/Update/Delete와

같은 쓰기 관련 작업을 수행할때, 데이타를 실제로 저장하기 전에 먼저 해당 작업에 대한 request

를 BackLog라는 곳에 저장한다. (BackLog는 일반적으로 Local 파일이다.) 이는 실제로 데이타를

쓰기전에 장애가 났을때, restart하면서 이 BackLog를 읽어서 복구를 위한 용도로 사용이 된다.

CDC는 이 Back Log를 이용해서 데이타를 복제하는데, Source DB로 부터 이 Back Log를 읽어서,

복제를 하고자하는 Target DB에 replay 하는 형식이다.

즉 Source DB에서, insert A,B,C를 하면 이는 모두 Back Log에 기록되고, 이를 읽어서 Target DB에

서 다시 replay – insert A,B,C를 순차적으로 수행하는 것이다.

대표적인 CDC 제품으로는 Oracle의 Golden Gate, Quest의 Share Flex가 있고, 오픈소스 제품으로

는 Galera5라는 제품이 있다.

Sharding

Sharding은 데이타베이스의 용량 한계를 극복하기 위한 기술이다. 클러스터링 기술을 사용하더라

도 데이타 베이스는 물리적인 용량 한계를 갖는 경우가 많다. 수년 전에만 해도, 하나의 서비스에

수천만명이 사용하는 서비스는 없었다. 인터넷의 발전등에 따라서 사용자가 급격하게 늘어나고

저장해야 하는 데이타의 양도 급격하게 늘어났다. 데이타 베이스 시스템은 이러한 용량 증가를

따라가지 못했다. 그래서 Sharding이라는 아키텍쳐가 유행하기 시작했는데, Sharding은 쉽게 말해

5 http://codership.com/products/galera_replication

서 데이타를 여러개의 데이타 베이스에 나눠 담는 방법이다.

하나의 데이타 베이스가 10억개의 레코드만 저장할 수 있다면, 100억개의 데이타를 저장하려면

10개의 데이타 베이스를 사용하여 분산 저장하는 방법이다. 이 각 10개의 데이타 베이스를 Shard

라고 한다.

Sharding은 데이타를 분산 하는 방식에 따라서 Vertical(수직적) Sharding과 Horizontal(수평적)

Sharding으로 나뉘어 진다.

Vertical Sharding은 연속된 데이타에 대해서 범위별로 데이타를 나누는 방법이다. 아래 예는 연령

대 별로, 데이타를 나누는 예이다.

Figure 8 Vertical Sharding

다음으로는 Horizontal Sharding이 있는데, 이는 연속된 키가 아니라 “Category”와 같은 종류에 따

라서 데이타를 수평적으로 분리하는 방법이다.

Figure 9 Horizontal Sharding

데이타를 분산 저장할때 위와 같이 meaningful한 데이타를 사용할 수 있는데, 이 경우에는 데이

타의 몰림 현상이라는 것이 발생할 수 있다. 위의 Vertical Sharding을 예를 들어보면, 해당 서비스

를 사용하는 연령층이 20대와 30대에 편중되어 있다면, 20,30대 Shard에는 데이타가 몰리게 되고,

부하도 더 많이 받게 될 것이다. 그래서 이렇게 meaningful한 데이타를 KEY로 사용할 경우에는

데이타 몰림현상을 고려하여 각 Shard 서버의 성능을 비 대칭적으로 설계할 수 있다. 즉 20,30대

의 Shard에는 더 좋은 CPU와 메모리를 갖는 서버를 배치하는 방법이 대안이 된다.

만약에 데이타 편중 현상에 대한 예측이 어려운 경우에는, meaningful 하지 않은 KEY를 사용해서

Sharding을 할 수 있다. 10개의 Shard를 갖는 데이타 베이스에서, 사용자 레코드를 등록할때, KEY

를 Sequence를 이용해서 순차적으로 부여한다. 첫번째 사용자는 1, 두번째는 2, 다음은 3,4,5,6..

등으로.. 그리고 이 ID를 10으로 나눈 나머지 값을 가지고 Shard를 결정하면, 데이타를 모든

Shard에 걸쳐서 골고루 분산 시켜 배치 할 수 있다. (Hash 방식)

Sharding을 구현하는 방법은 DBMS 단에서 Sharding을 지원 하는 방법과, OR Mapper와 같은 DB

접근용 프레임웍에서 Sharding을 제공하는 방법 그리고, Application Code 자체에서 지원하는 방

법 세가지가 있다.

DBMS 단에서 제공하는 방법으로는 Microsoft SQL Server Azure의 federation model6이나 RDBMS

는 아니지만 NoSQL중 MogoDB의 경우 1.6부터 Sharding을 DB단에서 지원한다.

프레임웍단에서는 자바의 Hibernate의 경우 Hibernate Shard7라는 기능을 통해서 Sharding을 지

원한다. 프로그래밍 언어인 Grail의 경우에도 자체 프레임웍에서 “Grails Sharding Plug in”을 통한

Sharding 을 지원한다.

직접 Application에서 구현할 경우 Key에 따라서 DB Instance를 선택적으로 고를 수 있는 구조를

가져야 하며, 특히 다른 Shard간의 데이타 Join등은 불가능하기 때문에, 구현상에 이에 대한 고려

가 필요하다.

Sharding 이라는 것이 데이타를 분산 저장함으로써 시스템의 전체 용량을 늘릴 수 는 있지만

Application의 복잡도가 올라가고, 데이타 편중 방지등 여러가지 요소를 고려한후에 설계, 반영해

야 한다..

File System

파일 시스템은 우리가 익숙한 일반적인 파일 시스템이다. 각 프로그래밍 언어의 API를 이용해서

접근을 하지만, 실제 하단의 하드웨어나 파일 시스템등은 매우 차이가 많다.

먼저 일반적인 파일 시스템의 스택 구조를 보자.

6 http://social.technet.microsoft.com/wiki/contents/articles/2281.federations-building-scalable-

elastic-and-multi-tenant-database-solutions-with-windows-azure-sql-database-en-us.aspx

7 http://www.hibernate.org/subprojects/shards.html

① SDK : SDK는 프로그래밍 언어에서 지원되는 파일 시스템 접근용 API이다. C의 fopen,

JAVA의 java.io.*의 파일 시스템 관련 라이브러리 등이 이에 해당하낟.

② 운영 체제 계층 : 운영 체제 계층에서는 여러 종류의 다양한 파일 시스템을 같은 형태의

스토리지로 추상화 해준다. Linux의 VFS (Virtual File System)이 이와 같은 역할을 한다.

각 다양한 파일 시스템을 inode(파일이나 디렉토리에 대한 메타 정보를 저장하는 데이타

구조)에 메타 정보를 저장하고, 파일 자체를 block 단위로 나눠서 저장하는 구조로 추상

화 한다. 이렇게 추상화된 파일은 System Call Interface로 Abstract되서 접근할 수 있게

된다.

③ 파일 시스템 : 파일 시스템은 쉽게 예를 들면, 디스크를 포맷할때, 어떤 파일 시스템으로

포맷할것인가? 를 결정할때 선택하는 부분이다. PC 포맷할때 FAT32, NTFS등으로 선택하

는 것이 파일 시스템이다.

파일 시스템은 FAT32,NTFS,ext3과 같이 OS에서 제공하는 Native File System과, 이런 파

일 시스템 위에 설정하는 NFS,GFS (Gluster File System),HDFS (Hadoop Distributed File

System) 파일 시스템들이 있다. HDFS와 같은 파일 시스템은 쉽게 생각하면 ext3로 디스

크를 포맷한 다음 그 위에 파일 시스템 관리용 시스템 (HDFS)를 인스톨해서 HDFS 인터

페이스를 통해서 파일 시스템에 접근하게 된다.

각 파일 시스템은 성능, 확장성 그리고 안정성등에 최적화되어서 특성에 따라서 분리 된

다.

④ 스토리지 하드웨어 : 파일 시스템을 구성하는 스토리지 하드웨어는 크게 아래와 같이 3

가지로 분리 된다.

DAS (Direct Attached Storage) : DAS는 외장형 디스크로 생각하면 된다. 서버 외부에

용량을 확장해서, 그 서버에서만 사용하는 공간이다.

SAN (Storage Area Network) : 하나의 스토리지를 여러개의 서버에서 나눠서 사용하

는 스토리지이다. 하나의 SAN 스토리지를 여러개의 볼륨으로 나눠서 다수의 서버가

각각의 볼륨을 외장형 디스크 처럼 마운트해서 사용한다. 단 각 마운트된 볼륨은 다

른 서버에서 접근할 수 없다.

NFS (Network File System) : NFS는 공유 파일 시스템으로, 하나의 스토리지를 여러개

의 서버가 공유해서 사용한다. 즉 서버가 다른 서버의 저장 공간을 공유해서 사용할

수 있다.

스토리지 하드웨어에 대한 상세한 내용은 7장의 인프라스트럭쳐 부분에서 자세하게 설명

하도록 한다.

Native 파일 시스템은 소프트웨어 애플리케이션 아키텍쳐 설계상에는 크게 영향을 주지 않는다.

일반적인 파일 시스템으로 취급되기 때문에 애플리케이션에서 파일 시스템으로의 접근 방법이 동

일하기 때문이다. 그러나 이런 Native File System 위에 설치되는 NFS나 HDFS와 같은 파일 시스

템은 애플리케이션 설계에 영향을 준다. NFS의 경우 서버간의 공유가 가능하다는 접근성의 특성

을 가지고 있고, HDFS의 경우 파일 접근을 위한 API가 다르다. 그러면 애플리케이션 아키텍쳐 설

계에 영향을 주는 주요 파일 시스템 옵션은 무엇이 있을까?

Native File System : 일반적인 로컬 디스크로, 디스크가 붙어 있는 서버에서만 읽고 쓰기

접근이 가능하다.

Network File System : 공유 디스크의 개념으로 다수의 서버에서 읽고 쓰기로 접근이 가

능하다. 그래서 상태 정보나 작업 정보 공유용으로 사용된다.

사용 용도를 설명하기 위해서 하나의 아키텍쳐 예를 들어보자.

이미지 파일을 업로드해서 여러 크기로 바꿔서 저장하는 시나리오를 구현해보자

① Dispatcher는 파일을 업로드해서 Working Space에 저장한다. 그리고 파일이 저

장되었다는 메세지를 Message Queue에 저장한다.

② Post Processor는 Message Queue에서 순차적으로 메세지를 읽어서 Working

Space에서 파일을 읽어서 여러 해상도로 바꿔서 뒤에 Permanent Storage에 저

장한다.

중간단에 Working Storage를 NFS를 사용할 수 있는데, NFS를 사용하는 이유는 다음

과 같다. NFS를 사용하지 않으면 Local Disk에 저장이 되는데, 이 경우 해당

Dispatcher Node가 Fail이 났을때, 작업중인 데이타를 보장할 수 없다.

Local Disk를 사용하면 한대의 Machine에서 Post Processor를 각각 실행해야 하고,

한대의 Machine에서의 용량상의 한계가 있기 때문에 용량 확장이 불가능하다. NFS

를 사용한 구조를 취하면, Post Processor를 여러대의 Machine에서 동시에 여러개의

인스턴스를 실행시켜서 처리량을 높일 수 있다.

공유 스토리지는 아키텍쳐에 다양성을 제공해줄 수 있기 때문에 사용 용도가 많다.

단 Local Disk에 비해서 IO 성능이 비교적 떨어지기 때문에 이 부분에 대한 고려하에

아키텍쳐를 설계해야 한다.

Object Storage : 근래에 들어 Amazon S3나, OpenStack SWIFT와 같은 Object Storage라

는 형태의 새로운 파일 스토리지가 소개되었다.

이런 Object Storage는 기존의 파일 시스템과는 다르게 OS에서 디스크 형태로 mount해

서 사용하는 게 아니라, HTTP/REST와 같은 다른 파일 IO 인터페이스를 사용한다. 다른

인터페이스를 사용하기 때문에, 파일 시스템으로의 접근은 OS에 대한 제약을 받지 않는

다. NFS와 같은 공유 파일 시스템은 중앙 컨트롤러를 통해서 접근하기 때문에, 컨트롤러

의 병목에 의해서, 동시 접속 클라이언트가 많을 경우 성능 저하가 올 수 있다. 그러나

이러한 Object Store의 경우 처음부터 중앙 집중형 접속 포인트를 두지 않고, 아무 노드

에나 접속을 가능하게 하는 형태이고, 파일 저장 구조 역시 전체 노드에 걸쳐서 분산해

서 저장하기 때문에, 대용량 사용자들이 동시에 접속하게 하는 대용량 파일 서비스 구조

에 적합하다.

NoSQL

기존 IT 시스템은 주류가 기업의 업무를 IT로 구현하기 위한것이 목적이었다. 그래서 데이타베이

스도 기업의 복잡한 업무 구조를 표현하고 그 관계를 표현하기 위한 RDBMS가 주류를 이루고 있

었다. 데이타가 많다고는 하지만, 기업내의 직원과 기업내의 매출과 기업내의 제품과 상품등으로

한정된 데이타 양을 가지고 있었다.

그러나 근래에 들어서 인터넷의 발전으로 FaceBook, Twitter 등 SNS 서비스가 발전함에 따라서

데이타베이스에 대한 요구 사항은 변화되었다. 기업 처럼 복잡한 데이타 관계를 필요로하지 않는

다. 블로그만 예를 들어도, 블로그는 글제목,날짜,내용 등 몇개의 필드면 데이타를 저장할 수 있고,

테이블간의 관계도 거의 없다. 단 이런 서비스들은 일반 사용자를 위한 서비스이기 때문에 빠른

응답시간을 보장해야 하고, 전세계 사람들이 사용할 수 있기 때문에, 많은 용량을 저장할 수 있어

야 한다.

단순한 데이타를 대용량으로 저장할 수 있으며 빠른 성능을 제공하는 데이타 베이스가 필요하게

되었는데, 이러한 데이타 베이스를 NoSQL이라고 한다.

NoSQL은 특수 목적에 맞춰서 디자인이 되었으며, 특히 성능과 용량에 촛점이 맞춰진 제품들이

많다. 또한 데이타 모델은 단순하게 Key/Value 형태의 저장 구조를 갖으며, 데이타간의 relationshi

등은 지원하지 않는다. 오로지 단순 데이타를 빠르게 읽고 쓰는데 최적화가 되어 있다.

NoSQL은 사용할 때 주의할 점은

① 과연 NoSQL이 필요한가?

일종의 유행처럼 NoSQL이 퍼지고 있는데, 사실 일반적인 시스템 개발에서는 NoSQL이

필요없다. RDBMS 만으로도 충분하고, 필요에 따라서는 Query Off Loading과 Sharding

조합으로도 서비스가 가능하다. 아주 대용량의 서비스를 빠른 성능으로 제공할 때만

NoSQL을 고려해볼 필요가 있다. NoSQL은 생각보다 습득이 쉽지 않고 경험이 많이 필요

하기 때문에 유행에 휩쓸리지 말고 필요성을 냉정하게 따져볼 필요가 있다.

② NoSQL에 저장할 데이타는 무엇이며 어떤 NoSQL을 사용할 것인가?

NoSQL은 Non-RDBMS의 DBMS에 대한 총칭이다. 제품에 따라서 데이타 모델도 다르고,

그 기능과 특성도 모두 틀리다. 처음부터 하나의 NoSQL에 모든 데이타를 저장하겠다는

생각자체를 버리는 것이 좋다. 먼저 어떤 데이타를 NoSQL에 저장할 것인지 결정하고, 그

에 맞는 NoSQL을 선정해야 하며, 다른 데이타베이스 (RDBMS와 다른 NoSQL)과 함께 사

용할 방법을 고려해야 한다.

이 NoSQL은 근래에 SNS 서비스가 유행하면서 특히나 화두가 되고 있는 기술인데, 이 부분에 대

해서는 6장에서 자세하게 설명하도록 한다.

(4) Analysis Layer

앞에까지 설명한 (1)~(3) 까지의 계층은 실시간 트렌젝션을 처리하기 위한 아키텍쳐이다. 클라이

언트가 요청한 request에 대한 처리를 위한 구조이고, 지금 부터 설명하는 Analysis Layer는 트렌

젝션 처리에 의한 결과와 로그를 분석하는 Layer이다. Anlysis Layer 또는 BSS(Business Support

System) 그리고 은행에서는 정보계라는 용어를 사용한다.

전통적인 Analytics 계층은 위와 같은 모습을 갖는다.

Transaction Processing 계층에서 생성된 각종 로그와 비지니스 데이타를 Gathering 컴포넌트에서

수집한 후에, Transform 컴포넌트에서 이를 분석을 위한 저장소에 저장하기 위해서 포맷을 변경한

다. 예를 들어 웹서버의 텍스트 로그를 수집해서 RDBMS에 저장한다.

분석을 위한 데이타는 이 Store 컴포넌트에 정제된 형태로 저장된 후에, 사용자가 보고 싶은 리포

트 형태로 VIEW 컴포넌트에 의해서 리포트나 dash board 형태로 출력 한다.

이러한 개념적인 분석을 실제 소프트웨어 컴포넌트로 어떻게 구현할까? 여러가지 방법이 있겠지

만 트렌드에 따라서 크게 아래와 같이 3가지 정도로 분리해볼 수 있다.

전통적인 OLAP 방식의 분석 시스템

전통적인 기업형 업무에서는 RDBMS 기반의 분석 시스템을 사용해왔다. OLAP (OnLine Analytics

Processing) 이라는 형태의 분석에 최적화된 데이타 베이스를 사용하여 데이타를 분석하여 리포트

를 생성한다. 구조는 다음과 같다

ETL

ETL(Extract Transform Loading) 여러 데이타 소스로 부터 수집해서 변환 및 저장하는 역할을 한다.

E는 Extract의 약자로, 다양한 데이타 소스로 부터 데이타를 추출한다. 텍스트 기반의 로그 파일에

서 데이타를 추출하거나, 다른 RDBMS로부터 데이타를 추출하는 기능등을 수행한다.

T의 Transform은 추출된 데이타를 수신 변환하는 역할을 수행하는데, 필요한 데이타만 선별 추출

하거나, 필드를 합치거나 특정 룰에 따라서 데이타를 변환한다.

L은 Loading의 약자로, 이렇게 변환된 데이타는 수신쪽 데이타 베이스에 저장된다.

ETL이외에도 근래에는 클라우드 기반의 분산 컴퓨팅 환경에 맞춰서 전문화된 로그 수집 솔루션이

있다. 클라우드 환경의 특징은 로그 수집 대상이 되는 서버들이 분산되어 있으며, 처리 용량에 따

라서 Scale Out/In (서버의 수가 처리량에 따라서 동적으로 늘어나거나 줄어드는 기술)을 사용하기

때문에, 로그 수집 대상이 정적이지 않고 상황에 따라서 바뀐다. 이러한 분산 환경을 지원하는 솔

루션으로는 Flume 등이 있다.

data ware house & data mart

이렇게 데이타를 저장하는 장소를 OLAP (OnLine Analytics Processing) 형태의 데이타 베이스에

저장된다. 기업내의 모든 OLTP 시스템에서 수집된 모든 데이타는 먼저 data ware house 라는 중

앙 집중화된 데이타 베이스에 저장된다. 이렇게 저장된 데이타는 리포트를 보고자하는 각 부서에

따라 다시 정제 되서 저장된다. 이렇게 각 부서별로 데이타가 저장되는 장소를 data mart라고 한

다.

Data mart를 사용하는 이유가 몇가지가 있다.

부서의 업무 성격에 따라서, 테이블 구조나 데이타 베이스 구조 변경이 필요하고 이러한 구조 변

경은 타 부서 업무에 영향을 줄 수 있다. 그래서 데이타베이스에 대한 변경을 자유롭게 하기 위

해서 부서간에 공유되는 data ware house가 별도의 분리된 data mart를 사용한다.

또한 data warehouse에서 직접 데이타를 분석하게 되면, 부서간 리포팅 성격에 따라서 시스템에

부하를 주기 때문에 부서간의 분석 업무의 성능에 영향을 받을 수 있다.

서마다 분석 데이타에 대해서 유지해야 하는 주기가 다르다. 물론 data ware house에 데이타 저

장 기간을 가장 긴 기간으로 하향 평준화하여 맞추는 방법도 있지만, 문제는 data ware house

machine이 data mart보다 비싸다. 각 부서별로 데이타 저장 기간과 정책을 자유롭게 정할 수 있

다.

마지막으로, 부서의 데이타 분석 스타일에 따라서 원하는 데이타 리포팅 도구를 사용할 수 있다.

물론 기업의 크기가 크지 않고, 데이타 분석을 필요로 하는 부서의 수가 그리 많지 않다면 별도

의 data mart를 사용하지 않고 data ware house 하나로 데이타 저장소를 대신할 수 있다.

Data mart에 저장된 데이타는 Reporting 도구를 이용하여 업무의 특성에 맞게 적절한 분석을 통

해서 가시화된 리포트로 제공된다. 이 Reporting은 RBMS의 Join과 Query 등의 기능을 이용하여

구현되며, 저장된 데이타에 대해서 다차원 분석 수행한다. 다 차원 분석이란 우리가 흔히 보는 그

래프 형태인데, 흔히 X,Y 값 기반의 2차원 분석이나 X,Y,Z 값 기반의 3차원등 다차원 분석을 사용

한다.

Map & Reduce 기반의 분석 시스템

근래에 Google, Facebook 과 같은 대규모 B2C 서비스를 중심으로, 대용량 데이타의 분석에 대한

요구 사항이 생기게 되었고, 기존의 전통적인 OLAP RDBMS를 이용한 데이타 분석이 용량상의 한

계로 인하여 다른 접근 방법을 사용하게 되었다. 대표적인 방법으로 Map & Reduce라는 방법을

사용한 데이타 분석 방법이다.

Map & Reduce 는 프로그래밍 아키텍쳐의 개념으로, Map & Reduce 는 하나의 큰 데이타를

여러개의 조각으로 나눠서 처리 하는 단계(Map), 처리 결과를 모아서 하나로 합쳐서 결과를 내는

단계 (Reduce)로 나뉘어 진다.

<그림 Map & Reduce 의 기본 개념 >

예를 들어 한국에 사는 모든 사람의 수입의 합을 더한다고 하자. 우리한테는 한국에 있는 모든

사람의 수입이 적혀 있는 텍스트 파일이 하나 있다. 이 파일을 이용해서 각각 사람의 수입을

순차적으로 더해서할 수 도 있지만, 전체 파일을 10 조각, 100 조각으로 나눠서 각 조각의

수입합을 계산한후, 그 결과를 하나로 더하면, 조각을 나눈만큼의 계산을 병렬로 처리할 수 있기

때문에 조금 더 빠른 결과를 가질 수 있다. 이렇게 하나의 파일을 여러 조각으로 나눠서 계산

하는 것을 Map, 그리고 합치는 과정을 Reduce 라고 한다.

이러한 Map & Reduce 아키텍쳐의 대표적인 구현체로는 Apache 오픈소스 커뮤니티의 Hadoop이

있다. Map & Reduce는 저가의 일반적인 하드웨어로 대용량 분석 처리를 할 수 있다는 장점을

가지고 있으나, 데이타의 수집,변환 및 분석 리포팅의 전 과정을 직접 구현해야 하는 단점을 가지

고 있다. 그래서 Map & Reduce를 사용해서 데이타를 분석하는 조직은 일반적인 개발자나 시스템

엔지니어 보다는 데이타 분석에 대한 알고리즘을 만들어낼 수 있는 data scientist와 같은 특화된

데이타 분석 역할을 필요로 한다.

Map & Reduce + OLAP 형태의 데이타 분석 시스템

B2C 서비스를 중심으로 Map & Reduce가 데이타 분석에 대한 주류로 자리 잡게 되었고, 점점 증

가하는 고객의 데이타에 대한 분석 대응 능력이 고객에게 요구 되기 시작했다. 흔히 근래에 이야

기 하는 “빅데이타” 라는 이름이 이러한 데이타 분석의 이름인데, 일반적인 기업 입장에서는 다양

한 형태의 데이타 분석과 리포팅 필요하고, 주로 개발과 시스템 엔지니어를 보유한 일반적인 기

업 입장에서는 일반적인 기업에서는 data scientist와 같은 역할의 사람을 고용하기가 어렵다. 그

래서 OLAP과 Reporting Tool과 같이 자동화된 도구를 사용해왔는데, 이러한 RDBMS 기반의

OLAP으로는 빅데이타 분석을 위한 충분한 용량을 확보하기 어렵고 더불어 근래에 생성되는 고객

의 데이타는 기업 내부의 정형화된 데이타 뿐만 아니라 Face Book, Twitter등과 같은 SNS등에서

수집되는 비 정형화된 데이타에 대한 분석이 필요하게 되었다.

그래서 Map & Reduce의 장점과 OLAP 기반의 분석을 융합한 형태의 솔루션을 벤더에서 출시하

고 있다.

기존의 OLAP의 앞단에 Hadoop과 같은 Map & Reduce Framework을 붙인 형태인데, Hadoop은

정형화되지 않은 형태의 대용량 데이타를 수집하여 Map & Reduce를 이용하여 정제하고 OLAP에

저장한다. 이렇게 저장된 OLAP의 데이타는 기존의 OLAP 인프라와 프로세스를 그대로 이용하기

때문에 기업의 입장에서는 기존 OLAP 기반의 데이타 분석 구조와 인력 구조를 변경하지 않고도

빅데이타에 대해서 대응이 가능하다. 같은 DBA와, 같은 OLAP Reporting 툴들을 그대로 사용할

수 있다.

여기에 하나 더해서 데이타 분석 성능을 높이기 위해서 appliance 제품을 사용하는데, appliance

제품은 소프트웨어 솔루션 뿐만 아니라 소프트웨어에 최적화된 하드웨어와 함께 패키지된 형태의

제품이다. SQL 쿼리 엔진을 하드웨어 칩으로 만들어서 서버에 장착하거나, 해당 DBMS에 대한 쿼

리를 최적화 하기 위해서 DISK 구조나 IO 구조등을 최적화 해놓은 제품들이다.

대표적인 제품으로는 Oracle의 ExaData나 IBM의 Nettiza와 같은 제품들이 있다.

Figure 10 Oracle Exadata

실시간 분석 시스템

이러한 데이타 분석은 경영단의 의사 결정에 있어서 아주 큰 영향을 미친다. 그런데, 전통적인

OLAP 방식이나, Map & Reduce 방식은 일반적으로 Batch 방식이라고 이야기 하는 형식의 데이타

처리 형식인데, 이는 로그 데이타가 생성된지 하루나 이틀 이후에 리포트가 생성되기 때문에 신

속한 의사 결정이 어렵다. 그래서 근래에 들어서 많이 이슈가 되는 것이 실시간 데이타 분석이다.

Transaction이 발생하면서 부터, 실시간으로 리포트를 받아보고 거기에 따른 의사결정을 함으로써

빠르게 비지니스 환경에 대한 대응이 가능하다.

OLAP에서는 real-time BI (business intelligence)로 발전하였고 근래에 주목 받는 형태중의 하나

는 CEP (Complex Event Processing)이라는 개념을 사용한다. 특히 금융시장이나 증권 시장은 외부

시장 변화에 대한 분석 결과를 기반으로 빠른 대응이 필요하고, 공장 생산 라인에서 수집되는 데

이타나, 비행기 발권 시스템, 마케팅 결과 등의 데이타 들은 대응력이 빠를 수 록 얻을 수 있는

메리트가 크기 때문에 이러한 분야를 중심으로 CEP가 확산되어가고 있다. CEP 솔루션으로는

Esper등이 있다.

분석 계층에 대해서는 간단하게 설명하였지만, Map & Reduce 하나, ETL 하나만 해도 책 수권이

나올 수 있을 정도로 매우 넓은 주제이다. 이 글에서는 전체 아키텍쳐 측면에서 데이타 분석 계

층에 대한 컴포넌트를 설계를 위해서 큰 개념만을 설명하였다. 데이타 분석 계층에 대한 아키텍

쳐 설계는 분석하고자 하는 원본데이타의 성격 (정형화 여부, 원본 시스템의 개수, 데이타의 양)을

기반으로 해서 적절한 분석 플랫폼을 선택해야 하고, 그에 맞는 적절한 아키텍쳐를 조금 더 깊게

연구하고 설계 하기를 권장한다.

(5) OAM Layer

OAM은 Operation, Administration & Monitor의 약자로 다른말로는 OSS (Operation Support

System)이라고도 불린다. OAM 시스템은 서비스를 하는 입장에서, 시스템의 운영자 입장에서 필요

한 관리 및 모니터링 기능을 제공하며, 크게 설정 관리를 위한 Configuration Management와 시

스템에 대한 배포를 책임지는 Deployment System, 그리고 시스템의 상황을 모니터링하는

Monitoring 시스템등으로 분류될 수 있다.

CMDB (Configuration Management DB)

여러 인스턴스로 구성되는 분산 시스템이나 여러 컴포넌트로 조합된 시스템을 구축할때는 각 컴

포넌트와 인스턴스에 대한 설정 정보를 저장하기 위한 공용된 데이타 베이스가 필요한데, 이런

용도에서 사용되는 것이 CMDB이다. CMDB는 일반적인 RDBMS를 사용하는 방법도 있고, 조금 더

특화된 데이타 베이스를 사용하는 방법도 있다.

Tomcat이나 WebLogic같은 제품은 xml 파일로 이 CMDB 정보를 관리하고 Oracle이나 MySQL은

DB 자체에 CMDB 정보를 관리하기도 한다. 그러나 근래에 들어서 시스템이 분산화 되어가면서

중앙 집중화된 설정 정보 저장소가 필요하게 되었고, 또한 시스템의 상황에 따라서 Auto-Scale

Out과 같이 자동으로 인스턴스의 수를 조정하는 등의 부가적인 기능이 요구되면서 특화된 데이

타 베이스들이 등장하였는데, ZooKeeper등이 그러한 예에 속한다. ZooKeepr는 작은량의 데이타를

구조화된 형태로 저장하면서 빠른 억세스를 제공하고, 값이 바뀌는 것에 대해 이벤트 트리거 기

능을 제공하여, 어떤 설정값이 바뀌었을때 이에 대한 특정한 ACTION 등을 취할 수 있도록 해준

다.

Monitoring

모니터링은 시스템 운영에 있어서 가장 중요한 항목중의 하나이다. 시스템의 건전성을 체크하고

장애에 대한 전조를 인식하여 대응할 수 있게 하며, 장애 발생시 이를 추적하기 위한 근거를 데

이타를 제공한다.

여러가지 계층에 대해서 모니터링을 할 수 있는데, 크게 다음과 같은 계층으로 분리할 수 있다.

① Infrastructure : 인프라 모니터링은 서버,스위치,디스크등의 실제 하드웨어 인프라에 대한

모니터링을 지원한다. 이러한 인프라는 SNMP라는 표준 프로토콜을 이용하여 모니터링이

가능하며, 업체마다 이를 확장한 형태로 모니터링 인터페이스를 제공한다. 인프라를 모니

터링 하기 위한 오픈소스로는 Nagios,Cacti,Ganglia 등이 있다. 상용 도구로는 HP

OpenView, CA의 Unicenter TNG등이 있다.

② DBMS : 데이타 베이스에 대한 모니터링을 하기 위한 도구로, 대부분 데이타베이스 솔루

션 벤더에서 제품등을 제공하지만, 튜닝과 SQL 디자인등의 부가 기능을 제공하는 제품들

이 있다. 유명한 제품으로는 Quest社의 Toad등이 있다.

③ Middleware : 다음으로는 미들웨어에 대한 모니터링이 있는데, Tomcat,WebLogic같은 애

플리케이션 서버나 Rabbit MQ등의 큐등의 미들웨어가 있고, 이에 대한 모니터링은 대부

분 해당 제품 개발사에 포함되어 있는 경우가 많다. Tomcat이나 WebLogic등의

application server등은 Application을 모니터링 하는 제품에 함께 그 기능이 포함되어 있

는 경우가 많다.

④ Application : 애플리케이션 자체를 모니터링 하는 제품군으로, 일반적으로는 개발자가 해

당 애플리케이션에 맞게 개발하는 경우가 많지만, application server위에서 동작하는 제

품의 경우 application server와, application을 함께 모니터링 해주는 제품으로 APM

(Application Performance Monitoring)이라는 제품군이 있다. 대표적인 제품으로는

Jennifer Soft社의 jennifer라는 제품이 있다. Wily Introscope와 같은 고가의 외산 제품에

비해서 상대적으로 낮은 가격으로 상당히 높은 품질의 모니터링을 제공한다.

application server에 대한 모니터링 뿐만 아니라, 실시간 동시 접속자수, 애플리케이션

의 병목 구간등을 분석 해준다.

<그림. Jennifer Soft의 APM – Jennifer >

※ 수영장 딸린 회사, 1층에는 커피숍이 있고, 회사내의 어린이 집에는 외국인 보육 교

사가 애들을 봐줍니다. 헤이리에 있는 회사 뒷뜰에는 넓은 잔디밭이 있고, 수영 전문

강사가 직원들을 수영 강습해주고, 수영하는 시간은 업무 시간에 포함됩니다. 이게

Jennifer Soft의 복지입니다. 회사들이 여러 코드를 가지고 있지만, Jennifer Soft는 복

지 기반의 인간중심의 회사입니다. 제품도 좋지만 회사의 경영 사상이 매우 특이한

회사라고 볼 수 있겠지요. 외산 솔루션을 다 밀어내고 국내 확고한 1위에 더불어 해

외로 나가고 있는 회사 입니다. 좋은 솔루션인 만큼 확실하게 추천 드립니다. 그리고

이런 회사들이 한국에 많아졌으면 좋겠습니다.

Configuration Management

개발된 애플리케이션을 서버에 배포하는 모듈이다. 근래에 들어 Short Release 기반의 개

발 방법론이 유행하면서, 기존에 비해 자주 애플리케이션을 업그레이드해야 할 일이 생기

고, 더불어 클라우드 환경이 되면서 Auto Scale Out을 지원하면서, Scale Out된 새로운 인

스턴스에 애플리케이션을 배포해야 하기 때문에, 배포에 대한 요구 사항이 높아졌다.

애플리케이션에 대한 배포 뿐만 아니라, 이를 지원할 하드웨어 인프라나, 미들웨어까지도

자동으로 배포하는 시나리오가 근래에 들어서 많이 사용되는데, 이런 배포 및 설정까지

자동화 해주는 도구로 “Automation Tool”이라는 영역이 있고 대표적인 도구로는 Puppet,

Chef 등이 있다.

지금까지 대용량 시스템을 구현하기 위한 아키텍쳐들을 계층별 컴포넌트별로 쭈욱 살펴봤다. 그

럼 각각의 컴포넌트들을 구현하기 위한 구체적인 솔루션들은 무엇이 있을까? 아래 표는 오픈소스

를 중심으로 하여 각 계층별 컴포넌트를 구현할 수 있는 솔루션에 대한 목록이다.

Layer Component Product

Access Layer

Reverse Proxy

apache httpd

nginx

haproxy

Enterprise Service Bus mule

Oracle Service Bus

Identity Management Microsoft Active

Directory, LDAP

Integration Layer Apache Camel

Business Layer

Transaction processing(Sync)

apache tomcat

jetty

apache mina

apache netty

redhat jboss

oracle weblogic

Message Queue (Async)

Rabbit MQ

Active MQ

Zero MQ

data grid

memcached

redis

oracle coherence

Persistent Layer

RDBMS mysql

mysql replication

ganglia

tungsten

oracle golden gate

file system (NFS) glusterfs

file system (object store) openstack swift

NoSQL

hbase

cassandra

mongodb

riak

Analysis Layer log gathering

flume

flumed

analysis service splunk

ETL Pentaho

map & reduce Hadoop

+ pig,hive

cep esper

OAM

cmdb zookeeper

monitoring

jennifer

ganglia

nagios

configuration management puppet

chef

Global Service Architecture

여러 국가간에 걸쳐서 서비스 되어야 하는 시스템의 경우 아키텍쳐적으로 어떠한 사항을 고려해

야 할까? 일반적인 웹서비스를 국내에서 개발하는 것과는 또 다른 접근이 필요하다.

법적인 이슈에 대한 검토

먼저 시스템을 구축하고자 하는 지역의 법적인 제약 사항을 이해해야 한다.

미국이나 유럽의 경우에는 사용자 정보가 반드시 그 국가에 있어야 하는 제약 사항이 있다 그래

서 IDM을 각 국가에 배치해야 하고 인증 역시 해당 국가를 거쳐서 일어나야 한다.

중국의 경우에는 great fire wall 이라는 방화벽으로 전체 인터넷을 감싸고 있고, 국가의 정책에 따

라서 특정한 서비스를 갑자기 막아 버릴 수 도 있기 때문에, 중국 대상 서비스의 경우에는 중국

에 시스템을 놓는 것이 안전하다.

한국만해도, 위치 정보 서비스를 제공하기 위해서는 위치 정보 사업자를 내야 하는등 여러가지

법률적인 제약 사항이 있기 때문에, 사전에 서비스를 제공하고자 하는 법률 사항을 체크한 후에

시스템을 디자인 해야 한다.

이런 이유로, 글로벌 서비스의 경우 미국,유럽,중국 3개 지역이 주요 데이타 센터의 선정지가 되

고, 국내 서비스를 포함할경우, 한국도 시스템이 위치하는 지역에 포함된다.

시스템 위치 선정

글로벌 시스템을 구축할때 센터의 위치 선정도 또한 중요한 이슈가 된다. 결론 부터 말하자면 시

스템은 주로 유럽,미국,중국 3군데에 위치하는 것이 일반적이며, 조금더 확장되면 아시아 커버리

지를 위해서 싱가폴,홍콩,일본등에 센터를 구축하는 경우가 있다.

8

위의 그림은 대륙간의 인터넷 연결인데, 미국과 아시아는 미국 서부와 일본을 주축으로 연결이

되어 있으며 미국과 유럽은 미국 동부와 영국쪽으로 연결되어 있는 것을 볼 수 있다. 네트워크

대역폭면에서는 미국 서부,동부,유럽 서부(영국),일본이 가장 충분한 대역폭을 확보하고 있기 때문

에 가장 좋은 후보군들이 된다.

또한 인력 수급을 고려해야 하는데, 미국은 당연히 양질의 인력을 많이 가지고 있으며 영국의

Dublin 같은 지역의 경우 대학교 인프라가 좋아서 졸업생들을 중심으로 인력 수급이 수월한 편이

다.

장비 확충을 할때, 장비 공급이 원할한 곳도 중요한 포인트가 된다. 관세나 통관 절차가 복잡한

경우에는 장비 확장을 하는데 제약을 받을 수 있기 때문에 이 또한 함께 고려가 되어야 한다.

근래에는 Amazon과 같은 public cloud를 사용하는 경우가 많은데, 보안이 중요한 데이타는 자사

의 데이타 센터에 놓고, 추가적인 용량이 필요할때 마다 public cloud의 자원을 사용하는 시나리

오가 근래에 들어서 많이 고려되고 있다. 이러한 시나리오를 bursting이라고 하는데, bursting을

위해서는 자사의 데이타 센터와 public cloud 센터간의 네트워크 latency가 낮아야 한다. 그래서

amazon 데이타 센터 근방에는 colocation 형태로 데이타 센터를 임대해주는 곳이 있고, 그러한

데이타 센타는 Amazon 데이타 센터와 직접 망이 연결되어 10ms 내외의 latency로 연결이 가능

하다.

8 출처: http://www.fourwinds10.net/siterun_data/media/internet/news.php?q=1202249895

운영에 관련된 고려 사항

다음은 운영 센터에 대한 관점을 고려해야 한다. 운영은 데이타 센터가 있는 곳이면 가장 좋겠지

만, 운영은 고객 대응이 있는 경우에는 언어적인 문제와 24시간 365일 운영 지원을 해야 하기 때

문에, 별도의 운영 센터를 두는 경우가 많다.

시스템 운영의 경우에는 데이타 센터에 운영 인력을 상주 시키는 것이 좋다. 장애에 대해서 바로

대응할 수 있는 점이 유리한데, 단 24시간 운영을 위해서 최소한 두군데에 운영 팀을 만드는 것

이 좋은데, 보통 유럽과 미국과 같이 time zone이 반대인곳을 선택한다. 특히 24x7 지원을 하기

위해서 두개 이상의 권역을 걸쳐서 위치 하는 것이 일반적이다. 한 센터가 낮일때, 다른 센터가

밤일 수 있기 때문에, 양쪽에서 교대로 시스템을 관제한다. 이러한 모델을 FTS (Follow The Sun)이

라고 한다.

고객 대응의 경우에는 언어와 문화적인 특성을 감안해서 고객 대응 관리 그룹은 본사에 위치하지

만 고객 대응팀은 언어 권역별로 위치하되 인건비가 싼곳을 우선적으로 선정한다. 한국에 솔루션

이나 서비스를 납품하는 기업들을 보면 원가 절감 차원에서 연변의 조선족을 사용하는 경우가 많

고, 미국 대상의 회사의 경우에는 동남아(필리핀과 같은 영어권)나 인도같은 권역을 이용하는 경

우가 많다.

기술적인 고려 사항

그러면 다음으로 글로벌 배포 시스템을 설계 하기 위한 아키텍쳐적인 기술 고려 사항을 살펴보자.

1) 센터의 레벨과 분류

먼저 데이타 센터를 분류하자, 데이타 센터를 계층형으로 나누어서 정의하고 각 센터마다 배치될

시스템을 분류한다. 크게 분산 시스템의 센터는 HQ,RC,Edge 등으로 나눌 수 있다. HQ(Head

Quarter) 는 메인 시스템이 위치한 곳이며, RC (Regional Center)는 특정 권역을 커버하는 시스템

이다. 경우에 따라서 Edge 센터를 설립할 수 있다.

HQ(Head Quarter)는 전체 센터의 중심이 되는 곳으로 모든 핵심인력이 모여 있는 곳이다. 또한

공통적으로 필요한 시스템 예를 들어 데이타 분석 및 중앙 시스템 관제 등에 필요한 시스템이 위

치한다.

RC(Regional Center)는 각 권역을 서비스 하기 위한 센터로, HQ 보다는 작지만, 일정 규모 이상의

팀을 가지고 있으며,

또한 RC의 특징은 앞서 설명한 각 권역에 대한 법적인 이슈를 해결하기 위해서 위치 하는 경우

가 많은데, 크게 미주,유럽,중국 3개 권역이 RC가 위치 하는 대표적인 지역이 된다.

마지막으로 Edge Node라는 형태의 센터가 존재할 수 있는데, 권역에서 커버를 하지만, 네트워크

속도등의 영향을 받거나 특정 법적인 이슈를 피해가기 위해서 일부의 시스템만 위치 시킬때 사용

한다. 예를 들어, CDN (Contents Delivery Network)과 같이 파일 다운로드 성능을 높이기 위해서

특정 국가에 서버를 위치 시키거나, 사용자 정보가 그 나라에 저장되어야 한다는 법적인 제재를

피하기 위해서 사용자 정보와 인증 서버만을 그 국가에 위치 시키는 센터가 Edge Node가 된다.

보통 Edge Node는 센터 레벨이 아니라, 데이타 센터에 Co-Location 형식으로 위치하고, 서버등

인프라에 대한 지원을 out sourcing 형태로 사용하고, 시스템에 대한 관제는 해당 권역을 커버하

는 RC를 통해서 진행하기 때문에, 상주 인원이 없거나 또는 최소한의 상주 인원으로 운영한다.

2) Request Routing

이렇게 여러개의 데이타 센터에 걸쳐서 시스템을 운영하게 되면, 시스템이 비 대칭적으로 배포

된다. 즉 로깅 처리나 분석 시스템은 HQ에만 위치하고, 사용자 인증은 HQ,RC,Edge에 커버되는

국가에 따라서 분산되서 배치된다. 이런 형태에서, 시스템을 접근하는 클라이언트는 전체 시스템

에 대해서 똑같은 서비스를 제공 받아야 한다. 즉 로그 분석 시스템이 HQ에만 있다하더라도, RC

를 API로 호출하면, 로그 분석 request가 HQ로 forward되서 처리되어야 한다.

이런 기능을 request routing이라고 하는데, 이는 enterprise service bus (ESB)를 통해서 구현될 수

있다. Client는 RC나 HQ 아무곳으로나 동일한 API를 호출할 수 있고, 실제 비지니스 로직이나 데

이타가 있는 곳으로 request가 forwarding된다.

※ 한국에 있는 사용자가 미국으로 출장을 간다면, 해당 사용자는 미국 시스템에 접속되어야 할

까? 한국 시스템에 접속되어야 할까?

이 문제는 보통 글로벌 배포 시스템에서 공통적으로 고민하는 내용중의 하나이다.

결론 부터 이야기 하자면, 한국 사용자는 미국으로 가더라도 한국 시스템에 접속하는 것이 좋다.

다른 나라에 여행을 가보신 분들은 아시겠지만, 다른 나라에서 시스템을 호출한다고 하더라도 속

도가 크게 느리지 않다. 보통 100ms 내외의 latency가 더 해지는데, 약간 느린 느낌이 들더라도

큰 속도 차이는 나지 않는다.

오히려, 사용자가 국가를 이동할때, 데이타에 대한 라우팅등을 처리하는데 드는 비용이 훨씬 크

다.

3) 센터간의 Data Replication

다음으로 고려 사항이 데이타 센터간의 데이타 복제이다. 데이타 복제는 크게 두가지 관점에서

필요한데, 권역을 걸쳐서 동일한 데이타를 제공해야 하는 경우와, 장애시 Fail Over를 위한 HA

(High Availibility) 관점에서 데이타 복제가 필요하다.

데이타 복제는 크게 3가지 레벨에서 진행할 수 있다.

① 솔루션 레벨의 데이타 복제

첫 번째는 솔루션 자체 기능으로 데이타 센터간 데이타 복제를 하는 방법이다. RDBMS의

경우에는 CDC (Change Data Capture)라는 방식을 사용하는데, RDBMS는 장애 복구 등을

위해서 SQL 문장이 실행될때마다 change log라는 것을 파일 시스템에 저장한다. 즉 수행

된 모든 SQL 문장을 저장해놓는다.

그 후에 복제 대상에 이 CDC log를 복제해서 replay 하는 방식을 사용한다. 이렇게 하면,

SQL을 순차적으로 다시 수행하기 때문에 완벽하게 데이타를 복제할 수 있다.

MySQL의 replication 기능이나, Oracle社의 Golden Gate등이 이런 기능을 수행한다.

NoSQL의 경우, Cassandra,HBase 등도 이러한 데이타 복제 기능을 솔루션 레벨에서 가

지고 있다.

② 애플리케이션 레벨의 데이타 복제

솔루션의 조금 더 상위단에서 센터간의 데이타 복제를 수행할 수 있는데, RDBMS의 경우

ETL (Extract Transform Loading)과 같은 솔루션등을 예로 들 수 있다. 이는 특정 RDBMS

에 의존성 없이 RDBMS면 일반적으로 사용할 수 있는 솔루션인데, 업데이트 된 내용을

select한후에, 복제 대상에 다시 insert, update등을 해야 한다.

이를 위해서 select를 이용해서 데이타를 추출하기 위해서, 운영 테이블을 그냥 사용할

수 없고, 복제할 데이타만 별도로 인터페이스 테이블과 같은 곳에 별도 저장해서 전송을

하거나, 어디까지 복제 했는지를 알리는 index 컬럼 같은 것을 추가해야 한다. 즉 앞단의

솔루션 레벨의 복제와는 다르게 애플리케이션단의 설계상의 변화가 필요하다. 비단 ETL

이 아니더라도, 솔루션 자체 영역 이외의 영역에서 기타 솔루션이나 애플리케이션으로

직접 구현하는 방법이다.

③ 인프라 레벨의 데이타 복제

마지막 방법으로는 하드웨어 인프라 레벨에서 복제를 수행할 수 있다. DRBD9와 같은 솔

루션이 대표적인 예인데, 디스크 자체를 블록 레벨에서 복제 하는 방법이다. 주로 하드웨

어 기반의 HA (High Availibility) 구조에서 많이 사용된다.

Data Replication Topology

위와 같은 복제 방법을 이용하여 다양한 Toplogy로 데이타 복제를 구현할 수 있다.

① Multi Master

9 http://www.drbd.org/

모든 데이타 노드간에 양방향으로 데이타 복제를 하며, 각 노드에서 데이타에 대한 읽기

쓰기가 가능하다.

② Master Slave

데이타 복제를 Master에서 Slave 노드로 단 방향성으로 복제하며, Master 노드에서만 쓰

기가 허용되며, Slave 노드에서는 Read만 허용된다.

일반적으로 많이 사용하는 방식이며, 데이타 센터간 데이타 복제 뿐만 아니라, DB 의 성

능 향상을 위한 아키텍쳐로도 많이 사용된다.

FaceBook이 MySQL을 사용할때, 미국 서부와 동부에 걸쳐서 이러한 아키텍쳐를 사용하

였다.

③ Multi Write

위와는 조금 다른 접근 방법인데, 데이타베이스간의 replication을 사용하지 않고, 복제가

필요한 데이타 베이스 모두에 write시에 동시에 write를 하는 방법이다. MySQL 복제 솔

루션중 하나인 Garela가 이런 아키텍쳐를 사용하며, 또는 애플리케이션적으로도 구현이

가능하다.

센터간의 데이타 복제는 글로벌 시스템의 경우에 매우 중요한 요소지만, 구현이 대단히 까다

롭다. 지역적으로 멀리 떨어져 있기 때문에, 네트워크 latency가 크기 때문에 복제시에

latency가 생기기 때문에 애플리케이션 역시 이에 대한 고려가 되어 있어야 한다. 필요한 경

우에는 데이타 복제를 하는 두 데이타센터간을 전용선을 이용해서 전용 복제 라인을 만들 수

있지만, 비용이 대단히 많이 드는 일이다. (페이스북의 경우에는 미국 서부와 동부의 데이타

센터를 전용선으로 연결하였다.) 같은 도시내의 경우에는 충분히 해볼만한 일이지만, 도시를

벗어나는 도시간이나 국가간의 데이타 전송은 비용적인 문제가 충분히 고려되어야 한다.

(국내에도 보험사등에서 시스템 이전시에 두 데이타 센터를 전용선으로 연결하여, 데이타를

복제 시킨 후, 무정지로 시스템을 이전 시킨 사례가 있다.)

4) L10N과 I18N

마지막으로 지역화(Localization)와 국제화(Internalization)이다.

지역화는 L10N이라고도 하는데, 소프트웨어를 그 지역에 맞게 지역화 하여 수정하는 것을 의미한

다. 언어를 그 국가에 맞추는 것은 물론이고, 키보드 입력 체계, 화폐 단위($,\ 등)와 기타 각종

길이나 무게 단위를 그 나라에 맞게 변경해야 한다.

국제화는 I18N이라고도 하는데, 이 I18N은 소프트웨어가 동시에 여러 지역화를 지원할 수 있는

구조로 되어 있는 것을 정의한다. MS OFFICE가 좋은 예가 되는데, MS OFFICE는 설정에 따라서

한국어,일본어,영어,중국어등 다양한 국가의 설정을 반영할 수 있다.

이 국제화와 지역화는 각 국가에 따라서 단순하게 언어의 변경 뿐만 아니라 여러가지를 고려해야

하는데, 예를 들어 커서의 이동이 일반적인 경우에는 좌측우측으로 이동하지만, 국가에 따라서

는 우측좌측으로 이동하는 경우도 있고, “X”의 의미가 YES라는 의미로 사용하는 나라가 있는 반

면 NO라는 의미로 사용하는 경우도 있기 때문에 진출하고자 하는 나라의 소프트웨어에 대한 문

화 이해가 필요하다.

지금까지 간략하게나마, 근래에 많이 사용되는 대용량 시스템에 대한 레퍼런스 아키텍쳐를 살펴

보았다. 전체적인 소프트웨어 스택과 각 컴포넌트에 대한 기능 및 고려 사항을 설명하였지만, 일

부분에 불과하며 어디까지나 레퍼런스 아키텍쳐이다. 이 아키텍쳐를 기반으로 여러가지 variation

을 할 수 있고, subset으로 구성할 수 있다. 물론 아키텍쳐상의 변화는 많겠지만 큰 흐름이나 뼈

대 자체는 크게 변화가 없다.

5장 아키텍쳐 아키텍쳐 - 조대협의 블로그...

Documents