6. Software Architecture Styles

각 스타일별 주요 포인트

언제 사용하는가? 컴포넌트와 연결자는 어떻게 되는가? 장단점은?

 

Batch Sequential

타겟 시스템의 기능이 dataset를 조작하기 위하여 독립적인 구성 요소로 decompose 된다.

구성 요소는 일련의 데이터 변환을 순차적 및 배치 방식으로 수행합니다.

사용자는 모든 배치 처리가 완료 되기전까지 interact 할 수 없고, 끝날때까지 기다려야 합니다.

대용량 처리에 용이. 각 서브 시스템을 독립적으로 처리하는 프로그램이 될 수 있음.

 

Pipe and Filter

필터는 데이터 세트를 조작하는 구성 요소를 나타내고,

파이프는 데이터 세트를 필터 간에 스트림 모드로 전송하는 데이터 버스를 나타낸다.

이는 Batch Sequential Architecture Style로 한 번에 전체 데이터 세트를 전송하는 것과 대조된다.

 

Benefits

• Concurrency: It provides high overall throughput for excessive data processing.
• Reusability: Encapsulation of filters makes it easy to plug and play, and to substitute.
• Modifiability: It feature low coupling between filters, less impact, from adding new filters and modifying the implementation of any existing filters as long as the I/O interfaces are unchanged.
• Simplicity: It offers clear division between any two filters connected by a pipe.
• Flexibility: It supports both sequential and parallel execution.

Drawbacks

• It is not suitable for dynamic interactions.
• A low common denominator is required for data transmission in the ASCIII formats since filters may need to handle data streams in different formats, such as record type or XML type rather than character type.
• Overhead of data transformation among filters such as parsing is repeated in two consecutive filters.
• It can be difficult to configure a pipe and filter system dynamically.

Layered

‘관심사에 분리(Separation of concerns)’에 따라 시스템을 유사한 책임(관심)을 지닌 Layer로 분해하고

각각의 Layer가 하위 Layer에만 의존하도록 구성하는 아키텍처 패턴 (Organized Vertically)

각 레이어는 인터페이스를 가진 가상 머신. 가상 머신은 엄격한 순서 관계에 따라 상호작용.

각 계층에는 시스템에서 고유한 역할이 부여되며, 바로 아래 계층에서 제공하는 서비스를 호출한다.

하위 레이어는 상위 레이어 사용 불가.

가상 머신

• 레이어의 목적은 가상 머신의 제공
• 이식성(portability) 향상이 목적.

장점

전체적인 시스템의 결합도를 낮추고,

개발자의 인지 과부하를 방지하며,

재사용성을 높이고 유지보수성을 향상.

 

프로젝트 도메인이 복잡하 논리를 포함하지 않거나,

확장성보다는 일관성을 가져가는 것이 목표이거나,

소규모로 구성된 팀인 경우에는 적용하기 좋다고 생각.

 

단점

프로젝트 규모가 커질수록, 확장성이 떨어짐.

레이어로 분리된 관심사 외에 다른 관심사가 발견된 경우, 패키지 분리 및 코드 배치가 난감한 경우가 발생.

복잡한 비즈니스 논리를 해결하고 성능적 이점을 얻기는 어려움.

MVC

GUI가 있는 시스템을 모델, 뷰, 컨트롤러의 세개의 컴포넌트로 구분하는 아키텍처. 

유저 인터페이스와 비즈니스 로직들을 서로 분리하여 개발하는 방법

 

MVC 모델 작동 순서

1. Controller로 사용자의 입력이 들어옴
2. Controller로 Model에 데이터를 업데이트
3. Model은 해당 데이터로 보여줄 View를 업데이트하여 화면에 보여 주게 됨

장점

• Separation of Concern 달성 (재사용성, 유지 보수성)
• 동일한 모델로부터 다양한 View들을 표현할 수 있음
• View의 추가, 변경, 삭제가 자유로움. model과 decouple 되어 있으므로.
• View들의 동기화
  모델의 변경전파 메커니즘에 의하여 데이터 변경사항 통지.
• 뷰와 모델에 영향을 끼치지 않고 워크플로우를 수정하는게 수월함.
• Persistent 데이터 스토어가 view, control에 영향을 미치지 않음.

단점

• 간단한 애플리케이션에 적용하기에는 복잡성만 증가.
• View와 Controller는 밀접히 관련되어 있음.
• View와 Controller는 모델에 의존.
  모델의 인터페이스를 변경하면 View와 Controller도 변경 되어야 함.

 

Blackboard

Shared data, database와 같은 데이터 중심 패턴 중에 하나
명확히 정의된 문제 해법이 없을 때 문제를 풀어가는 하나의 방식을 정의한 패턴
대략적으로 해법을 수립하기 위해 특수한 서비스 시스템의 지식을 조합하는 패턴

그 다음 단계의 결과가 실행할때마다 다르게 나올 수 있는 알고리즘을 구현하는데 사용되는 스타일

ex) 음성인식, 차량식별, 신호해석

• 블랙보드(blackboard) : 솔루션의 객체를 포함하는 구조화된 전역 메모리
• 지식 소스(knowledge source): 자체 표현을 가진 특수 모듈
• 제어 컴포넌트 (control component) : 모듈 선택, 설정 및 실행을 담당
• KS는 타 문제 도메인에 재사용될 수 있음
• 계산 결과가 항상 동일하지 않아 테스트가 어려움
• 어떤 좋은 해법도 완벽하다고 장담할 수 없음

 

Shared Repository

공유 데이터는 central data repo에 저장됨. 이 repo는 여기에 관련된 모든 client app에 의해서 접근이 가능.

Client app들은 데이터를 읽고 쓰기 위하여 pulling을 사용

장점

• Efficient way of sharing datasets among applications
• Efficient way of storing a large amount of datasets
• Separating data storage concern from data manupulation concern
• Allowing concurrent accesses to the datasets.

 

단점

• Difficulty to manage the data scheme of the repository
• Potential performance overhead due to the remote access
• Concern on Availability
• Concern on Security

 

Micro Kernel

시스템의 요구사항이 변할때, 이를 쉽게 시스템에 반영하기 위한 패턴

일반적인 시스템의 기능에서 최소 핵심 기능은 공통으로 두고 변경이 가능한 확장 부분을 플러그인 방식으로 추가할 수 있는 패턴.

장점

• 이식성이 보장 (시스템을 새로운 환경으로 이동 시, Microkernel만 수정하면 됨)
• 유연성과 교환가능성이 확보 (Internal/External Server를 수정하거나 확장)
• 유지보수성과 가변성을 향상 (정책과 메커니즘을 분리)
• 확장성 확보, 신뢰성 지원, 투명성을 제공

 

단점

• 시스템 설계가 복잡하고 개발이 어려움.
• 성능이 떨어짐. internal server와 external server에 대한 호출로 인하여, 하나의 애플리케이션에서 훨씬 많은 프로세스 간 통신이 필요함.

 

Micro Service

대형 소프트웨어 프로젝트의 기능들을 작고 독립적이며 느슨하게 결합된 모듈로 분해하여 서비스를 제공하는 아키텍처

도메인은 공통 REST 기반 웹 인터페이스 서비스를 독립적으로 배포할 수 있습니다

 

장점

• 확장성, 탄력성, 진화성
• 복잡한 애플리케이션의 지속적 배포, 배치가 가능
• 상대적으로 작아서 이해하기 쉽고 생산적일 수 있음
• 오류의 고립(Fault Isolation)을 도움
• ex) 메모리 릭이 있다면, 해당 서비스만 진행을 멈추고 다른 서비스는 지속 운영 가능.
• 새로운 기술을 도입, 적용하기가 용이

단점

• 성능, 단순성, 비용
• 개발자는 분산 시스템에서 나오는 추가적인 문제들을 다루어야 함.
• 여러 서비스를 배치 하는것이 좀 더 복잡해 짐.
• 메모리 사용량이 증가. (예를 들어 각 서비스가 각자 VM을 사용하는 경우)

 

Dispatcher

Client에게 QoS가 높은 서버를 연결하기 위하여 중간에 속해 있는 서버.

QoS가 높은 서버 정보를 클라이언트에 넘겨주면, Client가 직접 서버에 연결됨.

Broker보다 성능이 좋음.

Broker

서로 다른 기종의 머신에 분산되어 있는 서비스(객체 혹은 컴포넌트)간에 어떻게 협력을 잘 할지 고민하다 나온 패턴.

분산 시스템이나 RPC를 구현할 때 많이 사용됨.

브로커가 해야 할일은 server locating, request를 포워딩, 결과와 예외처리를 클라이언트 측에 전달하는 것.

 

언제 사용?

• 실제 시스템 컴포넌트를 사용하는 사용자로부터, 서비스의 구체적인 구현을 감추어야 할때(캡슐화)
• 런타임에, 시스템 컴포넌트들을 교체 할 수 있습니다.
• 시스템 컴포넌트가 어디에 위치해있던지 신경쓰지 않고 호출 가능합니다.

명령어 예

0x5001|semtax|22

0x5001은 어떠한 방법으로 요청을 처리하라는 일종의 커맨드이고, 나머지 부분이 데이터의 역할을 하게 됨.
Broker에서는 이 명령어를 파싱하여 서버에 요청 및 응답을 받아서 다시 리턴.

 

Client Server

서버 티어는 클라이어트 티어를 위한 공통 서비스를 제공. 클라이언트 티어는 사용자와 소통.

복수개의 클라이언트 앱은 서버 티어의 기능을 공유 할 수 있음.

 

장점

• responsbility 분리, 서버 components 재사용

단점

• 이기종 인프라에 대해 요구 만족 어려움, 보안취약, 
• server availability and reliability, testability and scalability 어려움

 

Publish and Subscribe

이벤트 기반의 아키텍트 스타일.

Subscriber들은 특정 이벤트를 받기 위하여 등록/해제 

Publisher들은 매시지를 브로드캐스팅. (동기/비동기 형태로)

옵저버 패턴과 유사.

 

언제 사용?

There is a need for decoupling content producers from content consumers.

There is a need to deliver the same content to multiple consumers.

There is a need to deliver the content when it is available.

There is a need to avoid polling for the content.

 

장점

• Flexibility to add new subscribers dynamically.
• Loose coupling between publisher and subscribers
• Increased Efficiency due to Reduced Polling / Pulling

 

단점

• Overhead of Distributing Events
• With broker, publishers have no control on the delivery ordering