소프트웨어 아키텍처 스타일의 평가
측정은 평가를, 평가는 진화를 매개한다!
아키텍처 스타일은 제약의 집합이며, 이러한 제약이 속성을 유도한다는 점을 앞 장에서 살펴보았다. 이제 아키텍처 스타일의 종류와 각 스타일이 지닌 속성들을 자세히 알아보겠다.
Data Flow Styles
데이터의 흐름과 관련된 아키텍처 스타일 중 Pipe and Filter와 Uniform Pipe and Filter를 살펴보겠다.
Pipe and Filter와 Uniform Pipe and Filter 소개
Pipe and Filter는 데이터가 흐르는 파이프에 원하는 필터를 자유롭게 추가할 수 있는 아키텍처 스타일이다. Uniform Pipe and Filter는 이에 더해 모든 필터가 동일한 인터페이스를 가져야 한다는 제약을 추가한다.
예를 들어, 고객의 주문을 처리하는 시스템을 상상해 보자. 고객의 주문(Order)은 보안을 위해 암호화되어 있으며, 고객의 인증 정보도 포함되어 있다. 또한 중복 주문을 방지하기 위해 특별한 처리가 필요하다.
이때, 주문 데이터를 처리하기 위한 파이프를 만들고, 그 안에 암호화된 주문을 복호화하는 필터, 복호화된 주문에서 고객 인증 정보를 검사하는 필터, 그리고 마지막으로 중복 주문을 방지하는 필터를 추가할 수 있다. 이를 도식화하면 아래와 같다:
IncomingOrder(입력) ⇒ Pipe → Filter(복호화) → Filter(구매자 인증) → Filter(중복 주문 방지) → Pipe ⇒ CleanOrder(출력)
Pipe and Filter 스타일에서는 각 필터가 작업을 완료한 결과를 다음 필터로 전달한다. 만약 모든 필터가 동일한 입력 및 출력 인터페이스를 보장해야 한다면 Uniform Pipe and Filter 스타일이 된다. 즉, Pipe and Filter에 Uniform Interface의 제약이 더해진 것이다.
이러한 인터페이스에 대한 엄격한 제약이 얼마나 유용할까? 과장해서 말하면 로이 필딩의 이 논문 Architectural Styles and the Design of Network-based Software Architectures의 가치가 바로 여기에 있다고 말할 수 있을 정도로 엄청난 유용함을 만들어 낸다. 추후 REST를 소개할 때 Uniform Interface의 제약에 대해서 자세히 살펴볼 예정이다.
Pipe and Filter와 Uniform Pipe and Filter의 평가
Pipe and Filter는 전체 시스템의 입출력이 단순한 필터들의 조합으로 이루어지므로 단순성(simplicity)을 높여준다. 각 필터의 입출력이 명확하여 호환되는 필터끼리 자유롭게 연결할 수 있어 재사용성(reusability)과 설정 가능성(configurability)이 향상된다. 기존 파이프라인에 새로운 필터를 쉽게 추가할 수 있어 기능 확장성(extensibility)이 좋으며, 기존 필터를 개선된 버전으로 교체하는 것도 간단하기 때문에 진화 가능성(evolvability) 또한 높다. 또한, 어느 지점까지 수행했는지 파악하거나, throughput 분석 및 deadlock 분석 등 검증 가능성(verifiability)도 상대적으로 높은 편이다.
하지만 파이프라인이 너무 길면 전파 지연(propagation delay)이 발생할 수 있으며, 다수의 입력을 요구하는 파이프라인에서는 배치 프로세싱으로 인해 고객 체감 성능(user perceived performance)이 저하될 수 있다. 또한, 다른 필터나 파이프라인 외부의 맥락(외부 변수 등)과의 상호작용이 허용되지 않는다는 한계도 있다(interactivity).
Data Flow Styles와 유도된 속성 평가
아래의 속성들이 강화되었다.
단순성(simplicity)
재사용성(reusability)
설정 가능성(configurability)
기능 확장성(extensibility)
진화 가능성(evolvability)
검증 가능성(verifiability)
특히 Uniform Pipe and Filter는 단순성(simplicity), 재사용성(reusability), 설정 가능성(configurability)을 한층 강화시킨다.
아래의 속성들이 약화되었다.
고객 체감 성능(user perceived performance)
상호작용성(interactivity)
Scalability와 Extensibility
아키텍처 속성 중 Scalability와 Extensibility는 둘 다 확장성이라고 번역될 수 있다. 이러한 모호함을 없애기 위해, 가급적 아래의 형태로 번역하고자 한다.
Scalability: 성능 확장성. 시스템에 자원을 추가했을 때, 얼마나 더 많은 요청을 처리할 수 있는가를 의미한다.
Extensibility: 기능 확장성. 얼마나 쉽게(장애 혹은 서비스 중단없이) 시스템에 기능의 변경 혹은 추가가 가능한가를 의미한다.
소프트웨어 아키텍처 설계의 평가
특정 시스템의 아키텍처 설계는 여러 아키텍처 스타일을 선택하고 결합하거나 새롭게 창조하는 과정이다. 이 과정에서 어떤 스타일과 속성이 적용되었는지 파악하고, 이들이 서로 상충하는지, 아니면 서로를 보완하여 더 나은 결과를 이끌어낼 수 있는지를 평가하는 것이 중요하다. 이러한 평가를 통해 설계가 의도된 목적을 얼마나 잘 달성할 수 있는지 판단할 수 있다.
맺음말
지금까지 소프트웨어 아키텍처 스타일과 그 평가 방안에 대해서 알아봤다. 우리는 사례를 봄으로써 이해도와 응용력을 높일 수 있다. 따라서 다음 장에서는 다양한 스타일들과 이들의 조합 방법을 알아보도록 하겠다.
3편 끝.
