 |
|
난이도 : 중급 Stephen B Morris, CTO, Omey Communications
옮긴이: 박재호 이해영 dwkorea@kr.ibm.com
2008 년 8 월 19 일 오늘날 조직은 두 가지 중요한 전사적 아키텍처 요구사항의 도전에 직면하고 있습니다. 바로 유연성에 대한 필요와 규제 관리에 따른 부담입니다. 이런 요구사항은 서로 상극처럼 보입니다. 비즈니스 프로세스가 유연하면, 이런 프로세스를 관리하는 작업은 어려워질지도 모릅니다. 연재물 중 여섯 번째인 이번 기사에서는 이런 문제를 해결하기 위한 핵심적인 전사적 아키텍처(EA) 품질 속성으로 관리성이라는 개념을 설명합니다. EA 개발은 진행중인 프로세스이며, 이번 기사의 핵심은 EA 속성으로서 관리성을 추가해 조직 프로세스, 시스템, 소프트웨어를 관리 가능하도록 만드는 데 있습니다.
오늘날 조직은 두 가지 중요한 전사적인 아키텍처 요구사항의 도전에 직면하고 있다. 바로 유연성에 대한 필요와 규제 관리에 따른 부담이다. 이런 요구사항은 서로 상극처럼 보인다. 비즈니스 프로세스가 유연하면, 이런 프로세스를 관리하는 작업은 어려워질지도 모른다. 유연성에 대한 요구가 커질수록 관리는 좀 더 어려워진다. EA 품질 속성으로서 관리성 활용은 이런 문제를 해결하는 데 도움을 준다. EA가 관리성을 지원한다면, EA의 구현 요소는 조화를 이룰 수 있다. 다시 말해, 이런 조화는 필요한 비즈니스 유연성과 관리성에 필요한 수준을 충족한다. 이 기사는 핵심적인 EA 품질 속성으로서 관리성이라는 개념을 설명한다. 여기서는 아파치 제로니모(Geronimo)와 IBM WebSphere 응용 서버라는 관리성을 지원하는 도구 두 가지를 설명한다. EA 개발은 진행 중인 프로세스이며, 이번 기사의 핵심은 EA 속성으로 관리성을 추가해 조직 프로세스, 시스템, 소프트웨어를 관리 가능하도록 만드는 데 있다. 이런 관리성은 비즈니스가 필요로 하는 IT 기반 구조를 이끌며, 유연성을 제공하며, 규제 관리를 촉진하는 등 다양한 목적에 사용한다.
기술과 역량
이 연재 지난 회에 소개된 기사에서는 조직에서 늘어나는 아키텍처의 중요성을 토론했다. 직전 기사에서 휼륭한 아키텍처가 IT 기반 구조에 이익을 줄 뿐만 아니라 비즈니스 가치도 높인다는 교훈을 설명했다. EA를 통해 사람, 프로세스, 기술을 효과적으로 연결하는 방법으로 이런 목표를 달성한다. 이번 기사에서는 아키텍처 품질 속성으로서 관리성에 얽힌 쟁점과 어떻게 관리성이 유연성을 높이고 EA 수명을 연장하는지 방법을 살펴보겠다. 하지만 관리성이란 개념은 다소 추상적이다. 관리성이 무엇을 의미하는지 좋은 예제가 없을까?
한 문장으로 설명하자면, 관리성은 시스템이나 소프트웨어 상태를 바라보고 변경하는 능력을 의미한다. 관리 활동은 컴퓨터 재시작부터 대규모 급료 지불에 이르기까지 크기와 범위가 다양하다. 여기서 설명할 두 가지 예제는 각각 기계 단위에서 상호 작용과 비즈니스 프로세스 시작을 다룬다.
연관된 EA가 아키텍처적인 품질 속성으로 관리성을 포함한다면, 위에서 언급한 활동은 쉽고 (더욱 중요하게) 자동으로 수행이 가능하다. 이렇게 해서 얻는 장점은 전사적인 범위로 퍼진다.
모든 활동은 관리 운영이다
비즈니스 프로세스를 분리하는 작업은 실제로 관리 활동이 아니라고 생각할 것이다. 이런 활동은 전통적으로 관리 작업에서 분리되어 독자적으로 존재해왔다. 내 의견에 따르면 이는 실수다. 시스템과 소프트웨어 사이에 일어나는 모든 상호 작용은 개념적으로 관리 활동이다. 전자편지를 여는 작업도 일반 사용자가 시작한 관리 활동이다. 여러 서버를 지원하는 데이터베이스 백업 작업 역시 관리 활동이다. 명백하게 후자는 IT 관리자가 수행하는 활동이지만, 두 활동 모두 근본적으로 관리 운영이다. 차이점은 범위와 확장성이다.
특정 사용자 기계에서 서버로 파일을 대량으로 복사하는 작업은 가용 대역폭에 확실히 영향을 미친다. 따라서 각 사용자는 전반적인 관리(즉, 컴퓨터와 네트워크) 환경에서 상당한 영향을 미치는 활동을 할 수 있다. 이런 활동은 관리 환경 상태에 영향을 미칠 수 있기에, (무심코 수행하긴 했지만) 개념상 관리 활동이 된다.
독립적인 활동으로서 응용 프로그램 상호 작용과 IT 운영은 (겹치지 않으면서도 상호 의존적인) 너무나 많은 사일로를 만들어내는 경향이 있다. 예를 들어, 이런 사일로 접근법으로 인한 결과는 SOA(Service-Oriented Architecture) 이주를 훨씬 더 어렵게 만든다.
대다수 활동은 관리 운영으로 봐야 하며, EA가 관리성을 주요 아키텍처적인 품질 속성으로 포함할 때 좀 더 손쉬워진다. 이런 EA는 신원, 영향, 자원 활용을 기반으로 특정 활동을 허용하거나 허용하지 않는 방법으로 질서를 유지하는 장점을 제공한다.
관리성 이해하기
관리성이라는 개념 이해는 EA 관리성을 위해 필요한 기술과 역량의 기초를 다진다. 관리성이 높은 소프트웨어와 시스템의 주요 특성은 다음과 같다.
- 감시와 통제 시스템
- 자동화된 운영
- 사건 주도 관리
- 패턴 지원
- 모델 기반
이런 특성은 이어지는 절에서 살펴보겠다.
감시와 통제 시스템
관리자는 소프트웨어와 시스템 상태를 파악해 필요에 따라 변경하는 감시와 통제 시스템을 활용할 수 있다. 이런 소프트웨어와 시스템 기능을 기술적인 관점에서 정리하면 다음과 같다.
- 스크립트를 지원하는 간단한 명령행 인터페이스
- SNMP(Simple Network Management Protocol), WSDM(Web Services Distributed Management)와 기타 표준
- 독점 기술
통신이나 유닉스/리눅스(UNIX®/Linux®) 영역에서 사용하는 많은 시스템은 관리를 위한 스크립트를 전문적으로 사용한다. 스크립트 기반 관리는 제대로 동작하지만, 확장성과 복잡성이라는 문제를 안고 있다. 관리 대상이 특정 경계 조건을 넘어가면(일반적으로 50노드 정도), 스크립트는 다루기 어려워진다. 또한 해석이 필요하기 때문에 스크립트 사용 과정에서 성능 병목이 생긴다. 몇몇 관리 시스템은 심지어 그림 사용자 인터페이스를 제공하기도 한다. 물론 이런 소프트웨어 뒷단에서는 스크립트를 사용한다.
SNMP, WSDM, 그 밖에 DMTF(Distributed Management Task Force)와 같은 엇비슷한 표준이 추상화 단계를 높여주는 이유는 근본적으로 모델 기반이기 때문이다. 관리 자료는 미리 정의되어 있으며 확장 가능하며, 간단한 프로토콜을 제공해 자료 접근과 변경을 허용한다. 하지만 두 기술 모두 시스템과 소프트웨어가 성장함에 따라 제대로 확장을 따라가지 못한다. 그럼에도 불구하고 관리 기능이 전혀 없는 경우와 비교하면 상황이 훨씬 더 좋다.
독점 기술은 임베디드 웹 서버와 같은 시스템을 포함한다. 웹 응용 프로그램용으로 유용한 반면에, 독점 정책은 일반적으로 성능과 확정성 측면에서 제약이 많다.
자동화된 운영
진짜 관리성을 제공하는 핵심 요소는 자동화된 운영이다. 자발적인 운영과 복원력은 IBM 자율 컴퓨팅 선도 프로젝트에서 성공적인 최종 목적지를 보여준다. 로그 파일 검사와 자동 프로세스 재시작 같은 저수준 세부 사항을 소프트웨어가 다룰 수 있기 때문이다. 사용자 개입을 줄임으로써 자동화가 가능해진다. 따라서 닫힌 고리라는 자동화는 자율 컴퓨팅 시스템 결과물 중 하나다.
사건 주도 관리
정보 제공 개체는 상태, 메모리 적재, 실패 모드에 대한 직접적인 정보를 자동으로 제공한다. 다시 말해, IT 관리자가 자료 더미에 푹 빠지지 않고서도 개체와 관련한 중요한 문제를 바로 따라잡도록 만든다. 이를 위한 일반적인 메커니즘은 사건이다. 어떤 중요한 문제가 생길 때 관리 하에 있는 개체가 능동적으로 보내는 메시지 말이다. 예를 들어, 메모리에 올라오는 시스템이 허용된 경계 조건을 벗어날 경우에 사건이 발생한다. 시스템은 정의된 경계 조건을 초과하는 상황을 감지해 사건 메시지를 보낸다. 여기서, 너무 많은 출력 결과로 인해 (심지어) 사건 메커니즘이 관리 중인 개체에서 귀중한 컴퓨터 자원을 잡아먹는다는 전통적인 문제가 있다.
패턴 지원
패턴 지원은 예를 들어 설명하면 가장 쉽다. 자바(Java™) 2 플랫폼 마이크로 에디션(J2ME™) 플랫폼은 휴대전화, PDA, TV 셋톱박스 등과 같이 자원 제약이 있는 작은 장치에서 사용하도록 설계되었다. J2ME에서 흥미로운 점은 단지 유한한 개수만큼 잘 정의된 상태 전이가 일어나도록 보장하는 방법으로 플랫폼에서 소프트웨어 동작을 통제하는 응용 프로그램 관리자를 지원한다는 사실이다. 이는 프로그래머에게 무거운 짐을 내려놓도록 만들고, 유일한 요구사항을 특정 패턴에 맞춰 작성한 J2ME 코드로 제한한다. 프로그래머가 반드시 작성해야 하는 자바 메서드는 startApp(), pauseApp(), destroyApp(), 생성자다. 이런 패턴을 따르면, 응용 프로그램 관리자가 수행을 뒷바라지한다. 자바 2 플랫폼 스탠다드 에디션(J2SE™)과 자바 2 플랫폼 엔터프라이즈 에디션 (J2EE™)은 자원 제약이 있는 플랫폼에서 돌아가지 않으므로 비슷한 배포 패턴 기능을 제공하지 않는다.
모델 기반 운영
관리를 위한 모델 지원 영역은 SNMP, CIM(Common Information Model), CMIP(Common Management Information Protocol) 등으로 분리되어 있다. 각 모델마다 장단점이 있다. 전통적으로 가장 큰 단점은 분리다. 관리 기능은 일반적으로 추가 모듈 형태로 구현되며, 개발 끝 무렵이나 (더 나쁘게는) 개발 완료 후에 소프트웨어와 결합된다.
하지만 EMF(Eclipse Modeling Framework)처럼 새로운 기술과 더 최근에 나온 GMF(Eclipse Graphical Modeling Framework) 같은 기술은 이런 문제를 해결해줄지도 모른다. 이런 도구는 주요 개발과 동시에 모델을 정의하는 수단을 제공한다. 실제로 EMF와 GMF를 사용해 만든 시스템과 소프트웨어는 처음부터 모델 기반으로 돌아간다. 이는 관리성을 제공하는 EA를 위한 좀 더 자연스러운 기초가 된다. 구성 요소가 관리 가능하다면, 전반적인 아키텍처 또한 관리가 가능해야 한다.
관리 문제
거의 30년 동안 공을 들여왔음에도 불구하고, 시스템과 소프트웨어 관리 문제는 여전히 핵심 사항이 해결되지 않은 채로 남아있다. 이유는? 주요 이유는 다음과 같다.
- 독점 소프트웨어의 폐쇄성
- 관리성은 차별화 대상이 아니다.
오픈 소스 유행이 시작되기 전에, 대다수 소프트웨어는 개발자와 설계자를 제외한 나머지 사람에게는 문을 걸어 잠그고 있었다. 함축적으로 이런 유행은 관리 수단에 최소 추구, 기본 표준, 독점이라는 본질적인 특성이 있음을 시사했다. 따라서 X라는 회사에서 만든 소프트웨어는 역시 X라는 회사에서 만든 관리 도구를 요구했다. 물론 이런 도구가 존재할 때 이야기지만.
관리성을 차별화 대상으로 취급하지 않기 때문에, 일반적인 회사는 진짜 끝과 끝을 연결하는 해법으로 서비스와 제품을 제공할 기회를 놓치고 있다. 이제 EA가 신흥 세력으로 등장하자, 전반적인 관리성 쟁점이 새로운 형태로 다시 떠오르고 있다. SOA를 위한 EA 요구사항은 이제 전형적으로 서비스 중심, 느슨한 결합, 쉬운 협력이라는 요구사항과 ESB(Enterprise Service Bus) 시스템에 대한 지원을 포함한다. 이는 서버, 응용 프로그램, 자료, 서비스 등과 같은 기반 구조 구성 요소를 통합하는 접근법을 강조한다. 이런 접근법은 메시지 중심, 사건 주도, 서비스 중심이 되어야 한다.
오늘날 EA에 대한 지속적인 중요성은 아키텍처 품질 속성으로서 관리성이라는 요구를 뒷받침하는 흥미로운 배경을 제시한다.
비즈니스 프로세스, IT, 서비스 관리성 이해하기
연재물에 실린 직전 기사에서는 현존하는 기술, 비즈니스 관례, 서비스에 대한 전사적인 분석의 중요성을 강조했다. 이런 분석 작업은 EA 관리성에 대한 요구사항이 있을 경우 중요한 활동으로 남을 수 있다. 다음 절은 좀 더 세부적인 사항을 설명한다.
도구와 기술
다행스럽게도 EA 설계는 완전히 새로운 도전이 아니다. 도움을 줄 만한 훌륭한 정보는 다음과 같다.
- The Open Group Architecture Framework(TOGAF)
- Enterprise Unified Process(EUP)
- Zachman Framework
이런 도구 활용은 관리성 관점에서 EA 비전을 명확하게 만드는 작업을 돕는다. 특히, EUP 활용이 EA 프로젝트 비용을 줄이는 이유는 현재까지 RUP에 투자한 비용을 보존해 주기 때문이다.
TOGAF
TOGAF는 EA를 개발하는 방법론이며 툴킷을 포함한다. TOGAF가 아키텍처 속성으로서 관리성을 포함하는 훌륭한 프레임워크인 이유는 TOGAF가 아키텍처 구성 요소, 관계, 설계와 발전에 대한 원칙 및 지침을 정의하기 대문이다. TOGAF는 기본적으로 아키텍처 개발 방법이며 우수 사례, 실질적인 사례 연구에 대한 참조, 개발 지침을 포함한다. TOGAF는 방법론, 모델과 패턴 저장소, 지침 목록이라는 세 부분으로 구성되어 있다.
TOGAF 배포물 중 하나는 변경을 위한 요구사항에 현존하는 구현 장점과 제약사항에 대한 정보를 결합하는 방법으로 만들어진 목표 아키텍처 집합이다.
따라서 관리성이 현재 시점에서 요구사항이 아니라면, TOGAF는 구현까지 지연이 가능한 수단을 제공한다. 다시 말해, 요구사항을 기록하고, 모델링하고, 필요에 따라 나중에 구현할 수 있게 된다. 한 가지 더 좋은 기능은 해당 회사 내부에서 사용할 전사적인 아키텍처 개발 목적을 위해 어떤 회사라도 TOGAF를 내려받을 수 있다는 사실이다. 이는 또한 아키텍처 생성 비용을 줄이는 과정에서 도움을 준다.
EUP
또 다른 유용한 기술은 EUP다. 이는 IBM RUP(Rational Unified Process)® 확장이다. EUP가 RUP 확장이라는 사실은 현재 사용하는 RUP 기술을 대체하는 대신 확장을 의미하므로 활용 과정에서 비용을 줄여준다. 이런 이유 때문에 EUP를 적용하는 경우에 먼저 RUP를 사용하고 EUP로 이주하는 접근 방식을 권장한다.
RUP와 마찬가지로 EUP 단계는 유연하게 활용이 가능하다. 예를 들어, 팀이 제품을 시작 시점으로 되돌릴 수 있다. 아니면, 구현에서 개선으로 단계를 변경할 수도 있다. 후자는 몇 가지 전사적인 아키텍처 요구사항을 도입하거나 바꿀 필요가 있을 때 사용이 가능하다. 알기 쉬운 예제는 전사적인 아키텍처 관리성 도입이다.
EUP는 전사적인 단계에서 운영과 지연을 포함한 여러 규칙을 소개한다. 여기에 일곱 가지 전사적인 규칙을 정리했다.
- 전사적 비즈니스 모델링
- 포트폴리오 관리
- 전사적 아키텍처
- 전략적 재사용
- 인력 관리
- 전사적 관리
- 소프트웨어 프로세스 개선
RUP와 EUP 사이에 드러나는 차이점은 EUP가 전체 IT 생명 주기를 다룬다는 점이다. RUP는 단지 생명 주기에서 소프트웨어 개발 부문만 다룬다. TOGAF와 EUP/RUP 사이에 드러나는 명백한 차이점은 EUP는 RUP 투자를 재사용하도록 허용한다는 점이다. 이는 비용 절감 측면에서 유리하다.
Zachman Framework
Zachman Framework이 현존하는 EA 문맥에서 유용한 이유는 EA 구성 요소를 표현하기 위해 쓰일 수 있기 때문이다. 따라서 만일 요구사항이 관리성 지원 추가라면, Zachman은 시작 지점을 건너뛰는 데 도움을 줄지도 모른다.
Zachman은 EA를 위한 또 다른 프레임워크이며, 전사적인 아키텍처 정의와 모델링을 위한 정형화되고 구조화된 방식을 제공한다. Zachman Framework는 여섯 가지 기본 의문사(무엇을, 어떻게, 어디서, 누가, 언제, 왜)와 이해 관계자 그룹과 관련한 여섯 가지 구분 모델 유형(예언자, 소유자, 설계자, 건설자, 구현자, 작업자)에 기반을 둔 2차원 분류 모델을 제공한다. 2차원 Zachman 모델의 목표는 모델 대상 기업의 전반적인 시각을 제공하는 데 있다.
Zachman은 종종 전사적 기술이나 시스템 아키텍처를 검토하는 데 활용된다. Zachman이 TOGAF나 EUP와 다른 점은 기술 개발자나 사용자 공동체에는 별로 관심을 끌지 못하지만 IT 아키텍트에게 인기가 있기 때문이다. 반면에 특정 조직의 소프트웨어 아키텍처를 평가하는 과정에서 사용될 수 있다. Zachman을 비판하는 사람들은 너무 많은 문서를 만들어낸다고 평가한다. 하지만 EA 쟁점을 고려할 때 현존하는 아키텍처를 이해하고 개선하기를 원하는 조직에 적용이 가능하다. 따라서, Zachman은 아키텍처를 계획하고 있지만 현존하는 아키텍처를 완전히 뜯어 고칠 계획이 없는 조직에 유리하다.
학습 자료
EA 관리성 맥락에서 제로니모와 WebSphere® 응용 서버는 연구할 가치가 있다.
제로니모
단순히 이론적인 고려 사항을 논의하는 수준을 넘어서, 제로니모는 이미 이 기사에서 설명한 몇 가지 기능을 구현했다. JMX(Java Management Extension)와 제어 전환 개념에 기반을 두고 제로니모 커널에 있는 모든 객체는 MBean이다. 제로니모에서 제공하는 서비스는 GBeans를 사용해 기술하는데, (놀랍게도) MBeans가 아니라 제로니모에 특화된 특성이 있다. GBeans는 시작, 중지, 실패를 포함한 유한한 상태 집합을 따르는 독자적인 관리 단위다.
제로니모는 호환성이 좋은 응용 프로그램 서버이며, 기계 두 대 이상에서 서비스를 담당할 수 있다. 명백히 이런 서비스를 위한 내장 관리성은 EA 관리성 측면에서 이 기술을 고려할 만한 끌리는 요소다. 제로니모는 처음부터 관리성 기능을 탑재했으며 이미 동작하는 시스템이기 때문이다. 시작부터 이를 고려해 제로니모를 자세히 연구한다면 EA 관리성에 이르는 길을 찾을 수 있다.
WebSphere 응용 서버
제로니모와 마찬가지로, WebSphere 응용 서버도 J2EE 제품과 호환되며, 다음을 비롯해 포괄적인 관리 지원을 포함한다.
- 스크립트
- 문제 측정
- 서버 관리
- 세션 관리
- 배포
- 자원 설정
WebSphere 응용 서버는 또한 J2EE 관리 API를 지원하므로, 사용자가 프로그램을 활용해 관리 운영을 수행할 수 있다. WebSphere 응용 서버보다 제로니모를 선택하는 이유는 대부분 도입 결정에 달려있다. 이 절은 특정 시스템을 권고하지 않는다. 각각 장단점과 추종자가 있기 마련이다.
중간 목표
EA 관리성을 이해하는 첫 단계는 올바른 요구사항 정의다. 기술과 역량 절을 참조해 시작에 필요한 몇 가지 요구사항 템플릿을 만들자. EA 관점에서 관리성 정의는 연관된 품질 속성 세부 사항을 포함한다.
다음 주요 과제는 EA 이해이며, 이런 목적을 위해 직전에 설명한 도구 중 하나를 활용할 수 있다. 특정 조직이 추구하는 목표가 EA 개발이라면, TOGAF나 EUP를 사용하면 된다. 이미 RUP에 투자했다면, RUP 확장 형태인 EUP가 적절하다. 반면에 EA 이해가 필요하다면, Zachman이 적절한 선택이다.
품질 속성으로서 관리성을 포함한 EA 생성은 도전적인 작업이다. 하지만 현존하는 도구와 기술은 EA가 자연스럽게 진행하는 프로젝트일 뿐이라는 사실을 지적한다. 또한 관리성을 위한 주요 구성 요소는 밝혀져 있으며, 몇몇 플랫폼과 제품은 이미 몇몇 요구사항을 제대로 지원하고 있다.
관리성을 포함한 EA를 생성했다면 성공을 판단하는 기준은 무엇일까? 이에 답하려면 요구사항으로 돌아가서 제대로 충족하는지를 살펴보자. 다음 질문은 훌륭한 지침이다.
- EA 구성 요소가 감시와 통제 시스템을 갖추고 있는가?
- 자동화된 운영이 가능한가?
- EA 구성 요소가 사건 주도식인가?
- EA가 모델 기반인가?
이런 질문과 기타 질문에 대한 대답은 한번에 모두 제공할 필요가 없다. EA가 관리성을 높이기 위해 확장을 결정하는 시기에 맞춰 대답할 수 있다.
요약
SOA로 향한 추세가 가속화되면서, 관리성에 대한 요구가 점점 늘어나고 있다. SOA가 현존하는 IT 자원을 한계점까지 제한할지도 모르기에 이런 현상이 생긴다. SOA는 단지 막 고개를 내밀었을 뿐이다. 따라서 EA 관리성을 조사하기 위한 결정은 중요하며, 중요성은 시간이 흐름에 따라 점점 더 커질지도 모른다.
참고자료 교육
제품 및 기술 얻기
- IBM 제품 평가판을 내려받아 DB2®, Lotus®, Rational®, Tivoli®,
WebSphere®와 같은 응용 프로그램과 미들웨어에 친숙해지자.
토론
필자소개 | | | Stephen Morris는 아일랜드 소재 Omey Communications의 CTO다. 20년 동안, Stephen은 세상에서 가장 큰 몇몇 네트워크 회사를 위해 J2EE/J2SE 기반 네트워크 관리 시스템, 청구서 응용 프로그램, SNMP 엔티티 이식과 개발, 네트워크 디바이스 기술, GSM 모바일 네트워크 응용 프로그램을 포함한 대규모 소프트웨어 프로젝트를 진행해 왔다. Morris는 Network Management, MIBs and MPLS: Principles, Design and Implementation(Prentice Hall PTR, 2003)의 저자이며, InformIT와 OnJava.com에 네트워크 관리와 기타 주제에 대한 여러 기사를 작성했다. |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
