Architecture Tactics 는 Architecture Driver를 달성하는 일반적인 풀이 방식이다. 일반적으로 문제마다 정해진 문제 풀이 패턴이 존재한다. Architecture Driver도 마찬가지로 Architecture Driver의 속성에 따라 그에 맞는 문제 풀이 방법이 존재 한다. 여러 연구를 통해 문제 종류마다 그에 적합한 솔루션을 찾았고 이 솔루션들이 지속적으로 사용됨에 따라 Architecture Tactic이 되었다
Architecture Driver 는 품질 요구 사항 중, 중요도와 난이도가 높은 항목을 선정하여 설계를 통해 풀어야 하는 핵심 문제이다. Tactic은 일반적으로 전략을 의미한다. 소프트웨어 개발에서 Tactic은 설계 목표 달성 즉, Architecture Driver를 달성하기 위한 접근 방식이다.
하나의 문제를 푸는데, 여러 방법을 사용할 수 있는 것처럼, 하나의 Architecture Driver를 달성하는데 여러 Tactic이 동시에 사용될 수 있다. 문제에 대한 해결 방법을 여러 관점에서 고민해야 한다. 배경 지식이 많은 수록 Tactic 선정에 많은 도움이 된다.
자극은 품질 속성이고, 응답은 품질 속성을 달성한 결과물이라고 볼 수 있다. 자극을 응답으로 변환하도록 하는 것이 Archtiecture Tactic이다.
1. Functionality(가용성)을 위한 Architecture Tactics
가용성은 얼마나 원할하게 동작 하는가에 대한 품질 속성이다. 결함을 감추고 보수가 빠르게 이루어지도록 하여 서비스 가능시간을 최대한 늘리는 것이다. 이를 위해 하기와 같은 Tactic이 있다.
- 결함탐지 : 핑/에코, HeartBeat,
- 복구-준비 및 수정 : voting, 활성 중복, 비활성 중복, Spare
- 복구 : Check Point/Rollback
2. Efficiency(성능)을 위한 Architecture Tactics
성능은 고객에게 가장 잘 드러나는 품질 속성이다. 따라서 고객의 입장에서 가장 중요한 품질 속성 중 하나이다. 성능은 다른 품질 속성과는 다르게 비용을 요구한다. 증설 및 Resource 추가는 곧 비용이기 때문이다.
- 리소스 증설
- 더 많은 메모리 및 프로세서를 추가 함으로 처리 시간을 감소 시킨다.
- 동시성증가 (병렬처리)
- 여러 Thread를 생성하여 병렬로 처리하도록 한다.
- 복사본 유지
- 복제를 통해 서버의 부하를 분산 시킨다.
- Resource Scheduling.
- 동적으로 우선순위에 따라 스케줄링 한다.
- Dispatcher Architecture Style
- Active Repository Architecture Style
3. Maintainability(유지보수성)을 위한 Architecture Tactics
유지보수성을 달성하기 위해선, OCP를 위한 설계 원칙들을 적용해야 한다. SOLID 원칙 및 Clean Architecture 의존성 규칙을 적용함으로써, 유지보수성을 달성 할 수 있다. 유지보수성은 고객의 입장에서 드러나는 품질 속성이 아니다. 그렇기 때문에, 우선순위를 낮추기 쉽다. 그러나, 개발자 입장에선 가장 적은 노력(비용)으로 기능의 추가와 기존 code의 재사용을 위해서 반드시 추구해야 할 품질 속성이다.
- 모듈크기줄이기
- 모듈분할을 통해 향후 변경 시 Cost를 줄여야 한다.
- 응집도 높이기
- SRP원칙을 적용하여 해당 모듈이 하나의 책임만을 갖도록 한다.
- 결합도 낮추기
- 추상화된 Interface에 의존하도록 한다.
- 지연바인딩
- 결합되는 시점을 최대한 뒤로 이동시킨다.
- 설계시점부터 서로 의존 하지않고, Complie 타임이나 배포타임 등 최대한 binding되는 시점을 뒤로 미룬다.
- Layered Architecture Style
- Microservice Architecture Style
4. Reliablility(신뢰성)을 위한 Architecture Tactics
신뢰성을 통해 고객이 지속적으로 우리 시스템을 사용할 수 있도록 해야 한다. 이 품질 속성도 성능과 마찬가지로 고객의 입장에서 중요한 품질 속성이다.
- 내결함성 (Fault Tolerance)
- 로드밸런싱을 구현하여 부하를 분산
- 복구 시스템을 구현하여 다른 인스턴스로 전환
- 오류처리와 회복(Error Handling and Recovery)
- 오류 메시지 처리
- 장애상황 모니터링하여 문제 식별
- 자가치유성
- 스스로 오류나 장애를 감지하고 자동으로 복구
- Broker Architecture Style
5. Tactic으로 선정될 수 있는 Architecture Style
문제를 해결하기 위한 표준화된 해답으로 Architecture Style를 사용할 수 있다. 일반적인 문제 풀이 방법으로 사용된다.
문제에 대한 풀이 방법이 바로 떠오르지 않듯, Architecture Driver를 달성하기 위한 Architecture Tactic 또한 바로 떠오르지 않는다. 경험과 지속적인 학습이 필요하다. Architecture Style이나 Pattern, 설계 원칙들을 연구해보고 어떤 품질 속성 달성에 적합한지 고민해봐야 한다.
Architect 는 설계에 대한 전개 과정을 문서로 담아야 한다. 그래야 Software에 담겨있는 중요 결정에 대한 이유를 알 수 있다. 이유를 알아야 기존 Software 구조를 재사용 하든, Refactoring을 하든 결정할 수 있다.
Architecture Driver 를 달성하는데 해당 Architecture Tactic을 선택한 이유도 중요하지만, 후보 구조로 고려했지만 선택하지 않는 이유를 논리적으로 설명할 수 있어야 한다.
이렇게 선택에 대한 이유를 기록해두는 것은 추후 제품 개발에 도움이 된다. 제품 개발 환경은 지속적으로 변하고 요구 사항 또한 변하기 때문이다. 새로운 제품 개발 시, 과거의 결정을 살펴보고, 기존 구현을 승계해야 하는지 또는 재설계 해야 하는지 결정 할 수 있다. 또한 이러한 논리적인 전개를 Architecture Description을 통해 풀어낼 수 있어야 한다.