Design Decision Model

1. 들어가면서

 

System Design이란 시스템의 구성요소인 하드웨어 컴포넌트들, 소프트웨어 컴포넌트들, 그리고 이들의 정적 및 동적 관계를 식별하는 것, 다시말해 설계 결정사항을 기획하고 이를 실행하는 것이라 할 수 있습니다. 당연히 설계를 위한 입력은 시스템의 분석모델들입니다. 다른 관점에서 표현하면 시스템의 기능을 하드웨어와 소프트웨어 컴포넌트로 변환하는 것이라고 할 수 있습니다. 따라서 이를 기능할당(Functional Allocation)이라고 합니다. 다시말해 컴포넌트를 식별한다는 것이 시스템의 컴포넌트들이 수행할 기능을 결정하는 것과 같다고 할 수 있습니다.

 

특히 소프트웨어 시스템의 경우는 모든 기능이 소프트웨어에 의해 수행되므로 소프트웨어 컴포넌트에 모든 기능이 할당되고, 하드웨어인 컴퓨터시스템은 소프트웨어를 효율적으로 실행하는 역할을 한다고 할 수 있습니다. 따라서 소프트웨어 시스템인 경우 시스템의 분석모델 중 기능모델인 use-case 모델을 시스템의 설계모델인 소프트웨어 컴포넌트 구조 모델로 변경하는 것을 설계라고 할 수 있습니다. 이때 설계의 목표는 비기능적 요구사항인 품질요구사항을 만족하는 것이며, 품질요구사항을 만족하기 위해 설계 결정사항을 모델링하는 것을 Design Decision Model이라고 할 수 있습니다. 

 

소프트웨어 시스템의 설계의 개념

2. Design Decision Modeling

 

OMG에서는 의사결정 모델을 모델링하기 위해 Decision Modeling and Notation(DMN)이라는 표준언어를 정의하고 있습니다. 이를 이용하여 Design Decison Modeling을 하고자 합니다. DMN은 비지니스 프로세스상의 의사결정을 위한 모델링언어입니다. 이중에 Design Decision을 위해 가장 간단한 DMN의 표기법을 사용하고자 합니다. 

 

DMN의 예

Decision은 입력을 받아 어떤 규칙에 의해 결정의 출력을 생성합니다. 이때 의사결정에 필요한 지식을 위한 참조 지식정보(Knowledge Source)와 비지니로직 등을 위한 정보(Business Knowledge)를 참조합니다. Decision의 규칙은 다양한 형태로 정의할 수 있습니다. 일반적인 스크립트 형태로 표현할 수도 있고, 예에서 처럼 Decision Table로 표현할 수도 있습니다. 사실 설계란 여러개의 설계 대안중에 하나를 선택하는 행위라고도 할 수 있습니다. 설계 대안은 설계시 고려할 품질 요구사항의 조합일 수도 있고, 설계 결과의 대안들일 수도 있습니다. 따라서 Decision의 입력은 설계 대안이거나, 설계의 목표가 되는 품질요구사항의 조합이 될 수 있습니다. 

 

3. 설계 대안들을 품질요구사항으로 비교하는 설계 결정사항

 

여러 솔루션이나 설계 대안들에서 품질속성을 고려하여 최적 설계대안을 결정하는 경우는 설계 대안을 식별하고, 각 설계 대안중에 품질 요구사항을 고려하여 대안을 분석 후 하나의 대안을 결정하여 설계를 수행합니다.

 

대안이 되는 OS를 결정하기 위한 Design Decision Model의 예

 

4. 품질요구사항을 고려하여 설계 대안 하나를 결정하는 설계 결정사항

 

다양한 설계대안을 고려하기 어려운 경우는 품질요구사항을 만족할 수 있는 하나의 대안을 설계하는 경우가 있습니다. 예를 들어 소프트웨어 응용구조를 설계하는 경우 소프트웨어 컴포넌트들의 다양한 조합의 대안을 설정하기 보다 다양한 품질 요구사항을 만족하는 하나의 설계대안을 결정하는 경우가 많다.

 

소프트웨어 응용구조를 BCE 패턴으로 설계하기 위한 Design Decision Model

 

5. System Architecture의 주요 설계 고려사항

 

소프트웨어 시스템을 설계하는 입장에서는 System Architecture를 Layered Architecture 개념으로 Technology, Application, Data Architecture로 구분하여 설계합니다. Technology Architecture는 Solution Architecture라고 하며, 이는 Application Software이하의 미들웨어와 하드웨어 구조를 의미합니다.

 

Layered Architecture 관점에서의 System Architecture

 

Architecture Pattern

 

Architecture Pattern은 반복적인 문제를 해결하기 위해 적용되는 문제의 해결방안이라고 할 수 있습니다. Design Pattern이 마이크로한 프로그램의 구조에 대한 해결방안이라면 Architecture Pattern은 매크로한 시스템의 구조에 대한 해결방안이라고 할 수 있습니다. 유사한 개념으로 Architecture Style이라는 용어를 사용하기도 합니다. 조금 다른 의미를 갖고 있기는 하지만 크게 이에 대한 구분 없이 사용해도 가능할 것으로 생각합니다.

 

가장 대표적인 패턴으로 생각되는 것이 Layered Architecture입니다. 이 아키텍처 패턴은 시스템의 재사용성, 확장성 등에서 유용한 구조로서 많은 시스템을 설계할 때 사용하는 아키텍처 패턴이라고 할 수 있습니다. 위에 있는 레이어의 컴포넌트들이 하래의 컴포넌트에 의존적이며, 가장 상위 레이어의 컴포넌트들이 외부 환경과 상호작용하도록 하여 환경 변화에 시스템의 컴포넌트가 영향을 받지 않도록 설계된 구조라 할 수 있습니다. 

 

Layered Architecture Pattern의 한 예

 

Distributed Architecture Pattern

 

컴퓨터시스템의 아키텍처를 구성하는 가장 일반적인 방법은 수평적 확장(Scale-out)이 가능한 분산구조입니다. 대표적으로는 n-tier 클라이언트-서버 아키텍처, Peer-to-Peeer 아키텍처, 가상화를 기반으로 클라우드 아키텍처라고 할 수 있습니다. 특별히 클라우드를 활용하는 경우는 이러한 Technology Architecture는 크게 고민하지 않고 이미 구축된 구조를 참조하여 구현이 가능할 것입니다.

 

 

Service-Oriented Architecture (SOA)

 

ESB(Enterprise Service Bus)라는 통신 미들웨어를 기반으로 각 서비스의 공통적으로 정의된 인터페이스를 통해 서비스들이 유연하게 통합 및 확장이 용이한 응용 서비스 아키텍처 패턴입니다. 예를 들어 무기체계에서는 Real-time SOA의 관점에서 DDS(Data Distribution Service)라는 통신 미들웨어 표준을 통해 SOA 패턴을 적용합니다. 그리고 일반적인 정보처리시스템에서는 Kafka라는 이벤트기반 미들웨어를 사용하여 구현하는 일반적입니다.

 

SOA 구조의 Design Decision Model의 예

 

 

Micro Service Architecture (MSA)

 

MSA에 대한 정의는 상호 공유되고 표준화된 개념이 있는 것처럼 보이지 않습니다. 다만 Monolithic Architecture가 아닌 작은 serivce들로 시스템을 세분화하여 구성하는 아키텍처 패턴을 의미합니다. 이러한 의미에서 SOA도 MSA라고 할 수 있습니다. 그러나 조금 다른 관점에서 Service-Oriented Architecture에서 시스템의 규모가 커지고 복잡해지는 경우는 개발 조직 또는 관련 기술 등에 따라 서비스를 분리하고 그 안에서 SOA를 적용하는 형태로 아키텍처를 구성하는 것을 Micro Service Architecture라고도 이해할 수 있습니다. MSA는 공유의 관점보다는 독립적으로 개발 및 운영가능한 단위로의 서비스를 분할하는 것에 우선순위를 둔 아키텍처패턴이라고 할 수 있습니다.

 

독립적인 서비스로 구성하는 MSA의 패턴

 

Zero-Trust Architecture (ZTA)

 

사이버보안은 모든 시스템 구성에 매우 중요한 품질로서 미국은 ZTA에 대한 표준안을 구성하여 모든 시스템에 적용하는 보안모델을 제시하였습니다. ZTA는 모든 시스템의 구성할 때 해당 시스템에 인터페이스 되는 Actor들을 아무도 믿지 않고 시스템에 연결된 상태에서의 상태를 늘 검증한다는 보안모델입니다.

 

ZTA의 가장 기본적인 Software Defined permeter의 개념