잘 정의된 시스템의 기능적인 부분. 특정 Responsibility를 가지고 있고, 잘 정의된 인터페이스를 통해 다른 요소들과 연결할 수 있게 한다. 재사용 가능한 소프트웨어 모듈이고 독립성과 재사용성을 강조한다. 즉 독립적으로 교체할 수 있다.
2. Class와 Component의 차이
Class는 객체지향 프로그래밍에서 데이터와 데이터를 처리하는 메소드를 포함하는 청사진, 템플릿이다. 실제 객채를 생성하기 위한 것으로 클래스는 구현 타이밍의 유닛, 컴포넌트는 디자인 타임의 유닛이라고 볼 수 있다. 즉 컴포넌트는 하나 이상의 클래스에 의해 구현된다.
3. Component와 Package의 차이
Package는 서로 관련이 있고 함께 변경될 수 있는 요소(클래스, 인터페이스)들을 그룹화하는 데에 사용되는 네임스페이스이다. - Functional Grouping : 패키지 안의 클래스들은 한가지 기능에 대해서 매우 관련이 있고 Facade 클래스는 public으로 정의 되어 다른 패키지로 부터 클래스를 숨긴다. - Logical Grouping : 로직적으로 관련이 있는 인터페이스와 클래스들은 패키지로 묶인다. - Comceptual Grouping : 개념적으로 관련이 있는 클래스들은 패키지로 묶인다. data type이나 file stream 들이 그 예이다.
4. Decomposition을 수행하기 위한 전략들
디자인이란 일련의 Decomposition(분할)이다. 설계란 어떤 방법으로 Decomposition 하느냐에 의해 결정된다. Architectural Driver를 기준으로 각 Component와 그 관계를 분해(Decomposition)하고, 각 Component를 Component Requirement를 기준으로 클래스와 그들의 관계로 Decomposition한다. Decomposition은 Architectural Driver를 만족해야한다. Decomposition 전략들 - 기능적 분해 (Functionality) - QA 달성 : 각 QA에 맞는 Tactic의 적용(성능, 가용성..) . 변경 용이성 분해 전략 : 각 변경 사항에 대한 영향을 지역화 해야한다. shotgun Surgery 방지 . 성능 분해 전략 : 예상되는 대기 시간과 처리량을 추정해야한다. 잠재적인 병목현상을 파악해야한다. 동기화 프로세스로 분해햐여 병렬성을 활용한다. 네트워크 통신 량과 데이터 접근 빈도를 관리한다. - Archetypes : AD와 Tactic만으로 아키텍트가 직관적으로 떠올리는 기능의 묶음과 그 관계가 드러난 스케치. - 재사용 : 아키텍처나 패턴을 참조 - 코드 구현 - 공통 vs 변수 - 직접개발(Build) vs 솔루션 구매(Buy) - 팀원 배정
Tactics
1. Tactic(택틱)이란?
Tactic이란 아키택트들이 특정 품질 속성을 얻기 위해 수년간 사용해온 기술이다. 즉 각각의 품질요구사항을 달성하기 위해 정립한 설계기법이다.
2. Pattern(패턴)과 Tactic(택틱)의 차이점
Tactic은 특정 품질 속성을 개선하거나 유지하기 위한 전략이나 접근법을 의미한다. 택틱은 개별적은 문제를 해결하는 기본 원칙 또는 접근 방식으로 볼 수 있다. Pattern은 택틱들이 구체적인 솔루션 형태로 조합되어서 일반적이거나 전체적인 문제를 해결하는 방법을 설명한다. Pattern은 특정 문맥에서 반복적으로 나타나는 설계 문제를 해결하기 데에 사용되는 잘 알려진 솔루션을 말한다.
3. 성능에 관한 Tactic
Control Resource demand : 리소스 수요 통제 - 표본화 비율 관리 : Request 수요를 모두 처리하지 않고 Sampling 하여 성능을 높임. - 이벤트 반응 제한 : Request를 Queue에 보관하여 처리하는 개수를 통제. 가변성 있는 Queue를 사용하고 그 크기에 따라 리소스 수요 통제 - 이벤트 우선 순위 결정 : Request 들의 우선순위 계획을 수행하여 등급을 매기고 중요한 Request를 먼저 수행. 낮은 등급은 무시될 수 있다. - 실행 시간 제한 : 이벤트에 반응하기 위해 사용되는 실행시간을 제한함.
Manage Resources : 리소스 관리 - 리소스 증설 : 비용을 들여 더 빠른 프로세서, 추가 메모리, 추가 프로세서 - 동시성 증가 : Request를 스레드를 이용해 병렬로 처리한다. - 여러 데이터/연산 복사본 유지 관리 : 여러 서버는 연산의 복제본. 복제본의 목적은 모든 계산이 중앙 서버에서 수행될 때 발생할 수 있는 경합을 줄인다. 캐싱은 경합을 줄이기 위해 별도의 리포지토리에 데이터를 복제하는 전술.데시어를 복사하되 복사본을 일관되고 동기화된 상태로 유지하도록 해야함.
Scheduling Policy : 리소스 스케줄링 - 선입선출 FIFO, 고정 우선 순위 예약(각 소스에 우선순위를 할당하고 그 순서로 리소스를 할당), 동적 우선 순위 스케줄링
4. 가용성/신뢰성에 관한 Tactic
가용성 Tactics이란 결함이 실패가 되는 것을 방지하거나 최소한 오류의 영향을 제한하고 보수를 가능하게 하는 설계 전략이다.
Defect Faults : 결함 감지 - 문제없는지 탐지함 - Ping/Echo : 핑을 실행하고 조사 중인 구성요소에서 미리 정의된 시간 내에 에코를 다시 수신하는지 관찰. 고가용성 시스템에서는 네트워크 사용으로 비용이 발생하게 된다. - Heart beat : 주기적으로 하트비트 메세지를 내보내고 다른 구성 요소에서 이를 수신함. 고가용성 시스템에 좀 더 적합하다. - Exception : 오류가 인식될때 예외를 발생 시킴. 예외를 통해 결함을 탐지함. 단일 프로세스 내에서 작동한다.
Recover from Faults : 오류 복구 - 대안 - 투표 : 같은 입력을 서로 다른 프로세스가 처리하여 그 결과를 투표한 뒤, 투표 결과로부터 오류를 감지한다. - 활성 중복 : 모든 중복 구성요소는 병렬로 이벤트에 응답하여 결과적으로 동일한 상태에 있도록 구성. 오류가 발생하는 경우에도 빠른 응답이 필요한 고가용성 분산시스템에서 사용. 오류가 발생하면 백업이 항상 최신 상태로 복구 가능. 가동 중지 시간은 일반적으로 밀리초. - 비활성 중복 :같은 구성요소를 Active-Stanby 상태로 구성. 한개의 구성요소가 이벤트에 응답하고 다른 구성 요소(대기중)에게 수행해야하는 상태 업데이트를 알림. 동기화를 지원해야 한다. 가동 중지 시간은 일반적으로 몇 초. - 예비 : 오류가 발생했을 때 예비 구성 요소에 의해 상태를 복구한 후 재시작. 가동 중지 시간을 일반적으로 몇 분. - CheckPoint/Rollback : 체크포인트는 주기적 또는 특정 이벤트에 대한 상태의 기록을 생성. 비정상적인 상황일 때 이전에 저장한 트랜젝션 로그를 사용하여 시스템을 복원.
Prevent faults : 결함 방지 - 낌새 대응 - 서비스에서 제거 : 예상되는 오류를 방지하기 위해 일부 시스템 구성요소를 작동에서 제거함. 메모리 누수 발생히 해단 구성요소 재부팅. - 트랜젝션 : 한번에 실행취소 할수 있도록 여러 순차적 단계를 묶어놓음. 한 단계가 실패할 경우를 방지하고 동일한 데이터에 여러 동시 스레드간의 충돌을 방지 - 프로세스 모니터 : 프로세스의 오류가 감지되면 모니터링 프로세스는 해당 프로세스를 삭제하고 새 인스턴스를 실행.
Architectural Patterns
1. Architectural Pattern이란?
Pattern이란 자주 발생하는 문제에 대한 잘 확립된 해결책이다. 각 디자인 레벨 별로 Pattern이 있으며 Architectural Design Patterns는 여러가지 품질 속성에 도움이 된다. Design Pattern처럼 유지보수성만을 위한 게 아니다. Infra Structure View, Structure View로 표현 된다. 아키텍쳐 패턴은 Tactic의 Combination이다. 특정 설계 상황에서 반복적으로 발생하는 설계 문제를 제기하고 그 문제에 대한 해법을 제시한다. 그 문제의 영역은 정해져있고, 이미 기존에 입증된 설계 경험을 정리한 것이다.
2. 아키텍처 패턴의 예시와 그 패턴들의 장점
- Layer Pattern : 시스템의 일부를 영역을 나눠서 독립적으로 개발하고 발전시킬 때 사용하는 패턴. 레이어는 서비스를 제공하는 모듈의 집합으로 각 모듈이 호환성과 모듈성, 재사용을 지원하면서 적은 상호작용으로 개발하고 발전시켜야 한다. 상위 추상 레벨이 하위 추상레벨을 제어하므로 최상위 추상 레벨이 하위 추상 레벨에 의존성을 갖게 된다. 따라서 DIP 의존성 역전이 실현되어야 한다. 즉 Abstract Layer를 추가해 의존성을 역전시킨다.
- Batch Sequential Pattern : 데이터는 하나의 서브시스템에서 다음 서브 시스템으로 데이터를 전달하되 각 서브시스템 또는 모듈은 이전 서브 시스템의 데이터 처리가 끝나기 전에는 스스로 시작할 수 없다. 단방향 파이프로서 데이터 셋을 전달한다. 동시성 지원 불가, 인터렉션을 위한 인터페이스 제공하지 않음.(ex, Complier) 낮은 성능과 높은 Latency를 가진다. 서브시스템들이 단순하게 분리된다는 장점도 가진다.
- Pipe and Filter Pattern : 입력과 출력 사이에 단순하고 일반적인 상호 작용 메커니즘을 사용하여 재사용하고 느슨하게 연결되어야 할때 사용하는 패턴. 파이프 연결을 위해 메시지 큐를 사용할 수 있다. 필터는 데이터 가공을 하며 각각 분할되어 식별가능해야한다. 필터 컴포넌트는 필터가 수행해야하는 태스크와 인접 파이프들에 의해 결정된다. 또 처리된 데이터는 바로 다음 단계로 전달된다. Batch Sequential Pattern은 이전 데이터의 처리가 모두 완료 되어야 다음 단계로 입력된다.
- Broker Pattern : 개별 서비스간 상호작용에 대한 고민이 필요할 때, 분리된 컴포넌트들을 구조화하고 상호작용하도록 하는 패턴. 모든 서비스는 브로커를 통해 상호 작용이 일어난다. 브로커는 서버를 등록하거나 등록에서 제거한다. 또 클라이언트의 요청을 실행하기위해 적절한 서버의 위치를 알아내고, 요청을 서버로 전송한뒤 클라이언트에게 결과를 반환하는 중개자가 된다. 브로커는 커뮤니케이션 병목점이 될 수 있다. 클라이언트와 서버에 각각 프록시(특정 시스템에 맞춰진 기능을 캡슐화)를 구현하고 해당 프록시와 브로커를 연관시킨다. 브로커는 메시지 큐나 중개 서버를 활용햐여 구현할 수있다.
- Publisher-Subscriber Pattern : Publisher와 Subscriber사이에 직접적인 종속성을 제거하여 시스템의 유연성을 높이는 패턴이다. Publisher에서 일어나는 변경사항에 종속된 모든 컴포넌트(Subscriber)에 메시지를 전송할 수 있게 한다.
