Software Architecture: 사례를 포함한 ATAM, Architecture Evaluation

여기서는 Software Architect가 이해 관계자들과 아키텍처 평가를 진행하는 실 사례를 ATAM을 기준으로  살펴 보자.

 

Software Architecture 평가 방법에 대해서 [1]에서 CBAM 및 ATAM을 포함하여 설명하고 있다. 특히, ATAM 관련해서는 [2][3]에서 잘 설명하고 있다. ATAM의 예로서는 [4]에서 살펴 볼 수 있다. 특히, [2]에서 살펴 볼 수 있는 9가지 단계는 잘 살펴 보면 아키텍처를 설계하는 것과 같은 절차이다. 즉, 설계한 아키텍처를 이해관계자들에게 전달하는 것을 포함하여 설계의 평가에 대한 내용도 전달하는 것이다. 그렇다면, 어떻게 전달해야 하는 것일까?

 

ATAM 프로세스[2]

 

핵심은 위의 그림에 있다. 특히 분석(Analysis)가 가장 중심이 된다. 이 것의 입력으로 볼 수 있는 것이 품질 속성 시나리오(Quality Attribute Scenario)와 아키텍처 결정(Architectural Decision)이라고 볼 수 있다.

 

아키텍처 설계에서 중요한 것이 품질 속성이라고 볼 수 있다. 비지니스 드라이버(Business Driver)에서 품질 속성(Quality Attribute)를 도출하고 시나리오에 적용하여 분석한다. 이와 더불어 아키텍처에서 여러 접근법을 활용하여 아키텍처 결정(Architectural Decision)을 결정한다.

 

이를 기반으로 아키텍처 설계가 잘 되었는지 분석을 할 때, 트레이드오프(Tradeoff), 센세티비티 포인트(Sensitivity Point), 논리스크(Non-risk) 그리고 리스크를 도출하고 이것들이 영향을 미치는 설계를 반복하여 최종적인 설계가 완료될 때까지 검토를 하면 된다.

 

이해관계자들에게 이 부분을 어떻게 보여 주면 좋을까? 아래는 iPhone의 SharePlay와 유사하게 다른 사람들과 컨텐츠를 함께 보는 서비스의 설계 관련한 품질 속성으로 도출한 서버 비용(Server Cost)의 품질 시나리오(Quality Scenario) 측면에서의 ATAM 보고의 일부이다.

Scenario	공동 시청에 사용되는 서버 비용은 작아야 한다.
Environment	시스템 정상 동작
Stimulus	서비스 시작
Artifact	시스템
Response	서비스는 서버를 사용하여 서비스를 제공
Measure	[Cloud 포함 서비스 운영 비용 < 월 $5000]
Architectural Decision		Sensitivity	Tradeoff	Non-Risk	Risk
Video/Control 분리		S1	T1	N1
RTT 기반 성능 관리		S2	T2		R1
Sensitivity	S1: 컨텐츠 공유 방안에 따라 서버 비용에 영향을 받는다. S2: 사용자 간 재생 위치 최적화 방안에 따라 서버 비용에 영향을 미친다.
Tradeoff	T1: Server Cost vs Modifiability OTT 추가에 따른 수정용이성을 좋게 하기 위해서 실재 비디오 데이터를 다뤄야 하므로 서버 비용이 증가하고, 서버 비용을 줄이기 위해 비디오와 컨트롤을 분리하면 수정용이성이 나빠진다. T2: Server Cost vs Performance 사용자간 재생 위치 최적화에 대한 서버 비용을 최소화 하려면 추가적인 통신을 하지 않도록 해야 한다. 하지만, 추가적인 성능 확보를 위한 추가적인 정보교환이 필요한 경우 서버 비용이 증가한다.
Non-risk	N1: 비디오와 컨트롤을 분리하여 컨트롤만 서버가 담당하게 하여 서버 비용을 줄였다.
Risk	R1: 사용자가 재생 위치 차이 최적화를 위하여 참가자들의 네트워크 상황을 파악하고 수집하여 기준 사용자 선정하는데 추가적인 통신을 수행하였다. 이를 위한 서버 비용 증가가 발생하였다.
Reasoning	사용자간 재생 위치 차이 최적화를 위하여 초가적인 통신이 발생하는데, 이를 위한 서버 비용 증가를 피하기 어렵다. 하지만, 이 부분 또한 기존 통신 필요 기능에 관련 기능 통합을 고려하여 추가 최적화를 진행하여 비용을 최소화하였다.
Architectural Diagram	** 편의상 구조도는 생략한다.

 

위의 내용에서 품질 시나리오는 설계시 도출된 것을 그대로 가져온다. 그리고, 이 품질 속성과 관련된 아키텍처 결정(Architectural Decision)을 가져오고, 분석(Analysis)를 통해 도출한 트레이드오프(Tradeoff), 센세티비티(Sensitivity), 논리스크(Non-risk) 그리고 리스크(Risk)를 설명한다. 특히, 트레이드오프는 아키텍처 결정에 따른 트레이드오프 관계의 품질 속성에 대해 상세한 설명이  필요하다. 또한 선택된 구조로 인한 리스크에 대해서 상세히 기술할 필요가 있다. 이를 위해서 리스크에 대해서 어떻게 관리해야 하는지에 대한 설명(Reasoning)도 반드시 있어야 한다.

참고 문헌

[1] 소프트웨어 구조 평가 모델 비교, http://blog.skby.net/%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98-%ED%8F%89%EA%B0%80-%EB%AA%A8%EB%8D%B8-atam-cbam/

[2] 아키텍처 트레이드오프 분석 방법(ATAM), https://www.geeksforgeeks.org/architecture-tradeoff-analysis-method-atam/

[3] 소프트웨어 아키텍처 평가, https://www.slideshare.net/ssuserff7918/atam-19297511

[4] Rick Kazman, et al, "ATAM: Method for Architecture Evaluation," https://www.win.tue.nl/~wstomv/edu/2ii45/year-0910/00tr004.pdf

[5] iPhone SharePlay, https://support.apple.com/ko-kr/guide/iphone/iph861568c10/ios