Architectural Pattern
소프트웨어 아키텍쳐에서 일반적으로 발생하는 문제점들에 대한 일반화되고 재사용 가능한 솔루션이다.
OReilly
Dossier
| Category | General | Distributed Computing | Communication | Event Handling |
|---|---|---|---|---|
| Patterns | Layer Pattern Hexagon Pattern Pipe&Filter Pattern MVC Pattern | Client-Sever Pattern Shared Data Pattern Multi-Tier Pattern Service-oriented Architecture Pattern P2P Pattern | Messaging Pattern Broker Pattern Publisher-Subscriber Pattern | Reactor proactor Connector-Acceptor Asynchronous Completion Token |
1. 계층화 패턴 (Layered Pattern)
n-티어 아키텍쳐 패턴
전체적인 흐름의 디자인
각 계층의 역할을 정의하여 세분화, 구조화의 목적
- 하위 모듈들의 그룹으로 나눌 수 있는 구조화된 프로그램에서 사용할 수 있다.
- 각 하위 모듈은 특정한 수준의 추상화를 제공한다.
- 각 계층은 다음 상위 계층에 서비스를 제공한다.
- 서로 마주보는 두 개의 계층 사이에서만 상호작용이 이루어지며, 변경 사항을 적용할 때도 서로 마주보는 두 개의 계층에만 영향을 미치므로 변경 작업이 용이하다.
- 특정 계층만을 교체해 시스템을 개선하는 것이 가능하다.
계층의 종류
| 계층 | ' | 설명 |
|---|---|---|
| Presentation Layer | UI Layer | |
| Application layer | Service layer | 유저 + 브라우저와 상호작용하는 로직을 가짐 |
| Business Layer | Domain layer | 요청에 맞는 비즈니스 로직을 수행 |
| Data access layer | Persistence layer | 데이터를 저장하고 관리 |
주의점
- 많은 계층을 통과하기 때문에 Performance가 안 좋아질 수 있다.
- 적용 이후에 다른 패턴을 섞거나, 수정하는데에 유연함이 떨어진다.
- 어플리케이션의 서비스가 커짐에 따라 유지하기 힘든 구조이다.
- 각 계층의 역할이 명확하여 개발과 테스트가 편해진다.
예시
- Desktop Application
- Web Application
2. 클라이언트-서버 패턴 (Client-Server Pattern)
- 하나의 Server Component와 다수의 Client Component로 구성된다.
- Server Client로 서비스를 제공한다.
- Client가 Server에게 서비스를 요청하면, Server는 Client에게 적절한 서비스를 제공한다.
- Server는 Client부터의 요청을 대기한다.
- 요청, 응답을 받기 위해 동기화되는 경우를 제외하곤 서로 독립적이다.
- Client 들은 서로 직접 통신하지 않으며, 응용 프로그램 서버와 직접 통신하거나 Broker와 통신한다.
N-Tier Architecture Pattern
대부분의 Web application은 N-Tier 아키텍처이다. Application, Server, 다수의 Client 및 DB가 있다.
N-Tier는 실제로 Layered Pattern 와 결합된 Client-Server 아키텍처이다.Client-Dispatcher-Server Pattern (CDS)
예시
- Online application : email, document share, bank
3. 마스터-슬레이브 패턴 (Master-Slave Pattern)
SETI에는 Master라는 단일 중앙 컴퓨터가 있고, Client라고 하는 인터넷 컴퓨터에 data package를 보낸다. 각 Client 는 이 데이터를 처리하고 그 결과를 Master Server로 다시 보낸다. Master는 이 결과를 DB에 통합하고 Client에게 더 많은 Data를 제공한다.
- Master와 Slave 두 부분으로 구성된다.
- Master Component는 동등한 구조를 지닌 Slave Component 로 작업을 분산하고, Slave가 변환한 결과값으로부터 최종 결과값을 계산한다.
- Dependency가 없는 대량 프로세스가 여러개 있는 경우에 이 Pattern을 사용한다.
Use
- 사용 가능한 처리 능력은 충분하지만 시간 제약이 있을 때 사용한다.
- Slave는 동일한 마이크로프로세서에서 별도의 프로세스로 실행될 수도 있지만 순차적으로 처리하지 않는 충분한 이유가 있어야 한다.
예시
- SETI
- 분산 컴퓨터 시스템
- DB 복제에서, 마스터 데이터베이스는 신뢰할 수 있는 데이터 소스로 간주되며 슬레이브 데이터베이스는 마스터 데이터베이스와 동기화된다.
- 컴퓨터 시스템에서 버스와 연결된 주변장치
4. 파이프-필터 패턴 (Pipe-filter Pattern)
- Data Stream을 생성하고 처리하는 시스템에서 사용할 수 있다.
- 각 처리 과정은 Filter Component에서 이루어지며, 처리되는 데이터는 Pipe를 통해 흐른다.
- Pipe는 버퍼링 또는 동기화 목적으로 사용될 수 있다.
- Filter는 RunTime에 Pipe를 추가 및 제거할 수 있도록 강력하게 만들어야 한다.
구성
| 요소 | 설명 |
|---|---|
| Filter | 연결된 Pipe를 통해 수신하는 Data를 변환하거나 필터링한다. Filter에는 원하는 수의 입력 Pipe와 원하는 수의 출력 Pipe가 있을 수 있다. |
| Pipe | 한 Filter에서 다음 Filter로 Data를 전달하는 Connector이다. 다음 Filter가 처리할 시간이 있을 때 까지 모든 Data를 저장하기 위해 일반적으로 Data Buffer에 의해 구현되는 방향성 Data Stream이다. |
| Pump (producer) | Data Source. Static Text File 또는 Keyboard 입력 장치가 될 수 있으며, 지속적으로 새로운 Data를 생성한다. |
| Sink (Consumer) | Data Target. 다른 File, DB, 또는 Computer 화면이 될 수 있다. |
Use
수행하기 위해 많은 Transformation이 필요하며, 유연성/강력함이 요구될 때 사용한다.
주의점
- 필터가 모든 Data(ex,Sort Filter)를 수신할 때까지 기다려야하는 경우 Overflow 또는 Deadlock이 발생 할 수 있다.
- Pipe가 단일 Data 유형만 허용하는 경우 Filter는 일부 구문 분석을 수행해야한다. 이는 상황을 복잡하게 만들고 속도를 늦추게 된다. 서로 다른 Data 유형에 대해 서로 다른 Pipe를 생성하는경우 Pipe를 Filter에 연결할 수 없다.
- Filter는 별도의 Thread로 구현된다.
예시
- Compiler (Filter : 어휘 분석, 파싱, 의미 분석, 코드 생성 수행)
- Unix Program
5. 브로커 패턴 (Broker Pattern)
Service Oriented Architecture
"You just want the job to be done.
You don't care who performs it, but you may have some demands.
Tell your broker. He will take care of it."You go to a broker to buy a house. You don't want to need to know all about the housing business, costs, quality, suppliers. You just tell the broker your maximum price and some other requirements, and he starts looking.
- 분리된 Component들로 이루어진 분산 시스템에서 사용된다.
- Component들은 원격 Service 실행을 통해 서로 상호 작용 할 수 있다.
- Broker Component는 Comopnent들 간의 통신을 조정하는 역할을 한다.
- Server는 항상 Broker에 자신을 등록 및 등록 취소를 할 수 있다.
Server에 장애가 발생하면, 시간 초과 후 Broker에 의해 자동으로 등록 취소가 된다. - Server는 자신의 기능(Service 및 특성)을 Broker에게 넘겨주며(Publish),
Client가 Broker에 Service를 특정 형식으로 지정하여 요청하면
Broker는 Client를 자신의 Registry에 있는 가장 적합한 Service 로 Redirection 한다.
Client와 Server 간의 Link가 설정되면 직접 통신을 시작하여 Broker를 해제 할 수 있다. - Multi Broker가 Architecture에 있을 수 있다. 이때, own Communicaiton Protocol이 필요할 수 있다.
Use
- Client-Server 관계가 고정되어 있지 않거나 적합한 Server 가 많거나 시간이 지남에 따라 Server의 가용성이 변경되는 경우에 사용한다.
- Server 선택은 별도의 구성 요소에 위임하기에 기준에 따라 다르다.
- Sever의 물리적인 위치에서 독립적인 경우에 사용한다.(location transparacy)
주의점
Broker를 설정하면 Service 호출을 쉽게 프로그래밍 할 수 있다. 따라서 Transaction, Exception 처리를 잘 해 주어야 한다.
예시
- CORBA (Common Object Request Broker Architecture)
- Web Services
- 메시지 브로커 소프트웨어 : Apache ActiveMQ, Apache Kafka, RabbitMQ, JBoss Messaging
6. 피어 투 피어 패턴 (Pear to Pear Pattern/P2P)
Resource 감지를 위해서 Hasing을 일반적으로 사용한다.
- 각 Component를 피어 (peers)라고 부른다.
- Pear는 클라이언트로서 피어에게 서비스를 요청할 수도 있고, 서버로서 각 Pear에게 서비스를 제공할 수도 있다
Pear는 Server,Client 의 역할이 유동적으로 변한다.
Use
- 많은 사람들이 유지 관리하고 공유해야 하는 Resource가 많을 때 사용한다.
- 고려사항
- 노드 존재 Notify
: 다른 노드의 주소 table에 이 노드의 주소를 추가하면 새 노드가 추가된다.
노드 자체는 직접 연결된 노드에 주소를 전달한다. - Resource Search
: 모든 Peer에게 요청을 보내고 응답을 기다린다.
Resource 를 찾을 위치를 각 노드에게 알려주는 Data 구조를 사용할 수 있다.
- 노드 존재 Notify
주의점
- System이 열려 있으면 오용될 가능성이 있다.
- 많은 Node가 이탈 시 Resource 감지가 어려워 진다.
예시
- 파일 공유 네트워크
- 멀티미디어 프로토콜
- 독점적 멀티미디어 애플리케이션 (Spotify)
7. 이벤트-버스 패턴 (Event-Bus Pattern)
Message Bus
relate with : Observer Pattern in Design Pattern
다양한 방식으로 서로 통신해야 하는 많은 Module이 필요한 경우.
Runtime에 Module을 추가, 제거하고 직접 통신하거나 Message를 BroadCast할 수 있다.
구성
| 요소 | 설명 |
|---|---|
| 이벤트 소스 (Event Source) | Event Bus를 통해 특정 Channel로 message를 발행(publish)한다. |
| 이벤트 리스너 (Event Listener) | 특정 Channel에서 message를 구독(subscribe)한다. 이전에 구독한 Channel에 발행된 message에 대해 알림을 받는다. |
| 채널 (Channel) | |
| 이벤트 버스 (Event Bus) |
통신
| 통신 | 설명 |
|---|---|
| Publish-Subscribe | Module은 특정 message 유형을 구독할 수 있다. Module이 Bus에 message를 게시할 때마다 해당 message 유형을 구독하는 모든 module에게 전달된다. |
| BroadCast | message가 모든 Module에 전달된다. |
| Point-to-point | 1 Message : 1 Receiver |
주의점
- Module이 많은 양의 Data를 공유하는 경우
항상 Bus를 통해 이를 Pumping 하는 것은 좋지 않다.
Module간에 Data를 공유하도록 선택한 경우 동기화 문제가 있을 수 있다.
예시
- 안드로이드 서비스
- 알람 서비스
8. 모델-뷰-컨트롤러 패턴 (MVC Pattern)
대화형 Application (interactive application)
- Model : 핵심 기능과 데이터를 포함한다.
- View : 사용자에게 정보를 표시한다 (1개이상)
- Controller: 사용자로부터의 입력을 처리한다.
- 여러 개의 뷰를 필요로 하는 대화형 애플리케이션에 적합
예시
- 일반적인 웹 어플리케이션 설계 아키텍처
- 웹 프레임워크 : Django
- GUI 응용 프로그램
- 워드 프로세서
9. 블랙보드 패턴 (Blackboard Pattern)
BlackBoard는 Knolege Source의 공통 Data 구조이다.
구성
| 요소 | 설명 |
|---|---|
| 블랙보드 (blackboard) | 솔루션의 객체를 포함하는 구조화된 전역 메모리 별도의 자료구조가 필요한 경우 board를 pannel로 나눈다. 'is-part-of' |
| 지식 소스 (knowledge source) | 자체 표현을 가진 특수 모듈 솔루션에 추가되는 구성 요소 knowlege source는 다른 knowlege source와 완전히 연결되어 있지 않다. |
| 제어 컴포넌트 (control component, Scheduler) | 모듈 선택, 설정 및 실행을 담당 |
Use
- 문제 공간은 별도의 부분으로 분해 할 수 있어야 한다.
- 문제는 상향식 및 하향식 추론과 같이 문제에 접근하는 다양한 형태가 필요하다.
예시
- 음성 인식
- 차량 식별 및 추적
- 단백질 구조 식별
- 수중 음파 탐지기 신호 해석
10. 인터프리터 패턴 (Interpreter Pattern)
- 특정 언어로 작성된 프로그램을 해석하는 Component를 설계할 때 사용.
- 언어의 각 기호에 대해 Class 생성
예시
- SQL과 같은 DB 쿼리 언어
- 통신 프로토콜을 정의하기 위한 언어
Architecture 비교
| 아키텍처 | 장점 | 단점 |
|---|---|---|
| Layered | 하위 레이어는 다른 상위 Layer에 의해 사용됨 Layer 표준화가 쉬우며 Layer 수준을 정의하기 수월 Layer를 변경해도 다른 Layer에는 영향을 끼치지 않음 | 광범위한 적용이 어려움 특정 상황에서는 특정 Layer가 불필요할 수 있음 |
| Client-Server | Client가 요청할 수 있는 일련의 Service를 Modeling 할 수 있음 | 요청은 일반적으로 서버에서 별도의 Thread로 처리. Process간 통신은 서로 다른 Client가 서로 다르게 표현되므로 Overhead 발생 |
| Master-Slave | 정확성-서비스의 실행은 각기 다른 구현체를 가진 slave 들에게 전파 | Slave가 독립적이므로 공유되는 상태가 없음 Real time System에서는 Master-slave간 latency 문제가 발생할 수 있음. 분리가능한 문제에만 적용가능 |
| Pipe-Filter | 동시성 처리를 나타냄 I/O가 Stream으로 구성되고 Filter가 Data를 수신하면서 연산을 수행하기 시작 Filter 추가가 쉬움 System 확장성이 좋음 Filter는 Reuse 가능 주어진 Filter을 재구성하여 또 다른 Pipeline을 구축가능 | 가장 느린 Filter연산에 의해 효율성이 제한될수 있음 Filter간 Data 이동에서 Data 변환 overhead가 발생 |
| Broker | 객체의 동적인 변경, 추가, 삭제 및 재할당이 가능하며 개발자에게 배포를 투명하게 만듬 | Service 표현에 대한 표준화가 필요 |
| Peer to Peer | 탈중앙화딘 컴퓨팅을 지원. 특정 노드 장애에 매우 강함 Resource 및 컴퓨팅 성능면에서 확장성이 뛰어남 | Node들이 자발적으로 참여하기 대문에 서비스 품질에 대한 보장이 어려움 보안에 대한 보장이 어려움 노드의 갯수에 따라 성능이 좌우 |
| Event-bus | 새로운 Publishers와 Subscribers 및 연결의 추가가 수월 고도로 분산화된 Application에 효과적 | 모든 message가 동일한 event bus를 통해 전달되기 때문에 확장성 문제가 발생 할 수 있음 |
| MVC | 동일한 model에 대해 여러개의 view를 만들 수 있으며, Runtime에 동적으로 연결/해제 가능 | 복잡성을 증가시키며, 사용자의 행동에 대한 불필요한 업데이트가 많이 발생 가능 |
| BlackBoard | 새로운 Application을 쉽게 추가할 수 있음 데이터 공간의 구조를 쉽게 확장 가능 | 모든 Application이 영향을 받기 때문에 data 공간의 구조를 변경하기가 어려움 동기화 및 접근 제어가 필요 |
| Interpreter | 매우 동적인 설계 가능 최종 사용자가 프로그래밍하기 좋음 Interpreter Program을 쉽게 교체 할 수 있기 때문에 유연성이 향상 | Interpreter 언어는 일반적으로 Compile 언어보다 느리기 때문에 성능 문제가 발생 할 수 있음 |
newb-grammer